n8n : comprendre l'outil et l'apprendre dans le bon ordre

Cloud ou auto-hébergé

L'auto-hébergement se justifie sur deux critères : des données que vous ne pouvez pas laisser sortir (RGPD, santé, patrimoine), et du volume dont vous voulez maîtriser le coût sur la durée. Un agent de support déployé chez un client e-commerce tourne sur un VPS à moins de cinq euros par mois, base vectorielle comprise.

Ce qu'il vous facture en retour, c'est la responsabilité des mises à jour. n8n 2.0, sortie fin 2025, a durci les valeurs par défaut de sécurité et séparé le fait d'enregistrer du fait de publier. Sur le Cloud, l'éditeur encaisse la migration ; en auto-hébergé, c'est vous qui appuyez sur le bouton et vous qui ramassez les morceaux. Pour apprendre, prenez le Cloud : c'est le même n8n des deux côtés.

n8n ou Make

Les deux montent les mêmes automatisations. Ce qui les sépare, c'est le compteur qui tourne derrière et la marche technique à franchir.

Make facture à l'opération : chaque module qui s'exécute consomme une unité. n8n facture à l'exécution : un workflow entier qui tourne compte pour un, quel que soit son nombre d'étapes. Sur un workflow de dix étapes lancé dix mille fois par mois, ça fait cent mille opérations chez Make, dix mille exécutions chez n8n. L'écart se creuse avec le nombre d'étapes, pas avec la fréquence. Le tarif à l'unité de Make reste doux, ce qui le place entre n8n et Zapier, dont le modèle à la tâche peut atteindre cinq à dix fois la facture n8n sur le même volume.

Make demande moins : les modules sont préconfigurés, le mapping se fait à la souris, et vous partez de zéro plus vite sur des automatisations métier classiques. n8n réclame un cran de technicité supplémentaire, du JSON, des expressions, un peu d'administration serveur si vous vous auto-hébergez, et il rend ce cran sur les agents IA à plusieurs étapes, le volume, et les données qui doivent rester chez vous. Dans les faits, la plupart des gens que j'accompagne gardent Make pour le quotidien et sortent n8n sur les projets qui dépassent ce cadre.

n8n ou écrire le code

L'argument « je ferais ça plus vite dans un script » tombe presque toujours sur le même contre-exemple. Pennylane n'a pas de nœud natif dans n8n, et ça n'a rien changé au projet de facturation qu'on a livré : le nœud HTTP Request dialogue avec n'importe quelle API REST. L'absence d'intégration native n'est donc pas un motif pour sortir de n8n. Ce que vous gagnez en restant dedans, c'est ce qu'il y a autour : le journal d'exécution, les relances, la reprise sur erreur, un canvas qu'une autre personne peut lire six mois plus tard.

La limite existe quand même, et n8n 2.0 l'a rendue explicite : les nœuds Code ne lisent plus les variables d'environnement, le nœud Python a changé, deux nœuds sont désactivés par défaut. Si votre plan est de faire passer un vrai programme en contrebande dans un nœud Code, écrivez le programme.

Les derniers 5 % coûtent autant que les 95 premiers

Sur un projet qui relie une boutique Shopify à Pennylane, le workflow tournait déjà : commandes reçues, clients créés, factures générées. Le chiffre lâché pendant le point de suivi était « on est à 95 % ». Tout le mois suivant est parti dans les 5 % restants. Sur du reporting, 5 % d'erreur est un détail. Sur de la facturation, une facture fausse part chez le client, se lit, et s'enregistre dans la comptabilité d'en face : il faut émettre un avoir, expliquer, refaire. La question qui occupe ce mois-là est « qu'est-ce qui se passe quand ça ne marche pas ? ».

La production invente des cas que la recette n'a pas

Sur le même projet, le workflow prévenait le client en cas de rupture de stock. Sauf que certaines lignes de commande étaient des mentions de service facturées à zéro euro, et le système les lisait comme des ruptures. Des mails partaient pour rien. La correction a consisté à resserrer la définition d'une rupture de stock. Ce type de faux positif ne se voit ni en test ni en recette : il apparaît sur des commandes réelles, dans des combinaisons que personne n'aurait listées. D'où deux habitudes qui font partie du travail : surveiller quotidiennement les premières semaines, et fabriquer soi-même deux ou trois documents tordus à faire traverser le workflow avant qu'un vrai cas ne compte.

Les arbitrages de production se jouent hors du canvas

Faut-il bloquer la facture jusqu'à validation humaine, ou l'envoyer et vérifier ensuite ? Bloquer arrête la file entière dès que la personne qui valide est absente une journée. Envoyer met une facture potentiellement fausse chez le client. La sortie a été un troisième chemin, la facture générée en brouillon, et cette décision-là s'est prise pendant un appel, pas dans le canvas. Même logique sur un refactoring pourtant prêt : le client partait en congés et le système venait tout juste de se stabiliser, donc le chantier a attendu.

Le temps gagné, chiffres à l'appui

Les chiffres sont posés : une heure par semaine récupérée sur le traitement des mails, mesurée sur trois mois ; un agent de support autour de neuf euros par mois pour cinq cents conversations, à condition d'avoir choisi le bon modèle, puisque le même agent grimpe à quatre-vingts euros avec un modèle haut de gamme pris sans raison. Sur une boutique en ligne, les six chantiers identifiés pendant un appel partaient tous du même squelette : un événement Shopify déclenche, n8n agit ailleurs. Le temps part dans le design des cas particuliers ; la plomberie, elle, se répète d'un chantier à l'autre.