Réarmer la souveraineté numérique : un plan quinquennal open source pour la France

Chapitre 1 : État des lieux - Inventaire national des capacités

1.1. Pourquoi un inventaire national ? La nécessité d'une photographie exacte

Avant de reconstruire, il faut savoir ce qui existe. La France dispose d'un patrimoine numérique dispersé mais substantiel : data centers universitaires, clusters de calcul, équipes SRE/DevOps, projets open source méconnus, compétences pointues dans des laboratoires isolés. Sans recensement systématique, nous pilotons à l'aveugle.

Les erreurs à éviter :

• Réinventer l'existant : des piles OpenStack tournent déjà dans 15+ universités, souvent ignorées des décideurs
• Sous-estimer les gaps : croire disposer de compétences MLOps alors que 80% des sites n'ont aucun ingénieur formé
• Surinvestir certaines zones : concentrer les moyens en Île-de-France alors que Grenoble ou Toulouse ont des capacités GPU sous-utilisées

L'inventaire en 90 jours constitue donc la pierre angulaire de tout le plan : c'est la carte qui permet de naviguer, la baseline qui permet de mesurer le progrès, et la preuve que nous construisons sur du solide plutôt que des promesses.

1.2. Méthodologie d'audit en 90 jours : rigueur et pragmatisme

L'inventaire national suit un processus structuré en phases successives, permettant une collecte systématique et une validation rigoureuse des données. Chaque phase a des livrables précis et des critères de passage (gates).

```mermaid gantt title Planning d'audit national (90 jours) dateFormat YYYY-MM-DD section Préparation Cadrage et charte :a1, 2025-01-01, 7d Liste des sites :a2, after a1, 3d section Collecte Formulaires standard :b1, after a2, 23d Scripts d'inventaire :b2, after a2, 23d Entretiens ciblés :b3, after b2, 7d section Contrôles Cohérence des données :c1, 2025-01-15, 30d Normalisation :c2, after c1, 15d section Scoring Évaluation maturité :d1, 2025-01-30, 30d Validation croisée :d2, after d1, 7d section Restitution Consolidation nationale :e1, 2025-02-28, 23d Cartes et tableaux :e2, after e1, 7d ```

Explication du processus (pédagogie) :

Phase 1 - Préparation (J0-J7) : On ne se lance pas tête baissée ! Les 7 premiers jours servent à :

• Rédiger la Charte d'audit : qui fait quoi, avec quels accès, quelle confidentialité (les sites ont peur de partager leurs faiblesses)
• Établir la liste exhaustive des sites : universités, IUT, écoles, labos CNRS/INRIA, opérateurs, ESN spécialisées
• Préparer les formulaires standardisés : mêmes questions pour tous, sinon impossible de comparer
• Constituer les équipes d'auditeurs : 1 coordinateur régional pour 5-10 sites, mix de profils tech/juridique

Phase 2 - Collecte (J7-J30) : C'est le cœur de l'audit. Pendant 23 jours :

• Chaque site remplit le formulaire standard (infrastructure, piles logicielles, RH, datasets, contrats)
• Des scripts d'inventaire tournent automatiquement pour capturer versions, capacités, configs (`k8s_info.sh`, `ceph_info.sh`, etc.)
• Les entretiens ciblés permettent de lever les ambiguïtés : "Vous dites avoir du Kubernetes, mais c'est quelle version ? Avec quels Operators ?"

Pourquoi c'est important : Sans preuves automatisées, on obtient du déclaratif biaisé. Les scripts forcent l'honnêteté.

Phase 3 - Contrôles (J15-J45) : Là, on vérifie que les données tiennent la route :

