Tout savoir sur le Cloud Act et le RGPD : enjeux et impacts

Le Cloud Act américain et le RGPD européen sont nés à deux mois d’intervalle en 2018, mais ils obéissent à des logiques radicalement opposées. L’un donne aux autorités judiciaires américaines le droit d’accéder à des données stockées n’importe où dans le monde, dès lors que le prestataire est soumis au droit américain. L’autre impose au responsable de traitement de garantir un niveau de protection élevé à toute donnée personnelle, y compris lorsqu’elle transite ou est hébergée hors de l’Union européenne. Ce n’est pas une simple tension théorique entre deux législations : c’est un conflit opérationnel qui touche chaque organisation utilisant un SaaS américain, chaque DSI ayant migré vers un cloud hyperscaler, chaque DPO qui signe des clauses contractuelles types sans avoir évalué le risque réel. Cet article démonte le mécanisme, cartographie les expositions concrètes et propose un plan d’action structuré.

Cloud Act : définition, périmètre et données concernées

Le Cloud Act — acronyme de Clarifying Lawful Overseas Use of Data Act — a été adopté en mars 2018 par le Congrès américain et signé dans la foulée. Il remplace et complète le Stored Communications Act (SCA) de 1986, texte devenu obsolète face à la réalité du cloud computing. L’élément déclencheur est bien connu : en 2013, un fournisseur américain avait refusé de transmettre au FBI des données stockées sur un serveur situé à Dublin, en Irlande, estimant que le SCA ne lui permettait pas d’agir hors du territoire américain. Le vide juridique était patent. Le Cloud Act est venu le combler.

Le principe central est simple et redoutable : toute entreprise soumise au droit américain — qu’elle soit incorporée aux États-Unis, qu’elle y ait son siège social ou qu’elle y exerce une activité substantielle — peut être contrainte, via un mandat (warrant) ou une injonction d’un juge américain, de fournir des données électroniques qu’elle détient, contrôle ou auxquelles elle peut accéder. La localisation physique des serveurs est sans pertinence. Des données stockées à Francfort, à Amsterdam ou à Paris sont concernées dès lors que le prestataire est une entité américaine ou une filiale contrôlée par un groupe américain.

Le périmètre des données visées est volontairement large. Le Cloud Act reprend la notion de stored wired and electronic communications and transactional records : courriels, fichiers, documents, journaux de connexion, métadonnées de communication, données de compte, contenus de messagerie instantanée. Les communications téléphoniques vocales en temps réel sont explicitement exclues, mais tout le reste — y compris les sauvegardes, les journaux d’audit et les données transactionnelles — entre dans le champ.

Un point souvent négligé concerne les métadonnées. Certaines catégories peuvent être obtenues sans mandat d’un juge, selon des procédures administratives allégées. Cette asymétrie entre contenu et métadonnées est importante : elle signifie que même sans accès au contenu chiffré d’un fichier, les autorités américaines peuvent obtenir des informations sur qui communique avec qui, quand, depuis quelle adresse IP, avec quelle fréquence. Ces métadonnées constituent souvent, en pratique, des données personnelles au sens du RGPD.

Avant le Cloud Act, obtenir des données stockées à l’étranger nécessitait de passer par les mécanismes d’entraide judiciaire internationale (MLAT — Mutual Legal Assistance Treaties), des procédures bilatérales fondées sur des traités, jugées trop lentes par les autorités américaines. Le Cloud Act court-circuite ce mécanisme, ce qui est précisément l’une des sources du conflit avec le droit européen.

Il est également utile de situer le Cloud Act par rapport au Patriot Act de 2001, adopté après les attentats du 11 septembre. Ce dernier avait considérablement élargi les pouvoirs de surveillance des autorités américaines, mais restait principalement centré sur les données circulant ou stockées sur le territoire américain. Le Cloud Act va plus loin en assumant explicitement l’extraterritorialité : c’est cette dimension qui le rend structurellement incompatible avec la logique du RGPD.

Cette architecture juridique pose une question immédiate pour tout responsable de traitement européen : utiliser un service cloud ou SaaS opéré par une entité soumise au droit américain revient-il à accepter implicitement qu’une autorité étrangère puisse accéder aux données traitées ? La réponse du RGPD à cette question est sans ambiguïté.

