CLOUD Act : définition et conséquences en Europe

Le CLOUD Act est une loi fédérale américaine de 2018 qui permet aux autorités des États-Unis d'exiger d'un fournisseur de services américain les données qu'il détient, quel que soit le pays où elles sont stockées.

Pour une organisation française, cela veut dire que des données hébergées à Paris ou à Francfort chez un fournisseur américain restent exposées à une injonction venue des États-Unis. En France, c'est l'une des raisons pour lesquelles l'État impose un cloud qualifié SecNumCloud pour ses données sensibles. Dans ce guide, nous verrons :

• ce que prévoit le CLOUD Act et à quels fournisseurs il s'applique ;
• pourquoi il entre en tension avec le RGPD, notamment avec son article 48 ;
• ce que cela change concrètement pour les organisations européennes ;
• comment réduire l'exposition, en particulier pour vos communications sensibles et votre communication de crise.

Pour découvrir comment Wire sur Cloud Temple protège vos communications sensibles, échangez avec notre équipe.

Qu'est-ce que le CLOUD Act ?

Le CLOUD Act (Clarifying Lawful Overseas Use of Data Act) est une loi américaine adoptée en mars 2018. Elle permet aux autorités américaines d'exiger des données détenues par un fournisseur relevant de la juridiction des États-Unis, même stockées à l'étranger, y compris dans l'Union européenne, et même lorsqu'elles concernent des personnes non américaines.

Le texte, disponible sur le site du Département de la Justice américain, a été adopté pour répondre à un litige où Microsoft refusait de livrer des courriels stockés en Irlande. Il a tranché la question en faveur de l'accès : ce qui compte est la maîtrise des données par le fournisseur, pas l'endroit où elles sont stockées.

Il est parfois appelé « Cloud Act américain » ou « loi CLOUD ». Il s'applique aux fournisseurs de services de communications électroniques et de cloud, c'est-à-dire aux hébergeurs, aux messageries et aux suites collaboratives.

Comment fonctionne le CLOUD Act ?

Le CLOUD Act repose sur deux séries de dispositions. La première oblige les fournisseurs à communiquer les données qu'ils détiennent, la seconde permet à Washington de conclure des accords avec des pays tiers.

À qui s'applique-t-il ?

Aux fournisseurs soumis à la juridiction américaine : sociétés américaines, mais aussi filiales étrangères de groupes américains dès lors que le groupe contrôle les données. Une filiale européenne de Microsoft, Google ou Amazon n'échappe donc pas au texte du seul fait de son implantation.

Le texte vise les données « en possession, sous la garde ou sous le contrôle » du fournisseur, où qu'elles soient stockées : serveurs en Europe ou aux États-Unis, c'est la même règle.

Qu'exige-t-il exactement ?

Une injonction américaine doit en principe s'appuyer sur un mandat délivré par un juge dans le cadre d'une enquête pénale. Elle peut viser le contenu des messages comme les données de connexion, et peut être accompagnée d'une interdiction d'en informer la personne concernée.

Il ne s'agit donc pas d'un accès « sans mandat », comme on le lit parfois, mais d'un accès sans contrôle d'un juge européen et sans que l'autorité de protection des données de l'Union soit associée.

Les accords exécutifs et la possibilité de s'opposer

Le CLOUD Act autorise les États-Unis à conclure des accords exécutifs avec des pays tiers : leurs enquêteurs peuvent alors s'adresser directement aux fournisseurs de l'autre pays, et réciproquement. Le premier a été signé avec le Royaume-Uni en octobre 2019, et le Contrôleur européen de la protection des données a suivi la négociation d'un accord avec l'Union européenne.

Un fournisseur peut contester une injonction qui l'obligerait à violer le droit d'un pays étranger. Mais ce recours dépend d'un juge américain, repose sur des conditions strictes et reste d'un usage limité : il ne protège pas de manière fiable des données européennes.

CLOUD Act et RGPD : quel conflit juridique ?

Le conflit tient à une question simple : qui décide qu'un fournisseur peut transférer des données personnelles à une autorité étrangère ?

L'article 48 du RGPD

L'article 48 du RGPD prévoit qu'une décision d'une juridiction ou d'une autorité d'un pays tiers exigeant un transfert de données ne peut être reconnue ou exécutée que si elle repose sur un accord international, tel qu'un traité d'entraide judiciaire (MLAT) conclu entre ce pays et l'Union ou un État membre.

Or le CLOUD Act offre aux autorités américaines une voie directe, plus rapide que l'entraide judiciaire. En l'absence d'accord exécutif avec l'Union, une injonction fondée sur ce seul texte ne constitue pas, en droit européen, une base suffisante pour transférer des données personnelles.

