« Une IA américaine, c'est non conforme ? » Non. Et voici pourquoi.
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.
- Sources officielles vérifiées le 03.07.2026
- Rigueur, pas règlement de comptes
- 4 schémas · 12 objections tranchées
« Utiliser une IA américaine, c'est illégal. » C'est inexact.
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.
- ✕ Mythe
« On n'a pas le droit de mettre des factures fournisseurs ou des données clients chez un prestataire américain. »
✓ Réalité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.
- ✕ Mythe
« Le CLOUD Act rend tout prestataire US illégal. »
✓ Réalité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.
- ✕ Mythe
« Héberger en Suisse ou en UE me rend automatiquement conforme. »
✓ Réalité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.
- ✕ Mythe
« L'administration et les banques n'ont évidemment pas le droit au cloud américain. »
✓ Réalité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.
En Suisse, le cadre de référence est la nLPD. Pas le RGPD.
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 |
Le point que presque personne ne connaît : la Suisse a sa PROPRE adéquation US
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.
La loi n'interdit pas les fournisseurs américains. Elle impose des principes.
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.
1Le traitement contient des données personnelles ?
Pas de contrainte LPD
Reste possible : contrat, secret métier, confidentialité
2Ce sont des données sensibles ?
santé · génétique · biométrie · religion · opinions · origine · vie sexuelle · poursuites, ou secret pro (avocat, médecin…)
Socle standard, données ordinaires
- Finalité · proportionnalité · sécurité · information
- DPA si prestataire externe · validation conseillée
- Registre si ≥ 250 employés *
Socle renforcé, sensibles / secret pro
- Consentement exprès si le consentement justifie (art. 6 al. 7)
- Secret pro (art. 321 CP) : cloud souvent conditionné au consentement du client · souveraineté plus haute
AIPD (art. 22), transversale, pas réservée au sensible
obligatoire dès un risque élevé : profilage / scoring à grande échelle inclus
3L'outil : contrat (DPA) + aucun entraînement sur les données ?
✕ En l'état, non
Outil grand public gratuit ou pas de contrat (DPA) : ces données n'ont rien à y faire. → API/entreprise, rapatrier, renoncer. Sensible/secret pro sans base : interdit.
✓ Pas de transfert
Hébergé en Suisse ou pays adéquat (UE/EEE, UK, Canada…). DPA + socle LPD/RGPD.
✓ Adéquation DPF
Prestataire US certifié (Swiss-U.S. / EU-U.S.) + DPA
Pays tiers non adéquat
Clauses types (art. 16 al. 2) + analyse de transfert, ou dérogation art. 17 (consentement exprès…)
Le doute « boîte américaine » a un vrai fondement. On ne le balaie pas.
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.
- 2000Safe Harbor✕ invalidé en 2015
- 2016Privacy Shield✕ Schrems II, 2020
- 2023Data Privacy Framework✓ valide, décision 2023/1795Latombe rejeté (03.09.2025)
- 2025-26Sous pressionAppel Latombe pendant (31.10.2025)+ noyb saisit la Commission (30.06.2026)
Concession assumée : le résidu CLOUD Act
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).
La souveraineté n'est pas binaire. C'est un curseur.
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.
Effort / maîtrise ▲
- ①API publique grand publicrisque élevé si sensibleDonnées hors UE possibles. À éviter pour de la donnée sensible.
- ②Cloud US en région UE✓ TimeKraft, en prodEx. AWS Bedrock, Francfort. Traité dans l'UE, fournisseur sans accès, pas d'entraînement. Résidu CLOUD Act à traiter (mesures suppl.).
- ③Modèle managé UEsouveraineté accrueHébergé et opéré en UE. On remonte encore d'un cran.
- ④Auto-hébergement, poids ouvertssouveraineté maximaleEx. Mistral OCR self-host, modèles ouverts sur infra maîtrisée. Effort max ; coût/token variable.
Souveraineté croissante ▶
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.
La conformité ne se joue pas sur le fournisseur. Elle se joue autour.
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 ».
1 · Cadre légalLPD / RGPD, principes de traitement et bases de transfert
art. 6-7-16 LPD2 · AIPD, analyse d'impactIdentifier le risque élevé avant de déployer
art. 22 LPD3 · DPA + registre des sous-traitantsContrat de sous-traitance, clauses de transfert, cartographie
art. 9 LPD4 · Minimisation + validation humaineLe moins de données possible ; un humain décide
art. 7 · 21 LPD5 · Journalisation + auditabilitéTracer qui a fait quoi, prouver la maîtrise
ISO 420016 · Le workflow, en productionMaîtrisé, documenté, réversible
Cas des professions à secret : fiduciaires, avocats, médecins
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.
Secteur bancaire : la preuve par le plus régulé
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 ».
Les 12 phrases qu'on entend. Tranchées, une par une, sourcées.
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).
« Interdit » : quasi inexistant. « Mal documenté » : ça, oui.
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.
- M365
- L'administration fédérale suisse introduit Microsoft 365 sous supervision du PFPDT, avec garde-fous et restrictions, pas une interdiction.
- FINMA
- Les banques suisses placent des données clients (CID) dans le cloud US, encadrées par la circulaire d'externalisation 2018/3.
- ~345 M
- d'abonnés payants à Microsoft 365 dans le monde en 2025 (~30 % du marché des suites bureautiques). Estimations agrégées, Statista.
- 15-20 ans
- que des millions de PME européennes rangent devis, factures et fichiers clients dans Gmail et Outlook. Sans que ce soit illégal.
Les contre-cas, traités honnêtement
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.
- 08.03.2024EDPS
Commission européenne / Microsoft 365. Le contrôleur européen reproche à la Commission un contrat qui « ne spécifiait pas suffisamment quels types de données personnelles » étaient collectés, et des transferts mal encadrés. Base juridique : le règlement propre aux institutions de l'UE, pas le RGPD des entreprises. Ce n'est ni une amende, ni une interdiction de Microsoft.
→ Reproche au responsable, pas au produit. Décision contestée en justice. - 25.04.2022Bade-Wurtemberg
Écoles allemandes / M365. L'autorité recommande d'y renoncer. Mais elle écrit noir sur blanc que « les écoles sont soumises à des exigences nettement plus strictes que les entreprises » : données d'enfants, pas de consentement valable, contexte scolaire sensible.
→ Ne se transpose PAS aux PME. - 15.11.2025Hesse
Le revirement. L'autorité de Hesse, qui avait rejeté Office 365 en 2019, conclut désormais que Microsoft 365 peut être utilisé de façon conforme au RGPD, parlant de « sécurité juridique fondamentale pour les entreprises et les autorités ». Raisons : Data Privacy Framework, EU Data Boundary de Microsoft, DPA amélioré.
→ La démonstration que c'est une question de cadre et de contrat qui évolue, pas d'illégalité. - 2022Danemark
Commune de Helsingør / Google Workspace. Interdiction temporaire pour DPIA et analyse de risque insuffisantes (art. 35-36 RGPD), levée après correction de la documentation. Cas d'une commune traitant des données d'élèves mineurs.
→ Interdiction levée après mise en conformité documentaire.
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.
Que ce soit LPD ou RGPD, américain ou européen, la question n'est jamais le drapeau.
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.
Chaque terme, expliqué simplement.
Tous les sigles et notions de la page, définis en clair. Le lexique de référence LPD / RGPD / IA.
Lois & cadres réglementaires
- nLPD (LPD)Suisse
- Loi fédérale sur la protection des données (RS 235.1), en vigueur depuis le 1er septembre 2023. Cadre de référence des entreprises suisses ; technologiquement neutre, elle s'applique directement à l'IA.
- OPDoOrdonnance
- Ordonnance d'exécution de la LPD (RS 235.11). Fixe notamment la liste des pays à protection adéquate (annexe 1) et le contenu exigé des garanties de transfert.
- RGPDUE
- Règlement général sur la protection des données (UE 2016/679). S'applique à une entreprise suisse quand elle vise des personnes dans l'UE (biens/services, suivi de comportement).
- AI ActUE 2024/1689
- Règlement européen sur l'IA. Régule par niveau de risque (inacceptable, élevé, limité, minimal), indépendamment de la nationalité du fournisseur.
- CLOUD ActUS
- Loi américaine de 2018. Oblige un fournisseur sous juridiction US à livrer, sur mandat judiciaire ciblé, des données en sa possession même stockées hors des USA. Un conflit de lois, pas une interdiction.
- FISA Section 702US
- Base légale de la surveillance ciblée de personnes non-américaines situées hors des USA, pour du renseignement extérieur. Statut expiré en juin 2026, mais surveillance maintenue via les certifications de la FISA Court en cours jusqu'en mars 2027.
- Patriot Act (§ 215)
- Ancienne base de la collecte de masse de métadonnées, expirée le 15 mars 2020 et jamais réautorisée. N'est plus le référentiel pertinent.
- Art. 321 CPSecret pro
- Secret professionnel pénal (Code pénal suisse). Vise avocats, notaires, médecins et leurs auxiliaires. Un fiduciaire n'y figure pas en tant que tel, sauf comme organe de révision.
- FINMA 2018/3
- Circulaire sur l'externalisation des banques et assurances. Autorise le cloud, y compris à l'étranger, sous conditions d'audit et d'accès aux informations.
- ISO/IEC 42001
- Norme internationale de système de management de l'IA (2023). Cadre volontaire de gouvernance ; Anthropic en est certifié.
- Convention 108+ / Convention IA
- Instruments du Conseil de l'Europe. La Convention-cadre sur l'IA a été signée par la Suisse le 26 mars 2025 ; distincte de la Convention 108+ sur la protection des données.
Acteurs & autorités
- Responsable de traitement
- L'entité qui décide des finalités et des moyens d'un traitement. Elle porte la responsabilité de la conformité, même en recourant à un sous-traitant.
- Sous-traitant
- Prestataire qui traite des données pour le compte du responsable, sur ses instructions (ex. un fournisseur cloud ou d'IA). Encadré par un DPA.
- PFPDTSuisse
- Préposé fédéral à la protection des données et à la transparence : l'autorité suisse de contrôle. Équivalent fonctionnel d'une CNIL.
- EDPBUE
- Comité européen de la protection des données. Réunit les autorités nationales de l'UE et publie les lignes directrices de référence (transferts, accès distant…).
- EDPS
- Contrôleur européen de la protection des données. Supervise les institutions de l'UE (≠ entreprises), sous le règlement 2018/1725.
- CNILFrance
- Autorité française de protection des données. Ses guides pratiques (ex. l'analyse de transfert) font référence.
- Commission européenne
- Adopte les décisions d'adéquation (ex. EU-U.S. DPF) qui autorisent les transferts vers un pays tiers.
- CJUE / Tribunal de l'UE
- Cour de justice de l'UE et son Tribunal. La CJUE a invalidé Safe Harbor puis Privacy Shield ; le Tribunal a rejeté le recours Latombe contre le DPF (2025).
- noyb
- ONG fondée par Max Schrems, à l'origine des recours ayant fait tomber Safe Harbor et Privacy Shield.
Types de données
- Données personnelles
- Toute information se rapportant à une personne physique identifiée ou identifiable (nom, e-mail, mais aussi un identifiant indirect).
- Données sensibles
- Catégorie protégée (art. 5 let. c LPD / art. 9 RGPD) : santé, religion, opinions, vie sexuelle, données génétiques et biométriques, origine, poursuites pénales. Régime renforcé.
- Données ordinaires
- Données personnelles non sensibles (nom, e-mail, facture courante). Socle standard, sans les exigences renforcées.
- CIDBanque
- Données identifiant le client d'une banque, couvertes par le secret bancaire (art. 47 LB). Peuvent aller dans le cloud sous cadre FINMA.
Conformité, le socle
- Base légale / motif justificatif
- En RGPD, tout traitement exige une base légale (art. 6). En nLPD, un responsable privé n'a besoin d'un motif justificatif (art. 31) qu'en cas d'atteinte à la personnalité.
- Finalité · proportionnalité · minimisation
- Principes de base : ne traiter que pour un but déterminé, de façon proportionnée, avec le minimum de données nécessaires.
- Privacy by design / by default
- Protection intégrée dès la conception et par des préréglages restrictifs (art. 7 LPD, art. 25 RGPD).
- Registre des traitements
- Inventaire documenté des traitements. En Suisse, les entreprises de moins de 250 employés en sont dispensées, sauf traitement à risque élevé (art. 12 LPD).
- AIPD / DPIAArt. 22 LPD
- Analyse d'impact relative à la protection des données. Obligatoire dès qu'un traitement présente un risque élevé, données sensibles, mais aussi profilage ou scoring à grande échelle.
- DPAArt. 9 LPD
- Contrat de sous-traitance (Data Processing Addendum). Obligatoire dès qu'on confie des données à un prestataire : il encadre instructions, sécurité, sous-traitants ultérieurs.
- Consentement exprès / explicite
- Accord libre et informé. En droit suisse, exprès quand le consentement sert de justification (art. 6 al. 7 LPD) ; le RGPD l'exige explicite pour les données sensibles.
- Décision individuelle automatisée
- Décision fondée exclusivement sur un traitement automatisé à effet juridique ou significatif (art. 21 LPD / art. 22 RGPD). Encadrée : d'où l'intérêt d'une validation humaine.
Transferts internationaux
- Transfert
- Toute communication de données hors de Suisse / de l'EEE. Selon l'EDPB, un simple accès à distance depuis un pays tiers en constitue un.
- Pays adéquat
- État reconnu (par le Conseil fédéral ou la Commission UE) comme offrant une protection suffisante : UE/EEE, UK, Canada… Le transfert s'y fait sans garantie supplémentaire.
- DPFData Privacy Framework
- Mécanisme d'adéquation pour les organisations US certifiées. L'UE (EU-U.S. DPF, 2023) et la Suisse (Swiss-U.S. DPF, dès le 15.09.2024) ont chacune le leur : la certification suisse est distincte.
- Clauses contractuelles typesSCC
- Contrats-types approuvés par l'autorité qui encadrent un transfert à défaut d'adéquation (art. 16 al. 2 LPD / art. 46 RGPD). Filet de sécurité si le DPF venait à tomber.
- BCR
- Règles d'entreprise contraignantes : cadre interne à un groupe multinational, approuvé par l'autorité, autorisant les transferts intragroupe.
- DérogationsArt. 17 LPD
- Transfert possible sans adéquation ni garanties dans des cas ponctuels : consentement exprès, exécution d'un contrat, intérêt public, exercice d'un droit (art. 49 RGPD).
- Mesures supplémentaires
- Protections ajoutées aux clauses types après Schrems II (chiffrement, pseudonymisation, cloisonnement) pour compenser un risque d'accès étranger (EDPB, Recomm. 01/2020).
- TIA / analyse de transfert
- Transfer Impact Assessment : évaluation, avant un transfert, du risque réel d'accès par les autorités du pays destinataire.
- Accès distant
- Consulter à distance, depuis un pays tiers, des données stockées dans l'EEE. L'EDPB le qualifie de transfert (Guidelines 05/2021).
- Personal jurisdiction
- Notion de droit US : un tribunal n'a autorité que sur les entités qui lui sont rattachées. Le CLOUD Act ne l'étend pas à de nouvelles entreprises étrangères.
Jurisprudence & épisodes
- Safe Harbor
- Premier cadre de transfert UE–US (2000), invalidé par la CJUE en 2015.
- Privacy Shield
- Successeur du Safe Harbor (2016), invalidé en 2020 par l'arrêt Schrems II (FISA 702, absence de recours effectif).
- Schrems IIC-311/18
- Arrêt CJUE du 16.07.2020. Invalide le Privacy Shield mais confirme la validité des clauses types.
- Latombe
- Recours d'un député français contre le DPF. Rejeté par le Tribunal de l'UE le 03.09.2025 ; appel formé le 31.10.2025, pendant devant la CJUE.
- Trump v. Slaughter
- Arrêt de la Cour suprême US (29.06.2026) fragilisant l'indépendance de la FTC, sur laquelle repose le DPF. Ravive le débat Schrems.
Technique, IA, hébergement, sécurité
- Souveraineté des données
- Degré de contrôle et d'exposition juridique sur ses données. Pas binaire : un curseur, de l'API publique à l'auto-hébergement.
- Résidence des données
- Localisation géographique du stockage/traitement. Réduit le risque de transfert, mais ne suffit ni à la conformité ni à échapper au CLOUD Act.
- Zero Data RetentionZDR
- Option contractuelle où le fournisseur ne conserve pas la donnée après le traitement. Chez Anthropic, la donnée n'est pas stockée au repos après la réponse de l'API.
- Chiffrement / BYOK
- Bring Your Own Key : le client garde la clé hors de portée du fournisseur. Vraie parade contre un accès, mais inopérant pendant l'inférence, où la donnée doit être en clair.
- Inférence
- Le moment où le modèle traite la donnée pour produire une réponse. La donnée y est nécessairement en clair : la protection est alors contractuelle (ZDR, no-training), pas cryptographique.
- Auto-hébergement / poids ouverts
- Faire tourner un modèle à poids ouverts (ex. Mistral) sur sa propre infrastructure. Souveraineté maximale, coût et effort maximaux.
- API vs grand public
- L'usage pro via API/offre entreprise n'entraîne pas les modèles par défaut ; le compte grand public gratuit, si. Distinction décisive.
- EU Data Boundary
- Engagement de Microsoft de traiter les données personnelles de ses clients dans l'UE/EEE. A pesé dans le revirement de l'autorité de Hesse (2025).
- AWS Bedrock
- Service AWS d'accès à des modèles (dont Claude) en région choisie (ex. Francfort). Le fournisseur du modèle n'a pas accès aux données ; pas d'entraînement dessus.
Tout est vérifiable. C'est ce qui rend cette page citable.
Textes officiels et sources de référence, vérifiés le 3 juillet 2026. Chaque lien résout.
Droit suisse (nLPD)
Droit UE (RGPD) & transferts
- RGPD : Règlement (UE) 2016/679 (EUR-Lex)
- CJUE : Schrems II, C-311/18 (16.07.2020)
- Décision d'adéquation EU-U.S. DPF 2023/1795 (10.07.2023)
- EDPB : Guidelines 05/2021 (accès distant = transfert)
- EDPB : Recommandations 01/2020 (mesures supplémentaires)
- CNIL : guide Transfer Impact Assessment (janvier 2025)
- AI Act : Règlement (UE) 2024/1689 (EUR-Lex)
- Commission européenne : cadre réglementaire de l'IA (AI Act)
Statut du cadre de transfert US
Droit US invoqué comme risque
Fournisseurs & hébergement
Précédents & contre-cas
Aller plus loinArbitrer entre un outil américain et une solution suisse, dossier par dossier, relève d'une direction IA sous mandat.