« On passe à Linux. » « On part sur du logiciel libre. » Ces phrases reviennent dès qu’un comité aborde la souveraineté logicielle, et elles s’énoncent avec le ton de l’évidence, comme si le code ouvert réglait la question par sa seule nature. Il en règle une partie. Il en laisse une autre intacte, et parfois il déplace le problème sans le résoudre. La souveraineté ne se joue pas sur l’opposition entre propriétaire et libre. Elle se joue couche par couche : qui tient quoi, et peut-on en sortir.

Ce que l’open source garantit réellement

Le logiciel libre repose sur quatre libertés, formalisées par la Free Software Foundation : exécuter le programme pour n’importe quel usage, étudier son fonctionnement, le redistribuer, et le modifier puis diffuser les versions modifiées. L’open source, défini par l’Open Source Initiative, recouvre un périmètre proche. Ces libertés ne sont pas théoriques. Elles produisent trois propriétés concrètes.

L’auditabilité d’abord. Le code source est lisible, donc vérifiable. Une organisation qui le souhaite peut faire examiner ce qu’un logiciel exécute réellement, sans s’en remettre à la parole de l’éditeur. Pour un secteur réglementé, cette transparence a une valeur de preuve.

L’absence de licence révocable ensuite. Une licence libre, GPL, Apache, MIT, ne s’éteint pas sur décision unilatérale. L’éditeur ne peut pas couper l’accès à une version déjà obtenue, ni en interdire l’usage du jour au lendemain. La continuité ne dépend pas du bon vouloir d’un tiers.

La possibilité de fork enfin. Si le projet change de cap, ferme, ou tombe entre des mains hostiles, le code reste disponible et quelqu’un peut en reprendre le développement. La communauté de maintenance, quand elle existe, répartit cette charge entre plusieurs contributeurs et plusieurs organisations.

Ce qu’il ne garantit pas

Aucune de ces libertés n’est un service. Le code ouvert ne vient avec ni support, ni garantie de correction, ni feuille de route. La liberté de modifier ne vaut que pour qui sait modifier, et la liberté d’auditer ne vaut que pour qui en a les moyens. Lire le source d’un noyau, d’un hyperviseur ou d’une base de données pour s’assurer qu’il ne contient pas de faille suppose des compétences rares et un investissement continu. Le code disponible n’est pas le code audité.

La sécurité suit la même logique. Un logiciel libre n’est pas sûr parce qu’il est ouvert ; il est sûr quand des gens compétents le lisent, le testent et le corrigent dans la durée. L’épisode de la faille critique de log4j en 2021, brique présente dans d’innombrables systèmes et maintenue par une poignée de bénévoles, a rappelé qu’un composant ouvert et omniprésent peut rester sous-financé et sous-surveillé. L’ouverture rend l’audit possible, elle ne le réalise pas.

Surtout, l’open source ne dit rien de l’infrastructure. Un logiciel libre s’exécute toujours quelque part, sur des machines, dans un réseau, sous une juridiction. La licence du code et le rattachement juridique de l’hébergeur sont deux questions distinctes, et la première ne répond jamais à la seconde.

Les cas où l’OSS change vraiment quelque chose

Le logiciel libre pèse sur la souveraineté quand il agit sur les bons leviers. Trois situations le montrent.

Le déploiement local. Un logiciel libre installé sur une infrastructure que l’organisation maîtrise élimine la dépendance à un fournisseur de service distant. Le code est sur place, sous un droit choisi, sans appel sortant vers un tiers. C’est le cas qui se rapproche le plus de l’indépendance réelle.

L’auditabilité réglementaire. Pour une autorité de santé, une banque, un opérateur d’importance vitale, pouvoir produire le code exact qui traite des données sensibles n’est pas un confort, c’est parfois une obligation. Un composant propriétaire scellé interdit cette preuve ; un composant ouvert la permet.

L’absence de licence révocable. Un service propriétaire critique peut voir ses conditions changer, son prix monter, son accès se couper sur décision d’un éditeur ou sous l’effet d’une mesure d’extraterritorialité. La licence libre soustrait à ce risque la couche logicielle elle-même. Elle ne soustrait pas le reste.

Les cas où ça ne change rien

À l’inverse, l’étiquette « open source » n’apporte aucune garantie de souveraineté dans plusieurs configurations courantes.

Le logiciel libre déployé chez un tiers. Une base de données ou un orchestrateur libre opéré comme service managé sur une infrastructure étrangère relève du droit de cet opérateur, exactement comme un produit propriétaire. Le code est ouvert, la dépendance demeure entière. La nature de la licence ne change rien au rattachement juridique de celui qui exploite la machine.

