Agents autonomes

Jusqu’ici, vous étiez dans la boucle : chaque sortie de l’agent passait sous vos yeux avant d’exister. Un agent autonome travaille pendant que vous faites autre chose. Et cette absence change tout.

Ce n’est pas une différence d’outil, c’est une différence de régime : tout ce que votre présence corrigeait silencieusement doit devenir explicite, mécanique et vérifiable. Ce guide pose les quatre piliers de ce régime : une unité de travail bordée, un environnement isolé, des garde-fous, et un sas de sortie.

---

Ce qui change quand personne ne regarde

En session pilotée, vous êtes le mécanisme de correction d’erreur : une dérive se repère d’un coup d’œil, une ambiguïté se lève en une question, un débordement s’arrête d’un mot. L’agent autonome n’a rien de tout ça. Les erreurs ne se corrigent plus au fil de l’eau, elles se composent. Une interprétation fausse au premier quart d’heure produit une heure de travail parfaitement cohérent. Avec l’erreur.

Le calcul économique s’inverse. En session, l’ambiguïté coûte un aller-retour. En autonomie, elle coûte la totalité du travail construit dessus. La dette qui s’exécute (les Fondamentaux l’ont posé pour le prompt et le CLAUDE.md) s’exécute désormais sans témoin. Tout l’investissement se déplace donc vers l’amont, la spécification, et vers l’aval, la vérification. Le milieu (la production), c’est précisément ce qu’on délègue.

D’où le critère d’éligibilité d’une tâche à l’autonomie : sa réussite doit être vérifiable mécaniquement. La sortie d’un modèle n’a pas besoin d’être digne de confiance, elle a besoin d’être vérifiable à bas coût. En autonomie, ce principe cesse d’être un conseil de relecture et devient un filtre : ce qui ne se vérifie que par votre jugement reste en session, avec vous dans la boucle.

La boucle issue → PR

L’unité de travail naturelle d’un agent autonome existe déjà dans votre processus : le ticket. Une issue bien spécifiée en entrée, une pull request en sortie. Rien d’autre. Ce choix n’est pas cosmétique :

• L’issue est le prompt. Tout ce que la section « Coder avec un agent » dit de la spécification s’applique ici sans le filet de l’itération : objectif observable, contraintes explicites, périmètre fermé en négatif, critères d’acceptation vérifiables. Une issue qu’un développeur humain viendrait clarifier de vive voix n’est pas prête pour un agent.
• La PR est le sas. L’agent ne pousse jamais sur la branche principale. Sa production entre dans le circuit de revue commun (CI, relecture, exigences du projet), exactement comme celle d’un humain. L’autonomie porte sur la production, jamais sur l’intégration.
• La boucle est traçable. Issue liée, branche nommée, PR argumentée : quand quelque chose déraille, vous savez ce que l’agent croyait faire, et pourquoi.

Le tips Craftomancer

Exigez de l’agent qu’il sache s’arrêter. Un agent qui rencontre une ambiguïté réelle et « se débrouille » produit du travail plausible sur une interprétation inventée. La pire des sorties, parce qu’elle ressemble à une réussite. La consigne doit être explicite : si les critères sont ambigus, commente l’issue et stoppe. Un agent qui s’arrête est un agent qui fonctionne.

L’isolation : un environnement par agent

Un agent autonome exécute des commandes : installations, scripts, tests, parfois des outils arbitraires. Le laisser travailler dans votre environnement courant est exclu, pour deux raisons indépendantes :

• L’intégrité du travail. Plusieurs agents (ou un agent et vous) sur la même copie du repo se piétinent : fichiers modifiés sous les pieds, états de build mélangés. Un worktree ou un clone par tâche rend chaque travail reproductible et jetable. Si la production déçoit, on supprime l’environnement. Rien à nettoyer, rien à démêler.
• Le rayon d’explosion. Le moindre privilège s’applique à l’agent comme à tout processus non fiable : système de fichiers borné à l’environnement de travail, réseau restreint à ce que la tâche exige, et surtout aucun secret de production à portée. Un agent qui n’a pas les credentials de prod ne peut ni les fuiter dans un log, ni les committer, ni « réparer » la base en croyant bien faire.

L’isolation n’est pas une précaution contre la malveillance du modèle. C’est une précaution contre son aplomb. Un agent fait ce qui est plausible, et « plausible » inclut le rm sur le mauvais dossier comme le push --force bien intentionné.

Garde-fous et budgets

Sans humain dans la boucle, c’est le système qui doit dire stop. Trois familles de limites, toutes mécaniques :

• Le budget. Tokens, temps, nombre d’itérations : chaque tâche déléguée a un coût maximal au-delà duquel l’agent s’arrête et rapporte. Un agent qui boucle sur un test qui ne passera jamais consommera tout ce qu’on le laisse consommer. La persévérance statistique ne converge pas toujours.
• Le verdict. La commande qui fait foi (build, tests, lint) est la condition de sortie, pas l’auto-évaluation de l’agent. Un modèle optimise la vraisemblance, y compris celle d’un rapport de succès. La preuve, c’est la sortie de la commande, jamais la déclaration.
• Le périmètre. Branches protégées, droits en écriture minimaux, opérations destructives bloquées par l’outillage plutôt qu’interdites par la consigne. Une règle écrite dans le prompt est une probabilité ; une règle appliquée par le système est une garantie.

En pratique

• Ne déléguez en autonomie que des tâches dont la réussite se vérifie mécaniquement. Le reste se traite en session, avec vous dans la boucle.
• Écrivez l’issue comme la spécification complète qu’elle est : critères d’acceptation vérifiables, périmètre fermé en négatif. Et relisez-la en vous demandant ce qu’en ferait un exécutant littéral qui ne peut pas vous poser de question.
• Un environnement isolé et jetable par tâche ; aucun secret de production dans la portée de l’agent.
• Plafonnez tout (tokens, temps, itérations) et faites de l’arrêt-rapport un comportement attendu : un agent qui s’arrête vaut mieux qu’un agent qui s’acharne.
• La PR est le sas : la production d’un agent entre dans le circuit de revue commun, jamais directement sur la branche principale.

Reste à faire tenir ce circuit de revue à la cadence des agents : c’est l’objet du guide suivant, sur l’IA dans la CI.