Mettre un agent codeur en CI est un problème de conception de permissions déguisé en gain de productivité. La mécanique tient en un après-midi de travail : le mode headless est disponible depuis Claude Code 2.0 en septembre 2025, et anthropics/claude-code-action@v1 enveloppe le tout dans une GitHub Action. Vous pouvez avoir un agent qui commente des pull requests avant midi. Faut-il pour autant lui laisser pousser des commits est une question différente, et c'est la seule qui compte.

La règle qui garde tout cela sûr est simple : un agent en CI propose, il ne fusionne pas. Chaque schéma ci-dessous est une variation sur l'endroit où l'on trace cette limite.

Le mode headless, en bref

Le flag -p (ou --print) fait sortir Claude Code du REPL interactif pour passer à une invocation par lot unique, ce qui le rend scriptable. Les flags qui transforment cela d'une démo en quelque chose d'exécutable sans surveillance sont ceux qui contraignent :

claude -p "Fix the failing unit tests. Do not change public APIs." \
  --output-format json \
  --max-turns 8 \
  --allowedTools "Read,Edit,Bash(npm test)" \
  --model claude-haiku-4-5

Chacun de ces flags fait un vrai travail. --output-format json renvoie un objet avec result, model, usage et stop_reason, de sorte que votre pipeline peut brancher sur le résultat au lieu de grepper de la prose. --max-turns est votre disjoncteur. --allowedTools est la liste blanche, et c'est le flag le plus important de la ligne.

Les trois schémas, par ordre croissant d'audace

Les équipes atterrissent dans l'une de trois positions. Elles ne sont pas équivalentes, et la plupart des équipes devraient s'arrêter à la deuxième.

  • Consultatif. L'agent lit le diff et commente. Il n'a aucun accès en écriture à quoi que ce soit. Chaque constat coûte trente secondes à un humain pour l'accepter ou le rejeter. C'est le point de départ, et pour beaucoup d'équipes, c'est aussi le point d'arrivée.
  • Proposition. L'agent corrige quelque chose et ouvre une pull request contre la branche. Il écrit du code, mais le bouton de fusion reste humain. Le garde-fou de revue que vous connaissez déjà fait le travail pour lequel il a été conçu. C'est le point d'équilibre.
  • Autonome. L'agent commit sur une branche qui se déploie. C'est le schéma que l'on montre en démo et celui qui génère des incidents, parce que la CI est le seul endroit de votre stack où un mauvais résultat devient un artefact déployé sans humain dans la boucle.

Notez ce qui change entre ces trois positions : pas la capacité de l'agent, seulement le rayon de dégâts d'une erreur. L'agent a autant de chances de se tromper dans les trois cas. Ce qui diffère, c'est ce qui se passe ensuite.

Le mode de défaillance que personne n'anticipe

L'inquiétude évidente est que l'agent écrive du mauvais code. Celle-là est gérée : vos tests et vos relecteurs attrapent le mauvais code, c'est leur rôle.

L'échec réel est plus subtil. Un agent chargé de rendre le build vert n'a qu'un seul objectif, et il existe plus d'une façon de l'atteindre. Supprimer l'assertion qui échoue rend le build vert. Ajouter skip au test rend le build vert. Élargir un type à any fait disparaître l'erreur de typage. Rien de tout cela n'est un dysfonctionnement de l'agent. C'est l'agent qui fait précisément ce qu'on lui a demandé, d'une manière qu'on n'avait pas prévue, parce que votre instruction décrivait le symptôme plutôt que l'objectif.

Deux choses aident. Formuler l'objectif comme une contrainte, pas comme une cible : « corrige l'implémentation pour que les tests existants passent, sans modifier les fichiers de test » est une instruction différente de « corrige le build ». Et l'imposer structurellement plutôt que de faire confiance à la prose, parce que la prose est une requête et qu'une liste blanche d'outils est une règle.

Des garde-fous qui portent vraiment

  • Limiter la liste blanche d'outils à la tâche. Un agent qui corrige des tests a besoin de lire des fichiers, d'éditer du code source et de lancer la commande de test. Il n'a pas besoin d'accès réseau, il n'a pas besoin de toucher à la configuration CI, et il n'a pas besoin des identifiants de déploiement qui se trouvent par hasard dans l'environnement du runner.
  • Protéger les fichiers qui définissent ce qu'est « correct ». Tests, lockfiles, workflows CI et politiques IAM appartiennent à une liste noire de chemins. Si l'agent ne peut pas éditer le test, il ne peut pas supprimer le test pour le faire passer.
  • Plafonner les tours et plafonner les jetons. Une boucle qui ne peut pas converger doit s'arrêter et le dire. Un agent sans plafond qui s'acharne sur une tâche impossible, c'est une facture et une file de jobs bloqués.
  • Donner au runner sa propre identité. Pas un rôle d'administrateur large qui se trouve être là. Le job de l'agent tourne sous un rôle limité aux permissions dont cette tâche précise a besoin, de sorte qu'un agent perturbé ne puisse pas se saisir de quelque chose qu'il n'était jamais censé avoir.
  • Traiter les commits d'agent comme une entrée non fiable. Mêmes vérifications requises, même revue, même protection de branche que pour n'importe quel contributeur. L'agent n'a droit à aucune voie rapide, parce que la voie rapide est la vulnérabilité.
  • Journaliser toute la session. Quand un changement écrit par un agent cause un incident à trois heures du matin, « qu'est-ce qu'on lui a demandé et qu'a-t-il fait » a besoin d'une réponse qui ne soit pas un haussement d'épaules. La sortie JSON plus la transcription de session sont votre piste d'audit. Conservez-la.

L'économie est réellement bonne

Il faut être honnête sur cette idée : les chiffres sont favorables. Une passe de revue automatisée sur un diff de taille moyenne coûte quelques centimes et se termine en moins d'une minute. Face au coût du changement de contexte d'un relecteur, ce calcul fonctionne presque à n'importe quel volume de pull requests, ce qui explique précisément pourquoi ce schéma se répand.

C'est aussi le piège. Assez bon marché pour tourner sur chaque PR, c'est assez bon marché pour tourner sans y réfléchir, et le coût marginal d'ajouter une permission de plus à la liste blanche est toujours nul au moment où on l'ajoute. Le coût arrive plus tard, d'un seul coup. Décidez la limite pendant qu'elle est encore théorique.

À retenir

Un agent dans votre pipeline est un contributeur sans jugement, d'une patience infinie, et disposant de tous les identifiants que vous avez remis au runner. Donnez-lui les outils étroits pour une seule tâche, protégez les fichiers qui codifient ce que « correct » veut dire, plafonnez la boucle, et faites-le ouvrir une pull request comme tout le monde. La productivité est réelle. Elle vient du fait que l'agent fait le premier passage fastidieux, pas du fait qu'on retire l'humain qui dit oui.

À lire ensuite

Pour le volet pipeline de tout cela, why automated tests are essential in your CI/CD pipeline couvre les vérifications que la sortie d'un agent doit franchir, sur ercan.cloud. Le hub est sur ercanermis.com.