Souveraineté numérique ou semi-souveraineté : mesurer le contrôle réel

Souveraineté numérique : une promesse plus facile à déclarer qu'à démontrer

Dans le numérique, la souveraineté devrait d'abord renvoyer à une capacité concrète : décider, contrôler, auditer, maintenir, faire évoluer et remplacer un système sans qu'un acteur extérieur puisse imposer unilatéralement ses règles sur les fonctions critiques.

Cette définition est volontairement exigeante. Elle ne se limite ni à la localisation géographique d'un serveur, ni à la nationalité d'un prestataire, ni au lieu où une facture est émise. Une organisation peut héberger ses données en Europe, utiliser des outils présentés comme "de confiance", signer des contrats solides et rester malgré tout dépendante d'un éditeur étranger, d'un composant propriétaire, d'une chaîne de mise à jour non maîtrisée ou d'un service dont le fonctionnement interne échappe à tout audit réel.

La Commission européenne retient elle-même une approche multidimensionnelle. Son Cloud Sovereignty Framework distingue notamment la souveraineté stratégique, juridique et juridictionnelle, celle des données et de l'IA, la souveraineté opérationnelle, celle de la supply chain, la souveraineté technologique ainsi que la sécurité et la conformité. Autrement dit, l'hébergement n'est qu'une couche parmi d'autres.

C'est là que le terme semi-souveraineté devient utile comme outil de lecture. Il ne décrit pas une faiblesse honteuse. Il décrit une situation fréquente et beaucoup plus honnête : celle où l'on a repris une partie de la main, sans avoir repris toute la chaîne de contrôle.

Le problème n'est pas d'être partiellement souverain. Dans un système numérique mondialisé, c'est souvent la situation réelle. Le problème commence lorsqu'une maîtrise partielle est présentée comme une maîtrise totale.

Semi-souveraineté : nommer le contrôle partiel sans le maquiller

Parler de semi-souveraineté permet de sortir d'une opposition trop simple entre "souverain" et "non souverain". Une organisation peut disposer de garanties sérieuses sur certaines dimensions tout en conservant des dépendances importantes sur d'autres.

Elle peut maîtriser la localisation de ses données, mais dépendre d'un fournisseur unique pour les correctifs de sécurité. Elle peut exploiter une infrastructure européenne, tout en utilisant un hyperviseur, un firmware ou un service de gestion dont elle ne contrôle ni la feuille de route ni le code. Elle peut chiffrer ses données mais dépendre d'un composant propriétaire pour l'identité, la supervision ou la gestion des clés. Elle peut enfin disposer d'une excellente protection contractuelle tout en restant techniquement incapable de migrer dans un délai acceptable.

La semi-souveraineté ne signifie donc pas "presque souverain" au sens publicitaire. Elle signifie : voici précisément ce que je maîtrise, voici ce qui reste dépendant, voici ce que je peux auditer et voici ce que je ne peux pas encore remplacer.

Cette nuance est d'autant plus importante que les cadres publics récents vont eux-mêmes vers une évaluation graduée. Dans son guide d'implémentation du Cloud Sovereignty Framework publié en 2026, la Commission européenne distingue plusieurs niveaux, de l'absence de souveraineté à la "Full Digital Sovereignty". Entre les deux figurent notamment des niveaux de souveraineté des données et de souveraineté technologique qui admettent encore des dépendances ou une influence non européenne résiduelle.

Le vocabulaire officiel n'utilise pas "semi-souveraineté", mais l'idée de degrés de maîtrise est bien présente. Le débat n'est donc plus uniquement sémantique : il devient mesurable.

Boîtes noires, télémétrie et dépendances : là où la maîtrise se perd

Le numérique contemporain repose sur une accumulation de couches techniques que peu d'organisations maîtrisent intégralement. Il y a le matériel, les firmwares, le système d'exploitation, l'hyperviseur, les bibliothèques, les agents de supervision, les mécanismes de télémétrie, les connecteurs cloud, les dépendances tierces, les mises à jour automatiques, les services managés, les intégrations SaaS, les API, les composants embarqués et parfois des chaînes complètes de sous-traitance.

