Une équipe produit veut que son assistant de support réponde à « où en est ma commande ? ». Le modèle ne connaît pas vos commandes. Il ne peut pas non plus interroger lui-même votre logiciel de gestion. Il sait seulement demander : « appelle l'outil de suivi avec le numéro 48213 ». Votre application décide ensuite d'exécuter cette demande, ou non. Tout ce qui suit découle de ce partage des rôles.
Un outil, c'est une demande que votre application exécute
Un outil se décrit en trois parties : un nom, une description en langage courant et un schéma qui fixe ses paramètres, comme une sortie structurée. Par exemple : suivre_commande, « renvoie le statut d'une commande à partir de son numéro », un paramètre numero_commande obligatoire. Le modèle reçoit ces définitions avec la question. S'il juge qu'un outil répond au besoin, il ne rédige pas de réponse. Il renvoie une demande d'appel : le nom de l'outil et les paramètres remplis.
Votre application reçoit cette demande. Elle vérifie les paramètres et exécute l'appel. Elle renvoie ensuite le résultat au modèle, qui rédige sa réponse. En octobre 2026, Anthropic et OpenAI décrivent le même échange dans leur documentation : le modèle produit l'appel, l'application l'exécute. Anthropic précise que certains de ses outils s'exécutent chez lui, pas chez vous. On parle aussi d'appel de fonction (function calling).
Ce partage a une conséquence pratique. Le modèle ne décide pas de ce qu'il a le droit de faire. L'application exécute, donc c'est elle qui peut refuser, vérifier les droits de l'utilisateur ou demander une confirmation. Un outil trop large, comme « exécute n'importe quelle commande sur la base de données », laisse tout le contrôle au modèle. Un outil réduit au nécessaire, comme « lis le statut d'une commande », le garde dans votre code.
Un utilisateur demande « où en est ma commande ? ». Le modèle ne connaît pas vos commandes et ne peut pas interroger lui-même votre logiciel de gestion.
La description compte autant que le code. Selon la documentation d'Anthropic, en octobre 2026, le modèle appelle un outil quand la demande correspond à ce que l'outil dit savoir faire. Avec une description vague, l'outil est appelé au mauvais moment, ou jamais.
Concept clé
Un outil est une fonction que votre application met à la disposition du modèle : un nom, une description et un schéma de paramètres. Le modèle ne fait que demander l'appel ; votre application l'exécute. Les droits, les vérifications et les confirmations se fixent donc dans l'application. MCP (Model Context Protocol) standardise la façon de brancher ces outils. Il ne décide pas de ce qu'ils ont le droit de faire.
MCP : une prise commune pour les connecteurs
Avec MCP, chaque logiciel expose une prise commune, avec ses outils, ses ressources et ses modèles d'instructions. Mais un cadenas reste ouvert : MCP standardise la prise, pas la confiance.
Sans standard, chaque assistant demande sa propre intégration pour chaque logiciel. Le CRM est branché pour l'un, puis à nouveau pour l'autre. MCP règle ce problème. En octobre 2026, son site le présente comme un standard open source pour connecter les applications d'IA à des systèmes externes, et le compare à un port USB-C.
Le protocole distingue deux côtés. D'un côté, un serveur MCP expose ce qu'un logiciel sait faire : des outils (créer un ticket), des ressources, c'est-à-dire des données à lire (une fiche client), et des modèles d'instructions. De l'autre, l'application d'IA, que la spécification appelle l'hôte, s'y branche. Un serveur écrit une fois sert à plusieurs assistants. Côté utilisateur, ce branchement s'appelle souvent un connecteur : un accès à vos autres logiciels. La dernière version de la spécification date du 28 juillet 2026.
Le 9 décembre 2025, Anthropic a confié MCP à l'Agentic AI Foundation, créée au sein de la Linux Foundation, selon l'annonce de celle-ci. Amazon Web Services, Anthropic, Google, Microsoft et OpenAI figurent parmi ses membres Platinum. Selon la page de gouvernance du projet, ses responsables techniques y siègent à titre personnel. Aucun siège n'est réservé à une entreprise.
En octobre 2026, selon leur documentation, Claude, ChatGPT, Microsoft Copilot Studio, Gemini Enterprise, Visual Studio Code et Cursor acceptent des serveurs MCP. Les conditions varient. Chez Claude, les connecteurs personnalisés existent dans toutes les offres, mais un compte gratuit n'en a qu'un. Dans Gemini Enterprise, un administrateur branche le serveur MCP personnalisé.
La question arrive donc dans les achats. Un éditeur qui publie un serveur MCP se branche sur les assistants que vous utilisez déjà, sans projet d'intégration. Un outil IA qui accepte MCP atteint vos systèmes sans attendre que son éditeur écrive chaque intégration. Reste à savoir qui, chez vous, peut ajouter un connecteur, et ce que ce connecteur peut faire.
Ce que MCP ne règle pas
MCP standardise la prise, pas la confiance. La spécification le dit : le protocole ne peut pas imposer lui-même ses principes de sécurité. C'est aux applications qui l'utilisent de les appliquer. Ces principes portent sur le consentement de l'utilisateur, la protection de ses données et la prudence face aux outils. Un outil revient à exécuter du code quelconque. L'hôte doit donc obtenir l'accord explicite de l'utilisateur avant d'en appeler un.
Brancher un serveur MCP revient donc à donner un accès, comme on crée un compte pour un prestataire. Trois questions décident du risque : quels outils sont ouverts, sur quelles données, et au nom de qui.
Un connecteur, le moins de droits possible
Le moindre privilège s'applique connecteur par connecteur. L'OWASP, une fondation de référence en sécurité applicative, nomme ce risque « l'agentivité excessive » (excessive agency). Il figure dans son classement 2025 des risques des applications à base de LLM (grand modèle de langage). Elle en donne trois causes : trop de fonctions, trop de droits, trop d'autonomie. Les réglages suivent la même découpe.
- Les fonctions. N'ouvrez que les outils dont la tâche a besoin. Un assistant de support lit le statut d'une commande ; il n'a pas besoin de l'outil qui l'annule. En octobre 2026, le connecteur MCP de l'API d'Anthropic permet de lister les outils autorisés ou interdits d'un serveur, et l'API d'OpenAI permet de restreindre les outils d'un serveur MCP.
- Les droits. Le connecteur agit avec les droits de l'utilisateur, pas avec ceux d'un compte technique qui voit tout. À la connexion, refusez les autorisations larges dont la tâche n'a pas besoin. Les bonnes pratiques de sécurité de MCP recommandent de commencer par un jeu réduit de droits en lecture, puis de les élargir quand une action l'exige.
- L'autonomie. Toute action qui modifie ou envoie quelque chose attend une validation humaine. En octobre 2026, OpenAI recommande de garder la validation pour les outils qui modifient des données. Il prévient qu'une écriture reste possible même si le serveur déclare l'outil en lecture seule.
Les trois sont réduits : toute action qui modifie ou envoie quelque chose attend une validation humaine avant de partir.
Qui possède un connecteur
Un connecteur ouvre un système. Son propriétaire est donc l'équipe qui répond de ce système, pas l'équipe qui déploie l'IA : la finance pour la comptabilité, le support pour l'outil de tickets. Elle approuve les outils ouverts et les droits accordés. Elle relit les descriptions, suit les journaux et retire l'accès quand il ne sert plus.
Plusieurs éditeurs réservent l'ajout aux administrateurs. En octobre 2026, dans l'offre Team de Claude, seuls les propriétaires de l'organisation peuvent ajouter un connecteur personnalisé. Dans l'offre Enterprise, il faut être propriétaire ou avoir un rôle qui l'autorise. Pour Copilot Studio, Microsoft rappelle que l'entreprise répond des outils et des ressources qu'elle utilise sur un serveur MCP.
Tenez un inventaire simple. Pour chaque connecteur : son propriétaire, ses outils ouverts, en lecture ou en écriture, le compte utilisé et la date de la dernière revue. C'est la liste qu'un auditeur, un client grand compte ou votre équipe sécurité vous demandera.
Quatre risques propres aux connecteurs
- Un serveur non fiable. Un serveur MCP installé sur un poste est un programme qui tourne sur ce poste, avec les mêmes droits que l'assistant. Un serveur distant reçoit les données que l'assistant lui envoie. En octobre 2026, Anthropic recommande de ne brancher Claude que sur des serveurs conçus et hébergés par des organisations de confiance. OpenAI rappelle que les serveurs MCP personnalisés ne sont ni développés ni vérifiés par lui. Le registre officiel de MCP recense des serveurs ; sa page d'accueil n'annonce aucun contrôle de sécurité.
- L'empoisonnement d'outil. En avril 2025, la société de sécurité Invariant Labs a décrit des instructions malveillantes cachées dans la description d'un outil. L'utilisateur ne les voit pas ; le modèle les lit. Variante : le serveur modifie la description après votre accord. Or certains hôtes répercutent ces changements seuls. En octobre 2026, Copilot Studio met à jour les outils d'un agent quand le serveur MCP les modifie. La spécification demande de traiter les descriptions comme non fiables, sauf si elles viennent d'un serveur de confiance.
- L'injection par le résultat d'un outil. Le résultat d'un appel est du contenu que le modèle lit : un e-mail, un ticket, une page web. S'il contient des instructions, le modèle peut les suivre. C'est l'injection de prompt indirecte, décrite dans la page Les garde-fous.
- Les données qui sortent par un outil. Selon OpenAI, en octobre 2026, tout serveur MCP peut recevoir des données sensibles lors d'un appel. Un outil qui envoie un e-mail ou appelle une adresse web est aussi une porte de sortie. La page Les agents décrit la combinaison à éviter, le « tiercé fatal » (lethal trifecta) : données privées, contenu non fiable et capacité d'envoyer vers l'extérieur.
Ce que ça change pour vous
Pour les product managers
Spécifiez chaque outil comme une fonctionnalité : ce qu'il fait, ce qu'il ne fait pas, et si son action attend une validation. Préférez plusieurs outils réduits au nécessaire à un outil qui fait tout. Écrivez les descriptions avec l'équipe technique. Testez-les sur de vraies demandes : celles qui doivent appeler l'outil et celles qui ne le doivent pas. Les évals (pour « évaluations ») d'un assistant vérifient aussi les outils appelés.
Pour les tech leads
Validez chaque appel dans le code avant de l'exécuter : schéma, droits de l'utilisateur, montants plafonnés. Activez l'option stricte quand l'API la propose. Pour un serveur MCP, n'ouvrez que les outils listés, demandez les droits minimaux et figez la version du serveur. Relisez ses descriptions à chaque mise à jour. Traitez chaque résultat d'outil comme une donnée non fiable. Enregistrez chaque appel avec ses paramètres et l'identité de l'utilisateur. Dans un agent de code, un hook (une commande exécutée automatiquement à un moment fixé) peut bloquer un appel d'outil par une règle écrite dans le code : en octobre 2026, Claude Code le permet, y compris pour les outils MCP.
Pour les dirigeants
Décidez qui a le droit d'ajouter un connecteur, et faites-le écrire. Chaque connecteur a un propriétaire du côté du système qu'il ouvre. Lors d'un achat, posez quatre questions à l'éditeur. Son outil accepte-t-il les connecteurs MCP ? Peut-on restreindre les serveurs autorisés ? Peut-on limiter les outils et exiger une confirmation pour les écritures ? Où sont les journaux ? Sans réponse claire, l'outil ouvre vos systèmes sans que vous sachiez comment.
L'erreur classique
fAIling RÈGLE XIII
Le piège : Supprimez les garde-fous. Allez vite.
Le connecteur marche en démo, alors on ouvre tous ses outils, avec un compte qui voit tout, et on coche « toujours autoriser » pour ne plus être interrompu. Chaque confirmation supprimée est une action que plus personne ne relit. Le premier e-mail piégé que lit l'assistant peut alors s'en servir. Fixez les outils, les droits et les validations au moment de brancher le connecteur, pas après le premier incident.
Lire la règle XIII du manifesteÀ essayer
Maintenant. Ouvrez les réglages de l'assistant IA que vous utilisez le plus et listez ses connecteurs. Pour chacun, notez ce qu'il peut lire, ce qu'il peut modifier ou envoyer, et avec quel compte.
Cette semaine. Choisissez le connecteur le plus large. Avec la personne qui répond du système concerné, désactivez un outil qui ne sert pas, ou remplacez une autorisation permanente par une confirmation. Notez qui est désormais propriétaire de ce connecteur.
Autour du sujet
Pour aller plus loinConnecteurs, skills et plugins
Un connecteur donne un accès : lire le CRM, créer un ticket. Un skill donne la méthode pour se servir de cet accès dans une tâche précise. Un plugin peut regrouper les deux. La page Skills et plugins : du savoir-faire à la demande détaille ce que contient un skill, qui l'écrit et qui le relit.
Les deux ensemble : le connecteur donne accès au système, le skill donne la méthode, c'est-à-dire comment se servir de cet accès pour une tâche donnée.
Pour aller plus loinTrop d'outils coûte cher
Les définitions des outils font partie de chaque requête envoyée au modèle, et elles se paient. Selon la documentation d'Anthropic, en octobre 2026, les noms, descriptions et schémas des outils sont facturés comme des tokens d'entrée (un token est un fragment de texte, souvent un morceau de mot). Un serveur MCP dont les cinquante outils sont ouverts les envoie tous, même pour une question simple. Anthropic propose un outil de recherche qui charge les définitions à la demande. Le plus simple reste de n'ouvrir que les outils utiles, dans le harnais (harness) : tout ce qui entoure le modèle dans un produit.
Pour aller plus loinUn serveur MCP local s'exécute sur votre poste
Un serveur MCP peut tourner sur le poste de l'utilisateur ou chez un hébergeur. Les bonnes pratiques de sécurité de MCP rappellent qu'un serveur local est un programme téléchargé et exécuté sur la même machine que l'assistant. Avant d'installer un serveur, l'application doit afficher la commande exacte et obtenir l'accord explicite de l'utilisateur. Elle doit aussi faire tourner le serveur dans un environnement isolé, avec un minimum de droits. Pour une entreprise, la règle pratique est celle de n'importe quel logiciel : une liste de serveurs approuvés, installés depuis une source connue, dans une version figée.
Quoi en faire
Placez les droits, les vérifications et les confirmations dans votre application, pas dans les consignes du modèle.
Préférez plusieurs outils réduits au nécessaire à un seul qui fait tout, et soignez chaque description : c'est elle qui décide quand l'outil est appelé.
MCP standardise la prise, pas la confiance : ouvrez chaque connecteur avec le moins de droits, et confiez-le à l'équipe qui répond du système.