La souveraineté numérique publique ne peut plus être réduite à la localisation d’un datacenter. Elle dépend de la maîtrise simultanée de la connectivité, du compute, de la donnée, de l’identité, de la cryptographie et des politiques de sécurité. Un État peut héberger ses données sur son territoire tout en restant dépendant d’un cœur de réseau externe, d’une IAM fragmentée, de clés mal maîtrisées, de registres administratifs non interopérables ou d’une PKI incapable de migrer vers le post-quantique.
L’architecture numérique souveraine cible ne repose pas sur une technologie isolée. Elle fait converger Private 5G SA et Network Slicing pour les communications critiques, SecNumCloud 3.2 et Confidential Computing pour la maîtrise juridique et la protection de la Data-in-Use, X-Road, OOTS et le principe Once-Only pour l’interopérabilité administrative, un LLM souverain RAG-first pour l’exploitation contrôlée des connaissances gouvernementales, et NIST SP 800-207 pour déplacer la confiance du réseau vers l’identité, le contexte et la ressource.
La transition doit également anticiper le risque Harvest Now, Decrypt Later par une stratégie crypto-agile basée progressivement sur ML-KEM, ML-DSA et un Cryptographic Bill of Materials. Sur trois ans, le programme doit être piloté par des indicateurs opérationnels : MTTD, MTTR, coût par service numérique, taux de réutilisation Once-Only, réduction du backlog administratif, exposition legacy, couverture Zero Trust et taux de migration cryptographique.
1. La souveraineté numérique est un système de contrôle, pas une localisation géographique
Un État peut héberger ses données sur son propre territoire et néanmoins ne pas maîtriser réellement son système numérique.
Il suffit que l’un des éléments suivants échappe au contrôle public :
- l’administration opérationnelle du Cloud ;
- les clés de chiffrement ;
- le cœur de réseau ;
- la politique d’identité ;
- les dépendances de supply chain ;
- les modèles d’IA ou leur télémétrie ;
- la couche d’interopérabilité ;
- les certificats et algorithmes cryptographiques à longue durée de vie.
2. Pilier 1 — Private 5G SA : transformer le réseau de l’État en infrastructure de mission
Le premier arbitrage ne doit pas opposer naïvement « 5G chère » et « Wi-Fi moins cher ».
Pour une infrastructure critique, le bon modèle compare :
TCO + couverture + mobilité + densité + SLA + coût de l’indisponibilité.
| Dimension | Private 5G SA | Wi-Fi 7 |
|---|---|---|
| CAPEX initial | Élevé | Faible à modéré |
| Core réseau | 5G Core dédié | Architecture WLAN/IP |
| Couverture grands sites | Très favorable | Densification AP plus forte |
| Mobilité | Handover natif | Plus dépendante du design radio |
| Identité device | SIM / eSIM | 802.1X / certificats / NAC |
| Isolation logique | Network Slicing / NPN | VLAN / VRF / segmentation |
| SLA critique | Très favorable | Plus difficile en environnement partagé |
| Cas naturel | Ports, aéroports, défense, utilities, logistique | Bâtiments administratifs, bureautique, indoor dense |
Sur un ministère tertiaire classique, Wi-Fi 7 peut rester économiquement supérieur.
Sur un port, un aéroport, un hôpital critique, une zone de défense ou une plateforme logistique, la Private 5G SA doit être évaluée comme une infrastructure opérationnelle.
2.1 Network Slicing : le réseau comme ensemble de contrats de service
La valeur stratégique de la 5G SA n’est pas son débit maximal. Elle réside dans la capacité à isoler et prioriser des classes de mission.
Les évolutions 3GPP Release 17 et Release 18 renforcent notamment les Non-Public Networks, les mécanismes de gestion de slices et l’assurance de leurs performances.
La chaîne opérationnelle doit devenir fermée :
2.2 MEC : garder le traitement critique près du terrain
Le principe consiste à localiser le User Plane et le compute au plus près du site lorsque la décision ne doit pas dépendre d’un aller-retour vers un datacenter national distant.
2.3 Open RAN : l’interopérabilité augmente les trust boundaries
Open RAN désagrège plusieurs composants auparavant plus intégrés :
O-RU O-DU O-CU Near-RT RIC Non-RT RIC xApps rApps A1 E2 O1 O2
Cette ouverture améliore le multi-vendor, mais multiplie les frontières techniques et la surface d’attaque.
Une xApp peut affecter le comportement radio. Elle doit donc être traitée comme un workload privilégié.
3. Pilier 2 — Cloud souverain : la localisation du serveur ne suffit pas
3.1 SecNumCloud 3.2 : faire converger sécurité technique et contrôle juridique
Un Cloud peut être physiquement situé en Europe tout en restant exposé à des dépendances juridiques, capitalistiques ou opérationnelles externes.
Le cadre SecNumCloud 3.2 intègre précisément cette dimension.
| Critère de contrôle | Exigence / principe |
|---|---|
| Participation individuelle d’une entité hors UE | Plafonnée dans le cadre de qualification |
| Participation collective hors UE | Encadrée |
| Droit de veto extra-européen | À éviter / proscrit selon les conditions applicables |
| Siège et contrôle | Architecture de gouvernance européenne |
| Accès aux clés | Doit être maîtrisé |
| Accès opérationnel | Personnel, consoles et chaînes de support sous contrôle |
3.2 Confidential Computing : sécuriser la Data-in-Use
Le chiffrement classique protège :
- la Data-at-Rest ;
- la Data-in-Transit.
Le Confidential Computing ajoute un troisième domaine :
la Data-in-Use.
AMD SEV-SNP
Isolation et chiffrement mémoire à l’échelle de la VM, avec réduction de la confiance accordée à l’hyperviseur.
Intel SGX
Isolation plus fine par enclave pour certains workloads et portions de code sensibles.
Une architecture gouvernementale mature doit coupler le TEE avec l’attestation distante.
Le simple accès à l’hyperviseur ne doit donc plus suffire à accéder aux données en traitement.
3.3 Lift & Shift : déplacer la dette technique dans le Cloud
Un rehost pur reproduit souvent les défauts du legacy :
Le Cloud est alors facturé comme une infrastructure moderne, mais exploité avec une architecture ancienne.
La stratégie doit partir d’une segmentation du portefeuille :
3.4 Rearchitect et FinOps
Pour les workloads qui le justifient :
- API-first ;
- microservices lorsque la granularité métier le justifie ;
- Kubernetes ;
- Infrastructure as Code ;
- CI/CD ;
- autoscaling ;
- observability ;
- rightsizing ;
- FinOps intégré à l’architecture.
Le KPI public ne doit pas se limiter au coût par vCPU.
Il faut également mesurer :
- coût par service citoyen ;
- coût par transaction ;
- coût par API ;
- coût par utilisateur actif ;
- coût de disponibilité ;
- taux réel d’extinction du legacy.
4. Pilier 3 — Data Fabric gouvernemental : appliquer le principe Once-Only sans créer une méga-base nationale
Le principe Once-Only ne signifie pas :
Il signifie :
Cela nécessite :
- purpose limitation ;
- IAM et ABAC ;
- minimisation ;
- auditabilité ;
- interopérabilité sémantique ;
- catalogue de preuves ;
- traçabilité du partage.
4.1 X-Road : échanger les données sans centraliser les registres
Chaque ministère conserve sa base métier. La couche X-Road porte principalement la confiance, la sécurisation de l’échange, l’identification, la journalisation et la preuve.
Ce modèle réduit le besoin de créer un repository gouvernemental universel.
4.2 OOTS : étendre le Once-Only au contexte européen
Le Once-Only Technical System ajoute notamment :
- Evidence Requesters ;
- Evidence Providers ;
- discovery ;
- eDelivery ;
- authentification eIDAS ;
- AS4 ;
- preview et approval lorsque requis.
5. IA gouvernementale souveraine : RAG-first, contrôle d’accès avant retrieval
Une architecture publique fragile serait :
La cible souveraine doit conserver l’ensemble de la chaîne sensible dans un environnement contrôlé.
5.1 Autorisation avant recherche documentaire
Le RAG gouvernemental doit respecter l’ordre :
L’authorization filter doit intervenir avant le retrieval.
Sinon, le modèle peut récupérer un document non autorisé avant même que la couche applicative ne bloque sa restitution.
5.2 RAG avant fine-tuning pour le droit et les procédures
Les lois, circulaires, formulaires, seuils et procédures évoluent.
Ils ne doivent pas être massivement figés dans les poids du modèle.
Le fine-tuning est plus pertinent pour :
- le style administratif ;
- la classification ;
- l’extraction structurée ;
- les comportements spécialisés ;
- la terminologie.
Pour la connaissance évolutive : RAG + corpus officiel versionné.
5.3 Federated Learning
Les données restent localement, mais les gradients ne doivent pas être considérés comme automatiquement anonymes.
Le programme doit étudier :
- Secure Aggregation ;
- Differential Privacy ;
- membership inference testing ;
- réidentification ;
- privacy budget.
6. eIDAS 2.0 et EUDI Wallet : passer de l’identité numérique à la divulgation minimale
Le Wallet EUDI ne doit pas être conçu comme une simple carte d’identité numérique affichée sur smartphone.
Il organise :
- issuers ;
- credentials ;
- wallets ;
- relying parties ;
- présentations ;
- selective disclosure ;
- assurance levels ;
- protocoles cryptographiques.
Son écosystème technique mobilise notamment :
OpenID4VP OpenID4VCI SD-JWT VC ISO mdoc W3C VC eIDAS 2.0
6.1 Selective disclosure
Les attributs inutiles ne sont pas présentés.
6.2 Zero-Knowledge Proof
7. Pilier 4 — Zero Trust : abolir la confiance implicite entre réseaux gouvernementaux
Le modèle historique :
doit être remplacé par :
Cette logique correspond au modèle NIST SP 800-207 Zero Trust Architecture.
7.1 PE / PA / PEP
Une architecture nationale doit rester fédérée : le niveau central définit les standards de confiance, mais chaque ministère conserve une capacité d’enforcement adaptée à ses propres ressources.
7.2 Software-Defined Perimeter
L’objectif n’est plus de donner accès à un réseau, mais à une ressource précise pour une durée et un contexte donnés.
7.3 NIS 2 : transformer la réglementation en contraintes de temps
| Étape | Fenêtre réglementaire |
|---|---|
| Early warning | 24 heures |
| Notification détaillée | 72 heures |
| Rapport final | 1 mois |
Cette contrainte impose une chaîne opérationnelle industrialisée :
Des objectifs de programme cohérents seraient :
- MTTD < 4 h pour les incidents critiques ;
- MTTR < 1 h sur les périmètres automatisables ;
- >70 % d’automatisation des tâches de tri et d’enrichissement compatibles ;
- <30 min pour générer un package technique d’early warning.
7.4 SBOM et supply-chain security
8. Cryptographie post-quantique : traiter aujourd’hui les secrets qui doivent encore l’être dans vingt ans
Le scénario Harvest Now, Decrypt Later est simple :
Pour une donnée nécessitant vingt ans de confidentialité, le risque commence donc aujourd’hui.
8.1 Les noms à utiliser dans les cahiers des charges
| Nom historique | Standard NIST | Fonction |
|---|---|---|
| CRYSTALS-Kyber | ML-KEM / FIPS 203 | Key establishment |
| CRYSTALS-Dilithium | ML-DSA / FIPS 204 | Digital signatures |
| SPHINCS+ | SLH-DSA / FIPS 205 | Hash-based signatures |
8.2 Commencer par un Cryptographic Bill of Materials
Avant de migrer, il faut savoir où se trouve la cryptographie.
- TLS ;
- VPN ;
- IPsec ;
- SSH ;
- PKI ;
- smart cards ;
- HSM ;
- firmware signing ;
- code signing ;
- S/MIME ;
- archives ;
- IoT ;
- 5G et Open RAN.
Le facteur décisif est la crypto-agilité : être capable de remplacer une primitive cryptographique sans refondre l’ensemble du système.
9. Matrice d’architecture souveraine
| Technologie | Enjeu souverain | Risque principal | Métrique de succès |
|---|---|---|---|
| Private 5G SA | Maîtrise de la connectivité critique | Core/RAN mal segmentés | Disponibilité, couverture, handover, coût/site |
| Network Slicing | Priorisation des missions | SLA non assuré end-to-end | SLA compliance par slice |
| Open RAN | Multi-vendor | xApps/rApps et supply chain | Workloads signés, mTLS, runtime alerts |
| MEC | Traitement local critique | Multiplication des Edge sites | Latency et autonomie WAN |
| SecNumCloud | Maîtrise juridique et opérationnelle | Extraterritorialité | % workloads sensibles qualifiés |
| Confidential Computing | Protection Data-in-Use | TEE / attestation compromise | % workloads critiques attestés |
| X-Road / OOTS | Interopérabilité distribuée | Droits excessifs | Transactions Once-Only |
| Sovereign LLM | Maîtrise des données IA | Leakage / unauthorized retrieval | Grounded answers / zero sensitive egress |
| EUDI Wallet | Identité décentralisée | Over-disclosure | Attributs minimaux par transaction |
| Zero Trust | Suppression de la confiance réseau implicite | Legacy bypass | % ressources critiques derrière PEP |
| SOC / SOAR | Réaction NIS 2 | Automatisation dangereuse | MTTD / MTTR / temps de preuve |
| PQC | Confidentialité longue durée | Legacy crypto | % actifs crypto inventoriés et migrés |
10. KPIs décisionnels sur 36 mois
| KPI | Cible de programme |
|---|---|
| MTTD cyber critique | <4 h |
| MTTR cyber critique | <1 h sur périmètres automatisables |
| Automatisation SOC | >70 % des tâches de tri/enrichissement compatibles |
| Génération package NIS 2 | <30 min |
| Backlog administratif ciblé | −30 à −60 % |
| Temps de recherche documentaire | −40 à −70 % |
| Validation documentaire assistée | −50 à −80 % |
| Formulaires simples automatisables | >70 % straight-through sur périmètres adaptés |
| Crypto assets critiques inventoriés | 100 % |
| Prompt sensible sortant du périmètre souverain | 0 |
| Workloads legacy réellement arrêtés après migration | >90 % des workloads concernés |
11. e-Estonia vs Virtual Singapore : deux modèles complémentaires
11.1 Estonie : distributed trust architecture
L’Estonie démontre la valeur d’une architecture où les registres restent distribués mais sont interopérables via une couche de confiance.
Les résultats régulièrement associés au modèle estonien comprennent :
- accès numérique généralisé aux services publics ;
- signature numérique massivement utilisée ;
- prescriptions électroniques ;
- administration paperless ;
- réutilisation des données via X-Road ;
- vote en ligne dans certains scrutins.
Le principal enseignement architectural est moins « numériser tous les formulaires » que :
11.2 Singapour : Government Platform Engineering
Singapour montre une autre logique : industrialiser les services publics comme une plateforme.
Les briques telles que MyInfo, les Government Tech Stacks et les infrastructures urbaines numériques réduisent le coût marginal de création d’un nouveau service.
Estonie
Force dominante : trust fabric, identité, interopérabilité distribuée.
Singapour
Force dominante : platform engineering, réutilisation et orchestration urbaine.
La meilleure architecture gouvernementale ne consiste pas à choisir entre les deux.
12. Roadmap d’un DSI gouvernemental : 0 à 36 mois
Mois 0–6 — Discover, classify, establish control
Télécoms
- cartographie des zones critiques ;
- RF survey ;
- TCO Private 5G vs Wi-Fi 7 ;
- définition des SLA ;
- architecture 5G Core.
Cloud
- inventaire des workloads ;
- classification des données ;
- Sovereign Landing Zone ;
- mapping des dépendances extraterritoriales ;
- baseline FinOps.
Cyber
- identification des High Value Assets ;
- IAM baseline ;
- phishing-resistant MFA ;
- Zero Trust target architecture ;
- CBOM initial.
Exit criterion : 100 % des actifs critiques identifiés, owners nommés et baseline opérationnelle établie.
Mois 6–12 — Construire les premières boucles souveraines
- pilote Private 5G sur un site critique ;
- local UPF / MEC lorsque nécessaire ;
- premiers workloads sur Cloud souverain ;
- Confidential Computing pilote ;
- X-Road / Once-Only entre 2–3 registres ;
- premier RAG souverain ;
- SDP/ZTNA pour administrateurs ;
- SIEM/SOAR et package NIS 2 industrialisé.
Exit criterion : première transaction Once-Only, premier workload IA sans data egress sensible et premier slice critique mesuré.
Mois 12–24 — Industrialiser
- Private 5G multi-sites ;
- Network Slicing ;
- Telco Cloud Zero Trust ;
- xApp/rApp admission control ;
- plateforme Kubernetes gouvernementale ;
- X-Road/OOTS ;
- intégration EUDI ;
- RAG multi-ministériel ;
- SOC/SOAR national ;
- microsegmentation ;
- premiers pilotes PQC hybrides.
KPIs : MTTD <4 h, MTTR critique <1 h, réduction mesurable des délais documentaires et diminution du footprint legacy.
Mois 24–36 — Passer de projets souverains à une architecture souveraine nationale
- slices critiques nationaux ;
- observabilité SLA de bout en bout ;
- multi-cloud gouverné ;
- extinction physique des workloads legacy ;
- Once-Only par défaut sur les procédures prioritaires ;
- Government AI Platform ;
- registry central des modèles ;
- continuous verification Zero Trust ;
- supplier telemetry ;
- CBOM automatisé ;
- migration PQC hybride des HVA.
13. Architecture de référence finale
14. La décision stratégique du DSI d’État
Le principal risque n’est pas de manquer une technologie.
Il est d’acheter toutes les technologies sans architecture commune.
Un État peut parfaitement déployer :
- une Private 5G ;
- un Cloud souverain ;
- un Data Lake ;
- un Wallet ;
- un SOC ;
- un assistant IA ;
- un programme PQC ;
et conserver malgré tout les mêmes silos structurels.
La vraie architecture souveraine ferme une seule chaîne :
La 5G transporte la mission.
Le Cloud fournit le compute sous contrôle juridique et opérationnel.
X-Road et OOTS transportent les preuves sans centraliser tous les registres.
L’EUDI Wallet transporte l’identité et uniquement les attributs nécessaires.
Le RAG permet à l’IA de travailler sur une connaissance autorisée, actuelle et traçable.
Zero Trust décide qui peut atteindre quelle ressource, depuis quel device, dans quel contexte et pour quelle durée.
Le SOC détecte la dérive. Le SOAR accélère l’investigation. NIS 2 impose que l’organisation puisse démontrer sa réaction.
La cryptographie post-quantique protège ce qui doit encore être secret lorsque RSA et ECC ne seront plus suffisants.
C’est cette convergence qui définit un véritable État numérique souverain, résilient et interopérable.
Pourquoi cette architecture concerne directement l’écosystème NEXUS
La transformation numérique de l’État traverse simultanément les télécommunications, le Cloud, la cybersécurité, l’intelligence artificielle, les infrastructures critiques, la mobilité, l’identité et la gouvernance des données.
Pour NEXUS TECH, les enjeux portent sur Private 5G, Edge/MEC, Cloud souverain, AI Platforms, Data Architecture, Zero Trust, SOC/SOAR et PQC.
Pour NEXUS MOTION, ils concernent les infrastructures de transport intelligentes, les ports, les aéroports, les réseaux critiques et la connectivité mission-critical.
Pour le NEXUS SUMMIT, la question devient stratégique : comment construire des infrastructures publiques qui restent performantes, interopérables et technologiquement maîtrisables pendant plusieurs décennies ?
NEXUS Expo & Summit · Tangier, Morocco · 11–15 November 2026.
Méthodologie et niveau de preuve
Cette étude synthétise le corpus de recherche technique préparé sur les architectures télécom 5G SA, Open RAN, Cloud souverain, SecNumCloud, Confidential Computing, interopérabilité gouvernementale, X-Road, eIDAS 2.0, EUDI Wallet, IA souveraine, NIST SP 800-207, NIS 2 et cryptographie post-quantique.
Les chiffres de marché, gains de productivité et benchmarks de cas publics doivent être interprétés selon leur périmètre exact. Une estimation institutionnelle, un pilote, une étude analyste et une obligation réglementaire ne constituent pas le même niveau de preuve.
Les objectifs MTTD, MTTR, automatisation, réduction de backlog ou optimisation Cloud présentés ici sont donc des cibles de programme à recalculer à partir de la baseline réelle de chaque administration.