Souveraineté éducative : le coût caché de l'hébergement de vos contenus pédagogiques hors UE

La question revient à chaque appel d'offres public, à chaque audit Qualiopi sérieux, à chaque conversation avec un DPO conscient des dossiers en cours. Où sont vraiment hébergés les contenus pédagogiques, les référentiels métier, les données apprenants, les copies d'évaluation, les enregistrements de classes virtuelles que produit votre organisme de formation ? Et qui peut, légalement, y accéder en dehors de votre contrôle ?

Beaucoup de directions de la formation continuent de répondre à cette question avec deux raccourcis. Le premier : « nos données sont hébergées en Europe, donc tout va bien ». Le second : « notre fournisseur cloud applique le RGPD ». Les deux réponses sont fausses, ou plus exactement, incomplètes au point d'être trompeuses. Cette tribune explique pourquoi, et propose une grille concrète pour qualifier la souveraineté réelle d'un fournisseur cloud quand il héberge des contenus pédagogiques.

1. La localisation physique des données ne suffit plus depuis 2018

Le CLOUD Act américain — Clarifying Lawful Overseas Use of Data Act, loi H.R. 4943 — a été adopté en mars 2018. Il modifie le Stored Communications Act de 1986 et autorise les autorités fédérales américaines à exiger de toute entreprise technologique relevant de la juridiction américaine la communication de données qu'elle stocke, que ces données soient physiquement situées aux États-Unis ou à l'étranger.

Conséquence pratique pour un OF qui héberge ses contenus chez un hyperscaler américain — AWS, Microsoft Azure, Google Cloud — dont les datacenters sont à Francfort, Paris ou Dublin : la localisation physique européenne ne protège pas contre une demande des autorités américaines. Le critère qui compte est la juridiction du fournisseur, pas l'emplacement physique du serveur. L'European Data Protection Supervisor a publiquement qualifié le CLOUD Act de texte « en conflit potentiel avec le RGPD ».

À côté du CLOUD Act, la Section 702 du Foreign Intelligence Surveillance Act (FISA 702) autorise la surveillance ciblée de personnes non américaines situées hors des États-Unis, avec assistance obligatoire des fournisseurs de communications électroniques. Cette section a été renouvelée en avril 2024 par la loi Reforming Intelligence and Securing America Act (RISAA) pour deux ans, soit jusqu'en avril 2026 — son prochain renouvellement est un des dossiers parlementaires américains à surveiller cette année.

Combinaison des deux textes : un OF hébergé chez un hyperscaler américain en Europe est susceptible de voir ses contenus pédagogiques et ses données apprenants demandés par les autorités américaines sans information préalable du responsable de traitement européen, et sans recours juridique européen exploitable. C'est le scénario que la juriste autrichienne Maximilian Schrems a fait reconnaître à la Cour de justice de l'Union européenne dans l'arrêt qui porte son nom.

2. Schrems II : l'arrêt qui a invalidé le Privacy Shield et compliqué les clauses contractuelles types

L'arrêt C-311/18 du 16 juillet 2020 — connu sous le nom de Schrems II — a invalidé la décision d'adéquation Privacy Shield qui encadrait jusqu'alors les transferts de données entre l'Union européenne et les États-Unis. La CJUE a estimé que le droit américain — notamment FISA 702 — ne fournissait pas de protection essentiellement équivalente au RGPD pour les personnes concernées européennes.

La Cour a maintenu la validité de principe des clauses contractuelles types (CCT) publiées par la Commission européenne, mais avec une mise en garde majeure : leur efficacité doit être évaluée au cas par cas pour chaque transfert. Un responsable de traitement européen qui transfère des données vers les États-Unis ne peut pas se reposer uniquement sur la signature des CCT par son fournisseur — il doit conduire une analyse d'impact spécifique, mettre en place des mesures supplémentaires si nécessaire, et documenter le tout en cas de contrôle CNIL.

Pour un OF qui héberge ses cours, ses référentiels et ses évaluations chez un fournisseur cloud relevant du droit américain, Schrems II n'a pas fermé la porte : il l'a rendue beaucoup plus coûteuse à passer. La documentation à produire, les mesures techniques supplémentaires à déployer — chiffrement bout en bout sans clé chez le fournisseur, pseudonymisation forte, audits récurrents — finissent par effacer une grande partie du gain économique initial de l'hyperscaler américain.

3. SecNumCloud 3.2 : à quoi reconnaître un cloud réellement souverain

L'ANSSI, agence nationale de la sécurité des systèmes d'information, publie depuis 2016 un référentiel d'exigences pour les prestataires de services d'informatique en nuage : SecNumCloud. La version courante, 3.2, publiée en 2022 et mise à jour depuis, est aujourd'hui le standard le plus exigeant en France pour qualifier la sécurité d'une offre cloud.

Le référentiel impose plus de 360 critères de conformité répartis sur 14 thèmes couvrant la sécurité technique, organisationnelle, opérationnelle et juridique. Il est fondé sur l'ISO/IEC 27001 mais y ajoute des obligations prescriptives spécifiques : guides de durcissement, cloisonnement, authentification forte, chiffrement, audits PASSI, et — c'est le point critique pour la souveraineté — localisation des données dans l'Union européenne ET garanties capitalistiques contre les lois extra-européennes.

La condition capitalistique est ce qui distingue SecNumCloud des autres certifications cloud. Elle exige que le prestataire ne soit pas sous contrôle effectif d'une entité soumise à un droit extra-européen — typiquement le droit américain via le CLOUD Act ou la FISA. Cette condition élimine de fait les hyperscalers américains du périmètre SecNumCloud, même quand ils créent des entités juridiques européennes ou des partenariats locaux. Les partenariats Microsoft-Bleu et Google-S3NS sont actuellement en cours de qualification pour tenter de franchir cette barrière, mais le débat reste ouvert sur leur capacité réelle à isoler les opérations européennes du droit américain.