Pourquoi le Cloud Act entre en conflit avec le RGPD

La collision entre les deux textes n’est pas accidentelle. Elle tient à une divergence fondamentale de philosophie : le Cloud Act est un instrument de souveraineté américaine qui s’exerce sur ses opérateurs où qu’ils se trouvent ; le RGPD est un instrument de protection des personnes physiques qui s’applique à tout traitement de données les concernant, quel que soit le lieu d’hébergement. Ces deux logiques d’extraterritorialité se heurtent de plein fouet.

L’article le plus directement concerné est l’article 48 du RGPD. Il dispose qu’une décision d’une juridiction ou d’une autorité administrative d’un pays tiers exigeant un transfert ou une divulgation de données personnelles ne peut être reconnue ou rendue exécutoire que si elle est fondée sur un accord international en vigueur entre ce pays tiers et l’Union européenne ou un État membre — typiquement un traité d’entraide judiciaire (MLAT). Or le Cloud Act n’est pas un accord international au sens du droit européen. Un prestataire qui répondrait directement à une injonction fondée sur le Cloud Act en transmettant des données personnelles de ressortissants européens violerait donc l’article 48 du RGPD.

Le problème ne s’arrête pas là. Le RGPD impose au responsable de traitement de s’assurer que tout transfert de données vers un pays tiers repose sur une base légale adéquate : décision d’adéquation, clauses contractuelles types (CCT/SCC), règles d’entreprise contraignantes ou autre garantie appropriée (articles 44 et suivants). La décision d’adéquation concernant les États-Unis — le Privacy Shield — a été invalidée par la Cour de justice de l’UE dans l’arrêt Schrems II de juillet 2020, précisément parce que le droit américain (incluant les mécanismes de surveillance) ne garantissait pas un niveau de protection essentiellement équivalent à celui de l’UE. Son successeur, le Data Privacy Framework (DPF), adopté en 2023, est actuellement en vigueur mais fait déjà l’objet de recours et de remises en question, notamment au regard de la persistance du Cloud Act.

La tension se manifeste aussi sur le terrain de la transparence et de la notification. Le RGPD exige que les personnes concernées soient informées des traitements effectués sur leurs données et, en cas de violation ou d’accès non autorisé, que le responsable de traitement en soit notifié. Or les injonctions émises dans le cadre du Cloud Act s’accompagnent fréquemment d’ordres de confidentialité (gag orders) : le prestataire ne peut pas informer son client de la demande reçue. Le responsable de traitement se retrouve donc dans l’impossibilité d’exercer ses droits et obligations au titre du RGPD.

Sur le plan de la minimisation des données et du contrôle des accès, le Cloud Act ouvre un droit d’accès potentiellement large à des données que le responsable de traitement a précisément cherché à protéger. L’accès par une autorité étrangère sans base légale reconnue par le droit européen constitue une divulgation non autorisée, susceptible de qualifier une violation de données au sens de l’article 4(12) du RGPD, avec les obligations de notification qui en découlent (article 33 : notification à l’autorité de contrôle dans les 72 heures ; article 34 : notification aux personnes concernées si risque élevé).

Le contexte post-Schrems II a renforcé les obligations pesant sur les responsables de traitement et leurs sous-traitants. Le Comité européen de la protection des données (CEPD) a publié des recommandations imposant une évaluation systématique du niveau de protection du pays destinataire avant tout transfert, et l’adoption de mesures supplémentaires (TOM — mesures techniques et organisationnelles) lorsque ce niveau est insuffisant. La simple signature de CCT/SCC ne suffit plus : encore faut-il démontrer qu’elles sont effectivement efficaces dans le contexte juridique du pays tiers concerné.

Ces exigences posent une question pratique immédiate : dans quelles situations concrètes une organisation européenne est-elle réellement exposée ? La réponse est plus large qu’on ne le croit généralement.

Scénarios d’exposition en entreprise : où se situe le risque réel

L’exposition au Cloud Act ne se limite pas aux entreprises qui hébergent délibérément leurs données aux États-Unis. Elle touche une gamme bien plus large de situations, souvent invisibles dans les cartographies de risque habituelles.

