Les agents IA, MCP et le paysage moderne des frameworks

Comment fonctionnent les agents IA

Un agent IA est un système piloté par un LLM qui fonctionne en boucle :

1. Planifier : décomposer un objectif en sous-tâches.
2. Agir : sélectionner et invoquer un ou plusieurs outils.
3. Observer : lire les résultats des outils et mettre à jour l'état interne.
4. Itérer : répéter jusqu'à ce que l'objectif soit atteint ou qu'une condition d'arrêt soit remplie.

L'exemple le plus fondamental de cette boucle est ReAct (Reasoning + Acting). Présenté par Yao et al. en 2022, ReAct entrelace des traces de raisonnement en chaîne de pensée avec des étapes d'action. L'agent réfléchit à voix haute à ce qu'il doit faire, appelle un outil, observe le résultat, et raisonne à nouveau. C'est, en somme, le « Hello World » des architectures d'agents : presque tous les frameworks modernes (LangChain, Semantic Kernel, ADK, Agents SDK) embarquent une boucle de type ReAct comme mode d'agent par défaut. Comprendre ReAct est le prérequis pour comprendre tout le reste de cet article.

En option, les agents intègrent une mémoire (contexte à court et long terme) et des points de contrôle avec intervention humaine (human-in-the-loop) pour les décisions critiques pour la sécurité.

La décomposition canonique de NVIDIA reste un modèle mental utile :

