Chapitre 13.4 — Le cloud américain & la souveraineté

⏱️ TL;DR — En pratique, une grande partie du web tourne sur des fournisseurs américains : AWS, Google Cloud, Microsoft Azure, Vercel, Cloudflare, OpenAI… Le point délicat : même quand ils hébergent en Europe, leur maison-mère reste soumise au droit américain — dont le CLOUD Act, qui peut contraindre l’entreprise à communiquer des données où qu’elles soient stockées. D’où la question de souveraineté : qui peut, légalement, accéder aux données ? La réponse est nuancée : ce n’est pas « interdit », c’est « à encadrer et à évaluer » selon la sensibilité. Des repères existent : le label SecNumCloud, la doctrine du cloud de confiance, et des alternatives européennes.

🎯 Objectifs

• Comprendre pourquoi héberger « en Europe » chez un acteur américain ne clôt pas la question.
• Situer le CLOUD Act et la logique de souveraineté numérique.
• Connaître les repères : SecNumCloud, cloud de confiance, alternatives UE.
• Décider de façon nuancée (encadrer / évaluer) plutôt qu’idéologique (interdire / ignorer).

La réalité : une dépendance massive

Soyons lucides : l’infrastructure d’un projet web moderne repose souvent, à un étage ou un autre, sur un hyperscaler américain. Calcul et stockage (AWS, Google Cloud, Microsoft Azure), déploiement (Vercel), réseau et cache (Cloudflare), et désormais l’IA (les grands fournisseurs de modèles de langage sont majoritairement américains). Ce n’est pas un défaut moral : c’est un fait technique avec lequel il faut composer en connaissance de cause.

Ces fournisseurs proposent presque tous des régions européennes : les serveurs sont physiquement à Francfort, Paris ou Dublin. Bonne nouvelle pour la latence et pour une partie du sujet transfert — mais insuffisant pour clore la question, à cause du droit auquel la maison-mère reste soumise.

Le CLOUD Act : la localisation ne suffit pas

Le CLOUD Act est une loi américaine qui permet aux autorités des États-Unis d’exiger d’une entreprise soumise à leur juridiction qu’elle communique les données qu’elle contrôle — quel que soit le pays où ces données sont physiquement stockées. Conséquence : une filiale européenne d’un groupe américain, même hébergée à Francfort, peut être juridiquement atteignable par ces demandes.

C’est exactement la logique que la CJUE a pointée dans Schrems II : au-delà du CLOUD Act, les lois de renseignement américaines (notamment le FISA) permettent un accès aux données sans que l’Européen dispose toujours de recours équivalents à ceux de l’UE. La localisation des serveurs en Europe réduit l’exposition, mais ne la supprime pas tant que le fournisseur reste soumis à un droit extraterritorial.

⚠️ Piège — « Nos données sont dans la région européenne du fournisseur, donc souveraines. » Non. La localisation physique n’égale pas la souveraineté juridique. Si le prestataire (ou sa maison-mère) est soumis au CLOUD Act ou au FISA, la donnée peut, en droit, être exigée — même stockée à Paris. La vraie question n’est pas « où sont les serveurs ? » mais « quel droit s’applique à celui qui les opère, et qui peut y accéder ? ».

Souveraineté : la bonne question

La souveraineté numérique ne se résume pas à un drapeau. Elle pose trois questions concrètes :

• Contrôle juridique — à quel droit est soumis l’opérateur ? Peut-il être contraint de livrer les données par une autorité étrangère ?
• Contrôle technique — qui détient les clés de chiffrement et les accès d’administration ? Le client peut-il rester maître de ses données ?
• Réversibilité — peut-on récupérer ses données et changer de fournisseur sans être verrouillé ?

Un hébergement peut être « en Europe » et faiblement souverain (opérateur soumis à un droit extraterritorial, clés côté fournisseur), ou au contraire fortement souverain (opérateur européen, clés côté client). C’est un curseur, pas un interrupteur.

