Automatiser des processus RH, financiers ou contractuels avec n8n soulève immédiatement une question que les guides d'installation évitent souvent : qui a accès à vos données d'exécution, où sont-elles stockées, et qui est responsable si elles fuient ?
En 2026, les contraintes se sont durcies. La directive NIS2 est transposée en droit français. La CNIL a multiplié les mises en demeure sur les transferts de données hors UE. L'AI Act impose une traçabilité sur les traitements automatisés impliquant de l'IA. Et les DSI qui ont signé en aveugle des DPA avec des fournisseurs cloud américains commencent à en payer le prix lors des audits.
Le auto-hébergement de n8n est la réponse technique à ce problème. Mais un "docker compose up" sur un VPS sans configuration de sécurité n'est pas du auto-hébergement souverain : c'est un incident de sécurité en attente de se produire. Un port 5678 exposé sans authentification, un N8N_ENCRYPTION_KEY à sa valeur par défaut, des credentials stockés en clair dans un fichier .env versionné — ce sont des erreurs que nous voyons régulièrement lors de nos audits chez Tensoria.
Ce guide est écrit pour les DSI, RSSI et responsables ops d'ETI qui traitent des données sensibles et veulent un déploiement n8n techniquement rigoureux, conforme au RGPD, résilient et maintenable. Il suppose un niveau technique suffisant pour manipuler Docker, un VPS Linux et des fichiers de configuration. Pour une introduction plus stratégique au sujet RGPD et souveraineté, l'article n8n, RGPD et hébergement souverain pose les fondations. Si vous évaluez encore n8n face à Make ou Zapier, consultez d'abord notre comparatif.
Ce que couvre ce guide
- ✓ Les 3 modèles de déploiement n8n et leurs implications RGPD réelles
- ✓ Choisir un hébergeur souverain : OVH, Scaleway, Outscale, Hetzner avec certifications HDS et SecNumCloud
- ✓ Architecture cible et spécifications serveur chiffrées selon votre volume
- ✓ Docker Compose sécurisé avec PostgreSQL et Redis
- ✓ Reverse proxy TLS, SSO/LDAP, gestion des secrets (Vault, Doppler)
- ✓ Sauvegardes Restic, monitoring Grafana/Prometheus, plan de reprise
- ✓ RGPD pratique : DPA, registre des traitements, anonymisation, durée de conservation
- ✓ NIS2, APIs IA hors UE, Community vs Enterprise : les arbitrages clés
- ✓ Budget annuel complet d'un setup production-grade
Pourquoi le sujet est critique en 2026
Trois évolutions réglementaires changent le calcul pour les entreprises qui automatisent avec des outils cloud tiers.
NIS2 est transposée. La directive européenne sur la cybersécurité des réseaux et systèmes d'information (NIS2) est entrée en application en France en 2025. Elle élargit considérablement le périmètre des entreprises concernées : plusieurs milliers d'entités supplémentaires par rapport à la NIS1, notamment dans les secteurs de la santé, de l'énergie, des transports, de la finance et de l'administration. Les obligations de l'article 21 imposent des mesures techniques concrètes : sauvegardes testées, chiffrement des données, authentification multifacteur, gestion documentée des incidents. Un outil d'automatisation critique comme n8n entre directement dans ce périmètre.
La CNIL durcit le ton sur les transferts hors UE. Les transferts de données personnelles vers des fournisseurs américains (AWS, Azure, Google Cloud) restent juridiquement fragiles depuis l'arrêt Schrems II. Le Privacy Shield 2.0 (Data Privacy Framework) offre un cadre, mais il est contesté devant la CJUE. En pratique, plusieurs DPO d'ETI que nous accompagnons privilégient désormais des hébergeurs européens pour tout traitement de données sensibles, pour couper court à la discussion lors des audits.
L'AI Act impose de la traçabilité sur les workflows IA. À partir d'août 2026, l'article 50 oblige les déployeurs de systèmes d'IA à informer les utilisateurs et à documenter les modèles utilisés. Un workflow n8n qui traite des candidatures RH via un LLM ou qui score des leads est directement concerné. Cette traçabilité nécessite des logs d'exécution structurés — ce que seul un auto-hébergement maîtrisé permet de produire et de conserver selon vos propres règles.
Le résultat concret : les entreprises qui ont choisi n8n Cloud ou une plateforme SaaS américaine il y a deux ans se retrouvent à devoir justifier des DPA insuffisantes, des transferts de données non documentés et des logs d'exécution qu'elles ne contrôlent pas. La migration vers le auto-hébergement souverain est devenue une question de quand, pas de si.
Les 3 modèles de déploiement et leurs implications RGPD
Avant d'aller dans la technique, il faut choisir son modèle de déploiement. Ce choix détermine vos obligations RGPD, votre niveau de contrôle et votre charge opérationnelle.
| Critère | n8n Cloud | Auto-hébergé VPS/Cloud souverain | Auto-hébergé infrastructure interne |
|---|---|---|---|
| Localisation données | Azure EU (via n8n GmbH) | France ou UE, vous choisissez | Vos propres datacenters |
| Sous-traitant RGPD | n8n GmbH + Microsoft Azure | L'hébergeur (OVH, Scaleway…) | Aucun sous-traitant IA |
| DPA à signer | n8n GmbH + Azure | L'hébergeur uniquement | Aucune (usage interne) |
| Purge des exécutions | Paramètres limités | Configurable librement | Configurable librement |
| Audit logs | Plan Enterprise uniquement | Logs serveur complets | Logs serveur complets |
| Charge opérationnelle | Très faible (managé) | Moyenne (maintenance infra) | Élevée (infra + réseau) |
| Conformité HDS/SecNumCloud | Non | Possible (OVH HDS, Cloud Temple) | Possible si infra certifiée |
Pour une ETI qui traite des données RH, financières ou contractuelles sans exigence sectorielle spécifique (santé, défense), l'auto-hébergement sur VPS souverain est l'équilibre optimal : contrôle total sur les données, charge opérationnelle maîtrisable, coût bien inférieur au Cloud. C'est ce modèle que ce guide détaille.
Choisir un hébergeur souverain
Tous les hébergeurs ne se valent pas lorsqu'on parle de souveraineté réelle des données. La localisation géographique ne suffit pas : il faut regarder la structure juridique de l'entreprise, ses certifications et son exposition au droit extraterritorial américain (CLOUD Act, FISA 702).
Le critère CLOUD Act
Une entreprise soumise au droit américain — même si ses serveurs sont en France — peut être contrainte par une injonction américaine de transmettre des données à des autorités américaines sans vous en informer. AWS, Azure et Google Cloud sont dans ce cas, quelle que soit la région choisie. OVHcloud et Scaleway sont des entreprises de droit français, non soumises au CLOUD Act. C'est la différence fondamentale.
| Hébergeur | Localisation DC | Certifications clés | CLOUD Act | VPS 4 vCPU / 8 Go RAM |
|---|---|---|---|---|
| OVHcloud | Roubaix, Strasbourg, Gravelines | ISO 27001, HDS, SOC 2 | Non exposé | ~24 €/mois |
| Scaleway | Paris (DC2, DC3, DC5) | ISO 27001, SOC 2, SecNumCloud (partiel) | Non exposé | ~28 €/mois |
| Outscale (Dassault) | Paris, Saint-Cloud | SecNumCloud qualifié ANSSI, HDS, ISO 27001 | Non exposé | ~60–90 €/mois |
| Cloud Temple | Paris, Lyon | SecNumCloud qualifié ANSSI, HDS, ISO 27001 | Non exposé | ~80–120 €/mois |
| Hetzner | Nuremberg, Helsinki (Allemagne/Finlande) | ISO 27001, ISO 9001 | Non exposé (droit allemand) | ~14 €/mois |
Recommandation selon votre contexte
- Données RH, financières, contractuelles (RGPD standard) : OVHcloud ou Scaleway. Bon équilibre coût/certifications/localisation France.
- Données de santé (obligation HDS) : OVHcloud HDS ou Cloud Temple. La qualification HDS est indispensable pour héberger des données de santé au sens strict.
- Marchés publics sensibles ou données classifiées (SecNumCloud) : Outscale ou Cloud Temple, seuls qualifiés SecNumCloud par l'ANSSI en 2026.
- Budget prioritaire sans contrainte France stricte : Hetzner (Allemagne, droit UE, pas de CLOUD Act). Le moins cher de la liste, très utilisé par les startups et ETI sans contrainte sectorielle forte.
Architecture cible production-grade
Un déploiement n8n production-grade ne se résume pas à n8n seul. Voici les composants indispensables et leur rôle.
- n8n : le moteur de workflows, exposé uniquement via le reverse proxy, jamais directement sur internet
- PostgreSQL 15+ : base de données pour les workflows, exécutions et credentials (SQLite est insuffisant en production)
- Redis 7+ : file de messages pour les executions en mode Queue Mode (indispensable dès que vous avez des workflows concurrents)
- Caddy ou Nginx : reverse proxy avec terminaison TLS, renouvellement Let's Encrypt automatique
- HashiCorp Vault ou Doppler : gestion des secrets applicatifs (clés API, N8N_ENCRYPTION_KEY)
- Restic + S3 souverain : sauvegardes chiffrées de PostgreSQL et des volumes Docker
- Prometheus + Grafana : métriques n8n, alerting sur les exécutions échouées et la santé du serveur
- Fail2ban + UFW : protection périmétrique, bannissement des IPs suspectes
Cette architecture tient sur un seul VPS pour des volumes modérés (moins de 30 000 exécutions par mois). Au-delà, on sépare les workers n8n (Queue Mode) du processus principal sur des serveurs distincts. Le dimensionnement dépend aussi du type d'architecture : un workflow déterministe avec un appel LLM ponctuel consomme beaucoup moins de ressources qu'un agent autonome multi-itérations. Pour calibrer correctement votre serveur, consultez notre grille workflow vs agent IA dans n8n, quand utiliser quoi.
Étape 1 : provisioning et dimensionnement serveur
Le dimensionnement est la première erreur opérationnelle. Un VPS sous-dimensionné donne des timeouts sur les webhooks et des workers qui se bloquent mutuellement. Un VPS sur-dimensionné coûte inutilement cher.
| Profil d'usage | Exécutions/mois | Specs minimales | Specs recommandées | Coût OVH/Scaleway |
|---|---|---|---|---|
| Démarrage / test | < 5 000 | 2 vCPU, 4 Go RAM, 40 Go SSD | 2 vCPU, 4 Go RAM, 40 Go SSD | 7–12 €/mois |
| PME standard | 5 000–20 000 | 4 vCPU, 8 Go RAM, 80 Go SSD | 4 vCPU, 8 Go RAM, 80 Go SSD | 18–28 €/mois |
| ETI workflows intensifs | 20 000–80 000 | 8 vCPU, 16 Go RAM, 160 Go SSD | 8 vCPU, 32 Go RAM, 200 Go SSD | 45–90 €/mois |
| ETI + agents IA locaux (Ollama) | Tout volume | 8 vCPU, 32 Go RAM, GPU recommandé | 16 vCPU, 64 Go RAM, A10G ou H100 | 150–500 €/mois |
Concernant le stockage : chaque exécution n8n stocke ses données d'entrée et de sortie dans PostgreSQL. À 20 000 exécutions par mois avec des payloads de 5 Ko en moyenne, cela représente 100 Go de données brutes par mois sans purge configurée. C'est pourquoi la variable EXECUTIONS_DATA_MAX_AGE est critique : fixez-la à 30 jours maximum pour les données personnelles, moins si votre politique de rétention l'exige.
Sécurisation initiale du serveur
Avant d'installer n8n, le serveur doit être durci. Ce ne sont pas des détails :
- SSH par clé uniquement : désactiver l'authentification par mot de passe dans
/etc/ssh/sshd_config(PasswordAuthentication no) - UFW (pare-feu) : n'exposer que les ports 22, 80 et 443. Le port 5678 de n8n ne doit jamais être accessible directement depuis internet
- Fail2ban : protection contre les attaques par force brute sur SSH et les tentatives d'accès répétées sur les webhooks
- Mise à jour du système :
apt update && apt upgrade -yavant toute installation, puis configuration des mises à jour de sécurité automatiques (unattended-upgrades) - Utilisateur dédié : créer un utilisateur système non-root pour exécuter Docker et n8n, sans sudo permanent
Étape 2 : Docker Compose sécurisé
La configuration Docker Compose est l'endroit où la majorité des erreurs de sécurité apparaissent. Voici ce qu'une configuration production-grade doit respecter, et ce qu'elle doit impérativement éviter.
Les variables d'environnement critiques
Plusieurs variables n8n conditionnent directement votre niveau de sécurité et votre conformité :
N8N_ENCRYPTION_KEY: clé AES qui chiffre tous vos credentials dans PostgreSQL. Générez-la avecopenssl rand -hex 32et ne la perdez jamais — sans elle, tous vos credentials sont irrécupérables. Sauvegardez-la dans Vault ou un gestionnaire de mots de passe avant de démarrer le service.EXECUTIONS_DATA_SAVE_ON_SUCCESS: mettre ànoneouallselon votre besoin de débogage, mais documentez ce choix dans votre registre des traitements.allconserve les données d'entrée/sortie de chaque exécution — incluant les données personnelles.EXECUTIONS_DATA_MAX_AGE: durée de rétention en heures. Pour des données personnelles, 720 (30 jours) est un maximum raisonnable. Pour des données sensibles (médicales, RH), descendez à 168 (7 jours).N8N_SECURE_COOKIE: toujourstrueen production. Sinon les cookies de session ne sont pas protégés contre les interceptions.WEBHOOK_URL: l'URL publique HTTPS de votre instance. Doit correspondre exactement au domaine de votre reverse proxy.DB_TYPE,DB_POSTGRESDB_*: connexion PostgreSQL. Utilisez un utilisateur PostgreSQL dédié avec des droits minimum (pas le superuserpostgres).
Ce que votre fichier .env ne doit jamais contenir
Un fichier .env est lisible par quiconque a accès au système de fichiers. Il ne doit jamais être versionné dans Git. Ajoutez .env à votre .gitignore et vérifiez que ce fichier n'apparaît dans aucun historique Git existant.
Pour les secrets les plus sensibles (N8N_ENCRYPTION_KEY, mots de passe PostgreSQL), la pratique recommandée est d'injecter ces valeurs via Docker secrets ou directement depuis Vault au moment du démarrage du conteneur — jamais en dur dans un fichier texte.
Mode Queue avec Redis
Par défaut, n8n s'exécute en mode "main" : un seul processus gère à la fois l'interface web, les déclenchements et les exécutions. Ce mode ne convient pas à la production dès que vous avez plus de 5 à 10 workflows qui peuvent se déclencher simultanément.
Le Queue Mode (variable EXECUTIONS_MODE=queue) sépare le processus principal (interface, API) des workers d'exécution. Redis sert de file de messages entre les deux. Cette architecture permet d'ajouter des workers sans redémarrer n8n, et d'éviter qu'une exécution lourde bloque toutes les autres. Pour une ETI avec 20 workflows actifs et des webhooks entrants, le Queue Mode est indispensable.
Étape 3 : reverse proxy et TLS
n8n ne doit jamais être exposé directement sur les ports 80 ou 443. Un reverse proxy est le composant qui gère la terminaison TLS, les en-têtes de sécurité HTTP et la protection de l'interface d'administration.
Caddy vs Nginx : lequel choisir
Caddy est notre recommandation pour la majorité des déploiements n8n. Il gère automatiquement la génération et le renouvellement des certificats Let's Encrypt sans aucune configuration supplémentaire. Sa syntaxe est radicalement plus simple que Nginx, et il n'y a pas de risque d'erreur sur la configuration SSL/TLS. Caddy suffit largement pour une instance n8n même à fort volume.
Nginx** est préférable si vous avez déjà une infrastructure Nginx existante avec des configurations avancées (rate limiting granulaire, load balancing multi-workers, intégration avec un WAF). La courbe de configuration est plus raide mais la flexibilité est supérieure.
Quelle que soit l'option choisie, les en-têtes HTTP de sécurité suivants doivent être configurés :
Strict-Transport-Security: max-age=31536000; includeSubDomains: force HTTPS pendant 1 anX-Frame-Options: DENY: protège contre le clickjackingX-Content-Type-Options: nosniff: empêche le MIME sniffingContent-Security-Policy: restreindre les sources de scripts et styles à votre domaineReferrer-Policy: no-referrer: ne pas exposer l'URL d'origine dans les appels sortants
Certificats TLS
Let's Encrypt (gratuit, renouvelé automatiquement) est suffisant pour la majorité des déploiements. Pour des environnements qui exigent un certificat d'une autorité commerciale reconnue (certains marchés publics, certains DPA internes), prévoyez un certificat wildcard chez DigiCert ou Sectigo (environ 200 à 500 euros par an).
Le certificat doit couvrir votre domaine principal et le sous-domaine des webhooks si vous en utilisez un séparé. Configurez une alerte d'expiration à 30 jours minimum pour éviter les pannes silencieuses sur les webhooks entrants.
Étape 4 : authentification SSO, 2FA et LDAP
L'authentification est le point où Community Edition et Enterprise Edition divergent le plus significativement. Voici ce qui est disponible dans chaque édition et comment l'implémenter.
Community Edition : ce qui est possible
La Community Edition propose une authentification native par email/mot de passe avec gestion des rôles (Admin, Member). Depuis la version 1.0, la 2FA (double authentification) via TOTP (Google Authenticator, Authy) est disponible nativement — activez-la pour tous les comptes administrateurs sans exception.
Pour les entreprises qui veulent une intégration LDAP (Active Directory, OpenLDAP) en Community Edition, il faut passer par un proxy d'authentification externe comme Authelia ou Authentik devant le reverse proxy. Ces outils open source gèrent l'authentification LDAP et délèguent ensuite à n8n via des en-têtes HTTP. La configuration est plus complexe, mais elle permet d'utiliser votre annuaire d'entreprise sans passer à l'Enterprise.
Enterprise Edition : SSO natif
L'Enterprise Edition intègre nativement le SSO via SAML 2.0 et OIDC, ce qui permet une intégration directe avec Azure AD, Okta, Keycloak ou Google Workspace. Les utilisateurs se connectent avec leur compte d'entreprise, la gestion des accès est centralisée dans votre IAM, et la révocation d'accès se fait immédiatement lors du départ d'un collaborateur.
Si votre entreprise a déjà un IAM (Identity and Access Management) en place et que les utilisateurs de n8n sont des profils sensibles (accès à des workflows RH ou financiers), le SSO Enterprise est difficile à contourner pour un niveau de sécurité sérieux.
Politique de mots de passe et accès
En Community Edition sans SSO, appliquez ces règles sans exception :
- Mots de passe d'au moins 16 caractères, générés par un gestionnaire de mots de passe
- 2FA activée pour tous les comptes, pas seulement les administrateurs
- Revue trimestrielle des comptes actifs : supprimer les comptes des personnes qui ont quitté l'équipe
- Ne jamais partager un compte utilisateur entre plusieurs personnes (auditabilité impossible sinon)
- Restreindre les accès aux workflows selon le rôle : un utilisateur marketing n'a pas besoin d'accéder aux workflows RH
Étape 5 : gestion des secrets
Les secrets dans un déploiement n8n sont de deux natures distinctes, et chacune demande un traitement différent.
Les secrets d'infrastructure
Ce sont les secrets qui font tourner votre stack technique : N8N_ENCRYPTION_KEY, mot de passe PostgreSQL, mot de passe Redis, clé de session. Ces secrets ne doivent jamais être accessibles via l'interface n8n et ne doivent jamais apparaître dans les logs.
La pratique minimale : fichier .env avec permissions chmod 600, non versionné, sauvegardé dans un gestionnaire de mots de passe (Bitwarden, 1Password Business, KeePassXC). La pratique recommandée pour une ETI : HashiCorp Vault en mode Community (gratuit) ou Doppler avec injection au démarrage du conteneur. Ces outils permettent la rotation des secrets sans redéploiement, un audit trail des accès et une intégration avec votre CI/CD.
Les credentials métier dans n8n
Ce sont les clés API que vos workflows utilisent : tokens Slack, clés CRM, credentials email SMTP, tokens API métier. n8n les stocke chiffrés dans PostgreSQL avec la N8N_ENCRYPTION_KEY. Ce chiffrement est solide — AES-256 — mais il ne vaut que si votre N8N_ENCRYPTION_KEY est elle-même protégée.
n8n 1.x introduit l'intégration avec des gestionnaires de secrets externes via l'interface graphique. En Enterprise Edition, vous pouvez connecter n8n directement à HashiCorp Vault, AWS Secrets Manager ou Azure Key Vault pour récupérer les credentials à la volée, sans les stocker dans PostgreSQL. C'est la solution la plus robuste pour des environnements avec de nombreux credentials rotatifs.
Ce qu'il ne faut jamais faire
- Passer une clé API directement dans un paramètre d'un nœud n8n en clair (visible dans l'export du workflow)
- Utiliser le même
N8N_ENCRYPTION_KEYsur plusieurs instances (prod, staging, dev) - Stocker
N8N_ENCRYPTION_KEYuniquement sur le serveur sans sauvegarde externe - Versionner le fichier
.envdans Git, même dans un dépôt privé
Étape 6 : sauvegardes et résilience
La plupart des installations n8n n'ont pas de stratégie de sauvegarde sérieuse jusqu'au jour où elles en ont besoin. En production, une corruption de la base PostgreSQL ou une suppression accidentelle d'un volume Docker signifie perdre tous vos workflows, credentials et historiques d'exécution. Le temps de reconstruction manuelle est généralement sous-estimé : pour 30 workflows complexes, comptez 2 à 5 jours.
Sauvegardes PostgreSQL avec pg_dump
La sauvegarde la plus importante est celle de PostgreSQL. Un dump complet quotidien via pg_dump doit être automatisé, chiffré et exporté vers un stockage externe au serveur principal. Un dump de n8n avec 30 workflows et 3 mois d'historique d'exécution représente généralement 500 Mo à 5 Go selon le volume.
Le workflow de sauvegarde recommandé :
- pg_dump quotidien à 2h00 UTC vers un fichier local temporaire
- Chiffrement du dump avec
gpgou directement via Restic - Export vers S3 souverain : Scaleway Object Storage (Paris), OVHcloud Object Storage, ou Exoscale (Suisse)
- Rétention : 7 jours de sauvegardes quotidiennes, 4 semaines de sauvegardes hebdomadaires, 3 mois de sauvegardes mensuelles
- Test de restauration mensuel : indispensable. Une sauvegarde non testée n'est pas une sauvegarde.
Restic pour les volumes Docker
Restic est l'outil de référence pour sauvegarder les volumes Docker de manière incrémentale et chiffrée. Il gère nativement les backends S3, ce qui permet d'envoyer les sauvegardes directement vers votre Object Storage souverain. Une sauvegarde Restic complète d'un volume n8n de 10 Go prend 3 à 8 minutes ; les sauvegardes incrémentales suivantes prennent moins d'une minute.
Plan de reprise d'activité
Définissez vos objectifs avant d'être en crise :
- RTO (Recovery Time Objective) : combien de temps vous pouvez vous permettre d'être sans n8n ? Pour des workflows critiques (facturation, alertes), le RTO devrait être inférieur à 4 heures.
- RPO (Recovery Point Objective) : quelle quantité de données vous pouvez vous permettre de perdre ? Avec des sauvegardes quotidiennes, le RPO maximum est de 24 heures. Pour descendre à 1 heure, configurez des sauvegardes WAL PostgreSQL continues.
- Procédure documentée : la restauration doit être documentée étape par étape et testée au moins une fois par trimestre. La personne qui restaure en urgence à 2h du matin ne sera peut-être pas celle qui a installé le système.
Étape 7 : monitoring et alerting
Un n8n non monitoré est un n8n qui accumule silencieusement des erreurs que personne ne voit. Les workflows qui tombent en erreur, les workers qui se bloquent, les webhooks qui ne répondent plus : sans monitoring, vous découvrez le problème quand un utilisateur métier vous signale que "ça ne marche plus".
Métriques n8n via Prometheus
n8n expose nativement des métriques Prometheus sur le chemin /metrics (activé via la variable N8N_METRICS=true). Les métriques les plus importantes à surveiller :
n8n_executions_totalpar statut (success, error, waiting) : détecter un pic d'erreurs inhabituellesn8n_active_executions_gauge: nombre d'exécutions concurrentes en cours — un plateau élevé indique une saturation des workersn8n_webhook_calls_received_total: volume entrant de webhooks, utile pour détecter des appels abusifsprocess_resident_memory_bytes: consommation RAM du processus n8n — un leak mémoire progressif est difficile à détecter autrement
Alertes indispensables
Configurez dans Grafana Alerting (ou Prometheus AlertManager) les alertes suivantes avec notification vers votre canal Slack, Teams ou email :
- Taux d'erreur des exécutions supérieur à 10 % sur 15 minutes : un workflow cassé qui s'exécute 100 fois par heure génère du bruit sans alerte
- Aucune exécution sur un workflow critique depuis 2 heures : un workflow de facturation qui s'arrête silencieusement est pire qu'un workflow en erreur visible
- RAM utilisée supérieure à 80 % du total : le processus n8n consomme la mémoire de PostgreSQL et Redis si le VPS est saturé
- Espace disque inférieur à 15 % : les logs et le volume PostgreSQL grandissent continuellement sans purge configurée
- Certificat TLS qui expire dans moins de 14 jours : Caddy renouvelle automatiquement, mais des configurations incorrectes peuvent bloquer le renouvellement
Monitoring externe de disponibilité
Un monitoring interne ne détecte pas les pannes réseau ou les plantages du serveur entier. Configurez une vérification externe de disponibilité (Uptime Kuma, Better Uptime, ou l'offre gratuite de Freshping) qui ping votre endpoint n8n toutes les 2 minutes. Si n8n ne répond plus, une alerte SMS ou email doit partir dans les 5 minutes. Uptime Kuma peut être auto-hébergé sur le même VPS ou sur un VPS séparé pour plus de fiabilité.
Conformité RGPD pratique
Le auto-hébergement résout la question de la localisation des données. Il ne résout pas automatiquement toutes les obligations RGPD. Voici les points qui demandent une action concrète.
Registre des traitements
Chaque workflow n8n qui traite des données personnelles doit être documenté dans votre registre des traitements (article 30 RGPD). Pour chaque workflow, documentez : la finalité, les catégories de données traitées, la base légale, les catégories de personnes concernées, la durée de conservation, les éventuels destinataires (APIs tierces), et les mesures de sécurité en place. Si vous avez 40 workflows dont 15 traitent des données personnelles, vous avez 15 entrées à ajouter à votre registre.
Durées de conservation et purge automatique
La variable EXECUTIONS_DATA_MAX_AGE pilote la purge automatique des données d'exécution dans n8n. Cette valeur doit être alignée avec votre politique de conservation :
- Données clients courantes : 30 jours (720 heures) est un défaut raisonnable
- Données de facturation : vérifiez vos obligations légales (généralement 10 ans pour les pièces comptables)
- Données RH candidates : 2 ans maximum après la fin du processus de recrutement selon les recommandations CNIL
- Données de santé : durées spécifiques selon la nature du soin, à vérifier avec votre DPO
DPA avec l'hébergeur et les APIs tierces
Avec un hébergeur souverain, vous devez signer un DPA (Data Processing Agreement) avec lui pour les données personnelles hébergées. OVHcloud et Scaleway proposent des DPA conformes RGPD disponibles en ligne. Pour les APIs tierces utilisées dans vos workflows (CRM, email, outils métier), chaque prestataire qui reçoit des données personnelles doit avoir signé un DPA avec vous. Faites un inventaire des APIs appelées par vos workflows et vérifiez le statut de chaque prestataire.
Anonymisation des logs
Les logs du reverse proxy et de n8n peuvent contenir des données personnelles (adresses IP, emails dans les URLs de webhooks, identifiants dans les query strings). Configurez votre reverse proxy pour anonymiser les IPs dans les logs (remplacer le dernier octet par 0) et évitez de logger des paramètres de requête qui pourraient contenir des données personnelles. La CNIL précise ses attentes sur la conservation des logs de connexion : 12 mois maximum en règle générale.
Analyse d'impact (AIPD)
Une Analyse d'Impact sur la Protection des Données (AIPD) est obligatoire pour les traitements à risque élevé, notamment le profilage, le traitement de données sensibles à grande échelle, ou la prise de décision automatisée. Si vos workflows n8n font du scoring de leads, du traitement de dossiers RH ou de l'extraction de données de santé, une AIPD est probablement requise avant de les mettre en production.
Cas particuliers : APIs IA et données hors UE
Le nœud de conformité le plus fréquent dans les workflows n8n modernes n'est pas l'hébergement de n8n lui-même — c'est l'appel à des APIs d'IA américaines depuis des workflows qui traitent des données personnelles.
OpenAI et Anthropic : données hors UE
Quand votre workflow envoie un email client à l'API OpenAI ou Claude pour le résumer, cet email transite vers des serveurs américains. Même si OpenAI propose une option Zero Data Retention (ZDR) sur API (les données ne sont pas utilisées pour l'entraînement), elles transitent toujours aux États-Unis. Pour les données personnelles, cela nécessite des Clauses Contractuelles Types (CCT) de la Commission européenne, qui doivent être signées avec OpenAI ou Anthropic et documentées dans votre registre des traitements.
En pratique, beaucoup d'entreprises acceptent ce risque pour des données faiblement sensibles. Mais pour des données RH, médicales ou financières, c'est un risque juridique que les DPO écartent systématiquement.
Mistral AI : l'alternative souveraine
Mistral AI est une entreprise française dont les APIs sont hébergées en France et en Europe. Elle propose un DPA conforme RGPD, des modèles de haute qualité pour le français (Mistral Large, Mistral Medium), et une option d'accès dédié pour les entreprises qui ont besoin de garanties supplémentaires. Pour des workflows n8n en contexte français, Mistral AI est la première alternative à évaluer avant OpenAI ou Anthropic.
Albert, le modèle souverain développé par Etalab pour les administrations françaises, est une option pour les entités publiques ou para-publiques. Pour les ETI privées, les modèles Mistral via API sont plus accessibles.
Modèles locaux via Ollama
La solution radicale : Ollama permet de faire tourner des modèles open source (Mistral 7B, Mixtral 8x7B, LLaMA 3 70B, Gemma 2) directement sur votre infrastructure. n8n se connecte nativement à Ollama via son nœud LangChain. Aucune donnée ne quitte votre serveur.
- Mistral 7B Instruct : excellent pour la classification, le résumé et l'extraction en français, tourne sur un serveur avec 16 Go RAM (CPU) ou 8 Go VRAM (GPU)
- Mixtral 8x7B : meilleure qualité, nécessite 48 Go RAM en CPU ou un GPU A10G (24 Go VRAM)
- LLaMA 3 70B : le plus puissant des modèles locaux accessibles, nécessite 2× A10G ou 1× H100
Pour 80 % des cas d'usage métier (classification d'emails, extraction structurée, résumé de documents), Mistral 7B local offre des résultats suffisants. Le surcoût en infrastructure (RAM, GPU si nécessaire) est compensé par l'absence totale de facture API et la garantie souveraine absolue. Notre article sur les agents IA n8n en production détaille quand un modèle local suffit et quand un modèle cloud est justifié.
Budget annuel d'un setup production-grade
Voici le coût total annuel d'un déploiement n8n production-grade pour une ETI de 50 à 200 personnes avec 30 à 80 workflows actifs et 20 000 à 50 000 exécutions par mois.
| Poste | Détail | Coût annuel |
|---|---|---|
| Hébergement VPS | OVHcloud 4 vCPU / 8 Go RAM (Roubaix) | 288 €/an |
| Sauvegarde Object Storage | Scaleway Object Storage 100 Go/mois | 24 €/an |
| Nom de domaine | Sous-domaine dédié (n8n.votredomaine.fr) | 0 € (domaine existant) |
| Certificat TLS | Let's Encrypt via Caddy | 0 € |
| Licence n8n | Community Edition | 0 € |
| Vault / Doppler | HashiCorp Vault Community (auto-hébergé) | 0 € |
| Monitoring | Grafana + Prometheus (auto-hébergé), Uptime Kuma | 0 € |
| APIs IA (Mistral API) | 5 000 appels/mois, prompts moyens | 360–720 €/an |
| Maintenance interne | 4h/mois, profil DevOps junior (55 €/h chargé) | 2 640 €/an |
| Prestataire externe (optionnel) | Accompagnement Tensoria forfait suivi mensuel | 1 200–3 600 €/an |
| Total sans prestataire externe | 3 312–3 672 €/an | |
| Total avec prestataire externe | 4 512–7 272 €/an |
À comparer avec n8n Cloud Business à 667 euros par mois : 8 004 euros par an, sans les APIs IA et sans la maîtrise totale sur la localisation des données. Pour une ETI avec des enjeux de souveraineté, l'auto-hébergement production-grade revient 2 à 3 fois moins cher à volume équivalent. Notre article sur les coûts réels de n8n en production détaille tous les scénarios avec des simulations par volume d'exécutions.
Community Edition vs Enterprise : quand basculer
La question revient régulièrement lors de nos accompagnements. La Community Edition couvre la grande majorité des besoins des ETI. Voici les critères qui font basculer vers l'Enterprise.
Restez en Community Edition si
- Votre équipe de moins de 20 utilisateurs n8n gère ses accès avec email/mot de passe + 2FA
- Vous n'avez pas d'obligation d'audit logs certifiés pour des raisons réglementaires (NIS2 niveau élevé, HDS strict)
- Vous n'avez pas besoin d'environnements séparés (dev/staging/prod) avec des workflows qui se synchronisent via Git nativement
- Votre budget n8n est un critère important et vous pouvez gérer l'intégration LDAP via Authelia ou Authentik
Envisagez l'Enterprise si
- Vous avez plus de 20 utilisateurs n8n avec des rôles granulaires différenciés à gérer
- Vous avez une obligation de SSO via SAML 2.0 ou OIDC (intégration Azure AD, Okta) sans vouloir déployer un proxy d'authentification tiers
- Vous avez besoin d'audit logs natifs et certifiés pour répondre à un audit NIS2 ou un audit client
- Vous avez des équipes distinctes qui travaillent sur des projets séparés et ne doivent pas voir les workflows des autres
- Vous avez besoin d'un SLA contractuel de n8n GmbH (uptime, temps de réponse support)
Le prix de l'Enterprise est négocié directement avec n8n GmbH. D'après les retours du marché, comptez entre 500 et 2 000 euros par mois selon le volume d'exécutions et le niveau de support. C'est un écart significatif avec le Community Edition (gratuit), mais pertinent pour une ETI de 100+ personnes dont les workflows sont des processus critiques.
Notre lecture terrain
Nous avons déployé des installations n8n pour des ETI dans le secteur industriel, juridique et comptable à Toulouse et en région Occitanie. Dans 90 % des cas, la Community Edition bien configurée suffit : authentification 2FA, Authelia pour l'intégration LDAP, logs structurés, sauvegardes Restic, monitoring Grafana.
Le vrai frein à l'adoption n'est pas la licence — c'est la charge opérationnelle du auto-hébergement. Un n8n auto-hébergé mal maintenu est pire qu'un n8n Cloud bien managé. Si vous n'avez pas la ressource interne pour assurer la maintenance, c'est le premier problème à résoudre avant de choisir entre Community et Enterprise.
Aller en production sereinement
Vous déployez n8n pour des données sensibles ? Nous auditons votre setup et sécurisons votre configuration.
Pour aller plus loin
- n8n RGPD et hébergement souverain : le cadre stratégique et juridique avant de passer à la technique
- Combien coûte vraiment n8n en production : tous les postes de coût chiffrés, Cloud vs auto-hébergement, scénarios PME/ETI
- Agents IA n8n en production : pièges, garde-fous et patterns fiables pour des agents autonomes en contexte d'entreprise
- n8n, Zapier ou Make : lequel choisir pour votre PME en 2026 : comparatif complet avant de s'engager sur un outil
- AI Act et conformité PME : obligations concrètes pour les entreprises qui utilisent de l'IA dans leurs processus
- Workflow vs agent IA dans n8n, quand utiliser quoi : le choix d'architecture qui conditionne directement le dimensionnement infra et le budget API
- Agent IA n8n pour répondre aux appels d'offres : cas d'usage typique avec données sensibles (DCE, propales clients) où le auto-hébergement souverain devient obligatoire
- Workflow n8n de relance de factures clients : la donnée financière exige les mêmes garanties RGPD et de souveraineté que les données RH ou contractuelles
- Notre service d'automatisation n8n : accompagnement de bout en bout, de l'audit technique au déploiement production
- Agence n8n Toulouse : Tensoria, spécialiste n8n pour PME et ETI en Occitanie
- Documentation officielle n8n Hosting : référence technique maintenue par n8n GmbH
- Fiches pratiques IA de la CNIL : les obligations RGPD spécifiques aux traitements automatisés avec IA
- NIS2 selon l'ANSSI : périmètre, obligations et calendrier de la directive