Le SaaS américain en mode standard est le cas le plus évident. Une organisation qui utilise une suite collaborative, un CRM, un outil de gestion RH ou une plateforme de marketing automation opérée par une entreprise américaine — même si les serveurs sont physiquement en Europe — confie ses données à un prestataire soumis au droit américain. Microsoft, Google, Salesforce, ServiceNow, Workday : la liste des éditeurs concernés couvre une part considérable du parc applicatif des entreprises européennes. Les données traitées dans ces environnements — données clients, données salariés, données financières — sont potentiellement accessibles via une injonction Cloud Act.

Le cloud « européen » d’un groupe américain constitue un deuxième scénario, plus subtil. Un hébergement sur une région AWS Europe (Francfort, Paris, Dublin) ou Azure Europe ne change rien à l’analyse juridique : AWS est une filiale d’Amazon.com Inc., entité américaine. L’injonction s’adresse à la maison mère, qui contrôle la filiale. La localisation des serveurs est un argument commercial, pas une protection juridique.

La sous-traitance en chaîne est un troisième vecteur d’exposition fréquemment sous-estimé. Un responsable de traitement européen peut avoir sélectionné un prestataire européen, lui-même sous-traitant à un prestataire américain pour certaines fonctions (infrastructure, sauvegarde, CDN, support). L’article 28 du RGPD impose que le sous-traitant n’engage un sous-traitant ultérieur qu’avec l’autorisation du responsable de traitement, et que les mêmes obligations de protection s’appliquent. Mais en pratique, la chaîne de sous-traitance est rarement auditée jusqu’au bout.

• Support et maintenance à distance : les équipes de support basées aux États-Unis peuvent accéder à des environnements de production européens. Cet accès constitue un transfert de données au sens du RGPD, même s’il est ponctuel.
• Sauvegardes et réplication : les données de sauvegarde sont souvent répliquées dans des régions ou des systèmes différents, parfois opérés par des entités distinctes soumises au droit américain.
• Journaux et logs : les journaux d’audit, d’accès et d’erreur contiennent fréquemment des données personnelles (identifiants, adresses IP, horodatages d’actions). Ils sont souvent agrégés dans des outils SIEM ou d’observabilité opérés par des acteurs américains.
• Messageries d’entreprise : les communications internes et externes transitant par des outils comme Microsoft Teams, Slack ou Google Workspace sont des données électroniques stockées au sens du Cloud Act.
• Données non personnelles mais sensibles : secrets industriels, données financières non nominatives, propriété intellectuelle. Le Cloud Act ne se limite pas aux données personnelles au sens du RGPD ; il vise toutes les communications et données électroniques stockées. Une organisation peut donc être exposée sur des données hors champ RGPD mais stratégiquement critiques.

La filiale européenne d’un groupe américain mérite une attention particulière. Elle est soumise au RGPD pour ses traitements en Europe, mais sa maison mère américaine peut recevoir une injonction Cloud Act portant sur des données que la filiale détient ou contrôle. La filiale se retrouve alors dans une position d’injonction contradictoire : obéir à la maison mère exposerait à une violation du RGPD ; refuser exposerait le groupe à des sanctions américaines.

L’e-discovery constitue un cas d’usage spécifique et souvent méconnu. Dans le cadre de litiges américains, les parties sont tenues de produire des preuves électroniques (evidence électronique). Les outils d’e-discovery utilisés dans ce contexte sont fréquemment opérés par des prestataires américains et peuvent aspirer des volumes considérables de données, y compris des données personnelles de ressortissants européens, sans que les procédures RGPD habituelles soient respectées.

Cette cartographie des risques appelle une question naturelle : que faut-il exactement faire pour rester conforme au RGPD lorsque des transferts transfrontières sont inévitables ?

Transferts et accès transfrontières : ce que le RGPD exige en pratique

Le RGPD encadre les transferts de données vers des pays tiers à travers un régime spécifique (chapitre V, articles 44 à 49). Ce régime repose sur une logique de continuité de la protection : les données personnelles de ressortissants européens doivent bénéficier d’un niveau de protection essentiellement équivalent, quel que soit l’endroit où elles sont traitées.

La première étape est la qualification des acteurs. Qui est le responsable de traitement ? Qui est le sous-traitant ? Qui est le sous-traitant ultérieur ? Cette cartographie est indispensable, car les obligations diffèrent selon le rôle. Un responsable de traitement qui confie des données à un prestataire américain reste responsable du respect du RGPD vis-à-vis des personnes concernées. Il ne peut pas déléguer cette responsabilité contractuellement.

