Sommaire
MCP et une API peuvent intervenir dans la même connexion entre un agent IA et un CRM. L’API du CRM donne accès aux fonctions de l’application. MCP fournit un protocole pour présenter des outils et du contexte à l’application qui héberge l’agent. Un serveur MCP peut appeler cette API. Le choix d’architecture doit préciser les permissions, les données retournées et les actions qui nécessitent une approbation.
Suivre une demande jusqu’au CRM
Imaginons qu’un employé demande : « Retrouve le dossier de ce client et prépare une mise à jour de son adresse. » Le système doit identifier le bon client, lire les informations nécessaires, produire une proposition, puis faire valider la modification. Une conversation compréhensible ne prouve pas que la bonne ligne du CRM a été choisie.
Dans une intégration directe, l’application de l’agent appelle une fonction définie par votre équipe. Cette fonction vérifie les paramètres et utilise l’API du CRM. L’application contrôle les accès, les erreurs et le résultat renvoyé au modèle. Vous choisissez exactement les opérations exposées.
Avec MCP, l’application utilise un client MCP pour communiquer avec un serveur qui expose des outils. Le serveur peut ensuite appeler l’API du CRM. La présentation officielle de MCP décrit cette connexion et les ressources qu’un serveur peut fournir. Le protocole ajoute une interface commune; les règles métier du CRM et ses droits d’accès restent à appliquer.
Le chemin direct est : employé, application de l’agent, fonction métier contrôlée, API du CRM. Le chemin avec MCP est : employé, application avec client MCP, serveur MCP, fonction métier contrôlée, API du CRM. Dans les deux cas, placez le contrôle d’écriture sur le système qui exécute l’action.
IllustrationConnexion directe de l’application agent au backend métier puis à l’API du CRM · bloc partageable
IllustrationConnexion du client MCP au serveur MCP puis au backend métier et à l’API du CRM · bloc partageable
Décider quelles opérations exposer
Une opération nommée « gérer les clients » donne trop peu d’information sur son effet. Préférez des outils séparés : rechercher un client, lire certains champs, préparer une modification et appliquer une proposition approuvée. La documentation MCP sur les outils présente les descriptions et les schémas d’outils. Votre conception doit ajouter les limites propres au métier.
Pour une recherche, définissez les paramètres acceptés et le nombre maximal de résultats. Pour une modification, demandez l’identifiant du dossier, les champs visés et la référence de la proposition approuvée. Le serveur vérifie cette référence au moment de l’écriture. Un champ « approved: true » envoyé librement par le modèle ne constitue pas une preuve d’approbation.
TableauOpération · bloc partageable
| Accès utile | Contrôle recommandé | |
|---|---|---|
| Rechercher | Identité et référence de contact | Filtrage selon l’utilisateur, résultat limité |
| Lire | Champs nécessaires à la tâche | Contrôle du dossier et des champs autorisés |
| Proposer | Brouillon de changements | Comparaison avec les valeurs actuelles |
| Appliquer | Champs explicitement approuvés | Autorisation serveur et approbation encore valide |
| Supprimer | Aucun accès dans ce pilote | Procédure distincte réservée à un responsable |
Dans cet exemple, l’agent peut préparer une adresse corrigée. Il ne peut pas modifier le plafond de crédit ni supprimer le client. Ces restrictions doivent tenir même si le document lu contient une instruction demandant le contraire. Les données d’un outil sont des informations à traiter, avec un niveau de confiance défini.
Comparer l’intégration directe et MCP
Une intégration directe convient lorsque vous contrôlez une application et un petit nombre de fonctions. Elle peut simplifier les dépendances du pilote. MCP mérite d’être étudié lorsqu’un même ensemble d’outils doit servir à plusieurs applications compatibles, avec une interface maintenue à part.
TableauCritère · bloc partageable
| Intégration directe à l’API | Exposition via MCP | |
|---|---|---|
| Interface utilisée par l’agent | Fonctions propres à votre application | Outils exposés selon MCP |
| Réutilisation | Adaptation possible pour chaque application | Réutilisation par des clients compatibles à vérifier |
| Exploitation | Application et connexion CRM à maintenir | Serveur MCP et connexion CRM à maintenir |
| Permissions | Contrôles dans le backend et le CRM | Contrôles dans le serveur, le backend et le CRM |
| Choix du pilote | Peu d’outils, application unique | Plusieurs clients ou outils mutualisés |
La compatibilité se vérifie sur les versions et les transports réellement utilisés. Un serveur présent dans un catalogue n’est pas automatiquement adapté à votre CRM ou à votre politique d’accès. Vérifiez sa provenance, son entretien et les opérations qu’il expose avant de connecter un compte métier.
La documentation MCP sur l’autorisation précise les mécanismes du protocole. Votre application doit encore déterminer qui peut consulter tel dossier et dans quelles circonstances une modification est permise. Une connexion authentifiée peut porter des droits trop larges pour la tâche demandée.
Préserver l’approbation et la trace des changements
L’employé doit voir le dossier concerné, les valeurs actuelles et les valeurs proposées. Après son accord, l’exécuteur vérifie que le dossier n’a pas changé depuis la proposition. Si une autre personne a modifié l’adresse entre-temps, demandez une nouvelle validation. Cette règle évite d’écraser un travail plus récent.
Conservez une trace reliant la demande, les lectures utiles, la proposition et l’écriture. Limitez les données personnelles contenues dans les journaux. Pour investiguer une erreur, l’équipe doit retrouver l’opération et sa décision sans multiplier des copies complètes du dossier.
Préparez la reprise après un délai réseau. Avant de relancer une modification, vérifiez son état avec un identifiant d’opération. Définissez aussi comment suspendre les écritures tout en conservant, si nécessaire, la consultation autorisée. Le guide d’intégration API entre CRM, comptabilité et boutique développe les questions de synchronisation entre systèmes.
Tester l’architecture sur une tâche limitée
Pour la recette, utilisez un compte d’essai et deux utilisateurs ayant des droits différents. Demandez au second utilisateur de lire un dossier réservé au premier. Essayez aussi une modification hors périmètre, un refus d’approbation et une proposition devenue ancienne. L’action doit être contrôlée dans le système d’exécution, même lorsque le modèle formule une demande convaincante.
Ces tests complètent la vérification des réponses de l’agent. Notre guide sur la sécurité des agents IA couvre les risques liés aux outils et aux contenus externes. Pour cadrer la connexion au CRM, le service d’automatisation CRM et ERP permet de définir les opérations utiles avant de choisir le protocole.
Questions fréquentes
MCP remplace-t-il l’API du CRM?+
Un serveur MCP peut utiliser l’API du CRM pour exécuter ses outils. L’API reste alors la voie d’accès aux données et aux opérations. MCP organise la façon dont l’application de l’agent découvre et appelle les fonctions exposées.
MCP suffit-il pour sécuriser une intégration?+
Le protocole fournit des mécanismes d’interconnexion et d’autorisation. La sécurité dépend aussi du serveur, des droits CRM et de vos contrôles métier. Vérifiez les accès et les actions avec des tests indépendants de la réponse du modèle.
Une approbation dans le message de l’agent est-elle suffisante?+
L’exécuteur doit vérifier une approbation provenant du parcours autorisé et correspondant aux changements proposés. Un modèle peut produire un champ ou une phrase d’approbation; cette sortie seule ne prouve pas l’accord de l’utilisateur.
Faut-il ajouter MCP au premier pilote?+
Ajoutez-le lorsque la réutilisation des outils ou les clients compatibles justifient cette couche. Pour une application unique avec quelques opérations, comparez aussi une intégration directe. La décision doit tenir compte de l’exploitation après le pilote.
Auditer les connexions de votre agent
Décrivez votre processus et les outils utilisés. Daillac pourra cadrer le périmètre, les accès et les critères d’acceptation d’un pilote.
D
