Le CLOUD Act : tout ce qu’il faut savoir

Le CLOUD Act inquiète les directions juridiques et les DSI européens depuis son adoption en 2018, souvent pour de bonnes raisons mais parfois sur la base d’amalgames qui brouillent l’analyse. Comprendre ce que cette loi permet réellement — à qui elle s’applique, quelles données elle vise, et en quoi elle frictionne avec le RGPD — est la condition préalable à toute décision rationnelle sur l’architecture cloud et la gouvernance des données. Ni le rejet dogmatique du cloud américain ni l’indifférence ne constituent une réponse satisfaisante : ce qu’il faut, c’est une grille de lecture opérationnelle.

Le cloud en bref : modèles et enjeux de sécurité

Avant d’aborder le CLOUD Act, il faut poser un vocabulaire commun. Le terme « cloud » recouvre des réalités très différentes, et la confusion entre modèles de déploiement est l’une des sources les plus fréquentes d’erreurs d’appréciation juridique et technique.

On distingue trois grands types de cloud, souvent schématisés ainsi :

• Le cloud public : les ressources informatiques (calcul, stockage, réseau) sont mutualisées entre plusieurs clients et exploitées par un fournisseur tiers. AWS, Microsoft Azure, Google Cloud Platform en sont les exemples les plus répandus. Le client n’a aucune maîtrise sur l’infrastructure physique.
• Le cloud privé : l’infrastructure est dédiée à une seule organisation, qu’elle soit hébergée dans ses propres locaux (on-premise) ou chez un prestataire. La maîtrise technique est plus grande, mais les coûts et la complexité opérationnelle aussi.
• Le cloud hybride : combinaison des deux précédents, permettant de faire circuler des données et des charges de travail entre un environnement privé et un ou plusieurs clouds publics selon des règles définies. C’est l’architecture dominante dans les grandes entreprises européennes.

À ces modèles de déploiement s’ajoutent les modèles de service — IaaS (infrastructure), PaaS (plateforme), SaaS (logiciel) — qui déterminent la répartition des responsabilités entre le fournisseur et le client, notion centrale dans le RGPD (responsable de traitement vs sous-traitant).

Sur le plan de la sécurité, trois principes fondamentaux structurent toute politique de protection des données, souvent résumés par le triptyque CIA :

• Confidentialité : seules les personnes ou systèmes autorisés accèdent aux données. Le chiffrement en est l’outil technique principal.
• Intégrité : les données ne sont ni altérées ni corrompues de manière non détectée, que ce soit par accident ou par malveillance.
• Disponibilité : les données et les systèmes sont accessibles lorsque les utilisateurs légitimes en ont besoin, ce qui implique redondance, sauvegardes et plans de continuité.

Ces trois principes ne sont pas abstraits : ils conditionnent directement les choix d’architecture cloud. Un accès forcé à des données chiffrées par une autorité étrangère attaque la confidentialité. Une injonction de gel ou de suppression de données menace la disponibilité et l’intégrité. Comprendre ces mécanismes permet d’évaluer ce que le CLOUD Act change — ou ne change pas — dans l’équation de sécurité d’une organisation.

C’est précisément ce que la section suivante examine : l’origine, la logique et les objectifs de cette loi américaine qui a redéfini les règles du jeu pour les fournisseurs de services cloud.

CLOUD Act : définition, origine et objectifs

Le Clarifying Lawful Overseas Use of Data Act, plus connu sous l’acronyme CLOUD Act, est une loi fédérale américaine adoptée le 23 mars 2018 par le Congrès des États-Unis (référence législative : H.R. 4943). Son adoption a été discrète — elle a été intégrée dans un projet de loi budgétaire — mais ses implications sont considérables pour toute organisation utilisant des services cloud fournis par des acteurs soumis au droit américain.

Pour comprendre pourquoi cette loi a été créée, il faut remonter à 1986 et au Stored Communications Act (SCA), le texte que le CLOUD Act modifie principalement. Le SCA encadrait l’accès des autorités américaines aux communications électroniques stockées, mais il avait été conçu avant l’essor du cloud computing mondial. Ses dispositions ne répondaient pas clairement à la question : un mandat américain peut-il contraindre un fournisseur américain à remettre des données stockées sur des serveurs situés hors des États-Unis ?