Chaque couche peut apporter de la puissance, de la rapidité ou de la sécurité. Mais chaque couche peut également ajouter une dépendance, une surface d'attaque, un risque de verrouillage ou une zone d'opacité.

Le point critique n'est donc pas seulement que ces couches existent. C'est qu'elles peuvent fonctionner comme des boîtes noires techniques ou organisationnelles. On sait ce qu'elles promettent, mais pas toujours ce qu'elles font exactement, quelles données elles collectent, où elles les transmettent, quels sous-traitants interviennent, quelles fonctions peuvent être modifiées à distance ou dans quelles conditions leur comportement peut évoluer.

La télémétrie illustre bien cette difficulté. Une collecte de métriques peut être parfaitement légitime pour détecter une panne, améliorer un service ou répondre à un incident. Mais si l'organisation ne sait pas quelles données partent, vers quelles destinations, avec quelle durée de conservation, pour quelles finalités et avec quelles possibilités de désactivation, elle ne dispose pas d'une maîtrise complète. Le problème n'est pas la télémétrie en soi, c'est la télémétrie non maîtrisée.

Même logique pour les mises à jour. Automatiser des correctifs peut réduire fortement le risque opérationnel. Mais si aucune procédure ne permet de différer, tester, auditer, revenir en arrière ou continuer à fonctionner en cas de rupture avec l'éditeur, l'organisation échange une partie de sa maîtrise contre de la commodité.

Dans ces conditions, parler de souveraineté sans nuance peut revenir à confondre l'intention de contrôle avec la capacité démontrée de contrôle.

L'open source améliore l'auditabilité, mais ne suffit pas à lui seul

Favoriser des solutions inspectables est une piste solide, mais il faut éviter une autre simplification : open source ne signifie pas automatiquement souverain.

Un logiciel ouvert peut dépendre de bibliothèques maintenues hors d'Europe, d'une forge étrangère, d'une chaîne de compilation difficilement reproductible, d'un matériel propriétaire, de services de signature ou de distribution externes, ou encore d'un petit nombre de mainteneurs difficiles à remplacer. À l'inverse, un composant propriétaire peut parfois offrir de bonnes garanties de réversibilité, de documentation, d'audit contractuel et d'autonomie opérationnelle.

L'ouverture du code est donc un levier important d'auditabilité, d'interopérabilité et de substituabilité, mais elle doit être examinée avec le reste de la chaîne : build, dépendances, clés, mises à jour, infrastructure, gouvernance, financement, compétences et supply chain.

Pourquoi le mot "souverain" engage techniquement et juridiquement

Le mot "souverain" possède une force politique et symbolique considérable. Il rassure, mobilise, donne une direction et peut signaler une volonté légitime de réduire des dépendances critiques. Mais il peut aussi masquer les zones grises.

Lorsqu'une solution repose sur un socle que l'on ne peut ni auditer complètement, ni maintenir durablement, ni modifier librement, ni remplacer dans des conditions réalistes, le qualificatif de souverain devient discutable. Cela ne signifie pas que la solution est mauvaise, dangereuse ou inutile. Cela signifie simplement que la promesse doit rester proportionnée au niveau de contrôle réellement démontré.

Ce n'est pas un détail sémantique. Le vocabulaire façonne les décisions d'architecture, d'achat et de sécurité.

Si l'on parle de souveraineté alors qu'il ne s'agit que d'une maîtrise partielle, on risque de sous-estimer les dépendances, de surestimer la résilience et de négliger le verrouillage fournisseur. On peut aussi confondre conformité, sécurité, localisation, nationalité et souveraineté, alors que ces notions se recoupent sans être équivalentes.

Une offre peut être très sécurisée sans être souveraine. Une solution peut être européenne sans être facilement réversible. Un produit open source peut être transparent mais dépendre d'une chaîne d'approvisionnement non maîtrisée. Un hébergement local peut rester vulnérable à des composants matériels ou logiciels dont la gouvernance échappe totalement à l'opérateur.

À l'inverse, assumer une semi-souveraineté permet de mettre les bons mots sur une réalité complexe et de construire une trajectoire : reprendre le contrôle par étapes plutôt que transformer un objectif en slogan.

La souveraineté numérique n'est pas binaire

