Les trois questions qui décident du résultat sont rarement posées au début : ce que le scénario coûtera par passage, ce qui préviendra le jour où il tombera, et ce qui se passera quand il tombera au milieu du flux. Voici comment nous les traitons, avec les modèles de facturation à jour de Make, n8n et Zapier.
Ce qui mérite une automatisation, et ce qui n'en mérite pas
Trois conditions doivent tenir ensemble : la tâche est répétitive, elle est stable, et son échec est détectable. Si l'une manque, l'automatisation coûte plus qu'elle ne rapporte.
Répétitive veut dire suffisamment fréquente pour amortir la construction et la surveillance. Une tâche exécutée deux fois par mois pendant trois minutes représente un peu plus d'une heure par an. Un scénario correct, avec gestion d'erreur et supervision, ne se construit pas en une heure et ne se maintient pas gratuitement. Le calcul est vite fait, et il conclut souvent à l'inverse de ce qu'on espérait en le lançant.
Stable veut dire que les règles ne changent pas tous les trimestres. Une automatisation encode un processus dans un graphe de connecteurs, et changer le processus impose de rouvrir le graphe. Un service en pleine réorganisation n'est pas un bon candidat, même si la tâche est fréquente. Il vaut mieux attendre que le processus se soit posé, quitte à le faire à la main six mois de plus.
Détectable veut dire que quelqu'un s'apercevrait qu'elle n'a pas tourné. C'est la condition la plus négligée des trois. Une synchronisation qui alimente un tableau consulté chaque matin se remarque en vingt-quatre heures. Une relance automatique envoyée à des prospects se remarque au bout de combien de temps ? Si la réponse honnête est qu'on ne sait pas, l'automatisation doit être livrée avec sa supervision, ou ne pas être livrée.
Reste l'anti-modèle : automatiser un processus cassé. Le résultat est un processus cassé plus rapide, avec plus de volume et moins de gens dans la boucle pour repérer l'anomalie. Avant d'automatiser une ressaisie, la vraie question est de savoir pourquoi cette ressaisie existe, et si l'information ne pourrait pas remonter directement à la source.
Le coût à l'usage : trois unités de facturation, trois factures différentes
La ligne qui explose sans prévenir n'est pas le prix affiché du plan, c'est l'unité facturée, parce qu'elle se multiplie par le volume.
Zapier facture la tâche, définie comme une action réussie dans un Zap. Les déclencheurs ne consomment rien, pas plus que les filtres, les chemins, le Formatter, le Delay, le Looping, le Digest ou le Storage. Une action en erreur n'est pas comptée. En revanche, un rejeu complet recompte les étapes déjà réussies, et certaines briques coûtent plus d'une tâche : Code by Zapier selon la durée d'exécution, un appel d'outil via Zapier MCP pour deux tâches, un routage de lead pour cinq. Le plan gratuit donne cent tâches par mois et des Zaps à deux étapes, soit un déclencheur et une action.
Make facture le crédit, unité qui a remplacé les opérations le 27 août 2025. Chaque action de module compte pour un crédit, tandis que les routeurs et les directives de gestion d'erreur n'en consomment pas. Pour les modules d'intelligence artificielle, la consommation varie selon les jetons utilisés, ce qui rend la facture nettement moins prévisible que sur les modules classiques. Le plan gratuit donne mille crédits par mois.
n8n facture l'exécution, définie comme un passage complet du workflow, quel que soit le nombre d'étapes et le volume de données traité. C'est la différence structurelle de la plateforme, et elle change tout sur les workflows longs.
Traduisez cela en arithmétique. Un processus de quinze étapes exécuté mille fois par mois, à supposer qu'il s'agisse d'un déclencheur et de quatorze actions d'application facturables, consomme quinze mille crédits sur Make, où le module déclencheur compte, quatorze mille tâches sur Zapier, où il ne compte pas, et mille exécutions sur n8n, quel que soit le nombre d'étapes. Remplacez une seule de ces quinze étapes par un filtre, un routeur ou un Formatter et les deux premiers chiffres baissent d'autant, car c'est la composition du scénario et non son nombre d'étapes qui fixe la facture. Ajoutez une boucle : un itérateur qui éclate une liste de cinquante éléments et exécute trois modules par élément produit cent cinquante unités par passage sur une facturation à l'étape. C'est ce mécanisme, et non le prix du plan, qui fait passer une facture de quelques euros à quelques centaines.
Deux vérifications valent largement le temps qu'elles prennent : comment votre plateforme compte un déclencheur périodique qui ne trouve rien, et quel plafond déclenche le passage au palier tarifaire supérieur. Ce sont deux lignes qui creusent une facture sans produire un seul résultat utile.
n8n auto-hébergé contre Make en SaaS : l'arbitrage honnête
Et existe-t-il chez vous une personne nommée qui tiendra la machine, appliquera les mises à jour et interviendra quand elle tombera un week-end ? Nous ne prenons pas d'astreinte : nos réponses partent par écrit sous vingt-quatre heures ouvrées, ce qui ne remplace pas quelqu'un de disponible chez vous. Si la réponse à la seconde est non, l'auto-hébergement ne fera économiser aucun argent : il transformera une dépense en risque.
L'échec silencieux, les reprises, et le moment où du code coûte moins cher
Une automatisation ne tombe presque jamais bruyamment. Elle s'arrête. Le jeton d'un compte connecté expire côté fournisseur, une application est déconnectée par un changement de mot de passe, Remplacer, dans localContent.blocks[3].body, le segment allant de « un scenario est desactive a la suite d'erreurs repetees » jusqu'a « Une alerte branchee sur l'erreur ne verra rien passer. » par :
un webhook continue d'être appelé par un émetteur qui a changé d'adresse, un déclencheur périodique ne remonte plus jamais rien. Ces deux derniers cas ne signalent aucune erreur, puisqu'il n'y a plus d'exécution du tout, et une alerte branchée sur l'erreur ne verra rien passer. Les deux premiers dépendent de la plateforme : Make envoie par défaut un e-mail quand une erreur empêche un scénario d'aboutir et quand il désactive lui-même un scénario à cause d'erreurs répétées. n8n ne prévient personne : sa désactivation automatique après exécutions en échec est inactive par défaut et n'envoie aucun e-mail, il faut brancher un workflow d'erreur pour être averti.
(La phrase precedente du body, « Le jeton d'un compte connecte expire cote fournisseur, une application est deconnectee par un changement de mot de passe, », reste inchangee : elle fournit les « deux premiers » cas. La suite du bloc, « Le mecanisme qui repond a cela est le signal de vie... », s'enchaine sans modification.)
Le mécanisme qui répond à cela est le signal de vie. Chaque passage écrit un horodatage et un compteur d'éléments traités dans un endroit extérieur à la plateforme. Un observateur indépendant alerte quand l'horodatage dépasse la fréquence attendue, ou quand le compteur reste à zéro alors que du volume était attendu. Un scénario qui tourne parfaitement en traitant zéro ligne est en panne, et c'est la panne la plus difficile à voir.
Vient ensuite la reprise. La question à poser sur chaque flux est celle de l'idempotence : si ce passage est rejoué, crée-t-il un doublon ? Un assemblage de connecteurs n'est idempotent que si on l'a construit pour l'être, avec une recherche avant écriture ou une clé stable portée par la donnée d'origine. Sans cela, une reprise après incident double des enregistrements, envoie deux fois le même message et abîme durablement la confiance interne dans l'outil. Prévoyez aussi une destination pour ce qui n'a pas pu être traité, sinon ces éléments disparaissent avec le journal d'exécution, dont la rétention est limitée.
Reste la limite de l'exercice. Un assembleur excelle sur le déclenchement, l'authentification aux API tierces et le passage de données entre systèmes. Il devient un mauvais outil dès que la logique devient l'essentiel du travail : conditions imbriquées, transformations complexes, itérations sur des milliers de lignes, règles métier qu'il faudrait tester. À ce stade, un petit service que vous possédez, appelé par une seule requête depuis le scénario, coûte moins en unités facturées, se relit, se teste et se versionne. Nous le disons quand c'est le cas, y compris quand cela réduit la mission.
Nous sommes basés à Dijon et travaillons à distance, par écrit, avec une réponse sous vingt-quatre heures ouvrées.
