Comment fiabiliser un agent IA : plan pas à pas, de la mesure au travail autonome

Pourquoi un agent n'est pas fiable même si le modèle est puissant

La fiabilité d'un agent est une propriété de l'ensemble du système, non du seul modèle. Une tâche longue se compose de dizaines d'étapes, et les erreurs s'accumulent : avec 95 % d'étapes correctes, environ 60 % des exécutions franchissent une chaîne de dix étapes sans la moindre erreur (0.95^10 ≈ 0.60), et moins de 10 % en franchissent cinquante. Vous ne pouvez pas augmenter la précision du modèle, mais vous pouvez attraper l'erreur à l'endroit même où elle survient et la rendre peu coûteuse. C'est ce que fait le harnais : instructions, outils, environnement, état et retour d'information autour du modèle.

Voici un plan qui mène d'un travail « au ressenti » à une fiabilité mesurable, puis au travail autonome. Les étapes sont classées par ordre de rendement : chacune s'appuie sur la précédente.

Étape 1. Arrêtez d'évaluer au ressenti

Un ingénieur est convaincu qu'un nouveau prompt a tout changé, un autre ne voit aucune différence, et personne n'a rien mesuré. Commencez par un journal des échecs : chaque fois que l'agent se bloque, casse quelque chose ou annonce une fonctionnalité défectueuse comme terminée, notez une ligne.

| date  | tâche            | ce qui s'est passé             | sous-système   |
|-------|------------------|--------------------------------|----------------|
| 10.10 | remises panier   | « terminé », e2e non lancé     | retour         |
| 10.10 | webhook paiement | impossible de démarrer la base | environnement  |
| 11.10 | refactoring API  | solution rejetée reproposée    | état           |

La colonne « sous-système » est essentielle. Au bout d'une semaine, on voit où se trouve le goulot d'étranglement, et l'on répare celui-là plutôt que tout à la fois. Mesurer la fiabilité au nombre de réussites est une erreur : c'est le journal des pannes qui montre où l'agent échoue.

Étape 2. Introduisez deux indicateurs : MTBF et MTTR

La fiabilité se résume à deux chiffres. Le MTBF (temps moyen entre pannes) d'un agent désigne le nombre d'étapes qu'il enchaîne avant de se bloquer. Le MTTR (temps moyen de rétablissement) est le temps nécessaire pour revenir à un état de travail après une panne. La disponibilité augmente lorsque le premier chiffre croît ou que le second diminue.

Courir après un agent qui ne se trompe jamais est une course sans fin. Réduire le MTTR se fait généralement en une journée. Commencez donc par le second chiffre.

Étape 3. Rendez les erreurs peu coûteuses

L'autonomie n'est acceptable ni lorsque l'agent a cessé de se tromper, ni lorsque le coût d'une erreur est tombé presque à zéro. Il faut pour cela trois choses :

• De petits commits propres — chaque modification peut être annulée par une seule commande.
• L'isolation — l'agent travaille dans une branche ou une copie de travail séparée, par exemple via git worktree, et dans un bac à sable sans accès à la production.
• Un script de réinitialisation de l'environnement — la base, les dépendances et les services reviennent à leur état initial en une commande.

git worktree add ../shop-agent -b agent/discount
cd ../shop-agent
make reset   # recréer la base, appliquer les migrations, charger les fixtures

Chronométrez le temps nécessaire pour un retour complet à un état de travail. C'est votre MTTR. Limitez également le rayon d'action : un plafond sur la taille du diff d'une tâche et une interdiction de modifier des fichiers hors de son périmètre.

Étape 4. Refermez la boucle de retour

Sans vérifications, l'agent est son seul juge, et il considère sincèrement le travail comme accompli. Donnez-lui des commandes pour se contrôler lui-même, et rendez-les obligatoires.

• Fail-fast : une vérification échoue dès la première erreur, avec un message clair, plutôt que d'afficher cent lignes de bruit.
• Des vérifications rapides après chaque modification : linter et vérification de types via un hook de l'agent.
• La redondance : une seconde vérification indépendante de la même propriété — un scénario E2E par-dessus les tests unitaires. Des tests unitaires verts ne prouvent pas que la fonctionnalité marche pour l'utilisateur.

Formulez le critère « terminé » comme une condition vérifiable : « le scénario E2E de commande avec code promo passe », et non « remise implémentée ».

Étape 5. Déplacez la mémoire dans des fichiers

L'agent ne se souvient pas de la session précédente. Tout ce qui est nécessaire pour reprendre le travail doit vivre dans le dépôt : l'objectif, ce qui a été fait et comment c'est vérifié, les décisions avec leur justification, les impasses, la prochaine étape. Signe d'une bonne mémoire : une nouvelle session qui ne reçoit que le dépôt et le mot « continue » se met immédiatement à un travail utile.

Un long historique de conversation condensé donne une impression de continuité, mais il perd l'essentiel : les raisons des décisions rejetées. Une réinitialisation délibérée de la session, accompagnée d'un état écrit complet, coûte généralement moins cher.

Étape 6. Une tâche à la fois

