Si vous utilisez déjà Make.com, vous avez un capital dormant : des scénarios construits, testés, fiables — enrichissement de leads, création de fiches CRM, notifications, synchronisations. Jusqu'ici, ils se déclenchaient sur programmation ou sur événement. Avec le serveur MCP de Make, ils gagnent un troisième mode de déclenchement : la demande en langage naturel.
Concrètement, vos scénarios "à la demande" deviennent des outils que Claude connaît et peut exécuter — avec les paramètres que vous lui donnez dans la conversation. C'est le chaînon manquant entre deux mondes : l'automatisation déterministe de Make et la flexibilité conversationnelle de l'IA.
Le principe : vos scénarios comme outils IA
Le Model Context Protocol (MCP) est le standard qui permet à un assistant IA d'utiliser des outils externes. Le serveur MCP de Make expose vos scénarios configurés "on demand" : chacun apparaît à Claude comme une capacité nommée, avec ses paramètres d'entrée. Claude décide quand l'appeler, remplit les paramètres à partir de votre demande, et récupère le résultat.
L'intérêt architectural est majeur : la logique métier reste dans Make — visible, testable, versionnée — et l'IA n'est qu'un déclencheur intelligent. Si un scénario doit changer, vous le modifiez dans Make, et Claude utilise automatiquement la nouvelle version. Rien n'est enfermé dans un prompt.
La bonne répartition : Make exécute (fiable, déterministe, journalisé), Claude comprend (la demande, le contexte, les paramètres). Ne demandez pas à l'IA de refaire ce que le scénario fait déjà bien — donnez-lui juste la main sur le déclenchement.
Ce que ça change par rapport à Make classique
- Plus besoin d'interface pour les déclenchements ponctuels : un scénario qui demandait un formulaire, un webhook à appeler ou un clic dans Make se lance en une phrase
- Les paramètres deviennent conversationnels : "lance l'enrichissement pour les leads du salon d'hier" — Claude traduit en paramètres d'entrée du scénario
- L'IA peut enchaîner : interroger le CRM via MCP, décider quels enregistrements traiter, puis déclencher le scénario Make correspondant — une orchestration qui demandait du développement
- Le non-technique y accède : un commercial peut déclencher un workflow que seul l'Ops savait lancer
À quoi ça ressemble concrètement
Dans chaque cas, Claude appelle le scénario Make avec les bons paramètres, attend l'exécution et restitue le résultat dans la conversation. La traçabilité reste entière : chaque exécution apparaît dans l'historique Make, comme n'importe quelle autre.
Installation pas à pas
Prérequis : un compte Make.com avec des scénarios configurés en déclenchement "on demand", et un abonnement Claude permettant les connecteurs.
- Côté Make : vérifiez que les scénarios à exposer sont en mode "on demand" et nommez-les clairement — c'est ce nom que Claude verra et utilisera pour choisir le bon outil.
- Récupérez l'URL de votre serveur MCP Make dans les paramètres de votre profil (voir la documentation Make pour l'emplacement exact selon votre plan).
- Dans Claude, ajoutez un connecteur personnalisé avec cette URL et validez l'authentification.
- Testez : "Quels scénarios Make peux-tu déclencher ?" — la liste doit correspondre à vos scénarios on demand. Puis déclenchez le plus inoffensif pour valider la boucle complète.
En cas de problème
Si un scénario n'apparaît pas dans la liste, vérifiez son mode de déclenchement : seuls les scénarios "on demand" sont exposés, pas ceux qui tournent sur planification ou webhook. Si un déclenchement échoue, l'historique d'exécution Make vous donne l'erreur module par module — c'est votre premier réflexe de diagnostic, bien plus précis que le message côté conversation. Enfin, des noms de scénarios explicites ("Enrichir leads depuis Airtable") évitent à Claude de choisir le mauvais outil quand plusieurs se ressemblent.
3 cas d'usage détaillés
1. L'enrichissement à la demande, sans refaire la plomberie
Vous avez déjà un scénario qui enrichit des leads (FullEnrich, Dropcontact…) et les pousse dans le CRM. Exposé en MCP :
Le scénario existant fait le travail ; Claude gère l'entrée (une liste dictée, un fichier collé) que Make seul ne savait pas recevoir aussi souplement.
2. L'orchestration conditionnelle
C'est le motif le plus puissant : une connexion MCP (le CRM) fournit la condition, un scénario Make exécute l'action. Ce type d'orchestration demandait soit du code, soit un scénario Make complexe et fragile — ici, la logique conditionnelle vit dans la conversation, où elle est facile à ajuster.
3. Le guichet unique pour l'équipe
Publiez trois ou quatre scénarios bien choisis (enrichissement, création de compte, reporting, relance) et l'équipe commerciale dispose d'un guichet : plus besoin de savoir où est le formulaire, quel webhook appeler, qui demander. On demande à Claude, qui connaît les outils disponibles et leurs paramètres. L'Ops garde la maîtrise de ce qui est exposé — et voit tout dans les historiques Make.
Bonnes pratiques et limites
- N'exposez que l'utile : chaque scénario exposé est un levier que l'IA peut actionner. Commencez par les scénarios sans effet irréversible (lecture, enrichissement, notification) avant ceux qui écrivent ou envoient.
- Nommez et décrivez soigneusement : Claude choisit l'outil d'après son nom et sa description. Un scénario mal nommé sera mal utilisé.
- Surveillez la consommation d'opérations : un déclenchement conversationnel reste une exécution Make facturée en opérations. Les gros volumes récurrents restent mieux sur planification classique.
- Le récurrent reste programmé : le MCP couvre le ponctuel et le contextuel. Ce qui doit tourner tous les jours à 8h n'a aucune raison de passer par une conversation — voir la page automatisation pour cette répartition.
Questions fréquentes
Make ou n8n ou Zapier pour ce type d'usage ?
Les trois évoluent vers le MCP. Make offre aujourd'hui le meilleur équilibre pour les PME françaises (prix, catalogue d'applications, lisibilité des scénarios) — c'est mon choix par défaut, mais l'architecture décrite ici se transpose si votre stack est ailleurs.
Claude peut-il créer un scénario Make à ma place ?
Le MCP déclenche des scénarios existants ; la construction reste dans l'éditeur Make. Claude peut en revanche vous aider à concevoir le scénario (modules, logique, gestion d'erreurs) avant que vous ne l'assembliez — c'est un bon copilote de conception.
Que se passe-t-il si le scénario échoue en cours d'exécution ?
Comme pour toute exécution Make : l'erreur est journalisée dans l'historique, avec le module fautif et les données en entrée. Claude vous remonte l'échec, et le diagnostic se fait dans Make — la gestion d'erreurs (reprises, chemins alternatifs) se configure dans le scénario, pas dans la conversation.
Est-ce que ça remplace les connexions MCP directes (Pipedrive, Lemlist…) ?
Non, c'est complémentaire. La connexion directe est meilleure pour interroger et agir finement sur un outil ; Make est meilleur pour les chaînes multi-outils éprouvées. Règle simple : une question ou une action simple → MCP direct ; un processus en plusieurs étapes → scénario Make déclenché par MCP.
Et après ?
Ce guide clôt la boucle des briques : les connexions MCP directes pour interroger et agir, Make pour exécuter les chaînes, et les agents IA pour les tâches qui demandent du jugement. La bonne architecture combine les trois selon vos blocages réels — c'est exactement l'objet de la méthode en 5 étapes.
Envie du même niveau d'automatisation chez vous ?
On regarde ensemble où un déploiement comme celui-ci ferait gagner du temps à votre équipe — 30 minutes, sans engagement.
Réserver un appel stratégique →