Ce qui compte comme outil open source d'automatisation (et ce qui ne compte pas)
Un outil open source d'automatisation est un moteur qui orchestre des flux — il déclenche, connecte des apps, déplace des données, décide entre les étapes — et dont le code peut être hébergé sur votre propre infrastructure plutôt que dans le cloud d'un tiers. La différence avec Zapier ou Make n'est pas ce qu'ils font, c'est où vit le moteur et qui contrôle la donnée : dans un SaaS fermé, sur leurs serveurs ; dans un outil open source, là où vous voulez.
Une confusion de nom mérite d'être levée. « IA open source » désigne d'habitude les modèles de langage que vous pouvez auto-héberger (Llama, Mistral et compagnie), et c'est une autre décision — modèle ouvert vs. API fermée. Ici on parle d'orchestration : l'outil qui exécute le flux et appelle le modèle, quel qu'il soit. Deux couches distinctes, choisies sur des critères différents.
Les trois qui comptent : n8n, Activepieces et Windmill
Le paysage open source est large, mais pour l'automatisation IA en entreprise la vraie conversation tourne autour de trois. Les trois s'auto-hébergent ; elles diffèrent par la licence, l'approche et le public visé.
| Outil | Licence | Approche | À qui ça convient |
|---|---|---|---|
| n8n | Sustainable Use License (fair-code) | Éditeur visuel de nœuds + code au besoin | Équipes mixtes ; la plus grande communauté et le plus d'intégrations |
| Activepieces | MIT (la plus permissive) | No-code visuel, simple | Équipes peu techniques voulant une liberté de licence totale |
| Windmill | AGPLv3 | Code-first (TypeScript, Python, Go, Bash, SQL) avec UIs auto-générées | Équipes d'ingénierie qui veulent leur outillage interne en code |
La licence n'est pas une note de bas de page pour juristes : elle change ce que vous pouvez faire. Celle de n8n est ouverte pour un usage interne mais interdit de le revendre comme service géré à des tiers. Activepieces, sous MIT, ne vous lie presque à rien. Windmill, sous AGPLv3, n'oblige à publier vos modifications que si vous distribuez le logiciel — pas si vous l'utilisez en interne. Pour 90 % des entreprises, qui l'hébergent pour leur propre exploitation, les trois se comportent comme du vrai open source.
Quand l'auto-hébergement en vaut la peine (et quand non)
L'auto-hébergement n'est ni gratuit ni supérieur par défaut. Il en vaut la peine quand une de ces pressions est réelle — et pas quand aucune ne l'est.
Ça vaut le coup si :
- La donnée ne peut pas sortir de la maison. Secteur régulé, information sensible ou politique RGPD exigeant que la donnée reste dans votre périmètre. C'est la raison numéro un et la plus lourde.
- Le volume fait exploser le prix. Le SaaS facture à l'opération ou à la tâche ; au-delà d'un certain volume, le coût par exécution d'un plan cloud grimpe plus vite que celui de votre propre serveur.
- Vous avez besoin de logique sur mesure ou de code. Quand le flux demande ce que le no-code ne couvre pas, pouvoir glisser du code dans n'importe quelle étape cesse d'être un luxe.
- Vous voulez éviter le lock-in. Contrôler le moteur signifie qu'un changement de prix ou de conditions du fournisseur ne vous met pas au pied du mur.
Ça ne vaut pas le coup si :
- Vous ne connectez que deux ou trois apps et le plan cloud vous convient : changer coûte plus que ça n'économise.
- Vous n'avez personne pour maintenir l'infrastructure (voir le coût réel plus bas).
- Votre goulot d'étranglement n'est pas l'exécution mais le jugement : lire du texte libre, comprendre l'intention, décider sur l'ambigu. Changer d'outil ne règle pas ça ; c'est poser une couche d'IA par-dessus.
Le coût réel de l'auto-hébergement, au-delà de la licence
« 0 € de licence » est vrai et trompeur à la fois. Le coût n'est pas dans la licence ; il est dans l'exploitation du système. Voici ce qui apparaît vraiment sur la facture :
- Serveur et hébergement : la machine où il tourne, sa bande passante et son stockage.
- Sauvegardes et haute disponibilité : un flux critique qui tombe sans copie est un incident, pas une automatisation.
- Mises à jour et correctifs de sécurité : chaque version apporte des corrections à appliquer ; un moteur ouvert et non corrigé est une porte ouverte.
- Supervision et logs : sans observabilité, vous ne savez pas que le flux a échoué avant que quelqu'un se plaigne.
- La personne qui le maintient : le coût dominant. Ce n'est pas le logiciel, c'est le temps technique pour le garder sain.
Auto-hébergement et RGPD : souveraineté de la donnée, pas une case à cocher
Héberger l'outil vous-même garde le moteur et sa base de données dans votre périmètre. C'est un bon point de départ pour le RGPD, mais ça ne clôt pas le sujet. La souveraineté de la donnée se décide sur toute la chaîne du flux, pas sur l'étiquette du tableau de bord.
L'angle mort habituel : le moteur est à la maison, mais le flux appelle une API de LLM hébergée aux États-Unis, ou déclenche un webhook vers un tiers, ou enregistre une pièce jointe dans un stockage cloud. À chacun de ces sauts, la donnée sort de votre périmètre comme avec un SaaS. Auto-héberger l'orchestrateur et envoyer du contenu sensible à un modèle externe non contrôlé, c'est de la demi-souveraineté. Il faut regarder où vit chaque saut — et c'est là que n8n auto-hébergé brille face aux alternatives cloud, précisément parce que vous pouvez garder toute la chaîne sous votre toit.
Comment choisir en une phrase
Équipe peu technique et liberté de licence totale → Activepieces (MIT). Équipe mixte qui valorise communauté et intégrations → n8n (fair-code). Équipe d'ingénierie qui veut tout en code et versionné dans Git → Windmill (AGPLv3). Et un avertissement qui sauve des projets : si votre vrai problème est que le flux a besoin de jugement, aucune des trois ne le règle seule — c'est une couche d'IA par-dessus, pas un changement d'outil.