Piloter son CRM depuis Claude ou ChatGPT : ce que le MCP casse

Un agent connecté en MCP peut chercher dans votre CRM, y écrire et déclencher un envoi. Le protocole ne hiérarchise pas ces trois gestes : il expose des outils, le schéma de leurs arguments et quelques indications de comportement, puis laisse le client décider. CRMArena-Pro, le benchmark publié par Salesforce AI Research le 24 mai 2025, mesure environ 58 % de réussite en un tour sur des tâches CRM, et 35 % à plusieurs tours.

La règle pratique tient en deux lignes. Un agent mène seul ce qui est réversible et désigné sans ambiguïté : chercher, lire un historique, créer une note, avancer une affaire. Ce qui est irréversible ou massif se confirme, et le serveur doit exiger cette confirmation : envoi, import, fusion de doublons, suppression, changement du modèle de données.

Le protocole ne trace pas cette frontière. La NSA écrit dans sa fiche de mai 2026 sur le Model Context Protocol que rattacher une session à une identité n'y est pas défini, que les composants peuvent être configurés sans contrôle d'accès, et que beaucoup d'implémentations omettent l'authentification.

Ce qu'un agent réussit dans un CRM, et où il s'effondre

Le détail de CRMArena-Pro déplace le problème. Sur l'exécution de processus, où la cible est nommée et la procédure connue, les meilleurs agents dépassent 83 % en un tour. Le taux global tombe à 35 % quand il faut poser une question pour combler un manque. L'agent n'échoue pas à écrire, il échoue à savoir sur quoi écrire.

Le même article ajoute une observation moins commentée : les agents testés ne montrent quasiment aucune conscience des règles de confidentialité, et les y sensibiliser par le prompt dégrade leur performance. Un agent qui a la main sur un CRM ne se retient pas seul, et lui apprendre à se retenir lui coûte sa précision.

Trois trajets décrivent l'usage. Trouver : l'agent lit et croise, et c'est là qu'il sert le plus. Écrire : il crée et met à jour, tant que la cible est désignée sans équivoque. Envoyer : l'effet sort du CRM, et l'erreur n'est plus rattrapable. Trois trajets, trois niveaux d'autorisation, que le CRM doit encoder quelque part.

Pourquoi un CRM « avec une API » n'est pas un CRM pilotable par un agent

Une API REST suppose qu'un développeur ait lu la documentation, choisi les points d'entrée et écrit le mapping. Le MCP fait entrer cette documentation dans la session : le serveur renvoie ses outils, le schéma JSON de leurs arguments et une description en langage naturel. La carte de votre CRM devient un document, et non plus du code.

La révision du 28 juillet 2026 de la spécification a rendu le protocole sans état. Elle supprime la poignée de main d'initialisation et l'identifiant de session, porte le routage par les en-têtes Mcp-Method et Mcp-Name, et rend les listes d'outils cachables par ttlMs et cacheScope. La carte se mémorise et sert plusieurs tours.

Dans un CRM où objets et champs se configurent par organisation, cette description se génère par espace de travail, sinon l'agent raisonne sur un schéma qui n'est pas le vôtre. La révision du 25 novembre 2025 avait d'ailleurs ajouté des recommandations de nommage des outils, signe que la confusion vient de la pratique.

Les quatre choses que le MCP casse

Une fois la carte lue, quatre défauts apparaissent, aucun n'étant un bug d'implémentation. Quatre responsabilités que la spécification laisse au serveur : nommer sans ambiguïté, borner l'échelle d'un appel, réappliquer les droits de la personne connectée, rattacher la session à une identité.

L'ambiguïté de schéma

Deux champs nommés statut, l'un sur le contact, l'autre sur l'affaire, suffisent. Le modèle choisit sur la foi d'un libellé, et un choix erroné écrit une valeur plausible au mauvais endroit. Le CRM ne verra pas d'erreur, puisque la valeur est du bon type. Le remède : des noms qui portent leur objet, et une introspection du schéma avant d'écrire.

