Repérer les modes d’échec classiques · Ingénierie agentique : la formation pratique

Les agents échouent de quelques façons reconnaissables. Voici les huit que je vois le plus, où chacun se manifeste, et les fils-pièges peu coûteux qui les attrapent avant main.

Après assez d’exécutions d’agent, les échecs cessent de surprendre. Les mêmes huit motifs reviennent, peu importe l’outil, le langage ou la base de code.

Une fois que vous pouvez les nommer, vous pouvez les attraper tôt. Mieux encore, vous pouvez poser des fils-pièges pour qu’ils se signalent tout seuls.

Le guide de terrain

Huit modes d’échec classiques, groupés selon l’endroit où vous avez le plus de chances de les repérer.

Quelques notes sur ceux qui m’ont coûté le plus cher :

La vérification truquée est la plus dangereuse, parce que tout paraît vert. C’est pour ça que la leçon 4.1 verrouille les tests avant l’implémentation.
Le « terminé » prématuré se règle en ne croyant jamais l’agent sur parole. Lancez la vérification vous-même, chaque fois.
La dérive de contexte et la boucle sans fin sont des problèmes de contexte, pas d’intelligence. Repartez d’une note de passation (leçon 2.4) au lieu de forcer.

Posez des fils-pièges, pas des rappels

Relire chaque diff à la recherche des huit motifs, c’est épuisant. Certains laissent des traces qu’un script peut trouver : laissez donc un script les trouver. Voici ce que je mettrais dans une vérification avant fusion ou une checklist de pull request.

Fils-pièges pour les branches d'agent
- Fichiers de test modifiés sans mention dans le brief → signaler
- Nouveaux commentaires d'exclusion (lint désactivé, échappatoires
  de types, tests ignorés)                            → échec
- Manifeste de dépendances ou lockfile modifié         → signaler
- Config de CI, de build ou du linter modifiée         → signaler
- Diff plus gros que la taille convenue dans le brief  → signaler
- Nouvelles fonctions au nom très proche d'une existante → signaler

Diagnostiquez l’exécution

🧠 Quel mode d’échec est-ce?

Pointage: 0 / 6

1. L’agent affirme « tous les tests passent ». Vous les lancez : deux échouent.
Il a annoncé un succès sans vraie exécution, ou n’a lancé qu’une partie. Exigez « colle la sortie finale de la vérification » dans votre définition de terminé.
2. La suite est verte, mais un test attend maintenant 0 là où il attendait 42.
La cible a été déplacée pour coller au code. Annulez le changement au test et relancez avec les tests verrouillés.
3. Vingt minutes plus tard, il essaie le même ajustement de config pour la quatrième fois.
Arrêtez-le. Il manque quelque chose dans son contexte. Ajoutez-le, ou découpez la tâche, et repartez à neuf.
4. Un nouvel utilitaire formatDate() apparaît. Le dépôt en a déjà un dans utils.
L’agent n’a pas trouvé l’existant, ou on ne le lui a pas indiqué. Pointez-le dans votre fichier d’instructions.
5. Les échecs de paiement retournent maintenant une liste vide au lieu d’une erreur.
Une erreur a été avalée pour que le flux continue. Demandez ce que l’appelant devrait voir, et ajoutez un test pour le chemin d’échec.
6. Après trois heures, il se met à utiliser la bibliothèque de journalisation que vous aviez bannie dans votre premier message.
L’instruction du début s’est fait enterrer. Mettez les règles durables dans le fichier d’instructions et repartez d’une note de passation.

Voilà qui termine le module sur la vérification. Au module 5, on passe à l’échelle : plusieurs agents à la fois, exécutions sans interface et garde-fous, qui reposent tous sur les vérifications que vous venez de mettre en place.

Avant de continuer

✅ À retenir

0 / 4 complété

Je peux nommer les huit modes d’échec classiques et dire où chacun se manifeste.
Je n’accepte jamais « terminé » sans lancer la vérification moi-même.
J’ai au moins un fil-piège automatisé sur les branches d’agent (tests modifiés, exclusions, dépendances).
Chaque échec attrapé devient une ligne de brief, une règle d’instructions ou une vérification.