Cette ambiguïté a été mise en lumière par l’affaire dite « Microsoft Ireland », un litige engagé depuis 2013 dans lequel le gouvernement américain cherchait à obtenir des données stockées par Microsoft sur des serveurs localisés en Irlande. Microsoft avait refusé, arguant que le mandat américain ne pouvait s’appliquer à des données stockées en dehors du territoire national. L’affaire est remontée jusqu’à la Cour suprême des États-Unis, créant une incertitude juridique majeure pour les agences fédérales et les fournisseurs de services.

Parallèlement, des agences fédérales américaines signalaient des difficultés croissantes à obtenir des données à distance via des fournisseurs, du fait des limites de portée des mandats sous le SCA. Le cadre existant, fondé sur les accords d’entraide judiciaire internationale (MLAT), était jugé trop lent et trop lourd pour les besoins opérationnels du law enforcement.

Le CLOUD Act répond à ces deux problèmes avec une logique simple : l’obligation de remise des données suit le fournisseur, pas les serveurs. Un prestataire soumis au droit américain doit remettre les données demandées par une autorité judiciaire américaine compétente, même si ces données sont physiquement stockées à Dublin, Francfort ou Paris.

La loi poursuit également un objectif de coopération internationale : elle prévoit la possibilité de conclure des executive agreements (accords exécutifs bilatéraux) entre les États-Unis et d’autres pays, permettant des demandes directes auprès des fournisseurs de services et un accès réciproque aux données, y compris celles stockées sur le territoire américain.

Ces objectifs — clarifier la portée extraterritoriale des mandats américains et moderniser la coopération judiciaire internationale — définissent le périmètre réel du CLOUD Act. Ce périmètre est plus précis qu’il n’y paraît dans les débats publics, comme le montre l’analyse détaillée de son champ d’application.

À qui et à quoi s’applique le CLOUD Act : champ d’application réel

La question la plus fréquemment mal posée est : « Mes données sont-elles soumises au CLOUD Act parce qu’elles sont hébergées aux États-Unis ? » La bonne question est : « Mon fournisseur de services est-il soumis au droit américain ? » La distinction est fondamentale.

Les acteurs visés sont les prestataires de services de communication électronique, de traitement ou de stockage électronique, de cloud computing ou de services informatiques à distance, dès lors que leur activité est régie par le droit américain. Concrètement, cela inclut :

• Les grands hyperscalers américains (AWS, Microsoft Azure, Google Cloud, Oracle Cloud, etc.) dont le siège social est aux États-Unis ;
• Toute entreprise étrangère possédant une filiale aux États-Unis, si cette filiale a le contrôle ou la possession des données en question ;
• Tout fournisseur opérant sur le marché américain de manière suffisamment substantielle pour être considéré comme soumis à la juridiction américaine.

Ce dernier point est crucial et souvent sous-estimé : une entreprise non établie aux États-Unis peut être soumise au CLOUD Act si elle y possède une filiale ou si elle y exerce une activité significative. Un éditeur SaaS européen qui a constitué une entité juridique américaine pour commercialiser ses services outre-Atlantique entre potentiellement dans ce périmètre.

Le critère déterminant est celui du contrôle ou de la possession (control or possession) des données, et non leur localisation physique. Si un fournisseur américain peut techniquement accéder aux données stockées sur ses serveurs irlandais ou français, il est tenu de les fournir sur demande judiciaire valide.

Les données visées sont les communications électroniques et les informations stockées dans le cadre de la fourniture de services de communication ou de stockage. Cela couvre en pratique :

• Les e-mails, messageries instantanées, fichiers stockés dans des espaces collaboratifs ;
• Les métadonnées associées (horodatage, identifiants, adresses IP) ;
• Les données applicatives hébergées sur des plateformes cloud (bases de données, documents, sauvegardes).

La procédure n’est pas un accès libre et unilatéral. Les autorités américaines — fédérales, mais aussi locales y compris municipales — ne peuvent contraindre un prestataire à fournir des données qu’en vertu d’un mandat (warrant), d’une injonction ou d’une assignation (subpoena) délivrés par une juridiction américaine compétente. C’est une limite procédurale réelle, même si elle reste entièrement dans le cadre du droit américain, sans contrôle préalable par une autorité du pays où les données sont hébergées.

