Vous faites tourner plusieurs agents IA de programmation sur le même dépôt. Peut-être trois, peut-être treize. Ils doivent gérer leur propre travail : créer des tickets, mettre à jour des statuts, vérifier les dépendances, rapporter leur progression. Des dizaines d'écritures par minute sur toute la flotte.
C'est l'ingénierie agentique : des humains coordonnant des flottes d'agents IA pour livrer du logiciel. Le workflow est nouveau, mais la première chose que tout le monde fait est de se tourner vers l'outil qu'il connaît déjà. Jira. Linear. GitHub Issues. Notion. Tout ce que votre équipe utilise pour la gestion de projets.
Ça ne fonctionne pas. Et l'incompatibilité n'est pas superficielle. Elle est architecturale.
La latence tue le débit
Un appel API Jira prend de 200 à 800ms. Un appel API Linear est plus rapide mais reste entre 100 et 300ms. Créer un seul ticket, lire ses dépendances, mettre à jour son statut : ce sont trois allers-retours via HTTPS, résolution DNS, handshake TLS et sérialisation JSON. Disons 500ms par beau temps.
Une écriture locale via CLI dans une base de données SQLite prend moins de 50ms. Souvent moins de 10ms.
Ça ressemble à une erreur d'arrondi jusqu'à ce que vous multipliiez par le nombre d'opérations. Un agent travaillant sur une tâche peut créer 2 ou 3 sous-tickets, mettre à jour le statut du parent, vérifier les blocages et commenter sa progression. Six opérations. À 500ms chacune, ça fait 3 secondes d'attente pure. À 10ms chacune, 60 millisecondes. L'agent qui pourrait terminer un cycle de tâche en 30 secondes passe maintenant 10% de son temps à attendre HTTP au lieu d'écrire du code.
Multipliez par 13 agents et l'overhead se mesure en minutes par heure.
L'infrastructure d'authentification est de la colle fragile
Chaque agent a besoin d'un token API. Les tokens expirent. Les limites de taux existent. Un agent lance 20 mises à jour rapides et reçoit un 429 Too Many Requests. Le voilà coincé dans une boucle de retry avec backoff exponentiel au lieu de faire son travail.
Vous venez d'ajouter un mode de défaillance entier qui n'a rien à voir avec le travail lui-même. Rotation de tokens, gestion de secrets, répartition des limites de taux entre agents. C'est de l'overhead opérationnel pour une capacité qui devrait être triviale : écrire un enregistrement dans une base de données locale.
Quand le gestionnaire de tickets est un fichier sur disque, il n'y a rien à authentifier. Si l'agent peut lire le système de fichiers, il peut lire et écrire des tickets. Un souci de moins.
Le modèle de données suppose des humains
Ouvrez Jira. Vous voyez des sprints. Des story points. Des assignés avec photos de profil et adresses email. Des workflows avec des états comme "En revue" et "Prêt pour le raffinement". Le modèle de données entier a été conçu pour une équipe d'humains faisant des standups, du sprint planning et des rétrospectives.
Les agents ne font pas de standups. Ils n'estiment pas en story points. Ils n'ont pas besoin d'un workflow à sept états et quatre portes d'approbation.
Ce dont les agents ont besoin, c'est d'un graphe de dépendances. Cette tâche est bloquée par celle-là. Cet épique a 12 enfants et 7 sont terminés. Cet agent a revendiqué ce ticket il y a 45 secondes et n'a pas fait de rapport. La structure de données fondamentale est un arbre de tâches avec des relations de blocage, pas un tableau de cartes se déplaçant entre des colonnes.
Les outils SaaS ajoutent des fonctionnalités d'"automatisation", mais le modèle central reste un tableau Kanban pour humains. Vous pouvez écrire un plugin Jira qui permet aux agents de créer des tickets. Vous ne pouvez pas changer le fait que Jira pense que votre agent est une personne dans une équipe de sprint.
La dépendance au cloud est un point unique de défaillance
Vos agents tournent localement. Ils lisent des fichiers locaux, écrivent du code local et font des commits dans des repos git locaux. Ils peuvent travailler hors ligne, dans un avion ou sur un réseau avec 2000ms de latence. Ça leur est égal.
Mais si votre gestionnaire de tickets est un produit SaaS, chaque opération d'agent nécessite un accès internet. Linear tombe pendant 10 minutes ? Toute votre flotte s'arrête. Votre internet domestique vacille pendant 30 secondes ? Chaque agent boucle en retry. Le gestionnaire de tickets, celui qui est censé coordonner le travail, devient le point unique de défaillance de tout le système.
Local-first signifie que le gestionnaire de tickets est aussi fiable que le système de fichiers. Toujours disponible, toujours rapide, toujours sous votre contrôle.
Le volume d'écritures est de plusieurs ordres de grandeur supérieur
Les outils SaaS de gestion de projets sont conçus pour une équipe de 5 à 10 humains faisant quelques mises à jour par jour. Peut-être 50 à 100 écritures sur toute l'équipe.
13 agents mettant à jour des tickets 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 schéma d'utilisation entièrement différent. Les limites de taux qui semblent généreuses pour les équipes humaines deviennent des murs infranchissables pour les flottes d'agents.
Et ce n'est pas que le volume. C'est la concurrence. Trois agents mettant à jour les enfants du même épique simultanément. Des conditions de course sur les champs de statut. Des échecs de verrouillage optimiste sur les fils de commentaires. Ce sont des problèmes que les outils SaaS n'ont jamais eu à résoudre parce que les humains ne mettent pas à jour le même ticket depuis trois terminaux au même instant.
Collaborer signifie céder vos données
Pour partager un projet Jira avec un collègue, vous avez tous les deux besoin de comptes Jira. Les données vivent sur les serveurs d'Atlassian. Vous payez par siège, par mois, pour le privilège d'accéder à vos propres données de projet via leur API.
Vous voulez migrer vers un autre outil ? Exportez ce que vous pouvez en CSV et abandonnez le reste. Commentaires, pièces jointes, champs personnalisés, historique d'audit : bonne chance pour tout extraire dans un format utilisable. Le modèle SaaS échange la propriété des données contre la commodité.
Mais la collaboration ne nécessite pas d'intermédiaire. Si votre base de données de tickets est sauvegardée par quelque chose comme Dolt (Git pour les bases de données), vous faites un push vers un remote et votre collègue fait un pull. Créez des branches sur votre base de tickets comme vous le faites sur du code. Fusionnez de la même façon. Résolvez les conflits avec les mêmes outils et le même modèle mental. Vos données restent les vôtres. La collaboration fonctionne comme git, pas comme un abonnement.
Ce qui fonctionne vraiment
Oubliez les noms de marque et réfléchissez à ce dont les agents ont réellement besoin d'un gestionnaire de tickets :
- Local-first. Aucune dépendance réseau. La base de données est un fichier sur disque.
- Natif CLI. Les agents vivent dans le terminal. L'interface devrait aussi.
- Basé sur Git. Versionné, fusionnable, auditable. Pas de verrouillage fournisseur.
- Sans overhead d'authentification. Si l'agent peut lire le système de fichiers, il peut gérer des tickets.
- Faible latence. Moins de 50ms par opération, pas 500ms.
- Synchronisable sans intermédiaire. Push et pull comme un repo git, pas via des webhooks d'API.
C'est ce que j'utilise au quotidien. beads est un gestionnaire de tickets natif Git conçu exactement pour ce workflow. Il stocke tout dans une base de données locale SQLite adossée à Dolt pour le versionnement et la synchronisation. Le CLI est l'interface principale. Les agents créent, mettent à jour et consultent des tickets de la même façon qu'ils exécutent n'importe quelle autre commande.
Beadbox est la couche visuelle que j'ai construite par-dessus. Elle surveille la base de données locale pour détecter les changements et affiche les arbres de dépendances, la progression des épiques et l'activité des agents en temps réel. Les agents utilisent le CLI. J'utilise le dashboard. Les deux lisent la même base de données locale.
Les anciens outils ne sont pas le problème
Jira excelle dans ce qu'il fait : coordonner des équipes humaines à travers des workflows structurés. Linear est magnifique pour les petites équipes qui veulent vitesse et élégance. GitHub Issues est idéal pour la collaboration open-source.
Aucun d'entre eux n'est mauvais. Ils résolvent un problème différent. Si votre workflow est une équipe de cinq humains faisant des sprints de deux semaines, continuez à les utiliser.
Mais si vous faites tourner 5, 10 ou 13 agents IA se coordonnant en temps réel sur le même dépôt, vous avez dépassé le modèle SaaS. L'ingénierie agentique a besoin d'outils conçus pour l'ingénierie agentique, pas de workflows humains avec une API greffée par-dessus.