Construire un agent IA robuste : les leçons de Guillaume Laforge (Google Cloud)

Developer Advocate chez Google Cloud, Guillaume Laforge propose son panorama de ce qui fonctionne vraiment dans les architectures d’agents IA. Pour celui qui contribue à la fois à des frameworks IA et à la structuration de communautés de développeurs, le sujet dépasse largement le simple effet de mode et mène à une transformation en profondeur de la manière dont on conçoit des systèmes intelligents. Patterns, anti-patterns… Comment construire un système fiable et déconstruire des idées déjà reçues.

Comprendre ce qu’est vraiment un agent IA

« Je pense que vous serez tous d’accord avec moi sur le fait que l’IA, la GenAI, les LLM, etc., représentent une vague inarrêtable. Une vague au moins aussi importante que les révolutions Internet ou mobile. » Le ton est donné. Pour Guillaume Laforge, l’arrivée des agents IA marque, selon lui, un basculement comparable aux grands changements d’infrastructure de ces dernières décennies.

Pour poser des bases solides, l’expert distingue trois grandes catégories d’agents : les agents grand public (ChatGPT, Claude, Gemini…), les assistants de code (Gemini CLI, Claude Code…), et surtout les agents conçus sur mesure, intégrés dans des applications, des sites ou des workflows métier. Ce sont ces derniers qui concentrent aujourd’hui l’innovation, car ils doivent interagir avec des données privées, des outils internes, voire d’autres agents.

Il y a trois grandes catégories de tâches : l’observation, la planification et l’action.

Guillaume Laforge rappelle qu’un agent IA est un système composite, loin du simple chatbot. « Un agent, c’est un LLM, auquel on ajoute une mémoire (…) et un aspect très important : la planification par étape. Et qui dit étapes dit donc appel d’outils. » Il propose même une véritable équation de l’agent, où chaque brique joue un rôle précis : LLM (le « cerveau ») + mémoire (conversationnelle ou long terme) + planification + outils (MCP, API, RAG, code exécuté…) + une boucle d’itération.

Cette boucle se déroule en plusieurs temps successifs :

• Observer (comprendre la requête, interpréter le prompt système, identifier le but),
• Planifier (choisir la stratégie et les outils),
• Agir (recherche, appels API, exécution de code, interaction avec d’autres agents, human-in-the-loop),
• Réfléchir pour améliorer ou corriger la sortie.

« Il y a trois grandes catégories de tâches : l’observation, la planification et l’action. Et il y a aussi la partie réflexion : le LLM se dit « c’est pas mal ce que j’ai fait, mais il manque peut-être une section ». » Autrement dit, un agent IA n’est pas un chatbot plus sophistiqué : c’est une machine à décomposer et exécuter des tâches complexes. Et cette capacité structure complètement la manière dont on les conçoit.

Ce qui marche vraiment : les patterns d’architecture identifiés par Guillaume Laforge

Le mythe de l’agent totalement autonome

Guillaume Laforge commence par démonter l’idée selon laquelle les agents pourraient s’autogérer sans contrôle : « Les LLM continuent d’halluciner. Même les meilleurs modèles. Le LLM peut dire « il faudrait appeler telle fonction », et elle n’existe pas. Ou il change l’ordre d’invocation des outils. Ou il invente des paramètres. » Il pointe notamment l’erreur fréquente consistant à enrichir sans fin le prompt système pour « canaliser » l’agent : « Plus le prompt est grand, plus les LLM hallucinent. Garbage in, garbage out. »

Pattern n°1 : le chef d’orchestre

Face à ces limites, un pattern émerge nettement : le découpage. « Un pattern qui fonctionne bien, c’est celui du chef d’orchestre : on découpe en petites tâches. Une tâche de recherche, une tâche de résumé, une tâche de synthèse. Plus les tâches sont spécialisées, plus ça marche. »

Cette orchestration peut passer par :

