La souveraineté numérique est une posture, pas un produit

Si la demande pour les offres estampillées souveraines est bien réelle, il existe un écart entre l’intention et l’exécution avec des plateformes vendues avec ce label sans livrer la chose. Et ce n'est pas un débat franco-français, ni même européen. Dès qu’une décision contractuelle ou géopolitique peut couper un service critique, la question de la dépendance se pose. Peu importe le drapeau.

L’intégration, ce piège très confortable

L’intégration n’est pas l’ennemi. Une plateforme bien intégrée fait gagner du temps et évite aux équipes de passer leurs journées à recoller des briques qui n’ont jamais été pensées pour cohabiter. Sur le papier, c’est exactement ce que cherchent les DSI. Le problème arrive quand cette intégration devient impossible à défaire. Quand les identités, les secrets, la supervision, la conformité et la distribution Kubernetes sont à ce point imbriqués qu’on ne peut plus en retirer un seul morceau sans faire vaciller le reste. À ce stade, la complexité n’a pas disparu. Elle est devenue moins visible. La dépendance ne s’installe d’ailleurs jamais frontalement : elle se niche dans les couches qu’on touche le moins, justement parce qu’elles sont au cœur de l’exploitation. Du coup, la bonne question n’est pas « est-ce que c’est bien intégré ? ». C’est « est-ce que je pourrai encore choisir demain ? ».

Le marché a compris que la souveraineté était devenue stratégique. Mécaniquement, elle est devenue marketing. On voit donc fleurir l’ouvert, le portable, l’hybride, le « basé sur l’open source ». Je vais être un peu cassant, parce que c’est le cœur du sujet : « basé sur l’open source » ne veut pas dire ouvert, et ouvert ne veut pas dire remplaçable. Un composant open source encapsulé dans une distribution propriétaire, avec un support qui saute dès que vous y touchez, ne vous a pas rendu libre. Il a juste changé la forme de votre dépendance. C’est ce que j’appelle le sovereign washing : reprendre le vocabulaire de la souveraineté sans livrer les propriétés techniques qui vont avec.

4 questions à poser avant de croire une promesse

On peut ramener la problématique à quatre questions. Difficiles à satisfaire, mais simples à poser.

1. Le code est-il vraiment auditable, dans la version qui tourne en prod ?

Pas « inspiré de », pas « basé sur ». La question n’est pas de savoir s’il y a de l’open source quelque part dans la chaîne, mais si je maîtrise ce que j’exécute réellement.

2. Les standards sont-ils ouverts ?

Pas seulement les composants : les interfaces, les formats, les API. Assez pour remplacer une brique sans faire tomber le reste. Pas forcément sans effort, mais sans chantage technique.

3. Puis-je l’exécuter là où j’en ai besoin ?

Sur site, en cloud privé, en edge, en environnement isolé, sans dépendre d’une autorisation permanente venue d’ailleurs. Avec l’IA et l’edge, ce point n’a plus rien de théorique : on ne veut plus seulement consommer un service, on veut décider où tournent ses modèles et ses données sensibles.

4. Quelle juridiction s’applique vraiment ?

Où sont les équipes de support, qui accède à quoi, quelle loi tranche le jour où ça se tend. Ce ne sont pas des questions agréables, mais elles sont nécessaires. D’autant qu’un répondant sur deux déclare qu’une entité étrangère a déjà enfreint ses règles de confidentialité ou de données, et près d’un quart parlent d’un incident majeur.

Au fond, mon test préféré tient en une phrase : que se passe-t-il si je veux partir ? Pas dans dix ans, pas dans le schéma idéal d’un slide. Sous pression budgétaire, après un rachat, sur une rupture de support ou un durcissement réglementaire. Est-ce que je peux remplacer un composant critique, déplacer mes workloads, conserver mes données, mes politiques et mes automatisations, sans renvoyer mes équipes à la case départ ? La souveraineté ne se mesure pas à l’entrée, au moment de signer. Elle se mesure à la sortie. Et non, une architecture souveraine n’est pas une architecture sans dépendances : ça n’existe pas. C’est une architecture où les dépendances sont choisies, comprises, documentées et réversibles. Une dépendance qu’on maîtrise, c’est un choix d’ingénieur. Une dépendance qu’on subit finit tôt ou tard en sujet de comité de direction.

Une dépendance numérique se rompt pour trois raisons : technique, juridique ou géopolitique. Le jour où votre continuité d'activité ne tient plus que sur un contrat, sans redondance, sans portabilité, sans solution de remplacement réelle, vous n'êtes pas souverain. Vous êtes dépendant, et le contrat ne fait que mettre des mots dessus.

Je ne vais pas prétendre que l’open source règle tout. Un projet sans gouvernance, sans support sérieux, sans écosystème, c’est un risque comme un autre. Mais il apporte quelque chose qu’aucun modèle fermé ne donne : la possibilité d’auditer, de comprendre, de contribuer, de forker si besoin, et de ne pas dépendre de la seule feuille de route d’un acteur unique. C’est pour cela qu’il est au centre de la résilience, et les chiffres le confirment : 94 % des décideurs interrogés jugent l’open source très ou extrêmement important pour leur résilience numérique. Le regard a changé. Pendant longtemps, on en parlait surtout en termes de coût ou de communauté. Aujourd’hui, on en parle en termes de continuité.

Beaucoup de solutions donnent un vrai sentiment d’autonomie. Tant que les prix ne bougent pas, que l’éditeur garde le même cap, que personne ne demande à remplacer une brique. Une autonomie qui ne fonctionne que quand tout va bien, ce n’est pas de la souveraineté. C’est du confort opérationnel. Le confort a de la valeur, et je ne le méprise pas. Il ne faut juste pas le confondre avec le contrôle. Ce déplacement, on commence à le voir dans les achats. 51 % des répondants intègrent désormais la souveraineté comme exigence au moment d’acheter de la technologie. Les acheteurs ne se contentent plus d’un discours rassurant : ils veulent savoir d’où vient le code, qui le gouverne, ce qui se passe si le client part, quelle juridiction s’applique. Ces questions doivent devenir banales. Pas idéologiques, pas agressives. Banales.

La souveraineté numérique n’est pas un produit. Ce n’est pas une option à cocher dans un catalogue, ni un label qu’on colle sur une plateforme pour rassurer un comité d’achat. C’est une posture d’architecture et de gouvernance, et elle tient à une question : est-ce que mon organisation garde la capacité de décider quand le contexte change ? Si la réponse est oui, on peut commencer à parler de souveraineté. Si elle est non, le niveau d’intégration, la qualité du packaging et la beauté de la promesse ne changent rien : on reste dans une dépendance. Très bien présentée, peut-être. Mais une dépendance.

C’est sans doute moins vendeur qu’un slogan. C’est beaucoup plus utile le jour où ça se complique.