Standard · Niveaux
Quatre niveaux. Une hiérarchie de la confiance.
De la boîte noire opaque à la souveraineté structurelle — une échelle graduée avec des exigences minimales claires par domaine.
L0 — Boîte noire opaque§
Aucune transparence vérifiable. Structurellement inadapté aux charges critiques de souveraineté.
L0 signifie qu'aucun domaine d'évaluation n'atteint la transparence requise pour la souveraineté. Propriété, juridiction, sous-traitants et architecture technique ne sont ni documentés ni auditables de manière indépendante. Les leviers opérationnels sont hors de portée du client — toute intervention est impossible en cas de crise.
Profil type : services grand public non certifiés, dark SaaS, shadow IT, outils à structure fournisseur opaque. Des services certifiés peuvent aussi tomber en L0 s'ils documentent la sécurité mais pas la souveraineté.
Cas d'usage : aucun. L0 est explicitement un constat, pas un niveau recommandé — il signale la présence d'un risque structurel de souveraineté.
| Domaine | Exigence minimale |
|---|---|
| D1 | Propriété ou juridiction non documentée. |
| D2 | Accès et rôles de clés non transparents. |
| D3 | Stack fermé, pas de chemins de sortie documentés. |
| D4 | Chaîne d'approvisionnement largement inconnue. |
L1 — Socle de transparence§
Structurellement compréhensible, mais sans capacité d'intervention opérationnelle côté client.
L1 marque le socle de l'évaluation de souveraineté. Propriété, juridiction, sous-traitants, architecture et chaîne d'approvisionnement sont entièrement documentés et auditables de manière indépendante. Le client peut comprendre ce qu'il utilise — mais ne peut pas encore intervenir lui-même sur les leviers centraux.
Profil type : services d'hyperscalers certifiés à forte maturité technique mais sans contrôle structurel européen ; éditeurs SaaS établis avec documentation détaillée ; services européens matures en phase de construction de leurs fonctions de souveraineté.
Cas d'usage : charges non critiques, marketing, applications bureautiques générales, collaboration sur contenus non sensibles.
| Domaine | Exigence minimale |
|---|---|
| D1 | Propriété, juridiction, sous-traitants entièrement documentés. |
| D2 | Accès et rôles de clés entièrement décrits, consultation des journaux possible. |
| D3 | API et chemins d'export documentés, export des données en formats ouverts. |
| D4 | SBOM complet et chaîne matérielle ; points d'étranglement identifiés. |
L2 — Contrôle opérationnel§
Le client pilote lui-même les leviers opérationnels centraux — clés, accès, localisation, sortie.
L2 exige un contrôle opérationnel démontrable. La maîtrise des clés (p. ex. HYOK), la révocation d'accès côté client, une localisation des données opposable et un chemin de sortie documenté avec capacité de migration prouvée constituent les exigences minimales. Le client peut agir stratégiquement — pas seulement documenter.
Profil type : services UE souverains à l'architecture claire, fournisseurs européens à stack open source, offres cloud public régulées avec gestion de clés externe effective et référence de migration documentée.
Cas d'usage : fonctions soumises à NIS2 et DORA, dossier patient électronique, charges critiques sectorielles, applications standard du secteur public.
| Domaine | Exigence minimale |
|---|---|
| D1 | Règles d'accès aux données contractuellement sécurisées selon le droit UE ; droits de notification. |
| D2 | Maîtrise des clés (HYOK ou équivalent) ; révocation d'accès et localisation opposables. |
| D3 | Sortie démontrée dans un délai et un coût acceptables ; SBOM complet. |
| D4 | Sources diversifiées pour les composants critiques ; stratégie de substitution. |
L3 — Souveraineté structurelle§
Indépendance structurelle vis-à-vis de fournisseurs individuels et de juridictions extra-européennes.
L3 marque la souveraineté structurelle. Le service peut être changé sans perte de contrôle ni de continuité ; la chaîne technique et juridique est diversifiée et résiliente à l'échelle UE. La souveraineté n'est plus seulement une propriété du fournisseur, mais une propriété de l'ensemble du stack et de ses alternatives.
Profil type : architectures multi-cloud entièrement open source, fournisseurs spécialisés de niveau infrastructure critique avec leur propre stack, infrastructures numériques portées par l'État avec diversification documentée.
Cas d'usage : infrastructures critiques, administration sensible, applications proches du domaine défense, objectifs de protection de souveraineté les plus élevés.
| Domaine | Exigence minimale |
|---|---|
| D1 | Aucun droit d'accès extraterritorial ; indépendance structurelle UE. |
| D2 | Accès du fournisseur aux contenus techniquement exclu ; notarisation externe. |
| D3 | Stack majoritairement open source ; migration reproductible vers au moins deux cibles concurrentes. |
| D4 | Alternatives UE viables pour chaque composant critique. |
Quel niveau pour quel cas d'usage ?§
Les niveaux minimaux recommandés ci-dessous sont indicatifs — la détermination contraignante se fait par secteur via les objectifs de protection et les niveaux minimaux par domaine (voir Principe d'agrégation).
| Cas d'usage | Niveau minimal recommandé |
|---|---|
| CRM marketing, newsletters, portée externe sans analytics | L1 |
| Environnements bureautiques et collaboratifs sans données personnelles de catégorie particulière | L1 |
| Dossiers RH, systèmes RH généraux | L2 |
| Comptabilité financière, ERP | L2 |
| Services soumis à NIS2 (énergie, santé, transports) | L2 (D2 ≥ L2) |
| Fonctions essentielles du secteur financier soumises à DORA | L2 (D3 ≥ L2) |
| Dossier patient électronique (DPE) et hébergement | L2 (D2 ≥ L3) |
| Administrations traitant des informations classifiées (niveau VS-NfD) | L3 |
| Systèmes de pilotage d'infrastructures critiques | L3 |
| Administration sensible, applications proches du domaine défense | L3 sur tous les domaines |
