Quand une automatisation doit devenir industrielle

Le débat Zapier vs Make vs n8n occupe les forums, mais il pose la mauvaise question. Notre thèse : le passage de l'automatisation légère à l'orchestration industrielle se décide sur cinq critères mesurables — le volume d'événements, la criticité métier, l'observabilité, le coût à l'exécution et la reprise sur erreur. Pas sur une préférence d'outil, pas sur une habitude d'équipe.

Cette thèse est réfutable, et c'est voulu : les quatre plateformes étudiées — Zapier, Make, n8n, Trigger.dev — montent toutes en gamme. Le seuil d'industrialisation n'est donc pas une frontière entre outils : c'est le point où les patterns changent — file d'attente, export de logs, découpage, retries configurés et testés.

Chez Ownward, cette grille fait partie de notre façon de construire : mesurer d'abord, choisir ensuite. Les chiffres qui suivent — tous vérifiés le 12 août 2026 — posent cette mesure.

Aucune des quatre plateformes ne facture la même chose. Chaque éditeur facture ce que son moteur mesure — c'est une information d'architecture, pas un détail commercial.

Prenez un workflow de 10 étapes déclenché 10 000 fois par mois : environ 100 000 tâches côté Zapier, environ 100 000 opérations côté Make, exactement 10 000 exécutions côté n8n, un volume de secondes lié à la durée réelle de traitement côté Trigger.dev, plus 0,25 $ d'invocations. Quatre factures très différentes pour le même besoin.

Le pattern : au-delà de quelques milliers d'événements mensuels sur des flux multi-étapes, recalculez le même flux dans les quatre unités avant tout arbitrage — le coût réel ne se lit jamais sur le prix d'entrée.

La montée en volume ne casse pas les plateformes : elle déclenche des mécanismes de régulation documentés. C'est leur forme, pas leur existence, qui doit guider le dimensionnement.

Le pattern transversal : au-delà d'une centaine d'événements simultanés, l'exécution immédiate devient une file avec rejeu contrôlé. La bonne question n'est plus « l'outil tient-il ? » mais « le délai de résorption est-il compatible avec le métier ? » : 1 000 événements résorbés à une exécution par seconde, c'est 15 minutes de latence sur le dernier — acceptable pour une synchronisation de contacts, pas pour une confirmation de paiement.

Conseil pratique : chez un même éditeur, page tarifaire et page de limites peuvent afficher des chiffres de concurrence différents (constaté le 12 août 2026). Dimensionnez sur la documentation de limites, validez par un test de charge.

Un workflow qui tourne n'est pas un workflow observé. La rétention des logs d'exécution est le critère le plus souvent découvert trop tard — au moment de l'incident.

Le pattern : au-delà du nombre de jours d'audit exigé par votre métier, l'export des logs vers un stockage que vous contrôlez devient le niveau requis — quel que soit l'éditeur. En auto-hébergement n8n, ces défauts se lisent dans la configuration :

EXECUTIONS_DATA_PRUNE=true          # purge glissante activée par défaut
EXECUTIONS_DATA_MAX_AGE=336         # 14 jours de données d'exécution
EXECUTIONS_DATA_PRUNE_MAX_COUNT=10000
EXECUTIONS_TIMEOUT=-1               # aucun timeout par défaut
EXECUTIONS_MODE=queue               # file d'attente pour la montée en charge

Ce que ça coûte de ne rien faire — Un flux à 5 000 exécutions mensuelles avec 2 % d'échecs silencieux perd 100 événements par mois. Détecté au bout d'un trimestre, l'incident porte sur environ 300 événements dont la majorité des traces a expiré — la rétention standard des quatre plateformes, de 1 à 69 jours selon le plan, ne couvre pas un trimestre. Il reste la réconciliation manuelle, enregistrement par enregistrement, dans les systèmes sources.

Les quatre plateformes offrent une reprise sur erreur. Aucune ne l'active entièrement à votre place : la durabilité est un choix explicite d'ingénierie, pas une propriété émergente de l'outil.

• Zapier : autoreplay des runs en erreur sur Professional, Team et Enterprise, configurable au niveau du compte ou par Zap (« Always replay » / « Never replay ») ; l'autoreplay cible les runs en statut « errored », les arrêts de sécurité (« safely halted ») se traitent par rejeu manuel depuis l'historique, et la documentation publique reste qualitative sur le rythme des tentatives.
• Make : handler Retry qui conserve le message d'erreur et les mappings, et rejoue les erreurs temporaires (connexion, rate limit) — exemple documenté : 3 tentatives toutes les 15 minutes ; le stockage des exécutions incomplètes est désactivé par défaut et s'active scénario par scénario.
• n8n : « Retry on Fail » réglable nœud par nœud (Max Tries, Wait Between Tries en millisecondes), complété par des error workflows dédiés.
• Trigger.dev : retry déclaratif dans le code, avec backoff exponentiel, désactivé par défaut en environnement DEV à l'initialisation :

retry: {
  maxAttempts: 10,
  factor: 1.8,
  minTimeoutInMs: 500,
  maxTimeoutInMs: 30_000,
  randomize: true,
}

Le pattern : partout, la reprise se conçoit, se configure et se teste. Si un flux touche au chiffre d'affaires, le test de panne — couper l'API cible, observer le rejeu — appartient à la recette. C'est le critère qui sépare le plus nettement l'automatisation d'appoint de l'orchestration industrielle.

Cette grille condense les cinq critères en décisions concrètes : des seuils, jamais une marque — c'est la situation qui déclenche le changement de niveau.

Si deux lignes ou plus s'appliquent à un même flux, vous êtes déjà en zone industrielle. C'est le type d'audit que nous déroulons dans notre méthode : une journée suffit en général pour passer un portefeuille de flux au crible de ces sept lignes.

Cette grille suppose un volume et une criticité mesurables. Elle ne s'applique pas aux prototypes, aux POC ni aux migrations ponctuelles : là, l'outillage léger sans reprise configurée est le bon choix, et l'industrialiser serait du sur-engineering. Elle ignore aussi deux facteurs bien réels : la compétence de l'équipe — une équipe TypeScript n'aborde pas un outil visuel comme une équipe ops — et l'écosystème déjà en place (licences, connecteurs, habitudes de support). Enfin, les chiffres cités sont des tarifs et quotas publics au 12 août 2026 : ils évoluent, parfois différemment d'une page à l'autre chez un même éditeur. La grille reste valable ; les seuils exacts se revérifient à chaque décision.