La plupart des entreprises découvrent les agents IA via un outil qu’elles utilisent déjà. Zapier a ajouté des AI Agents à sa plateforme. Make a suivi avec ses propres fonctionnalités de scénarios agentiques. Les deux sont réellement utiles — et les deux ont des modes d’échec qui ne deviennent évidents que lorsqu’un processus qui compte vraiment est en production.
Ceci est une évaluation d’achat, pas un test produit. La question n’est pas quelle plateforme offre la meilleure UX. La question est : compte tenu des enjeux business du processus que vous souhaitez automatiser, quel niveau d’outil est le choix rationnel ?
Pourquoi “des agents dans chaque SaaS” brouille la décision d’achat
Les plateformes d’automatisation qui retrofittent des “agents IA” dans leur produit créent un problème de nomenclature. Le mot “agent” couvre désormais tout : d’un simple prompt GPT qui reformate une entrée Notion, à un système multi-étapes avec état qui route, décide et agit sur des API externes avec une logique de récupération.
Les plateformes ne mentent pas — mais le label cache d’énormes différences en matière de fiabilité, contrôle des données, structure des coûts et gestion des erreurs. Un workflow qui publie une mise à jour LinkedIn quand un blog est mis en ligne n’appartient pas à la même catégorie qu’un agent qui qualifie des leads entrants, consulte votre CRM, rédige une réponse personnalisée et enregistre le résultat. Les traiter comme équivalents mène à choisir le mauvais outil pour la mauvaise tâche.
Les trois dimensions qui comptent vraiment pour cette décision :
- Économie par exécution — quel est le coût de chaque run, et comment évolue-t-il à l’échelle ?
- Modes d’échec — comment le système se comporte-t-il quand un appel LLM tourne mal, qu’une API tierce est lente, ou que les données en entrée sont désordonnées ?
- Contrôle des données et observabilité — où vont vos données, et pouvez-vous voir ce que l’agent a réellement fait ?
Coût par exécution : quand les coûts de plateforme deviennent difficiles à prévoir
Zapier et Make facturent par opération ou consommation de tâches. Un Zap simple avec un déclencheur et deux étapes d’action coûte deux tâches — les déclencheurs sont toujours gratuits dans le modèle de facturation de Zapier. Un run “agent” qui appelle un LLM, interroge une feuille de calcul, envoie un message Slack et met à jour un enregistrement CRM peut consommer dix à trente opérations selon la façon dont il est structuré — et cela avant de prendre en compte les coûts de tokens LLM, que les plateformes transfèrent généralement avec une majoration.
Pour un processus à faible volume et faibles enjeux — disons 50 runs par mois avec des entrées prévisibles — la tarification plateforme est tout à fait raisonnable. Vous payez pour la vitesse de déploiement et zéro surcharge d’infrastructure. C’est une vraie valeur.
L’économie change quand :
- Le volume dépasse quelques centaines de runs significatifs par mois
- Chaque run implique plusieurs appels LLM (récupération, classification, génération sont des appels séparés dans la plupart des modèles agentiques)
- Vous avez besoin d’une logique de retry, qui réexécute les opérations et multiplie la consommation
Une illustration concrète : une équipe commerciale de 10 personnes utilisant un agent basé sur Zapier pour qualifier et router 500 formulaires entrants par mois, avec chaque run touchant cinq opérations et deux appels LLM, pourrait consommer 5 000+ tâches par mois plus les coûts LLM pass-through. À ce volume, un agent custom fonctionnant sur une cloud function coûte une fraction du prix par run — le coût variable correspond uniquement aux dépenses directes d’API LLM, typiquement bien en dessous de $0,01 par run de qualification avec les modèles mid-tier actuels (à titre de référence, GPT-4o mini est tarifé à $0,15 par million de tokens en entrée et Claude Haiku à $0,25 par million de tokens en entrée à mi-2026).
Le point de croisement varie selon les cas d’usage, mais pour la plupart des processus agentiques significatifs, il arrive plus tôt que les acheteurs ne l’anticipent.
Comment les agents de plateforme échouent — et pourquoi c’est difficile à anticiper
Le problème profond n’est pas le coût. C’est que Zapier et Make ont été conçus pour des workflows déterministes. Quand l’étape A se termine, l’étape B s’exécute. Les agents ne sont pas déterministes — ils impliquent des appels LLM qui peuvent retourner des formats inattendus, des sorties ambiguës, ou des erreurs directes. Les plateformes sous-jacentes n’ont pas été construites pour gérer cela élégamment.
En pratique, cela se manifeste par :
Échecs partiels silencieux. Un Zap peut se terminer avec succès même si le LLM a retourné une réponse malformée, parce que l’étape en aval enregistre simplement ce qu’elle a reçu. Votre CRM est mis à jour avec des données corrompues, et vous le découvrez des semaines plus tard.
Pas d’intelligence de retry. Si un appel API échoue en milieu de run, la plupart des agents basés sur plateforme s’arrêtent ou déclenchent une erreur générique. Il n’y a aucune logique pour réessayer l’étape spécifiquement défaillante, utiliser un modèle de secours, ou alerter un réviseur humain pour ce cas précis.
Profondeur de débogage. La visibilité de débogage varie selon la plateforme. Zapier expose l’historique au niveau des tâches et des points de contrôle de version. Le Reasoning Panel de Make (lancé en février 2026) fournit des traces visuelles étape par étape des décisions de l’agent et des appels d’outils. Aucun des deux n’égale l’observabilité complète d’un système custom — vous n’aurez pas la trace complète de raisonnement LLM, les décomptes bruts de tokens, ou un journal d’audit structuré dans le format que vous définissez — mais l’écart se réduit. Pour un processus touchant des données clients ou des registres financiers, même les outils de plateforme en amélioration peuvent s’avérer insuffisants.
Contrôle du prompt et du modèle. Les agents de plateforme varient dans le contrôle qu’ils exposent. Zapier et Make offrent désormais le support multi-modèles et la configuration du system-prompt ; cependant, le contrôle granulaire sur le versionnage du modèle et les paramètres d’inférence reste plus limité que dans un système entièrement custom. Quand une plateforme met à jour ses défauts de modèle sous-jacents, le comportement de votre agent peut changer sans préavis.
Pour les processus où une erreur coûte de l’argent, endommage une relation client, ou touche des données réglementées, ces modes d’échec ont une importance considérable.
Quand les agents de plateforme sont la bonne réponse
Pour être directs : les agents Zapier et Make sont un bon choix dans des scénarios spécifiques.
Bonne adéquation :
- Processus qui s’exécutent moins de quelques centaines de fois par mois
- Tâches de contenu à faibles enjeux : mise en forme, synthèse, notifications internes
- Équipes sans capacité de développement en interne et besoin réel d’aller vite
- Prototypes et preuves de concept où la vitesse d’itération importe plus que la fiabilité en production
- Combler les lacunes entre des outils SaaS qui ont déjà des intégrations Zapier
Si vous êtes un cabinet de conseil de cinq personnes qui veut un agent pour extraire des notes de réunions clients depuis Notion, les synthétiser et rédiger un email de suivi — Zapier ou Make fonctionneront très bien et vous y amèneront en une après-midi.
Le problème survient quand un outil choisi pour sa commodité dans un contexte à faibles enjeux est promu vers un processus à forts enjeux parce qu‘“il fonctionne déjà”. C’est le chemin vers les échecs silencieux et les mauvaises surprises.
Ce que “custom” signifie vraiment — et quand ça vaut la peine
“Custom” ne signifie pas repartir de zéro sans aucune dépendance. En pratique, cela signifie construire sur des frameworks agentiques ouverts (LangGraph, CrewAI, orchestration personnalisée) et une infrastructure que vous contrôlez, plutôt qu’à l’intérieur d’une plateforme d’automatisation tierce.
Les avantages sont concrets :
- Observabilité complète. Chaque appel LLM, invocation d’outil et décision est enregistré dans un format que vous définissez. Vous pouvez retracer exactement pourquoi un agent a effectué une action spécifique.
- Gestion déterministe des erreurs. Vous écrivez la logique de retry, les chemins de fallback, les déclencheurs human-in-the-loop. L’agent se comporte selon vos règles, pas le gestionnaire d’erreurs générique de la plateforme.
- Les données restent où vous le décidez. Les agents custom peuvent fonctionner dans votre environnement cloud ou on-premise. Aucune donnée client ne passe par l’infrastructure Zapier ou Make.
- Le coût évolue linéairement avec l’usage, pas exponentiellement. Les coûts directs des API LLM sont prévisibles et typiquement bien inférieurs par run aux tarifs pass-through de la plateforme à volume élevé.
- Le comportement est figé. Vous contrôlez les versions de modèle, les prompts et les cycles de mise à jour. Rien ne change dans votre agent parce qu’un éditeur SaaS a poussé une mise à jour.
Le compromis est réel : le développement custom exige un temps de build plus long (des semaines, pas des heures), une spécification, et un propriétaire continu. Pour des processus véritablement à forts enjeux — qualification clients, extraction de données financières, communications réglementées, workflows multi-étapes où les échecs ont un coût réel — cet investissement se rentabilise généralement en quelques mois. Pour de simples tâches internes, c’est excessif.
Voir Build vs Buy : un cadre décisionnel pour les agents IA pour une approche structurée permettant de déterminer quand le développement custom est réellement justifié.
Une matrice de décision pratique
| Agent de plateforme (Zapier/Make) | Agent custom | |
|---|---|---|
| Vitesse de déploiement | Heures à jours | Semaines |
| Développement requis | Aucun | Oui |
| Coût par run à volume élevé | Élevé (tâche + majoration) | Faible (API directe) |
| Transparence des erreurs | Limitée | Complète |
| Contrôle des données | Hébergé sur la plateforme | Vous contrôlez |
| Fixation prompt/modèle | Limitée | Complète |
| Adapté pour | Faible volume, interne, faibles enjeux | Fort volume, orienté client, forts enjeux |
| Non adapté pour | Logique complexe, données réglementées, fort volume | Prototypage rapide, pas de ressources de développement |
Cette matrice simplifie, mais la logique sous-jacente tient : le choix doit suivre les enjeux du processus, pas la commodité des outils.
Pour en savoir plus sur les limites structurelles des plateformes no-code, Quand les builders d’agents IA no-code atteignent leur plafond couvre les schémas que nous observons le plus souvent.
Le tableau des coûts sur 12 mois
Les acheteurs comparent souvent le coût de construction (le custom est plus cher initialement) sans modéliser le tableau complet. Un agent custom construit une fois et fonctionnant pendant un an face à une solution de plateforme coûtant CHF X/mois à volume significatif est souvent très différent au sixième mois.
Les variables qui font basculer le calcul :
- Volume mensuel de runs
- Opérations moyennes par run
- Si le processus va croître (le volume reste rarement stable)
- Le coût d’un événement d’échec (un seul mauvais run qui envoie un devis erroné à 200 clients change entièrement les calculs)
Pour une analyse détaillée de comment ces chiffres s’accumulent réellement, Le coût réel des agents IA : TCO custom vs plateforme approfondit le modèle de coût total.
La vraie question pour votre processus spécifique
Quand un client vient nous voir avec “on pense à construire ça dans Zapier”, la première chose que nous demandons ne concerne pas l’outil. C’est : quel est le coût d’un mauvais run ? Quel est le volume mensuel attendu dans douze mois, pas aujourd’hui ? Certaines des données traitées appartiennent-elles à des clients ?
Ces trois questions résolvent généralement la décision plus rapidement que n’importe quelle comparaison de fonctionnalités.
Si vos réponses indiquent un agent de plateforme — utilisez-en un. Ce sont de bons outils pour ce pour quoi ils sont conçus. Si vos réponses indiquent quelque chose avec des enjeux et des volumes réels, l’automatisation de plateforme créera probablement une dette technique et un risque opérationnel qui dépassent la commodité de déploiement.
Notre travail de développement d’agents IA commence typiquement par ce type de cadrage : nous analysons le processus, les données, la tolérance aux échecs et le modèle de coûts avant de recommander une approche. Parfois, la réponse est “continuez à utiliser Zapier pour ça.” Souvent non.
Si vous évaluez une automatisation qui a dépassé le stade “proof of concept” et souhaitez une vue honnête sur l’adéquation du niveau d’outil aux enjeux, réservez un appel de 30 minutes avec nous. Nous analyserons le processus spécifique, le modèle de coûts, et vous dirons clairement quelle approche est pertinente — même si cela signifie garder ce que vous avez. Pas de pitch, juste l’analyse.