« 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.
Sources
- Free Software Foundation, définition du logiciel libre, gnu.org
- Open Source Initiative, Open Source Definition, opensource.org
- Apache Software Foundation, vulnérabilité Log4Shell (CVE-2021-44228), décembre 2021
- ANSSI, recommandations sur la sécurité des socles logiciels, cyber.gouv.fr