MCP et connecteurs : brancher Claude sur vos outils

MCP — Model Context Protocol — est un protocole ouvert, publié par Anthropic fin 2024 et confié depuis à une fondation indépendante, qui permet de brancher Claude sur vos outils : un connecteur MCP expose à l’IA les données et les actions d’une application — CRM, gestion de tickets, drive, base documentaire — de façon standardisée. Une fois le connecteur en place, Claude lit vos données réelles et agit dans vos outils, au lieu de raisonner sur ce qu’on veut bien lui coller dans la conversation.

Avant MCP, chaque intégration était un développement spécifique : un pont par outil, par usage, à maintenir. Le protocole remplace cette multiplication par un standard unique — comparable à ce que l’USB a fait pour les périphériques : un seul port, des milliers d’appareils. La question n’est plus « peut-on connecter cet outil ? » mais « que veut-on que Claude y fasse ? ».

Ce que le copier-coller vous coûte vraiment

Sans connecteurs, l’IA la plus capable du marché travaille les yeux bandés. L’utilisateur exporte, colle, reformule, recolle le résultat dans l’outil d’origine — et recommence à la prochaine tâche. Ce ballet a trois coûts : du temps, des erreurs de transcription, et surtout un plafond d’usage. Les tâches qui demanderaient de croiser trois sources ne sont simplement jamais confiées à l’IA, parce que l’assemblage manuel décourage.

Dans les entreprises que nous auditons, c’est le premier écart entre le potentiel et le réel : des licences déployées, des équipes formées — et une IA qui ne voit ni le CRM, ni les tickets, ni les documents. Elle répond bien, mais dans le vide.

Il y a enfin un coût de fiabilité : une donnée collée est une donnée figée. Le compte rendu préparé lundi sur un export de vendredi ignore tout ce qui s’est passé entre les deux. Avec un connecteur, Claude consulte l’état actuel de l’outil au moment de la demande — pas une copie d’écran de la semaine passée.

Que change un connecteur, concrètement ?

Le jour où les connecteurs sont en place, la nature des tâches confiées à Claude change :

• Préparer un rendez-vous client : Claude lit l’historique CRM, les derniers échanges et les tickets ouverts, et produit une fiche de synthèse — sans qu’on lui colle quoi que ce soit.
• Traiter un ticket support : l’IA consulte la base de connaissances et l’historique du client, rédige la réponse, et met à jour le ticket dans l’outil.
• Chercher dans les documents : la question « qu’avons-nous promis à ce client sur les délais ? » interroge le drive et cite le document source, au lieu de reposer sur la mémoire de quelqu’un.
• Croiser les sources : un état des lieux qui combine CRM, tickets et documents devient une requête, plus un après-midi de compilation.

Qui contrôle le protocole ? La question que pose toute DSI

Brancher son système d’information sur un protocole, c’est en accepter la trajectoire. La question revient à chaque comité d’architecture : que se passe-t-il si l’éditeur change d’avis ? Depuis le 9 décembre 2025, la réponse est publique — Anthropic a cédé MCP à l’Agentic AI Foundation, un fonds dirigé hébergé par la Linux Foundation, co-fondé avec Block et OpenAI, puis rejoint par AWS, Google, Microsoft, Cloudflare et Bloomberg. Le protocole y côtoie deux autres briques ouvertes de l’écosystème agentique, goose et AGENTS.md.

La fondation apporte un cadre neutre, pas une tutelle technique : elle annonce explicitement qu’elle ne dictera pas la direction technique de MCP, laissée aux mainteneurs du projet et aux propositions d’évolution de la communauté. Pour une DSI, l’intérêt n’est pas institutionnel, il est contractuel : un connecteur écrit pour MCP cesse d’être un pari sur la stratégie commerciale d’un fournisseur unique.

L’adoption a suivi le même chemin. À la date de cette donation, l’écosystème comptait plus de 10 000 serveurs MCP publiés, et le protocole est pris en charge nativement par les principaux clients du marché — Claude, mais aussi Cursor, Visual Studio Code, Microsoft Copilot, Gemini et ChatGPT. Autrement dit : le connecteur que vous développez pour vos outils internes ne vous enferme pas chez un fournisseur d’IA. C’est, à ce jour, le meilleur argument de réversibilité disponible sur ce marché.

Et la sécurité ? Le périmètre avant la puissance

Brancher l’IA sur les données de l’entreprise impose une discipline. Un connecteur MCP se déploie avec des périmètres explicites : quelles données sont accessibles, à qui, et quelles actions sont permises. Notre doctrine est constante — lecture d’abord, écriture ensuite : on commence par des connecteurs en consultation seule, on n’ouvre les actions d’écriture que process par process, quand l’usage est rodé et le contrôle en place.

Depuis la révision du 28 juillet 2026 — la plus importante depuis la création du protocole — cette discipline n’est plus seulement une bonne pratique de cabinet : elle est écrite dans la spécification. Un serveur MCP y est formellement un serveur de ressources OAuth 2.1. Il doit vérifier que le jeton qu’on lui présente a bien été émis pour lui, et il lui est interdit d’accepter ou de faire transiter un jeton destiné à un autre service. Cette règle ferme la porte au scénario qui inquiète le plus les DSI : un connecteur qui deviendrait un passe-plat vers le reste des applications de l’entreprise.

Le reste de la révision va dans le même sens. Les droits demandés doivent être les plus étroits possibles : un serveur sollicité hors de son périmètre répond par un refus explicite, en nommant les droits manquants — ce qui permet de n’élever les permissions qu’au moment où l’usage l’exige, et non « au cas où ». L’enregistrement dynamique de clients, longtemps le maillon faible des déploiements, y est déprécié au profit d’identités de client publiées à une adresse que le serveur d’autorisation peut vérifier. Traduction côté entreprise : les accès de l’IA se pilotent depuis le fournisseur d’identité déjà en place — mêmes comptes, mêmes révocations, mêmes journaux.

Ces règles relèvent des garde-fous du Harness — la couche d’orchestration entre Claude et vos process : les droits de l’IA y sont définis dans l’architecture, alignés sur les droits existants des utilisateurs, et validés avec la DSI plutôt que contre elle.

La journalisation complète les périmètres : chaque consultation et chaque action passée par un connecteur est tracée — qui a demandé quoi, quelles données ont été lues, ce qui a été modifié. En cas de doute, on rejoue le fil. C’est un niveau d’auditabilité que le copier-coller manuel n’a jamais offert.

Par où commencer ?

Pas par un inventaire exhaustif des connecteurs possibles. Partez d’un process qui fait mal — la préparation des rendez-vous commerciaux, le tri des tickets, la recherche documentaire — et branchez uniquement les deux ou trois sources que ce process exige. Un connecteur utilisé chaque jour vaut mieux que dix connecteurs déclarés dans un schéma d’architecture. Le critère de succès est simple : un utilisateur qui ne voudrait plus revenir en arrière.

Reste une inquiétude légitime : le rythme des évolutions. Un protocole jeune bouge vite, et personne ne veut réécrire ses connecteurs tous les six mois. La révision de juillet 2026 a précisément introduit une politique de dépréciation formelle : une fonctionnalité appelée à disparaître continue de fonctionner au moins douze mois après l’annonce. C’est court à l’échelle d’un SI, mais suffisant pour traiter les montées de version dans un plan de maintenance ordinaire plutôt que dans l’urgence.

C’est l’ordre que nous suivons dans le Programme Autonomie Claude : les connecteurs arrivent au service d’un process précis, avec leurs périmètres, leur pilotage et leurs utilisateurs formés — pas comme une infrastructure en attente d’un usage.