Licences qui changent, petites bibliothèques sous-financées, dépendances invisibles : l’Europe découvre que le code ouvert ne suffit pas, à lui seul, à garantir sa souveraineté numérique.
Pendant plus d’une décennie, l’Europe a principalement cherché à affirmer sa souveraineté numérique par le droit. RGPD, DMA, DSA, AI Act : le continent est devenu une puissance normative, capable d’imposer certaines de ses règles bien au-delà de ses frontières.
Le retour de Donald Trump à la Maison-Blanche et la perspective de tensions commerciales et technologiques durables ont toutefois rappelé une réalité plus matérielle : une règle européenne ne suffit pas à garantir l’accès à un cloud, à un logiciel stratégique ou à une infrastructure contrôlée depuis l’étranger.
Face à cette vulnérabilité, l’open source apparaît de plus en plus comme une composante essentielle de l’autonomie numérique européenne.
Le paquet sur la souveraineté technologique présenté par la Commission européenne le 3 juin 2026 le confirme. Pour la première fois à ce niveau, le logiciel libre et open source est placé au centre d’une stratégie visant à renforcer la résilience, la compétitivité et l’autonomie technologique du continent.
Le signal politique est important. Lorsqu’un logiciel peut être étudié, modifié, réutilisé et maintenu par plusieurs acteurs, la dépendance à un fournisseur unique diminue.
Mais cette ouverture ne constitue pas, à elle seule, une garantie de souveraineté.
Le bouclier peut se fissurer au moment même où l’Europe décide de s’y abriter.
L’histoire récente de Terraform en offre une illustration.
Cet outil d’Infrastructure as Code est utilisé pour décrire, déployer et administrer des infrastructures cloud. Pendant plusieurs années, Terraform a été distribué sous licence libre Mozilla Public License 2.0. Des entreprises, des prestataires et des équipes informatiques ont organisé une partie de leurs opérations autour de cet écosystème.
En août 2023, HashiCorp a annoncé que les futures versions de plusieurs de ses produits, dont Terraform, seraient publiées sous Business Source License. Le code restait accessible et de nombreux usages demeuraient autorisés, mais la nouvelle licence introduisait des restrictions commerciales incompatibles avec les principes habituels de l’open source.
Cette décision était juridiquement possible et pouvait se comprendre du point de vue économique de l’entreprise. Elle a néanmoins révélé une faiblesse structurelle : un projet peut être perçu pendant des années comme une infrastructure ouverte, tout en restant dépendant des décisions stratégiques de l’entreprise qui en contrôle les nouvelles versions.
La communauté a réagi en créant OpenTofu, à partir de la dernière version encore publiée sous licence libre. Le projet a ensuite rejoint la Linux Foundation et constitue aujourd’hui une alternative open source placée sous une gouvernance plus neutre.
Cette réaction montre toute la force du modèle ouvert. Lorsque le droit de copier et de modifier le code a été garanti, un fork peut préserver la continuité du projet.
Mais un fork n’efface pas la rupture. Il faut constituer une nouvelle gouvernance, reprendre la maintenance, rassurer les utilisateurs, tester les compatibilités et mobiliser des financements. La possibilité technique de reprendre un logiciel est indispensable. La capacité humaine et économique de le faire l’est tout autant.
Le problème n’est donc pas d’opposer les entreprises aux fondations. Les entreprises ont besoin de modèles économiques viables, et l’open source ne signifie pas que tout travail devrait être fourni gratuitement.
La question est plus fondamentale : sur quelles garanties une organisation peut-elle s’appuyer lorsqu’elle choisit une brique logicielle pour les dix ou quinze prochaines années ?
La souveraineté ne consiste pas seulement à pouvoir consulter ou copier du code. Elle suppose aussi de savoir qui le maintient, qui le finance, qui décide de son évolution et qui sera encore présent lorsque la prochaine faille devra être corrigée.
L’Europe utilise massivement l’open source, le recommande et commence à mieux reconnaître son importance stratégique. Mais elle ne participe pas encore suffisamment à la gouvernance et au financement de toutes les briques dont dépendent ses administrations, ses entreprises et ses infrastructures critiques.
Cette fragilité ne concerne d’ailleurs pas uniquement les grands projets.
Derrière les systèmes les plus visibles se trouvent des milliers de petites bibliothèques, parfois maintenues par une seule personne. Elles assurent la compatibilité entre logiciels, le traitement de formats de données, la compression, la journalisation, la sécurité ou l’authentification.
Leur nom est rarement connu des dirigeants ou des responsables politiques. Leur code peut pourtant se retrouver, directement ou indirectement, dans des millions d’applications.
Core-js en constitue un exemple révélateur.
Cette bibliothèque fournit des mécanismes de compatibilité permettant d’utiliser des fonctionnalités modernes de JavaScript dans des environnements plus anciens. Elle intervient souvent indirectement dans les chaînes de développement et peut être présente dans un projet sans que ses utilisateurs en connaissent l’existence.
Pendant des années, son développement a reposé en grande partie sur le travail d’un seul mainteneur, alors même que la bibliothèque était téléchargée plusieurs dizaines de millions de fois par semaine et utilisée par un très grand nombre de projets.
Cette situation illustre un paradoxe central de l’économie numérique : un composant peut créer une valeur considérable pour des milliers d’entreprises sans que cette valeur se traduise par des moyens suffisants pour la personne qui l’entretient.
L’exemple n’est pas européen au sens géographique. Il concerne toutefois directement l’Europe dès lors que ses entreprises, ses administrations ou ses prestataires utilisent ces composants. La souveraineté numérique européenne dépend aussi de la capacité du continent à identifier et à soutenir les communs mondiaux sur lesquels reposent ses propres systèmes.
L’affaire XZ Utils, découverte en mars 2024, a montré le versant sécuritaire de cette fragilité. Une bibliothèque de compression largement intégrée aux systèmes Linux avait été infiltrée progressivement par un contributeur malveillant, jusqu’à l’introduction d’une porte dérobée dans certaines versions.
L’opération a été détectée avant une diffusion généralisée, mais elle a démontré combien l’isolement et la surcharge de quelques mainteneurs pouvaient devenir un risque pour toute la chaîne d’approvisionnement logicielle.
Le sujet ne relève donc pas seulement du confort des développeurs. Il concerne la résilience économique, la cybersécurité et la continuité des infrastructures numériques.
Lorsqu’une bibliothèque utilisée par des milliers d’organisations dépend d’une seule personne insuffisamment soutenue, cette personne devient malgré elle un point critique de l’économie numérique.
Les grandes fondations jouent ici un rôle essentiel. Elles apportent une gouvernance, une structure juridique, des ressources et une capacité de coordination.
Mais financer uniquement les grandes fondations ne suffira pas.
Une grande partie de la fragilité se trouve en dessous de leur radar : dans les petites bibliothèques, les utilitaires spécialisés et les composants peu visibles qui forment les dépendances indirectes de systèmes beaucoup plus importants.
L’Europe doit donc agir à plusieurs niveaux. Elle peut soutenir les grandes fondations, accompagner les entreprises européennes qui développent des solutions ouvertes et financer les infrastructures stratégiques les plus visibles.
Mais elle doit aussi pouvoir apporter quelques milliers ou quelques dizaines de milliers d’euros à un développeur indépendant pour documenter une bibliothèque, corriger sa dette technique, organiser un audit, préparer sa succession ou simplement consacrer du temps à sa maintenance.
Ces mécanismes ne peuvent pas reposer sur des procédures conçues pour de grands consortiums. Un mainteneur isolé ne dispose généralement ni d’un service juridique ni d’une équipe chargée des appels à projets européens.
Un financement réellement accessible doit être simple, proportionné et rapide.
L’Europe ne doit pas seulement financer les logiciels qu’elle souhaite voir naître. Elle doit aussi entretenir ceux dont elle dépend déjà.
Cette ambition a nécessairement un coût. Or les moyens annoncés restent sans commune mesure avec l’ampleur de la dépendance.
La stratégie européenne prévoit de mobiliser environ deux milliards d’euros sur sept ans en faveur de l’open source, soit près de 286 millions d’euros par an.
Dans le même temps, l’Europe dépense chaque année environ 264 milliards d’euros en produits et services numériques propriétaires non européens.
Rapporté à une même période, l’effort annuel consacré à la stratégie open source représente donc à peine 0,11 % de ces dépenses. Pour 1 000 euros consacrés aux technologies propriétaires non européennes, l’Europe investirait un peu plus d’un euro dans cette stratégie.
Les deux montants ne recouvrent évidemment pas exactement le même périmètre : l’un correspond à un effort public ciblé, l’autre aux dépenses numériques de l’ensemble de l’économie européenne. Mais l’écart d’échelle reste révélateur et le compte n’y est pas encore.
La question n’est d’ailleurs pas seulement budgétaire. Encore faut-il savoir où se trouvent les dépendances et comment atteindre les projets les moins visibles.
Aujourd’hui, une administration peut connaître son fournisseur principal sans savoir précisément quelles bibliothèques maintiennent ses services en fonctionnement. Une entreprise peut acheter une solution européenne dont une partie importante dépend de composants extérieurs insuffisamment financés.
Il manque encore une capacité européenne de cartographie, de reconnaissance et de mise en relation.
L’expression « GitHub européen » vient spontanément à l’esprit, mais elle ne décrit pas correctement le besoin. Copier une plateforme américaine pour créer un nouvel espace centralisé ne suffirait pas.
L’Europe a plutôt besoin d’une infrastructure fédérée des communs logiciels.
Cette infrastructure ne remplacerait pas les forges existantes. Elle pourrait relier les plateformes publiques, universitaires, associatives et privées déjà présentes sur le continent. Chaque projet conserverait son lieu d’hébergement et son autonomie, tout en pouvant être découvert et reconnu dans un espace européen commun.
Son premier rôle serait de repérer les dépendances importantes. Les administrations, les entreprises et les projets financés publiquement pourraient déclarer les composants ouverts qu’ils utilisent. L’analyse des nomenclatures logicielles et des chaînes de dépendances permettrait d’identifier les bibliothèques peu visibles mais devenues essentielles.
Son deuxième rôle serait de donner de la visibilité et de la crédibilité. Chaque projet pourrait présenter sa licence, son mode de gouvernance, son nombre de mainteneurs actifs, sa politique de sécurité et ses besoins de financement.
Il ne s’agirait pas de certifier qu’un logiciel est parfait, mais de rendre sa situation compréhensible.
Son troisième rôle serait de mettre en relation les utilisateurs et les mainteneurs. Plusieurs organisations dépendant du même composant pourraient mutualiser un contrat de maintenance, un audit de sécurité ou le financement d’une nouvelle version.
Son quatrième rôle serait de faciliter le financement. Des microfinancements, des bourses de maintenance ou des contrats pluriannuels pourraient être attribués en fonction de l’usage réel et de la criticité du composant.
Enfin, cette infrastructure pourrait aider à organiser la transmission. Un mainteneur souhaitant se retirer pourrait trouver de nouveaux contributeurs, transférer son projet à une structure neutre ou préparer une gouvernance collective.
Une telle infrastructure ne devrait pas devenir une administration centrale du logiciel libre. Les communautés open source fonctionnent précisément parce qu’elles conservent leur autonomie, leur diversité et leur liberté d’organisation.
L’Europe ne peut pas décréter cette culture. Elle peut en revanche lui offrir de meilleures conditions d’existence.
Elle peut aussi poser des exigences lorsqu’elle finance directement un projet. Si une technologie reçoit des fonds publics parce qu’elle est présentée comme une brique de souveraineté, il est légitime de prévoir une licence réellement ouverte, une gouvernance transparente et une stratégie de maintenance.
Pour les projets que l’Europe utilise sans les financer ni les gouverner, la réponse ne peut être la contrainte. Elle doit passer par le soutien, la contribution aux communautés, la diversification et la préparation d’alternatives crédibles.
L’Europe n’a pas besoin d’administrer l’open source. Elle doit devenir un partenaire durable de ceux qui le construisent.
Le paquet présenté le 3 juin constitue donc une étape importante. Il reconnaît enfin que le logiciel ouvert n’est pas seulement une préférence technique ou un moyen de réduire les coûts. Il peut devenir une infrastructure industrielle, un outil de résilience et un moyen de préserver une capacité d’action autonome.
Mais le succès de cette stratégie ne se mesurera pas uniquement au nombre de projets financés ou aux déclarations favorables aux standards ouverts.
Il se mesurera à la capacité de l’Europe à connaître les briques dont elle dépend, à soutenir leurs mainteneurs avant qu’ils ne s’épuisent et à garantir que les projets stratégiques puissent survivre à un changement de propriétaire, de licence ou de modèle économique.
Le logiciel libre n’est pas gratuit. Son coût existe toujours : développement, maintenance, documentation, infrastructure, audits et correction des vulnérabilités. Lorsque personne ne le paie directement, ce coût est simplement supporté ailleurs, souvent par quelques individus dont le travail reste invisible.
Pour faire de l’open source un véritable pilier de souveraineté, l’Europe devra accepter d’en payer le prix, mais aussi d’en partager la responsabilité. Car un code accessible offre une possibilité de reprise.
Seuls une communauté active, une gouvernance solide et un financement durable peuvent transformer cette possibilité en garantie réelle.
Et vous, qu'en pensez-vous ?
On en discute sur LinkedIn avant de se retrouver ici la semaine prochaine ?
Merci d'avoir lu cette édition jusqu'au bout.
— Fabrice | LinkedIn | Fabrice.Willot.eu
