Cloud souverain et formation : préparer les étudiants aux enjeux géopolitiques du cloud

La souveraineté numérique n'est plus un débat de théoriciens. C'est une contrainte opérationnelle que vos étudiants rencontreront dès leur premier poste en DSI, en cabinet de conseil ou en RSSI. Pourtant, la majorité des cursus cloud se concentrent sur les hyperscalers américains — AWS, Azure, GCP — en laissant de côté la question fondamentale : où sont les données, qui peut y accéder, et selon quelle loi ?

Cet article propose un parcours pédagogique complet pour aborder le cloud souverain en formation : cartographie des offres, cadre réglementaire, atelier de décision multi-cloud, travaux pratiques sur un IaaS européen, et débat en salle sur la tension souveraineté/agilité. Le tout en une journée ou en sessions disséminées dans votre cours de sécurité cloud existant.

Introduction : pourquoi le cloud souverain est devenu un enjeu d'enseignement

Pendant longtemps, la question du cloud souverain était perçue comme un sujet politique. Les équipes techniques faisaient leur choix en fonction des fonctionnalités et du coût. La localisation du datacenter et la nationalité du prestataire passaient au second plan.

Plusieurs événements ont changé la donne. Le Cloud Act américain (2018) permet aux autorités américaines d'accéder aux données hébergées par des entreprises soumises au droit américain, quelle que soit la localisation physique du serveur. En 2020, l'arrêt Schrems II de la CJUE a invalidé le Privacy Shield et mis en lumière les tensions entre droit européen et lois de surveillance américaines. Ces évolutions ont imposé aux administrations et aux entreprises d'évaluer concrètement le risque juridique lié à chaque prestataire cloud.

Pour vos étudiants, cela se traduit très directement : un futur expert en sécurité cloud doit savoir expliquer pourquoi héberger des données RH sur AWS Paris ne résout pas le problème de souveraineté, et savoir évaluer une offre cloud souveraine en comprenant ses compromis. C'est ce que cet article vous aide à enseigner.

Cartographier les offres et les concepts : ce que les étudiants doivent savoir

Résidence des données, hébergement et qualification (SecNumCloud, C5, ISO 27001)

La première confusion à lever avec vos étudiants est celle entre résidence des données et souveraineté des données. Un datacenter localisé en France n'est pas synonyme de données souveraines si l'entreprise qui l'exploite est soumise à une législation extraterritoriale.

Présentez ces trois niveaux de garantie, du plus faible au plus fort :

• La résidence des données : le stockage physique est localisé dans un pays ou une région définie. C'est une garantie de localisation, pas de protection juridique.
• L'hébergement par une entité de droit européen : le prestataire est une société de droit français ou européen, sans actionnaire ou maison mère soumis au Cloud Act américain ou à d'autres législations à portée extraterritoriale. C'est la condition nécessaire mais pas toujours suffisante pour parler de souveraineté opérationnelle.
• La qualification : une certification formelle atteste que le prestataire répond à un référentiel exigeant. En France, le visa SecNumCloud de l'ANSSI est le référentiel le plus élevé. En Allemagne, le BSI C5 joue un rôle comparable. L'ISO 27001 reste une baseline internationale reconnue, mais sans dimension souveraineté intrinsèque.

Le SecNumCloud mérite une explication soignée. Ce référentiel de qualification publié par l'ANSSI (Agence Nationale de la Sécurité des Systèmes d'Information) impose notamment l'absence de loi extraterritoriale applicable au prestataire, un audit rigoureux des processus de sécurité et des exigences fortes sur la gestion des clés de chiffrement. En 2026, un nombre limité de prestataires ont obtenu cette qualification ou sont en cours de processus : c'est un excellent sujet d'analyse de risque réglementaire à confier à des groupes d'étudiants.

Tableau comparatif simplifié : hyperscalers vs cloud souverains européens

Le tableau suivant constitue un support pédagogique de référence à projeter et commenter en cours. Les données sont qualitatives et illustratives ; invitez vos étudiants à les compléter et à les vérifier sur les sites officiels des prestataires.