Les écritures en masse

Le protocole ne distingue pas un appel qui touche un enregistrement d'un appel qui en touche deux cents. Seule une annotation les distingue, destructiveHint. Le blog officiel du Model Context Protocol rappelle le 16 mars 2026 que les annotations ne décrivent pas fidèlement le comportement d'un outil, et que les clients doivent les traiter comme non fiables tant qu'elles ne viennent pas d'un serveur de confiance.

Le périmètre de permissions

Le jeton d'un serveur MCP n'a aucune raison d'avoir le périmètre exact de la personne connectée. Asana a lancé son serveur MCP le 1er mai 2025 et découvert le 4 juin un défaut d'isolation entre organisations. Environ 1 000 clients ont été potentiellement exposés selon les avis de l'éditeur relayés par BleepingComputer : tâches, commentaires et fichiers lisibles d'un locataire à l'autre.

Le cas Supabase documenté par Simon Willison le 6 juillet 2025 montre comment ce défaut devient fatal. Un ticket de support portait des instructions cachées, que l'agent a exécutées en lisant la file. L'injection était le vecteur ; ce qui l'a rendue exploitable est le rôle utilisé, une clé de service à laquelle la sécurité au niveau des lignes ne s'appliquait pas.

L'identité, que le protocole ne définit pas

Reste le point relevé par la NSA. Censys a recensé 12 520 services MCP joignables depuis internet au 28 avril 2026, sur 8 758 adresses IP, et précise que ceux qu'il décrit étaient sans authentification. Wiz a publié le 28 juillet 2026 qu'environ 70 % des serveurs exposés livrent leur catalogue d'outils à un appelant anonyme, et 42 % des données réelles.

Les révisions récentes referment une partie du trou. Depuis le 18 juin 2025, la spécification classe les serveurs MCP comme Resource Servers OAuth 2.0 et leur ajoute des métadonnées de ressource protégée. Celle du 25 novembre 2025 aligne cette découverte sur la RFC 9728 et ajoute le consentement de portée incrémental par l'en-tête WWW-Authenticate. Les deux décrivent comment authentifier, pas comment forcer un serveur déployé sans.

Le garde-fou que le protocole laisse au serveur

Ces quatre défauts se recoupent sur une opération manquante : rendre une action irréversible impossible sans accord explicite, et cet accord vérifiable ailleurs que dans le client. Beaucoup de clients affichent une boîte de dialogue quand destructiveHint vaut vrai. Bon réflexe, mauvaise garantie : la décision d'afficher appartient au client.

La forme qui tient est un aperçu qui engage. Le premier appel n'exécute rien : il renvoie ce qui va se passer et un jeton lié à l'empreinte exacte de l'opération. Le second répète ce jeton, à usage unique et de durée courte, et le serveur refuse sinon. Un accord donné pour un email ne peut pas servir à en envoyer un autre.

Le protocole s'en rapproche. L'elicitation, introduite le 18 juin 2025, permet au serveur d'interrompre l'exécution pour demander une information par un schéma JSON. La révision du 28 juillet 2026 la remplace par les requêtes à plusieurs allers-retours : le serveur répond resultType input_required, et le client rejoue l'appel. Rien n'oblige un éditeur à s'en servir pour les écritures irréversibles.

Rien de tout cela n'est propre à un éditeur. Un jeton lié par empreinte tient en quelques dizaines de lignes ; sa vraie difficulté est de décider ce qu'il fait quand le magasin qui le garde tombe. Un garde-fou qui laisse passer pendant une panne est un réglage, pas une règle.

Quels CRM exposent un serveur MCP, au 6 septembre 2026

Le tableau change vite, et une affirmation sur un concurrent ne vaut que datée. Voici ce que la documentation publique de chaque éditeur indique au 6 septembre 2026, avec la page qui le dit. Les dates sont celles de la disponibilité générale, pas d'une bêta.

