Anti-patterns agentiques
Ce qu'il ne faut pas construire. Chaque fiche décrit un choix d'architecture qui se paie en production : les symptômes qui le trahissent, pourquoi il nuit, les incidents publics qu'il a causés et les patterns du catalogue qui y remédient.
Cadrage et choix du niveau
Ai-je choisi le bon niveau d’architecture ?
Construire plus compliqué que nécessaire, ou viser une autonomie que rien ne justifie : les erreurs commises avant la première ligne de code.
- AP01 · Agent là où un workflow suffit — Le chemin est connu d’avance, mais un modèle le redécide à chaque exécution.
- AP02 · Multi-agent par défaut — Plusieurs agents découpés par rôles, là où un agent seul réussissait déjà la tâche.
- AP03 · LLM pour une décision déterministe — Le modèle tranche ce qu’une règle, un parseur ou un linter ferait exactement et presque gratuitement.
- AP06 · Tâche plus longue que l’horizon fiable — Une tâche de plusieurs heures confiée d’un bloc, que l’agent tente de produire d’une traite.
Outils et interface agent-machine
Mes outils sont-ils conçus pour un agent ?
Des outils pensés pour des développeurs, trop nombreux, trop bavards ou trop puissants.
- AP10 · Outil calqué sur l’API — Chaque point d’accès d’une API pour développeurs devient un outil, sans regroupement par tâche.
- AP12 · Trop d’outils chargés d’emblée — Toutes les définitions d’outils sont chargées à chaque tour, y compris celles qui se recoupent.
- AP13 · Sorties d’outils non bornées — Le résultat brut d’un outil entre tel quel dans le contexte, quelle que soit sa taille.
- AP19 · Outil à fonctionnalité excessive — Un outil ouvert (SQL brut, shell, HTTP libre) là où la tâche n’exige que quelques actions bornées.
Instructions
Mes consignes sont-elles lisibles et à jour ?
Des prompts qui grossissent, se contredisent ou compensent un modèle qui n’est plus là.
- AP21 · Instructions obèses — Un fichier d’instructions qui grossit à chaque incident, jusqu’à ce que des règles importantes soient ignorées.
Contexte et mémoire
Que lit l’agent, et que retient-il ?
Un contexte qui gonfle, s’empoisonne ou casse le cache ; une mémoire que n’importe quel contenu peut écrire.
- AP25 · Contexte qui gonfle sans gestion — Tout s’accumule dans la fenêtre, et l’agent exploite de moins en moins bien ce qu’il a sous les yeux.
- AP26 · Empoisonnement du contexte — Une erreur écrite dans le contexte devient un fait, que l’agent relit et renforce à chaque tour.
- AP27 · Consigne éparpillée au fil des tours — La demande arrive par morceaux ; l’agent s’engage dès le premier et ne revient plus en arrière.
- AP30 · Préfixe instable qui casse le cache — Un horodatage ou un JSON réordonné en tête du prompt, et chaque appel repaie tout le contexte au prix fort.
- AP33 · Mémoire en écriture libre — L’agent retient ce qu’il lit, y compris les ordres glissés dans un document, et les relit plus tard comme des faits.
Boucle, arrêt et orchestration
Qui décide de s’arrêter, et qui vérifie ?
Des boucles sans borne, des fins déclarées sans preuve, des erreurs qui passent d’un agent à l’autre.
- AP35 · Boucle sans borne ni budget — Rien dans le code n’arrête l’agent : ni plafond de tours, ni budget, ni délai.
- AP36 · Fin décidée par l’agent seul — L’agent dit « terminé », et personne ne vérifie l’état réel avant de le croire.
- AP37 · Agir sans vérifier l’effet — Une action échoue en silence, et l’agent enchaîne comme si elle avait réussi.
- AP39 · Propagation sans validation — La sortie d’un agent devient l’entrée du suivant sans contrôle, et une erreur locale finit dans le livrable.
- AP40 · Plusieurs agents qui écrivent en parallèle — Plusieurs agents modifient le même livrable en même temps, chacun avec ses propres décisions implicites.
- AP41 · Débat qui converge vers l’erreur — Des agents débattent pour se corriger et finissent alignés sur la réponse la plus assurée, même fausse.
Vérification et évaluation
Comment sais-je que ça marche ?
Pas d’évaluation, un évaluateur complaisant, ou un oracle que l’agent peut modifier.
- AP46 · Pas d’évaluation, seulement des correctifs — Chaque plainte donne lieu à un correctif, et personne ne sait si l’agent progresse ou régresse.
- AP49 · L’agent juge son propre travail — Le même agent produit et note : il trouve presque toujours son travail bon.
- AP50 · Oracle visible et modifiable par l’agent — L’agent voit ou peut réécrire ce qui le note, et finit par optimiser la note plutôt que la tâche.
- AP52 · Fiabilité mesurée sur un seul essai — Réussir un essai prouve que l’agent sait faire, pas qu’il réussira à chaque fois.
Sécurité et droits
Que peut faire une entrée hostile ?
Une règle de sécurité laissée au prompt, des droits trop larges, une production à portée de l’agent.
- AP58 · Garde-fou probabiliste comme unique barrière — Un filtre ou un classifieur d’injection fait office de frontière, sans aucune contrainte d’architecture derrière.
- AP59 · Trifecta létale en autonomie — Un même agent lit du contenu non fiable, touche aux données privées et peut émettre, sans que personne n’approuve.
- AP61 · Le contenu d’un tiers agit avec les droits du mandant — L’agent agit avec les droits de qui le lance, sur un texte écrit par un tiers moins privilégié.
- AP63 · Consigne de sécurité confiée au prompt — La règle « ne touche pas à la production » n’existe que dans le prompt ; rien ne l’impose à l’appel d’outil.
- AP64 · Environnements non séparés — L’agent de développement atteint la production, et les sauvegardes partagent son rayon d’impact.
- AP67 · Chaîne d’approvisionnement d’outils non vérifiée — Serveurs MCP, extensions et skills installés sans vérification ni épinglage, avec toute la confiance de l’agent.
Supervision, exploitation et gouvernance
Qui surveille, qui répond, qui arrête ?
Une validation humaine de façade, un agent opéré à l’aveugle, des régressions que personne ne voit.
- AP72 · Validation humaine de façade — L’humain approuve presque tout, en quelques secondes, sur des demandes qui ne montrent pas ce qui va se passer.
- AP75 · Agent opéré à l’aveugle — En production sans trace par étape : on ne peut ni rejouer une session, ni dire où elle a échoué.
- AP77 · Régressions silencieuses au changement — Le modèle, le prompt ou l’infrastructure change, et seuls les utilisateurs voient la qualité baisser.