J’ai arrêté d’écrire de longs prompts dans une boîte de discussion en espérant obtenir un résultat parfait du premier coup. Cette approche a montré ses limites. Nous avons atteint un plateau où les modèles de langage gèrent sans problème les premiers 80 % d’une tâche, mais butent systématiquement sur les détails complexes des 20 % restants.
Face à ce constat, chercher un modèle toujours plus intelligent est une impasse. La solution réside plutôt dans la conception de systèmes capables de s’auto-corriger. C’est tout le principe de l’ingénierie agentique, qui s’appuie sur une boucle récursive : penser, agir, observer (Reason-Act-Observe).
Cette boucle transforme un simple agent conversationnel statique en un système autonome capable de poursuivre un objectif et d’itérer jusqu’à l’atteindre.
On a souvent tendance à penser que le modèle de langage est l’élément central du système. En réalité, d’après mes observations, il ne représente qu’environ 10 % de la réussite finale. Les 90 % restants reposent sur le harnais de contrôle, c’est-à-dire l’échafaudage sophistiqué composé du contexte, des outils et des protocoles qui encadrent et guident le comportement de l’agent.
La dynamique de la boucle Reason-Act-Observe
Le cycle démarre par la phase de réflexion (Reason). L’agent évalue son état actuel et planifie les étapes nécessaires pour atteindre son but. Plutôt que de formuler une réponse immédiate, son moteur de raisonnement détermine quel outil est le plus adapté à la situation.
Vient ensuite la phase d’action (Act). L’agent interagit avec son environnement extérieur en exploitant des outils tels que des API, des systèmes de fichiers ou des serveurs spécialisés.
Mais l’étape cruciale (celle où l’on sort de la simple automatisation linéaire) reste l’observation. Durant cette phase, l’agent analyse les résultats de ses actions et vérifie s’ils correspondent à la définition attendue du travail accompli. Si le résultat s’avère insatisfaisant, la boucle redémarre : l’agent intègre ces nouvelles informations pour réajuster sa planification et corriger le tir.
Avec ce fonctionnement, nous ne sommes plus le principal fournisseur d’instructions de l’IA ; nous concevons le système qui pilote l’agent. Notre rôle évolue d’un contrôle manuel et minutieux vers une délégation à fort impact.
Quitter le “Vibe Coding” pour une évaluation rigoureuse
Une boucle de rétroaction ne vaut que par la qualité de son mécanisme de vérification. C’est un point sur lequel butent de nombreux développeurs : il est indispensable de définir une condition d’arrêt extrêmement claire, pour que l’agent sache précisément quand sa tâche est finalisée (un peu comme pour vérifier la cuisson d’un gâteau).
Cette vérification dépasse la simple exécution d’un code sans erreur. Elle repose sur deux piliers :
- L’évaluation du résultat (output evaluation) : l’analyse minutieuse du produit final généré par l’agent.
- L’évaluation de la trajectoire (trajectory evaluation) : l’examen du cheminement et des étapes empruntées par l’agent pour parvenir à ce résultat.
Sans ces barrières de sécurité automatisées, on tombe rapidement dans ce que j’appelle le “vibe coding”, une pratique risquée consistant à accepter les productions de l’IA sur la simple foi d’une impression visuelle rapide, sans validation systématique.
En ingénierie agentique, nous utilisons des tests classiques pour valider les composants déterministes du système, tandis que les évaluations (ou “evals”) s’appuient sur des grilles de critères et des modèles juges pour analyser le raisonnement non déterministe.
Ce dispositif crée un cercle vertueux d’amélioration continue capable de détecter des défaillances conceptuelles subtiles qu’un œil humain pourrait laisser passer.
Le Model Context Protocol (MCP) : connecter l’agent au monde réel
À mesure que ces boucles gagnent en autonomie, le besoin de standardiser leur connexion aux ressources numériques se fait ressentir. C’est l’origine du Model Context Protocol, ou MCP.
Les API traditionnelles ont été conçues pour que des programmes communiquent entre eux, fonctionnant un peu comme un coffre-fort nécessitant une clé d’accès très spécifique. Le protocole MCP change la donne en fournissant directement au modèle une carte sémantique, lisible par machine, de vos outils et de vos données.
Au lieu de coder en dur des instructions rigides pour chaque point d’accès, on expose un protocole qui permet à l’agent de découvrir lui-même les fonctionnalités disponibles. Le modèle ne se contente plus d’utiliser passivement un logiciel ; il s’intègre activement dans l’environnement technique. Cela supprime les couches de liaison complexes entre le moteur de raisonnement et les sources de données, transformant des routes statiques en interfaces dynamiques.
L’essor de l’économie agentique et du protocole A2A
L’horizon ne se limite pas à un agent travaillant seul dans son coin. Nous voyons émerger une économie de l’agentique, caractérisée par des millions d’agents capables de collaborer, de négocier et de se déléguer des tâches.
Certains objectifs complexes dépassent les capacités d’un modèle généraliste unique. Il devient alors indispensable de s’appuyer sur des sous-agents spécialisés. Pour orchestrer ce réseau, des protocoles de communication d’agent à agent (A2A ou Agent-to-Agent) permettent de transférer les tâches et de gérer les erreurs sur des architectures distribuées.
On peut ainsi imaginer un agent de développement logiciel déléguant la validation de son code à un agent expert en sécurité, qui lui-même consulte un agent spécialisé en bases de données, le tout sans la moindre intervention humaine directe. Cette intelligence partagée s’apparente aux structures de nos sociétés, où la mise en commun des expertises individuelles permet de surmonter des défis complexes.
L’équation économique de l’ingénierie agentique
Ce changement de paradigme redéfinit également l’aspect financier du développement logiciel. Le “vibe coding”, séduisant par ses faibles coûts initiaux, engendre en réalité une dette opérationnelle colossale à cause de la consommation excessive de tokens lorsque l’on demande de manière répétée à l’IA de corriger ses propres erreurs non vérifiées.
L’ingénierie agentique exige un investissement de départ plus important (les coûts d’infrastructure et de développement pour concevoir le harnais), mais elle réduit considérablement les frais d’exploitation sur le long terme. En structurant intelligemment le contexte et en activant dynamiquement les outils requis, on s’assure que le modèle ne reçoit que des données à forte valeur ajoutée, évitant ainsi la surconsommation liée à des contextes surchargés.
De plus, il est possible de mettre en œuvre un routage dynamique des modèles : réserver les modèles de pointe, plus onéreux, pour les choix d’architecture de haut niveau, et déléguer les tâches de vérification courantes à des modèles plus légers et économiques.
Faire évoluer sa posture d’ingénieur
Adopter la boucle Reason-Act-Observe implique de passer d’une logique de syntaxe à une logique d’intention. Dans ce contexte, le harnais d’orchestration doit être considéré comme un actif d’ingénierie de premier plan. Si un agent commet une erreur, l’enjeu n’est pas simplement de corriger le code produit, mais de mettre à jour les règles et les garde-fous du système pour que cette défaillance ne se reproduise plus jamais.
Nous nous dirigeons vers un modèle d’organisations extrêmement légères où un nombre très restreint de personnes pourra piloter une flotte complète d’agents gérant des départements entiers. Pour tirer parti de cette transition, l’accent doit être mis sur l’art de la spécification, de la décomposition des problèmes et de l’évaluation critique.
Il est temps de dépasser la simple rédaction de consignes pour concevoir l’infrastructure globale qui génère les résultats. Je vous encourage à concevoir votre première boucle dès aujourd’hui en définissant avec précision les critères de validation de votre projet.
N’hésitez pas à vous abonner pour suivre l’évolution de ces technologies, et partagez en commentaire la boucle la plus complexe que vous tentez de mettre en œuvre.