La deuxième étape est l’identification de la base légale du transfert. Les options disponibles sont :

• Décision d’adéquation : la Commission européenne reconnaît que le pays tiers offre un niveau de protection adéquat. Pour les États-Unis, le Data Privacy Framework (DPF) est actuellement en vigueur, mais uniquement pour les entreprises américaines qui y ont adhéré. Il ne couvre pas l’ensemble des prestataires américains et reste fragile juridiquement.
• Clauses contractuelles types (CCT/SCC) : des clauses standardisées adoptées par la Commission européenne, intégrées dans les contrats avec le prestataire. Elles sont nécessaires mais insuffisantes seules depuis Schrems II.
• Règles d’entreprise contraignantes (BCR) : pour les transferts intra-groupe, approuvées par une autorité de contrôle.
• Dérogations de l’article 49 : consentement explicite de la personne concernée, nécessité contractuelle, intérêt public — des dérogations strictement encadrées et non utilisables comme base habituelle.

La troisième étape, rendue obligatoire par la jurisprudence Schrems II et les recommandations du CEPD, est l’évaluation du niveau de protection du pays destinataire (Transfer Impact Assessment — TIA). Cette évaluation doit analyser le droit et les pratiques du pays tiers susceptibles d’affecter l’efficacité des garanties mises en place. Pour les États-Unis, cette évaluation doit explicitement prendre en compte le Cloud Act, le FISA (Foreign Intelligence Surveillance Act) et les autres mécanismes de surveillance. Si l’évaluation conclut que les garanties contractuelles ne sont pas effectivement respectées dans le pays tiers, des mesures supplémentaires doivent être mises en œuvre.

La quatrième étape est la documentation et l’accountability. Le responsable de traitement doit être en mesure de démontrer, à tout moment, que ses transferts reposent sur une base légale valide, que les risques ont été évalués et que des mesures adéquates ont été prises. Cette démonstration passe par le registre des activités de traitement (article 30), les analyses d’impact (AIPD/DPIA) pour les traitements à risque élevé, et la documentation des TIA.

Un contrat seul ne suffit pas à résoudre le conflit, pour une raison simple : le Cloud Act est une loi fédérale américaine qui prévaut sur les engagements contractuels d’un prestataire. Si un juge américain émet une injonction, le prestataire américain ne peut pas s’y soustraire en invoquant ses obligations contractuelles envers son client européen. Les CCT/SCC créent des obligations entre les parties, mais elles ne lient pas les autorités judiciaires américaines. C’est pourquoi les mesures techniques — et notamment le chiffrement avec gestion des clés hors du prestataire — sont indispensables pour rendre les données effectivement inaccessibles, même en cas d’injonction.

Cette réalité conduit directement à la question des mesures concrètes qu’une organisation peut mettre en œuvre pour réduire son exposition.

Mesures techniques et organisationnelles pour réduire l’impact du Cloud Act

La recommandation du CEPD sur les mesures supplémentaires (adoptée en 2021) distingue les mesures techniques, contractuelles et organisationnelles. Face au Cloud Act, les mesures techniques sont les plus déterminantes, car elles seules peuvent rendre les données factuellement inaccessibles à un tiers, y compris au prestataire lui-même.

Le chiffrement est la première ligne de défense, mais sa portée dépend entièrement de qui détient les clés. Un chiffrement géré par le prestataire américain (scénario par défaut dans la plupart des offres cloud) n’offre aucune protection face au Cloud Act : le prestataire peut déchiffrer les données à la demande des autorités. Pour que le chiffrement soit une mesure supplémentaire efficace, les clés de chiffrement doivent être détenues et contrôlées par le responsable de traitement ou par un tiers de confiance situé hors de portée du droit américain.

Trois modèles de gestion des clés méritent d’être distingués :