La loi prévoit également un mécanisme de contestation : un fournisseur peut déposer une requête pour modifier ou annuler une demande s’il estime que le client concerné n’est pas une « US person » (citoyen ou résident américain) et que la divulgation créerait un risque de violation du droit du pays où les données sont stockées. Mais ce mécanisme est facultatif, et son activation dépend de la volonté et de la capacité du fournisseur à l’exercer.

Dernier point souvent ignoré : la loi peut permettre l’obtention de communications personnelles sans que l’individu concerné en soit informé, et sans que son pays de résidence ou le pays de stockage des données ne soit notifié. Cette absence de notification constitue l’un des points de friction les plus sérieux avec le droit européen, que la section suivante examine sous l’angle des risques concrets pour les entreprises.

Risques concrets pour les entreprises en France et en Europe

Traduire un mécanisme légal en risques opérationnels est l’exercice que beaucoup d’analyses sur le CLOUD Act négligent. Voici une cartographie structurée des expositions réelles pour une organisation française ou européenne utilisant des services cloud fournis par des acteurs soumis au droit américain.

Risque de confidentialité et de secret des affaires : une data request formulée dans le cadre d’une enquête américaine peut porter sur des données commerciales sensibles — contrats, correspondances avec des clients, données financières, propriété intellectuelle. Le destinataire de la demande est le fournisseur, pas l’entreprise cliente. Celle-ci peut ne jamais en être informée, et n’a aucun droit de regard sur la procédure américaine. La loi française n°68-678 du 26 juillet 1968, dite « loi de blocage », interdit en principe la communication à des autorités étrangères de documents d’ordre économique, commercial, industriel, financier ou technique, mais son efficacité comme bouclier contre une injonction américaine adressée directement au fournisseur est limitée.

Risque de conformité RGPD : si les données visées incluent des données personnelles de citoyens européens, leur transmission aux autorités américaines sans base légale reconnue par le RGPD constitue un transfert de données vers un pays tiers non couvert par une décision d’adéquation ou des garanties appropriées. La CNIL et ses homologues européens pourraient considérer que le responsable de traitement a manqué à ses obligations, même si c’est le sous-traitant (le fournisseur cloud) qui a effectué la divulgation.

Risque de gouvernance des sous-traitants : dans la chaîne de sous-traitance cloud, le responsable de traitement est souvent une entreprise française ou européenne, tandis que le sous-traitant est un hyperscaler américain. Le RGPD impose au responsable de traitement de s’assurer que ses sous-traitants offrent des garanties suffisantes. Si le sous-traitant est légalement contraint de divulguer des données à une autorité étrangère, la question de la responsabilité remonte vers le responsable de traitement.

Risque de continuité et de disponibilité : une injonction peut théoriquement contraindre un fournisseur à geler ou à préserver des données, ce qui peut affecter la disponibilité des services pour l’organisation cliente. Ce scénario reste rare dans la pratique courante des entreprises non impliquées dans des enquêtes, mais il est réel pour des acteurs opérant dans des secteurs sensibles (défense, énergie, finance).

Risque réputationnel : la révélation qu’une organisation a vu ses données transmises à des autorités américaines — même dans un cadre légal — peut nuire à sa réputation auprès de ses clients, partenaires et régulateurs européens, indépendamment de toute faute de sa part.

Ces risques ne sont pas uniformément distribués. Ils dépendent du type de données hébergées, du fournisseur choisi, de l’architecture déployée et des mesures de sécurité en place. C’est précisément la tension avec le RGPD qui structure la réponse réglementaire européenne à ces risques.

CLOUD Act et RGPD : où se situe la tension juridique

La coexistence du CLOUD Act et du RGPD crée une zone de friction normative que ni les entreprises ni les régulateurs ne peuvent ignorer. Elle ne conduit pas automatiquement à une incompatibilité absolue, mais elle impose une analyse précise des situations à risque.

Le point de tension central est l’article 48 du RGPD. Cet article 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 — par exemple un traité d’entraide judiciaire (MLAT) — en vigueur entre ce pays tiers et l’Union européenne ou un État membre. Or, le CLOUD Act permet précisément d’obtenir des données sans passer par un tel accord international, en s’adressant directement au fournisseur. Il contourne ainsi le mécanisme que l’article 48 du RGPD présuppose.

