Cas d'usage cloud souverain
Partie 1 : comparaison sur un cas d'usage concret¶
Comme tu n'as pas précisé de cas, j'en prends un typique : une ETI industrielle de 500 salariés qui migre son ERP, son SIRH (paie, dossiers du personnel) et ses données de R&D (plans, brevets en cours) vers le cloud. Elle a des clients publics et un site classé sensible.
| Critère | Cloud souverain qualifié (type SecNumCloud) | Cloud public américain (AWS, Azure, GCP) |
|---|---|---|
| Droit applicable au fournisseur | Droit européen uniquement, exposition aux lois extraterritoriales écartée par conception | Droit américain applicable (CLOUD Act, FISA 702), même avec des datacenters en UE |
| Catalogue de services | Plus restreint : IaaS solide, PaaS en cours d'enrichissement | Très large : IA, analytique, bases managées, IoT |
| Rapidité d'innovation | Plus lente | Très rapide |
| Coût | Souvent plus élevé à périmètre équivalent, tarification parfois moins flexible | Économies d'échelle, mais factures qui dérivent sans FinOps |
| Intégration avec l'écosystème | Moins d'intégrateurs et de connecteurs prêts à l'emploi | Écosystème immense, compétences faciles à recruter |
| Conformité réglementaire | Atout fort pour marchés publics, OIV, données sensibles | Possible avec des garde-fous (chiffrement, clés maîtrisées), mais zone grise juridique résiduelle |
| Réversibilité | Dépend de l'offre, souvent bâtie sur des standards ouverts | Verrouillage fort si on utilise les services propriétaires |
| Résilience | Moins de régions, moins de redondance géographique | Réseau mondial, redondance élevée |
Ce que je recommanderais comme logique pour ce cas, par type de données :
- Données R&D stratégiques et dossiers du personnel : cloud souverain qualifié. Le risque d'accès par une autorité étrangère, ou d'espionnage économique, pèse davantage que le gain de fonctionnalités.
- ERP : à arbitrer. Si l'éditeur propose une version sur cloud souverain ou qualifié, c'est le meilleur compromis. Sinon, cloud public avec chiffrement et clés gérées par l'entreprise.
- Applications courantes et environnements de test : cloud public, pour la souplesse et le coût.
- Pour les marchés publics ou les donneurs d'ordre sensibles : le cloud qualifié peut être une condition d'accès, pas une option.
La bonne réponse est rarement un choix unique. Une architecture à deux niveaux, avec des données classées par criticité, est ce que font la plupart des organisations qui prennent le sujet au sérieux.
Partie 2 : les exigences de SecNumCloud 3.2¶
Structure générale¶
Le référentiel couvre plus de 360 exigences auditées, couvrant sécurité technique, gestion des accès, gouvernance, audit, chaîne d'approvisionnement, continuité d'activité et conformité. Il s'appuie sur les normes ISO 27001 et apparentées, puis ajoute des exigences propres au cloud et à la souveraineté.
1. Les exigences de sécurité (le socle)¶
- Gouvernance et gestion des risques : politique de sécurité, analyse de risques, responsabilités claires.
- Ressources humaines : vérifications préalables, sensibilisation, gestion des départs.
- Contrôle d'accès et authentification : comptes à privilèges encadrés, authentification renforcée pour l'administration.
- Cryptographie : chiffrement des données au repos et en transit, gestion rigoureuse des clés.
- Sécurité physique des datacenters.
- Cloisonnement des clients : isolation stricte entre locataires (« multi-tenant »).
- Journalisation et détection : traçabilité des actions, détection d'intrusion, supervision.
- Gestion des incidents : procédures et information du client.
- Continuité et reprise d'activité.
- Réversibilité : restitution des données et sortie du service dans des conditions définies.
2. Les exigences de souveraineté (ce qui distingue SecNumCloud)¶
Ancrage dans l'UE. Le prestataire doit avoir son siège statutaire, son administration centrale ou son principal établissement dans un État membre de l'Union européenne.
Contrôle capitalistique. Une entité hors UE ne peut détenir plus de 24 % du capital ou des droits de vote, et les entités hors UE ensemble ne peuvent pas dépasser 39 %. D'autres formes de contrôle décisif, comme certains droits de veto, sont aussi restreintes. L'objectif est qu'aucun actionnaire étranger ne puisse peser sur les décisions stratégiques du prestataire.
Immunité juridique. Les données ne doivent pas pouvoir faire l'objet d'injonctions de la part d'États non européens. Cela s'étend à la chaîne de sous-traitance : il faut documenter sa chaîne de dépendances pour prouver qu'aucun acteur non européen ne dispose d'un accès privilégié aux données.
Localisation et opérations. Le stockage, le traitement, l'administration et le support doivent rester sous maîtrise européenne. Certaines sources évoquent aussi des exigences sur la nationalité et l'habilitation des opérateurs. Je n'ai pas pu confirmer ce point précis dans le texte du référentiel, à vérifier si cela compte pour toi.
Cadre contractuel. Le contrat doit être soumis à un droit européen, avec des clauses sur la protection des données, la confidentialité et la réversibilité.
3. Le processus de qualification¶
Un audit indépendant vérifie la conformité, et l'ANSSI délivre la qualification. Elle est soumise à un audit annuel et à un renouvellement tous les trois ans. Une qualification obtenue doit donc être suivie dans le temps.
Les limites à garder en tête¶
- Le périmètre de qualification : elle peut ne couvrir qu'une partie de l'offre d'un prestataire, pas l'ensemble de sa chaîne technique. Il faut vérifier quel service précis est qualifié.
- L'immunité n'est pas absolue. En janvier 2026, le directeur général de l'ANSSI a lui-même souligné que les opérateurs européens dépendent encore de matériel, de logiciels et de mises à jour qui ne sont pas entièrement maîtrisés en Europe. La protection contre l'ingérence de pays tiers ne peut donc pas être totale.
- Le coût de conformité pour les prestataires se répercute sur les prix et peut limiter le nombre d'acteurs qualifiés.
- Les statuts évoluent vite : Bleu, S3NS et d'autres sont en cours de qualification. La liste officielle de l'ANSSI fait foi.