Au chapitre précédent, nous avons fait tourner un agent minimal qui relie des outils à son cerveau (LLM) et fait tourner lui-même la boucle. Cette première expérience vous l'a montré : la puissance réelle d'un agent se joue presque entièrement dans « à quels outils il est relié ». Dans ce chapitre, on sort de l'usure qu'il y a à réinventer ces outils à chaque fois, et on apprend à se relier de façon standard aux outils et données externes grâce à un standard commun : MCP (Model Context Protocol). Né avec Claude, MCP est en passe de devenir le standard de connexion adopté par toute l'industrie.
L'objectif : « se relier en sécurité par un standard commun, sans fabriquer ses outils »
Pourquoi la connexion d'outils est le nerf de l'agent
Le LLM en lui-même, aussi intelligent soit-il, ne sait rien faire d'autre que « produire des mots ». Connaître le stock actuel, écrire une ligne dans un fichier — sans moyen de toucher au monde extérieur, c'est impossible. Si l'agent peut faire tourner la boucle « chercher, exécuter, vérifier », c'est uniquement parce qu'il possède des outils qui agissent sur l'extérieur.
Autrement dit, le plafond de capacité d'un agent est déterminé par la qualité et le nombre des outils qui lui sont reliés. À LLM égal, un agent qui n'a qu'une calculatrice et un agent relié à une base de données, à un moteur de recherche, aux fichiers et aux API internes ne peuvent pas du tout les mêmes choses. Il n'est pas rare que relier de bons outils au bon endroit fasse davantage progresser la capacité ressentie que de changer le cerveau pour un meilleur.
💡 Plutôt « bien outillé » qu'« intelligent ». Même une personne brillante ne peut rien faire avec une boîte à outils vide. Une grande partie du temps de développement d'agents est en réalité consacrée à la conception de « quel outil donner, et comment le donner en sécurité ». Ce chapitre en est le cœur.
Les limites des définitions d'outils artisanales
Au chapitre précédent, on a défini les outils à la main. Écrire une fonction, passer nom, arguments et description au LLM, l'exécuter à la réception d'un appel et renvoyer le résultat — ce flux lui-même est correct, et reste la base aujourd'hui. Le problème, c'est de le refabriquer à chaque fois, pour chaque outil, pour chaque projet.
Prenons par exemple un « outil qui interroge une base de données ». Écrire la connexion, monter la requête, formater les résultats, gérer les erreurs, manier les identifiants en sécurité… Cet ensemble, votre projet, l'équipe d'à côté et un autre langage l'implémentent chacun de leur côté. La réalité des définitions d'outils artisanales, c'est que le même outil est réinventé encore et encore par des développeurs du monde entier.
Un outil écrit pour un projet est lié à ce framework, à ce langage, et difficile à emporter ailleurs.
Relier M types d'outils à N plateformes d'agents demande en théorie N×M codes de connexion.
Chaque fois que la spécification d'une cible change, il faut corriger un à un les outils maison éparpillés partout.
Cela ressemble beaucoup à l'époque où chaque périphérique exigeait son propre câble. Une prise dédiée pour l'imprimante, une autre pour la souris — plus les appareils se multiplient, plus les types de branchement explosent. Avec une « prise commune », toute cette corvée disparaît d'un coup. C'est là qu'entre en scène MCP.
Qu'est-ce que MCP — le standard commun de connexion d'outils
MCP (Model Context Protocol) est un standard ouvert pour relier l'IA aux outils et données externes de façon standardisée. Anthropic l'a publié fin 2024 pour Claude, puis divers outils et services d'IA l'ont adopté. En 2026, il est largement adopté au-delà des éditeurs et grandit, sous une gouvernance neutre, en un standard de l'industrie. Point essentiel : ce n'est pas le produit d'une seule entreprise, mais une spécification commune que chacun peut implémenter.
En un mot, l'idée de MCP est « l'USB de la connexion d'outils IA ». De même que l'arrivée de l'USB a permis d'utiliser le périphérique de n'importe quel fabricant avec la même prise, un outil compatible MCP est « il suffit de le brancher pour l'utiliser » avec n'importe quel agent compatible MCP. Créateurs et utilisateurs suivant les mêmes conventions, l'enfer combinatoire N×M se replie en « N + M ».
L'agent que vous construisez, ou une application comme Claude, se trouve ici. C'est celui qui interroge le serveur « quels outils sont connectés en ce moment ? » et appelle les outils voulus.
Celui qui expose des fonctions comme « outils » : opérations sur fichiers, requêtes BD, intégrations SaaS. Un seul serveur peut porter plusieurs outils.
Les deux dialoguent selon une procédure établie. Quand le client se connecte, il reçoit d'abord du serveur « la liste des outils disponibles » et « la description et les arguments de chacun ». Le LLM consulte cette liste, choisit l'outil adapté à l'objectif et l'appelle, le serveur l'exécute et renvoie le résultat — que cet aller-retour se fasse sans implémentation individuelle par outil, voilà le nerf de MCP.
Client → Serveur : « Dis-moi quels outils sont disponibles » Serveur → Client : « search_docs / read_file / query_db, voici leurs descriptions » Le LLM décide : « Appelons query_db avec l'argument {sql:"..."} » Client → Serveur : « Exécute query_db » Serveur → Client : « Voici les lignes de résultat »
Il y a principalement 2 modes de publication. Le mode local, où le serveur tourne comme un processus sur votre machine, et le mode distant, auquel on se connecte via le réseau. Le local convient à vos fichiers ou à une BD de développement, le distant aux intégrations SaaS partagées en équipe. Dans les deux cas, la convention « recevoir la liste des outils et les appeler » est identique, et le maniement côté client change à peine.
📖 D'abord la vue d'ensemble. Lire d'abord l'article « Qu'est-ce que MCP », qui clarifie en douceur la genèse, le vocabulaire et l'état de compatibilité, fera entrer sans effort le propos de ce chapitre. Les détails de la spécification et les versions évoluant vite, vérifiez toujours la dernière version dans la doc officielle avant d'implémenter.
Utiliser et créer des serveurs MCP
Le meilleur atout de MCP, c'est de pouvoir utiliser tels quels des serveurs déjà publiés dans le monde. Les outils courants, quelqu'un les a en général déjà préparés sous forme de serveur MCP. En les connectant à votre agent maison, sa capacité augmente d'un coup, sans réinventer la roue.
Lecture-écriture d'un dossier donné. La base pour faire lire des documents ou écrire des livrables.
Exécution SQL et lecture du schéma. À « fais l'agrégation », il peut répondre en interrogeant les données réelles.
Recherche web ou dans la base de connaissances interne. Devient la « main qui enquête » pour ramener infos récentes et justifications.
Gestion de tickets, messagerie, stockage… Transformer les outils métier existants en mains et pieds de l'agent.
La procédure de connexion elle-même est simple. Il suffit de démarrer le serveur voulu (ou d'indiquer son URL), et d'enregistrer dans la configuration côté client l'emplacement du serveur et les identifiants. Ensuite, l'agent reçoit la liste des outils à la connexion et les appelle au besoin. Vous n'avez pas à écrire « l'intérieur de l'outil de requête BD ». Votre travail devient de combiner les outils fournis selon l'objectif.
⚠️ « Tout connecter parce que c'est pratique » est à proscrire. Chaque serveur ajouté augmente d'autant les descriptions passées au LLM, disperse son jugement et élargit la place pour l'erreur. La base : ne connecter que les outils réellement nécessaires à l'objectif de cet agent. Trop d'outils fait au contraire baisser la précision.
On peut aussi créer son propre serveur
Un outil sans serveur tout fait — une API interne maison, une logique métier particulière — il suffit d'écrire soi-même un serveur MCP. C'est là toute la beauté de MCP : une fois publié comme serveur, il s'utilise de la même manière depuis n'importe quel agent compatible. Un outil créé pour un projet se réutilise sans réécriture dans le suivant, ou dans un autre agent de l'équipe.
Créer un serveur consiste à « définir la fonction voulue comme un outil, en déclarer nom, arguments et description, et, à l'appel, exécuter le traitement et renvoyer le résultat ». L'idée est la même que la définition d'outil artisanale du chapitre précédent, mais avec une différence décisive : la sortie ne vise plus « un agent particulier » mais « la prise commune qu'est MCP ». L'effort de création est ponctuel, la réutilisation infinie.
🛠 Pour entrer dans l'implémentation. Pour le code concret d'assemblage d'agents et de connexion d'outils avec Claude, Le SDK Claude Agent, pour débuter est très pratique. Le SDK intègre de quoi manier les serveurs MCP : connexion de serveurs tout faits comme création maison se font en suivant la doc officielle.
Quels outils donner, et comment
Une fois qu'on sait « connecter » des outils, la question suivante est « quoi donner, et comment ». C'est ici le nerf de la conception qui décide de la qualité et de la sécurité de l'agent, et le socle des chapitres suivants. Retenons 3 principes.
Ne donner que les outils et l'étendue nécessaires à la tâche. « Si lire suffit, ne pas donner le droit d'écriture. » Pour une BD, un compte restreint en lecture ; pour les fichiers, seulement le dossier cible.
Le LLM décide de l'utiliser ou non en s'appuyant sur la seule description. Écrire concrètement « ce que fait l'outil, quand l'utiliser, le sens des arguments, quand ne pas l'utiliser ». Une description vague engendre le mésusage.
Écriture, suppression, facturation, exécution de commandes… les opérations irréversibles ne se placent pas au même rang que la lecture. Toujours y adjoindre confirmation avant exécution, restriction de cible et journalisation.
Le ③ est particulièrement important. Les outils « qui enquêtent » (recherche, consultation, lecture), même appelés par erreur, causent rarement de gros dégâts. En revanche, les outils « qui modifient » (écriture, suppression, envoi, exécution) : une seule erreur peut produire un résultat irréversible. La règle d'or : séparer consciemment lecture et écriture, et empiler des gardes sur les seconds.
| Type | Exemples | Risque | Comment le donner |
|---|---|---|---|
| Lecture | Recherche, consultation, lecture de fichier | Plutôt faible (attention au maniement des infos) | Assez librement. Restreindre l'étendue |
| Écriture | Mise à jour de fichier, écriture BD, envoi | Élevé (difficile à annuler) | Confirmation, restriction et journalisation obligatoires |
| Exécution | Exécution de commandes, appels externes, facturation | Maximal (porte d'entrée du dérapage et de l'abus) | En principe garde + validation humaine |
🔒 Nous traiterons cela à fond au chapitre 6. Le contrôle des outils dangereux, la parade à l'injection de prompt, la conception des flux de validation sont des thèmes incontournables pour mettre un agent en production. Le chapitre 6, « Garde-fous et sécurité » les traite ensemble ; dans ce chapitre, retenez seulement le sens qu'« il existe des degrés de dangerosité entre les outils ». Ne pas connecter à la légère un serveur MCP peu fiable est aussi une habitude importante.
Les outils avancés, comme le pilotage de navigateur
Parmi les outils, l'un des plus remarqués ces dernières années est le pilotage de navigateur. Voir l'écran, suivre les liens, remplir les formulaires, cliquer sur les boutons — si l'on peut confier à l'agent ce qu'un humain fait dans un navigateur, de nombreux services web sans API dédiée deviennent des « mains et pieds ». Des implémentations exposant le pilotage de navigateur en serveur MCP sont apparues, et la barrière à la connexion a baissé.
Cela dit, c'est aussi l'un des outils les plus puissants et les plus risqués. Le danger de prendre pour argent comptant les instructions affichées à l'écran (manipulation, fausses informations), les clics ou envois non voulus, l'exposition des identifiants — les précautions du « type exécution » de la section précédente s'appliquent à la lettre. Il est sage de commencer par des usages plutôt en lecture, comme la consultation et la récupération d'informations, et de n'entourer les opérations d'écriture de gardes qu'avec prudence.
🌐 Jusqu'où peut-on lui déléguer ? La capacité réelle et les limites des agents de pilotage de navigateur sont vérifiées concrètement dans Jusqu'où l'IA peut-elle automatiser les tâches de navigateur. Garder en tête la juste distance — « pas universel, mais utilisable si l'on restreint l'usage » — évite les décisions hasardeuses dans le choix des outils.
Navigateur ou non, plus un outil est avancé, plus « ce qu'il peut faire » et « ce qui peut arriver » grandissent de pair. Plus l'outil confié est puissant, plus il faut appliquer avec soin les 3 principes : permission, description, garde — c'est le message répété tout au long de ce chapitre.
- La capacité d'un agent se joue dans la qualité et le nombre des outils reliés. Souvent, la conception des outils pèse plus que le cerveau.
- Fabriquer ses outils à la main est difficile à réutiliser et mène à l'enfer combinatoire N×M. On en vient à vouloir une prise commune.
- MCP est un standard ouvert qui relie l'IA aux outils externes de façon standard. Un « USB de l'IA » où client (celui qui utilise) et serveur (celui qui fournit) dialoguent selon les mêmes conventions.
- On peut brancher et utiliser des serveurs MCP tout faits (fichiers/BD/recherche/SaaS), et rendre ses outils maison réutilisables via un serveur maison.
- Les principes pour donner un outil : ① minimiser les permissions ② soigner les descriptions ③ traiter à part les outils dangereux. Plus l'outil est puissant (pilotage de navigateur), plus de prudence.
Une fois qu'on sait garnir la boîte à outils, l'étape suivante est de « multiplier les agents ». On passe à une conception où le travail qu'un seul agent ne peut porter est réparti et coordonné entre plusieurs. Au chapitre 4, « Conception multi-agent », apprenons la répartition des rôles et la coordination entre agents (A2A).