Limites actuelles du coding assisté
Ce que l'agent fait mal, quand reprendre la main. Modes d'échec courants et stratégies de mitigation.
Les angles morts structurels de l’agent
Un agent de coding optimise pour un signal mesurable : le build compile, les tests passent, le linter ne signale rien. Tout ce qui échappe à ces signaux automatiques est un angle mort.
Ce que l’agent ne sait pas faire
Les limites fondamentales, en 2026, restent les mêmes :
- Raisonner sur la performance en production — concurrence, thread starvation, latence sous charge, consommation mémoire. Le compilateur et les tests unitaires ne mesurent rien de tout ça.
- Évaluer la pertinence métier — le code fait-il ce que le client veut ? L’agent ne connaît pas l’intention derrière la spec.
- Estimer sa propre incertitude — un LLM produit une réponse avec la même assurance qu’elle soit correcte ou inventée. Il n’y a pas de signal « je ne suis pas sûr ».
- Comprendre le contexte organisationnel — qui maintient ce module, quelles sont les contraintes de déploiement, quel SLA respecter.
Point clé : L’agent est excellent pour le travail mécanique vérifiable. Il est mauvais pour tout ce qui demande du jugement, du contexte implicite, ou une évaluation non fonctionnelle.
Taxonomie des modes d’échec
Les échecs d’un agent de coding se classent en catégories récurrentes. Les connaître permet de les anticiper.
| Mode d’échec | Symptôme | Détection |
|---|---|---|
| Hallucination d’API | L’agent invente une méthode, un paramètre ou une version de librairie qui n’existe pas | Erreur de compilation, ou comportement inattendu si un homonyme existe |
| Drift silencieux | Le code compile et passe les tests, mais ne fait pas ce qu’on veut | Review humaine, tests d’acceptation, démo au métier |
| Sur-ingénierie | Abstractions inutiles (interfaces à une implémentation, factories sans raison) | Review de la complexité du diff par rapport au besoin |
| Teaching to the test | Après plusieurs corrections, l’agent contourne le problème pour faire passer les tests | Review du diff — le code « triche » pour satisfaire le signal |
| Vision locale | L’agent corrige un module sans voir l’impact sur les consommateurs | Tests d’intégration, analyse d’impact manuelle |
| Boucle infinie | L’agent tente la même correction en boucle sans progrès | Limite de tours, détection de pattern répétitif |
Quand reprendre la main
La question n’est pas « l’agent peut-il faire cette tâche ? » mais « l’agent a-t-il le feedback nécessaire pour vérifier son travail ? »
Signaux pour reprendre le contrôle
- L’agent boucle depuis 3+ tours sans progrès mesurable.
- Le diff produit est significativement plus complexe que ce que la tâche justifie.
- La tâche touche à la sécurité, la performance, ou la concurrence — domaines sans feedback automatique.
- Le code fonctionne mais le raisonnement de l’agent montre une incompréhension du problème.
- Le module cible n’a ni tests, ni types forts, ni architecture claire — les leverage points sont absents.
Point clé : Plus les leverage points sont en place (tests, types, lint, architecture claire), plus l’agent peut travailler seul. Moins ils le sont, plus le jugement humain est nécessaire.
Attention : Ne pas confondre « l’agent a réussi » et « le résultat est bon ». Un build vert et des tests verts sont des conditions nécessaires, pas suffisantes.
Stratégies de mitigation (lien ZTE)
Le Zero Trust Execution part du principe qu’aucune étape n’est fiable par défaut. Chaque sortie de l’agent doit être vérifiée avant d’être considérée comme acquise.
En pratique
- Limites de tours — fixer un budget max de tentatives de correction (3 à 5 tours). Au-delà, le problème est probablement dans le prompt ou le contexte, pas dans le code.
- Review du diff, pas seulement du résultat — vérifier comment l’agent a résolu le problème, pas seulement si les tests passent.
- Sub-agent reviewer — un second agent qui n’a pas vu le processus de création relit le code avec un regard neuf.
- Tests d’intégration en boucle fermée — lancer les tests d’intégration (pas seulement unitaires) après chaque modification pour attraper les effets en cascade.
- Découpage en sous-tâches — réduire la portée de chaque session pour limiter le context rot et faciliter la vérification.
Point clé : La confiance dans l’agent se construit par la vérification, pas par l’espoir. Plus la tâche est critique, plus les garde-fous doivent être explicites.
Remonte relire la fiche memo ci-dessus en pretant attention aux points rates, puis clique sur « Recommencer » pour retenter.