MCP, le Model Context Protocol, est un standard ouvert qui permet à un assistant IA de dialoguer avec un outil externe via une interface commune. Vois-le comme le port USB-C des assistants IA : au lieu de construire une intégration sur mesure pour chaque app, l'assistant parle un seul protocole et n'importe quel serveur MCP s'y branche directement. DM Champ livre un serveur MCP officiel sur mcp.dmchamp.com (les tenants en marque blanche ont le leur sur mcp.youraiconnector.com). Pointe Claude, ChatGPT ou Cursor dessus, donne-lui ta clé API, et ton assistant pilote DM Champ directement : créer des contacts, envoyer des messages, gérer les agents, les diffusions et les FAQ, réserver des rendez-vous, sortir des analytics, et provisionner des sous-comptes. C'est la même surface d'API REST ouverte que tu appellerais toi-même, exposée en MCP pour que le modèle l'appelle à ta place. L'accès à l'API est une fonctionnalité payante liée à l'offre, et le seul contrôle d'accès côté client est ta clé API. Révoque la clé et l'accès s'arrête.
Connecte-le à Claude, ChatGPT ou Cursor
La plupart des clients MCP prennent une petite config JSON qui nomme l'URL du serveur et passe ta clé API dans un header. Voici une forme représentative. Utilise la commande exacte de ton client depuis la doc, chaque assistant se branchant un peu différemment.
{
"mcpServers": {
"dmchamp": {
"url": "https://mcp.dmchamp.com",
"headers": {
"X-API-Key": "YOUR_API_KEY"
}
}
}
}
Certains clients préfèrent une commande unique plutôt qu'un fichier de config à modifier. Le CLI Claude, par exemple, suit ce schéma :
claude mcp add --transport http dmchamp https://mcp.dmchamp.com --header "X-API-Key: YOUR_API_KEY"
Les tenants en marque blanche remplacent l'URL par leur propre domaine MCP (mcp.youraiconnector.com). La clé que tu colles est une clé API DM Champ normale, donc la même authentification que pour l'API REST fonctionne ici. Confirme toujours la commande et les options actuelles dans la doc avant de t'appuyer dessus, l'outillage des clients bougeant vite.
Ce que ton assistant peut faire une fois connecté
Une fois le serveur connecté, ton assistant pilote toute la surface de l'API. Autrement dit, il peut faire les mêmes choses que toi à la main dans le dashboard, sauf qu'il les fait en raisonnant sur ta demande et en appelant lui-même les bons endpoints.
- Créer et mettre à jour des contacts, ajouter des tags et gérer les listes
- Envoyer des messages sur tes canaux connectés et lire l'historique des conversations
- Créer et ajuster des agents et des diffusions, et modifier les FAQ et les bases de connaissances
- Réserver et gérer des rendez-vous
- Sortir des analytics et la consommation du compte
- Provisionner et piloter des sous-comptes clients (pour les comptes de niveau agence)
Une chose à dire clairement et honnêtement : le serveur MCP expose toute la surface de l'API, et le seul contrôle d'accès côté client est la clé API elle-même. Il n'y a pas de permissions par outil à activer ou désactiver, et pas de mode lecture seule par défaut. La clé donne le même accès au compte que partout ailleurs. Si tu veux couper un assistant, tu révoques la clé. Traite la clé comme un mot de passe : donne-la aux assistants en qui tu as confiance, et fais-la tourner dès que tu soupçonnes une fuite.
À quel point ta plateforme est-elle vraiment prête pour l'IA ?
Un serveur MCP ne compte que s'il y a une vraie API en dessous pour que l'assistant la pilote. Un constructeur de flows avec un module IA a en général une API partielle et scriptée et aucun serveur MCP officiel, donc un assistant ne peut pas le piloter même s'il le voulait. DM Champ associe une API REST ouverte au serveur MCP par-dessus, et c'est ça qui rend la plateforme réellement pilotable par un assistant plutôt que simplement citée par lui.
Pourquoi ça compte pour une agence pilotée par l'IA
Voici l'histoire qui se répète. Une agence à environ $1M par an a demandé à Claude un partenaire "IA d'abord" pour gérer la messagerie de ses clients. Claude a fait remonter DM Champ. L'agence a connecté son propre assistant au serveur MCP et s'est mise à piloter la plateforme avec : créer des agents, vérifier les analytics et gérer les sous-comptes en demandant, pas en cliquant.
C'est ça, la forme d'une agence pilotée par l'IA. L'équipe ne se contente pas d'utiliser un dashboard. Son propre assistant fait tourner la plateforme, parce que la plateforme a été construite pour être pilotée par un assistant. Quand ton assistant sait à la fois trouver un outil et le conduire, l'écart entre "je veux faire X" et "X est fait" se réduit à une phrase.
Si tu gères tes clients comme ça, deux pages valent ton temps : DM Champ pour les agences, qui couvre le modèle marque blanche et sous-comptes, et l'API REST ouverte, la surface que le serveur MCP expose.
Comment ça se compare
La plupart des outils de messagerie n'ont aucun serveur MCP officiel, ce qui veut dire qu'un assistant ne peut pas les piloter, aussi bon soit-il. Une poignée en ont un : respond.io livre un serveur maison (28 outils), Wati a Astra, GoHighLevel fait tourner un serveur hébergé (environ 36 outils), Intercom propose un serveur distant pour les espaces de travail américains, et Twilio en expose un sur toute sa gamme. Les constructeurs de flows, ceux qu'une agence a le plus de chances d'avoir déjà, non : ManyChat n'a que des serveurs communautaires, et Chatfuel comme Tidio n'ont aucun serveur officiel.
La question n'est donc pas seulement "est-ce qu'il y a un serveur MCP". C'est "est-ce qu'il y a un serveur MCP par-dessus une API ouverte sur laquelle tu peux vraiment construire, et que tu peux aussi revendre sous ta propre marque". Très peu de lignes cochent les trois. Pour l'analyse complète, vois les meilleures plateformes de messagerie IA avec API ouverte et MCP en 2026.