Les repères pour décider

Face à ça, on ne choisit pas au hasard :

• SecNumCloud — une qualification délivrée par l’ANSSI (l’agence française de cybersécurité) qui exige, entre autres, une immunité aux lois extraterritoriales non européennes. Un cloud qualifié SecNumCloud vise donc à échapper au CLOUD Act. C’est la référence pour les données sensibles et le secteur public.
• Cloud de confiance — la doctrine de l’État français : privilégier des offres qualifiées (souvent adossées à SecNumCloud) pour les données les plus critiques, tout en gardant du pragmatisme pour le reste.
• Alternatives européennes — des acteurs comme OVHcloud ou Scaleway (entre autres) proposent une infrastructure opérée depuis l’UE, hors d’atteinte du droit américain. À évaluer selon les fonctionnalités dont tu as besoin.

Décider sans dogmatisme

La règle n’est pas « interdit d’utiliser un cloud américain ». La règle est : évaluer selon la sensibilité, encadrer ce qu’on garde, relocaliser ce qui l’exige.

• Pour des données peu sensibles et un usage courant, un hyperscaler américain certifié DPF, avec CCT + TIA en filet et chiffrement dont tu gardes les clés, est souvent acceptable.
• Pour des données sensibles (santé, mineurs à grande échelle) ou un contexte public/scolaire, l’exigence monte : on privilégie une offre européenne ou SecNumCloud, et on justifie tout choix contraire.

💡 Réflexe — Chiffre, et garde les clés. La mesure la plus efficace contre le risque d’accès extraterritorial, c’est un chiffrement fort dont toi seul (côté EEE) détiens les clés. Même si une autorité étrangère obtient l’accès aux serveurs, elle ne récupère qu’un contenu illisible. Combine avec la minimisation (n’envoie pas ce dont le service n’a pas besoin) et la pseudonymisation.

📚 Le texte — Il n’y a pas d’article du RGPD qui nomme le « CLOUD Act » : c’est une loi américaine. Mais c’est exactement le type de législation d’accès que l’arrêt Schrems II (C-311/18) impose d’évaluer dans le TIA (chapitre 13.3), au titre des garanties appropriées de l’article 46. La souveraineté n’est pas un concept « politique » hors sujet : elle est au cœur de l’analyse d’impact du transfert.

🧭 Sur FormaCampus — FormaCampus traite des données d’élèves mineurs et, via les aménagements de handicap, des données de santé — donc sensibles. Pour ces flux, l’exigence de souveraineté monte : elle évalue sérieusement des alternatives européennes ou SecNumCloud pour l’hébergement du LMS scolaire, et réserve les fournisseurs américains aux traitements moins sensibles, toujours avec DPF + CCT + TIA + chiffrement. Elle documente pourquoi chaque brique est acceptable — ou pourquoi elle a préféré relocaliser.

🔒 Côté personne concernée — Pour un parent, « mes données sont en Europe » et « mes données sont à l’abri d’un accès étranger » ne sont pas la même chose. La souveraineté, vue de la personne, c’est la certitude que les données de son enfant ne pourront pas être réquisitionnées par une autorité étrangère sans protection. C’est ce qui rend le sujet particulièrement sensible dans l’éducation — on y revient à l’atelier (13.5) et en Partie 15.

✏️ Exercices

Exercice 1 — La localisation suffit-elle ? Un fournisseur américain garantit un hébergement 100 % en région européenne. Un collègue en conclut : « aucun risque de transfert ni d’accès étranger ». Corrige.

Exercice 2 — Quel repère pour quelle donnée ? Associe : (a) un back-office interne peu sensible ; (b) un LMS qui héberge des données de santé d’élèves mineurs. Quel niveau d’exigence, quel type d’offre ?

🧠 Quiz de révision

Chapitre suivant : Atelier : sécuriser les transferts — on applique toute la partie à FormaCampus : cartographier, fonder, évaluer, sécuriser, documenter.