L'agent en CI : le ticket qui se code seul

Le dispositif

Dans le projet étudié, un job CI dédié fait tourner un agent côté serveur : on pose le label claude::todo sur un ticket bien formé → le job clone le repo, charge le manifeste et les skills, code le ticket et ouvre une MR — qui entre dans le circuit de revue normal, pipeline de qualité complet inclus.

Le point conceptuel : l'agent en CI n'est PAS un raccourci du process — c'est un contributeur de plus qui suit exactement le même process que les humains : branche, conventional commits, MR, CI verte, revue. Rien de spécial ne lui est accordé ; tout ce qui bloque un humain le bloque.

Ce qui rend ça raisonnable (et ce qui le rendrait dangereux)

Les conditions de sécurité, dans l'ordre d'importance :

1. le périmètre : des tickets bien formés et bornés (un bug reproduit, une tâche mécanique, un comportement spécifié avec critères). Pas de « refondre le module auth » — le tri de ce qui est délégable est une compétence d'équipe à part entière ;
2. la CI complète en aval : la MR de l'agent passe mypy strict, ruff, import-linter, tests testcontainers, Sonar gate — les leçons précédentes travaillent toutes ici ;
3. la revue humaine reste obligatoire : l'agent produit, l'humain décide. La MR d'agent se lit d'ailleurs plus vite : le style est constant, les conventions respectées (il a relu le manifeste, lui) ;
4. des droits minimaux : le job pousse une branche et ouvre une MR — jamais de merge, jamais d'accès prod.

L'économie réelle (sans le marketing)

Ce que l'équipe y gagne : les queues de backlog mécaniques se vident (le bug reproduit-mais-jamais-priorisé, le refactor systématique, la couverture manquante) — le travail important-mais-pas-urgent que les sprints écrasent. Ce que ça ne remplace pas : la conception, l'arbitrage, tout ce qui demande de comprendre POURQUOI avant de coder. La formule honnête : l'agent en CI transforme du backlog en revues — le goulot se déplace vers la relecture et la qualité des tickets, et c'est un excellent problème à avoir.