Le dilemme des fournisseurs

Les fournisseurs soumis aux deux droits se retrouvent pris en étau :

• s'ils se conforment à l'injonction américaine, ils risquent une sanction au titre du RGPD ;
• s'ils refusent, ils s'exposent à des sanctions aux États-Unis.

Dans une réponse commune de juillet 2019, le Comité européen de la protection des données et le Contrôleur européen ont rappelé que les opérateurs européens ne peuvent pas donner directement suite à une demande fondée sur le seul CLOUD Act. À notre connaissance, aucun accord exécutif entre l'Union et les États-Unis n'a été conclu à ce jour.

Schrems II et le Data Privacy Framework

Le sujet s'inscrit dans un contentieux plus large. En 2020, l'arrêt Schrems II a invalidé le Privacy Shield, au motif que la surveillance américaine ne garantissait pas une protection équivalente. Le Data Privacy Framework, adopté par la Commission en juillet 2023, l'a remplacé pour les transferts vers les entreprises américaines certifiées.

Le Tribunal de l'Union européenne a rejeté, le 3 septembre 2025, un recours en annulation contre ce cadre (affaire T-553/23). Un pourvoi est pendant devant la Cour de justice (affaire C-703/25 P), dont l'issue conditionnera la solidité de ce mécanisme. Le Data Privacy Framework encadre les transferts vers des entreprises certifiées, mais il ne supprime pas l'exposition de ces entreprises à des injonctions américaines.

Quelles conséquences pour les organisations européennes ?

Le CLOUD Act change la manière d'apprécier la souveraineté : la localisation des données n'est plus le bon critère, c'est le droit auquel le fournisseur est soumis.

La localisation ne protège pas

Un fournisseur américain peut garantir que vos données « ne quittent jamais l'Union ». Cette promesse ne l'empêche pas de répondre à une injonction américaine, puisque le texte s'applique quel que soit le lieu de stockage. La juridiction suit le contrôle, pas le serveur.

Les offres « souveraines » des hyperscalers

Les grands fournisseurs américains proposent des offres comme l'EU Data Boundary de Microsoft, le cloud souverain européen d'Amazon ou les contrôles souverains de Google. Elles améliorent la localisation, l'exploitation ou le contrôle des clés, ce qui a une vraie valeur. Mais tant que l'éditeur relève du droit américain, la question de l'accès extraterritorial n'est pas supprimée.

C'est pourquoi la qualification SecNumCloud délivrée par l'ANSSI retient des exigences de protection face aux lois extraterritoriales, qui vont au-delà de la localisation. Elle porte sur l'offre et son opérateur, et ne préjuge pas du niveau de sécurité des services hébergés.

Ce qui protège, et ce qui ne protège pas

Le CLOUD Act n'est pas la seule loi en cause

Le CLOUD Act vise les enquêtes pénales. La section 702 du FISA, dont le renouvellement fait régulièrement l'objet de débats au Congrès, relève du renseignement : elle permet de collecter, auprès de fournisseurs américains, les communications de ressortissants étrangers situés hors des États-Unis. Les deux textes ont le même effet pratique pour une organisation européenne : un fournisseur américain peut être contraint de remettre des données qu'il détient.

Pour une analyse plus large des conséquences sur le choix du fournisseur, lisez notre guide de la souveraineté du cloud.

Les secteurs les plus exposés

L'enjeu est plus fort pour les opérateurs d'importance vitale (OIV) et les futurs opérateurs essentiels au sens de NIS 2, la défense et sa base industrielle (BITD), l'énergie, la santé, la finance et le secteur public. Ces organisations manipulent des informations qui ne doivent pas être accessibles à une autorité étrangère, et doivent pouvoir le démontrer.

En France, la loi SREN impose déjà aux administrations de l'État de recourir à une offre qualifiée SecNumCloud pour leurs données sensibles confiées à un prestataire. Pour NIS 2, parlez de préparation plutôt que de conformité : le projet de loi Résilience n'a pas encore été examiné en séance à l'Assemblée nationale. Notre guide pour se préparer à NIS 2 détaille les mesures attendues.

Comment réduire son exposition au CLOUD Act ?

Aucune mesure ne suffit seule. C'est la combinaison de la juridiction, du chiffrement et du contrat qui réduit l'exposition.

1. Cartographiez vos fournisseurs et leurs juridictions

Listez les services cloud et SaaS réellement utilisés, Shadow IT compris, puis identifiez pour chacun l'éditeur, ses actionnaires, son hébergeur et ses sous-traitants. Cette cartographie révèle souvent des dépendances américaines insoupçonnées.

2. Classez vos données selon leur sensibilité

