Introduction
Dans sa vidéo “Your AI Agent Fails 97.5% of Real Work. The Fix Isn’t Coding.”, Nate B Jones défend une idée simple: le principal point de rupture n’est pas le code produit par l’agent, mais le travail qu’on lui assigne. Le “97.5%” est mis en avant dans le titre de la vidéo, sans étude primaire détaillée dans les sources citées ici. Ce chiffre doit donc être lu comme un signal d’alerte, pas comme une mesure universelle.
Ce diagnostic rejoint l’esprit du dépôt GitHub vectara/awesome-agent-failures, présenté comme une collection communautaire d’échecs d’agents et de correctifs testés. Le motif récurrent n’est pas “les modèles sont incapables”, mais “les agents dérapent quand le cadre est flou”: objectifs ambigus, périmètre mal borné, permissions trop larges, validation humaine absente ou tardive.
La question utile pour une équipe devient alors très concrète: comment obtenir des résultats plus prévisibles sans exploser le coût, le délai et le risque sécurité?
Décryptage
Selon Nate B Jones, le “fix” durable n’est ni un prompt plus long ni un patch isolé. C’est un design du travail plus strict. Le format le plus opérationnel est un contrat d’exécution en six blocs:
- objectif testable;
- périmètre autorisé;
- limites de temps et de coût;
- critères d’acceptation;
- niveau d’autonomie;
- points de validation humaine.
D’après le repo Vectara, les échecs reviennent souvent sous les mêmes formes. C’est plutôt une bonne nouvelle: ce qui est répétitif se corrige par des règles stables. Si un agent modifie des fichiers hors sujet, c’est généralement un défaut de scope. Si une action risquée part sans contrôle, c’est un problème de gouvernance, pas une fatalité “magique” du modèle.
Une boucle courte suffit souvent à améliorer vite les résultats:
- créer un ticket agentique avec sortie vérifiable;
- imposer des checkpoints (“plan”, “diff proposé”, “risques”);
- mesurer (succès au premier run, temps humain, reruns);
- ajuster le contrat avant d’ajuster le prompt.
Checklist de brief réutilisable en équipe:
- Objectif: résultat mesurable sur un type de tâche précis.
- In-scope: chemins/fichiers explicitement autorisés.
- Out-of-scope: secrets, infra, migrations, changements non demandés.
- Sortie attendue: tests, logs utiles, justification des choix.
- Stop conditions: plafond de coût, délai max, seuil de confiance minimal.
Pour outiller cette approche, on peut compléter avec ce playbook de cadrage agent, ce guide sur les permissions minimales et les KPI utiles.
Ce que ça change pour les devs
Le changement clé est méthodologique: on remplace le brief vague par un contrat explicite. En pratique:
- standardiser un template de contrat d’exécution pour chaque ticket agentique;
- séparer clairement exécution automatique et décision humaine pour les actions à risque;
- suivre au minimum trois métriques par tâche: succès premier run, temps humain total, coût par ticket;
- démarrer en permissions minimales (idéalement lecture seule), puis ouvrir progressivement;
- tenir une revue hebdo courte: 2 échecs récurrents, 2 règles ajustées, 1 test pour la semaine suivante.
Cette discipline limite deux pièges coûteux: surestimer une démo ponctuelle et sous-estimer le coût caché des reruns.
Conclusion
Le message opérationnel n’est pas “les agents sont mauvais”, mais “les agents sans cadre échouent souvent”. Selon Nate B Jones, le levier principal est l’organisation du travail confié. Et d’après le repo Vectara, les incidents sont suffisamment récurrents pour être traités comme un problème d’ingénierie, pas comme une anomalie isolée.
Recommandation pratique: ne pas industrialiser un agent tant qu’il n’a pas passé un protocole minimal sur fiabilité, coût et sécurité. Le gain “wow” est parfois moins visible au départ, mais la performance réelle en production et la confiance de l’équipe progressent nettement.
Sources: https://www.youtube.com/watch?v=awV2kJzh8zk, https://github.com/vectara/awesome-agent-failures
