Le ticket semble simple. Une dépendance à mettre à jour, une erreur de validation à corriger, un test instable à stabiliser. L’équipe hésite : faut-il le donner à un agent IA, le traiter manuellement ou le transformer d’abord en tâche plus étroite ? Cette décision arrive souvent trop tard, au moment où l’agent a déjà lu trop de fichiers, proposé un diff trop large ou demandé une validation humaine parce que le périmètre initial était flou.
Le sujet n’est pas de savoir si l’agent est capable de coder. La question utile est plus précise : ce ticket possède-t-il les propriétés qui rendent une délégation vérifiable, limitée et réversible ? Un bon arbre de décision évite deux dérives opposées : refuser toute autonomie par prudence, ou déléguer des tickets mal cadrés parce qu’ils paraissent répétitifs.
Point de départ : le ticket décrit-il un résultat vérifiable ?
La première branche est volontairement stricte. Si le ticket ne permet pas de dire clairement ce qui doit changer et comment le résultat sera vérifié, il ne doit pas partir directement vers un agent. Il peut être reformulé avec l’aide de l’IA, mais pas exécuté par elle.
Un ticket délégable contient au minimum un comportement attendu, un périmètre de fichiers probable, une commande ou une méthode de validation, et une limite explicite. Sans ces éléments, l’agent risque de compenser par des hypothèses. Le diff peut alors devenir convaincant en surface, tout en répondant à une interprétation non validée du besoin.
- Oui : passer à la question suivante.
- Non : demander une clarification, écrire des critères d’acceptation ou transformer le ticket en tâche de diagnostic.
Le changement est-il localisable avant exécution ?
Un agent travaille mieux lorsque l’équipe peut nommer une zone probable : un composant, un module, une route, une commande, une suite de tests, un fichier de configuration. Il n’a pas besoin d’un périmètre parfait, mais il doit commencer dans un espace raisonnable.
Si le ticket touche potentiellement l’architecture, les permissions, les migrations de données ou plusieurs services, la délégation brute devient moins pertinente. Dans ce cas, l’agent peut aider à cartographier, résumer ou proposer un plan, mais l’exécution devrait rester humaine ou fortement découpée.
Arbre de décision rapide
| Question | Si oui | Si non |
|---|---|---|
| Le résultat attendu est-il observable ? | Continuer l’évaluation. | Reformuler le ticket avant délégation. |
| Le périmètre probable est-il borné ? | Autoriser une exploration limitée. | Demander une cartographie sans modification. |
| Le changement est-il réversible ? | Envisager une délégation avec PR. | Garder une validation humaine préalable. |
| Les tests ou contrôles existent-ils ? | Exiger leur exécution dans la sortie. | Demander d’abord une proposition de tests. |
| Le ticket expose-t-il des secrets, droits ou données sensibles ? | Limiter fortement ou exclure. | Continuer vers la délégation. |
Anecdote hypothétique : le ticket qui semblait mécanique
Imaginons une équipe qui confie à un agent IA un ticket intitulé « remplacer l’ancien client HTTP ». Le changement paraît mécanique : une API interne a été renommée, quelques appels doivent suivre. L’agent trouve bien les occurrences, modifie les imports, ajuste deux tests et ouvre une pull request propre.
En revue, un détail apparaît : l’ancien client appliquait implicitement une politique de retry sur certains statuts, tandis que le nouveau client laisse cette décision à l’appelant. Le ticket n’était donc pas seulement une migration syntaxique. Il touchait au comportement réseau. L’erreur ne vient pas d’un mauvais modèle, mais d’une mauvaise classification initiale du ticket.
Dans l’arbre de décision, ce ticket aurait dû bifurquer vers « analyse avant exécution ». L’agent aurait pu produire une carte des appels, signaler les différences de comportement et proposer un découpage. La modification automatique, elle, aurait attendu une décision humaine.
Branche 1 : délégation directe
La délégation directe convient aux tâches locales, répétables et faciles à vérifier. Elle peut inclure une correction de libellé, l’ajout d’un test manquant bien identifié, une adaptation de format, une petite refactorisation déjà décidée ou une mise à jour documentaire liée à un changement précis.
La sortie attendue ne doit pas être seulement un patch. Elle doit inclure les fichiers modifiés, les commandes lancées, les tests qui passent ou échouent, et les hypothèses restantes. Cette logique rejoint le besoin de traçabilité déjà traité dans le journal des interventions IA dans un dépôt, mais elle intervient plus tôt : au moment de décider si le ticket peut être confié.
Branche 2 : analyse sans modification
Certains tickets sont de bons candidats pour l’IA, mais pas pour l’écriture immédiate. Ils demandent d’abord une lecture du code, une cartographie des dépendances, une liste de risques ou un plan de découpage. C’est le cas lorsqu’un bug traverse plusieurs couches, lorsqu’une règle métier est implicite ou lorsqu’un composant ancien n’a pas de propriétaire clair.
Dans cette branche, l’agent ne doit pas produire de diff. Son livrable est une note exploitable : zones inspectées, hypothèses, pistes, tests à créer, points qui nécessitent une décision. L’équipe peut ensuite transformer cette analyse en tickets plus petits, dont certains deviendront délégables.
Branche 3 : binôme humain-agent
Le binôme est adapté aux tickets où l’agent peut accélérer une partie du travail, mais où la décision centrale reste humaine. Une correction de sécurité, une migration partielle, une modification de permission ou une évolution d’API publique entrent souvent dans cette zone.
L’humain garde la main sur le choix de conception, puis l’agent exécute une tranche bornée. Cette approche évite de transformer chaque incertitude en blocage, tout en empêchant l’agent de décider seul sur des conséquences produit ou sécurité. Pour les moments où l’agent doit s’arrêter pendant l’exécution, le prolongement naturel est le protocole d’escalade humaine dans un workflow de développement.
Branche 4 : refus temporaire
Un refus n’est pas un échec d’automatisation. C’est parfois le meilleur choix technique. Un ticket doit être refusé temporairement s’il dépend d’un accès à des données sensibles, d’une décision produit non écrite, d’un comportement non testé ou d’un environnement que l’équipe ne sait pas reproduire.
Le bon réflexe consiste à convertir le refus en action préparatoire : écrire un test de caractérisation, isoler un module, créer des données factices, ajouter une documentation courte ou préparer un environnement contrôlé. Quand ces prérequis existent, le ticket peut revenir dans l’arbre de décision.
Chronologie d’adoption sur deux semaines
- Jour 1 : choisir dix tickets récents et les classer manuellement selon les quatre branches : délégation directe, analyse seule, binôme, refus temporaire.
- Jours 2 à 4 : exécuter uniquement les tickets de délégation directe avec un format de sortie imposé.
- Jour 5 : comparer les PR acceptées, les reprises humaines et les cas où le ticket avait été mal classé.
- Semaine 2 : ajouter les tickets d’analyse sans modification, puis transformer les meilleures analyses en petites tâches vérifiables.
- Fin de semaine 2 : ajuster l’arbre avec les signaux réellement observés dans le dépôt.
Les signaux qui imposent de ralentir
Un ticket ne doit pas continuer dans la voie de la délégation directe si l’agent commence par élargir fortement le périmètre, modifier des fichiers non annoncés, contourner des tests instables ou proposer une refactorisation non demandée. Ces signaux ne prouvent pas que l’agent est inutile. Ils indiquent que la classification initiale était trop optimiste.
Il faut aussi ralentir lorsqu’un ticket contient des formulations comme « nettoyer », « améliorer », « moderniser », « sécuriser » ou « optimiser » sans critère précis. Ces verbes peuvent cacher une vraie tâche, mais ils ne constituent pas seuls un contrat d’exécution.
Le format minimal à ajouter au ticket
Pour rendre l’arbre exploitable, l’équipe peut ajouter un court bloc avant délégation. Il tient en quelques lignes et évite beaucoup d’ambiguïtés.
- Mode : délégation directe, analyse seule, binôme ou refus temporaire.
- Périmètre : fichiers, modules ou commandes concernés.
- Limite : ce que l’agent ne doit pas modifier.
- Validation : tests, revue, capture, scénario manuel ou contrôle attendu.
- Sortie : diff, note d’analyse, plan de découpage ou question d’escalade.
Le critère de réussite
Un arbre de décision n’a pas réussi parce qu’il envoie davantage de tickets vers l’IA. Il réussit lorsque les tickets délégués produisent des changements plus faciles à relire, avec moins de surprises de périmètre et moins de reprises dues à une intention mal comprise.
La bonne mesure est donc qualitative avant d’être volumétrique : combien de tickets ont été correctement orientés dès le départ ? Si l’équipe sait répondre à cette question, elle ne pilote plus l’agent au ressenti. Elle construit progressivement une capacité de délégation explicite, révisable et adaptée à son propre dépôt.
quels critères utilisez-vous déjà pour décider si un ticket peut être confié à un agent IA ?
Publié dans la discussion