• Salesforce : serveurs MCP hébergés en disponibilité générale le 29 avril 2026 selon le blog développeurs, pour toute organisation Enterprise Edition et au-dessus, avec des serveurs standards pour Agentforce 360, Tableau Next et Data 360 SQL. Le serveur MCP Data 360 dédié n'est, lui, qu'en developer preview depuis mai 2026.
• HubSpot : serveur MCP distant en disponibilité générale le 13 avril 2026 selon le changelog développeurs, lecture et écriture sur les objets CRM et les engagements, lecture seule sur le marketing, sans accès aux propriétés sensibles. Sur developers.hubspot.com/ai-tools/mcp.
• Pipedrive : serveur MCP natif annoncé le 30 juin 2026 en salle de presse, sur tous les plans avec des quotas de jetons, connexion OAuth, périmètre borné aux droits de l'utilisateur, journal des actions. Sur pipedrive.com/en/features/mcp-server.
• Attio : serveur MCP hébergé annoncé au changelog le 19 février 2026, authentifié comme l'utilisateur par OAuth. Sur docs.attio.com/mcp/overview.
• Kasar : serveur MCP exposé en lecture et en écriture.

Ce que le tableau ne dit pas est plus instructif. Attio est le seul à écrire que ses lectures sont auto-approuvées et que ses écritures demandent une confirmation. Aucune page ne dit lesquelles, ni si le refus vient du serveur ou du client. Pipedrive documente les droits de l'utilisateur et un journal, jamais un point d'arrêt avant exécution.

Ce qui se passe quand vous collez une URL dans Claude ou ChatGPT

Brancher un CRM sur un assistant tient en trois gestes : coller l'adresse du serveur, passer un consentement OAuth, choisir l'espace de travail. Le client interroge la liste des outils et la tient à disposition. Depuis la révision du 25 novembre 2025, ce consentement peut être incrémental : le serveur réclame une portée supplémentaire quand elle devient nécessaire, par l'en-tête WWW-Authenticate.

Ce détail change l'expérience d'achat. Un serveur qui demande d'emblée l'accès complet fait signer une autorisation que personne ne relira. Un serveur qui la demande à l'usage rend chaque élargissement visible. C'est le dernier moment où l'acheteur voit quelque chose. Après, tout se joue entre le modèle et le serveur.

Six questions à poser avant de brancher un agent sur votre CRM

Chaque section produit une question, et chacune se vérifie sur un document plutôt que sur une promesse commerciale. Elles portent sur le serveur, pas sur la chaîne de traitement derrière : celle-là est l'objet d'un autre article de ce blog, « Où sont mes données : six réponses, une seule concerne un pays ». Les deux se posent au même fournisseur.

• Le schéma : le serveur décrit-il vos objets et champs réels, et l'agent peut-il l'introspecter avant d'écrire ?
• L'irréversible : quelles opérations exigent une confirmation côté serveur, et cette liste est-elle écrite ?
• L'échelle : combien d'enregistrements un seul appel peut-il modifier, et ce plafond est-il documenté ?
• Les droits : le périmètre de l'agent est-il celui de la personne connectée, ou d'un jeton d'application ?
• La portée : l'autorisation est-elle demandée d'un bloc, ou élargie à l'usage ?
• La trace : existe-t-il un journal des appels d'outils, rattaché à une identité et exportable ?

Trois de ces six questions ne se posaient pas avant que les agents écrivent. Un éditeur qui répond aux six par un document daté a fait le travail. Celui qui répond que son serveur MCP est sécurisé a décrit une intention. La première panne dira laquelle des six il avait traitée.

Kasar est un CRM AI-natif dont l'agent s'appelle Léo. Il capture les interactions par email, LinkedIn, WhatsApp, calendrier et appels, et il expose un serveur MCP : les six questions valent pour nous comme pour tout autre éditeur, et rien n'oblige à nous croire avant d'avoir demandé ce journal. L'essai dure 14 jours.