Ça fait maintenant un bon moment que je me pose la question : est-ce que je dois quitter n8n pour une autre solution d’automatisation ?

n8n est un excellent outil, je l’utilise depuis longtemps, mais au fil des versions une tendance devient claire : de plus en plus de fonctionnalités sont réservées aux offres Enterprise et le menu d’administration commence sérieusement à ressembler à un mur de paywall.

Rien d’illogique d’un point de vue économique (tout travail mérite salaire), mais quand on est en self-hosting perso (comprendre non entreprise), orienté services et maîtrise de son infra, ça donne envie d’aller voir ailleurs.

J’ai donc décidé de tester plusieurs alternatives, en m’appuyant à la fois sur ChatGPT pour creuser rapidement les concepts et sur selfh.st pour identifier des solutions réellement auto-hébergeables.

Node-RED : simple, mais trop limité pour mon usage

Ma première tentative a été Node-RED.

L’outil est agréable, simple à prendre en main et très populaire dans le monde de l’IoT et de la domotique. Mais très vite, je me suis heurté à plusieurs limites bloquantes pour mon usage :

• manque réel de traçabilité des actions,
• pas de rejeu simple des flux en erreur,
• debug et historique très en retrait par rapport à n8n.

Il existe bien Dashboard 2 pour enrichir l’ensemble, mais à ce stade, je me serais retrouvé à tout reconstruire, pour finalement obtenir moins de fonctionnalités que ce que j’ai déjà.

➡️ Node-RED est excellent dans son domaine, mais pas adapté à mon besoin d’orchestration un peu avancée.

Kestra : puissant, mais lourd et très orienté entreprise

Ensuite, j’ai testé Kestra.

J’avoue partir avec quelques a priori : solution en Java, stack plus “enterprise”… et malheureusement, ces craintes se sont confirmées assez vite.

Dès le départ, on se retrouve avec :

• une interface lourde,
• la console docker qui pisse du log spring,
• et surtout… du paywall un peu partout.

➡️ Clairement, Kestra est taillé pour des équipes data, des pipelines complexes, des environnements corporate. Pour mon usage personnel / self-hosted, c’était beaucoup trop.

Activepieces : très bon, mais encore trop bridé

J’ai ensuite voulu tester Activepieces.

Là, on est sur quelque chose de très propre, très bien pensé, clairement au niveau de n8n en termes d’UX et de possibilités. Mais le problème revient encore une fois : beaucoup trop de fonctionnalités clés derrière un paywall.

C’est frustrant, parce que la base est excellente, mais dans les faits, je retrouvais exactement la situation que je voulais éviter.

Windmill : prometteur, mais pas pour moi (pour l’instant)

Dernier test : Windmill, dont j’avais entendu énormément de bien.

L’outil est intéressant, vraiment puissant, mais :

• beaucoup moins low-code que n8n,
• une stack assez lourde avec un grand nombre de conteneurs Docker,
• et, là encore… des limitations côté gratuit.

➡️ Windmill a clairement du sens pour du scripting, de l’automatisation orientée dev, voire des équipes. Mais pour mes workflows orientés services, intégrations et automatisation quotidienne, ce n’était pas le bon compromis.

Pourquoi je reste finalement sur n8n

Après tous ces tests, la conclusion s’est imposée d’elle-même :
👉 je reste sur n8n !

Et ce choix est aujourd’hui totalement assumé.

Les raisons principales :

• ✅ Je maîtrise déjà l’outil,
• ✅ Un seul conteneur Docker, simple à maintenir,
• ✅ Une communauté énorme,
• ✅ Un excellent équilibre entre low-code et flexibilité,
• ✅ Suffisamment de puissance pour couvrir 95 % de mes besoins,
• ✅ 0 migration !

Plutôt que de migrer, j’ai décidé de faire évoluer mon existant intelligemment.

Ce que je fais évoluer sur mon instance n8n

Utilisation des community nodes

Lors de la mise en place de certains workflows, ces nodes n’existaient pas encore. C’est désormais corrigé, notamment pour :

• Bluesky,
• Threads,
• Withings.

Ça me permet de simplifier fortement des workflows qui reposaient jusque-là sur du HTTP custom ou du code.

Migration vers les Data Tables

J’ai aussi commencé à migrer certains usages basés sur : getWorkflowStaticData() (storage lié au workflow) vers les Data Tables, qui sont :

• plus lisibles,
• plus maintenables,
• plus adaptées à une logique “données” qu’à une logique “hack technique”.

Pour de la configuration, des états ou des mappings, c’est clairement un mieux.

Conclusion

Oui, n8n évolue vers un modèle plus commercial. Oui, certaines fonctionnalités sont désormais payantes.

Mais malgré tout, aucune alternative testée ne m’a offert aujourd’hui un meilleur compromis entre :

• simplicité,
• puissance,
• auto-hébergement (1 seul container !),
• maîtrise opérationnelle.

Plutôt que de repartir de zéro, j’ai choisi d’optimiser ce que je connais déjà, et pour l’instant, n8n reste le meilleur choix pour mon usage.