Pourquoi cette mesure ?
La souveraineté numérique n’est pas un synonyme de fermeture technologique. Pour un État, elle désigne la capacité de choisir ses outils, de déplacer ses données, de changer de modèle ou de prestataire, de connaître les dépendances critiques et de continuer à fonctionner lorsqu’un fournisseur devient indisponible ou juridiquement problématique. La mesure 9.01 propose donc une architecture à cinq étages : données et référentiels ; infrastructure de calcul ; couche d’inférence et de modèles ; applications métiers ; gouvernance, audit et contrôle humain. Cette séparation oblige à distinguer ce qui doit être mutualisé de ce qui relève du métier de chaque administration. Elle évite également qu’un ministère achète simultanément une infrastructure, un modèle, une interface et un contrat captif alors qu’une partie de ces briques existe déjà ailleurs dans l’État.
État des lieux en 2026 : partir de ce qui existe vraiment
En 2026, l’État français ne part plus d’une page blanche. La DINUM opère Albert API, plateforme interministérielle d’inférence, et présente désormais un socle interministériel d’IA générative. Le plan gouvernemental annoncé en juin 2026 vise lui aussi à structurer une IA « utile, humaine et souveraine » pour les services publics. La proposition L’analyse doit donc être lue comme une doctrine d’architecture et d’extension : elle ne prétend pas inventer Albert, elle fixe les règles pour empêcher que la montée en charge recrée vingt architectures concurrentes. Le bon test n’est plus « avons-nous un chatbot public ? », mais « les briques sont-elles mutualisées, auditables, réversibles et compatibles avec les besoins de la Justice, de la fiscalité, de la santé ou des collectivités ? ».
Source au point d’usage : DINUM — IA dans l’État ↗
Concevoir, financer et sécuriser la mise en œuvre
Architecture, fonctionnement et conditions techniques
L’étage 1 regroupe les données, leurs catalogues, droits d’accès, durées de conservation et règles de qualité. L’étage 2 porte l’infrastructure : calcul, stockage, réseaux, chiffrement et environnements qualifiés. L’étage 3 fournit les modèles et services d’inférence, avec possibilité de faire évoluer les modèles sans réécrire chaque application. L’étage 4 contient les produits métiers : assistant d’agent, classement documentaire, détection d’anomalies, recherche juridique, etc. L’étage 5 impose gouvernance, journalisation, évaluation et contrôle humain. La règle de conception est simple : une dépendance métier ne doit jamais être cachée dans une couche technique impossible à remplacer. Chaque interface critique doit être documentée et testée.
Démonstration financière : séparer coût, capacité et économie
Aucun gain budgétaire autonome n’est attribué à l’architecture elle-même. Elle constitue une infrastructure et une méthode de déduplication. Si la DGFiP économise du temps grâce à un cas d’usage, ce gain appartient à 9.06 ; si une application réduit un coût de marché public, le résultat appartient à 9.14 ou à la mesure métier concernée. Comptabiliser une seconde fois la même économie sous 9.01 serait un double compte. Le suivi financier doit donc publier séparément le coût du socle mutualisé, les coûts évités par mutualisation et les gains réellement constatés dans les applications. Une architecture peut être économiquement rationnelle même si son propre poste budgétaire augmente, dès lors qu’elle remplace plusieurs dépenses redondantes et réduit les coûts de sortie.
Droit applicable et limites à ne pas franchir
La doctrine peut être mise en place en grande partie par gouvernance interministérielle, politique d’achat, référentiels de sécurité et contrats. Les aspects qui touchent aux droits des personnes, aux décisions automatisées ou à des obligations imposées aux administrations peuvent nécessiter des textes sectoriels ou la loi. Le règlement européen sur l’IA doit être intégré dès la conception, mais son calendrier doit être présenté correctement : le règlement 2026/1744 a notamment décalé au 2 décembre 2027 certaines obligations du chapitre III pour les systèmes à haut risque de l’annexe III. Ce report n’interdit évidemment pas à l’État d’appliquer plus tôt ses propres exigences internes de traçabilité et de supervision. [source]
Plans A, B et C : l’objectif survit au blocage d’une voie
adopter une doctrine interministérielle obligatoire, raccorder progressivement les ministères au socle commun et publier les exceptions.
si une obligation générale rencontre des blocages budgétaires ou techniques, commencer par les données les plus sensibles et les nouveaux projets, puis conditionner les nouveaux marchés à l’architecture cible.
si certaines administrations doivent conserver des infrastructures propres, exiger au minimum des interfaces documentées, un registre des dépendances et des tests de réversibilité. L’objectif est la maîtrise de l’architecture ; il ne dépend donc pas d’un fournisseur unique ni d’un vote législatif unique.
Risques, objections et garde-fous
Le principal risque est de transformer la souveraineté en monopole technique public mal dimensionné. Une plateforme commune ne doit pas devenir un point de panne unique ni une obligation d’utiliser un seul modèle. Autre risque : centraliser les données sous prétexte de mutualisation. L’architecture proposée doit au contraire permettre de garder les données au bon niveau, de réduire les mouvements inutiles et d’appliquer les principes de minimisation et de séparation des accès. Enfin, la souveraineté doit être mesurée : nombre de dépendances critiques, temps nécessaire pour changer de modèle, capacité à exporter les données et continuité réelle en cas d’indisponibilité.
Indicateurs, audit et preuve de réussite
Indicateurs : part des applications raccordées au socle ; nombre de modèles interchangeables ; part des données sensibles traitées dans les environnements autorisés ; délai de bascule vers un modèle de secours ; coût unitaire d’inférence ; nombre de développements redondants évités ; résultats des tests de réversibilité ; incidents de sécurité ; taux d’applications disposant d’une analyse juridique et d’un responsable métier identifié. Le tableau de bord doit séparer performance technique, sécurité, coût et qualité du service rendu.
Ce que l’architecture commune change concrètement dans un ministère
Une architecture commune ne retire pas aux ministères leur responsabilité métier. Elle change le point de départ des projets. Au lieu de demander à chaque direction de choisir séparément stockage, moteur d’inférence, modèle, journalisation et interface, le socle fournit des briques réutilisables avec des contrats d’interface connus.
Une direction de la Justice peut ainsi se concentrer sur la recherche juridique et les exigences de procédure, tandis qu’une direction fiscale se concentre sur le contrôle et le recouvrement. Le bénéfice principal est organisationnel : les équipes métiers cessent de reconstruire des fonctions techniques déjà disponibles et les équipes centrales cessent de dicter le contenu fonctionnel. Cette séparation doit être inscrite dans les responsabilités, les budgets et les critères d’acceptation des projets.
Cartographier les dépendances avant de parler de souveraineté
Le mot souveraineté n’a de valeur que s’il est associé à une cartographie vérifiable. Pour chaque service critique, il faut connaître le lieu d’hébergement, le propriétaire du modèle, les bibliothèques indispensables, les clés de chiffrement, les opérateurs disposant d’un accès privilégié, les formats d’export, les délais de remplacement et les contrats de support.
Cette cartographie doit aussi identifier les dépendances indirectes : un service hébergé en France peut rester captif d’un composant propriétaire ou d’un service d’authentification étranger. L’objectif n’est pas d’exiger que chaque composant soit français, mais de savoir quelles dépendances sont acceptables, lesquelles doivent être substituables et lesquelles constituent un risque critique. Une revue annuelle permet ensuite de mesurer réellement la réduction de ces dépendances.
Déployer par paliers plutôt que par grand soir informatique
Le déploiement peut être conduit en cinq paliers. Premier palier : inventaire des projets et de leurs dépendances. Deuxième : obligation pour tout nouveau projet de documenter ses interfaces, données et conditions de sortie. Troisième : raccordement volontaire des services simples au socle commun afin d’éprouver les performances et la facturation.
Quatrième : migration des services sensibles ou coûteux après tests de charge, de sécurité et de réversibilité. Cinquième : fermeture des doublons dont la fonction a été réellement reprise. Chaque palier possède un critère de sortie. Cette méthode évite de transformer la souveraineté en migration massive risquée et donne au Parlement comme aux administrations une chronologie vérifiable. Un service ne quitte son architecture historique que lorsque la continuité est démontrée.
Arbitrer entre mutualisation, résilience et liberté technologique
Mutualiser tout serait aussi dangereux que ne rien mutualiser. Certaines briques gagnent à être communes : registre des modèles autorisés, authentification, journalisation, catalogue de coûts, outils d’évaluation et standards d’interface. D’autres doivent rester distribuées : jeux de données métiers, règles de décision, choix de modèles spécialisés et capacité locale de continuer en mode dégradé.
La doctrine doit donc définir ce qui est obligatoire, ce qui est recommandé et ce qui relève de l’exception justifiée. Une exception n’est pas une faute : elle devient problématique lorsqu’elle n’est ni documentée ni réévaluée. Cette distinction protège à la fois la résilience et l’innovation, tout en évitant que la mutualisation se transforme en monopole technique interne impossible à contester.
Questions de contrôle avant de déclarer la mesure réussie
Cinq questions doivent être posées lors de chaque audit. Peut-on remplacer un modèle sans réécrire l’application ? Peut-on exporter les données et les journaux dans un format exploitable ? Une panne du socle dispose-t-elle d’un mode dégradé ?
Les coûts d’inférence et d’hébergement sont-ils comparables entre administrations ? Les responsables métiers savent-ils précisément quelles décisions restent humaines ? Une réponse négative n’implique pas nécessairement l’arrêt du projet, mais elle doit produire un plan correctif daté. Le succès de 9.01 ne se mesure donc ni au nombre de serveurs ni au nombre d’applications déclarées « souveraines ». Il se mesure à la capacité de l’État à comprendre, déplacer, auditer et maintenir ses services numériques critiques sans dépendance cachée.
Approfondissement opérationnel et conditions de réussite
Marchés publics et standards ouverts : rendre l’architecture réellement substituable
Une architecture souveraine n’est pas seulement une liste de briques hébergées en France. Elle doit pouvoir changer de fournisseur sans réécrire tout le système. Les cahiers des charges imposent donc des formats documentés, des interfaces exportables, l’accès aux journaux techniques et une description des dépendances indispensables. Les composants propriétaires restent possibles lorsqu’ils apportent une fonction utile, mais ils ne doivent pas rendre impossible le remplacement d’une couche. Le test pratique est simple : une autre équipe doit pouvoir reprendre les données, la configuration et les interfaces essentielles à partir de la documentation contractuelle. Cette exigence réduit le risque de dépendance commerciale et transforme la souveraineté en propriété vérifiable plutôt qu’en slogan.
Scénario de crise : continuer à servir l’État lorsqu’une brique devient indisponible
La résilience doit être testée avant l’incident. Pour chaque étage — données, modèles, inférence, services métiers et supervision — le dossier identifie une solution de continuité, le temps maximal acceptable d’interruption et les fonctions qui peuvent fonctionner en mode dégradé. Si un modèle externe devient inaccessible, les services essentiels doivent pouvoir basculer vers un modèle de secours pour les tâches autorisées. Si une plateforme d’inférence tombe, les traitements non urgents peuvent être différés mais les services critiques doivent conserver une voie minimale. Un exercice annuel documente le temps de bascule, les pertes de fonctionnalités et les coûts. La souveraineté se mesure ainsi à la capacité de continuer, pas seulement à l’adresse du centre de données.
Classer simultanément la sensibilité des données et la criticité du service
Deux systèmes utilisant des données comparables peuvent exiger des architectures différentes si l’un est une expérimentation interne et l’autre un service indispensable au fonctionnement quotidien d’une administration. La cartographie croise donc au moins deux axes : sensibilité des données et criticité du service. À cela s’ajoutent les besoins de disponibilité, de latence, de volume, de traçabilité et de réversibilité. Cette matrice évite d’imposer une architecture maximale à une application secondaire tout en sous-protégeant une fonction essentielle. Chaque nouvelle application justifie son niveau d’exigence et les écarts éventuels à la doctrine commune. Le résultat est revu lors d’un changement de finalité, d’un nouveau type de données ou d’un passage à l’échelle. La souveraineté devient ainsi proportionnée au risque réel et non appliquée comme une étiquette uniforme.
Séparer les identités, les droits d’accès et les journaux entre les cinq étages
Une architecture en couches n’est robuste que si une compromission locale ne donne pas automatiquement accès à tout le système. Les comptes de service, les droits d’administration et les secrets sont donc séparés autant que possible entre données, calcul, modèles, plateformes et applications. Les accès privilégiés sont nominatifs ou fortement traçables, les droits inutiles expirent et les changements de configuration sensibles sont journalisés. La supervision rapproche ensuite les journaux techniques et métier pour reconstituer un incident sans exposer inutilement le contenu des dossiers. Cette conception facilite aussi l’audit : on peut savoir quel composant a appelé quel modèle, avec quelle version et sous quelle autorisation. Une architecture souveraine doit être techniquement explicable après incident ; sinon la localisation nationale des serveurs ne suffit pas à garantir la maîtrise.
Construire un catalogue de composants autorisés sans figer l’innovation
La doctrine centrale publie un catalogue de composants et de configurations évalués : solutions d’hébergement, plateformes d’inférence, modèles, bibliothèques, mécanismes de journalisation ou services de sécurité. Ce catalogue accélère les projets récurrents, car chaque équipe n’a pas à réexaminer les mêmes questions depuis zéro. Mais il ne devient pas une liste fermée éternelle. Une procédure documentée permet de proposer une nouvelle solution, de la tester et de l’ajouter si elle apporte un gain de performance, de coût ou de souveraineté. Inversement, un composant peut être retiré si sa maintenance cesse ou si le risque devient excessif. Cette gouvernance évite que la standardisation se transforme en verrouillage technologique interne. Elle donne aussi aux acheteurs un référentiel commun pour comparer les offres et identifier les dérogations réellement nécessaires.
Relier architecture technique et compte économique de chaque service
Chaque couche génère un coût différent : stockage, calcul, licences éventuelles, réseau, personnel, support, sécurité et maintien des interfaces. Le compte économique rattache ces coûts aux services qui les consomment sans facturation artificielle destinée à créer une pseudo-économie. Une mutualisation est intéressante si le coût total partagé est inférieur à la somme des alternatives tout en maintenant les niveaux de service. Les investissements communs ne sont pas réattribués une deuxième fois comme économies dans chaque cas d’usage. Le tableau distingue coût fixe, coût variable, coût de transition et coût de sortie. Cette discipline permet d’arbitrer objectivement entre une plateforme partagée et une capacité locale. Elle rend également visible le moment où une couche centrale, créée pour économiser, deviendrait elle-même trop coûteuse ou trop lente.
IA publique souveraine : donner à chaque étage une responsabilité technique précise
Séparer données, calcul, modèles, outils et applications
Une architecture en cinq étages est utile si chaque couche possède des interfaces et responsabilités claires. Les données doivent être gouvernées indépendamment des modèles ; l’infrastructure de calcul doit pouvoir accueillir plusieurs modèles ; les outils communs de recherche, vectorisation ou classification ne doivent pas enfermer chaque ministère dans une application spécifique.
Cette séparation facilite la concurrence et la réversibilité : changer de modèle ne doit pas imposer de reconstruire tout le service.
Mutualiser ce qui est réellement commun
Albert API illustre l’intérêt d’une plateforme interministérielle d’inférence déjà utilisée par de nombreux projets. La mutualisation évite que chaque administration achète séparément des GPU, maintienne sa propre passerelle et reproduise les mêmes composants de sécurité.
En revanche, les données métiers, règles de décision et interfaces usagers restent souvent spécifiques. Le socle doit donc fournir des briques communes sans devenir un monolithe central.
Mesurer souveraineté et dépendance fournisseur
Le tableau annuel doit publier part des workloads sur infrastructures qualifiées, nombre de modèles interchangeables, capacité d’export des données et délai testé de bascule vers un autre fournisseur. La souveraineté devient ainsi une propriété mesurable plutôt qu’un label déclaratif.
Un exercice de réversibilité annuel peut révéler les dépendances avant une crise contractuelle.
Sources primaires et institutionnelles
Les affirmations de droit ou d’état de l’art ci-dessus sont rattachées à des sources publiques. Les hypothèses propres au Plan Delta-Sierra sont signalées comme propositions et ne sont pas présentées comme des chiffres officiels.
Date de vérification : 12 août 2026. Le cadre de l’IA évolue rapidement ; les dates d’application du règlement européen sont vérifiées contre le règlement (UE) 2026/1744.