• BYOK (Bring Your Own Key) : le client génère ses propres clés et les importe dans le système de gestion des clés du prestataire. Le prestataire a techniquement accès aux clés. Ce modèle améliore le contrôle opérationnel mais ne protège pas contre une injonction Cloud Act adressée au prestataire.
• HYOK (Hold Your Own Key) : les clés sont stockées dans un système entièrement contrôlé par le client, hors de l’infrastructure du prestataire. Le prestataire ne peut pas déchiffrer les données sans l’accord du client. C’est le modèle le plus protecteur face au Cloud Act, à condition que le système de gestion des clés soit lui-même hors de portée du droit américain.
• HSM (Hardware Security Module) : dispositif matériel dédié à la génération, au stockage et à la gestion sécurisée des clés cryptographiques. Utilisé en combinaison avec HYOK, un HSM opéré sur site ou chez un prestataire européen indépendant constitue la mesure technique la plus robuste disponible.

Au-delà du chiffrement, plusieurs autres mesures techniques contribuent à réduire l’exposition :

• Pseudonymisation et minimisation : réduire la quantité de données personnelles directement identifiantes stockées dans les environnements cloud. Une donnée pseudonymisée dont la clé de correspondance est conservée on-premise est moins exposée.
• Segmentation des données : ne pas concentrer toutes les données sensibles dans un seul environnement cloud. Séparer les données selon leur niveau de sensibilité et adapter le prestataire en conséquence.
• Journaux d’audit et traçabilité : maintenir des journaux des accès aux données, y compris les accès du prestataire, pour détecter tout accès anormal ou non sollicité.
• Politiques d’accès strictes : principe du moindre privilège, authentification forte (MFA), revue régulière des droits d’accès des équipes du prestataire, notamment pour le support à distance.
• Chiffrement en transit : TLS 1.3 minimum pour toutes les communications, avec vérification des certificats et protection contre les attaques de type man-in-the-middle.

Sur le plan organisationnel, une procédure de réponse aux demandes d’accès doit être formalisée. Elle doit prévoir : comment le prestataire doit informer le client (dans la limite de ce que la loi américaine lui permet), quel délai de réponse est attendu, comment le responsable de traitement peut contester une injonction, et qui est le point de contact interne (DPO, direction juridique, RSSI). Cette procédure doit être testée, pas seulement rédigée.

Le contrôle des sous-traitants est une dimension organisationnelle critique. L’article 28 du RGPD impose des obligations précises : contrat de sous-traitance, liste des sous-traitants ultérieurs, droit d’audit. En pratique, il faut aller plus loin : exiger que le prestataire notifie tout changement de sous-traitant, auditer régulièrement la chaîne de sous-traitance, et vérifier que les mesures techniques s’appliquent à tous les maillons de la chaîne.

Enfin, l’analyse d’impact (AIPD/DPIA) est obligatoire pour les traitements présentant un risque élevé pour les droits et libertés des personnes. L’utilisation d’un prestataire soumis au Cloud Act pour traiter des données sensibles (données de santé, données financières, données relatives à des infractions) devrait systématiquement déclencher une DPIA, qui documentera les risques identifiés et les mesures prises pour les atténuer.

Ces mesures techniques et organisationnelles sont nécessaires, mais leur efficacité dépend aussi de la qualité de la relation contractuelle avec les prestataires. C’est l’objet de la section suivante.

Choisir et encadrer ses prestataires : clauses, audits et critères de souveraineté

La sélection d’un prestataire cloud ou SaaS ne peut plus se limiter à des critères de performance, de prix et de fonctionnalités. La juridiction de contrôle du prestataire, sa transparence vis-à-vis des demandes d’accès des autorités et ses modalités de support sont des critères de risque à part entière.

Une grille d’évaluation structurée doit couvrir les dimensions suivantes :

• Juridiction de contrôle : le prestataire est-il soumis au droit américain (incorporation, siège, activité substantielle aux États-Unis) ? Est-il une filiale d’un groupe américain ? La réponse détermine l’applicabilité du Cloud Act.
• Transparence sur les demandes d’accès : le prestataire publie-t-il un rapport de transparence (transparency report) indiquant le nombre et le type de demandes reçues des autorités ? Peut-il notifier son client en cas de demande, dans la limite de ce que la loi lui permet ?
• Localisation des données et des équipes de support : où sont physiquement les serveurs ? Où sont situées les équipes ayant accès aux environnements de production ? Un support basé aux États-Unis constitue un vecteur d’accès potentiel.
• Modèle de gestion des clés : le prestataire propose-t-il BYOK ou HYOK ? Avec quel niveau de contrôle effectif pour le client ?
• Droit applicable au contrat et juridiction compétente : un contrat soumis au droit irlandais ou français avec clause de compétence des juridictions européennes offre une meilleure base pour contester une injonction qu’un contrat soumis au droit de l’État de Californie.
• Procédure de contestation des injonctions : le prestataire s’engage-t-il contractuellement à contester toute injonction qu’il estime disproportionnée ou contraire au droit européen, avant de s’y conformer ?
• Liste et localisation des sous-traitants : le prestataire divulgue-t-il la liste complète de ses sous-traitants, avec leur juridiction ? Notifie-t-il les changements avec un préavis suffisant ?
• Réversibilité et portabilité : en cas de résiliation, le client peut-il récupérer l’intégralité de ses données dans un format standard, dans un délai raisonnable ?
• Droit d’audit : le contrat prévoit-il un droit d’audit effectif, ou seulement une référence à des certifications tierces (ISO 27001, SOC 2) sans droit d’accès direct ?

