Vos mainteneurs open source ont un financeur, et ce n'est pas vous
Vous auditez le moindre fournisseur commercial. Jamais la gouvernance des bibliothèques open source qui font tourner votre système d'information. Un angle mort qui devient coûteux.
Votre service achats sait tout de l'éditeur qui héberge votre CRM : son actionnariat, la localisation de vos données, ce qu'il advient de votre contrat en cas de rachat. Demandez-lui qui rémunère le mainteneur de la petite bibliothèque de parsing enfouie trois couches plus bas dans votre build, et vous obtiendrez un regard vide. Prenez cette bibliothèque comme représentative des dizaines que vous embarquez sans y penser. Aucun bon de commande, aucune signature, aucun chargé de compte. Elle est arrivée gratuitement, elle n'a donc jamais eu de ligne dans le registre des risques.
C'est l'erreur. La bibliothèque est gratuite pour vous et coûteuse à produire. Quelqu'un y consacre ses soirées, ou de plus en plus son temps salarié, pour la maintenir en vie. Suivez ce salaire et vous tombez sur la vraie question que dissimule votre arbre de dépendances.
En quoi le financement d'un projet open source constitue-t-il un risque de chaîne d'approvisionnement ?
Le modèle standard du risque open source raisonne en code. Existe-t-il une vulnérabilité connue ? La licence est-elle compatible ? Le projet est-il à l'abandon ? Ce sont de bonnes questions, et un scanner y répond toutes. Elles partagent une même hypothèse : le danger loge dans l'artefact que vous possédez déjà.
Le danger que le scanner ne voit pas loge dans les personnes qui décident du contenu de la prochaine version. Une dépendance est un flux de décisions futures prises par quiconque détient les droits de merge, et ces décisions répondent à des entrées. L'une des plus déterminantes est de savoir qui paie la personne qui décide.
Pendant des années, la réponse honnête à « qui paie » était « personne, et ça se voit ». Un mainteneur isolé, non rémunéré, à bout de souffle, qui rustine une bibliothèque dont dépend la moitié d'internet. C'était un problème de moyens, avec une solution évidente : payer ces gens.
Ils sont payés désormais, simplement pas par vous. Cela ne referme pas le problème, cela le déplace.
Quand le payeur n'est pas l'utilisateur
Voici le mécanisme. Quand le revenu d'un mainteneur provient des utilisateurs qui dépendent du logiciel, l'incitation pointe vers la stabilité. Casser l'outil dont ces utilisateurs dépendent, et l'argent s'arrête. La boucle de rétroaction est courte, et elle favorise celui qui fait tourner le code en production.
Quand le revenu provient d'une fondation, d'un programme d'entreprise ou d'une bourse publique, cette boucle change de trajet. Celui qui signe le chèque a des priorités, et il est légitime à les avoir : sécurité, pérennité, santé de la communauté, souveraineté numérique, quel que soit le mandat. Ces priorités deviennent une entrée de la feuille de route d'une dépendance dont dépendent des milliers d'entreprises, et aucune de ces entreprises n'a été consultée, parce qu'aucune n'est plus le client.
Ce sont de vraies institutions, avec des mandats publiés, et il vaut la peine de les lire. Le Sovereign Tech Fund allemand, adossé au ministère fédéral de l'Économie, investit dans les infrastructures numériques ouvertes d'intérêt public, et a mis de l'argent dans curl, OpenSSL, GnuPG, PHP, systemd et des pans de l'écosystème Rust. Alpha-Omega, un projet de l'Open Source Security Foundation de la Linux Foundation financé par Microsoft, Google et Amazon, vise à améliorer la posture de sécurité des projets critiques et a financé la Python Software Foundation, la Rust Foundation, Node.js et la Eclipse Foundation. Lisez les deux mandats côte à côte, le thème est limpide : sécurité, résilience, souveraineté. Des objectifs sensés, tous autant qu'ils sont. Ce sont aussi les objectifs de quelqu'un d'autre que vous, attachés aux bibliothèques mêmes qui se trouvent au fond de votre stack.
Le financement institutionnel des mainteneurs est, tout compte fait, une bonne nouvelle. Une infrastructure critique sous-payée est un pire état du monde qu'une infrastructure critique financée. Reste que celui qui paie fixe l'agenda, et dès lors que le payeur cesse d'être l'utilisateur, l'agenda dérive de la disponibilité de l'utilisateur vers le mandat du financeur, quelles que soient les intentions de ce dernier. Cette dérive n'apparaît jamais dans un scan de dépendances. Autant être honnête sur son statut : il s'agit d'un mécanisme à anticiper, construit sur les incitations, en amont de tout dossier public que vous pourriez brandir devant un sceptique. La raison de le surveiller est simple : les incitations vont déjà dans ce sens.
Un changement de priorité en amont a-t-il déjà touché des équipes en aval ?
Cela s'est produit, ou du moins un épisode se lit ainsi, et OpenSSL en est l'illustration la plus nette, offerte comme illustration plutôt que comme preuve. Après que le bug Heartbleed a révélé, en 2014, combien la bibliothèque était sous-dotée, le projet a attiré des financements institutionnels sérieux via la Core Infrastructure Initiative de la Linux Foundation, soutenue notamment par Amazon, Google, IBM, Intel et Microsoft. Financé et réorganisé, le projet a mené une refonte architecturale majeure, livrée sous la forme d'OpenSSL 3.0 en 2021, avec un nouveau système de « providers » et un module FIPS visé directement sur les utilisateurs soumis à des obligations de conformité. La mise à jour a aussi déprécié une longue liste d'API et s'est accompagnée de régressions de performance que les projets en aval ont passé des mois à diagnostiquer et contourner. Personne n'a agi de mauvaise foi. La séquence est documentée ; la lecture selon laquelle les priorités du financeur l'ont dessinée m'appartient, elle n'appartient pas aux faits. Un jeu de fonctionnalités orienté conformité, arrivant en même temps qu'une réorganisation financée, est à tout le moins compatible avec cette lecture, et tout le monde en aval a payé la facture de la migration.
Du don ponctuel à l'influence systémique
C'est l'échelle et la structure qui rendent le sujet pertinent aujourd'hui. Le financement des mainteneurs était autrefois occasionnel et personnel : un pourboire, une subvention ponctuelle, une entreprise qui sponsorisait l'outil dont dépendait sa propre équipe. Un financement occasionnel achète une influence occasionnelle, un bruit de fond que vous pouvez ignorer.
L'argent change de nature. Les programmes d'entreprise, les fondations philanthropiques et les initiatives soutenues par des États traitent de plus en plus les bibliothèques fondamentales comme une infrastructure publique méritant un financement pluriannuel. La direction probable, et ceci est une projection plutôt qu'un fait acquis, consiste à orienter cet argent structuré vers les mainteneurs des écosystèmes fondamentaux : les runtimes de langage et les bibliothèques standard qui se trouvent sous tout le reste. Un financement structuré et récurrent achète une influence structurée et récurrente. Atteignez la base du stack plutôt que sa périphérie, et les priorités d'un financeur cessent d'être du bruit pour commencer à se propager vers le haut, dans tout ce qui est construit dessus. Le futur Cyber Resilience Act européen ira dans ce sens, en poussant les éditeurs à documenter leurs dépendances logicielles, sans pour autant répondre à la question de gouvernance posée ici.
Plus vous comptez faire tourner votre stack actuel longtemps, plus vous pariez sur des priorités amont fixées, dans les années à venir, par des personnes dont vous n'avez jamais examiné les incitations.
Comment exercer une vigilance sur une dépendance que vous n'avez pas achetée ?
Vous ne pouvez pas auditer un projet open source comme vous auditez un fournisseur. Il n'y a ni contrat, ni chargé de compte, ni crédit de service quand ça tourne mal. L'absence de contrat plaide cependant pour une vigilance d'un autre type, pas pour l'absence de vigilance.
Commencez par les mainteneurs de vos dépendances véritablement critiques, la poignée dont un changement de cap soudain vous ferait réellement mal. Pour chacune, posez trois questions simples. Qui finance actuellement les mainteneurs principaux ? Quel est le mandat déclaré de ce financeur ? Et quel est votre plan de repli si ce mandat et vos besoins divergent : un fork que vous pourriez porter, une copie vendorisée que vous pourriez figer, une alternative commerciale que vous pourriez acheter ? Construire une cartographie claire de vos dépendances critiques et de leur gouvernance n'a rien de gratifiant, et cela ne paraît optionnel que jusqu'à la semaine où ça ne l'est plus.
La même discipline mord plus fort à mesure que vos systèmes se mettent à agir seuls. À mesure que les systèmes agentiques héritent d'une véritable autorité, les composants open source qu'ils embarquent héritent eux aussi du risque de gouvernance logé derrière leurs mainteneurs, et ils en héritent à la vitesse de la machine. Un changement de priorité que vous auriez autrefois pu absorber à la main devient un changement que votre automatisation propage avant que quiconque ait lu le changelog.
Rien de tout cela ne plaide pour fuir l'open source financé ; financé vaut mieux qu'abandonné. Le mouvement à faire, c'est de tarifer un risque que vous portez aujourd'hui gratuitement. Le code n'a jamais été toute l'exposition. Ce qui en fixe la direction, c'est l'incitation de l'humain qui l'écrit, et cette incitation répond désormais à un financeur que vous n'avez jamais rencontré.
Questions fréquentes
Faut-il cesser d'utiliser les projets open source financés par des États ou des entreprises ?
Non. Une maintenance financée est en général plus sûre qu'une maintenance bénévole à bout de souffle. Ce qui compte, c'est la vigilance : savoir qui finance vos dépendances critiques, et garder un plan de repli prêt pour le jour où les priorités du financeur et vos besoins cesseront de coïncider.
Comment savoir qui finance un mainteneur open source en particulier ?
Commencez par les pages de financement et de sponsoring du projet lui-même, sa fondation de tutelle le cas échéant, et les registres publiés de bourses ou de subventions. Recoupez avec les mainteneurs qui mergent réellement les changements. Là où c'est opaque, traitez l'opacité elle-même comme un signal de risque.
Quelle est la différence entre le risque de code et le risque de gouvernance en open source ?
Le risque de code concerne l'artefact que vous possédez déjà : vulnérabilités, licences, projet maintenu ou non. Le risque de gouvernance concerne les décisions à venir : qui détient les droits de merge, qui les rémunère, et quelles priorités façonneront la prochaine version. Les scanners détectent le premier et sont aveugles au second.
À lire aussi
- Sur Ubuntu 26.04 LTS, le coreutils dont dépend votre build n'est plus du GNU
- La prime de souveraineté : pourquoi les entreprises paient plus cher une IA qu'aucun gouvernement étranger ne pourra couper
- Le Secret des Affaires se Perd des Années Avant la Démission. Demandez au Poulet Faccenda.
- Security & Trust
Rédigé par un persona éditorial IA du système éditorial propriétaire d'Abyshire et relu par notre équipe.