n8n ou Make : cinq étapes peuvent multiplier la facture sans nouveau scénario

|Auteur: Équipe éditoriale de QUASA|5 min de lecture
n8n ou Make : cinq étapes peuvent multiplier la facture sans nouveau scénario

Pour un flux hypothétique de cinq étapes, n8n compte un lancement complet comme une exécution, quelle que soit sa longueur. Chez Make, les modules courants consomment généralement un crédit par opération : si les cinq modules agissent chacun une fois, le même passage utilise cinq crédits. Allonger ce parcours peut donc accroître la consommation de Make sans créer de scénario.

Pour choisir, il faut rapprocher la fréquence des lancements du nombre d’actions réellement effectuées à chaque passage. Un parcours court et simple peut convenir à Make ; un flux long ou qui traite des lots mérite un calcul précis des crédits face aux exécutions n8n. Si l’auto-hébergement entre en jeu, le temps consacré à l’exploitation fait aussi partie du coût.

Le nombre de modules ne suffit pas à prévoir l’usage

Chez n8n, l’unité des offres payantes est l’exécution du workflow entier. Ajouter une transformation ou un envoi à un lancement existant ne crée pas une exécution supplémentaire à lui seul. En revanche, déclencher le même workflow plus souvent augmente le compteur : la fréquence et la longueur du parcours jouent donc des rôles différents.

Chez Make, un module peut agir plusieurs fois au cours d’un seul passage. La documentation des opérations Make distingue le déclencheur, qui s’exécute une fois même s’il produit plusieurs lots de données, des modules suivants, qui traitent chacun de ces lots. Un scénario dessiné avec cinq modules ne consomme ainsi cinq crédits par passage que si chacun effectue une seule opération au tarif courant.

Trois simulations à fréquence et longueur identiques

Imaginons 1 000 passages mensuels et, à chaque passage, un déclencheur Make suivi de quatre modules. Le workflow équivalent est lancé 1 000 fois chez n8n et traite les éléments reçus dans chaque lancement. Tous les modules Make de l’exemple utilisent le tarif courant d’un crédit par opération ; aucun service externe ni fonction à tarification variable n’est inclus. Seul change le nombre d’éléments émis par le déclencheur.

  • Un élément par passage. Le déclencheur agit une fois et chacun des quatre modules suivants traite un élément. Cela donne 1 + 4 = 5 crédits par passage, soit 5 000 crédits mensuels chez Make. Le workflow n8n totalise 1 000 exécutions.
  • Trois éléments par passage. Le déclencheur agit toujours une fois, puis les quatre modules suivants agissent chacun trois fois. Le calcul est 1 + 4 × 3 = 13 crédits par passage, soit 13 000 sur le mois. Si n8n traite les trois éléments dans le même lancement, il reste à 1 000 exécutions.
  • Dix éléments par passage. Avec la même structure, le calcul devient 1 + 4 × 10 = 41 crédits par passage, soit 41 000 crédits mensuels. Sous la même hypothèse de traitement groupé, n8n conserve 1 000 exécutions. Aucun module ni lancement supplémentaire n’a été ajouté.

Ces simulations donnent des unités d’usage, pas trois factures en euros ou en dollars. Elles supposent aussi que les traitements produisent le même résultat sur les deux plateformes. Si la conception retenue impose plusieurs lancements n8n, son compteur doit être recalculé ; si un module Make ne traite qu’une partie des éléments, le total de crédits baisse.

À quel moment les crédits deviennent-ils une dépense ?

Le seuil du forfait compte autant que la multiplication des opérations. La grille tarifaire de Make affiche une offre gratuite limitée à 1 000 crédits par mois et des forfaits payants selon le volume choisi. Dans le premier exemple, 5 000 crédits dépassent déjà ce quota gratuit, alors qu’un parcours réduit à une opération par passage consommerait 1 000 crédits. Le passage à un forfait payant dépend donc des actions exécutées, même à fréquence et nombre de scénarios constants.

Une consommation cinq fois plus élevée ne signifie toutefois pas automatiquement une facture cinq fois plus chère. Un forfait peut absorber l’augmentation tant que son quota suffit ; au-delà, il faut choisir un volume supérieur ou acheter des crédits supplémentaires selon les conditions du compte. Comparer seulement les prix d’entrée masquerait cet effet de seuil. Les devises, la durée d’engagement et les fonctions comprises dans chaque offre doivent être alignées avant de comparer les montants payés.

Les opérations qui échappent au calcul linéaire

Les trois cas précédents isolent l’effet des lots. Dans un processus réel, une branche suivie seulement par certains éléments réduit le nombre d’opérations en aval ; une recherche qui renvoie plusieurs éléments peut au contraire le relever. Un déclencheur qui vérifie régulièrement l’arrivée de données effectue aussi une opération de contrôle, même lorsqu’il ne trouve rien. La fréquence des vérifications peut alors peser davantage que celle des traitements utiles.

Le rapport d’un crédit par opération concerne les modules ordinaires retenus pour les simulations. Certaines fonctions avancées de Make utilisent une consommation variable, notamment selon les jetons, la taille des fichiers ou le temps de traitement. Pour elles, compter les modules ne donne pas une estimation suffisante. Le volume pertinent est la somme des opérations effectivement réalisées, complétée par les règles propres aux fonctions utilisées.

L’auto-hébergement change la nature du coût

La documentation d’hébergement de n8n présente une édition Community gratuite sur sa propre infrastructure, ainsi que des éditions Business et Enterprise activées par licence. L’édition Community déplace la dépense vers le serveur et son exploitation. Elle ne doit pas être confondue avec les offres hébergées ni avec les fonctions supplémentaires des éditions sous licence.

Pour une petite équipe, l’estimation doit inclure l’hébergement, les sauvegardes, les mises à jour, la surveillance et la remise en service après une panne. Ce sont des tâches à confier à quelqu’un, même lorsque le logiciel utilisé est gratuit. Une équipe disposant déjà de compétences d’exploitation peut juger ce contrôle utile ; un indépendant qui souhaite éviter cette charge peut préférer un service hébergé. Le choix se fait alors sur le volume calculé, les fonctions nécessaires et le temps que l’équipe peut consacrer à maintenir le flux.

À lire aussi :

Partager:

Abonnez-vous à notre newsletter

Recevez directement les dernières actualités sur le Web3, l’IA et les cryptomonnaies.

0