tsutsumbi
Un suivi de projet où c'est l'agent qui ouvre les tickets, change les statuts et clôt sans validation humaine. L'humain consulte, recadre, archive.
Le point de départ
Quand une partie du travail de développement est menée par des agents, le suivi de projet classique se retourne. Les outils existants supposent qu'un humain ouvre le ticket, qu'un humain le déplace, et qu'un humain valide sa clôture. Chacune de ces trois étapes devient un goulot dès lors que celui qui fait le travail n'est pas celui qui tient le tableau.
Le symptôme est connu de quiconque a essayé : soit l'agent ne touche pas au suivi, et le tableau ment dès la deuxième heure ; soit il y touche, et il produit un flot de tickets techniques — « refactoriser le dépôt », « corriger le test qui échoue » — qui sont des étapes de travail, pas des unités de suivi.
D'où le positionnement, qu'il vaut mieux énoncer que laisser deviner : tsutsumbi ne remplace pas les tickets d'un dépôt de code. Il traite un cas qu'ils ne traitent pas — un suivi dont l'écrivain principal est une machine et le lecteur principal un humain, sur des projets qui ne sont pas tous du code.
Tsoutsoumbi est un petit insecte de Mayotte. Insecte, bug, gestion de projet : le nom était écrit.
Ce qui a été construit
Un suivi de projet dont l'écrivain principal est l'agent. Il ouvre les tickets, passe les statuts, commente les décisions et clôt en choisissant lui-même la résolution — corrigé, ne sera pas fait, abandonné, doublon, obsolète — sans attendre d'accord.
L'humain garde trois gestes : consulter, recadrer, archiver.
Deux interfaces sur le même modèle : une interface web pour l'humain, un serveur MCP pour l'agent. Ce n'est pas une passerelle posée après coup — les deux accès sont de premier rang.
Le déroulé
Écrire la règle d'abord, le code ensuite
La partie la plus difficile de ce projet n'a pas été le modèle de données — un ticket, un projet, des événements, ce n'est pas un sujet de recherche. Elle a été de définir ce qu'est un ticket avec assez de netteté pour qu'une machine s'y tienne.
La formulation retenue : une unité fonctionnelle que quelqu'un reconnaîtrait trois mois plus tard. « Export CSV des relevés », « TVA fausse sur les avoirs partiels ». Jamais une étape technique. Le titre décrit le résultat attendu, pas l'action ; la description tient en trois lignes — le besoin, la contrainte, ce qui est hors périmètre.
Cette règle ne vit pas dans une documentation à côté. Elle est écrite dans la description des outils eux-mêmes, à l'endroit exact où l'agent la lit au moment de s'en servir. Une consigne rangée ailleurs n'est pas appliquée — c'est vrai des humains, c'est encore plus vrai des machines.
Donner à l'agent le droit de clore
La décision structurante, et celle qui surprend. Un agent qui doit demander la permission de fermer un ticket ne ferme rien : il laisse le ticket ouvert et passe à la suite, et le tableau se remplit de travail terminé qu'on croit en cours.
La clôture est donc autonome, avec obligation de choisir une résolution. « Ne sera pas fait » et « abandonné » exigent en plus un commentaire d'explication — ce sont les deux seuls cas où l'absence de justification rendrait l'historique inutilisable six mois plus tard.
Le garde-fou n'est pas la validation, c'est la traçabilité. Rien n'est supprimé, chaque changement laisse un événement, et l'humain peut rouvrir. On échange un contrôle a priori — qui ne fonctionnait pas — contre un contrôle a posteriori qui, lui, fonctionne.
Traiter le blocage muet comme le pire état possible
Un ticket bloqué sans explication est plus nuisible qu'un ticket jamais ouvert : il donne l'impression que le sujet est pris en charge. Le passage au statut « bloqué » exige donc un commentaire, techniquement, dans la même transaction que le changement de statut. On ne peut pas bloquer en silence.
Même logique en fin de session : un ticket laissé en cours doit porter un mot disant où il en est.
Deux interfaces, un seul modèle
Le serveur MCP n'est pas une interface greffée sur une application web. Les deux accès ont été pensés ensemble, et les outils exposés à l'agent portent la même sémantique métier que les écrans, avec les mêmes contraintes.
Conséquence directe : il n'existe pas d'état atteignable par la machine et invisible à l'humain. C'est la garantie minimale d'un outil où l'écrivain principal n'est pas le lecteur principal.
Ce que ça a changé
L'outil est en production et suit mes propres projets, dont celui-ci. Le tableau reste juste sans effort d'entretien de ma part, ce qui était le seul objectif.
Ce que ce projet a produit d'inattendu : la contrainte « pas de ticket technique » a amélioré ma propre façon de découper le travail. Formuler ce qu'on fait en résultat attendu plutôt qu'en action à mener est un exercice utile même sans agent en face.
Ce qui reste ouvert : le nombre de projets suivis grandit, et la vue transversale — « où en est l'ensemble ? » — n'existe pas encore. C'est le prochain besoin réel.
