En 2022, l'éditeur de n8n a fait un choix qui a fâché une partie de sa communauté : abandonner la licence Apache pour un texte maison, la Sustainable Use License. L'argument était celui, désormais familier, des éditeurs qui voient un fournisseur de cloud revendre leur travail sans rien reverser. Le résultat est un logiciel dont le code est lisible par tous, modifiable, redistribuable, mais qui n'est pas libre au sens où on l'entend habituellement.
Quatre ans plus tard, le projet dépasse les deux cent mille étoiles et s'est installé comme l'outil d'automatisation par défaut dans les entreprises qui veulent éviter un abonnement par utilisateur. La question de la licence, elle, n'a pas disparu : elle est simplement passée sous le tapis. Reprenons-la, avec quatre autres objections qu'on entend avant chaque installation.
« C'est open source »
Non, et l'éditeur ne le prétend pas. Il emploie le terme fair-code, qui désigne précisément ce statut intermédiaire.
La licence autorise l'usage, la copie, la modification et la distribution pour les besoins internes de votre activité. Elle autorise aussi l'usage personnel et non commercial. Elle interdit en revanche de fournir le logiciel à des tiers contre rémunération : la distribution n'est permise qu'à titre gratuit. Les fichiers portant le suffixe .ee relèvent d'une licence commerciale distincte et ne sont pas couverts par ce texte.
La différence avec l'open source n'est pas théorique. Une entreprise qui déploie n8n pour automatiser ses propres processus est pleinement dans le cadre. Un éditeur qui construirait une offre d'automatisation mutualisée, avec n8n derrière et une facture mensuelle devant, en sort clairement.
Entre les deux, la zone grise est réelle et mérite d'être traitée honnêtement : un prestataire qui installe n8n sur l'infrastructure de son client, pour l'usage interne de ce client, et qui facture son travail d'installation et d'exploitation, n'est pas dans le cas visé par l'interdiction, puisqu'il ne vend pas le logiciel. La lecture est raisonnable, elle est largement pratiquée, et elle n'a pas valeur de garantie. Si une offre commerciale se construit là-dessus, la seule démarche sérieuse consiste à faire relire le texte par un juriste et, si le doute persiste, à écrire à l'éditeur. Cela coûte un courriel et cela évite une conversation désagréable deux ans plus tard.
« Alors autant prendre un service en ligne »
C'est la deuxième objection, et elle se tranche sur un critère unique : ce que transportent les automatisations.
Un enchaînement qui relie une boîte mail, un tableur, un logiciel de facturation et une messagerie d'équipe voit passer, en clair, à peu près tout ce qui compte dans une entreprise. Les pièces jointes, les montants, les noms des clients, parfois les coordonnées bancaires. Avec un service en ligne, ces contenus transitent chez un tiers, souvent hors d'Europe, et s'y attardent le temps d'un journal d'exécution.
Auto-héberger déplace ce risque, il ne le supprime pas : les données passent maintenant par une machine dont vous êtes responsable, avec ses journaux à protéger et ses sauvegardes à chiffrer. C'est un déplacement qui a du sens pour une entreprise soumise au RGPD sur des traitements sensibles, et beaucoup moins pour trois automatisations qui publient des articles sur les réseaux sociaux.
La question n'est donc pas « en ligne ou chez soi », mais « qu'est-ce qui circule ». La réponse détermine tout le reste.
« Ça remplace du développement »
Partiellement, et c'est là que les projets dérapent.
n8n excelle sur ce pour quoi il est fait : relier des systèmes qui ne se parlent pas, sur des volumes modérés, avec une logique qu'on peut lire sur un écran. Récupérer une pièce jointe, la déposer au bon endroit, prévenir quelqu'un, écrire une ligne dans une base. Quatre cents connecteurs évitent d'écrire quatre cents fois le même code d'authentification, et c'est un gain réel.
Il devient mauvais quand on lui demande d'être un programme. Un enchaînement de soixante noeuds avec des branches conditionnelles imbriquées est du code, mais du code qu'on ne peut ni tester unitairement, ni relire en diff, ni reprendre facilement quand son auteur est parti. Le nombre de noeuds est un bon indicateur : au-delà d'une vingtaine, la question de réécrire la logique dans un vrai service se pose sérieusement.
La frontière utile se formule ainsi : n8n orchestre, il ne calcule pas. Dès qu'une règle métier complexe apparaît, elle a sa place dans un service dédié que l'automatisation se contente d'appeler.
« Une fois installé, ça tourne tout seul »
C'est l'objection la plus coûteuse, parce qu'elle est fausse et qu'on ne s'en aperçoit qu'en cas d'incident.
Un outil d'automatisation détient les identifiants de tous les systèmes qu'il relie. Sa base de données est donc un trousseau de clés de l'entreprise entière. Elle se chiffre, elle se sauvegarde, et sa clé de chiffrement se conserve ailleurs que dans la même sauvegarde, faute de quoi la restauration ne restaure rien d'utilisable.
Les exécutions s'accumulent. Chaque passage conserve la trace de ce qui a circulé, pièces jointes comprises. Sans purge configurée, la base grossit jusqu'à saturer le disque, et le contenu des exécutions conservé six mois est une fuite qui attend son heure. La rétention se règle le jour de l'installation, pas le jour où le disque est plein.
Les échecs sont silencieux par défaut. Un enchaînement qui plante parce qu'une API a changé son format continue de ne rien faire, tous les jours, sans que personne ne le remarque, jusqu'à ce qu'un client s'étonne de ne plus recevoir ses documents. Il faut donc une automatisation qui surveille les autres, et une alerte qui sorte de l'outil.
Enfin, les montées de version sont fréquentes et modifient parfois le comportement de connecteurs existants. On épingle une version, on teste sur une instance séparée, on garde une sauvegarde restaurable avant chaque passage. Le volume de données du conteneur fait partie du périmètre à sauvegarder, au même titre que la base.
« C'est un outil pour les métiers, pas pour l'informatique »
Oui et non, et le malentendu produit les deux échecs classiques.
Si le service informatique garde la main sur tout, chaque demande devient un ticket et l'outil perd sa raison d'être : les métiers retournent à leurs tableurs et à leurs copier-coller. Si les métiers font ce qu'ils veulent, on se retrouve au bout d'un an avec soixante automatisations dont personne ne connaît l'utilité, des identifiants de production dans des enchaînements personnels, et une dépendance à un salarié parti depuis six mois.
Le partage qui fonctionne donne aux métiers la construction et les tests dans un espace séparé, et à l'informatique la gestion des identifiants, la mise en production et la supervision. Les identifiants sensibles ne sont jamais saisis par le métier ; ils sont posés une fois, par l'exploitation, et partagés en tant que références. C'est exactement le modèle que l'on applique à une plateforme d'orchestration comme AWX, et pour les mêmes raisons.
Ce qui reste vrai
n8n fait bien ce qu'il annonce, et il le fait sur votre infrastructure, ce qui est rare dans cette catégorie. Le prix à payer tient en trois lignes : une licence à lire avant de bâtir une offre dessus, une base à chiffrer et à purger, et une discipline de partage entre métiers et exploitation.
Reste l'automatisation numéro quarante-sept, construite à la va-vite pour dépanner quelqu'un, qui porte les identifiants du système de facturation et qui plante en silence depuis trois semaines. Personne ne l'a vue, parce que personne ne surveillait les échecs.
Sources
- Sustainable Use License de n8n, conditions d'usage interne, interdiction de fourniture payante à des tiers, exclusion des fichiers .ee
- Dépôt GitHub n8n-io/n8n, 205 546 étoiles au 21 septembre 2026, plus de 400 connecteurs, positionnement fair-code
- Documentation d'auto-hébergement n8n, déploiement, base de données, clé de chiffrement et rétention des exécutions
- CNIL, sécurité des données personnelles, obligations applicables aux traitements automatisés transportant des données personnelles