Le numérique n'oppose pas proprement un monde souverain à un monde non souverain. Il existe plutôt un continuum de maîtrise, et les cadres européens récents rendent ce continuum de plus en plus explicite.

On peut être souverain sur l'hébergement mais dépendant sur l'observabilité. On peut être souverain sur les données mais pas sur le moteur applicatif. On peut être autonome sur une partie du système mais exposé sur la supply chain logicielle. On peut même disposer d'un cadre juridique protecteur tout en conservant des vulnérabilités techniques, opérationnelles ou industrielles majeures.

C'est précisément pour cela qu'il faut penser en niveaux et en dimensions, et non en autocollants.

Données et juridiction

La localisation des données compte, mais elle ne suffit pas. Il faut également savoir qui peut y accéder, sous quel droit, avec quelles clés, quels journaux d'accès et quels mécanismes de suppression. La souveraineté des données suppose donc une maîtrise juridique et technique.

Le Cloud Sovereignty Framework de la Commission européenne prend explicitement en compte l'exposition à des lois de pays tiers, le contrôle cryptographique, la localisation du traitement, l'auditabilité des accès et la capacité à garantir l'effacement.

Opérations, compétences et réversibilité

Une organisation réellement autonome doit pouvoir exploiter, maintenir et faire évoluer les fonctions critiques sans dépendre indéfiniment d'un acteur qu'elle ne contrôle pas. Cela suppose de la documentation, des compétences disponibles, des procédures de continuité et une stratégie de sortie réaliste.

La réversibilité ne consiste pas à inscrire une clause dans un contrat. Elle doit être testable. Peut-on exporter les données dans un format exploitable ? Reconstruire le service ailleurs ? Restaurer les fonctions essentielles ? Remplacer une API propriétaire ? Continuer à fonctionner si le fournisseur retire son support ou modifie son offre ?

Une réversibilité jamais testée reste une hypothèse.

Supply chain, code et infrastructure

La maîtrise doit également descendre dans la chaîne d'approvisionnement. Origine des composants, firmware, logiciels embarqués, dépendances de build, bibliothèques, outils de signature, prestataires de support, sous-traitants, processeurs, accélérateurs et équipements réseau peuvent tous créer des dépendances critiques.

C'est l'un des apports importants des cadres récents : ils obligent à regarder sous la couche visible du service. La Commission européenne indique explicitement que l'évaluation ne doit pas s'arrêter à l'entité juridique qui répond à un appel d'offres, mais doit examiner les sous-traitants, les fournisseurs et les différentes couches techniques afin d'identifier les dépendances cachées.

Ce que disent réellement l'ANSSI, le BSI et la Commission européenne

Les référentiels de confiance ne promettent pas une indépendance absolue du monde extérieur. Ils cherchent surtout à encadrer, mesurer et réduire les dépendances, à imposer des exigences vérifiables et à aider les organisations à prendre des décisions adaptées au risque.

Cette distinction est importante : un référentiel de sécurité ou de confiance n'est pas la preuve qu'un système maîtrise chaque couche de sa chaîne technologique.

ANSSI et BSI : la souveraineté passe par les dépendances réelles

Dans leur déclaration commune publiée le 17 novembre 2025, l'ANSSI et le BSI relient explicitement la souveraineté du cloud aux dépendances technologiques non européennes et aux risques associés en matière de confidentialité, de disponibilité et de contrôle des infrastructures.

Ce positionnement est plus exigeant qu'une simple logique de localisation. Il reconnaît qu'une dépendance peut rester structurante même lorsque les données sont stockées en Europe.

L'ANSSI adopte également une approche fondée sur le risque dans ses recommandations cloud. Pour les systèmes sensibles, elle insiste sur le choix d'offres adaptées à la criticité, sur la maîtrise des risques d'externalisation et sur les garanties associées à des offres qualifiées comme SecNumCloud lorsque le contexte l'exige.

Il faut toutefois conserver une distinction fondamentale : SecNumCloud est une qualification de sécurité et de confiance pour des offres cloud répondant à un référentiel précis. Ce n'est pas une preuve universelle de souveraineté de l'ensemble d'un système d'information.