Toutes les données n'exigent pas le même niveau de protection. Réservez les solutions les plus exigeantes aux données stratégiques, aux données de santé, aux échanges de direction et aux informations de crise.

3. Gardez la maîtrise des clés et chiffrez de bout en bout

Un fournisseur ne peut remettre que ce qu'il détient en clair. Un chiffrement dont vous détenez les clés, et pour les communications un chiffrement de bout en bout, rend les contenus illisibles pour l'hébergeur lui-même. Le principe est expliqué dans notre guide sur les applications de messagerie chiffrée.

4. Privilégiez un éditeur et un hébergeur européens, ou qualifiés SecNumCloud

Pour les données sensibles, choisissez des fournisseurs relevant du droit européen et, en France, des offres qualifiées SecNumCloud. Les enjeux de ce choix sont détaillés dans notre article sur le cloud souverain et les fournisseurs européens.

5. Encadrez les contrats

Exigez des clauses sur les demandes d'autorités étrangères : obligation de vous informer dans la mesure permise par la loi, de contester les demandes disproportionnées et de limiter les données communiquées. Ces clauses réduisent le risque sans l'éliminer, car le fournisseur reste tenu par son droit national.

6. Prévoyez la réversibilité

Formats ouverts, plan de sortie et absence de frais de changement : pouvoir quitter un fournisseur rapidement est une condition de la souveraineté. Privilégier l'open source et des standards ouverts facilite cette réversibilité, comme le montre notre comparatif des messageries instantanées open source.

Pourquoi vos communications sont-elles les premières concernées ?

Messageries et suites collaboratives concentrent les informations les plus sensibles : décisions de direction, échanges avec les sous-traitants, projets confidentiels et, en cas d'incident, coordination de la réponse. Beaucoup relèvent d'éditeurs américains.

Quand ces outils sont indisponibles ou compromis, la cellule de crise perd son canal au pire moment. D'où l'intérêt d'un espace de confiance préparé à l'avance, chiffré de bout en bout, sous un droit que l'organisation maîtrise.

Les solutions pour les échanges qui reposent aujourd'hui sur des applications grand public sont détaillées dans notre guide de l'alternative européenne à WhatsApp. Pour préparer votre canal de crise, consultez notre guide du plan de communication de crise.

CLOUD Act : que retenir ?

Le CLOUD Act expose les données gérées par un fournisseur américain à une injonction américaine, où qu'elles soient stockées, et entre en tension avec l'article 48 du RGPD. La conséquence pratique est simple : la souveraineté se juge à la juridiction du fournisseur et à la maîtrise des clés, pas à l'adresse du centre de données.

Pour réduire l'exposition, cartographiez vos fournisseurs, classez vos données, chiffrez de bout en bout et réservez les clouds de confiance aux usages sensibles. Pour vos communications, Wire sur Cloud Temple fait partie des options : une messagerie chiffrée de bout en bout par défaut, déployée sur une infrastructure qualifiée SecNumCloud par l'ANSSI.

Comment Wire sur Cloud Temple réduit l'exposition de vos communications

Avec Wire sur Cloud Temple, vos équipes disposent d'une messagerie chiffrée de bout en bout, déployée sur le cloud de confiance de Cloud Temple, qualifié SecNumCloud par l'ANSSI. Un espace de confiance pour vos échanges sensibles et votre communication de crise, à côté de vos outils habituels.

Principales fonctionnalités :

• Chiffrement de bout en bout par défaut : messages, appels et visioconférences sont chiffrés de bout en bout sur tous les appareils : un hébergeur ne peut pas remettre ce qu'il ne peut pas lire.
• Déploiement sur un cloud qualifié SecNumCloud : Wire est déployé sur l'infrastructure de Cloud Temple, qualifiée SecNumCloud par l'ANSSI, et référencé dans la Marketplace Cloud Temple. Découvrez Wire sur Cloud Temple.
• Sous contrôle européen : Wire s'appuie sur des investisseurs exclusivement européens.
• Messaging Layer Security (MLS) : Wire s'appuie sur MLS, standard ouvert de l'IETF (RFC 9420), conçu pour sécuriser les échanges en grands groupes.
• Code open source et auditable : le code de Wire est publié et peut faire l'objet d'audits indépendants.
• Gouvernance d'entreprise : administration centralisée, authentification unique (SSO) et provisionnement des comptes (SCIM).
• Collaboration au-delà de l'organisation : l'accès invités et la fédération permettent d'échanger avec vos partenaires, sous-traitants et autorités, avec des membres externes clairement identifiés.

Plus de 1 800 organisations utilisent déjà Wire pour sécuriser leurs échanges. Demandez des références adaptées à votre secteur.

Ou contactez-nous pour voir comment Wire sur Cloud Temple peut répondre à vos exigences.