Cloud souverain : souveraineté numérique et SecNumCloud

Le « cloud souverain » est l'un des sujets les plus discutés du numérique français, et l'un des plus mal cadrés. Certains le réduisent à la localisation des données en France, d'autres à un label, d'autres à un rejet des hyperscalers. La réalité est plus fine : la souveraineté se décide par niveaux, selon la sensibilité réelle de vos données et le risque juridique que vous acceptez ou refusez. Cette page pose une lecture neutre, ni pro-hyperscaler ni anti-hyperscaler : ce qu'est vraiment le cloud souverain, ce que qualifie SecNumCloud, où en est le schéma européen EUCS, ce que valent les offres de « cloud de confiance » françaises, la position réelle d'Azure et d'AWS, et comment arbitrer.

• Souveraineté numérique
• SecNumCloud (ANSSI)
• CLOUD Act & FISA 702
• EUCS (schéma européen)
• Cloud de confiance FR

Qu'est-ce que le cloud souverain ? Définition et périmètre

Le cloud souverain désigne un service de cloud dont l'usage garantit à l'organisation cliente la maîtrise de ses données et de son infrastructure, à l'abri d'un accès ou d'un contrôle par une puissance étrangère. La formule paraît simple, mais elle recouvre en réalité trois exigences qui ne se confondent pas, et que l'on peut atteindre séparément.

Cette distinction est le point de départ de toute décision sérieuse. Confondre les trois dimensions conduit à sur-payer une souveraineté dont on n'a pas besoin, ou à croire souverain un service qui ne l'est que partiellement.

• Souveraineté des données

  Maîtriser où les données sont stockées et surtout quel droit s'y applique : quelle autorité peut légalement en exiger l'accès, et dans quelles conditions. La localisation géographique n'est qu'un élément, jamais la garantie complète.

• Souveraineté opérationnelle

  Maîtriser qui administre et exploite la plateforme : accès des équipes techniques, résidence et nationalité des opérateurs, transparence des interventions, chiffrement des données face à l'exploitant lui-même.

• Souveraineté technologique

  Maîtriser la pile technique et la dépendance au fournisseur : capacité à faire fonctionner le service sans un acteur étranger, portabilité, standards ouverts, et réversibilité réelle si l'on doit changer de plateforme.

Un projet peut légitimement viser une seule de ces dimensions. Une entreprise soucieuse de résidence des données en Europe traite d'abord la souveraineté des données. Un organisme qui craint l'accès d'un administrateur étranger vise la souveraineté opérationnelle. Une direction qui refuse tout enfermement travaille la souveraineté technologique, un objet que nous relions directement à la gouvernance cloud et à la réversibilité. Le cloud dit « souverain » au sens fort, celui du label français, réunit les trois.

À retenir. La souveraineté n'est pas un interrupteur « oui / non ». C'est un curseur à plusieurs axes. La bonne question n'est jamais « faut-il du cloud souverain ? » mais « quelle dimension de souveraineté, à quel niveau, pour quelles données ? ».

Souveraineté n'est pas localisation : le vrai enjeu de l'extraterritorialité

Voici le malentendu le plus coûteux du sujet. Beaucoup d'organisations pensent régler la souveraineté en cochant « région France » ou « région Europe » dans leur console cloud. C'est nécessaire pour la résidence des données, mais insuffisant pour la souveraineté juridique. La raison tient à l'extraterritorialité du droit, en particulier américain.

• CLOUD Act (2018) : cette loi permet aux autorités américaines d'exiger d'un fournisseur soumis au droit des États-Unis la communication de données qu'il détient, y compris lorsqu'elles sont physiquement stockées en Europe. Le critère déclencheur n'est pas la localisation de la donnée, mais la nationalité et le rattachement juridique du fournisseur.
• FISA 702 : ce cadre de surveillance à des fins de renseignement peut viser les données traitées par des fournisseurs de communications électroniques relevant du droit américain.
• Executive Order 12333 : il encadre des activités de renseignement extérieur qui alimentent le débat sur l'exposition des données transitant par des infrastructures sous contrôle américain.

Conséquence directe : une donnée hébergée à Paris, sur la région France d'un hyperscaler américain, reste juridiquement atteignable par une injonction américaine si l'entité qui l'opère relève de ce droit. La localisation traite la conformité de résidence, pas la souveraineté juridique.