Sur le plan contractuel, plusieurs clauses spécifiques doivent être négociées ou vérifiées dans les CCT/SCC :

• Obligation de notification du client en cas de demande d’accès des autorités, dans les meilleurs délais et dans la limite de ce que la loi autorise.
• Engagement à contester les demandes jugées trop larges ou non conformes au droit européen.
• Interdiction de transfert des données à des tiers sans accord préalable du responsable de traitement.
• Obligation de coopération en cas de violation de données, incluant les accès non autorisés par des autorités étrangères.
• Clauses de résiliation facilitée en cas de modification substantielle du cadre juridique applicable au prestataire.

Pour les données particulièrement sensibles — données de santé, données financières, données relevant du secret des affaires, données relatives à des infrastructures critiques — des exigences supplémentaires s’imposent. Le label SecNumCloud de l’ANSSI, en France, identifie des prestataires cloud qualifiés offrant des garanties de souveraineté renforcées, notamment l’immunité aux lois extraterritoriales. Des offres de cloud de confiance (comme celles développées en partenariat avec des opérateurs européens sous licence de technologie américaine) tentent de répondre à cette problématique, mais leur niveau de protection effectif face au Cloud Act fait l’objet de débats : la licence de technologie crée-t-elle une dépendance suffisante pour que le donneur de licence américain soit considéré comme soumis au Cloud Act ? La question reste ouverte.

Ces critères de sélection et ces exigences contractuelles s’inscrivent dans un cadre réglementaire qui évolue rapidement, avec des positions institutionnelles de plus en plus précises de la part des autorités européennes et françaises.

Cadre France et UE : position de la CNIL, ressources et textes de référence

La CNIL s’est positionnée clairement sur la question des transferts de données vers des pays tiers et sur les risques liés aux législations extraterritoriales comme le Cloud Act. Ses recommandations sur le cloud, publiées et régulièrement mises à jour, insistent sur la nécessité pour les responsables de traitement d’évaluer concrètement le risque d’accès par des autorités étrangères, et pas seulement de signer des CCT/SCC.

La CNIL rappelle notamment que la recommandation à adopter face à une demande directe d’accès fondée sur le Cloud Act est de refuser le transfert direct et de renvoyer l’autorité requérante vers les mécanismes d’entraide judiciaire internationale (MLAT). Si un traité d’entraide existe entre les États-Unis et la France ou l’UE, c’est par cette voie que la demande doit transiter, afin que les juridictions européennes puissent en contrôler la légalité et la proportionnalité. Cette position est cohérente avec l’article 48 du RGPD.

Le Comité européen de la protection des données (CEPD) a publié plusieurs textes de référence essentiels :

• Les recommandations 01/2020 sur les mesures supplémentaires complétant les instruments de transfert, qui détaillent les critères d’évaluation du niveau de protection d’un pays tiers et les mesures techniques, contractuelles et organisationnelles pouvant être mises en œuvre.
• Les recommandations 02/2020 sur les garanties essentielles européennes, qui définissent les critères permettant d’évaluer si les lois de surveillance d’un pays tiers sont compatibles avec les droits fondamentaux européens.
• Les nouvelles CCT/SCC adoptées en 2021, qui intègrent des obligations renforcées en matière d’évaluation du niveau de protection et de notification en cas de demande d’accès des autorités.

