C’est peut-être LE sujet de 2025, tout le monde en parle, et de nouveaux outils sortent toutes les semaines (ça rappelle l’arrivée du terme « cloud »).

Un agent IA c’est quoi ? C’est un programme intelligent conçu pour réaliser des tâches ou prendre des décisions de manière autonome à partir de données. Pour atteindre un objectif donné, il interagit avec un modèle d’intelligence artificielle, en exploitant des outils et des ressources spécifiques.

La différence entre les modèles d’IA classiques et les agents réside dans leur mode d’interaction. Alors que les modèles d’IA comme Gemini ou Sonnet fonctionnent sur des échanges ponctuels et réactifs, sans mémoire des interactions précédentes ni capacité d’initiative, les agents sont autonomes et orientés vers des objectifs à long terme.

Agent workflow, patterns, systems

Voici un schéma qui explique très bien le fonctionnement de base d’un agent.

À la suite d’une demande utilisateur (généralement via une interface graphique de type chat), l’agent planifie ses actions et utilise ses outils (Tool) à disposition pour réaliser la tâche qui lui est demandée. (Think → Act → Observe)

Voici un autre schéma (j’aime bien les schémas), qui détaille un peu plus le fonctionnement interne de l’agent.

Il utilise un LLM (un modèle) pour la compréhension et le raisonnement. Les instructions (Prompt) qui lui sont attribuées lui permettent de réagir d’une manière précise et orientée.

Il utilise également sa mémoire pour garder le contexte entre les différentes actions (Step) et la conversation avec l’utilisateur. Puis il utilise ses outils (Tool) pour interagir avec l’extérieur. Un Tool est une fonctionnalité que l’agent peut utiliser pour effectuer une action. Il comporte une description, des inputs, et des outputs. Ça peut être un appel à une API de taux d’échange de monnaie, à un moteur de recherche, à une base de données etc.

Les tools sont la partie la plus intéressante, car ils permettent à l’agent d’agir sur l’environnement que vous lui conférez (accès au SI de votre entreprise par exemple).

Encore un schéma emprunté qui représente différents patterns / systèmes existant pour mettre en place un agent.

Le système 3 correspond aux deux premiers schémas : un agent simple avec des tools à sa disposition pour effectuer une tâche.

Le système 4 « multi-agent » est très intéressant à mettre en place. Il consiste à créer plusieurs agents (selon leur domaine par exemple), et à les faire collaborer ensemble. Un des avantages est similaire à une codebase : les domaines sont définis, isolés, séparés. Chaque agent a son prompt dédié (Sytem Prompt), et peut communiquer avec tous ou une partie des autres agents. Le tout est généralement orchestré par un RootAgent ou ManagerAgent.

Plusieurs frameworks permettent de mettre ce pattern en place facilement (LangGraph, LlamaIndex, smolagents, OpenAI, CrewAI, AutoGen). Ils utilisent généralement le ReAct Prompting (Let’s think step by step) et permettent aux agents d’avoir connaissance des tools de chacun, et ainsi de donner la possibilité aux agents de se passer la balle quand c’est nécessaire, avant de retourner une réponse finale à l’utilisateur.

Le protocole MCP

Model Context Protocol (MCP) : introduit par Anthropic fin 2024 et pris en charge par OpenAI en mars 2025. Il permet de créer des serveurs qui exposent des données et des fonctionnalités à des applications basées sur des LLM de manière sécurisée et standardisée. Considérez-le comme une API web, mais spécialement conçue pour les interactions avec les grands modèles de langage.

Ce protocole va permettre à notre agent d’utiliser des Tools beaucoup plus facilement. Par exemple, plutôt que d’intégrer l’API Jira dans notre agent (ou « client »), on va lui donner accès à un MCP serveur qui servira d’abstraction avec cette API. Ce « server » va exposer des Tools (via une description, inputs et outputs) que notre « client » va comprendre via son LLM.

Il existe d’ailleurs toute une panoplie de MCP serveur open-source que l’on peut récupérer.
Des SDK existent pour créer localement un MCP client/serveur et tester tout ça.

Quelques ressources :

• le protocole : https://modelcontextprotocol.io/
• SDK pour Python : https://github.com/modelcontextprotocol/python-sdk
• pour debug un MCP server : https://github.com/modelcontextprotocol/inspector
• MCP serveurs existants : https://mcp.so/ et https://www.pulsemcp.com/servers
• Docker MCP catalogue : https://hub.docker.com/catalogs/mcp

Le protocole A2A

Annoncé plus récemment par Google, ce protocole va plus loin et permet à deux agents distants de communiquer.

Par exemple, votre propre agent (qui utilise plein d’outils via des supers MCP serveurs), pourrait communiquer et gérer des tâches en commun avec un agent d’une autre entreprise (développé dans un autre langage, déployé sur un autre cloud etc.)

Ce protocole assure un échange sécurisé d’informations et une coordination des actions des agents sur les plateformes d’entreprise, améliorant l’interopérabilité et l’automatisation.

Autres considérations

Il est important de pouvoir tracer et monitorer ce qu’il se passe entre une requête utilisateur et la réponse finale. Déjà pour gérer les coûts des différents modèles, mais également pour comprendre comment l’agent (ou les agents) interagissent entre eux.

C’est valable pour le debug, le suivi d’erreurs, et l’évaluation. L’évaluation consiste à surveiller/suivre l’évolution de votre agent. A chaque nouvelle version/modification, il est important de savoir si votre agent est toujours aussi pertinent sur la réalisation de certaines tâches. Pour cela vous pouvez suivre l’évaluation offline (vérifier via un dataset les réponses apportées à des questions définies, un peu comme un benchmark) et l’évaluation online (feedback utilisateur par exemple). Langfuse est un outil qui permet de suivre tout ça (latency, coûts, erreurs, feedback, précision, metrics), il a une version gratuite donc ne pas hésiter à le tester.

Un autre point important est la sécurité (et la gestion des données personnelles). D’autant plus si vous exposez des éléments de votre système d’information via des Tools, il faut protéger ses inputs et ses outputs comme pour n’importe quelle application. Certains outils existent comme LLM-Guard, des APIs et autres techniques de défense.

Autres ressources

Quelques ressources supplémentaires en vrac :

• un cours en ligne sur les agents par Hugging Face : https://huggingface.co/learn/agents-course/unit0/introduction
• Roadmap AI Engineer, qui comporte pleins de notions intéressantes : https://roadmap.sh/ai-engineer
• Des « recettes » pour agent IA : https://www.agentrecipes.com/
• guide OpenAI sur la création d’agent IA : https://cdn.openai.com/business-guides-and-resources/a-practical-guide-to-building-agents.pdf

Retour d’expérience

J’ai commencé par un POC perso avec un agent (MCP client) et un MCP server qui me servait d’abstraction pour une API publique, histoire de tester ce nouveau protocole et également utiliser les librairies Python associées.

Ensuite à titre professionnel j’ai pu aller plus loin, avec un agent (multi-agent) beaucoup plus poussé, qui interagit avec des systèmes variés, toujours avec le protocole MCP. Les librairies Python sont encore très récentes mais fonctionnent plutôt bien, et la rapidité d’intégration / d’ajout de nouvelles features à l’agent est largement raccourci car on s’affranchit de la partie intégration.

Le prompting ainsi que la description des Tools est primordiale, il faut vraiment « guider » l’agent pour qu’il parvienne à se comporter comme on le souhaite.

Je n’ai pas encore testé le protocole A2A, qui est très récent et pour lequel il faut un cas d’usage (avec un agent extérieur).