Agents autonomes

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

Et 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.

---

Qu’est-ce qui change quand personne ne regarde ?

Les erreurs ne se corrigent plus au fil de l’eau : elles se composent. En session pilotée, c’est vous le mécanisme de correction — 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. Retirez-vous, et une interprétation fausse au premier quart d’heure produit une heure de travail parfaitement cohérent avec l’erreur.

J’aime bien l’image du cap. En session, une erreur c’est une faute de frappe : vous la voyez, vous la corrigez, on continue. En autonomie, c’est un degré d’écart au départ — et vous arrivez à cinquante kilomètres du port, sans que rien n’ait jamais paru anormal en route.

Le calcul économique s’inverse donc complètement. 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 — « La machine » l’a posé pour le prompt et le fichier d’instructions — court maintenant sans témoin.

Tout l’investissement se déplace vers l’amont (la spécification) et vers l’aval (la vérification). Le milieu, la production, c’est justement ce qu’on délègue.

D’où le seul critère d’éligibilité qui vaille : une tâche n’est déléguable en autonomie que si sa réussite se vérifie mécaniquement. La sortie d’un modèle n’a pas besoin d’être digne de confiance, elle a besoin d’être réfutable à 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.

C’est quoi la boucle issue → PR ?

L’unité de travail d’un agent autonome, et elle existe déjà dans votre processus : une issue bien spécifiée en entrée, une pull request en sortie. Rien d’autre.

• L’issue est le prompt. Tout ce que la section dit de la spécification s’applique ici, mais sans le filet de l’itération : objectif observable, contraintes explicites, périmètre fermé en négatif, critères d’acceptation vérifiables. Le test que j’applique avant de lancer : 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 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.

Concrètement, cette consigne vit dans mon modèle d’issue, en toutes lettres :

Si les critères d'acceptation sont ambigus : commente l'issue et
arrête-toi. N'invente pas d'interprétation.

Deux lignes, et elles m’ont épargné plusieurs PR entières à jeter.

Pourquoi un environnement isolé par agent ?

Pour deux raisons totalement indépendantes, et chacune suffirait. Un agent autonome exécute des commandes — installations, scripts, tests, parfois des outils arbitraires. Le laisser travailler dans votre environnement courant est exclu.

• 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. La production déçoit ? On supprime l’environnement, et il ne reste rien.
• 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.

Une précision qui compte : 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 autant que le push --force parfaitement bien intentionné.

Quels garde-fous quand personne ne surveille ?

Des garde-fous mécaniques, jamais des consignes. Sans humain dans la boucle, c’est le système qui doit dire stop, et il y a trois familles de limites à poser.

• 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 que vous le laissez consommer — j’ai la facture pour le prouver.
• Le verdict. La commande qui fait foi (build, tests, lint) est la condition de sortie, jamais 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, pas 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.

Cette dernière distinction, gardez-la : dès que quelque chose compte vraiment, ne le demandez pas, empêchez-le.

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 tout l’objet de l’Étape suivante, sur l’IA dans la CI.