Ce tableau appelle trois commentaires. Premièrement, les hyperscalers ont lancé des offres baptisées « souveraines » — Google Cloud pour la France avec Thales (S3NS), Microsoft avec Bleu — mais ces partenariats sont en cours de qualification et méritent une analyse critique : qui détient le capital, qui contrôle le code source ? Deuxièmement, Outscale (filiale de Dassault Systèmes) est l'un des prestataires IaaS ayant obtenu la qualification SecNumCloud, ce qui le positionne sur les SI les plus sensibles. Troisièmement, l'étendue du catalogue d'un hyperscaler est à la fois un atout et un risque : plus de services disponibles signifie plus de surface d'attaque et plus de dépendances potentielles.

Le cadre réglementaire : RGPD, Cloud Act, FISA — explication pédagogique

Trois textes structurent la compréhension réglementaire du cloud souverain. L'enseignant dispose ici d'un excellent cas pratique de conflit de droits.

Le RGPD (règlement UE 2016/679) encadre le traitement des données personnelles des ressortissants européens. Tout transfert hors EEE doit reposer sur un accord d'adéquation ou des clauses contractuelles types (CCT). Le RGPD n'interdit pas le cloud américain, mais impose de démontrer un niveau de protection équivalent — exercice rendu très complexe par l'arrêt Schrems II pour les prestataires soumis au droit américain.

Le Cloud Act (2018) permet aux autorités américaines de contraindre AWS LLC, Microsoft Corporation ou Google LLC à fournir des données hébergées n'importe où dans le monde, y compris en Europe. Il prévoit des mécanismes de contestation, mais crée une obligation légale qui prime sur les engagements contractuels.

Le FISA (Foreign Intelligence Surveillance Act), section 702, autorise la surveillance des communications de non-citoyens américains. C'est ce texte qu'a visé la CJUE dans Schrems II : les programmes de surveillance américains n'offraient pas de recours effectif aux ressortissants européens.

