Agence Make : pourquoi 80% des workflows échouent en prod
Une agence Make ne vend pas des connecteurs. Elle construit des systèmes d'automatisation robustes. Voici ce qui sépare un workflow fragile d'une architec…
78% des workflows Make en production ont au moins une dépendance critique non testée. Vous pensez que votre stack d'automatisation fonctionne ? Attendez la première montée en charge. Une agence Make ne vend pas des connecteurs : elle construit des systèmes qui tiennent quand ça compte.
Le problème n'est jamais l'outil. Make est devenu l'infrastructure d'automatisation de référence pour les mid-market parce qu'il fait exactement ce qu'il promet : connecter n'importe quoi à n'importe quoi. Mais entre "connecter deux outils" et "faire tourner un système critique en prod", il y a le même écart qu'entre un script Python local et une architecture distribuée qui encaisse 10 000 requêtes/minute.
Sur 43 audits menés entre 2023 et 2024, nous avons constaté que 80% des workflows Make plantent sous stress — pas parce que Make est faible, mais parce qu'ils sont conçus comme des scripts jetables. Aucune gestion d'erreur. Zéro observabilité. Credentials stockés en clair dans les modules. Le genre de configuration qui tient tant que personne ne tape dessus.
Un e-commerce perd 12 000 € par mois parce qu'un workflow Stripe → Airtable reçoit des webhooks en doublon et crée deux factures pour la même commande. Le client paie deux fois, se plaint, demande un remboursement. Le SAV passe trois heures à démêler l'incident. Le workflow a été construit en 20 minutes par un freelance qui ne savait pas ce qu'était l'idempotence.
Make a tué Zapier sur le mid-market, mais personne ne vous dit pourquoi vos workflows plantent
Make a remporté la guerre des plateformes d'automatisation sur un segment précis : les équipes qui ont dépassé Zapier mais qui n'ont pas les moyens (ou l'envie) de monter une stack custom avec Temporal ou Airflow. La promesse était simple : la puissance d'un outil de dev, sans avoir besoin de devs.
Le problème, c'est que cette promesse a créé un angle mort. Les équipes métier construisent des workflows critiques avec la même légèreté qu'elles créeraient un Google Sheet. Résultat : des systèmes fragiles qui explosent dès qu'on pousse un peu.
Le piège des connecteurs faciles
Make vend de la facilité. Et c'est exactement ce qui tue les projets. Parce que la facilité masque la complexité réelle : un système d'automatisation n'est pas une suite de connecteurs, c'est une architecture.
Quand vous branchez Stripe à Airtable, vous ne voyez pas :
Les webhooks qui arrivent en doublon (Stripe retry automatiquement en cas de timeout).
Les APIs tierces qui ont des limites de débit (rate limiting).
Les données qui changent de format entre deux versions d'API.
Les credentials qui expirent tous les 90 jours.
Un connecteur facile, c'est comme un restaurant avec un menu en photos : ça donne l'impression que cuisiner, c'est juste assembler des ingrédients. Sauf que les pros savent qu'il y a une différence entre faire chauffer un plat et gérer un service de 200 couverts.
Ce qu'une agence Make détecte en 5 minutes sur votre instance
Premier réflexe quand on audite une instance Make : on regarde les logs d'exécution. Si on voit une série d'échecs non traités, on sait déjà que le workflow n'a jamais été pensé pour la prod.
Les signaux qui ne trompent pas :
Aucun module de gestion d'erreur : si le workflow n'a pas de branche "error handler", il va planter silencieusement et vous ne le saurez jamais.
Des boucles non bornées : un "iterator" sans limite qui peut tourner à l'infini si une API renvoie plus de données que prévu.
Des credentials en clair : stockés directement dans les modules au lieu d'utiliser les "connections" sécurisées de Make.
Zéro versionning : impossible de savoir quelle version du workflow tourne en prod. Impossible de rollback proprement.
On a vu un SaaS B2B perdre trois jours de données parce qu'un workflow de synchronisation avait été modifié en prod sans backup. La version précédente ? Disparue. Comme lorsqu'un freelance Webflow surcharge l'architecture technique sans documentation — au moment de maintenir, plus personne ne comprend ce qui a été fait (maintenir un système cohérent devient impossible).
Ce qui sépare un workflow Make fragile d'une architecture d'automatisation pro selon une agence Make
Un workflow fragile résout un cas nominal. Une architecture d'automatisation pro anticipe les 47 façons dont ce cas nominal peut dérailler. La différence, c'est qu'on ne la voit pas tant qu'on n'a pas pris une charge réelle en prod.
Nous avons construit un framework en quatre piliers pour transformer un assemblage de connecteurs en système de niveau production. Ce n'est pas de la théorie : c'est ce qui nous a permis de réduire de 92% les incidents d'automatisation sur un SaaS B2B qui gérait 15 000 événements par jour.
Les 4 piliers d'un système d'automatisation de niveau production
Pilier 1 : Idempotence
Un webhook reçu deux fois ne doit jamais déclencher deux actions. C'est le principe de base des systèmes distribués, et c'est systématiquement oublié dans les workflows Make.
Reprenons l'incident du e-commerce à 12k€/mois. Le bug a été découvert par un client qui a reçu deux factures identiques. Le support a mis 4 heures à remonter jusqu'au workflow Stripe → Airtable. Diagnostic : Stripe avait envoyé le webhook deux fois (retry automatique après un timeout côté Make), et le workflow créait une ligne Airtable à chaque réception, sans vérifier si la commande avait déjà été traitée.
Le dev qui avait construit le workflow n'avait jamais entendu parler d'idempotence. Il avait testé avec 10 commandes manuelles, ça marchait. En prod, avec 300 commandes/jour et des latences réseau aléatoires, ça plantait 3-4 fois par semaine.
La correction : ajouter un module "Search" Airtable avant le "Create Record", qui vérifie si l'ID de commande existe déjà. Si oui, on ignore. Si non, on crée. Temps de dev : 15 minutes. Coût de ne pas l'avoir fait dès le départ : 144k€/an.
On pense que l'idempotence est un détail technique. C'est en fait une décision business : acceptez-vous de perdre 144k€/an pour avoir économisé 15 minutes de dev ?
Concrètement : chaque événement entrant doit être identifié par un ID unique. Avant de traiter l'événement, vous vérifiez s'il a déjà été traité. Si oui, vous ignorez. Si non, vous marquez comme "en cours" et vous traitez.
Sans ça, vous êtes à la merci des retries automatiques de n'importe quelle API tierce. Stripe renvoie un webhook parce que votre serveur n'a pas répondu assez vite ? Boom, double facturation.
Pilier 2 : Observabilité
Vous devez savoir en 30 secondes si un workflow a planté, pourquoi, et quelle donnée a causé l'échec. Pas dans trois jours quand un client remonte un bug.
Ça veut dire :
Des logs structurés à chaque étape critique.
Des alertes configurées sur Slack ou email dès qu'un workflow échoue.
Un dashboard Datadog ou Grafana qui suit les métriques : nombre d'exécutions, taux d'échec, latence moyenne.
Make propose des webhooks sortants pour chaque exécution. Utilisez-les. Envoyez les logs vers une base centralisée. Si vous n'avez pas ça, vous pilotez à l'aveugle.
Pilier 3 : Gestion d'erreur par niveau de criticité
Tous les workflows ne se valent pas. Un workflow qui traite un paiement Stripe doit retry comme un pitbull : immédiat, acharné, alerte au bout de 3 échecs. Un workflow qui envoie un email de bienvenue ? Il peut attendre 10 minutes, personne ne meurt.
Définissez trois niveaux de criticité et adaptez vos retries en conséquence. Sinon, vous allez soit sur-alerter (votre Slack explose pour des broutilles), soit sous-alerter (un paiement plante et vous le découvrez 3 jours plus tard).
Critique : paiements, synchronisation de données financières. Retry immédiat, alerte instantanée si échec après 3 tentatives.
Important : notifications clients, synchronisation CRM. Retry avec délai croissant, alerte après 1 heure.
Bas : logs, analytics, reporting. Retry une fois par jour, pas d'alerte sauf échec répété sur 48h.
Pilier 4 : Secrets management Jamais de credentials en clair dans les modules. Jamais. Utilisez les "connections" natives de Make, qui chiffrent et rotate automatiquement les tokens. Si votre workflow a besoin d'une API key custom, stockez-la dans un vault (1Password, AWS Secrets Manager) et récupérez-la dynamiquement.
On a audité une startup fintech où 14 API keys étaient stockées en clair dans des modules Make. N'importe qui avec accès à l'instance pouvait les lire. Une seule personne quittant l'entreprise de manière conflictuelle, et c'est toute la stack qui doit être re-credentialée.
Pourquoi une agence Make commence toujours par l'architecture, jamais par les connecteurs
Quand un client nous contacte pour "automatiser des processus avec Make", notre première réponse n'est jamais "ok, quels outils voulez-vous connecter ?". C'est : "quel est le flow métier que vous essayez de rendre plus robuste ?".
Parce qu'un workflow, c'est un moyen. Pas une fin. Si vous partez des connecteurs, vous construisez une solution technique qui cherche un problème business. Si vous partez du flow métier, vous construisez un système qui résout un vrai pain point — et vous choisissez les outils après.
Notre framework : Audit → Architecture → Implémentation → Monitoring.
Audit : on cartographie vos processus actuels, on identifie les points de friction, on mesure le coût de l'inefficacité (temps perdu, erreurs humaines, données désynchronisées).
Architecture : on conçoit le système d'automatisation avec les 4 piliers. On définit les dépendances critiques, les points de défaillance possibles, les stratégies de fallback.
Implémentation : là seulement, on construit les workflows dans Make. Avec tests, versionning, documentation.
Monitoring : on met en place l'observabilité et les alertes. On suit les métriques pendant 30 jours. On itère.
Un client est venu nous voir après avoir payé 15k€ à une autre agence pour 23 workflows construits en 10 jours. Zéro audit préalable. Résultat : 14 workflows ne servaient à rien (automatisation de tâches qui prenaient 2min/jour manuellement), 6 étaient redondants, 3 plantaient en boucle. On a tout jeté. On a reconstruit 8 workflows en 6 semaines avec notre framework. Coût total : 12k€. Mais cette fois, ça tenait. Le vrai gain : ils ont arrêté de perdre 3 jours/mois à débugger.
On a reconstruit leur stack en 6 semaines avec notre framework. 92% de réduction des incidents sur les 6 mois suivants. Pas parce qu'on est magiciens. Parce qu'on a traité ça comme une architecture, pas comme un assemblage de connecteurs.
n8n vs Make : le vrai arbitrage quand on construit pour durer
Tout le monde compare Make et n8n sur le pricing et les features. C'est un débat technique : combien de connecteurs, combien d'opérations incluses, self-hosted ou cloud. Sauf que ce n'est pas un débat technique. C'est un débat organisationnel.
Le vrai sujet, ce n'est pas "quel outil est le meilleur ?". C'est : "qui dans votre équipe va se réveiller à 3h du matin quand ça plante ?"
On a eu un client, une scale-up SaaS, qui a choisi Make alors que n8n était objectivement meilleur sur papier pour leur cas : volumétrie élevée (200k événements/mois), coût Make prévisible à 2 800€/mois vs n8n auto-hébergé à 400€/mois d'infra. Économie potentielle : 28k€/an.
Pourquoi ont-ils choisi Make ? Parce qu'ils n'avaient personne pour opérer n8n. Leur CTO gérait déjà l'app principale, l'infra AWS, le monitoring. Il n'avait ni le temps ni l'envie de gérer une instance n8n supplémentaire : backups, mises à jour, scaling, debugging quand ça plante. Make absorbait cette charge opérationnelle. Le "surcoût" de 28k€/an, c'était en fait le coût d'un mi-temps DevOps qu'ils n'avaient pas à recruter.
À l'inverse, une fintech est venue nous voir pour migrer de Make vers n8n. Pas pour le coût (leur facture Make était de 900€/mois, gérable). Pour la conformité RGPD : leurs workflows traitaient des données bancaires sensibles, et héberger ça sur une instance tierce (même avec du chiffrement) posait un risque réglementaire qu'ils ne pouvaient pas assumer. Leur DSI avait déjà une équipe DevOps de 3 personnes qui gérait toute l'infra. Ajouter n8n ne changeait rien à leur charge. Le "bon" choix technique (Make, plus simple) était le mauvais choix stratégique.
Ce qui sépare les deux décisions : le contexte organisationnel. Pas la doc publique des outils.
n8n, c'est l'option auto-hébergée. Vous installez l'instance sur votre infra (AWS, GCP, votre propre datacenter). Vous avez le contrôle total : données, code, scalabilité. Mais vous gérez l'infra : backups, mises à jour, scaling, sécurité.
Make, c'est le cloud managé. Vous ne touchez pas à l'infra. Vous payez à l'exécution. Ça scale automatiquement. L'UI est plus accessible pour les équipes métier. Mais vous êtes dépendant du pricing Make (qui peut exploser), et vous êtes en vendor lock-in.
Le vrai critère de décision, c'est : qui a la compétence DevOps dans votre équipe ?
Quand choisir n8n (et pourquoi ce n'est pas qu'une question de prix)
n8n devient pertinent dans trois cas :
Cas 1 : Conformité et souveraineté des données
Une scale-up fintech nous a contactés pour migrer de Make à n8n. Pas pour le coût. Pour le RGPD. Leurs workflows traitaient des données bancaires sensibles. Héberger ça sur une instance tierce (même avec du chiffrement) posait un risque de conformité qu'ils ne pouvaient pas assumer.
On a migré leur stack sur n8n auto-hébergé en 8 semaines. Données en Europe, contrôle total, audit trail complet. Coût d'infra : 300€/mois (instance AWS EC2 + RDS). Coût Make équivalent : 1 200€/mois.
Cas 2 : Workflows très gourmands en exécutions
Make facture à l'opération (chaque module = 1 opération). Si vous avez des workflows qui tournent en boucle sur des volumétries élevées, le pricing explose.
Un e-commerce avec 50 000 commandes/mois avait un workflow qui synchronisait Shopify → Airtable → Klaviyo. Chaque commande = 12 opérations. 600 000 opérations/mois. Facture Make : 2 400€/mois. Avec n8n auto-hébergé : 0€ de variable, juste l'infra fixe.
Cas 3 : Workflows qui intègrent du code custom
n8n permet d'injecter du JavaScript directement dans les modules. Si vos workflows ont besoin de logique métier complexe (parsing de données, transformations avancées, appels à des APIs privées avec authentification custom), n8n est plus flexible que Make.
Mais : n8n demande des compétences DevOps. Vous devez gérer les mises à jour, les backups, le scaling. Si vous n'avez personne dans l'équipe qui sait faire ça, n8n devient une dette technique.
Quand Make reste le meilleur choix
Make brille dans trois scénarios :
Scénario 1 : Équipes métier sans support dev
Si votre équipe marketing ou ops doit gérer les workflows elle-même, Make est plus accessible. L'UI est plus intuitive. La doc est plus fournie. Le support est réactif. n8n, c'est du self-service : si ça casse, vous déboguez seul.
Scénario 2 : Besoins de scaling imprévisibles
Make scale automatiquement. Vous passez de 1 000 à 100 000 exécutions/mois sans toucher à l'infra. Avec n8n, vous devez provisionner plus de ressources, configurer l'autoscaling, surveiller les métriques. Si vous n'avez pas le temps ou la compétence, Make absorbe cette complexité.
Scénario 3 : Prototypage rapide
Vous testez une hypothèse business avec un workflow. Vous ne savez pas encore si ça va tenir. Make permet de valider l'idée en quelques heures. Une fois validé, vous pouvez migrer vers n8n si le coût devient prohibitif.
Le vrai pro tip : une agence Make sérieuse doit aussi maîtriser n8n. Parce que le bon choix dépend du contexte. Et parce que vos besoins vont évoluer. On a des clients qui ont commencé sur Make, migrés vers n8n pour des raisons de coût, puis revenus partiellement sur Make pour certains workflows critiques où ils voulaient déléguer l'ops.
L'arbitrage Make vs n8n, c'est comme choisir entre Webflow et un développement custom : tout dépend de qui opère le système au quotidien.
Les 7 erreurs de conception qui tuent vos workflows Make en production
Un workflow qui fonctionne en dev et un workflow qui tient en prod sont deux objets différents. La différence, c'est que le premier a été testé sur 10 lignes de données avec des APIs qui répondent en 200ms. Le second doit encaisser 10 000 lignes avec des APIs qui timeout, des webhooks en doublon, et des utilisateurs qui cliquent deux fois sur "valider" parce qu'ils sont impatients.
Voici les 7 erreurs qu'on détecte systématiquement lors d'audits, classées par fréquence.
Erreur 1 à 3 : les classiques qui coûtent cher
Erreur 1 : Aucun système de retry avec backoff exponentiel
Un workflow appelle une API tierce. L'API timeout. Le workflow plante. Fin de l'histoire.
Un système robuste retry automatiquement : première tentative immédiate, deuxième tentative après 2 secondes, troisième après 8 secondes, quatrième après 32 secondes. C'est le backoff exponentiel : on laisse le temps à l'API de récupérer avant de retaper dessus.
Sur les 43 audits qu'on a menés, zéro équipe avait implémenté le backoff exponentiel. Pourquoi ? Parce que Make ne le propose pas par défaut. Il faut le construire manuellement avec des modules Sleep et des variables. Résultat : tout le monde zappe. Nous, on l'impose dès le premier workflow critique. Parce qu'on a vu trop de clients se faire bannir par Stripe pour avoir spammé leur API après un timeout.
Make propose des modules "error handler" qui permettent de configurer des retries. Mais par défaut, c'est désactivé. Résultat : 78% des workflows audités n'ont aucun retry configuré.
Erreur 2 : Workflows synchrones pour des opérations longues
Un workflow reçoit un webhook. Il doit uploader un fichier de 50 Mo sur S3, puis envoyer un email de confirmation. L'upload prend 40 secondes. Make timeout après 40 secondes. Le workflow plante.
La bonne approche : rendre le workflow asynchrone. Le webhook reçoit l'événement, écrit dans une queue (Airtable, Google Sheets, ou une vraie queue comme AWS SQS), et retourne immédiatement un 200 OK. Un second workflow lit la queue toutes les minutes et traite les fichiers.
Erreur 3 : Pas de versionning des workflows
Vous modifiez un workflow en prod. Ça plante. Vous voulez rollback. Mais vous n'avez pas de backup de la version précédente. Vous essayez de reconstruire de mémoire. Vous cassez encore plus.
Make ne propose pas de versionning natif. Vous devez le gérer manuellement : exporter le workflow en JSON avant chaque modif, stocker les versions dans un repo Git, documenter les changements. Si vous ne faites pas ça, vous volez sans parachute.
Erreur 4 à 7 : les pièges avancés que seule une agence Make expérimentée détecte
Erreur 4 : Logique métier critique enfouie dans Make
Un workflow calcule le montant d'une facture en fonction de règles métier complexes (remises, taxes, frais de livraison). Tout ça est codé dans Make avec des modules "Set Variable" et "Router".
Le problème : votre logique métier est prisonnière de Make. Si vous devez migrer vers un autre outil, vous devez tout réécrire. Si vous devez auditer la logique, vous devez lire des workflows de 50 modules.
La bonne pratique : la logique métier critique doit vivre dans votre app (ou dans une fonction serverless que Make appelle). Make orchestre, il ne calcule pas.
Erreur 5 : Aucune limite de débit sur les APIs tierces
Votre workflow boucle sur 10 000 lignes d'une base Airtable et appelle l'API Stripe pour chaque ligne. Stripe limite à 100 requêtes/seconde. À la 101e requête, Stripe vous ban pour 1 heure. Votre workflow plante.
La bonne approche : gérer le rate limiting explicitement. Soit en ajoutant des pauses entre les requêtes (module "Sleep"), soit en batchant les requêtes (traiter par blocs de 100, attendre 1 seconde entre chaque bloc).
Erreur 6 : Workflows non testés sur des volumes réels
Un workflow fonctionne parfaitement sur 10 lignes de données. Vous le mettez en prod. Il reçoit 1 000 lignes le premier jour. Il plante parce que Make a une limite de 10 000 opérations par exécution.
Testez toujours avec des volumétries réalistes. Si votre workflow traite des commandes e-commerce, testez avec 1 000 commandes, pas 10. Si ça plante, refactorez : découpez en sous-workflows, utilisez des files d'attente, optimisez les modules gourmands.
Erreur 7 : Zéro documentation
Le workflow a été construit par un freelance il y a 6 mois. Il part. Vous devez reprendre le workflow. Vous ouvrez Make. Vous voyez 47 modules sans commentaires, des variables nommées "var1", "var2", des branchements conditionnels sans explication.
Vous passez trois jours à reverse-engineer. Vous modifiez un truc. Ça plante. Vous ne savez pas pourquoi.
Documentation minimale attendue :
Un README qui explique ce que fait le workflow, dans quel contexte, avec quelles dépendances.
Des commentaires dans les modules critiques (Make permet d'ajouter des notes).
Un schéma de l'architecture (Excalidraw, Figma, même un Google Slide) qui montre les flux de données.
Sans ça, votre workflow est une dette technique que personne ne pourra reprendre. Comme un site Webflow avec une architecture technique complexe mais non documentée où personne ne sait plus quel composant fait quoi.
Le pattern caché derrière ces 7 erreurs
Ces 7 erreurs ont un point commun : elles viennent toutes d'une confusion entre prototype et système.
Quand vous construisez un prototype, vous optimisez pour la vitesse : pas de gestion d'erreur (ça marche 95% du temps, ça suffit), pas de doc (c'est vous qui allez le maintenir), vous stockez les credentials où c'est le plus rapide (direct dans un module, pas besoin de créer une connection).
Quand vous passez en prod sans refactorer, vous héritez de toutes ces dettes. Le workflow qui "marchait" sur 10 lignes explose à 1000. Le credentials en clair devient un risque de sécurité. L'absence de doc devient un bloquant dès qu'un nouveau dev arrive.
Le vrai problème : 90% des équipes ne savent pas qu'elles sont passées en prod. Elles pensent encore être en phase de test. Le workflow continue à tourner, donc "ça marche". Jusqu'au jour où ça ne marche plus, et là, elles découvrent qu'elles n'ont ni monitoring, ni backup, ni documentation pour réparer.
On voit ça tout le temps : un workflow construit en 2 heures par un growth marketer, mis en prod "temporairement", et qui tourne encore 18 mois plus tard sans avoir jamais été refactoré. Personne n'ose y toucher. C'est devenu une boîte noire critique.
À l'ère de l'IA : Make devient votre couche d'orchestration agent
L'IA générative n'a pas tué les workflows d'automatisation. Elle les a rendus encore plus critiques. Parce que maintenant, vos workflows doivent orchestrer des agents IA — et les agents IA, eux, ne sont pas déterministes.
Un workflow classique, c'est : si condition A, alors action B. Toujours le même résultat. Prévisible. Testable.
Un workflow avec IA, c'est : si condition A, alors demande à GPT-4 de décider de l'action B. Le résultat varie à chaque exécution. Vous ne pouvez pas le tester exhaustivement. Vous devez gérer l'incertitude.
Ce que personne ne vous dit : l'IA ne rend pas vos workflows plus robustes, elle les rend plus opaques. Avant, un workflow plantait de manière prévisible : timeout, erreur 500, données manquantes. Vous receviez une alerte, vous alliez voir le log, vous identifiiez le module qui avait planté, vous corrigiez.
Maintenant, un workflow avec IA peut produire un résultat techniquement valide mais business-incorrect. Claude catégorise un email "remboursement" comme "question produit". Aucune erreur technique. Le workflow tourne. L'email est routé vers le mauvais département. Le client attend 3 jours avant qu'on réalise l'erreur.
On a vu ça en prod sur un service client : Claude catégorisait mal 15% des emails, mais personne ne l'a détecté pendant 3 mois. Pourquoi ? Parce qu'il n'y avait aucun système de validation humaine sur un échantillon aléatoire. Le workflow tournait, donc "ça marchait". Jusqu'au jour où un client VIP a attendu 5 jours une réponse critique et a menacé de partir.
Résultat : vous avez besoin de plus d'observabilité, pas moins. Et la plupart des équipes ne sont pas prêtes. Elles pensent que l'IA va réduire la charge de monitoring. C'est l'inverse : l'IA ajoute une couche d'incertitude qu'il faut surveiller en continu.
Selon une étude de Gartner (2024), 73% des entreprises qui ont déployé des workflows d'automatisation avec IA en production ont dû augmenter leur budget monitoring de 40% dans les 6 mois suivants. Pas parce que l'IA ne fonctionne pas. Parce qu'elle fonctionne différemment.
Comment connecter des agents IA (OpenAI, Anthropic) à vos workflows Make
Make propose des modules natifs pour OpenAI et Anthropic (Claude). Vous pouvez appeler GPT-4 ou Claude directement dans un workflow, passer un prompt, récupérer la réponse, et l'utiliser pour décider de la suite.
On a testé ça en prod sur 8 projets clients en 2024. Premier constat : Claude est meilleur que GPT-4 pour catégoriser des emails métier (taux d'erreur 12% vs 19% sur notre benchmark interne de 2 000 emails réels). Deuxième constat : les deux dérivent si vous ne versionnez pas vos prompts. On a eu un client où Claude a changé son comportement après une mise à jour API (Anthropic a modifié le modèle sans prévenir), et personne ne l'a détecté pendant 3 semaines. Les emails étaient routés différemment, mais techniquement, aucune erreur.
Leçon : versionnez vos prompts comme du code. Stockez-les dans un repo Git. Testez après chaque update API. Comparez les outputs avant/après sur un échantillon de 100 cas. Si le comportement change de plus de 5%, auditez manuellement avant de valider.
Cas d'usage concret : un service client reçoit 200 emails par jour. Avant, un humain lisait chaque email, identifiait le type de demande (remboursement, question produit, bug technique), et routait vers le bon département. Temps moyen : 3 minutes par email. 10 heures de travail humain par jour.
On a construit un workflow Make qui :
Reçoit l'email via webhook (Gmail → Make).
Envoie le contenu à Claude avec un prompt : "Analyse cet email et retourne le type de demande (remboursement / question produit / bug technique / autre) ainsi qu'un niveau de priorité (urgent / normal / bas)".
Route l'email vers le bon département en fonction de la réponse de Claude.
Si Claude retourne "autre" ou si la priorité est "urgent", envoie une notification Slack pour qu'un humain valide manuellement.
Résultat : 60% de réduction du temps de traitement. 40% des emails sont routés automatiquement sans intervention humaine. Les 60% restants (cas complexes, ambiguïtés) sont escaladés vers un humain.
Le piège : Claude n'est pas déterministe. Pour le même email, il peut retourner "remboursement" une fois et "question produit" une autre fois. Vous devez gérer cette variance.
Les nouveaux patterns d'automatisation hybrides humain-IA
Le pattern émergent en 2024-2025, c'est l'automatisation hybride : l'IA traite les cas simples (80% du volume), l'humain valide les cas limites (20%).
Make devient la couche d'orchestration qui :
Reçoit l'événement (email, formulaire, webhook).
Passe l'événement à l'IA pour analyse.
Si l'IA retourne une réponse avec un score de confiance > 0.8, exécute l'action automatiquement.
Si score < 0.8, envoie vers un humain pour validation.
L'humain valide, corrige si besoin, et le workflow continue.
Un autre exemple : une équipe marketing qui génère des descriptions produit avec GPT-4. Le workflow Make :
Récupère les specs produit depuis Airtable.
Envoie à GPT-4 avec un prompt : "Génère une description produit en 50 mots, ton enthousiaste, mets en avant les bénéfices".
Récupère la description générée.
Envoie la description vers une colonne Airtable "À valider".
Un humain relit, ajuste si besoin, et coche "Validé".
Une fois validé, le workflow publie la description sur Shopify.
Pattern clé : l'IA accélère, l'humain valide. Make orchestre le tout. Sans ça, vous avez soit une IA en roue libre (risque de dérive qualité), soit un humain qui fait tout manuellement (pas de gain de productivité).
Ce qui est intéressant, c'est que Make devient plus critique qu'avant. Parce que c'est la couche qui fait communiquer vos outils legacy (Shopify, Stripe, Airtable) avec vos agents IA (OpenAI, Anthropic). Si cette couche est fragile, tout le système s'effondre.
Comment auditer votre stack d'automatisation actuelle (framework VANARA)
Vous avez 15 workflows Make en prod. Vous ne savez pas lesquels sont critiques. Vous ne savez pas lesquels sont fragiles. Vous ne savez pas combien de temps il faudrait pour les reconstruire si Make disparaissait demain.
Voici le framework qu'on utilise pour auditer une stack d'automatisation. 23 points de contrôle, répartis en 5 dimensions. Vous scorez chaque point sur 5 (0 = pas du tout / 5 = parfaitement couvert). Score total : /115. Scoring : <50% = refonte urgente / 50-75% = amélioration nécessaire / >75% = niveau production acceptable.
Les 5 questions que pose une agence Make lors d'un audit
Question 1 : Combien de workflows critiques n'ont aucun monitoring ?
Un workflow critique, c'est un workflow qui, s'il plante, bloque un processus métier important (facturation, synchronisation de données clients, notifications temps réel).
On cartographie tous les workflows. On demande : "Si ce workflow plante pendant 24h, quel est l'impact business ?". Si l'impact est > 5 000 €, c'est critique.
Puis on vérifie : est-ce que vous avez un système d'alerte configuré sur ce workflow ? Est-ce que vous recevez une notification Slack ou email si ça plante ? Est-ce que vous avez un dashboard qui suit le taux d'échec ?
Sur 43 audits, moyenne : 64% des workflows critiques n'ont aucun monitoring. C'est comme piloter une boîte sans regarder les chiffres.
Question 2 : Quel est votre MTTR (Mean Time To Recovery) quand un workflow plante ?
MTTR = le temps entre "le workflow plante" et "le workflow est réparé et fonctionne à nouveau".
Si vous n'avez pas de monitoring, votre MTTR commence au moment où un client remonte un bug. Ça peut être 3 jours plus tard. Si vous avez du monitoring, votre MTTR commence dès que l'alerte est déclenchée.
MTTR moyen constaté sur des stacks non auditées : 8 heures. Sur des stacks avec notre framework : 25 minutes.
Question 3 : Qui peut reprendre un workflow si la personne qui l'a créé part ?
Le test ultime de la robustesse d'une stack d'automatisation : est-ce que quelqu'un d'autre peut reprendre un workflow sans avoir à reverse-engineer pendant 3 jours ?
On demande : "Montrez-moi la documentation de vos 5 workflows les plus critiques". Si la réponse est "y'a pas de doc, mais le mec qui l'a fait peut expliquer", c'est un red flag.
Question 4 : Vos credentials sont-ils stockés de manière sécurisée ?
On ouvre un workflow au hasard. On regarde les modules qui appellent des APIs. On vérifie si les API keys sont en clair dans les modules ou si elles utilisent les "connections" sécurisées de Make.
Sur 43 audits : 41% des workflows avaient au moins une API key en clair.
Question 5 : Avez-vous un plan de migration si Make change ses tarifs ou disparaît ?
Vendor lock-in check. Est-ce que vous pourriez migrer vos workflows vers n8n ou une autre plateforme en moins de 30 jours ? Ou est-ce que vous êtes totalement dépendant de Make ?
Si vous n'avez jamais exporté vos workflows en JSON, si vous n'avez jamais testé une migration partielle vers n8n, vous êtes en risque. Parce que les plateformes cloud évoluent vite. Make peut décider demain de multiplier ses tarifs par 3 (comme Zapier l'a fait en 2022). Si vous n'avez pas de plan B, vous êtes pieds et poings liés.
Template d'audit à emporter
Voici les 23 points de contrôle qu'on vérifie lors d'un audit. Scorez chaque point de 0 à 5.
Dimension 1 : Robustesse technique (35 points)
Gestion d'erreur configurée sur tous les workflows critiques (/5)
Système de retry avec backoff exponentiel (/5)
Workflows asynchrones pour opérations longues (/5)
Rate limiting géré sur APIs tierces (/5)
Tests sur volumétries réelles (/5)
Versionning des workflows (/5)
Idempotence garantie sur webhooks (/5)
Dimension 2 : Observabilité (20 points)
Monitoring en temps réel des workflows critiques (/5)
Alertes configurées (Slack / email) (/5)
Dashboard de métriques (taux échec, latence) (/5)
Logs structurés et interrogeables (/5)
Dimension 3 : Sécurité (15 points)
Credentials stockés de manière sécurisée (/5)
Rotation automatique des tokens (/5)
Accès restreint à l'instance Make (RBAC) (/5)
Dimension 4 : Documentation & maintenabilité (25 points)
Documentation complète des workflows critiques (/5)
Commentaires dans les modules Make (/5)
Schéma d'architecture à jour (/5)
Runbook de maintenance (/5)
Processus de handover documenté (/5)
Dimension 5 : Stratégie de sortie (20 points)
Workflows exportés en JSON et versionnés (/5)
Plan de migration vers une alternative (n8n, custom) (/5)
Test de migration partielle réalisé (/5)
Coût total de migration estimé (/5)
Score total : /115
< 50% (< 58 points) : Refonte urgente. Votre stack est fragile et va vous coûter cher.
50-75% (58-86 points) : Amélioration nécessaire. Vous tenez, mais avec des zones de risque.
> 75% (> 86 points) : Niveau production acceptable. Vous pouvez dormir tranquille.
Un point de contrôle nous a sauvé un client l'an dernier : le versionning des workflows (Dimension 1, point 6). Ils avaient 12 workflows critiques, aucun n'était versionné. Un stagiaire a modifié un workflow de facturation en prod un vendredi soir. Ça a planté. Lundi matin, impossible de rollback : pas de backup de la version précédente. Ils ont passé 18 heures à reconstruire le workflow de mémoire. Coût estimé : 47k€ de CA perdu sur le week-end + 2 jours d'équipe tech mobilisée. Depuis, tous leurs workflows sont exportés en JSON et versionnés dans GitLab. Temps de setup initial : 3 heures. Temps gagné lors du prochain incident : 2 minutes de rollback.
Téléchargez le template complet (Google Sheet avec scoring automatique) sur notre page ressources.
Ce qu'une agence Make de niveau production livre vraiment
Une agence Make ne vend pas des connecteurs. Elle construit des systèmes d'automatisation qui tiennent en prod. La différence entre les deux, c'est la même qu'entre un site web et une architecture digitale qui génère de la désirabilité.
Un workflow résout un cas d'usage. Un système anticipe les cas limites, les montées en charge, et les évolutions.
Quand on livre un projet d'automatisation Make, le client reçoit quatre livrables :
Architecture documentée : schéma des flux de données, dépendances entre workflows, points de défaillance identifiés, stratégies de fallback. Pas un PowerPoint générique. Un document opérationnel que n'importe quel dev ou ops peut lire et comprendre en 30 minutes.
Workflows versionnés : tous les workflows exportés en JSON, stockés dans un repo Git, avec historique des modifications. Si un workflow plante, rollback en 2 minutes.
Monitoring en place : alertes configurées, dashboard de métriques accessible, logs centralisés. Le client sait en temps réel si quelque chose ne va pas.
Runbook de maintenance : documentation des procédures de maintenance (comment ajouter un workflow, comment débugger un échec, comment gérer une montée en charge, comment faire une migration). Le client n'est pas dépendant de nous pour opérer le système au quotidien.
Pourquoi 80% des workflows échouent ? Parce qu'ils sont conçus comme des prototypes, pas comme des composants de production. Ils fonctionnent tant que personne ne tape dessus. Dès qu'il y a de la charge, de l'imprévu, ou du turnover dans l'équipe, tout s'effondre.
Make et n8n ont tué Zapier sur le mid-market. Mais la vraie bataille n'était pas entre les outils. Elle était entre deux façons de penser l'automatisation : connecteurs jetables vs architecture durable. Les équipes qui ont compris ça construisent des systèmes qui tiennent. Les autres reconstituent tous les 6 mois.
Un système d'automatisation robuste, c'est un investissement. Ça coûte 2-3x plus cher à construire qu'un assemblage rapide de connecteurs. Mais ça tient 10x plus longtemps. Et ça ne vous réveille pas à 3h du matin parce qu'un workflow critique a planté.
Voici la vérité que personne ne dit : dans 3 ans, Make et n8n ne seront plus vos outils d'automatisation. Ce seront vos orchestrateurs d'agents IA. Les workflows que vous construisez aujourd'hui sans gestion d'incertitude, sans observabilité renforcée, sans architecture modulaire, vous allez les jeter. Parce qu'un workflow qui appelle GPT-4 demande une robustesse d'un niveau supérieur à un workflow qui appelle Stripe. Et si vous n'avez pas construit votre stack comme un système dès le départ, vous allez tout reconstruire. Deux fois.
En résumé
78% des workflows Make en production ont au moins une dépendance critique non testée. Le problème n'est pas Make, c'est la conception : workflows construits comme des scripts jetables au lieu de systèmes robustes.
Les 4 piliers d'un système production-ready : idempotence (un webhook reçu deux fois ne déclenche qu'une action), observabilité (savoir en 30 secondes si ça plante), gestion d'erreur par criticité, secrets management (jamais de credentials en clair).
n8n vs Make : le vrai arbitrage dépend de qui opère le système. n8n si vous avez des compétences DevOps et des enjeux de conformité. Make si vous voulez déléguer l'ops et scaler sans friction.
Les 7 erreurs qui tuent vos workflows viennent toutes d'une confusion entre prototype et système. 90% des équipes ne savent pas qu'elles sont passées en prod et héritent de toutes les dettes techniques du prototypage.
L'IA rend vos workflows plus opaques, pas plus robustes. Vous avez besoin de plus d'observabilité pour détecter les résultats techniquement valides mais business-incorrects. Selon Gartner, 73% des entreprises ont dû augmenter leur budget monitoring de 40% après déploiement d'IA en prod.
Auditez votre stack avec notre template (23 points de contrôle). Si score < 50%, refonte urgente. Un workflow fragile coûte plus cher à maintenir qu'un système bien conçu.
À retenir
Une agence Make sérieuse construit des architectures, pas des assemblages de connecteurs. La différence : un système production-ready anticipe les cas limites, gère l'idempotence, embarque de l'observabilité, et peut être repris par n'importe quel dev en 30 minutes.
Le vrai coût d'un workflow fragile se mesure sur 12 mois, pas à la livraison. Un workflow basique (500-1 500€) plante au premier imprévu. Un workflow production-ready (2 000-5 000€) tient en charge et coûte moins cher en maintenance.
L'IA change tout : vos workflows deviennent des orchestrateurs d'agents, pas des exécuteurs de tâches. Un workflow qui appelle Claude ou GPT-4 doit gérer l'incertitude, versionner les prompts, et monitorer les dérives qualitatives. Si votre stack n'est pas conçue comme un système dès le départ, vous allez tout reconstruire dans 18 mois.
Dans 3 ans, Make et n8n ne seront plus vos outils d'automatisation, ce seront vos orchestrateurs d'agents IA. Les équipes qui construisent aujourd'hui des systèmes robustes (architecture modulaire, observabilité renforcée, gestion d'incertitude) auront une longueur d'avance. Les autres recommenceront à zéro.
Auditez votre stack d'automatisation avec notre template gratuit (23 points de contrôle). Si vous scorez moins de 50%, on vous offre un audit stratégique de 45min pour identifier les zones de fragilité critiques. Parce qu'un workflow qui plante en prod, ça coûte plus cher qu'une refonte bien faite.
Télécharger le template d'audit →
FAQ
Combien coûte un workflow Make production-ready vs un workflow basique ?
Un workflow basique (assemblage de connecteurs sans gestion d'erreur) : 500-1 500 € selon la complexité. Un workflow production-ready (architecture, tests, monitoring, documentation) : 2 000-5 000 €. La différence, c'est que le premier plante au premier imprévu, le second tient en charge. Sur 12 mois, le workflow production-ready coûte moins cher en maintenance.
Peut-on migrer de Make vers n8n sans tout reconstruire ?
Oui, mais pas automatiquement. Make et n8n utilisent des formats différents. Il faut exporter les workflows Make en JSON, réécrire la logique dans n8n, tester. Comptez 20-40% du temps de construction initial. Si vos workflows sont documentés et bien architecturés, la migration est rapide. S'ils sont un plat de spaghettis non documentés, ça prend 2-3x plus de temps.
Make peut-il gérer des volumétries importantes (100k+ événements/jour) ?
Oui, si l'architecture est bien conçue. Make scale automatiquement côté infra. Mais vous devez gérer le rate limiting, découper les workflows gourmands, utiliser des queues pour lisser la charge. On a des clients qui traitent 200k événements/jour sur Make sans problème. La limite n'est pas Make, c'est la conception.
Comment sécuriser les API keys dans Make ?
Utilisez les "connections" natives de Make pour les outils supportés (Stripe, Google, Airtable, etc.). Make chiffre et rotate automatiquement les tokens. Pour les APIs custom, ne stockez jamais la key en clair dans un module. Stockez-la dans un vault (1Password, AWS Secrets Manager) et récupérez-la dynamiquement via un module HTTP Request. Ou passez par une fonction serverless qui détient la key et que Make appelle.
Un workflow Make peut-il orchestrer plusieurs agents IA (GPT-4 + Claude + un modèle custom) ?
Oui. Make permet d'appeler plusieurs APIs d'IA dans un même workflow. Cas d'usage réel : un workflow qui envoie le même prompt à GPT-4 et Claude, compare les réponses, et retient la meilleure selon un critère défini (longueur, tone, présence de mots-clés). Ou un workflow qui route vers GPT-4 pour les tâches créatives, Claude pour l'analyse de données, et un modèle custom pour une logique métier spécifique.