La tension se manifeste à plusieurs niveaux :

• Transferts de données : la remise de données personnelles d’un citoyen européen à une autorité américaine constitue un transfert vers un pays tiers au sens du RGPD. Sans décision d’adéquation couvrant ce transfert spécifique, sans clauses contractuelles types applicables, et sans consentement explicite de la personne concernée, ce transfert est potentiellement illicite au regard du droit européen.
• Obligations du sous-traitant : l’article 28 du RGPD impose au sous-traitant de ne traiter les données que sur instruction documentée du responsable de traitement. Répondre à une injonction américaine sans en informer le responsable de traitement ni obtenir son accord constitue un traitement non autorisé — sauf si le fournisseur y est légalement contraint, auquel cas il doit en informer le responsable de traitement « à moins que le droit applicable ne l’interdise pour des motifs importants d’intérêt public ».
• Absence de notification : le CLOUD Act peut interdire au fournisseur de notifier son client de l’existence d’une demande. Cette confidentialité imposée empêche le responsable de traitement d’exercer ses droits (contester la demande, notifier les personnes concernées, informer la CNIL), créant une situation d’impossibilité de conformité.
• Bases légales : aucune des bases légales du RGPD (consentement, exécution d’un contrat, intérêt légitime, obligation légale) ne couvre de manière évidente la divulgation contrainte à une autorité étrangère sans base conventionnelle.

Il serait inexact de conclure que toute utilisation d’un cloud américain est incompatible avec le RGPD. La tension existe lorsque des données personnelles de résidents européens sont effectivement visées par une demande, ce qui reste statistiquement rare pour la majorité des entreprises. Mais pour les organisations traitant des données sensibles à grande échelle — données de santé, données financières, données de millions d’utilisateurs européens — l’exposition est réelle et doit être traitée.

Pour comprendre ce que le CLOUD Act change vraiment, il faut le comparer aux instruments qui l’ont précédé, notamment le Patriot Act et le système des MLAT, souvent confondus dans le débat public.

CLOUD Act, Patriot Act, MLAT : ce qui est souvent confondu

Les discussions sur la souveraineté numérique mélangent fréquemment trois instruments juridiques distincts, avec des logiques, des portées et des procédures très différentes. Clarifier ces distinctions est indispensable pour évaluer correctement son exposition.

Le Patriot Act, adopté en 2001 dans le contexte des attentats du 11 septembre, est principalement centré sur le territoire américain. Il autorise des mesures de surveillance étendues, dont certaines sans mandat judiciaire classique (les National Security Letters), mais son champ d’application extraterritorial est plus limité que celui du CLOUD Act. Confondre les deux conduit à surestimer la portée du Patriot Act sur les données européennes et à sous-estimer celle du CLOUD Act.

Le système des MLAT (Mutual Legal Assistance Treaties) est le cadre antérieur que le CLOUD Act cherche partiellement à contourner. Avant 2018, pour obtenir des documents détenus à l’étranger par une entreprise américaine, le SCA exigeait une demande d’entraide judiciaire internationale fondée sur des traités bilatéraux. Ce mécanisme offrait une protection importante : le pays requis pouvait examiner la demande, vérifier sa conformité avec son propre droit, et refuser si elle contrevenait à ses principes fondamentaux. La Convention de Budapest sur la cybercriminalité (2001) avait d’ailleurs suggéré le recours à ces traités bilatéraux comme cadre privilégié pour l’échange de données dans un contexte judiciaire ou de sécurité nationale.

Le CLOUD Act modifie cet équilibre de deux façons :

• Il permet d’obtenir des données stockées à l’étranger sans demande internationale, en s’adressant directement au fournisseur soumis au droit américain ;
• Il crée un nouveau mécanisme d’executive agreements (accords exécutifs bilatéraux) qui permet des demandes directes entre pays signataires, avec réciprocité — ce qui signifie que les autorités du pays partenaire peuvent aussi accéder à des données stockées aux États-Unis.

Ce dernier point est souvent oublié dans le débat européen : le CLOUD Act n’est pas un instrument à sens unique. Il ouvre potentiellement la voie à une coopération réciproque, ce qui explique pourquoi certains gouvernements européens ont envisagé de négocier de tels accords exécutifs avec les États-Unis.

