Agent IA autonome : comment le laisser travailler pendant des heures sans produire de déchets

Qu'est-ce qu'un agent IA autonome et en quoi il diffère d'une simple requête

Le travail habituel avec un agent est pas à pas : vous rédigez un prompt, l'agent exécute une étape, vous regardez le résultat et décidez de la suite. Un agent IA autonome fonctionne en boucle : vous décrivez une fois à quoi ressemble l'état final, puis l'agent répète seul le cycle « faire — vérifier — corriger » jusqu'à ce que l'objectif soit atteint ou que le budget soit épuisé. Une fois lancé, vous pouvez vous éloigner.

C'est simple en théorie, mais la première expérience typique ressemble à ceci : l'agent reçoit la tâche le matin, et le soir on découvre qu'il a passé plusieurs heures à réparer un bug déjà corrigé, parce qu'il a oublié ce qu'il avait fait une heure plus tôt. Personne ne lui a dit quand s'arrêter et quand appeler un humain. Voici comment concevoir une boucle qui évite cela.

Précision importante : la boucle ne remplace pas le harnais. Le harnais rend une seule exécution fiable, la boucle rend les exécutions continues. Une boucle installée sur un mauvais harnais produit simplement plus vite des déchets.

La tâche se prête-t-elle à un agent autonome ?

La première question est de savoir si le travail a une ligne d'arrivée qu'une machine peut vérifier. « Tous les tests du dossier tests/payments passent », « toutes les fonctionnalités de la liste sont au statut passing », « la métrique a augmenté par rapport à la référence » : cela convient. « Rends le code meilleur » ou « continue d'améliorer les paiements » : cela ne convient pas. Un tel objectif n'a pas de fin, et la boucle tournera jusqu'à consommer tout le budget.

Il est utile de distinguer quatre types de boucles :

