Zapier SDK, MCP, code custom : le decision tree pour PME en 4 questions

Une commande shell, et un agent IA peut soudain piloter Salesforce, Slack, GitHub, Google Calendar et 8 996 autres applications. Pas une ligne d’OAuth à écrire. C’est la promesse de Zapier SDK, ouvert à tous depuis avril 2026 et gratuit pendant toute la durée de la beta. Pour une PME qui monte un agent IA, l’arrivée du SDK ouvre une troisième voie aux côtés de MCP et du développement custom. Reste à savoir laquelle choisir.

Cet article tranche en quatre questions.

Le pari de Zapier : 9 000 apps en une commande shell

Le pitch est simple à comprendre, et c’est précisément son intérêt. Vous installez zapier-sdk login dans votre coding agent, Cursor, Claude Code, Codex, peu importe. À partir de là, votre agent dispose d’un accès programmatique à 9 000+ applications, 3 600 APIs accessibles en HTTP brut authentifié, et 30 000+ actions prêtes à l’emploi.

Ce que Zapier prend en charge, et qui représente d’habitude la majorité du temps d’intégration : l’authentification OAuth, le rafraîchissement des tokens, les retries en cas d’erreur réseau, et les “API quirks” propres à chaque service (formats de date Salesforce, pagination LinkedIn, headers spécifiques à HubSpot). Vous écrivez la logique métier, Zapier tient les clés.

Pour donner un ordre de grandeur : un connecteur Salesforce custom, en partant de zéro, c’est 1 à 3 jours de développement pour un dev senior, gestion OAuth comprise. Avec le SDK, c’est environ 30 lignes. Le ratio est suffisamment violent pour justifier le détour, surtout si votre agent doit toucher à plusieurs SaaS.

La beta est gratuite. Aucun changement de facturation pendant l’open beta, et Zapier s’engage à prévenir avant tout switch. Sur les plans Enterprise et Team, l’accès au SDK est désactivé par défaut, il faut un opt-in manuel, ce qui rassure les DSI.

Zapier SDK vs MCP : le wrapper propriétaire face au protocole ouvert

C’est ici que la confusion s’installe pour beaucoup d’équipes. Le SDK Zapier et MCP font apparemment la même chose : permettre à un agent IA de manipuler des outils externes. En réalité, ils opèrent à des niveaux très différents.

MCP (Model Context Protocol) est un protocole standard ouvert, lancé par Anthropic et désormais adopté par la majorité de l’écosystème IA. C’est une spécification : n’importe qui peut écrire un serveur MCP, le faire tourner où il veut, le combiner avec n’importe quel client compatible. Si vous avez besoin d’une remise à niveau, le protocole MCP qui connecte vos outils métier à l’IA couvre l’essentiel.

Zapier SDK est un wrapper propriétaire. Vous l’installez, vous appelez ses méthodes, votre code passe par l’infrastructure Zapier. Le gain : un catalogue de 9 000 intégrations déjà construit, maintenu, et avec OAuth pré-câblé. Le coût : vous dépendez de Zapier sur la couche d’orchestration.

Sur sa propre page produit, Zapier ne nie pas le positionnement : “Where MCP gives agents a curated menu of pre-built actions, the SDK lets agents go further: write loops, handle edge cases, chain complex logic across apps.” Traduction honnête : MCP donne un menu d’actions, le SDK donne du code.

Les deux ne s’excluent pas. Vous pouvez très bien avoir un agent qui utilise MCP pour vos systèmes internes (souveraineté, contrôle) et Zapier SDK pour les SaaS externes (rapidité). C’est même probablement la combinaison gagnante pour une majorité de PME en 2026.

Côté sécurité, gardez un œil ouvert. MCP a connu sa propre crise de croissance, 43 % des serveurs MCP analysés présentaient des failles lors d’un audit en avril 2026. Zapier hérite de ses propres défis : le contrôle de gouvernance fin sur les appels API directs est encore “sur la roadmap” selon la documentation officielle. Aucune des deux options n’est magique.

SDK vs code custom : 30 lignes contre 3 jours

La troisième voie, la plus ancienne, reste valable. Coder vous-même l’intégration HubSpot ou Salesforce, gérer votre OAuth, vos retries, votre rate limiting. Pourquoi y consacrer du temps en 2026 ?

Trois raisons. La première : les volumes élevés. Si votre agent fait 50 000 appels par jour à une API, vous voulez un contrôle fin du rate limiting, du caching, des retries. La couche Zapier devient une boîte noire qui peut introduire de la latence, et le pricing post-beta pourrait pénaliser votre cas d’usage.

La deuxième : les données sensibles. Si votre agent manipule des données de santé, des données bancaires, ou des informations couvertes par un secret professionnel, vous ne voulez probablement pas que les requêtes transitent par un sous-traitant supplémentaire. Zapier devient un sous-traitant au sens RGPD, avec tout ce que cela implique en termes de DPA, d’audit et de tenue du registre.

La troisième : la logique métier non standard. Si votre intégration nécessite des transformations exotiques, des workflows long-running avec état, ou un comportement spécifique non couvert par les actions Zapier, le custom redevient pertinent.

Pour tout le reste, et “tout le reste” représente probablement 70 % des cas d’usage agents en PME, le SDK ou MCP gagnent largement contre le custom sur le ratio temps/résultat.

Le decision tree en 4 questions

Voici la grille de décision qu’on applique sur les missions LeCollectif quand un client hésite. Quatre questions, posées dans cet ordre.

1. L’application est-elle dans le catalogue Zapier ?