Agents vs. workflows (la distinction d'Anthropic)

Les deux appartiennent à la même famille des systèmes agentiques. Les systèmes en production combinent fréquemment des étapes de workflow déterministes avec des sous-tâches pilotées par des agents là où de la flexibilité est nécessaire.

Les outils sont des contrats sémantiques

Les outils sont des contrats sémantiques. Un agent lit le nom, la description et le schéma d'un outil pour décider s'il doit l'appeler et comment. Si l'un de ces signaux est vague, l'agent peut :

• Appeler le mauvais outil.
• Transmettre des entrées mal formées.
• Mal interpréter les sorties et halluciner par la suite.

La recherche d'Anthropic sur l'écriture d'outils pour les agents montre que traiter les outils comme des produits destinés aux développeurs améliore de façon mesurable les taux de réussite et réduit le gaspillage de tokens :

Patrons : du workflow à l'autonomie complète

Ces patrons se situent sur un spectre allant du totalement déterministe au totalement autonome. Choisissez selon le niveau de contrôle et de variance que votre cas d'usage exige :

Règle empirique (Anthropic) : Commencez par le patron le plus simple qui résout le problème. Ne passez à des boucles d'agent complètes que lorsque la tâche exige réellement une prise de décision dynamique.

Exemple concret : GitHub Copilot dans VS Code

L'agent de codage de GitHub Copilot dans VS Code illustre bien la façon dont ces patrons se combinent dans un produit livré :

1. Routage. Quand vous tapez un message, Copilot classe l'intention : s'agit-il d'une complétion en ligne, d'une question dans le chat, ou d'une modification multi-fichiers ? Chacune est routée vers un pipeline différent.
2. Orchestrateur et travailleurs. En mode agent, Copilot reçoit une tâche de haut niveau (par ex. « ajouter une validation des entrées au formulaire d'inscription »), la décompose en sous-tâches, et délègue chacune à des appels d'outils spécialisés : lire des fichiers, rechercher des symboles avec grep, exécuter des commandes dans le terminal, appliquer des modifications, lancer des tests.
3. Évaluateur et optimiseur. Après avoir apporté des modifications, l'agent lance des linters, des tests ou des vérificateurs de types. Si quelque chose échoue, il lit la sortie d'erreur, raisonne sur la correction, et itère dans une boucle générer, évaluer, affiner.
4. Chaînage de prompts avec contrôles. La sortie de chaque étape conditionne la suivante. Si la lecture d'un fichier renvoie un contenu inattendu, l'agent replanifie plutôt que de poursuivre à l'aveugle.

Sous le capot, il s'agit d'une boucle ReAct adossée à une intégration d'outils de type MCP : Copilot découvre les outils disponibles (système de fichiers, terminal, recherche, API de l'éditeur), les appelle via des schémas structurés, observe les résultats, et raisonne sur les étapes suivantes. C'est un exemple concret de système en production qui mêle workflows déterministes et flexibilité pilotée par agent.

Copilot vous laisse aussi modifier deux leviers clés qui influent directement sur le comportement :

• Modèle. Passer, disons, de GPT-4o à Claude Sonnet ou Gemini change le moteur de raisonnement. Les modèles ont des forces différentes : certains sont meilleurs pour planifier des modifications en plusieurs étapes, d'autres pour suivre les instructions avec précision, d'autres encore pour minimiser les hallucinations. Les mêmes outils et le même prompt peuvent produire des résultats sensiblement différents selon le modèle, et c'est pourquoi les évaluations (la phase 4 du plan de mise en œuvre ci-dessous) comptent.

• Mode. Copilot propose trois modes intégrés, situés à différents points du spectre d'autonomie :

  • Ask : un pipeline question-réponse (chaînage de prompts). Pas de modification de fichiers, pas d'appels d'outils, juste du raisonnement sur le contexte que vous fournissez.
  • Agent : la boucle complète orchestrateur-travailleurs. Il peut lire votre base de code, exécuter des commandes dans le terminal, installer des dépendances, créer des fichiers, et itérer de façon autonome sur les échecs. C'est la boucle ReAct en action.
  • Plan : un entre-deux. L'agent raisonne sur la tâche et produit un plan étape par étape, mais attend votre validation avant d'exécuter la moindre modification. C'est essentiellement le patron du « point de contrôle avec intervention humaine » décrit plus haut.

  Passer de Ask à Plan puis à Agent augmente la flexibilité, mais accroît aussi la variance, le coût, et l'importance de bons schémas d'outils. Vous pouvez également définir des agents personnalisés avec des instructions et des ensembles d'outils sur mesure, créant de fait une couche de routage spécialisée pour vos propres workflows.

• Sessions. Copilot permet d'exécuter plusieurs sessions d'agent en parallèle, chacune avec son propre modèle, mode et contexte. Cela transforme le modèle mono-agent en un patron de parallélisation concret : vous pouvez avoir une session qui écrit des tests unitaires pour un composant, une autre qui implémente une nouvelle fonctionnalité, une autre qui génère de la documentation, le tout s'exécutant simultanément sur la même base de code. Cela fonctionne particulièrement bien dans les architectures aux frontières de modules nettes. Dans un projet Django, par exemple, chaque app (authentification, facturation, notifications) est largement indépendante, avec ses propres modèles, vues, URLs et tests. Vous pouvez sans risque lancer des sessions parallèles cantonnées à différentes apps, avec un risque minime de conflits de fusion, car les surfaces de fichiers se chevauchent à peine. Le même principe s'applique à toute base de code aux frontières de packages ou de services bien définies (microservices, packages de monorepo, modules Go, etc.). En pratique, les sessions parallèles vous permettent d'échanger du temps réel contre du débit, en compressant en travail concurrent ce qui serait du travail séquentiel, tant que les tâches sont suffisamment isolées.

L'écosystème des frameworks

L'écosystème se divise en trois couches. Les frameworks d'agents sont là où vous construisez des agents. MCP est le protocole qui les relie aux outils externes. Les couches de gouvernance gèrent des flottes d'agents à l'échelle de l'entreprise. Elles sont complémentaires, et non interchangeables.

Frameworks d'agents

Microsoft Agent Framework

• Actuellement en public preview (GitHub).
• Unifie Semantic Kernel (SK) et AutoGen sous un même modèle de programmation.
• Ajoute des workflows typés et orientés graphe, avec une forte observabilité (OpenTelemetry intégré).
• Intégration native des protocoles MCP et A2A.
• Prise en charge multi-fournisseurs : Azure OpenAI, OpenAI, Anthropic, Ollama, et plus.
• Livré avec une interface développeur (DevUI) pour inspecter les traces des agents.

OpenAI

La pile d'agents d'OpenAI est répartie sur plusieurs produits :

La page Agent Platform est l'ombrelle marketing d'OpenAI pour tout ce qui précède.

Google Agent Development Kit (ADK)

• Framework open-source et modulaire, optimisé pour Gemini mais agnostique au modèle.
• Prend en charge les topologies mono-agent et multi-agents.
• Cibles de déploiement :
  • Vertex AI Agent Engine : entièrement managé, auto-scalable.
  • Cloud Run : conteneurisé, infrastructure que vous apportez.
  • GKE : déploiement basé sur Kubernetes.

Protocole d'interopérabilité

MCP (Model Context Protocol)

• Standard ouvert créé à l'origine par Anthropic, désormais gouverné par The Linux Foundation et ouvert aux contributions de la communauté (protocole et SDKs, registre de serveurs).
• Les clients (Claude, ChatGPT, VS Code, IDE JetBrains, Cursor, etc.) se connectent à des serveurs MCP qui exposent des schémas d'outils.
• Devient rapidement la couche d'interopérabilité de facto des systèmes agentiques.
• Registre croissant de serveurs communautaires et éditeurs (GitHub, Azure DevOps, Notion, Playwright, Slack, bases de données, etc.).
• Valeur clé : écrivez vos outils une seule fois, exposez-les à n'importe quel client compatible MCP, sans aucun travail d'intégration par client.
• Les trois frameworks ci-dessus prennent en charge MCP nativement ou via des plugins.

Couches de gouvernance

MuleSoft Agent Fabric (Salesforce)

• Couche de gouvernance d'entreprise pour les flottes d'agents :
  • Registre : catalogue des agents et outils disponibles.
  • Courtier : achemine les requêtes vers le bon agent.
  • Politiques : contrôle d'accès, limitation de débit, prévention des pertes de données.
  • Observabilité : journalisation et traçage centralisés.
• Prend en charge MCP comme standard de connectivité.
• Conçu pour les organisations qui exploitent des dizaines à des centaines d'agents à l'échelle.

Équipes multi-agents

Un patron en plein essor est celui des équipes d'agents conteneurisées : des groupes d'agents spécialisés par domaine qui collaborent sous une même enveloppe de gouvernance :

• AgentCatalog sur Docker Hub en est un exemple précoce : des images d'agents prêtes à l'emploi pour des tâches courantes.
• Les équipes peuvent être composées dynamiquement (par ex. une équipe de « revue de contrats » avec un agent d'extraction de clauses, un agent de scoring de risque, et un agent de synthèse).
• L'orchestration de conteneurs (Kubernetes, Docker Compose) permet le passage à l'échelle, le versionnement et le rollback au niveau de l'agent.
• Les politiques internes de gouvernance et d'accès peuvent être appliquées par conteneur.

Architectures de référence

Les quatre convergent vers MCP comme standard de connectivité des outils. Le choix est dicté par l'empreinte cloud existante, les relations avec les éditeurs, et les exigences de gouvernance.

De zéro à la production : un plan de mise en œuvre

Chaque phase a un livrable clair et des critères de sortie, pour que vous sachiez quand passer à la suite (ou faire un retour en arrière).

Phase 1 : Définir la surface de vos outils

Objectif : Décider ce qu'il faut exposer avant d'écrire la moindre ligne de code.

1. Auditez les API et workflows existants de votre système. Identifiez 3 à 5 opérations à forte valeur que des agents appelleraient de façon réaliste, par ex. rechercher des documents, extraire des entités, vérifier le statut d'un dossier, générer une synthèse.
2. Pour chaque opération, répondez :
   • Quelles sont les entrées requises vs. facultatives ? (Typez-les strictement.)
   • À quoi ressemble la sortie du cas nominal ? Et la sortie d'erreur ?
   • L'opération est-elle en lecture seule ou a-t-elle des effets de bord ?
3. Écrivez les schémas d'outils (JSON Schema ou équivalent) avec :
   • Une description claire et lisible par l'agent. C'est ce que le LLM voit pour décider d'appeler l'outil.
   • Un paramètre mode ("concise" | "detailed") pour contrôler le niveau de détail de la sortie.
   • Une pagination par curseur (cursor + limit) pour les endpoints de liste.
   • Un drapeau truncated: true dans les réponses, pour que l'agent sache qu'il faut en récupérer davantage.
   • Des erreurs pédagogiques : des messages d'erreur qui disent à l'agent comment corriger l'appel, pas seulement qu'il a échoué.

Livrable : Un document de schémas (définitions OpenAPI ou d'outils MCP) relu par au moins une personne qui ne l'a pas écrit.

Critère de sortie : Un collègue peut lire les schémas à froid et prédire correctement ce que fait chaque outil, quelles entrées il requiert, et à quoi ressemble la sortie.

Phase 2 : Construire le serveur MCP

Objectif : Transformer les schémas en un serveur en fonctionnement auquel tout client MCP peut se connecter.

1. Implémentez chaque outil derrière un serveur conforme à MCP (SDK TypeScript ou Python).
2. Choisissez votre transport selon le cas d'usage :

3. Intégrez la sécurité dès le premier jour :
   • Les outils à effets de bord doivent prendre en charge un mode dry_run (renvoie ce qui se passerait) et un mode commit (exécute l'action).
   • Les opérations destructrices exigent une étape de confirmation humaine avant que commit ne se poursuive.
4. Validez l'interopérabilité avec au moins deux clients MCP (par ex. Claude Desktop + VS Code Copilot). Si tous deux peuvent découvrir et appeler correctement chaque outil, le serveur est prêt.

Livrable : Un serveur MCP déployé (ou exécutable localement) avec des tests d'intégration réussis face à deux clients.

Critère de sortie : Les deux clients peuvent accomplir de bout en bout une tâche réaliste en plusieurs étapes en n'utilisant que les outils exposés.

Phase 3 : Brancher un framework d'agents

Objectif : Prouver que le serveur MCP fonctionne avec un vrai agent. Choisissez un seul framework pour commencer.

Choisissez le framework qui correspond à la pile de votre équipe :

Construisez deux choses :

1. Un workflow déterministe : une séquence fixe d'appels d'outils (par ex. « rechercher, extraire, résumer »). Cela valide que les outils se composent correctement.
2. Un agent libre : les mêmes outils, mais c'est le LLM qui décide du plan à l'exécution. Cela met vos schémas à l'épreuve : si l'agent choisit le mauvais outil ou transmet de mauvaises entrées, vos descriptions ou vos messages d'erreur ont besoin d'être retravaillés.

En option, répétez avec un second framework pour confirmer que le serveur MCP est réellement agnostique au framework.

Livrable : Un agent fonctionnel (workflow + libre) qui accomplit de vraies tâches en utilisant le serveur MCP.

Critère de sortie : L'agent accomplit ≥ 80 % des tâches de test sans intervention humaine.

Phase 4 : Évaluer et itérer

Objectif : Mesurer la qualité avec laquelle les agents utilisent vos outils, et corriger ce qui est cassé.

1. Créez 10 à 20 tâches réalistes avec des sorties de référence attendues (par ex. « Trouver tous les contrats expirant au T2 et résumer les obligations clés »).
2. Faites passer chaque tâche à la fois par le workflow et par l'agent libre. Pour chaque exécution, mesurez :

3. Triez les échecs :
   • Mauvais outil sélectionné : améliorez la description de l'outil.
   • Mauvais paramètres : resserrez le schéma, ajoutez des contraintes enum, améliorez les indications d'erreur.
   • Appel correct, mauvaise interprétation du résultat : simplifiez le format de sortie ou ajoutez un champ summary.
4. Relancez la suite d'évaluation après chaque correction. Suivez l'amélioration au fil des itérations.

Livrable : Une suite d'évaluation (automatisée, ré-exécutable) et un journal des modifications de schémas avec les taux de réussite avant/après.

Critère de sortie : ≥ 90 % de taux de réussite sur la suite d'évaluation avec les deux modes d'agent.

Phase 5 : Durcir et passer à l'échelle

Objectif : Se préparer au trafic de production et au déploiement à l'échelle de l'organisation.

1. Observabilité. Instrumentez le serveur MCP avec du traçage distribué (OpenTelemetry) et de la journalisation structurée. Chaque appel d'outil devrait être traçable, de la requête du client jusqu'au système back-end.
2. Limitation de débit et contrôle d'accès. Décidez qui (quels agents, quels utilisateurs) peut appeler quels outils, et à quel débit.
3. Gouvernance à l'échelle. Si vous prévoyez plusieurs serveurs MCP ou équipes d'agents, adoptez une couche de courtier/fabric (par ex. MuleSoft Agent Fabric) pour :
   • L'application centralisée des politiques.
   • La journalisation d'audit (qui a appelé quoi, quand, avec quelles entrées).
   • La supervision au niveau de la flotte et les coupe-circuits.
4. Documentation. Publiez un catalogue d'outils (descriptions lisibles par un humain, exemples d'appels, limitations connues) pour que d'autres équipes puissent construire des agents face à votre serveur MCP sans avoir à le rétro-concevoir.

Livrable : Un serveur MCP prêt pour la production, avec des tableaux de bord de supervision, des politiques d'accès, et un catalogue d'outils publié.

Critère de sortie : Une équipe qui n'a pas participé à la construction du serveur peut mettre en place un nouvel agent face à lui en n'utilisant que le catalogue et les schémas publics.