La dépendance à des composants propriétaires. Un système d’exploitation libre qui ne démarre qu’avec des pilotes propriétaires, des microcodes signés ou un firmware fermé n’est pas autonome. La couche visible est ouverte, mais elle s’appuie sur des briques qu’on ne peut ni lire, ni reproduire, ni remplacer. La liberté s’arrête à la première pièce scellée du matériel.

L’absence de capacité de maintenance interne. La liberté de forker un noyau critique ne vaut que pour qui peut effectivement le maintenir. Une entreprise très réglementée ou un acteur de défense qui n’a pas l’ingénierie pour reprendre le développement d’un OS dont l’éditeur se retire se retrouve dépendant d’un prestataire, ouvert ou non. Le droit de modifier ne crée pas la capacité de modifier.

Dans ces trois cas, la propriété qui comptait, la maîtrise de la couche et la possibilité d’en sortir, n’est pas assurée par la licence. Elle dépend d’où le logiciel tourne, de ce sur quoi il s’appuie, et de qui sait le tenir.

La bonne question ne porte donc jamais sur l’étiquette. Elle se pose couche par couche, du matériel au service : qui contrôle celle-ci, sous quel droit, et qu’advient-il le jour où ce contrôle se referme. Le logiciel libre déplace certaines de ces réponses dans le bon sens. Il n’écrit pas les autres à votre place.

L’État français a tranché, et ça change l’échelle

Le débat a quitté les forums. En 2026, la direction interministérielle du numérique, la DINUM, demande à chaque ministère un plan de réduction des dépendances numériques extra-européennes. Le périmètre est large: postes de travail, outils collaboratifs, antivirus, intelligence artificielle, bases de données, virtualisation, équipements réseau. La bascule du système d’exploitation, de Windows vers Linux, n’est que la couche la plus visible d’un chantier plus profond.

Autour de l’OS, l’État pousse sa propre pile: Tchap pour la messagerie, Visio pour la visioconférence, FranceTransfert pour les fichiers, regroupés dans la Suite numérique. L’Assurance maladie a déjà migré 80 000 agents vers ces outils. La cible affichée dépasse deux millions d’agents d’ici 2027. Le déclencheur n’est pas un caprice technique. Le retour des tensions commerciales en 2025 a réveillé la question de la juridiction, et celle du CLOUD Act est devenue trop visible pour être ignorée.

La gendarmerie l’a fait il y a vingt ans

La nouveauté, c’est l’ampleur, pas le principe. La Gendarmerie nationale tourne sous Linux depuis 2008, avec GendBuntu, une version d’Ubuntu taillée maison. En juin 2024, elle équipait 103 164 postes, soit 97 pour cent du parc. L’économie est nette: environ deux millions d’euros par an de licences en moins, et un coût de possession réduit d’environ 40 pour cent.

Le détail qui compte n’est pas le chiffre, c’est la méthode. La gendarmerie n’a pas basculé d’un coup. Elle a commencé dès 2004 par des briques sans douleur, le navigateur, la suite bureautique, la messagerie, le temps que les compétences internes et la gouvernance se construisent. L’OS est venu en dernier, sur un terrain préparé. En 2026, la DINUM cite explicitement ce modèle comme la marche à suivre pour les autres ministères. La souveraineté logicielle ne s’achète pas, elle se monte, couche par couche, sur des années.

Ouvert ne veut pas dire sûr

Reste un piège, et c’est exactement celui que cet article pointe depuis le début. Choisir Linux et l’open source retire une dépendance. Ça n’offre pas la sécurité en cadeau. Un outil souverain n’est pas un outil sûr par construction. Il faut encore l’auditer, le durcir, le maintenir, avec autant de rigueur que pour n’importe quel logiciel propriétaire, parfois davantage puisque la responsabilité ne se sous-traite plus à un éditeur.

La messagerie de l’État l’a appris à ses dépens, en découvrant que l’origine française et le code ouvert ne dispensaient jamais du travail de sécurisation. C’est même l’inverse: la liberté de regarder sous le capot impose le devoir de le faire. L’open source rend la sécurité vérifiable, il ne la garantit pas. Qui ne vérifie pas hérite d’une dépendance qu’il croyait avoir levée, avec en prime l’illusion d’être protégé.

C’est tout le sens de « ne suffit pas ». Linux est une condition, pas une réponse. La réponse tient dans ce qu’on fait de la liberté qu’il rend possible: la compétence qu’on garde, les couches qu’on contrôle vraiment, et la sécurité qu’on assume au lieu de la déléguer.

Sources