Que fournissent les frameworks et MCP ?
Distinguer le logiciel qui organise un agent du protocole qui le relie à des outils et à des données.
Notre agence doit relier un modèle, des recherches d’offres, un historique et des contrôles. Faut-il tout programmer ? Et si un fournisseur propose déjà un serveur MCP, que reste-t-il à construire ?
Le framework aide à organiser l’agent. MCP standardise certains échanges avec les systèmes auxquels l’application se connecte. Ils répondent à deux besoins différents et peuvent être utilisés ensemble.
Le framework fournit des composants réutilisables
Un framework d’agents est un ensemble de composants logiciels pour construire et exécuter des agents. Selon le framework, il prend en charge la boucle d’appels au modèle, l’exécution des outils, l’état de la conversation ou les points de validation humaine. Cela évite de réécrire ces mécanismes pour chaque projet.
Ce n’est pas un nouveau LLM. Le développeur choisit un modèle compatible, fournit les instructions, configure les outils et définit les règles de l’application.
Trois exemples permettent de situer les noms rencontrés dans ce cours :
- Google ADK fournit une structure pour définir des agents, leurs outils et leurs workflows, ainsi que des moyens de les tester et de les évaluer.
- LangChain Deep Agents assemble des capacités comme la gestion du contexte, l’accès aux fichiers, les sous-agents et les validations humaines. Il s’appuie sur LangChain et le moteur d’exécution LangGraph.
- Microsoft Agent Framework fournit des agents, des workflows, des sessions et des intégrations avec des modèles et des outils.
Ces solutions se recouvrent en partie ; ce ne sont pas trois couches à empiler. Les capacités disponibles et leurs réglages varient selon la version. Pour une petite boucle bien délimitée, du code direct peut aussi suffire.
MCP définit une façon commune de communiquer
MCP, pour Model Context Protocol, est un protocole ouvert : il définit des règles et des formats d’échange entre une application d’IA et des programmes qui lui proposent des capacités. Il ne choisit ni la mission ni la prochaine action du modèle.
La documentation officielle de MCP distingue trois participants. L’hôte est l’application d’IA. Elle utilise un client MCP, composant logiciel chargé de communiquer avec un serveur MCP. Ce serveur est un programme, local ou distant, qui expose des capacités.
Un serveur peut notamment fournir :
- des outils (tools) : des fonctions à appeler, comme rechercher des hôtels ;
- des ressources (resources) : des contenus à consulter, comme les conditions d’une offre ;
- des modèles de prompts (prompts) : des messages réutilisables, comme une trame de comparaison de séjours.
Ce ne sont pas trois types d’agents. Un serveur peut n’exposer qu’une partie de ces capacités, et une application doit prendre en charge celles qu’elle veut utiliser.
Suivre une recherche d’hôtel
Imaginons un fournisseur qui expose un outil de recherche via MCP. L’application obtient sa description et les paramètres attendus, puis peut le proposer au modèle parmi les outils autorisés.
Le modèle demande une recherche à Agadir pour certaines dates. Après les contrôles prévus, le client transmet l’appel au serveur MCP. Celui-ci interroge le service d’offres et retourne un résultat ou une erreur. L’application fournit le résultat utile au modèle pour poursuivre la comparaison.
MCP ne remplace donc pas nécessairement l’API, l’interface logicielle du fournisseur : le serveur peut l’utiliser en arrière-plan. Sans MCP, l’application pourrait appeler cette API par un outil intégré directement. L’intérêt du protocole est de réutiliser une interface commune entre applications et serveurs compatibles, pas de rendre toute intégration automatique.
La connexion ne garantit ni les droits ni le résultat
Un outil de réservation visible n’est pas une autorisation de réserver. Notre mission reste une comparaison. La spécification MCP impose aux serveurs des contrôles d’accès et la validation des entrées ; elle recommande aussi des confirmations pour les opérations sensibles et la vérification des résultats côté client.
Ces mécanismes doivent être effectivement mis en œuvre. Le développeur reste responsable du choix des serveurs, des permissions, des données transmises et des vérifications. Un résultat reçu par MCP peut être incomplet ou erroné, comme celui de tout autre outil.
À retenir : le modèle produit des réponses et des demandes d’action ; le framework aide à organiser leur traitement ; MCP fournit un langage commun pour certaines connexions. Aucun des trois ne garantit à lui seul que la mission est correctement accomplie.