Log4j est une bibliothèque de journalisation Java intégrée dans des millions d'applications — des serveurs d'entreprise aux systèmes industriels en passant par les consoles de jeux vidéo. La faille Log4Shell découverte en décembre 2021 était classée 10/10 sur l'échelle de criticité CVSS. Elle affectait potentiellement des centaines de millions de systèmes dans le monde. Log4j était maintenu par une poignée de bénévoles, sans financement commercial structuré. La réponse d'urgence à la faille a reposé sur ces mêmes bénévoles, contraints de travailler sans arrêt pendant plusieurs semaines sur un problème dont la résolution bénéficiait à des entreprises milliardaires qui n'avaient rien contribué à leur financement.

L'industrie logicielle mondiale est construite sur une pyramide inversée : des milliards de dollars de capitalisation boursière reposent, à leur base, sur des bibliothèques open source maintenues par des dizaines ou centaines de personnes sans financement proportionnel. Cette pyramide est stable tant qu'aucune faille critique n'apparaît dans les couches basses. Quand une faille apparaît, elle révèle que la base de la pyramide était en carton.

Une planche de bande dessinée publiée par le webcomic XKCD représente toute l'infrastructure numérique mondiale comme une pile de blocs de construction, dont l'un — minuscule, à la base — est labellisé "un projet maintenu depuis 2003 par une personne à Nebraska". Cette image est devenue virale en 2021 lors de Log4Shell parce qu'elle décrit avec précision la réalité : quelque part dans la chaîne de dépendance de chaque système critique, il y a une bibliothèque maintenue par une personne dont personne ne connaît le nom.

La vulnérabilité de l'open source non financé n'est pas seulement technique — elle est humaine. Un mainteneur qui s'épuise, qui change d'emploi, qui tombe malade, qui décide d'arrêter, abandonne une bibliothèque dont des milliers de projets dépendent. Cette bibliothèque ne sera plus maintenue, les nouvelles failles ne seront plus corrigées, les nouvelles versions de langage ne seront plus supportées. Le risque de "abandon de mainteneur" est documenté mais rarement intégré dans les analyses de risque d'infrastructure.

Google maintient Kubernetes, Angular, TensorFlow. Microsoft a acquis GitHub et contribue massivement à VSCode, TypeScript, .NET open source. Meta maintient React et PyTorch. Amazon contribue à OpenSearch. Ces contributions sont réelles et significatives — elles ne couvrent pas l'ensemble de la dette de financement de l'écosystème open source dont ces entreprises dépendent.

La contribution des hyperscalers se concentre sur les projets qu'ils contrôlent ou dont la visibilité sert leur image. Les projets critiques mais peu visibles — bibliothèques de compression, parseurs de formats de fichiers, implémentations de protocoles réseau — restent maintenus par des individus sans financement structuré. Ces bibliothèques sont utilisées par des millions de projets, dont ceux des hyperscalers eux-mêmes. La sélection de ce qui est financé est stratégique, pas altruiste.

Les fondations open source collectent des cotisations auprès des entreprises membres, emploient des développeurs à temps plein sur les projets critiques, et organisent la gouvernance. Ce modèle fonctionne pour les projets suffisamment visibles et utilisés pour attirer des membres payants. Il échoue pour les projets critiques mais peu visibles qui ne peuvent pas construire une masse critique de membres suffisante pour se financer.

Des entreprises comme HashiCorp, Elastic ou Redis Labs ont adopté des modèles où le code de base est open source et les fonctionnalités avancées sont propriétaires (open core) ou le code est disponible sous licence restrictive pour les usages commerciaux (dual licensing). Ces modèles financent le développement mais créent des tensions avec la communauté open source et des ruptures de compatibilité entre versions.

L'Allemagne a créé en 2022 le Sovereign Tech Fund — un fonds public qui finance directement la maintenance de bibliothèques open source critiques identifiées comme infrastructure numérique nationale. Ce modèle traite l'open source comme une infrastructure publique — au même titre que les routes ou les réseaux électriques — et le finance comme tel. C'est le modèle le plus cohérent avec la thèse de cette étude. Il reste marginal à l'échelle européenne.

Connaître les bibliothèques critiques dont son infrastructure dépend, leur niveau de maintenance (date du dernier commit, nombre de mainteneurs actifs, présence d'une fondation ou d'un sponsor), et leur historique de vulnérabilités. Cet audit devrait être aussi standard que l'audit de sécurité — parce que c'est de la sécurité. Un outil comme Dependabot ou Renovate automatise une partie de ce suivi.

Le risque qu'un mainteneur critique abandonne sa bibliothèque devrait figurer dans les analyses de risque d'infrastructure, au même titre que le risque de faillite d'un fournisseur ou de fin de support d'un OS. Ce risque a une réponse : fork interne de la bibliothèque, migration vers une alternative mieux maintenue, ou contribution au financement du mainteneur.

Les entreprises qui utilisent de l'open source peuvent contribuer par le code (correctifs de bugs, nouvelles fonctionnalités), par le financement (dons aux mainteneurs, adhésion aux fondations), ou par le temps (ingénieurs dédiés à la maintenance de bibliothèques critiques). Ces contributions ne sont pas du mécénat — elles sont de la gestion de risque. Une bibliothèque mieux financée est une dépendance moins risquée.

Sur le modèle du Sovereign Tech Fund allemand, un fonds européen de financement de l'open source critique — doté d'un budget proportionnel à la taille de l'économie numérique européenne — finance la maintenance des bibliothèques identifiées comme infrastructure critique. Ce fonds est alimenté par des contributions publiques et par des contributions obligatoires des entreprises dont le chiffre d'affaires dépasse un seuil défini et qui utilisent ces bibliothèques en production.

Les entreprises au-delà d'une certaine taille devraient déclarer annuellement leurs dépendances open source critiques — à l'image de la déclaration des fournisseurs critiques dans les plans de continuité d'activité. Cette transparence permettrait d'identifier les bibliothèques à risque (peu de mainteneurs, peu de financement, beaucoup d'utilisateurs) et de prioriser les efforts de financement collectif.

Tout marché public de services numériques devrait intégrer un critère de contribution à l'open source critique dans ses conditions d'attribution. Un prestataire qui contribue au financement des bibliothèques open source qu'il utilise dans sa prestation est un prestataire plus fiable — et son contrat devrait le refléter.