Ces distinctions posées, la question pratique qui se pose à toute organisation est : comment réduire concrètement son exposition, quelle que soit l’architecture cloud retenue ?

Réduire l’exposition : mesures techniques, contractuelles et organisationnelles

La réduction de l’exposition au CLOUD Act ne passe pas nécessairement par l’abandon des hyperscalers américains — ce qui serait souvent disproportionné et techniquement irréaliste. Elle passe par une combinaison de mesures techniques, contractuelles et organisationnelles proportionnées à la criticité des données.

Mesures techniques

Le chiffrement de bout en bout avec gestion des clés externalisée est la mesure la plus efficace. Si les données sont chiffrées avant d’être transmises au fournisseur cloud, et si les clés de chiffrement sont détenues exclusivement par l’organisation cliente (ou par un tiers de confiance hors portée du fournisseur), une injonction adressée au fournisseur ne lui permet d’accéder qu’à des données chiffrées inexploitables. Ce modèle, dit BYOK (Bring Your Own Key) ou HYOK (Hold Your Own Key), est proposé par la plupart des hyperscalers mais doit être configuré explicitement.

• Segmentation des données : isoler les données les plus sensibles dans des environnements distincts, idéalement hébergés chez des fournisseurs non soumis au droit américain pour les données à plus fort enjeu.
• Minimisation des données : ne stocker dans le cloud public que les données strictement nécessaires, en pseudonymisant ou anonymisant ce qui peut l’être.
• Journalisation et détection : mettre en place des mécanismes permettant de détecter toute tentative d’accès anormale, y compris de la part du fournisseur lui-même.

Mesures contractuelles

Les contrats avec les fournisseurs cloud doivent inclure des clauses spécifiques :

• Obligation de notification : exiger que le fournisseur notifie immédiatement toute demande d’accès émanant d’une autorité, dans la limite de ce que la loi applicable lui permet ;
• Obligation de contestation : requérir que le fournisseur utilise les mécanismes de contestation disponibles (notamment le mécanisme prévu par le CLOUD Act pour les données de non-US persons) avant de divulguer ;
• Localisation des données et des opérations : préciser contractuellement que les données ne doivent pas être accessibles depuis des entités soumises à une juridiction étrangère sans accord préalable ;
• Clauses d’audit : se réserver le droit d’auditer les pratiques de sécurité et de conformité du fournisseur, ou d’exiger des certifications tierces (ISO 27001, SOC 2 Type II).

Mesures organisationnelles

• Cartographie des données : identifier précisément quelles données sont hébergées chez quels fournisseurs, avec quel niveau de criticité et quelles mesures de protection. Sans cette cartographie, il est impossible d’évaluer l’exposition réelle.
• Procédure de réponse aux demandes d’accès : définir en amont qui, dans l’organisation, doit être alerté en cas de demande d’accès émanant d’une autorité étrangère, et quelle est la procédure de réponse (conseil juridique, notification à la CNIL, communication aux personnes concernées).
• Critères de sélection des fournisseurs : intégrer dans les appels d’offres cloud des critères explicites liés à la souveraineté juridique, à la localisation des équipes d’exploitation et à la chaîne de sous-traitance.
• Formation des équipes : sensibiliser les équipes IT, juridiques et métiers aux enjeux du CLOUD Act, pour éviter les décisions architecturales prises sans conscience des implications réglementaires.

Ces mesures doivent être calibrées en fonction de la nature des données et du modèle cloud retenu. La section suivante propose une méthode de décision structurée pour faire ce choix de manière documentée.

Méthode de décision : quel modèle de cloud pour quels niveaux de données

Choisir un modèle cloud ne devrait pas être une décision par défaut ou dictée par les seuls critères de coût et de performance. Pour les organisations traitant des données sensibles, ce choix doit être documenté, proportionné et défendable devant un régulateur. Voici une grille de décision structurée.

Étape 1 : classifier les données par niveau de criticité

Avant tout choix architectural, il faut catégoriser les données selon leur sensibilité :

