MCP et connecteurs : brancher Claude sur vos outils

MCP — Model Context Protocol — est un protocole ouvert, publié par Anthropic fin 2024, 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.

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.

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.

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.