• Pas à pas — vous saisissez chaque prompt ; c'est le travail interactif habituel.
• Par objectif — vous définissez un but, et la vérification indépendante ou le budget arrête le cycle. C'est l'agent autonome qui travaille pendant des heures.
• Par temps — lancement planifié (par exemple, l'analyse matinale des builds CI en échec), arrêt manuel.
• Par événement — déclencheur externe (nouvelle issue, déploiement en échec) ; le cycle s'arrête à la fin du traitement de l'événement ou à la limite de relances.

Erreur fréquente : confondre une boucle temporelle avec une boucle par objectif, par exemple « toutes les 10 minutes, continue les paiements ». Une boucle planifiée repart à chaque fois de zéro et ne sait pas ce qui a déjà été fait. Si la tâche a une fin, il faut une boucle par objectif avec une mémoire de la progression.

Étape 1. Bac à sable : là où l'agent peut casser des choses

Un agent sans surveillance finira tôt ou tard par faire quelque chose de malvenu : supprimer un fichier, réécrire une migration, lancer une commande lourde. La question n'est donc pas « comment l'empêcher de se tromper », mais « comment faire en sorte qu'une erreur ne coûte rien ».

• Copie de travail séparée. git worktree donne à l'agent son propre dossier et sa propre branche au-dessus du même dépôt. La branche principale reste intacte, plusieurs agents ne se gênent pas, et un essai raté se supprime d'une seule commande.
• Conteneur ou machine virtuelle. Si l'agent a besoin d'un accès complet aux commandes, lancez-le dans un conteneur sans accès au répertoire personnel, aux clés et aux bases de production.
• Données de test. Base locale, bacs à sable des systèmes de paiement, clés fictives. Aucun secret de production dans l'environnement de l'agent.

# une branche et un dossier dédiés à l'exécution autonome
git worktree add ../shop-agent -b agent/f03-refunds

# après l'exécution : consulter le résultat ou tout jeter
git -C ../shop-agent log --oneline main..
git worktree remove ../shop-agent

Étape 2. Droits : le minimum suffisant pour la tâche

Plus l'agent travaille seul, plus ses droits doivent être étroits. Dans Claude Code, les autorisations se configurent dans settings.json (listes allow et deny pour les outils et les commandes) : autorisez explicitement ce dont la tâche a besoin — lancer les tests, le linter, modifier les fichiers de la copie de travail — et interdisez le dangereux : push vers la branche principale, accès aux secrets, commandes réseau si elles ne sont pas nécessaires.

Un mode où l'agent exécute tout sans confirmation n'est acceptable qu'à l'intérieur d'un bac à sable isolé, où le pire résultat est un conteneur jeté. Sur une machine de travail qui a accès à vos clés et à vos dépôts, ce mode est interdit.

Les interdits qui ne doivent jamais être franchis doivent être appuyés par un mécanisme, et non par un texte. La phrase « ne touche pas à migrations/ » dans les instructions est un vœu pieux ; un hook qui bloque la modification de ce dossier, ou les droits du système de fichiers, sont une garantie.

Étape 3. Objectif, vérification, arrêt — trois lignes avant le lancement

Une boucle de travail simple repose sur trois éléments, à écrire avant le lancement et non en cours de route :

1. Objectif — à quoi ressemble l'état final.
2. Vérification — une manière vérifiable par machine de savoir que l'objectif est atteint : une commande qui renvoie succès ou échec.
3. Condition d'arrêt — une limite de tentatives, de temps ou d'argent, au-delà de laquelle la boucle s'arrête même si l'objectif n'est pas atteint.

Pratique : conservez cela dans un fichier de méthodologie que seul l'humain modifie. Exemple pour un backend de paiement :

# program.md — méthodologie de l'exécution autonome

## Objectif
Toutes les fonctionnalités de .agent/feature_list.json sont au statut passing.

## Métrique
Nombre de fonctionnalités en passing. Il ne fait que croître. Une régression = retour arrière immédiat.

## Contraintes
- Une seule fonctionnalité en cours à la fois.
- Ne pas modifier migrations/ ni infra/.
- Ne pas toucher aux dépendances sans consigner la modification dans le journal.

## Ordre de travail
1. Prendre la première fonctionnalité qui n'est pas en passing.
2. Implémenter, lancer pytest et le linter.
3. Si c'est vert : commit et ajout dans .agent/progress.md. Si c'est rouge : corriger.

## Arrêt et escalade
- 3 tentatives échouées sur une même fonctionnalité — la marquer blocked et passer à la suivante.
- Si toutes les fonctionnalités restantes sont blocked — s'arrêter et rédiger un rapport.
- Toute tâche touchant à l'argent des clients, aux droits d'accès ou à la suppression de données — ne pas la faire, mais escalader.

Étape 4. Boucle vérifier-corriger avec une mémoire sur disque

La fenêtre de contexte ne survit pas à un long travail : elle se remplit, se compresse, la session redémarre. La progression doit donc vivre dans des fichiers et non dans la « tête » de l'agent : liste des tâches avec leur statut, journal de ce qui a été fait et de ce qui n'a pas fonctionné, historique git.

Un bon modèle est celui du « cliquet qui n'avance que vers l'avant », tel qu'il apparaît dans le projet autoresearch d'Andrej Karpathy, où un agent mène pendant la nuit des centaines d'expériences de ML. Chaque itération : lire la méthodologie, formuler une hypothèse, appliquer une modification, lancer l'expérience avec un budget de temps fixe, comparer à la référence. Si c'est mieux — commit ; si ce n'est pas mieux — retour arrière. Le résultat est consigné dans le journal, puis vient l'hypothèse suivante.

Deux décisions sont à retenir de ce schéma :

• Budget fixe par tentative. Les tentatives deviennent comparables, et une hypothèse ratée ne consomme pas toute la nuit.
• Dans la branche principale, seulement les améliorations. Tout ce qui n'a pas marché est annulé, et non laissé à côté. git log devient un journal de travail vérifié, facile à relire le matin.

Le même schéma répartit les rôles par fichiers : personne ne modifie l'infrastructure et l'évaluation, le code de l'expérience n'est modifié que par l'agent, la méthodologie n'est modifiée que par l'humain. L'agent ne peut pas « améliorer » un résultat en trafiquant la façon dont on le mesure.

Étape 5. Qui décide que c'est terminé : un évaluateur séparé

Quand il n'y a pas d'humain dans la boucle, l'autoévaluation de l'agent devient le seul frein — et ce frein ne fonctionne pas. Un agent qui vient d'écrire du code a tendance à le trouver correct : il voit son raisonnement et « sait » ce qu'il voulait faire.

Règles de séparation entre générateur et évaluateur :

• Ce n'est pas la session qui a fait le travail qui l'évalue. Dans Claude Code, les subagents sont pratiques pour cela : chacun a son propre contexte.
• L'évaluateur reçoit un contexte vierge : l'exigence, le diff et les résultats des exécutions — et rien du raisonnement de l'exécutant.
• Dans la mesure du possible, l'évaluateur est un autre modèle, ou au moins un autre prompt avec un autre rôle.
• Le verdict repose sur une grille, et chaque critère renvoie à une preuve : une ligne de test, la sortie d'une commande, un endroit du diff.

Les vérifications automatiques restent prioritaires. L'évaluateur sert à ce que les tests ne détectent pas : exigence mal comprise, test ajusté au code, modification sortant du cadre de la tâche.

Critères d'arrêt : quand l'agent doit abandonner

Une boucle sans conditions d'arrêt finit par tourner en rond : c'est une question de temps. Ensemble minimal :

Vérifiez la progression sur le fond et non sur le nombre de tentatives : « 40 itérations effectuées » ne veut rien dire, « le nombre de fonctionnalités vertes est passé de 5 à 9 » veut dire quelque chose. Si une tâche patine, c'est une raison de la confier à un humain, et non de relancer la boucle une fois de plus.

Risques de l'agent autonome qui ne se voient pas tout de suite

Les risques évidents — fichiers supprimés, build cassé — sont couverts par le bac à sable et les droits. Les coûts silencieux, qui s'accumulent pendant des semaines, sont plus dangereux :

• Dette de vérification. « Ça a l'air normal » à la place de « confirmé par machine ». Seul remède : des conditions d'arrêt vérifiables par machine, sans exception.
• Perte de compréhension. Vous connaissez de moins en moins votre propre code. Remède : la lecture obligatoire des diffs. La vitesse de la boucle ne doit pas dépasser votre vitesse de lecture.
• Capitulation cognitive. Vous n'avez plus d'avis sur le résultat et acceptez tout. Il est utile de compter honnêtement les cas « je regarderai plus tard » et de ceux que vous n'avez pas regardés.
• Gonflement du contexte. Une longue exécution accumule l'historique, et chaque étape suivante coûte plus cher et réussit moins bien. La compression du contexte et la mémoire externe sont nécessaires dès la première boucle, et non quand tout a déjà dérapé.

Comment lancer une première boucle autonome en une soirée

Ne commencez pas par « l'agent trouvera et fera les tâches tout seul ». L'autonomie se construit par paliers : d'abord une tâche avec un objectif et une condition d'arrêt, puis une automatisation planifiée, puis un exécutant et un vérificateur séparés dans une copie de travail isolée, et seulement ensuite des boucles qui trouvent elles-mêmes le travail et fonctionnent en parallèle.

1. Repérez une tâche que vous faites à la main au moins deux fois par semaine et qui a une fin vérifiable.
2. Notez l'objectif, la vérification et la condition d'arrêt — trois lignes.
3. Créez une copie de travail séparée et réglez les droits : tests et modification de fichiers autorisés, push et secrets interdits.
4. Créez un fichier de progression et demandez à l'agent de le mettre à jour après chaque itération.
5. Séparez les rôles : l'exécutant écrit, le vérificateur, dans un contexte distinct, évalue le diff.
6. Fixez une limite globale et, la première fois, contrôlez le résultat au bout d'une heure, et non le matin.

En résumé

Un agent IA autonome n'est fiable que dans la mesure où son cadre l'est : un bac à sable où une erreur ne coûte rien, des droits minimaux, un objectif vérifiable par machine, une mémoire sur disque, un évaluateur séparé et des conditions d'arrêt strictes avec escalade vers un humain. Sans cela, une exécution longue n'est pas un gain de temps, mais un nettoyage différé. Comment assembler une telle boucle sur un projet complet — depuis program.md jusqu'à l'évaluateur indépendant — est détaillé en pratique dans le cours sur le harness engineering.