• Niveau 1 — Données publiques ou non sensibles : données marketing, contenus publics, données anonymisées. Aucune contrainte spécifique liée au CLOUD Act.
• Niveau 2 — Données internes sensibles : données RH, données clients pseudonymisées, données financières non critiques. Exposition modérée, mesures de chiffrement recommandées.
• Niveau 3 — Données critiques : données personnelles sensibles (santé, données judiciaires), secret des affaires, propriété intellectuelle stratégique, données relevant de la sécurité nationale. Exposition maximale, architecture à contrôler strictement.

Étape 2 : croiser criticité des données et modèle cloud

Étape 3 : vérifier le statut juridique du fournisseur

Pour chaque fournisseur envisagé, vérifier :

• Est-il soumis au droit américain (siège, filiale, activité substantielle aux États-Unis) ?
• Dispose-t-il d’une qualification de sécurité reconnue (SecNumCloud pour la France, C5 pour l’Allemagne) ?
• Ses équipes d’exploitation et d’astreinte sont-elles localisées en dehors de toute juridiction à risque ?
• Ses contrats incluent-ils des engagements explicites sur la notification et la contestation des demandes d’accès ?

L’hébergement en France ne suffit pas si le fournisseur est une filiale d’un groupe américain : c’est le rattachement juridique qui compte, pas l’adresse IP des serveurs.

Étape 4 : documenter la décision

Toute décision d’architecture cloud pour des données de niveau 2 ou 3 devrait faire l’objet d’une analyse d’impact relative à la protection des données (AIPD) au sens du RGPD, intégrant explicitement le risque CLOUD Act. Cette documentation protège l’organisation en cas de contrôle de la CNIL et démontre une démarche de conformité proactive.

Cette méthode n’est pas une garantie absolue — aucune architecture ne l’est — mais elle permet de prendre des décisions éclairées, proportionnées et traçables, ce qui est précisément ce qu’attendent les régulateurs européens.

FAQ

Ce qu’il faut savoir sur le cloud ?

Le cloud désigne la fourniture de ressources informatiques (calcul, stockage, applications) via internet par un prestataire tiers. Il existe trois modèles de déploiement principaux : public, privé et hybride. La sécurité des données dans le cloud repose sur trois principes fondamentaux — confidentialité, intégrité, disponibilité — et sur une répartition claire des responsabilités entre le fournisseur et le client, notamment en matière de protection des données personnelles au sens du RGPD.

Qu’est-ce que le Cloud Act ?

Le CLOUD Act (Clarifying Lawful Overseas Use of Data Act) est une loi fédérale américaine adoptée le 23 mars 2018. Elle autorise les autorités judiciaires américaines à exiger d’un fournisseur de services soumis au droit américain la remise de données de communications électroniques, quelle que soit la localisation physique de ces données. Le critère d’applicabilité est le rattachement juridique du fournisseur au droit américain, et non l’adresse des serveurs. La remise des données est conditionnée à un mandat judiciaire américain valide.

Quels sont les 3 types de cloud ?

Les trois types de cloud sont le cloud public (infrastructure mutualisée exploitée par un fournisseur tiers, accessible via internet), le cloud privé (infrastructure dédiée à une seule organisation, hébergée en interne ou chez un prestataire), et le cloud hybride (combinaison des deux, permettant de distribuer les charges de travail et les données selon leur criticité entre environnements public et privé).

Quels sont les 3 principes de la sécurité des données ?

Les trois principes fondamentaux de la sécurité des données sont la confidentialité (seules les personnes autorisées accèdent aux données), l’intégrité (les données ne sont pas altérées de manière non détectée) et la disponibilité (les données et systèmes sont accessibles quand les utilisateurs légitimes en ont besoin). Ces trois principes, souvent regroupés sous l’acronyme CIA, structurent toute politique de sécurité informatique et guident les choix d’architecture cloud.

Le CLOUD Act n’est ni un monstre juridique incontrôlable ni un risque négligeable. C’est une loi précise, avec un champ d’application défini, des procédures encadrées et des mécanismes de contestation. Ce qui la rend exigeante pour les organisations européennes, c’est qu’elle opère dans un cadre juridique américain sans contrôle préalable des autorités européennes, créant une tension réelle avec le RGPD pour les données personnelles. La réponse rationnelle est une stratégie de données différenciée : classifier, chiffrer, contractualiser, documenter — et choisir ses fournisseurs avec une connaissance précise de leur statut juridique réel.