Chapitre 12/12 • 18 min de lecture

MCP et Make Apps : étendre Make avec vos propres outils

Quand les modules natifs Make ne suffisent plus, deux options : créer une Make App custom (intégration native d'une API) ou utiliser le standard MCP (Model Context Protocol) pour connecter Claude à des outils maison. Quand utiliser quoi, et comment.

⏱️ En bref : Make Apps custom = vous créez une intégration native (avec actions, triggers, webhooks) pour un outil qui n'a pas encore son module Make. Effort technique : ~1-3 jours par app. MCP servers = standard ouvert pour exposer des outils à un LLM (Claude principalement). Plus jeune, plus complexe. En PME B2B 2026, les Make Apps custom couvrent 80% des besoins, MCP est utile pour les projets agents IA avancés.

Le problème : modules manquants

Make a 1 700+ modules natifs en 2026. C'est beaucoup. Mais pour des PME B2B avec des outils français spécifiques ou des outils internes, on rencontre régulièrement le mur :

Outil français de niche (un ERP métier, un logiciel sectoriel) qui n'a pas de module Make
API interne maison construite par votre équipe IT
Plateforme métier (ATS, GED, logiciel de signalétique...) avec API REST mais pas de connecteur
Évolution récente d'un outil : nouvel endpoint API que le module Make n'a pas encore intégré

Avant 2025, la seule réponse était : "utiliser le module HTTP générique" et reconstruire à la main les appels. Pénible et fragile. En 2025-2026, deux options structurées sont apparues : Make Apps custom et MCP servers.

Make Apps custom : créer son propre module natif

Make permet de créer des Apps custom qui apparaissent comme des modules natifs dans l'interface. C'est l'option historique et la plus mature.

Ce que vous obtenez

Un module qui apparaît dans la liste des modules avec votre logo
Des actions (Create, Update, Search, etc.) configurées et utilisables comme n'importe quel autre module
Des triggers (Watch...) si l'API source les supporte
Une gestion native d'authentification (API Key, OAuth2, Basic)
Un partage possible (privé pour vous, votre équipe, ou public sur le marketplace Make)

Quand créer une Make App custom

Cas typiques chez nos clients Lab0 :

Outil sectoriel français sans module : on a fait des apps pour Dolibarr (ERP open-source), Kleos (cabinet d'avocats), des logiciels de signalétique métier
API interne entreprise : votre équipe IT a une API REST pour les commandes / clients / stocks. On crée une app qui expose les principaux endpoints.
Webhook personnalisé : votre outil envoie des événements via webhook custom. App = trigger natif Make.
Réutilisation forte : si vous allez utiliser l'API dans 5+ scénarios différents, l'app est rentable. Si c'est pour 1 scénario unique, le module HTTP suffit.

Effort réel de création

Sur la base de notre expérience Lab0 :

App simple (3-5 actions, auth API Key, pas de trigger) : 4-8 heures de développement par un dev qui maîtrise déjà Make
App moyenne (10+ actions, OAuth2, 1-2 triggers) : 2-4 jours
App complexe (API mal documentée, pagination custom, multi-endpoints) : 5-10 jours

Compétences requises : connaissance de Make, JSON, IML (le langage de mapping de Make), et compréhension de l'API source (REST, GraphQL).

Le processus en 5 étapes

Définir le scope : quelles actions / triggers vous avez besoin. Ne pas couvrir 100% de l'API, juste ce dont vous avez besoin.
Configurer l'authentification : API Key, OAuth2, Basic. Test sur Postman avant de coder.
Coder les actions : un par un, avec test après chaque.
Coder les triggers si pertinent : polling ou webhooks.
Tester en condition réelle : créer un scénario qui utilise l'app, faire passer 50+ exécutions.

💡 Astuce Lab0

Pour les apps que vous créez en interne, gardez-les privées par défaut. Les rendre publiques sur le marketplace Make demande beaucoup plus de travail (validation Make, documentation, support utilisateurs). Pour 95% des cas PME, le mode privé suffit largement.

MCP Servers : le standard pour exposer des outils à Claude

MCP (Model Context Protocol) est un standard ouvert lancé par Anthropic fin 2024, qui permet à un LLM (Claude principalement) d'accéder à des outils externes de manière standardisée. C'est l'équivalent côté IA de ce que Make Apps fait côté workflow.

La différence fondamentale avec Make Apps

Aspect	Make App custom	MCP Server
Utilisateur direct	Vous (humain dans Make)	Le LLM (Claude qui appelle les outils)
Logique d'usage	Workflow déterministe	Décidée par le LLM
Compatibilité	Make uniquement	Tous LLMs supportant MCP (Claude, certains autres)
Maturité	Mature depuis 2018	Lancé fin 2024, écosystème en construction
Effort de création	4h - 10 jours selon complexité	2h - 5 jours selon complexité

Quand MCP est intéressant pour une PME B2B

Vous déployez des agents IA Claude en production et avez besoin que l'agent accède à vos données internes
Vous voulez une compatibilité multi-LLM (pas de vendor lock-in sur un éditeur)
Outil utilisé à la fois par humains et par IA : MCP sert l'IA, l'API sert les humains
Cas d'usage agentique pur où la décision d'utiliser tel outil ou tel autre est prise par le modèle

Quand Make Apps custom reste meilleur

Workflows déterministes qui ne nécessitent pas d'IA décisionnaire
Volume élevé d'exécutions où le coût IA serait prohibitif
Process critique où la prédictibilité est plus importante que la flexibilité
Équipe non-tech qui doit pouvoir maintenir les scénarios

⚠️ Anti-hype : MCP ne remplace PAS Make Apps

En 2026, on voit beaucoup de discours "MCP va remplacer toutes les automatisations". Ce n'est pas vrai. MCP est complémentaire à Make Apps, pas en concurrence. Une PME B2B mature utilisera typiquement les deux : Make Apps pour les workflows métier déterministes (le quotidien), MCP pour les projets agents IA spécifiques (les tâches complexes).

Retours terrain : 3 projets Lab0

Projet 1 : Make App pour ERP Dolibarr (signalétique B2B)

Client PME signalétique avec Dolibarr en interne. Module Dolibarr générique sur Make existait mais limité. Nous avons créé une Make App custom couvrant 12 actions spécifiques (création de devis avec lignes, gestion des produits multi-variantes, mise à jour de statut commande, etc.).

Effort : 5 jours de dev. Résultat : 4 scénarios principaux qui consomment l'app, 8 commerciaux qui ne tapent plus jamais dans Dolibarr pour les créations de devis (gain ~20 min/devis × 50 devis/semaine).

Projet 2 : MCP Server pour base interne (cabinet de conseil)

Cabinet de conseil avec une base interne de 2000+ missions historiques. Besoin : permettre à un agent Claude (utilisé en interne par les consultants) d'aller chercher des cas similaires lors de nouvelles propositions commerciales.

On a créé un MCP server qui expose 4 outils : recherche par client, recherche par secteur, recherche par mots-clés, récupération de fiche mission. Effort : 3 jours. Résultat : les consultants gagnent ~1h par proposition commerciale en accédant aux références passées en langage naturel.

Projet 3 : combinaison Make App + MCP (cabinet d'avocats)

Cabinet d'avocats migration. Make App custom pour Kleos (logiciel d'avocat) qui permet la création automatique de dossiers depuis Pipedrive — workflow déterministe quotidien. Et un MCP server distinct qui expose la base de jurisprudence interne aux agents Claude des avocats — usage agentique ponctuel pour la recherche de cas.

Les deux coexistent sans se chevaucher. Make App pour le commercial automatisé, MCP pour la R&D juridique des avocats. Effort total : ~8 jours de dev répartis sur 2 mois.

Recommandations Lab0

Sur la base de nos déploiements 2025-2026, voici notre grille de décision :

Étape 1 : commencez par les modules natifs Make

1 700+ modules. Vérifiez d'abord qu'il n'existe pas déjà. Marketplace Make.

Étape 2 : si pas de module natif, essayez le module HTTP générique

Pour un usage one-shot ou un scénario unique, le module HTTP suffit. Pas besoin de créer une app entière.

Étape 3 : si réutilisation forte (5+ scénarios), créez une Make App custom

L'effort de création est rentabilisé par la réutilisation et la robustesse.

Étape 4 : pour l'usage agentique IA, créez un MCP server

Quand vous voulez qu'un agent Claude accède à vos données internes, MCP est le standard à adopter en 2026.

Étape 5 : combinez les deux si nécessaire

Une PME B2B mature peut très bien avoir 3 Make Apps custom + 2 MCP servers en parallèle, chacun servant des cas d'usage différents.

💡 Coûts cachés à anticiper

Les Make Apps et les MCP servers ne sont pas que du dev initial : ils nécessitent de la maintenance (changements d'API source, nouvelles versions, ajout d'actions). Comptez 1-2 jours/an de maintenance par app/server. Pour les apps publiques sur le marketplace Make, c'est encore plus élevé (support utilisateurs).

À retenir

Make Apps custom = créer un module natif Make pour un outil spécifique. Mature, robuste, idéal pour les workflows déterministes.
MCP servers = standard ouvert pour exposer des outils à Claude (et autres LLMs MCP-compatibles). Plus jeune, idéal pour les projets agents IA.
Les deux sont complémentaires, pas en concurrence. Une PME mature peut avoir les deux.
Avant de créer quoi que ce soit, vérifiez les modules natifs et HTTP générique. La création d'app/server est un investissement.
Effort réel : 4h à 10 jours selon complexité. Maintenance : 1-2 jours/an.
Compétences requises : Make, JSON, API REST, IML pour les apps. Compétences supplémentaires Python ou TypeScript pour les MCP servers.

Pour des projets agents IA + MCP, voir notre service dédié : Agents Claude pour PME B2B et MCP pour PME. Pour des Make Apps custom, l'audit gratuit Lab0 permet de cadrer le besoin et l'effort.