Loi de Little : le nombre de tâches en cours est égal au débit d'arrivée multiplié par le temps que passe une tâche dans le système. À débit constant, des tâches parallèles n'accélèrent rien ; elles allongent seulement chacune d'elles. Pour un agent, c'est encore plus strict : trois fonctionnalités, ce sont trois modèles de domaine dans la même fenêtre de contexte.

• Maintenez WIP=1 : une fonctionnalité jusqu'à obtenir un résultat vérifié.
• Découpez les tâches à la bonne taille : une capacité utilisateur vérifiable, 1 à 3 fichiers, une vérification qui dure moins d'une minute.
• Créez un BACKLOG.md — une soupape pour le « tant qu'on y est ». Si l'agent remarque un défaut voisin, il ajoute une ligne au backlog au lieu de le modifier de sa propre initiative.

Étape 7. Séparez l'exécutant et le vérificateur

L'auto-évaluation de l'agent est un frein faible : la même session qui a écrit le code tend à le considérer comme correct. Confiez l'évaluation du résultat à un sous-agent ou à une session distincte, qui ne reçoit que l'exigence, le diff et les résultats des vérifications, sans les raisonnements de l'exécutant. Le verdict du vérificateur repose sur des contrôles automatiques, non sur un « ça a l'air correct ».

Étape 8. Laissez l'agent tourner dans une boucle autonome

Le harnais rend une exécution fiable ; la boucle rend une série d'exécutions autonome. Une boucle posée sur un harnais défaillant ne fait que multiplier les erreurs plus vite : cette étape vient donc en dernier. La boucle la plus simple tient en trois lignes :

Objectif :   le scénario E2E de paiement avec code promo passe
Vérification : make lint && make test && make e2e
Arrêt :      objectif atteint OU 15 tentatives OU 2 heures → appeler un humain

Choisissez le type de boucle en fonction de la tâche. Si le travail a une ligne d'arrivée, il faut une boucle orientée objectif : une mémoire de la progression, un vérificateur indépendant et un budget d'étapes. S'il n'y a pas de fin (contrôle CI du matin, tri des nouvelles erreurs), une boucle planifiée convient. Erreur fréquente : planifier une tâche qui a une fin ; chaque exécution la reprend alors à zéro.

Règles d'une autonomie sûre

• La condition d'arrêt doit être uniquement vérifiable par machine, avec une limite de tentatives et de budget.
• Escalade : listez à l'avance ce qui n'est pas confié à la boucle (migrations de production, argent, suppression de données).
• Si une tâche piétine et que la progression ne se confirme pas, c'est un signal pour la confier à un humain, non pour continuer à tourner en rond.
• Lisez les diffs. Le rythme de la boucle ne doit pas dépasser votre rythme de lecture, sans quoi vous ne comprenez plus votre propre base de code.

Erreurs fréquentes sur ce chemin

Commencer par réécrire les instructions

La réponse la plus répandue à un échec de l'agent consiste à ajouter une règle dans AGENTS.md. Quelques mois plus tard, le fichier compte des centaines de lignes, et les règles importantes s'y perdent. Si le journal des échecs montre que l'agent n'a pas lancé les vérifications, c'est le retour d'information qu'il faut corriger : une commande de vérification et un hook, pas un paragraphe de plus.

Tout corriger d'un coup

On a envie d'améliorer les cinq sous-systèmes du harnais en même temps. Mais alors on ne sait plus ce qui a réellement aidé. Notez chaque sous-système de 1 à 5, consacrez une demi-heure au plus faible et exécutez le même lot de cinq tâches types avant et après. La différence dans le journal des échecs montrera s'il y a eu un effet.

Confondre « les tests sont verts » et « la fonctionnalité marche »

L'agent peut écrire un test qui vérifie sa propre implémentation plutôt que l'exigence. Un tel test est toujours vert. La protection consiste en une vérification au niveau de l'utilisateur (un scénario E2E), écrite avant l'implémentation ou par un vérificateur indépendant, et en une règle interdisant à l'agent de modifier un test pour le faire passer.

Désactiver les vérifications pour gagner du temps

Les vérifications lentes incitent à les sauter « cette fois-ci ». Mieux vaut les séparer : linter et vérification de types rapides après chaque modification, suite de tests complète et E2E avant d'écrire « terminé ». La boucle de retour reste ainsi courte et ne gêne pas le travail.

Faire de l'ablation la première étape

On peut désactiver les sous-systèmes du harnais un par un et observer la baisse de qualité. C'est une vérification utile, mais coûteuse, et pas la première : c'est d'abord le journal des échecs qui désigne le goulot d'étranglement, l'ablation ne fait que confirmer l'hypothèse. Une baisse nulle lorsqu'on retire un composant ne prouve pas qu'il est inutile : l'ensemble de tâches choisi ne l'a peut-être tout simplement pas sollicité.

L'échelle de maturité

Synthèse

Pour fiabiliser un agent IA : mesurer, repérer le sous-système faible grâce au journal des échecs, rendre les erreurs peu coûteuses, refermer la boucle de retour, déplacer la mémoire dans des fichiers, garder une tâche à la fois et séparer l'exécutant du vérificateur. Ce n'est qu'alors qu'une boucle autonome, dotée d'une condition d'arrêt vérifiable par machine, devient sûre. Chaque étape de ce plan est traitée en pratique dans le cours sur le harness engineering.