• Des frameworks orientés graphes comme LangGraph,
• Des frameworks hiérarchiques d’agents comme ADK,
• Des workflow engines (n8n, etc.),
• Ou un pilotage programmatique classique.

Guillaume Laforge insiste : la spécialisation des sous-agents augmente la fiabilité et réduit les hallucinations.

Pattern n°2 : repenser les outils (plutôt que tout exposer à l’agent)

Autre erreur fréquente : donner à un agent IA un catalogue d’API REST brutes. « L’anti-pattern typique, c’est d’exposer des ressources GET, POST, etc. Il vaut mieux des fonctions métier. » Autrement dit, l’agent doit disposer de « capacités métier », pas d’une vision technique des endpoints. Moins d’outils, mieux conçus, entraîne moins de confusion.

Pattern n°3 : MCP, la standardisation

Guillaume Laforge revient ensuite sur le MCP, protocole qui s’impose rapidement dans l’écosystème : « MCP, c’est un protocole un peu comme l’USB des outils. Un protocole pour standardiser les interactions entre agents et outils. Avant, chacun développait son propre système. Aujourd’hui, on peut en utiliser un sur étagère. »

L’approche facilite la maintenance. Moins de « glue d’intégration dans chaque projet », plus de modularité, et la possibilité d’intégrer ses propres serveurs MCP à d’autres agents.

Pattern n°4 : l’interopérabilité agent-2-agent

Google travaille également sur un protocole de communication entre agents.
« A2A, ou agent-2-agent, a été lancé il y a un an par Google, et permet de définir un protocole entre agents. On standardise l’idée qu’un agent peut présenter une carte d’identité avec la description de ses compétences et être multimodal, en échangeant des messages, en créant des tâches et des artefacts. » Un futur où les agents pourraient donc collaborer librement, peu importe le framework, la langue ou la plateforme.

Les anti-patterns, ces pièges dans lesquels tombent presque toutes les équipes

Anti-pattern n°1 : le « mandat chatbot »

Beaucoup d’entreprises arrivent avec une injonction simple : « Il faut un chatbot. » Guillaume Laforge met en garde : « Je vois pas mal d’entreprises qui se disent… « Et si on faisait un chatbot ? » Mais souvent, les chatbots sont frustrants. Tout n’a pas besoin d’être conversationnel. »

Il invite à explorer des alternatives multimodales, plus naturelles, plus fluides et parfois invisibles pour l’utilisateur ou l’utilisatrice. « La meilleure intégration d’un agent IA devrait être transparente », explique-t-il.

Anti-pattern n°2 : l’évaluation insuffisante (le vibe-checking minimal)

Les agents doivent être testés au plus près du terrain : « Il faut être sûr d’observer, de mesurer, de réagir. Les modèles ont tendance à inventer des réponses avec force et conviction. »

Il insiste sur la collaboration avec les experts métier et sur la collecte des vraies interactions pour constituer des « golden responses » (réponses en or, ndlr). La phase d’évaluation n’est pas accessoire, mais centrale.

Anti-pattern n°3 : la confabulation silencieuse

Sans grounding (l’ancrage des réponses dans des faits précis et à jour) explicite, l’agent peut générer des affirmations fausses mais convaincantes. D’où l’importance de citer les sources (RAG, références, renvois) et de valider les sorties immédiatement via des mécanismes dédiés. Cette approche renforce la confiance dans la génération et se base sur une méthode dite IVO, pour Immediately Validate Output (sortie immédiatement validée).

Anti-pattern n°4 : « down the rabbit hole », quand l’agent entraîne le développeur

Les agents de code peuvent eux aussi convaincre… à tort. « Les agents de codage peuvent vous entraîner sur la mauvaise piste, avec assurance, conviction et aplomb. Il faut relever la tête, regarder ce qu’on fait et garder le contrôle. »

Guillaume Laforge appelle à se concentrer sur la valeur utilisateur, plutôt que sur l’ajout continu de fonctionnalités suggérées par l’IA. « Levez la tête du guidon et focalisez-vous sur la valeur ajoutée ! »