Cela ne signifie pas que les hyperscalers sont à proscrire. Pour la grande majorité des charges, un usage bien configuré, avec chiffrement et clés maîtrisées, répond aux obligations réelles. Cela signifie qu'il faut traiter l'extraterritorialité comme un risque à évaluer, pas comme un détail. Le panorama réglementaire complet (RGPD, ISO 27001, HDS, transferts hors UE) est traité sur notre page dédiée à la conformité cloud RGPD, ISO et HDS ; ici, l'angle est strictement celui de la souveraineté.

SecNumCloud : ce que le visa de l'ANSSI qualifie vraiment

SecNumCloud est le référentiel d'exigences et la qualification délivrée par l'ANSSI (Agence nationale de la sécurité des systèmes d'information) pour les services de cloud. Il est souvent cité comme le standard français du cloud souverain. Encore faut-il comprendre ce qu'il qualifie exactement, car les raccourcis sont fréquents.

La qualification atteste deux choses distinctes. D'une part, un niveau de sécurité élevé, comparable et souvent supérieur aux meilleures pratiques du marché (gouvernance de la sécurité, gestion des accès, chiffrement, journalisation, continuité). D'autre part, et c'est sa spécificité, une immunité aux lois extraterritoriales non européennes. C'est ce second volet qui en fait un instrument de souveraineté, et non un simple label de cybersécurité.

Dans sa version en vigueur (référentiel 3.2), SecNumCloud impose notamment que le fournisseur ne puisse être contraint par un droit non européen. Les critères marquants :

• Actionnariat et gouvernance : aucune entité établie hors de l'Union européenne ne doit détenir, directement ou indirectement, seule ou de concert, plus de 24 % du capital du fournisseur, ni disposer d'une minorité de blocage. L'objectif est d'empêcher qu'une injonction étrangère puisse s'imposer par le contrôle capitalistique.
• Localisation : les données et leur traitement restent au sein de l'Union européenne.
• Administration et support depuis le territoire de l'UE, par des personnels soumis au droit européen.
• Sécurité technique et organisationnelle de haut niveau, auditée par un évaluateur agréé.

Autrement dit, SecNumCloud répond surtout à la souveraineté des données et opérationnelle. La question de savoir quelles données doivent y résider relève d'une décision de classification, que nous détaillons plus bas dans la grille de niveaux.

EUCS : où en est le schéma européen de certification

À l'échelle de l'Union, un chantier vise à harmoniser la confiance dans les services cloud : l'EUCS (European Cybersecurity Certification Scheme for Cloud Services), élaboré sous l'égide de l'ENISA, l'agence européenne de cybersécurité, dans le cadre du Cybersecurity Act.

L'ambition initiale était de définir des niveaux d'assurance (de base à élevé) et, pour le niveau le plus élevé, d'y intégrer des critères de souveraineté proches de la logique SecNumCloud, dont l'immunité aux lois extraterritoriales. Ce point a suscité un débat nourri entre États membres : certains défendent des exigences de souveraineté fortes, d'autres redoutent d'exclure de fait les grands fournisseurs non européens.

À ce stade, l'état des lieux se résume ainsi, et il faut se garder de toute affirmation péremptoire sur un texte encore mouvant :

• Le schéma n'est pas encore un règlement d'exécution adopté et applicable : il reste en cours de finalisation.
• Les critères de souveraineté du plus haut niveau ont été plusieurs fois révisés, tantôt retirés, tantôt allégés au fil des versions de travail.
• En attendant, la référence opérationnelle française pour la souveraineté demeure SecNumCloud, seul dispositif qualifiant réellement disponible aujourd'hui.

Pour un décideur, la conclusion pratique est simple : ne pas attendre EUCS pour arbitrer. Les données sensibles qui exigent une immunité extraterritoriale se traitent dès maintenant avec les outils existants, quitte à réévaluer quand le schéma européen sera stabilisé.

Les offres de « cloud de confiance » françaises

Le label « cloud de confiance », annoncé par l'État français en 2021, désigne une offre qui réunit deux conditions : la qualification SecNumCloud et l'immunité aux réglementations extraterritoriales. Il a donné naissance à un modèle particulier : opérer une technologie, y compris étrangère, sous licence, mais via une société européenne dont la gouvernance et l'actionnariat respectent les critères de souveraineté. Le tableau ci-dessous situe les principaux acteurs du marché français, avec leur statut, à lire comme un état des lieux et non comme un classement.

Deux lectures s'imposent. D'abord, statut « qualifié » et statut « visé » ne se valent pas : un service effectivement qualifié offre une garantie opposable aujourd'hui, un service « en cours » relève d'une feuille de route qu'il faut suivre. Ensuite, le modèle sous licence (Bleu, S3ns) est une réponse pragmatique au dilemme fonctionnalités contre souveraineté : il vise à apporter la richesse fonctionnelle d'un hyperscaler dans un cadre juridique européen. Sa valeur dépendra de la qualification effective et du périmètre couvert, à examiner au cas par cas.

Notre position d'intermédiaire neutre. Nous ne revendons aucune de ces offres et n'en promouvons aucune par principe. Selon la sensibilité réelle de vos données, la bonne réponse peut être un hyperscaler bien configuré, une offre qualifiée SecNumCloud, ou une combinaison des deux. Le choix se documente par les risques et les contraintes, pas par un slogan.

Azure et AWS face à la souveraineté : capacités et limites

Traiter les hyperscalers de façon neutre suppose de reconnaître à la fois leurs dispositifs réels de souveraineté et leurs limites structurelles. Les deux plateformes ont investi le sujet, sans pour autant s'affranchir de leur rattachement au droit américain.

Microsoft Azure

• Régions françaises : France Central et France South assurent la résidence des données en France.
• EU Data Boundary : engagement de Microsoft de stocker et traiter les données client au sein de l'Union européenne, étendu progressivement aux données personnelles et aux données de support. Il renforce la résidence, mais ne supprime pas l'exposition au CLOUD Act, Microsoft demeurant une entreprise américaine.
• Microsoft Cloud for Sovereignty : ensemble de contrôles (zones d'atterrissage souveraines, politiques, informatique confidentielle) destiné aux organismes publics qui veulent durcir la maîtrise sans quitter Azure.
• Chiffrement et clés : clés gérées par le client (CMK) via Azure Key Vault et Managed HSM, avec des scénarios de type BYOK. Pour certaines charges Microsoft 365, la Double Key Encryption rapproche d'un modèle où une clé reste hors d'atteinte du fournisseur.

Amazon Web Services (AWS)

• Région Paris (eu-west-3) pour la résidence en France.
• AWS European Sovereign Cloud : cloud annoncé comme indépendant, opéré par des personnels résidant dans l'UE, avec une première région en Europe. C'est la réponse structurelle d'AWS à la demande de souveraineté opérationnelle, à suivre selon son calendrier de disponibilité.
• AWS Digital Sovereignty Pledge et conception « sovereign-by-design » : engagements sur le contrôle de la localisation, l'accès restreint et le chiffrement.
• Chiffrement et clés : AWS KMS avec clés gérées par le client, et surtout External Key Store (XKS), qui permet de conserver les clés dans un HSM hors d'AWS, sous votre contrôle exclusif. Le système Nitro limite par conception l'accès des opérateurs aux données des instances.

La limite reste structurelle : aucun dispositif technique d'un fournisseur américain ne le soustrait entièrement au droit américain. Pour les données dont le risque d'accès étranger est jugé inacceptable, la réponse n'est pas un réglage, mais un changement de niveau vers une offre qualifiée. Pour tout le reste, un hyperscaler durci suffit. Cet arbitrage est précisément l'objet de la grille suivante.

Les niveaux de souveraineté selon la sensibilité des données

Voici l'apport central de cette page : cesser de raisonner en tout ou rien, et raisonner en niveaux. Toutes les données d'une organisation n'ont pas la même sensibilité, et il serait aussi absurde de mettre un site vitrine sur un cloud qualifié que d'héberger un fichier régalien sur une région publique standard. La grille ci-dessous propose cinq paliers, à adapter à votre contexte.

Trois principes guident l'usage de cette grille. Premièrement, on classe les données avant de choisir la plateforme, jamais l'inverse. Deuxièmement, on ne surdimensionne pas : la souveraineté a un coût, et l'appliquer partout gaspille des ressources qui manqueront pour la sécurité réelle. Troisièmement, une même organisation combine plusieurs niveaux : rien n'oblige à tout mettre au même endroit. Cette logique de classification prolonge directement notre approche de la gouvernance des données et de la souveraineté.

Quels secteurs sont concernés, et à quel titre

La souveraineté n'a pas la même intensité selon l'activité. Quatre profils dominent les demandes que nous cadrons, chacun avec un cadre réglementaire propre.

• Secteur public, OIV et opérateurs de services essentiels. La doctrine « Cloud au centre » oriente les données sensibles de l'État vers des offres qualifiées. Les opérateurs d'importance vitale et les entités relevant de la directive NIS2 doivent en outre sécuriser leur chaîne d'approvisionnement numérique. Le sujet est développé sur notre page dédiée à la mise en conformité NIS2 dans le cloud et pour le secteur public.
• Santé. L'hébergement de données de santé impose un partenaire certifié HDS, et la sensibilité de ces données pousse fréquemment vers les niveaux N2 à N3 de la grille. La certification vise l'hébergeur, jamais votre application. Voir notre approche du secteur de la santé et, pour les acteurs exposés au droit américain, notre page architecture cloud conforme HIPAA.
• Finance et assurance. Le règlement DORA impose la maîtrise du risque lié aux prestataires tiers et une stratégie de réversibilité documentée, ce qui recoupe directement la souveraineté technologique. Détails sur notre page DORA et résilience opérationnelle dans le cloud et pour le secteur finance.
• Défense et données classifiées. Ici, on quitte le marché standard pour des dispositifs dédiés (niveau N4), hors du champ de cette page.

Arbitrer coût, souveraineté et fonctionnalités

Toute décision de souveraineté est un arbitrage entre trois sommets d'un même triangle : le niveau de souveraineté, le coût, et la richesse fonctionnelle. Tirer sur un sommet déplace les deux autres. Regarder ce triangle en face évite les déceptions.

• +20 à 50 %surcoût d'hébergement souvent observé sur un socle qualifié, selon les contraintes
• 3dimensions à arbitrer : données, opérationnel, technologique
• N0–N4cinq niveaux à combiner selon la classification des données
• Écartfonctionnel possible entre offre qualifiée et catalogue hyperscaler

Trois réalités à intégrer dans le calcul :

• Le coût. Un socle qualifié SecNumCloud ou un cloud de confiance induit un surcoût d'hébergement et d'exploitation, souvent observé de l'ordre de 20 à 50 % par rapport à une offre standard, à mettre en regard du risque évité. Ce surcoût n'est justifié que pour les données qui le méritent, d'où l'importance de la classification.
• Les fonctionnalités. Le catalogue de services managés d'un hyperscaler (IA managée, bases spécialisées, services serverless avancés) est plus large que celui d'une offre souveraine plus récente. Migrer une charge très intégrée à ces services vers un cloud souverain peut demander des adaptations. C'est un point d'architecture, pas un détail.
• La performance et l'écosystème. Le nombre de régions, la densité des zones de disponibilité et l'écosystème partenaire diffèrent. Pour des charges très exigeantes, cela pèse dans l'équation.

Le bon raisonnement de direction. La question n'est pas « le cloud souverain coûte-t-il plus cher ? » mais « pour quelles données ce surcoût est-il justifié par le risque, et pour lesquelles ne l'est-il pas ? ». Une réponse binaire est presque toujours une mauvaise réponse. La mise en regard du coût cloud global relève par ailleurs d'une démarche d'audit FinOps, qui chiffre l'impact réel.

Notre rôle : intermédiaire indépendant

La démarche : cartographier la sensibilité, choisir le bon niveau

Une décision de souveraineté ne s'improvise pas et ne se règle pas par un choix de fournisseur pris à l'avance. Elle suit une trajectoire courte mais rigoureuse, que voici appliquée à un environnement cloud.

1. Cartographier les données et les flux Inventorier ce que vous traitez réellement, où cela circule, et qui y accède. On ne protège que ce que l'on a d'abord cartographié.
2. Classifier par sensibilité Attribuer à chaque ensemble de données un niveau (des données publiques aux données stratégiques), en croisant valeur métier, exigence réglementaire et risque d'accès étranger.
3. Positionner chaque niveau sur la grille N0–N4 Déduire, classe par classe, la réponse de souveraineté adaptée : région UE, clés maîtrisées, HYOK, offre qualifiée. C'est ici que l'arbitrage coût / souveraineté / fonctionnalités se tranche.
4. Concevoir l'architecture cible et le plan de réversibilité Traduire les décisions en architecture (résidence, chiffrement, gestion des clés, isolation), en Infrastructure as Code versionnée, avec une stratégie de sortie explicite.
5. Documenter et outiller la preuve Produire la matrice de décision, la documentation opposable et les contrôles automatisés, réutilisables lors d'un audit ou d'un contrôle réglementaire.

Cette démarche s'articule avec deux briques voisines : l'état des lieux technique relève d'un audit de conformité cloud, et la mise en œuvre sécurisée du socle s'appuie sur le pilier sécurisation d'infrastructure cloud. La cohérence d'ensemble, elle, est un sujet de gouvernance cloud.

Budget, durée et livrables du cadrage de souveraineté

Le cadrage de souveraineté que nous coordonnons est une prestation de conseil, distincte de la mise en œuvre technique qui suit. Les repères ci-dessous concernent cette phase de décision et d'architecture cible.

• 2 à 10 jcadrage et grille de décision, selon le périmètre
• 5 à 18 k€budget indicatif, sur devis selon le périmètre
• N0–N4matrice de niveaux appliquée à vos classes de données
• IaCarchitecture cible versionnée dans vos dépôts

Les livrables type d'un cadrage : la cartographie des données et des flux, la matrice de classification par sensibilité, la grille de décision N0–N4 appliquée à votre contexte, l'architecture cible documentée avec sa stratégie de chiffrement et de gestion des clés, le plan de réversibilité, et une restitution en langage clair pour la DSI comme pour la direction générale. Pour explorer nos métiers connexes, voyez l'ensemble de nos services, le conseil en architecture, la cybersécurité cloud, les secteurs que nous accompagnons et le guide du cloud.

Prêt à trancher sur des faits, pas sur des slogans ? Notre diagnostic situe votre exposition et esquisse la grille de souveraineté adaptée à vos données. Lancez votre diagnostic en ligne ou contactez-nous : réponse sous 48 h ouvrées.

FAQ : Cloud souverain

Qu'est-ce que le cloud souverain ?

Le cloud souverain est un service de cloud dont l'usage garantit à l'organisation cliente la maîtrise de ses données et de son infrastructure, à l'abri d'un accès ou d'un contrôle par une puissance étrangère. Il recouvre trois dimensions distinctes : la souveraineté des données (où elles résident et quel droit s'y applique), la souveraineté opérationnelle (qui administre et exploite), et la souveraineté technologique (maîtrise de la pile technique et réversibilité). On peut viser une seule de ces dimensions selon son besoin.

Quelle différence entre souveraineté des données, opérationnelle et technologique ?

La souveraineté des données concerne la localisation et surtout le droit applicable, c'est-à-dire quelle autorité peut légalement exiger un accès. La souveraineté opérationnelle concerne les personnes qui administrent la plateforme, leur résidence, leurs accès et la transparence des interventions. La souveraineté technologique concerne la dépendance au fournisseur, la portabilité et la capacité à reprendre la main. Un projet peut légitimement viser un seul de ces axes ; le cloud souverain au sens fort les réunit.

Héberger ses données en France les rend-il souveraines ?

Non, pas à elles seules. La localisation en France assure la résidence des données, mais la souveraineté juridique dépend du droit auquel est soumis le fournisseur. Si l'opérateur relève du droit américain, le CLOUD Act permet d'exiger l'accès aux données même stockées en Europe. La localisation traite la conformité de résidence, pas l'exposition à une loi extraterritoriale : ce sont deux questions différentes qu'il faut distinguer.

Qu'est-ce que la qualification SecNumCloud de l'ANSSI ?

SecNumCloud est le référentiel et la qualification délivrée par l'ANSSI pour les services cloud. Elle atteste d'un niveau de sécurité élevé et, surtout, d'une immunité aux lois extraterritoriales non européennes. Dans sa version 3.2, elle impose qu'aucune entité hors UE ne détienne plus de 24 % du capital du fournisseur ni de minorité de blocage, que les données restent dans l'UE, et que l'administration soit assurée depuis le territoire européen. La qualification vise le service du fournisseur, pas votre application.

Qu'est-ce que le cloud de confiance et quelles sont les offres françaises ?

Le « cloud de confiance » est un label français désignant une offre qui réunit la qualification SecNumCloud et l'immunité aux réglementations extraterritoriales. Sur le marché : 3DS Outscale est qualifié SecNumCloud sur un périmètre défini, OVHcloud dispose d'offres au périmètre qualifié, Scaleway se positionne sur la souveraineté, Numspot vise la qualification sur un socle Outscale, tandis que Bleu (Capgemini/Orange, technologies Microsoft) et S3ns (Thales/Google) sont en construction et visent le label. Le statut « qualifié » et le statut « visé » ne se valent pas.

Azure et AWS peuvent-ils être considérés comme souverains ?

Ils offrent des dispositifs réels de souveraineté partielle : régions européennes, EU Data Boundary et Microsoft Cloud for Sovereignty côté Azure, AWS European Sovereign Cloud et External Key Store côté AWS, chiffrement avec clés maîtrisées des deux côtés. Ces mesures renforcent la résidence et la souveraineté opérationnelle. Mais aucune ne soustrait entièrement un fournisseur américain au droit américain. Pour la majorité des charges, un hyperscaler bien configuré suffit ; pour les données les plus sensibles, une offre qualifiée s'impose.

Où en est le schéma européen de certification EUCS ?

L'EUCS, élaboré par l'ENISA, vise à harmoniser la certification de cybersécurité des services cloud à l'échelle de l'Union. L'intégration de critères de souveraineté au niveau d'assurance le plus élevé a été très débattue entre États membres et plusieurs fois révisée. À ce stade, le schéma n'est pas encore un règlement adopté et applicable. En pratique, la référence française pour la souveraineté reste SecNumCloud, seul dispositif qualifiant réellement disponible aujourd'hui ; il ne faut pas attendre EUCS pour arbitrer.

Quelle est la différence entre BYOK et HYOK pour la souveraineté ?

Avec le BYOK (Bring Your Own Key), vous fournissez la clé de chiffrement, mais elle est utilisée à l'intérieur du service du fournisseur, ce qui réduit le risque sans l'éliminer. Avec le HYOK (Hold Your Own Key) ou l'External Key Store d'AWS KMS, la clé ne quitte jamais votre propre HSM et reste sous votre contrôle exclusif : couper la clé rend la donnée illisible, y compris pour l'exploitant. Le HYOK offre une barrière technique plus forte, à combiner avec le bon niveau d'hébergement.

Le cloud souverain est-il obligatoire pour mon entreprise ?

Dans la plupart des cas, non. La qualification SecNumCloud est progressivement imposée pour certaines données sensibles de l'État et de ses opérateurs, dans le cadre de la doctrine « Cloud au centre », mais elle ne s'impose pas à toutes les entreprises. Le RGPD, lui, encadre la protection et les transferts des données personnelles sans imposer un cloud souverain. La bonne approche consiste à classer vos données par sensibilité, puis à réserver la souveraineté forte aux classes qui la justifient réellement.

Le cloud souverain coûte-t-il vraiment plus cher ?

Un socle qualifié SecNumCloud ou un cloud de confiance induit un surcoût d'hébergement et d'exploitation souvent observé de l'ordre de 20 à 50 % par rapport à une offre standard, auquel s'ajoute parfois un catalogue de services managés plus restreint. Ce surcoût n'est pas un problème en soi : il devient un gaspillage s'il est appliqué à des données qui ne l'exigent pas. La bonne question n'est pas le prix absolu, mais pour quelles données ce surcoût est justifié par le risque évité.

Quels secteurs sont concernés par la souveraineté du cloud ?

Principalement quatre. Le secteur public, les OIV et les entités relevant de NIS2, orientés par la doctrine « Cloud au centre ». La santé, soumise à l'hébergement HDS et à une forte sensibilité des données. La finance et l'assurance, où DORA impose la maîtrise du risque tiers et la réversibilité. Et la défense, qui relève de dispositifs dédiés hors marché standard. Chaque secteur combine un cadre réglementaire propre et un niveau de souveraineté adapté à ses données.

Comment choisir le bon niveau de souveraineté pour mes données ?

En raisonnant par niveaux, pas en tout ou rien. On cartographie d'abord les données et les flux, on les classe par sensibilité, puis on positionne chaque classe sur une grille allant du standard hyperscaler (N0) au cloud dédié isolé (N4), en passant par la région UE avec clés maîtrisées et l'offre qualifiée SecNumCloud. Une même organisation combine généralement plusieurs niveaux. C'est l'objet du cadrage de souveraineté que nous coordonnons, avant toute mise en œuvre technique.