Souveraineté numérique : ce n'est pas où tourne votre cloud, c'est qui peut lire votre code

Décembre 2020. Dix-huit mille organisations découvrent que leur infrastructure a été compromise pendant neuf mois. Parmi elles : le Trésor américain, le Département d'État, des dizaines d'entreprises du Fortune 500. Aucune n'hébergeait ses données en Russie. Leurs serveurs étaient on-premise, dans des datacenters nationaux, dans des clouds certifiés. Tout était, sur le papier, souverain.

Le vecteur d'attaque ? Une mise à jour logicielle. Un fichier DLL dans un outil de monitoring réseau appelé SolarWinds Orion. Du code.

L'infrastructure était en ordre. Le code ne l'était pas.

Le mauvais débat

Depuis dix ans, la conversation sur la souveraineté numérique en France tourne autour d'une question : où sont vos serveurs ? Des milliards ont été investis dans des datacenters certifiés, des hébergeurs labellisés SecNumCloud, des infrastructures auditées par l'ANSSI. Tout ça est utile. Nécessaire, même.

Mais ça ne suffit pas.

Un datacenter certifié qui héberge un logiciel dont vous n'avez pas le code source, ce n'est pas votre propriété. C'est celle de l'éditeur, qui peut pousser une mise à jour ce soir, modifier ses conditions de service l'an prochain, décider de quitter le marché européen. Vous payez pour que vos données soient en France, tout en dépendant d'une chaîne logicielle sur laquelle vous n'avez aucune prise réelle.

La vraie question n'est pas géographique. C'est : si l'éditeur de votre système critique disparaît demain, que se passe-t-il ?

La boîte noire qui tourne depuis quinze ans

La plupart des systèmes critiques d'une organisation ne sont pas des logiciels récents sur un cloud moderne. Ce sont des applications construites il y a quinze ans, parfois vingt, par des équipes qui sont parties depuis, avec une documentation qui date d'une autre époque.

Ces systèmes tournent. Ils sont souvent fiables, justement parce que personne n'y touche. Mais quand personne n'y touche, c'est rarement par précaution. C'est parce que personne ne sait vraiment ce qui se passerait si on le faisait.

Posez trois questions à votre équipe sur chacun de ces systèmes : que fait exactement ce code, qui peut le modifier en cas de faille ou d'obligation réglementaire, et que se passe-t-il si le prestataire qui en a la clé ferme boutique ? Si les réponses sont floues, vous avez une dépendance. Peu importe où tournent les serveurs.

Cet écart entre ce que vous contrôlez formellement et ce que vous comprenez réellement, c'est ce qu'on appelle la dette de souveraineté. Dans la plupart des organisations que nous rencontrons, il est bien plus large qu'il n'y paraît.

Ce que NIS2 et DORA exigent vraiment

La directive NIS2, transposée en droit français fin 2024, impose aux entités essentielles une capacité d'audit, de traçabilité et de gestion des risques sur leurs systèmes d'information. Ce n'est pas une obligation de localisation. C'est une obligation de maîtrise.

Si votre infrastructure critique tourne sur un logiciel dont personne dans votre organisation ne peut lire le code de façon indépendante, vous serez en difficulté lors d'un audit NIS2. Pas pour une question de géographie, pour une question de contrôle.

DORA, pour le secteur financier, va plus loin encore : résilience opérationnelle prouvable, tests de pénétration réguliers, capacité à restaurer les fonctions critiques après un incident majeur. Tout ça suppose de comprendre vos systèmes, pas juste de savoir dans quel pays ils tournent.

Le régulateur ne vous demande pas où est votre cloud. Il vous demande si vous pouvez garantir la continuité, la traçabilité et la sécurité de ce que vous exploitez. C'est une question technique.

L'open source n'est pas une idéologie

L'open source est souvent présenté comme un choix politique ou une façon de faire des économies. C'est avant tout un outil de souveraineté opérationnelle.

Un logiciel open source peut être audité par une équipe indépendante. Il peut continuer à fonctionner si l'organisation qui le maintient disparaît ou change de cap. Il peut être adapté à des contraintes réglementaires précises sans attendre que l'éditeur décide de le faire. Et on peut le soumettre à un vrai audit de sécurité, pas un audit de surface.

C'est pour ça que GnuCOBOL, le compilateur COBOL open source que nous développons, est devenu le choix de la Direction Générale des Finances Publiques pour ses systèmes traitant 40,7 millions de contribuables. Pas parce que c'était moins cher qu'IBM COBOL. Parce que l'État français pouvait lire le code, vérifier son comportement et garantir sa continuité sans dépendre d'un éditeur américain dont les arbitrages commerciaux lui échappent complètement.

Ce n'est pas un choix militant. C'est un choix de gouvernance.

Le coût de la dépendance

Il y a une objection prévisible : la souveraineté réelle coûte plus cher. Comprendre les systèmes existants, adopter des solutions auditables, maintenir ces compétences en interne. C'est vrai que ça représente un investissement.

Mais le calcul doit inclure l'autre côté. Ce que coûte une dépendance quand elle se matérialise. Un éditeur qui double ses tarifs parce que vous n'avez aucune alternative. Un incident de sécurité sur un système que personne ne comprend vraiment. Un audit NIS2 ou DORA que vous ne pouvez pas passer parce que votre prestataire refuse de vous donner accès au code.

Les victimes de SolarWinds ont dépensé des centaines de millions de dollars pour gérer la crise. Leur infrastructure était, sur le papier, parfaitement en ordre.

Le vrai débat sur la souveraineté numérique n'est pas géographique. Il est technique. Et il commence par une question que peu d'organisations ont vraiment posée : qui comprend le code qui fait tourner vos systèmes critiques ?

Si vous n'êtes pas certain de la réponse, c'est là qu'il faut commencer.