C3A : transformer l'autonomie cloud en critères vérifiables

En avril 2026, le BSI a publié le cadre C3A, Criteria enabling Cloud Computing Autonomy. Son objectif est de permettre aux fournisseurs et aux clients cloud d'évaluer des critères d'autonomie et de souveraineté selon leur contexte de risque.

Le cadre couvre notamment des dimensions stratégiques, juridiques, opérationnelles, technologiques et de supply chain. Il cherche à rendre vérifiables des sujets qui étaient trop souvent traités comme des promesses commerciales : contrôle effectif, dépendance à des acteurs tiers, continuité d'exploitation, capacité de migration, disponibilité du code et de la documentation, ou encore autonomie de maintenance.

C3A n'est pas, en lui-même, une obligation générale imposée à tous les acteurs. C'est un cadre d'évaluation et de transparence. Cette nuance est essentielle, car elle confirme que la souveraineté utile n'est pas une étiquette uniforme : elle doit être appréciée par rapport à un usage, un niveau de risque et des critères démontrables.

La Commission européenne formalise elle-même plusieurs niveaux de souveraineté

Le point le plus intéressant pour le débat "souveraineté ou semi-souveraineté" se trouve peut-être dans le Cloud Sovereignty Framework de la Commission européenne.

Le document distingue plusieurs niveaux d'assurance, appelés SEAL, depuis l'absence de souveraineté jusqu'à la souveraineté numérique complète. Le niveau SEAL-2 admet encore des dépendances matérielles et un contrôle indirect d'acteurs non européens. Le niveau SEAL-3 décrit une situation dans laquelle les acteurs européens disposent d'une influence significative, mais non complète. Le niveau SEAL-4 correspond à une souveraineté numérique complète, avec technologie et opérations sous contrôle européen et sans dépendance critique non européenne.

Autrement dit, le cadre européen lui-même reconnaît qu'entre dépendance totale et maîtrise complète, il existe plusieurs états intermédiaires.

Plus révélateur encore, le guide d'implémentation publié en 2026 reconnaît une limite très concrète : le niveau le plus élevé, SEAL-4, n'est pas aujourd'hui pleinement adapté au contexte européen en raison de dépendances persistantes sur certaines chaînes d'approvisionnement, notamment les puces et le matériel.

Ce constat institutionnel mérite d'être pris au sérieux. Il ne signifie pas que la souveraineté européenne est impossible. Il signifie que la souveraineté complète ne peut pas être décrétée là où subsistent des dépendances critiques reconnues.

Dans cette perspective, "semi-souveraineté" n'est pas un terme officiel, mais il exprime assez bien une réalité que les cadres publics cherchent désormais à mesurer plus finement.

Le vrai sujet : la sincérité technologique

La question n'est pas de renoncer au mot souveraineté. Elle est de l'employer avec rigueur.

Dans un contexte où les infrastructures sont globalisées, où les dépendances sont nombreuses et où les chaînes logicielles et matérielles deviennent de plus en plus complexes, prétendre à une souveraineté totale sans expliciter le périmètre peut relever davantage de la communication que de l'ingénierie.

Dire "semi-souveraineté" n'est pas un aveu de faiblesse. C'est une façon de reconnaître que le contrôle est incomplet, qu'il doit être amélioré et que la maîtrise se conquiert couche après couche.

C'est aussi une manière de remettre de l'exigence dans le débat public. Car le vrai danger n'est pas de ne pas être totalement souverain. Le vrai danger, c'est de croire qu'on l'est alors qu'on ne maîtrise ni le code, ni les flux, ni les mécanismes invisibles qui gouvernent le système.

Cette sincérité technologique impose aussi d'accepter les contre-arguments. Une souveraineté absolue peut être économiquement irréaliste, techniquement inefficace ou même contre-productive si elle conduit à l'isolement, à la duplication systématique ou au refus de composants mieux sécurisés simplement parce qu'ils sont étrangers. L'objectif ne devrait donc pas être l'autarcie numérique.

La bonne question est plutôt : quelles dépendances sommes-nous prêts à accepter, lesquelles sont critiques, lesquelles peuvent être substituées, lesquelles doivent être auditées et lesquelles créent un risque disproportionné pour l'usage concerné ?