• Si oui, le SDK est un candidat sérieux. Vous gagnez 1 à 3 jours par intégration.
• Si non, partez sur MCP quand un serveur existe ou est facile à écrire, sinon sur du sur-mesure.

2. Quel est le volume d’appels prévu ?

• Faible à modéré, sous 1 000 appels par jour : le SDK reste pertinent. Vous ne saturerez pas les rate limits Zapier et la latence ajoutée est négligeable.
• Élevé, au-delà de 10 000 appels par jour : le sur-mesure devient sérieusement compétitif. Vous voudrez maîtriser le caching et le rate limiting vous-même.

3. Avez-vous besoin de portabilité hors Zapier ?

• Si non, le SDK est acceptable. Le lock-in est limité à la couche orchestration.
• Si oui, pour du multi-cloud, une ré-internalisation possible ou une exigence client, choisissez MCP. Le protocole est ouvert, vous pouvez changer de fournisseur sans réécrire.

4. Quelle est la sensibilité des données traitées ?

• Données standard : SDK ou MCP, au choix.
• Données sensibles en santé, finance, RH ou secrets industriels : MCP auto-hébergé ou sur-mesure. Vous ne voulez pas multiplier les sous-traitants.

En sortie de ces quatre questions, le bon choix tombe pour environ 90 % des situations. Pour les 10 % restants, on combine, généralement un mix MCP pour le sensible et SDK pour le périphérique.

Trois cas d’usage où chaque voie gagne

Cas 1 : MVP commercial en 5 jours

Vous montez un agent qui qualifie les leads entrants, les enrichit via Clearbit, les pousse dans HubSpot, alerte le commercial sur Slack. Verdict : Zapier SDK. Tous les outils sont au catalogue, le volume est faible, vous voulez livrer vite, le client paiera l’arbitrage technique plus tard.

Cas 2 : agent d’orchestration interne

Vous avez un ERP custom + 4 outils SaaS + un PostgreSQL maison. Verdict : MCP. Vous écrivez (ou trouvez) un serveur MCP par système, votre agent les compose. Vous gardez la portabilité et la cohérence avec une stack qui sera amenée à évoluer. Sur le sujet, n8n + MCP qui crée le workflow en 30 secondes montre la combinaison en action.

Cas 3 : agent de production à fort volume

Vous traitez 200 000 messages clients par jour avec un agent qui trie, route, répond, escalade. Verdict : custom, ou MCP self-hosted avec optimisations. Le SDK ferait exploser la facture post-beta, et la latence ajoutée serait perceptible côté utilisateur final.

Le piège du “tout SDK” : lock-in et tarification post-beta

Le SDK est gratuit aujourd’hui. Il ne le restera pas. Zapier s’engage simplement à “prévenir avant tout changement de facturation”. Cela peut arriver dans 6 mois, dans 12, ou dans 24, personne ne le sait. Et si vous avez bâti l’orchestration de cinq agents critiques sur le SDK, votre marge de manœuvre au moment de la bascule sera étroite.

Deuxième angle mort : la gouvernance fine sur les appels API directs (les “raw API calls” qui contournent les actions pré-construites) n’est pas encore implémentée. La documentation Zapier le précise : “Direct API governance is on the roadmap.” En clair : si vous reposez beaucoup sur les appels HTTP bruts, vous n’avez pas encore les mêmes contrôles que sur les actions standard.

Troisième angle : la couche d’orchestration propriétaire. Migrer un agent du SDK vers MCP ou du custom n’est pas trivial. Le code change, les abstractions changent, le modèle de gestion d’erreurs change.

Le contre-feu est simple. Pour chaque agent que vous montez sur Zapier SDK, posez-vous une question : si Zapier double ses prix dans 12 mois, ai-je un plan B viable ? Si la réponse est non, c’est un signal pour soit garder l’expérimentation petite, soit basculer sur MCP dès le départ.

Raccourci complémentaire, pas alternative

Le bon message à retenir : Zapier SDK n’est pas une alternative à MCP. C’est un raccourci complémentaire. MCP reste la couche standard ouverte qui garantit votre portabilité et votre indépendance. Zapier SDK est le levier qui vous fait gagner deux semaines sur le démarrage d’un agent multi-SaaS.

Pour une PME en 2026, la posture rationnelle ressemble à ceci : MCP par défaut sur les systèmes internes et les données sensibles ; SDK pour les SaaS périphériques où la rapidité prime ; custom uniquement quand le volume ou la criticité l’exigent. Et toujours : un plan B documenté, parce que le marché de l’orchestration agentique est encore en formation.

Le choix Zapier SDK vs MCP vs custom se replace dans un débat plus large : choisir la bonne couche d’orchestration agent. L’arbre de décision Salesforce Headless / Mistral Workflows / Workspace Agents couvre la couche au-dessus, celle de l’orchestrateur métier. Et côté sécurité, les trois incidents Lovable, MCP RCE et Shai-Hulud d’avril 2026 dessinent un pattern d’architecture à intégrer dès la conception de votre stack agent, quel que soit le wrapper choisi.

Si vous hésitez sur l’arbitrage entre les trois voies pour un projet spécifique, c’est exactement le genre de décision qu’on aide à trancher dans nos missions workflows automatisés et intégration IA. Trente minutes d’échange suffisent souvent à clarifier la bonne architecture, avant que la dette technique ne s’installe.

---

Sources : docs.zapier.com/sdk ; zapier.com/sdk ; Zapier expands AI governance, ITBrief, 24 avril 2026 ; annonce Wade Foster (CEO Zapier) sur LinkedIn.