Vous faites tourner plusieurs agents IA de programmation sur le meme depot de code. Peut-etre trois, peut-etre treize. Ils doivent gerer leur propre travail : creer des issues, mettre a jour des statuts, verifier les dependances, rapporter leur progression. Des dizaines d'ecritures par minute a travers toute la flotte.
C'est l'agentic engineering : des humains qui coordonnent des flottes d'agents IA pour produire du logiciel. Le workflow est nouveau, mais la premiere chose que tout le monde fait, c'est d'utiliser l'outil qu'il connait deja. Jira. Linear. GitHub Issues. Notion. Peu importe ce que votre equipe utilise pour la gestion de projet.
Ca ne fonctionne pas. Et l'incompatibilite n'est pas superficielle. Elle est architecturale.
La latence tue le debit
Un appel a l'API de Jira prend entre 200 et 800ms. Un appel a l'API de Linear est plus rapide, mais reste entre 100 et 300ms. Creer une seule issue, lire ses dependances, mettre a jour son statut : ce sont trois allers-retours a travers HTTPS, resolution DNS, handshake TLS et serialisation JSON. Disons 500ms par beau temps.
Une ecriture locale via CLI dans une base de donnees SQLite prend moins de 50ms. Souvent moins de 10ms.
Ca ressemble a une erreur d'arrondi jusqu'a ce que vous multipliiez par le nombre d'operations. Un agent travaillant sur une tache peut creer 2 ou 3 sous-issues, mettre a jour le statut du parent, verifier les blocages et commenter sa progression. Six operations. A 500ms chacune, ca fait 3 secondes d'attente pure. A 10ms chacune, 60 millisecondes. L'agent qui pourrait terminer un cycle de tache en 30 secondes passe maintenant 10% de son temps a attendre des reponses HTTP au lieu d'ecrire du code.
Multipliez ca par 13 agents et la surcharge se mesure en minutes par heure.
L'infrastructure d'authentification est un liant fragile
Chaque agent a besoin d'un token API. Les tokens expirent. Les limites de debit existent. Un agent envoie une rafale de 20 mises a jour rapides et recoit un 429 Too Many Requests. Le voila coince dans une boucle de retry avec backoff exponentiel au lieu de faire son travail.
Vous venez d'ajouter un mode de defaillance complet qui n'a rien a voir avec le travail lui-meme. Rotation des tokens, gestion des secrets, repartition des limites de debit entre agents. C'est de la surcharge operationnelle pour une capacite qui devrait etre triviale : ecrire un enregistrement dans une base de donnees locale.
Quand l'issue tracker est un fichier sur disque, il n'y a rien contre quoi s'authentifier. Si l'agent peut lire le systeme de fichiers, il peut lire et ecrire des issues. Une chose de moins qui peut casser.
Le modele de donnees suppose des humains
Ouvrez Jira. Vous voyez des sprints. Des story points. Des responsables avec photos de profil et adresses email. Des workflows avec des etats comme "En revue" et "Pret pour le refinement". Le modele de donnees entier a ete concu pour une equipe d'humains faisant des standups, de la planification de sprint et des retrospectives.
Les agents ne font pas de standups. Ils n'estiment pas en story points. Ils n'ont pas besoin d'un workflow a sept etats et quatre portes d'approbation.
Ce dont les agents ont besoin, c'est d'un graphe de dependances. Cette tache est bloquee par celle-la. Cet epic a 12 enfants et 7 sont termines. Cet agent a revendique cette issue il y a 45 secondes et n'a pas rapporte. La structure de donnees fondamentale est un arbre de taches avec des relations de blocage, pas un tableau de cartes qui se deplacent entre des colonnes.
Les outils SaaS ajoutent des fonctions d'"automatisation", mais le modele central en dessous reste un tableau Kanban pour humains. Vous pouvez ecrire un plugin Jira qui permet aux agents de creer des issues. Vous ne pouvez pas changer le fait que Jira pense que votre agent est une personne dans une equipe de sprint.
La dependance au cloud est un point unique de defaillance
Vos agents tournent en local. Ils lisent des fichiers locaux, ecrivent du code local et font des commits dans des repos git locaux. Ils peuvent travailler hors connexion, dans un avion ou sur un reseau avec 2000ms de latence. Ca ne les derange pas.
Mais si votre issue tracker est un produit SaaS, chaque operation de l'agent necessite un acces internet. Linear tombe pendant 10 minutes ? Toute votre flotte s'arrete. Votre connexion internet a la maison coupe pendant 30 secondes ? Chaque agent retente en boucle. L'issue tracker, la chose censee coordonner le travail, devient le point unique de defaillance de tout le systeme.
Local-first signifie que l'issue tracker est aussi fiable que le systeme de fichiers. Toujours disponible, toujours rapide, toujours sous votre controle.
Le volume d'ecritures est de plusieurs ordres de grandeur a cote
Les outils SaaS de gestion de projet sont concus pour une equipe de 5 a 10 humains faisant quelques mises a jour par jour. Peut-etre 50 a 100 ecritures pour toute l'equipe.
13 agents mettant a jour des issues toutes les quelques minutes produisent des centaines d'appels API par heure depuis un seul projet. Ce n'est pas une augmentation marginale de l'utilisation. C'est un patron d'utilisation completement different. Les limites de debit qui semblent genereux pour des equipes humaines deviennent des murs infranchissables pour des flottes d'agents.
Et ce n'est pas seulement le volume. C'est la concurrence. Trois agents mettant a jour les enfants du meme epic simultanement. Des conditions de course sur les champs de statut. Des echecs de verrouillage optimiste sur les fils de commentaires. Ce sont des problemes que les outils SaaS n'ont jamais eu a resoudre parce que les humains ne mettent pas a jour la meme issue depuis trois terminaux au meme instant.
Collaborer, c'est abandonner vos donnees
Pour partager un projet Jira avec un collegue, vous avez tous les deux besoin de comptes Jira. Les donnees vivent sur les serveurs d'Atlassian. Vous payez par siege, par mois, pour le privilege d'acceder a vos propres donnees de projet via leur API.
Vous voulez migrer vers un autre outil ? Exportez ce que vous pouvez en CSV et abandonnez le reste. Commentaires, pieces jointes, champs personnalises, historique d'audit : bonne chance pour extraire tout ca dans un format utilisable. Le modele SaaS echange la propriete des donnees contre de la commodite.
Mais la collaboration ne necessite pas d'intermediaire. Si votre base de donnees d'issues est supportee par quelque chose comme Dolt (Git pour les bases de donnees), vous la poussez vers un remote et votre collegue la tire. Creez des branches dans votre base de donnees d'issues comme vous creez des branches dans votre code. Faites des merges de la meme facon. Resolvez les conflits avec les memes outils et le meme modele mental. Vos donnees restent les votres. La collaboration fonctionne comme git, pas comme un abonnement.
Ce qui fonctionne vraiment
Oubliez les noms de marque et pensez a ce dont les agents ont reellement besoin d'un issue tracker :
- Local-first. Pas de dependance reseau. La base de donnees est un fichier sur disque.
- Natif CLI. Les agents vivent dans le terminal. L'interface devrait aussi.
- Supporte par Git. Versionne, fusionnable, auditable. Pas de dependance fournisseur.
- Pas de surcharge d'authentification. Si l'agent peut lire le systeme de fichiers, il peut gerer des issues.
- Faible latence. Moins de 50ms par operation, pas 500ms.
- Synchronisable sans intermediaire. Push et pull comme un repo git, pas via des webhooks API.
C'est ce que j'utilise au quotidien. beads est un issue tracker natif Git concu exactement pour ce workflow. Il stocke tout dans une base de donnees locale SQLite supportee par Dolt pour le versionnement et la synchronisation. Le CLI est l'interface principale. Les agents creent, mettent a jour et interrogent des issues de la meme facon qu'ils executent n'importe quelle autre commande.
Beadbox est la couche visuelle que j'ai construite par-dessus. Elle surveille la base de donnees locale pour detecter les changements et affiche les arbres de dependances, la progression des epics et l'activite des agents en temps reel. Les agents utilisent le CLI. J'utilise le dashboard. Les deux lisent la meme base de donnees locale.
Les anciens outils ne sont pas le probleme
Jira est excellent dans ce qu'il fait : coordonner des equipes humaines a travers des workflows structures. Linear est superbe pour les petites equipes qui veulent vitesse et finition. GitHub Issues est parfait pour la collaboration open-source.
Aucun d'entre eux n'est mauvais. Ils resolvent un probleme different. Si votre workflow est une equipe de cinq humains faisant des sprints de deux semaines, continuez a les utiliser.
Mais si vous faites tourner 5, 10 ou 13 agents IA se coordonnant en temps reel sur le meme depot de code, vous avez depasse le modele SaaS. L'agentic engineering a besoin d'outils construits pour l'agentic engineering, pas de workflows humains avec une API rajoutee.