C'est une approche moins spectaculaire, mais plus utile.

Comment reprendre la main réellement

Si l'on veut avancer sérieusement vers davantage de souveraineté numérique, il faut accepter une méthode plus exigeante que le simple choix d'un fournisseur présenté comme souverain.

Il faut d'abord cartographier les dépendances. Pas uniquement les contrats directs, mais aussi les sous-traitants, bibliothèques, API, services de gestion, outils de supervision, composants matériels, mécanismes d'authentification, chaînes de mise à jour et dépendances de build.

Il faut ensuite identifier les boîtes noires. Quels composants ne peuvent pas être inspectés ? Quelles fonctions nécessitent une confiance aveugle dans le fournisseur ? Quels flux ne sont pas suffisamment documentés ? Quelles données quittent réellement le périmètre ?

Il faut également auditer les couches critiques et distinguer auditabilité théorique et auditabilité réelle. Avoir accès à du code ne garantit pas qu'il ait été relu. Disposer d'une documentation ne prouve pas que l'architecture déployée lui corresponde. Posséder un droit d'audit contractuel ne signifie pas qu'un audit technique complet ait été réalisé.

La télémétrie non nécessaire doit être limitée, les flux sortants maîtrisés, les fonctions de collecte documentées et les mécanismes de désactivation testés lorsque cela est possible.

La réversibilité doit devenir une propriété opérationnelle. Exporter, migrer, restaurer et reconstruire doivent être testés périodiquement. Une stratégie de sortie qui n'a jamais été exercée peut échouer précisément le jour où elle devient indispensable.

Les solutions inspectables, interopérables et fondées sur des standards ouverts doivent être privilégiées lorsqu'elles réduisent réellement le verrouillage. Mais leur chaîne de dépendances doit être examinée avec la même rigueur qu'un logiciel propriétaire.

Les garanties contractuelles restent nécessaires, mais elles doivent être complétées par des garanties techniques : maîtrise des clés, journalisation, capacité d'audit, contrôle des accès, limitation des privilèges, continuité de service, documentation, portabilité des données et compétences internes ou substituables.

Enfin, il faut accepter de publier ou de maintenir en interne une cartographie honnête du niveau de maîtrise : ce qui est contrôlé, ce qui est seulement encadré, ce qui dépend d'un tiers, ce qui peut être remplacé et ce qui constitue encore un point de dépendance critique.

C'est à ce prix que le mot souveraineté retrouve sa crédibilité. Sinon, il devient un habillage séduisant posé sur des architectures encore largement dépendantes.

La semi-souveraineté n'est donc pas un renoncement. Elle peut être le premier diagnostic honnête d'une stratégie de reconquête.

Souveraineté ou semi-souveraineté : parler vrai avant de promettre

Alors, faut-il parler de souveraineté ou de semi-souveraineté ? La réponse la plus rigoureuse est probablement : les deux, mais pas au même niveau.

La souveraineté peut rester l'objectif. La semi-souveraineté peut décrire l'état réel d'un système qui a déjà repris le contrôle de certaines couches mais dépend encore de composants, d'acteurs ou de juridictions extérieures pour d'autres fonctions critiques.

Cette position est d'ailleurs plus proche des cadres récents que ne le laisse penser le débat public. La Commission européenne mesure plusieurs niveaux d'assurance de souveraineté. Le BSI structure l'autonomie cloud en critères vérifiables. L'ANSSI et le BSI insistent sur les dépendances technologiques et le contrôle des infrastructures. Tous convergent vers une même idée : la souveraineté doit être démontrée par des propriétés observables, pas seulement affirmée par un discours.

Tant que nous ne maîtrisons pas le code critique, la télémétrie, les flux, les mises à jour, la réversibilité, les clés, les dépendances logicielles et matérielles ou les boîtes noires disséminées dans les différentes couches, il est plus sérieux de décrire précisément les limites du contrôle que de les masquer derrière un mot confortable.

La souveraineté numérique ne se proclame pas. Elle se documente, se teste, s'audite et se démontre.

Et tant que cette démonstration n'est pas complète, parler vrai reste probablement la première forme de souveraineté.