En mars 2026, l'ANSSI et le BSI allemand — l'équivalent allemand de l'ANSSI — ont publié une déclaration commune sur les critères de souveraineté cloud, posant les bases d'une doctrine franco-allemande harmonisée. Le marché du cloud souverain européen est estimé à 12,4 milliards d'euros en 2026, en croissance de 34 % par rapport à 2025. Ce n'est pas un signal anecdotique.

4. EUCS et NIS2 : ce que la réglementation européenne prépare

Au niveau européen, l'ENISA — agence européenne pour la cybersécurité — développe depuis 2020 un schéma de certification cybersécurité pour les services cloud appelé EUCS (European Cybersecurity Certification Scheme for Cloud Services). Ce schéma prévoit quatre niveaux d'assurance — basic, substantial, high, high+ — avec des exigences croissantes en sécurité et en souveraineté.

L'EUCS n'est pas encore adopté formellement. Il fait l'objet, depuis 2024, d'un blocage politique au sein de l'Union européenne entre les États membres qui souhaitent y intégrer des critères de souveraineté forts (notamment la France) et ceux qui s'y opposent au motif que ces critères discrimineraient les fournisseurs non européens. En septembre 2024, le Conseil de l'Union a demandé à la Commission d'accélérer le processus. La révision du Cybersecurity Act prévue pour fin 2025 pourrait être l'occasion d'introduire des « facteurs de risque non techniques » dans les schémas de certification — terme diplomatique qui désigne précisément la question juridictionnelle.

En attendant, deux textes européens entrent en jeu sans attendre EUCS : la directive NIS2 (entrée en vigueur janvier 2023, transposition octobre 2024) et le Data Act (en vigueur depuis septembre 2025). Ces deux textes donnent aux États membres et aux autorités d'application le pouvoir d'exiger que les entités essentielles et importantes — dont une partie significative du secteur de la formation publique et de l'enseignement supérieur — s'appuient uniquement sur des fournisseurs cloud certifiés EUCS lorsque ce schéma sera adopté.

Pour un OF qui forme des publics relevant de la commande publique, des collectivités, des secteurs régulés (banque, santé, défense, énergie), ces évolutions ne sont pas hypothétiques. Elles arrivent dans la fenêtre 2026-2028.

5. Quatre questions concrètes à poser à votre fournisseur cloud

Au-delà des contrats commerciaux et des plaquettes marketing, voici quatre questions que tout OF, CFA ou éditeur SaaS pédagogique gagne à poser explicitement à son fournisseur cloud — et à exiger une réponse écrite, datée, signée.

Question 1 — Qui détient le capital de l'entité qui exploite le service ? Pas l'entité qui signe le contrat — l'entité qui exploite physiquement et opérationnellement le service. Si une part significative du capital est détenue par une entité relevant du droit américain, le CLOUD Act s'applique, même si le contrat est de droit français et le datacenter à Paris.

Question 2 — Quelle est la localisation effective des opérations de support, de maintenance et d'administration ? Les données peuvent être stockées en Europe, mais si les ingénieurs qui ont les accès root sont aux États-Unis ou en Inde, la donnée est de facto accessible depuis ces juridictions. Cette question révèle souvent un écart entre marketing et réalité opérationnelle.

Question 3 — Le fournisseur est-il qualifié SecNumCloud 3.2 ou en cours de qualification documentée ? Un fournisseur qualifié SecNumCloud 3.2 a déjà satisfait la condition capitalistique évoquée plus haut. Un fournisseur qui ne l'est pas et ne s'est pas engagé publiquement dans une démarche de qualification a fait un choix stratégique différent — qui peut être légitime, mais qui doit être transparent.

Question 4 — En cas de demande des autorités américaines, quel est le processus d'information du client ? Un fournisseur sérieux doit pouvoir documenter ce qu'il fait quand une telle demande arrive — il doit notamment vous dire si le client est informé (ce n'est pas toujours le cas, le CLOUD Act prévoit des gag orders), et quelles voies de recours sont activables.

Une absence de réponse claire à l'une de ces quatre questions n'est pas en soi disqualifiante. Une absence de réponse à plusieurs d'entre elles l'est presque toujours.

« Le coût caché de l'hébergement hors UE n'est pas seulement juridique. Il est aussi opérationnel — risk management, conformité, documentation des transferts au sens de Schrems II — et stratégique : un OF qui pratique la commande publique, ou qui forme des publics en milieu régulé, ne peut pas indéfiniment expliquer à ses commanditaires qu'il dépend d'une chaîne d'hébergement soumise à un droit étranger. »

Pour aller plus loin

Les alternatives existent. Le marché du cloud souverain européen, qualifié SecNumCloud ou en voie de qualification, est aujourd'hui assez mature pour accueillir l'essentiel des charges pédagogiques d'un OF — y compris des cours interactifs, des évaluations, des classes virtuelles, des plateformes LMS. La question n'est pas technique. Elle est gouvernance d'achat et lecture des contrats.

ESSN a fait, dès sa création, le choix d'une infrastructure 100 % européenne et de prestataires sous droit français ou européen, sans capital américain dominant. Ce n'est pas une posture marketing, c'est un prérequis pour servir le marché français de la formation professionnelle dans les années qui viennent. Si vous voulez auditer votre propre chaîne d'hébergement avec les quatre questions ci-dessus, demandez la grille d'analyse complète sur essnauthor.fr.