Une bonne boucle n’est pas une IA livrée à elle-même

Le mot autonomie donne parfois une fausse impression. On imagine une IA qui reçoit une mission, disparaît dans le terminal et revient avec un produit terminé. En pratique, une boucle autonome ressemble moins à un pilote automatique qu’à un système de contrôle.

Elle observe un état, effectue une action, mesure l’écart avec l’objectif, puis décide si elle doit corriger ou s’arrêter. Si l’objectif est vague, la mesure est mauvaise. Si les limites n’existent pas, la boucle peut continuer bien après le moment où elle aurait dû s’arrêter.

Le premier garde-fou : une condition de réussite

« Améliore le site » n’est pas une condition de réussite. Il n’y a pas de point précis où l’agent peut répondre : c’est terminé.

Une condition utile ressemble davantage à ceci :

Objectif :
- le parcours de connexion fonctionne sur mobile et desktop ;
- les tests d’authentification passent ;
- le lint retourne 0 ;
- aucun fichier en dehors de src/auth n’est modifié.

La dernière ligne est aussi importante que les autres. Une boucle peut atteindre un résultat technique en modifiant trop de choses. Le périmètre fait partie du résultat.

Le deuxième garde-fou : une validation indépendante

Il faut distinguer celui qui produit le changement de celui qui vérifie qu’il est acceptable. Claude peut écrire une correction puis lancer un test. Mais si le seul critère est « le code a l’air correct », la boucle n’a pas de mesure fiable.

Les validations possibles sont nombreuses :

• un test unitaire ou d’intégration ;
• un build qui retourne un code de sortie nul ;
• un lint ou un type-check ;
• un parcours Playwright dans le navigateur ;
• une comparaison avec une capture d’écran de référence ;
• une revue humaine pour les décisions de produit, de sécurité ou de contenu.

La preuve doit correspondre à la promesse. Un test backend ne prouve pas que l’interface est lisible. Une capture d’écran ne prouve pas que les permissions Firestore sont correctes.

Le troisième garde-fou : une mémoire visible

Une boucle qui travaille plusieurs tours a besoin d’un état persistant. Pas forcément d’une base de données : un fichier PROGRESS.md peut suffire.

# PROGRESS.md

## Objectif
Tous les tests du formulaire de contact passent.

## Dernier cycle
- Cause identifiée : validation absente sur le champ email.
- Fichier modifié : src/contact/validate.ts
- Vérification : npm test -- contact → OK

## Prochaine étape
Relancer le parcours navigateur sur mobile.

## Décisions humaines en attente
Aucune.

Cette mémoire évite de demander à l’historique de conversation de jouer le rôle d’un journal de projet. Elle permet aussi à un autre agent ou à une nouvelle session de reprendre le travail sans inventer ce qui s’est passé.

Le quatrième garde-fou : des limites explicites

Une boucle doit avoir une sortie normale et une sortie de secours :

• Limite de tours : arrêter après 10 ou 15 cycles.
• Limite de temps : ne pas laisser une tâche consommer indéfiniment.
• Limite de fichiers : interdire les réécritures hors du périmètre.
• Limite de coût : surveiller les tokens, les appels API et les outils externes.
• Limite de permissions : demander une validation pour le déploiement, la suppression ou les données sensibles.

Ces limites ne disent pas que l’agent va échouer. Elles disent que l’échec doit rester récupérable.

Les cinq façons dont une boucle peut mal tourner

1. Elle répète la même erreur

Le test échoue, Claude modifie un fichier, le même test échoue, puis une autre modification est tentée sans nouvelle hypothèse. La boucle avance en apparence, mais elle ne progresse pas.

2. Elle optimise le mauvais indicateur

Si l’objectif est « zéro erreur dans les tests », l’agent peut être tenté de modifier le test ou de contourner le comportement qui le faisait échouer. La contrainte « les tests existants ne doivent pas être affaiblis » devient alors indispensable.

3. Elle élargit silencieusement le périmètre

Une correction locale devient un refactoring complet. Le résultat semble plus propre, mais la surface de régression augmente. Pour une boucle, le changement minimal est souvent préférable au changement élégant.

4. Elle confond absence d’erreur et réussite

Une commande peut retourner 0 alors que la fonctionnalité n’est pas réellement utilisable. C’est pour cela que les validations techniques et visuelles doivent se compléter.

5. Elle dépasse une décision humaine

Un agent peut choisir un texte, un tarif, une règle métier ou une permission par défaut. Ce sont des décisions, pas des erreurs à corriger automatiquement. La boucle doit savoir les signaler et s’arrêter.

Le contrat de boucle que j’utiliserais

Avant de lancer une tâche autonome, j’écrirais quelque chose comme ceci :

Objectif :
La fonctionnalité X répond à tous les critères d’acceptation.

Contexte à lire :
README.md, CLAUDE.md, docs/feature-x.md et les tests existants.

Actions autorisées :
Modifier uniquement src/feature-x et ses tests.

Validation obligatoire :
npm test -- feature-x
npm run lint
Un parcours navigateur sur les trois états principaux.

En cas d’échec :
Lire la sortie réelle, formuler une cause, modifier le minimum,
puis relancer uniquement les validations concernées.

Mémoire :
Mettre à jour PROGRESS.md après chaque cycle.

Arrêt :
Succès, 12 cycles, ou décision humaine nécessaire.

Ce texte est court, mais il contient les éléments qui manquent le plus souvent dans un prompt : la preuve attendue, le périmètre, la mémoire et l’arrêt.

L’autonomie comme responsabilité d’architecture

Le loop engineering ne consiste pas à rendre l’IA plus libre à tout prix. Il consiste à choisir exactement où elle peut rebondir seule et où elle doit rendre la main.

Pour une correction de lint, une boucle rapide est raisonnable. Pour une migration de base de données, un paiement ou une permission utilisateur, il faut davantage de checkpoints, des sauvegardes et une intervention humaine explicite.

C’est la différence entre « laisser Claude travailler » et construire un système qui sait ce que travailler correctement veut dire.

Les principes de vérification et de limites décrits ici correspondent notamment aux mécanismes de goals et de hooks de Claude Code. Les commandes changent avec les versions ; le contrat de boucle, lui, reste valable.