L'administration fédérale suisse introduit Microsoft 365 sous supervision du PFPDT, avec garde-fous et restrictions. Les banques suisses placent des données clients dans le cloud américain, sous cadre FINMA. Depuis vingt ans, des millions de PME européennes rangent devis, factures et fichiers clients dans Gmail et Outlook. Rien de tout cela n'est illégal. L'IA ne change pas la règle.
Le drapeau du fournisseur n'a jamais été la question. La vraie ligne de partage, c'est avec ou sans gouvernance. Cette page le démontre, texte de loi par texte de loi, sans rien cacher des vrais points sensibles.
Si travailler avec un acteur américain rendait la conformité impossible, plus personne ne travaillerait sur ordinateur en Europe.
Toute l'Europe fonctionne au quotidien sur des prestataires américains, sous RGPD et sous LPD : banques, hôpitaux, administrations, fiduciaires, cabinets d'avocats. Ce n'est pas une zone grise tolérée, c'est un usage encadré et documenté depuis des années. Le règlement européen n'interdit pas les fournisseurs américains ; il encadre les transferts de données (RGPD, chapitre V, art. 44 à 49) et impose des garanties. Nuance décisive : encadré n'est pas interdit.
Le Préposé fédéral suisse (PFPDT) le dit à sa manière : la loi sur la protection des données, « formulée de manière neutre du point de vue technologique », s'applique directement à l'IA. Elle ne bannit aucun outil. Elle fixe des principes et un cadre. Le reste tient à la mise en œuvre.
« On n'a pas le droit de mettre des factures fournisseurs ou des données clients chez un prestataire américain. »
C'est un traitement comme un autre : base légale + contrat de sous-traitance (DPA) + outil de transfert. Une facture ordinaire n'est pas une donnée sensible, sauf si son contenu révèle une catégorie protégée (santé, religion…). Rien ne l'interdit par principe.
« Le CLOUD Act rend tout prestataire US illégal. »
Le CLOUD Act ne crée aucune interdiction. C'est une loi de procédure qui pose un conflit de lois potentiel, à gérer par analyse de risque et mesures contractuelles. Pas une prohibition.
« Héberger en Suisse ou en UE me rend automatiquement conforme. »
Faux aussi. La localisation ne crée pas la conformité. Sans registre, DPA et base légale, une PME « 100 % suisse » n'est pas en règle pour autant.
« L'administration et les banques n'ont évidemment pas le droit au cloud américain. »
Au contraire : l'administration fédérale suisse introduit Microsoft 365 sous supervision du PFPDT, avec garde-fous, et les banques placent des données clients dans le cloud sous cadre FINMA.
La moitié des « corrections » entendues en commentaire confondent les deux textes. Ce ne sont ni les mêmes lois, ni les mêmes autorités.
La nouvelle loi fédérale sur la protection des données (nLPD) et le RGPD suivent la même logique de fond : finalité, proportionnalité, minimisation, sécurité. Mais le RGPD ne s'applique à une entreprise suisse que dans des cas précis : traiter des données de personnes situées dans l'UE, leur offrir des biens ou services, ou suivre leur comportement. Pour l'essentiel d'une PME romande, la référence est la LPD, et l'autorité est le PFPDT, pas une CNIL.
| Critère | nLPD (Suisse) | RGPD (UE) |
|---|---|---|
| Autorité | PFPDT (Préposé fédéral), Berne | Autorités nationales (CNIL, etc.) + EDPB |
| Champ | Traitements en Suisse ou avec effet en Suisse | Personnes/marché de l'UE, y compris entreprises hors-UE qui les ciblent |
| Transferts | Art. 16-17 LPD : liste d'adéquation du Conseil fédéral, sinon clauses types du PFPDT | Chapitre V, art. 44-49 : décision d'adéquation, sinon clauses contractuelles types (SCC) |
| Analyse d'impact | AIPD — art. 22 LPD (risque élevé) | AIPD/DPIA — art. 35 RGPD |
| Adéquation des USA | Swiss-U.S. DPF (dès le 15.09.2024) — cadre distinct | EU-U.S. DPF (dès juillet 2023) |
| Sanctions | Amendes pénales jusqu'à 250 000 CHF, visant les personnes physiques responsables | Amendes administratives jusqu'à 4 % du CA mondial, visant l'entreprise |
Depuis le 15 septembre 2024, la Suisse reconnaît un niveau de protection adéquat pour les transferts vers les organisations américaines certifiées au Swiss-U.S. Data Privacy Framework (décision du Conseil fédéral du 14.08.2024, inscrite à l'annexe 1 de l'ordonnance OPDo). Attention au piège : c'est un cadre séparé de l'UE. Une entreprise américaine doit être certifiée spécifiquement sous le volet suisse ; la certification EU-U.S. seule ne suffit pas pour un transfert depuis la Suisse.
Les États-Unis figurent à l'entrée n°44 de l'annexe 1 de l'OPDo (RS 235.11) : adéquation « réputée garantie pour les données personnelles traitées par les organisations certifiées » au titre du décret exécutif 14086 et de la désignation de la Suisse, le 7 juin 2024, comme État bénéficiant du mécanisme de recours à deux niveaux (Data Protection Review Court). Hors certification DPF, le transfert retombe sous l'art. 16 al. 2 LPD (clauses types du PFPDT, BCR).
Voici, article par article, ce que la LPD demande réellement. Ni plus, ni moins.
En clair, la loi demande quatre choses : savoir pourquoi on traite une donnée, n'en prendre que le nécessaire, la sécuriser, et encadrer toute sortie du pays. Les articles qui suivent ne font que le préciser.
Le cœur tient en quelques principes de l'art. 6 LPD : licéité, bonne foi, proportionnalité, finalité déterminée et reconnaissable, et destruction ou anonymisation des données « dès qu'elles ne sont plus nécessaires ». L'idée de collecter le moins de données possible n'est pas un slogan : elle découle de la proportionnalité (art. 6) et se concrétise à l'art. 7 al. 3, qui impose des préréglages limitant le traitement « au minimum requis par la finalité ».
L'art. 7 pose la protection des données dès la conception et par défaut (privacy by design / by default). L'art. 22 exige une analyse d'impact (AIPD) lorsque le traitement est « susceptible d'entraîner un risque élevé pour la personnalité ou les droits fondamentaux ». Et lorsque les données quittent la Suisse, les art. 16 et 17 encadrent le transfert. C'est tout. Aucun de ces articles ne mentionne la nationalité du prestataire.
Une page qui cache les points sensibles se fait démonter en dix minutes. Alors on les nomme : surveillance américaine et transferts transatlantiques.
Le sujet réel n'est pas « américain = interdit », c'est la surveillance permise par le droit américain (FISA Section 702, CLOUD Act) et la fragilité juridique des cadres de transfert. C'est un feuilleton : la Cour de justice de l'UE a invalidé le Safe Harbor en 2015, puis le Privacy Shield en 2020 (arrêt Schrems II), au motif de FISA 702 et de l'absence de recours effectif pour les Européens. Le Data Privacy Framework de 2023 a pris le relais. Il est valide aujourd'hui, mais contesté.
Point d'honnêteté qui rend cette page robuste et vérifiable : selon l'EDPB (Guidelines 05/2021), même un accès à distance, depuis un pays tiers, à des données stockées dans l'EEE constitue un transfert. Et pour une IA qui doit lire la donnée en clair pour la traiter, le chiffrement seul ne résout pas tout. C'est le fond du problème CLOUD Act. On l'assume au lieu de le maquiller.
Un fournisseur sous juridiction américaine peut, en théorie, recevoir une injonction pour des données en sa « possession, custody or control », où qu'elles soient stockées. C'est un conflit de lois, pas une interdiction : l'accès doit être ciblé, fondé sur un mandat judiciaire, et le prestataire peut le contester au nom du RGPD. Mais le résidu existe. On ne prétend pas le contraire. On construit une architecture qui le neutralise (section suivante).
On ne choisit pas « souverain ou pas ». On choisit son niveau selon le risque réel du traitement. Plus de souveraineté = plus d'effort et de maîtrise à assumer (le coût, lui, dépend du volume). On dimensionne selon le risque.
La plupart des traitements d'une PME (résumer, extraire, pré-rédiger, classer) vivent très bien au palier ② : la donnée est traitée dans l'UE, le fournisseur du modèle n'y a pas accès, elle ne sert pas à l'entraînement. Pour un cas vraiment critique, on monte d'un cran. On ne prétend pas que tout le monde doit auto-héberger un modèle : ce serait une posture, pas de l'ingénierie.
Le drapeau, c'est une brique. La gouvernance, c'est le mur. Voici la pile concrète qui transforme « on utilise une IA » en « on utilise une IA de façon maîtrisée ».
Attention à une confusion fréquente. Le secret professionnel pénal (art. 321 CP) vise nommément l'avocat, le notaire, le médecin et leurs auxiliaires. Un fiduciaire ou expert-comptable n'y figure pas en tant que tel (sauf dans son rôle d'organe de révision). Son secret est contractuel et relève de la LPD, pas de l'infraction pénale de l'art. 321. Autrement dit, l'argument « je suis fiduciaire, secret professionnel, interdiction du cloud » ne tient juridiquement pas de la même façon que pour un avocat. Pour ces derniers, un cloud (surtout à l'étranger) est plus sensible et le consentement du client (art. 321 ch. 2) reste le réflexe prudent.
La circulaire FINMA 2018/3 autorise explicitement l'externalisation, y compris à l'étranger, sous conditions : droit d'audit intégral opposable à la banque, à son auditeur et à la FINMA, et accès aux informations « à tout moment en Suisse ». Si le secteur le plus surveillé du pays met des données clients dans le cloud américain de manière encadrée, la question n'est plus « a-t-on le droit », mais « comment ».
Chaque objection reçoit un verdict honnête : fausse, ou vraie mais nuancée. Quand elle a un fond de vérité, c'est écrit noir sur blanc. C'est ça, être défendable.
Le CLOUD Act (2018) est une loi de procédure pénale, pas une interdiction. Une injonction doit être ciblée, fondée sur un mandat judiciaire décrivant « avec particularité » les données visées ; ce n'est pas un accès général au serveur. Le prestataire peut la contester au nom d'un conflit avec le RGPD. Le DOJ le précise : le CLOUD Act n'étend la juridiction américaine à aucune nouvelle entreprise étrangère et ne modifie pas l'exigence de rattachement (personal jurisdiction). Le vrai enjeu est le conflit de lois, à traiter par analyse de risque, pas une prohibition.
Sources : U.S. DOJ, CLOUD Act Resources · Cross-Border Data Forum, CLOUD Act FAQs.
La disposition de collecte de masse (Section 215) a expiré le 15 mars 2020 et n'a jamais été réautorisée. Le référentiel pertinent aujourd'hui est FISA Section 702 (surveillance ciblée de non-Américains hors des USA). Citer « le Patriot Act » en 2026, c'est se tromper de loi. FISA 702 reste critiquable, mais ce n'est pas la collecte de masse fantasmée.
Sources : Congressional Research Service R40138 · EFF, « Section 215 Expired ».
La distinction est décisive. Grand public gratuit : les données peuvent servir à l'amélioration, sauf opt-out. C'est le fond de vérité. API et offres entreprise : pas d'entraînement par défaut. OpenAI : « we do not train on any inputs or outputs from our products for business users, including the API ». Anthropic : ne pas entraîner sur les contenus commerciaux. Une option Zero Data Retention existe. Pour un usage pro via API, l'objection tombe.
Sources : OpenAI Enterprise Privacy · Anthropic Commercial Terms & API data retention.
Le RGPD (art. 28) et la LPD (art. 9) autorisent explicitement la sous-traitance, encadrée par un contrat écrit (le DPA). L'art. 9 LPD : « le traitement peut être confié à un sous-traitant pour autant qu'un contrat ou la loi le prévoie ». Le caractère américain n'ajoute qu'une brique : un outil de transfert. Rien n'interdit la sous-traitance par principe.
Sources : RGPD art. 28 · LPD art. 9 (Fedlex).
L'AI Act régule le risque et l'usage, jamais la nationalité du fournisseur. Un « provider » est défini fonctionnellement, sans critère de nationalité. Au contraire, la loi attrape les fournisseurs hors-UE dès qu'ils mettent un système sur le marché européen. Modèle américain et modèle européen sont soumis aux mêmes obligations selon leur classe de risque.
Sources : Commission européenne, cadre réglementaire IA · AI Act, art. 3 (définitions).
Trois cas. Au repos / en transit : le prestataire détient souvent la clé, l'objection a un fond. Client-side / BYOK : si le client garde la clé, le prestataire ne peut techniquement pas produire du clair, c'est la vraie parade. Inférence IA : pour qu'un modèle raisonne, la donnée doit être en clair en mémoire. Le chiffrement de bout en bout est alors incompatible avec le traitement. La protection vient de l'engagement contractuel (pas d'entraînement, Zero Data Retention), pas de la cryptographie. Il faut le dire droit.
Source : Anthropic, API & data retention (garantie contractuelle, pas cryptographique pendant l'inférence).
Le DPF tient toujours : le 3 septembre 2025, le Tribunal de l'UE a rejeté le recours Latombe et confirmé la décision d'adéquation de 2023 (un appel est pendant, l'incertitude n'est pas nulle). Surtout, même en cas d'invalidation, il reste les clauses contractuelles types + mesures supplémentaires (art. 46 RGPD). La CJUE a d'ailleurs, dans Schrems II, invalidé le Privacy Shield tout en confirmant la validité des SCC. On prévoit les SCC en filet, précisément pour ne pas dépendre d'une décision politique.
Sources : IAPP (rejet Latombe, 03.09.2025) · EDPB, Recommandations 01/2020.
Deux réalités cassent l'équation. Un prestataire européen peut être exposé au droit américain s'il utilise des sous-traitants ou une maison-mère sous juridiction US (le critère du CLOUD Act est le contrôle, pas la localisation du datacenter). Et un prestataire américain peut être parfaitement conforme avec DPA, SCC, certification DPF, Zero Data Retention. Choisir un acteur européen réduit la surface d'exposition, c'est un argument légitime de réduction de risque, ce n'est ni une garantie automatique ni une disqualification.
Sources : CMS, white paper CLOUD Act vs souveraineté · Cross-Border Data Forum.
Vrai : le 20 mars 2023, un bug d'une librairie open-source a exposé quelques heures des titres de conversations et des données de facturation partielles. OpenAI l'a reconnu. Nuance : c'était un bug d'un composant, pas une revente de données ; la question LPD/RGPD n'est pas « zéro risque » mais « mesures de sécurité appropriées » (art. 32 RGPD / art. 8 LPD) et notification des violations. Un incident corrigé et notifié ne rend pas l'usage interdit ; il rappelle l'obligation de sécurité, qui vaut pour tout prestataire.
Source : OpenAI, post-mortem du 20 mars 2023.
L'art. 22 RGPD encadre les décisions fondées exclusivement sur un traitement automatisé, produisant des effets juridiques ou significatifs, sans intervention humaine (ex. refus de crédit automatique). Utiliser un modèle pour trier, résumer, extraire ou pré-rédiger, avec un humain qui valide, ne tombe pas sous l'interdiction. La quasi-totalité des automatisations bureautiques gardent un humain dans la boucle.
Source : RGPD, art. 22.
La localisation ne crée pas la conformité. Héberger à Genève ou à Francfort n'exonère de rien : il faut toujours une base légale, un registre, un DPA avec chaque sous-traitant, des mesures de sécurité, la gestion des droits des personnes. La résidence des données réduit le risque de transfert ; ce n'est pas un label de conformité. Beaucoup de PME se croient « en règle parce que c'est suisse » alors que le socle documentaire manque.
Sources : LPD (obligations indépendantes de la localisation) · RGPD art. 28.
Traiter des factures ou des données clients suit la même check-list que tout traitement : base légale (exécution d'un contrat, intérêt légitime), DPA, outil de transfert si sortie de l'EEE/Suisse. Une facture reste un traitement ordinaire, parfaitement encadrable. Les données sensibles (santé, art. 9 RGPD) exigent des garanties renforcées, mais des factures fournisseurs n'en relèvent pas.
Sources : RGPD art. 28 · LPD (sous-traitance + transferts).
On ne cache aucun contre-cas. On montre l'échelle réelle de l'usage légal, puis on désamorce honnêtement les décisions brandies pour faire peur.
Oui, il existe des décisions d'autorités. Non, aucune ne dit « le cloud américain est illégal ». Toutes reprochent la même chose : un responsable de traitement public, aux obligations renforcées, qui a mal documenté ou mal configuré ses transferts. Regardons de près.
Le fil rouge : la plupart des objections confondent conflit de lois avec interdiction, et localisation avec conformité. Le vrai travail n'est jamais le choix binaire « US = illégal / EU = safe ». C'est le socle : base légale, DPA, outil de transfert, sécurité, documentation. De la gouvernance.
C'est la gouvernance. Une IA américaine utilisée avec une architecture et une gouvernance sérieuses est conforme. Un outil « 100 % suisse » sans socle documentaire ne l'est pas. Voilà toute l'affaire.
Tous les sigles et notions de la page, définis en clair. Le lexique de référence LPD / RGPD / IA.
Textes officiels et sources de référence, vérifiés le 3 juillet 2026. Chaque lien résout.