Exercice efficace : donnez à des groupes un scénario (données RH d'une collectivité, dossiers médicaux, algorithmes de défense) et demandez-leur d'identifier les textes applicables et les risques résiduels selon le prestataire choisi.

Atelier de décision : multi-cloud, lock-in et chiffrement

Scénario de cas : quel cloud pour quelle donnée ?

Proposez ce scénario fil rouge, jouable en binômes.

Le contexte. Une métropole française informatise sa gestion administrative. Trois catégories de données sont identifiées : données de voirie (non sensibles), données RH et paie des agents (RGPD), données de vidéoprotection urbaine (potentiellement classifiées). La DSI doit proposer une architecture cloud cohérente avec les obligations légales.

Demandez à chaque groupe une matrice de décision : pour chaque catégorie, quel prestataire, quelle qualification, quel chiffrement, quelle réversibilité ? C'est l'exercice qui fait vivre la théorie réglementaire dans une décision architecturale concrète.

La notion de lock-in (exemples concrets)

Le lock-in — ou dépendance fournisseur — est une notion centrale de l'atelier. Il prend trois formes :

• Le lock-in technique : services propriétaires sans équivalent ailleurs. Un workflow AWS Step Functions + Lambda ne se migre pas facilement vers OVHcloud. Plus une organisation consomme de services managés propriétaires, plus elle est captive.
• Le lock-in de données : volume et frais d'egress (sortie de données) créent une barrière financière réelle à la migration.
• Le lock-in contractuel et organisationnel : compétences internes et processus construits autour d'un écosystème génèrent une inertie souvent sous-estimée.

Les stratégies de défense : containerisation (Kubernetes réduit la dépendance à l'IaaS), standards ouverts (S3-compatible pour le stockage, OpenStack pour l'IaaS), et clause de portabilité exigée dès la rédaction des contrats.

Le chiffrement client (BYOK) comme levier de souveraineté

Le chiffrement BYOK (Bring Your Own Key) est le levier technique de souveraineté le plus accessible à enseigner. Le principe : l'organisation génère et conserve ses propres clés de chiffrement, plutôt que de déléguer cette gestion au prestataire.

Si les données sont chiffrées avec des clés maîtrisées par l'organisation avant d'être envoyées dans le cloud, le prestataire ne peut pas y accéder en clair — même sous injonction légale. C'est un garde-fou partiel mais efficace : il ne supprime pas la visibilité sur les métadonnées, mais protège le contenu.

Les limites du BYOK sont pédagogiquement aussi importantes que ses atouts. La perte d'une clé équivaut à la perte des données. Le BYOK ne protège pas si le chiffrement est délégué à une bibliothèque propriétaire du fournisseur. En architecture SaaS, il est souvent inaccessible. Faites construire à vos étudiants un tableau des couvertures : quelles données, quel chiffrement, qui gère les clés, quelle procédure de révocation.

TP sur un IaaS pédagogique (3 heures)

Ce travail pratique se déroule sur OVHcloud ou Scaleway : deux prestataires proposant des offres accessibles aux étudiants, hébergées en France, sans carte bancaire obligatoire selon les niveaux. L'objectif est de confronter les étudiants à la réalité opérationnelle d'un cloud souverain, d'en mesurer les capacités et les contraintes, puis de les comparer avec un hyperscaler.

Déployer une VM sur OVHcloud ou Scaleway : étapes et points d'attention sécurité

La séquence proposée tient en six étapes :

1. Création du compte : notez que la vérification KYC est conforme au droit européen et que les données sont traitées en France.
2. Déploiement d'une instance (Compute Instance sur Scaleway, Public Cloud sur OVHcloud) : image Ubuntu LTS, région française (FR-PAR ou GRA), instance la plus petite.
3. Accès SSH avec clé publique : imposez Ed25519, interdisez l'authentification par mot de passe — bonnes pratiques valables sur tout prestataire.
4. Désactivation des ports inutiles : le groupe de sécurité n'autorise que le port 22 depuis votre réseau et les ports applicatifs strictement nécessaires.
5. Activation des logs : journal des connexions et supervision basique. Faites constater que les options de logging natif sont plus limitées qu'un hyperscaler — c'est un compromis réel.
6. Destruction de l'instance en fin de TP : ne jamais laisser de ressources actives non nécessaires, a fortiori en environnement pédagogique.

L'interface de gestion est disponible en français avec un support client francophone — un argument souvent sous-estimé. Le catalogue de services plus réduit peut être vécu comme contrainte ou comme simplification selon le contexte.

Configurer des politiques IAM minimalistes

L'IAM (Identity and Access Management) est le pilier de la sécurité cloud, souverain ou non. Pour ce TP, l'objectif est d'appliquer le principe du moindre privilège sur un périmètre simple.

Demandez à chaque binôme de créer deux utilisateurs fictifs : un administrateur d'infrastructure (droits de création et suppression d'instances) et un développeur applicatif (lecture des métriques et dépôt de fichiers dans un objet de stockage défini). Les droits sont attribués via des politiques IAM formelles, jamais via des comptes root.

Les questions à poser en cours de TP : comment révoquer l'accès d'un utilisateur en trente secondes ? Comment auditer qui a fait quoi sur les dernières 24 heures ? Ces questions n'ont pas toujours de réponse satisfaisante dans les offres de moindre taille — c'est une donnée de la comparaison avec les hyperscalers.

Comparer la latence et les options de conformité avec un hyperscaler

La comparaison est la conclusion pédagogique du TP. Proposez une mesure simple : depuis un même réseau, une requête HTTPS vers Scaleway Paris et vers AWS eu-west-3 (Paris) donnera une latence comparable pour des workloads standards. La proximité géographique des datacenters européens souverains ne pénalise pas les performances courantes.

La comparaison des options de conformité est plus instructive. Faites rechercher aux étudiants : quel prestataire propose une attestation HDS (Hébergement de Données de Santé) ? Lequel est qualifié pour des données de niveau Diffusion Restreinte ? Lequel propose un DPA (Data Processing Agreement) conforme au RGPD signable en ligne ? Ces recherches en autonomie développent une compétence d'évaluation fournisseur très concrète.

Liens avec les certifications cloud sécurité

Le cloud souverain ne dispose pas encore de certification grand public dédiée. Plusieurs certifications reconnues couvrent néanmoins des domaines directement liés et constituent des jalons de progression pertinents.

L'AWS Security Specialty reste la certification la plus demandée sur les postes de cloud security engineer en France. Elle couvre IAM, KMS, logging, GuardDuty — des compétences conceptuellement transférables à tout environnement cloud, y compris souverain. Nuance à transmettre : les services eux-mêmes ne sont pas portables, mais la posture (moindre privilège, chiffrement, audit) l'est entièrement.

