La nLPD et Zapier, ce que le texte dit vraiment
Quand j'entends un dirigeant me dire qu'il veut "quitter Zapier à cause de la nLPD", ma première question est toujours la même. As-tu lu l'article 16 de la loi, ou est-ce que quelqu'un t'a fait peur avec un post LinkedIn ? La réponse est presque toujours la seconde option.
Voici ce que la nouvelle loi fédérale sur la protection des données (entrée en vigueur le 1er septembre 2023, source Fedlex RS 235.1) dit réellement sur les transferts à l'étranger. Tu peux transférer des données personnelles vers un pays étranger si ce pays offre un niveau de protection adéquat, reconnu par le Conseil fédéral. Et depuis le 15 septembre 2024, le Conseil fédéral a reconnu le Swiss-U.S. Data Privacy Framework. Les entreprises américaines certifiées dans ce cadre peuvent recevoir des données depuis la Suisse sans clause contractuelle supplémentaire.
La limite technique que personne ne souligne. Ce framework repose sur une certification volontaire de l'entreprise américaine. Si l'éditeur de ton outil d'automatisation n'est pas certifié, ou si sa certification expire, tu te retrouves sans filet juridique du jour au lendemain. Et toi, dirigeant, tu es personnellement visé par les amendes. L'article 60 de la nLPD prévoit jusqu'à 250 000 CHF d'amende pénale contre la personne physique responsable, pas contre l'entreprise. C'est un détail que les comparatifs "Top 7 alternatives à Zapier" omettent systématiquement.
Tes données partent-elles vraiment aux États-Unis ?
Avant de migrer quoi que ce soit, fais un exercice qui prend dix minutes et qui peut t'éviter des semaines de travail inutile. Liste tes workflows actifs. Pour chacun, note ce qui transite réellement. Un workflow qui envoie le prénom d'un prospect dans un canal Slack n'a pas le même profil de risque qu'un workflow qui synchronise des données RH ou des informations médicales vers un CRM américain.
Voici comment trier.
- Données non personnelles (statistiques agrégées, numéros de commande sans nom). Aucun enjeu nLPD, reste sur Zapier sans souci.
- Données personnelles courantes (nom, email, téléphone). Vérifie la certification Data Privacy Framework de ton éditeur. Si elle est active, le transfert est couvert.
- Données sensibles (santé, opinions, données RH détaillées). Là, même avec un framework en place, tu veux un avis juridique et probablement un hébergement local.
J'ai vu des dirigeants lancer une migration complète vers n8n auto-hébergé alors que 80% de leurs workflows ne faisaient transiter que des identifiants de commande. Le calcul est simple. Si tu as 15 workflows et que 12 ne manipulent aucune donnée personnelle, tu n'as que 3 workflows à traiter. Migrer les 15 revient à brûler du temps et de l'argent pour un risque qui n'existe pas sur les 12 premiers. Fais le tri avant de toucher à l'infrastructure.
Les alternatives sérieuses et leurs vrais plafonds
Les listicles te donnent des noms. Je vais te donner ce que chaque outil ne peut pas faire, parce que c'est là que les projets déraillent.
n8n auto-hébergé. C'est l'option qui revient le plus souvent dans les discussions sur la souveraineté. Tu installes l'outil sur un serveur suisse, tes données ne sortent pas. Sur le papier, c'est parfait. En pratique, n8n en auto-hébergement suppose que quelqu'un gère les mises à jour, les sauvegardes, la sécurité du serveur, et les certificats SSL. Si tu n'as pas de personne technique en interne, tu dépends d'un prestataire externe pour chaque incident. J'ai détaillé les vrais enjeux de cette approche dans mon article sur n8n auto-hébergé et la souveraineté. Le plafond, c'est la maintenance. Pas l'outil lui-même.
Make (ex-Integromat). Hébergement en Europe (AWS Frankfurt pour la plupart des comptes). Plus accessible que n8n pour un non-technicien. Mais Make reste une entreprise tchèque avec des sous-traitants potentiellement hors UE. Tu dois vérifier leur liste de sous-traitants, qui change sans préavis. Et le Cloud Act s'applique si des données passent par des serveurs d'un fournisseur américain, même situés en Europe. Le plafond ici, c'est la transparence. Tu n'as pas toujours la visibilité sur la chaîne complète.
Activepieces. Open source, auto-hébergeable comme n8n. L'interface est plus récente, plus propre. Mais le nombre de connecteurs natifs est nettement inférieur à Zapier ou Make. Si tu utilises des logiciels métier suisses ou de niche, tu vas devoir développer tes propres intégrations via l'API. Le plafond, c'est l'écosystème de connecteurs.
Aucune de ces options n'est une solution miracle. Chacune déplace le problème ailleurs. Pour une vue d'ensemble plus large, j'ai comparé les approches dans le guide sur les alternatives souveraines à Zapier.
Auto-héberger en Suisse, la facture que personne ne montre
"n8n est gratuit et open source." C'est la phrase qui m'a coûté le plus cher en temps perdu. Pas parce qu'elle est fausse, mais parce qu'elle omet tout ce qui vient après l'installation.
Fais le calcul toi-même. Prends le coût mensuel d'un VPS suisse capable de faire tourner n8n avec tes volumes. Entre 30 et 80 CHF par mois selon le prestataire et la charge. Ajoute le temps de maintenance. Mises à jour de n8n (une toutes les deux à trois semaines en moyenne), mises à jour du système d'exploitation, surveillance des logs, gestion des certificats, sauvegardes quotidiennes et tests de restauration. Si tu fais ça en interne, compte entre 4 et 8 heures par mois pour quelqu'un qui sait ce qu'il fait. Si tu délègues à un prestataire IT, facture entre 150 et 200 CHF de l'heure en Suisse romande.
Le calcul annuel donne quelque chose comme ça. Hébergement, environ 600 à 960 CHF. Maintenance externalisée à 6 heures par mois, entre 10 800 et 14 400 CHF. Total, entre 11 400 et 15 360 CHF par an. Compare ça à un abonnement Zapier Team à environ 800 CHF par an, ou un Make Pro à des montants similaires. La différence est massive. Et elle ne couvre même pas les incidents imprévus, les migrations de version qui cassent un workflow, ou le jour où ton prestataire IT est en vacances et que ta synchronisation CRM tombe.
Je ne dis pas que l'auto-hébergement est une mauvaise idée. Je dis que le vendre comme "gratuit" à un dirigeant sans équipe IT, c'est malhonnête. J'ai fait cette erreur moi-même, en sous-estimant la charge de maintenance sur un projet. La leçon a été chère. Le coût réel de n8n en contexte suisse mérite d'être posé à plat avant toute décision.