• Cohérence : si un site déclare 500 GPU, on croise avec ses contrats d'énergie (un GPU A100 consomme 400W)
• Complétude : manque-t-il des pièces jointes ? Les SBOM sont-elles présentes ? Les rapports DR datent de quand ?
• Normalisation : unifier les formats (certains parlent en To, d'autres en TiB), corriger les fautes de frappe dans les noms de logiciels

Phase 4 - Scoring (J30-J60) : On évalue la maturité de chaque site sur 5 domaines (voir section suivante). C'est crucial car ça permet de :

• Identifier les sites pilotes (maturité ≥4/5) qui peuvent devenir des Cloud Labs rapidement
• Repérer les quick wins : un site à 2/5 qui pourrait passer à 3/5 avec 3 mois d'efforts
• Détecter les gaps critiques : aucun site en France ne dépasse 2/5 en MLOps ? Problème stratégique !

Phase 5 - Restitution (J60-J90) : On produit les livrables finaux :

• Cartes nationales : heatmaps des capacités GPU, des clusters K8s prod, des HSM, etc.
• Tableaux de bord : capacités agrégées par région et par type d'entité
• Plan d'actions : 3-5 quick wins par site, besoins en compétences/financements

Résultat à J90 : nous savons exactement où sont les forces, où sont les trous, et comment prioriser les investissements. Plus d'approximations, que des faits.

1.3. Scores de maturité par domaine : une grille objective

La grille de scoring évalue chaque site sur 5 domaines clés (Infrastructure, PaaS, Sécurité, Données, IA/ML), permettant d'identifier les forces et les faiblesses de l'écosystème national. L'échelle va de 1 (initial/bricolage) à 5 (référence/industriel).

```json { "type": "radar", "metadata": { "title": "Scores de maturité moyens par domaine", "description": "Évaluation sur une échelle de 1 à 5 pour chaque domaine technique", "height": 450 }, "config": { "chartType": "radar", "palette": "energy" }, "data": { "labels": ["Infrastructure", "PaaS", "Sécurité", "Données", "IA/ML"], "datasets": [{ "label": "Score moyen national", "values": [3.2, 2.8, 3.5, 2.5, 2.1], "unit": "/5" }] } } ```

Analyse des résultats : L'infrastructure et la sécurité présentent les meilleurs niveaux de maturité (≥3/5), tandis que les domaines IA/ML et données nécessitent des investissements prioritaires. Cette photographie révèle un écosystème hétérogène avec des poches d'excellence à consolider.

Comprendre les scores (pédagogie par l'exemple) :

Infrastructure à 3.2/5 - Opérationnel mais fragile :

• ✅ Forces : des data centers existent, KVM/VMware déployés, réseaux 10-100 Gbps
• ⚠️ Faiblesses : PRA/PCA rarement testés, redondance limitée, PUE médiocres (>1.8)
• 📈 Pour passer à 4/5 : drills DR trimestriels, multi-AZ effectif, monitoring proactif

Sécurité à 3.5/5 - Le meilleur score, mais insuffisant pour du critique :

• ✅ Forces : PKI en place, firewalls L7, IAM basique
• ⚠️ Faiblesses : secrets souvent en clair dans Git, pas de Vault, journaux non immuables
• 📈 Pour passer à 4/5 : Vault déployé, rotation automatique, bastions Zero-Trust

IA/ML à 2.1/5 - Le point noir national :

• ⚠️ Problème majeur : GPU présents mais aucune pile MLOps structurée
• Constat : beaucoup de GPU A100/H100 tournent en "mode notebook Jupyter" sans traçabilité
• 📈 Plan d'urgence : 10 Cloud Labs avec Kubeflow/Ray en 12 mois, formation de 200 MLOps Engineers

Pourquoi ces scores comptent : un score de 2/5 en IA/ML signifie qu'on ne peut pas confier de workloads critiques (santé, défense, finance) sur ces piles. Le gap est stratégique, pas cosmétique.

1.4. Répartition des capacités GPU par région : déséquilibres criants

Les capacités de calcul haute performance sont inégalement réparties sur le territoire, avec une forte concentration en Île-de-France et Auvergne-Rhône-Alpes.

```json { "type": "bar", "metadata": { "title": "Capacités GPU par région (équivalent A100)", "description": "Nombre de GPU haute performance disponibles dans les Cloud Labs et centres de calcul", "height": 400 }, "config": { "chartType": "bar", "palette": "corporate" }, "data": { "labels": ["Île-de-France", "Auvergne-RA", "Occitanie", "Hauts-de-France", "PACA", "Grand Est", "Bretagne", "Autre"], "datasets": [{ "label": "GPU équivalent A100", "values": [450, 320, 180, 145, 130, 95, 75, 105], "unit": "" }] } } ```

Lecture pédagogique du graphique :

Constat 1 - Hyper-concentration parisienne : L'Île-de-France capte 450 GPU (30% du total), principalement à Paris-Saclay (INRIA, CEA, Télécom Paris). C'est 3 fois plus que la Bretagne. Problème : si on veut former 2000 étudiants/an en MLOps, on ne peut pas tous les envoyer à Paris.

Constat 2 - Auvergne-Rhône-Alpes en force : Grenoble (CEA/Leti, INRIA) + Lyon (INSA) = 320 GPU. C'est le deuxième pôle national, avec une excellence en calcul scientifique et HPC. Opportunité : en faire un hub MLOps référence pour le Sud-Est.

Constat 3 - Occitanie sous-exploitée : Toulouse (IRT Saint-Exupéry, ISAE, Airbus) n'a que 180 GPU alors que la filière aéronautique explose en IA embarquée. Gap stratégique : il faut doubler la capacité GPU toulousaine d'ici 2 ans.

Constat 4 - Déserts relatifs : Grand Est (95), Bretagne (75) et "Autre" (Centre-Val de Loire, Bourgogne, etc.) sont en retard. Risque : creuser les inégalités territoriales, perdre des talents locaux qui partent à Paris/Lyon.

Plan d'action 5 ans :

• Année 1-2 : renforcer les 3 premiers pôles (IDF, ARA, Occitanie) → atteindre 1200 GPU
• Année 3-4 : équiper systématiquement chaque Cloud Lab de 30-50 GPU minimum
• Année 5 : viser 2000+ GPU nationaux, répartis sur 20+ sites, avec un ratio max 1:3 entre région la mieux dotée et la moins dotée

Chapitre 2 : Architecture de gouvernance - Qui décide quoi, et comment

2.1. Le problème de la dispersion : pourquoi nous échouons depuis 20 ans

La France a multiplié les initiatives cloud souverain depuis les années 2000 : Andromède (échec 2012), Cloudwatt/Numergy (échec 2015), divers projets universitaires isolés. Diagnostic commun : absence de gouvernance coordonnée.

Les erreurs récurrentes :

• Silos académie/industrie : les universités font de la recherche ignorée par les opérateurs, qui eux-mêmes n'ont aucun retour terrain
• Multiplicité de piles incompatibles : chaque labo invente sa solution, aucune interopérabilité
• Pas de standard de qualité : des "POC" sont présentés comme des solutions industrielles alors qu'ils plantent tous les 15 jours
• Financement en stop-and-go : 50M€ ici, 30M€ là, jamais de vision long terme, donc incapacité à recruter/retenir

Ce qui doit changer : une gouvernance permanente, multi-niveaux (national ↔ régional), multi-acteurs (État, académie, industrie), avec des règles claires et un pilotage par KPIs.

2.2. Organisation de l'Alliance Recherche-Entreprise (ARE) : un dispositif inédit

La gouvernance multi-niveaux garantit la cohérence nationale tout en respectant l'autonomie régionale des Cloud Labs. C'est une "fédération", pas un mammouth centralisé.

```mermaid graph TD A[Comité de Pilotage National] --> B[Direction de Programme] A --> C[Comité Scientifique & Technique] A --> D[Comité Standards & Conformité]

B --> E[Product Board IaaS] B --> F[Product Board PaaS] B --> G[Product Board Data] B --> H[Product Board Sécurité] B --> I[Product Board IA/ML]

E --> J[Bureau Régional IDF] F --> J G --> J

E --> K[Bureau Régional ARA] F --> K H --> K

J --> L[Cloud Lab Paris-Saclay] J --> M[Cloud Lab Sorbonne] K --> N[Cloud Lab Grenoble] K --> O[Cloud Lab Lyon]

L --> P[Projets étudiants] M --> P N --> P O --> P

style A fill:#0a2240,color:#fff style B fill:#3498db,color:#fff style C fill:#51cf66,color:#000 style D fill:#ffa94d,color:#000 ```

2.3. Processus d'industrialisation (Stage-Gate)

Le pa…