Le CCSP (Certified Cloud Security Professional, ISC²) et le CCSK (Certificate of Cloud Security Knowledge, CSA) offrent une perspective multi-cloud avec des chapitres spécifiques sur la souveraineté des données et les responsabilités contractuelles. Ces certifications ciblent particulièrement les futurs consultants ou architectes sécurité cloud.

La norme ISO 27017 (bonnes pratiques de sécurité dans le cloud) et l'ISO 27018 (protection des données personnelles dans le cloud) apparaissent fréquemment dans les contrats avec des prestataires souverains — utiles à mentionner comme grilles d'audit.

Pour aller plus loin sur les menaces ciblant les environnements cloud — persistance, escalade de privilèges, exfiltration — les frameworks d'analyse des menaces persistantes avancées complètent naturellement ce parcours.

Débat en salle : souveraineté vs agilité (format 45 minutes)

Ce débat structuré permet de clore la journée sur les dimensions stratégiques de la souveraineté cloud, souvent plus décisives que les aspects purement techniques.

Mise en place. Divisez la salle en deux camps. Le premier défend un DSI qui souhaite migrer l'ensemble du SI sur AWS pour gagner en agilité et en catalogue de services. Le second défend un RSSI qui exige que les données sensibles restent sur une offre qualifiée SecNumCloud. Chaque camp dispose de dix minutes pour préparer ses arguments.

Les thèmes à faire émerger. Le débat gagne à aborder les quatre tensions suivantes :

• Le coût de la souveraineté : les offres souveraines sont généralement plus coûteuses et proposent un catalogue moins riche. Comment justifier l'écart budgétaire devant une direction générale orientée efficacité ?
• La compétitivité des talents : les développeurs et les ingénieurs cloud veulent travailler sur les technologies les plus répandues du marché. Imposer un cloud souverain au catalogue réduit crée-t-il un désavantage dans le recrutement ?
• La réversibilité comme argument économique : éviter le lock-in sur un hyperscaler, c'est aussi préserver sa capacité à renégocier ou à changer de prestataire. La souveraineté peut alors être présentée comme un avantage compétitif à long terme.
• Le principe de proportionnalité : toutes les données ne méritent pas le même niveau de protection. Une stratégie multi-cloud différenciée — données sensibles sur cloud souverain qualifié, données non sensibles sur hyperscaler — est-elle réaliste opérationnellement ?

Débriefing. Réservez dix minutes pour identifier les arguments les plus solides et construire une synthèse : en pratique, la majorité des organisations adoptent une approche hybride différenciée selon la sensibilité des données. La compétence recherchée chez un futur professionnel n'est pas de choisir un camp, mais de maîtriser les critères de décision.

Ce qu'il faut retenir

• La résidence physique des données ne suffit pas : un datacenter en France opéré par une entité soumise au Cloud Act américain ne garantit pas la souveraineté des données. L'identité juridique et capitalistique du prestataire est au moins aussi importante que la localisation du serveur.
• SecNumCloud est le référentiel de référence en France : pour les données les plus sensibles, il constitue le critère de qualification à connaître et à savoir expliquer, aussi bien aux décideurs qu'aux équipes techniques.
• Le BYOK est un levier accessible, pas une solution universelle : il protège le contenu des données mais ne supprime pas la visibilité sur les métadonnées ni les obligations liées au Cloud Act. Enseigner ses limites est aussi important qu'enseigner son fonctionnement.
• Le lock-in se prévient dès la conception : containerisation, standards ouverts, clauses de portabilité et d'audit dans les contrats — ces décisions architecturales et contractuelles se prennent en amont, pas lors d'une migration d'urgence.
• La souveraineté est une décision de gouvernance, pas seulement technique : les meilleurs professionnels du cloud souverain sont ceux qui savent articuler contraintes réglementaires, analyse de risque et compromis opérationnels devant des interlocuteurs non techniques.

Vous souhaitez intégrer un module cloud souverain dans votre cursus, trouver un intervenant expert sur ces sujets ou structurer un TP sur IaaS européen ? Découvrez les ressources et l'accompagnement de Cyber Teachers pour enseigner la cybersécurité avec des cas réels et des supports pédagogiques prêts à l'emploi.