Auto-hébergement de n8n en Suisse : guide de conformité LPD/revDSG pour 2026

Chaque projet d'automatisation que je commence avec un client suisse atteint inévitablement la même question : où vont les données ?
Pour les entreprises qui automatisent les workflows RH, traitent des factures ou routent des emails clients, la réponse compte sous la LPD suisse (loi fédérale révisée sur la protection des données, en vigueur depuis septembre 2023) et le RGPD européen. Ce guide explique le cadre de conformité, quand l'auto-hébergement de n8n est la bonne réponse, et comment le configurer.
Que dit la LPD/revDSG sur l'utilisation d'outils d'automatisation cloud ?
En vertu de la LPD, le traitement de données personnelles via un service tiers constitue une communication de données à ce tiers. Ça s'applique que vous utilisiez Zapier, Make ou une instance n8n hébergée dans le cloud. Les obligations principales :
Vous avez besoin d'une base légale pour le transfert de données. Pour la plupart des automatisations B2B (données employés, données clients), c'est soit un contrat soit des intérêts légitimes — mais ça doit être documenté.
Vous avez besoin d'un accord de traitement des données (ATD/DPA) avec votre sous-traitant. Si vous routez des données personnelles via Make, Zapier ou un fournisseur n8n cloud, vous avez besoin d'un DPA valide avec chacun. Zapier et Make proposent tous les deux des DPA. Sans ça, vous êtes en infraction.
Les règles de transfert transfrontalier s'appliquent. Transférer des données personnelles vers un pays sans protection adéquate des données (les États-Unis, selon la plupart des interprétations) nécessite des garanties supplémentaires : clauses contractuelles types (CCT) ou équivalent. OpenAI et Anthropic proposent des CCT dans le cadre de leurs accords entreprise.
L'auto-hébergement élimine la question du sous-traitant tiers. Si n8n s'exécute sur une infrastructure que vous contrôlez — un VPS en Suisse, un serveur dans votre propre réseau — vos données d'automatisation ne quittent jamais votre périmètre défini. Aucun DPA requis avec n8n lui-même. Aucun problème de transfert transfrontalier.
Quand l'auto-hébergement est-il le bon choix ?
L'auto-hébergement ajoute une charge opérationnelle. Ce n'est pas toujours la bonne réponse. Utilisez ce cadre de décision :
Auto-héberger quand :
- Vous traitez des données personnelles de collaborateurs dans vos workflows (contrats, entrées de paie, documents d'onboarding)
- Vous traitez des données clients que vos propres contrats clients restreignent à quitter la Suisse ou l'UE
- Vous traitez des données de santé ou des données à sensibilité particulière sous l'article 5 de la LPD
- Votre équipe juridique ou sécurité a émis une politique contre les sous-traitants hébergés aux États-Unis pour certaines catégories de données
- Vous voulez éviter une tarification par tâche qui augmente avec le volume d'automatisation
Utiliser Make cloud ou n8n.cloud hébergés quand :
- Vos workflows ne traitent que des données opérationnelles internes non personnelles (rapports de pipeline, vérifications de stock, alertes système)
- Vous avez un DPA signé avec le fournisseur et des CCT pour les transferts vers les États-Unis
- Votre équipe doit modifier les workflows sans support technique
- La simplicité et la rapidité de configuration l'emportent sur les préoccupations de résidence des données
Comment auto-héberger n8n sur infrastructure suisse
Ce qui suit suppose un VPS Linux. Temps de configuration total : 2 à 4 heures pour une instance prête pour la production.
Étape 1 : Choisir votre infrastructure
Fournisseurs avec des serveurs en Suisse ou dans l'UE :
| Fournisseur | Localisation | Notes |
|---|---|---|
| Exoscale | Genève, Zurich | Fournisseur suisse, compatible LPD, ISO 27001 |
| Nine.ch | Suisse | Fournisseur suisse, fort engagement protection des données |
| Hetzner | Allemagne, Finlande | UE, faible coût, solide historique de conformité |
| Infomaniak | Genève | Fournisseur suisse, conforme RGPD/LPD |
Pour la plupart des PME suisses, Exoscale ou Infomaniak offrent le cadre de conformité le plus propre. Hetzner est une option UE économique.
Specs VPS recommandées pour n8n jusqu'à ~10 000 exécutions de workflows/mois : 2 vCPU, 4 Go RAM, 40 Go SSD.
Étape 2 : Installer n8n avec Docker Compose
# docker-compose.yml
version: '3.8'
services:
n8n:
image: n8nio/n8n
restart: always
ports:
- "5678:5678"
environment:
- N8N_BASIC_AUTH_ACTIVE=true
- N8N_BASIC_AUTH_USER=votre_utilisateur
- N8N_BASIC_AUTH_PASSWORD=votre_mot_de_passe
- N8N_HOST=n8n.votredomaine.ch
- N8N_PORT=5678
- N8N_PROTOCOL=https
- WEBHOOK_URL=https://n8n.votredomaine.ch/
- GENERIC_TIMEZONE=Europe/Zurich
- DB_TYPE=postgresdb
- DB_POSTGRESDB_HOST=postgres
- DB_POSTGRESDB_PORT=5432
- DB_POSTGRESDB_DATABASE=n8n
- DB_POSTGRESDB_USER=n8n
- DB_POSTGRESDB_PASSWORD=votre_mot_de_passe_db
volumes:
- n8n_data:/home/node/.n8n
depends_on:
- postgres
postgres:
image: postgres:16
restart: always
environment:
- POSTGRES_USER=n8n
- POSTGRES_PASSWORD=votre_mot_de_passe_db
- POSTGRES_DB=n8n
volumes:
- postgres_data:/var/lib/postgresql/data
volumes:
n8n_data:
postgres_data:
PostgreSQL est recommandé sur SQLite pour la production — meilleure concurrence, support de sauvegarde approprié.
Étape 3 : Configurer HTTPS avec un proxy inverse
Utiliser Nginx + Let's Encrypt (Certbot) pour terminer TLS. n8n doit être servi en HTTPS pour que les endpoints webhook fonctionnent correctement.
server {
listen 443 ssl;
server_name n8n.votredomaine.ch;
ssl_certificate /etc/letsencrypt/live/n8n.votredomaine.ch/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/n8n.votredomaine.ch/privkey.pem;
location / {
proxy_pass http://localhost:5678;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection 'upgrade';
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_cache_bypass $http_upgrade;
}
}
Étape 4 : Configurer les sauvegardes automatisées
Sauvegarder la base de données PostgreSQL et le volume de données n8n quotidiennement. Pour les instances hébergées en Suisse, Exoscale et Infomaniak proposent des solutions de sauvegarde gérées. Alternativement, utiliser un simple cron job pour dumper et chiffrer :
# /etc/cron.daily/n8n-backup
#!/bin/bash
BACKUP_DIR="/backups/n8n"
DATE=$(date +%Y-%m-%d)
docker exec postgres pg_dump -U n8n n8n | gzip > "$BACKUP_DIR/n8n-$DATE.sql.gz"
find "$BACKUP_DIR" -name "*.sql.gz" -mtime +30 -delete
Étape 5 : Restreindre les accès
- Activer la gestion des utilisateurs intégrée de n8n (disponible depuis n8n 0.221)
- Restreindre l'instance à la plage IP de votre entreprise via les règles de pare-feu VPS ou les directives
allow/denyde Nginx - Faire tourner les identifiants selon un calendrier défini
- Activer l'authentification à deux facteurs pour les comptes utilisateurs n8n
Qu'en est-il des modèles IA dans les workflows auto-hébergés ?
Si vos workflows n8n appellent les APIs OpenAI ou Anthropic, les données quittent quand même votre infrastructure lors de l'appel API, même si n8n lui-même est auto-hébergé. Pour les données qui ne peuvent pas quitter la Suisse, utilisez le nœud HTTP Request de n8n pour appeler une instance Ollama hébergée localement.
Configuration Ollama sur le même serveur ou un VPS adjacent :
# Installer Ollama
curl -fsSL https://ollama.com/install.sh | sh
# Télécharger un modèle (Llama 3.1 8B suffit pour la plupart des tâches de classification/extraction)
ollama pull llama3.1:8b
# Ollama écoute sur localhost:11434 par défaut
# Appeler depuis n8n via le nœud HTTP Request : POST http://votre-serveur-ip:11434/api/generate
Pour les tâches d'extraction documentaire (factures, contrats), Llama 3.1 8B gère de manière fiable les sorties JSON structurées. Pour le raisonnement complexe ou les tâches multilingues, Mistral 7B ou Mixtral 8x7B performent mieux.
À quoi ressemble une architecture d'automatisation conforme LPD ?
Une configuration complète pour une PME suisse :
- n8n auto-hébergé sur Exoscale à Zurich — toute l'exécution des workflows reste en Suisse
- PostgreSQL sur le même VPS — l'historique et les logs d'exécution ne quittent jamais le serveur
- Ollama hébergé localement pour les tâches IA impliquant des données personnelles — documents RH, contrats clients, emails employés
- API OpenAI/Anthropic pour les données opérationnelles non personnelles — rapports internes, métriques anonymisées, données de sources publiques — avec DPA signé et CCT
- Sauvegardes quotidiennes automatisées chiffrées au repos — stockées sur infrastructure suisse
- Comptes utilisateurs n8n avec 2FA — accès restreint aux personnes nommées
Cette configuration satisfait les exigences LPD pour le traitement des données personnelles, élimine les problèmes de transfert transfrontalier pour les catégories de données sensibles, et vous permet tout de même d'utiliser des modèles IA de pointe là où les données le permettent.
Faut-il faire appel à un avocat pour mettre ça en place ?
Pour l'infrastructure et la configuration technique : non. Pour la documentation légale (le registre des activités de traitement, les modèles de DPA pour les sous-traitants tiers que vous utilisez, et la mise à jour de la notice de confidentialité), une revue par un avocat ou un délégué à la protection des données est recommandée. C'est généralement une prestation de deux à quatre heures pour une PME standard.
Par où commencer
Si vous utilisez actuellement des workflows d'automatisation via un outil SaaS hébergé aux États-Unis et traitez des données personnelles dans ces workflows, la première étape est un audit : cartographier quels workflows touchent des données personnelles, vérifier si vous avez un DPA valide avec chaque outil, et identifier quels flux présentent le risque le plus élevé.
Si vous souhaitez de l'aide pour concevoir une architecture d'automatisation conforme LPD, prenez contact. Je travaille régulièrement avec des entreprises suisses sur ce sujet. Services liés : automatisation de workflows → · intégration IA avec modèles locaux →