Migrer sans tout casser, trois étapes pour une équipe de vingt
Si après le tri de tes workflows et le calcul des coûts, tu décides quand même de migrer certains flux, voici comment éviter le chaos. Ce n'est pas de la théorie. C'est l'ordre dans lequel je procède après m'être planté en voulant tout migrer d'un coup.
Étape 1. Isoler les workflows sensibles. Reprends ta liste de l'exercice précédent. Ne migre que les workflows qui manipulent des données personnelles sensibles ou des données pour lesquelles tu n'as pas de base juridique claire pour le transfert. Les autres restent où ils sont. Résiste à la tentation de "tout refaire proprement tant qu'on y est". C'est le piège classique qui transforme un projet de deux semaines en trois mois.
Étape 2. Faire tourner en parallèle. Pendant au moins quatre semaines, le nouveau workflow et l'ancien tournent en même temps. Tu compares les résultats. Tu notes les écarts. Les connecteurs n8n ou Make ne se comportent pas exactement comme ceux de Zapier. Les formats de date diffèrent, les gestions d'erreur aussi, les limites de débit API ne sont pas les mêmes. Ces détails ne se voient qu'en production réelle, jamais dans un test à blanc.
Étape 3. Documenter ce qui a changé pour l'équipe. Le workflow migré doit être compréhensible par quelqu'un d'autre que celui qui l'a construit. Un document d'une page par workflow suffit. Ce qu'il fait, ce qui déclenche l'exécution, ce qui se passe en cas d'erreur, et qui contacter. Sans ça, tu crées une dépendance à une seule personne. Et si cette personne, c'est toi, tu viens de te fabriquer un nouveau problème. J'observe souvent que cette étape de documentation est celle qui saute en premier quand le projet prend du retard. C'est pourtant celle qui détermine si la migration tient dans la durée.
Quand rester sur Zapier est la bonne décision
Ça va peut-être te surprendre dans un article qui parle d'alternatives, mais rester sur Zapier peut être parfaitement défendable. Et je le pense sincèrement.
Si tes workflows ne font transiter que des données non personnelles ou des données personnelles courantes vers un éditeur certifié au Swiss-U.S. Data Privacy Framework, tu es couvert. Si tu as documenté ta base juridique pour chaque transfert et que tu peux la montrer au PFPDT en cas de contrôle, tu es en règle. Migrer dans ce cas ne t'apporte rien juridiquement. Tu gagnes un sentiment de sécurité, pas une sécurité réelle.
Le vrai risque n'est pas l'outil. C'est l'absence de documentation. Un dirigeant qui utilise Zapier avec un registre des traitements à jour, des contrats de sous-traitance signés (article 9 nLPD), et une analyse d'impact pour les données sensibles est dans une bien meilleure posture qu'un dirigeant qui a migré sur n8n auto-hébergé en Suisse mais qui n'a documenté aucun traitement.
Ce que j'ai appris, parfois douloureusement, c'est que la conformité n'est pas une question d'adresse IP. C'est une question de gouvernance. L'outil est un détail technique dans une décision qui est d'abord organisationnelle et juridique. Si tu veux poser les bases correctement avant de choisir un outil, commence par un tri honnête de tes besoins en automatisation. Et si tu as des données vraiment sensibles, parle à un juriste avant de parler à un consultant en automatisation. Moi y compris.