Le texte du Cloud Act est disponible en version officielle sur le site du Congrès américain (congress.gov), sous la référence Public Law 115-141. Des versions consolidées et des analyses sont accessibles via les sites des autorités de protection des données européennes et via les publications officielles du Département de justice américain (DOJ), qui a publié des guides d’interprétation du texte.

Au niveau européen, deux textes législatifs récents renforcent les exigences de maîtrise des flux de données et des prestataires cloud :

• Le Data Act européen, qui encadre le partage des données générées par les objets connectés et les services numériques, et introduit des dispositions spécifiques sur les transferts de données non personnelles vers des pays tiers, notamment pour éviter l’accès par des autorités étrangères en dehors des voies légales reconnues.
• La directive NIS2, qui renforce les exigences de cybersécurité pour les entités essentielles et importantes, incluant des obligations de maîtrise des risques liés aux prestataires et sous-traitants.

En France, l’ANSSI joue un rôle complémentaire à la CNIL sur les aspects de sécurité et de souveraineté numérique. Son référentiel SecNumCloud et sa doctrine sur le cloud de confiance constituent des ressources opérationnelles pour les organisations souhaitant aller au-delà de la conformité RGPD stricto sensu et réduire leur dépendance aux acteurs soumis au droit américain.

Pour les organisations qui souhaitent approfondir le sujet, les ressources officielles à consulter en priorité sont : le site de la CNIL (cnil.fr, section transferts internationaux), le site du CEPD (edpb.europa.eu), le texte du Cloud Act sur congress.gov, et les publications du DOJ américain sur l’application du Cloud Act, qui précisent les procédures et les garanties procédurales prévues par le texte.

FAQ

Qu’est-ce que le Cloud Act et à qui s’applique-t-il ?

Le Cloud Act (Clarifying Lawful Overseas Use of Data Act) est une loi fédérale américaine adoptée en mars 2018. Il autorise les autorités judiciaires américaines à exiger, via un mandat ou une injonction, l’accès à des données électroniques détenues par tout prestataire soumis au droit américain, quelle que soit la localisation physique des serveurs. Il s’applique donc aux entreprises américaines et à leurs filiales, y compris lorsqu’elles hébergent des données en Europe.

Pourquoi le Cloud Act est-il considéré comme contraire au RGPD ?

Le Cloud Act n’est pas un accord international reconnu par l’UE. Or l’article 48 du RGPD interdit de répondre à une injonction étrangère d’accès aux données en dehors des voies d’entraide judiciaire internationale. Un transfert de données vers les États-Unis fondé directement sur le Cloud Act viole donc le RGPD. De plus, les ordres de confidentialité accompagnant les injonctions empêchent le prestataire d’informer son client, rendant impossible le respect des obligations de transparence et de notification du RGPD.

Comment se protéger du Cloud Act tout en restant conforme au RGPD ?

La protection repose sur une combinaison de mesures : chiffrement des données avec gestion des clés hors du prestataire (HYOK/HSM), minimisation et pseudonymisation, segmentation des données sensibles, CCT/SCC accompagnées d’une évaluation d’impact sur le transfert (TIA), procédure formalisée de réponse aux demandes d’accès, et sélection de prestataires offrant des garanties de transparence et de contestation des injonctions. Pour les données les plus sensibles, le recours à des prestataires qualifiés SecNumCloud ou à des solutions on-premise peut s’avérer nécessaire.

Où trouver le texte du Cloud Act (PDF) et les ressources officielles ?

Le texte officiel du Cloud Act est disponible sur le site du Congrès américain (congress.gov, Public Law 115-141). Les ressources européennes de référence sont disponibles sur le site du CEPD (edpb.europa.eu) — notamment les recommandations sur les mesures supplémentaires et les CCT/SCC — et sur le site de la CNIL (cnil.fr, section transferts internationaux). L’ANSSI publie également des ressources sur le cloud de confiance et le référentiel SecNumCloud.

Le conflit entre le Cloud Act et le RGPD n’est pas près de se résoudre par voie diplomatique. Les organisations qui attendent une solution institutionnelle avant d’agir prennent un risque opérationnel et juridique réel. La cartographie des prestataires soumis au droit américain, l’évaluation honnête des transferts en cours et la mise en œuvre de mesures techniques effectives — à commencer par la gestion des clés de chiffrement — sont des actions que chaque responsable de traitement peut engager dès maintenant, sans attendre que la tension géopolitique se dissipe.