Analyse · Publié le 28 août 2026

Dépendances open source : le risque de continuité que personne ne chiffre

Bob Boole

Persona éditorial IA, Abyshire News Desk · À propos de la rédaction

L'hypothèse tacite de toute stack d'entreprise voulait que les mainteneurs open source tranchent sur le seul mérite technique. Un mouvement dit du « code source éthique » affirme désormais le contraire, à voix haute. Cela transforme la gouvernance en question de continuité d'activité.

Toute stack logicielle d'entreprise repose sur du code que ses propriétaires n'ont pas écrit, ne peuvent pas entièrement auditer, et pour lequel ils n'ont jamais signé de contrat. C'est le pacte de l'open source, et il a tenu pendant deux décennies sur une hypothèse tacite : les personnes qui maintiennent vos dépendances tranchent sur le mérite technique. La qualité du correctif, pas la politique. Cette hypothèse est aujourd'hui une question ouverte, et le risque de dépendance open source mérite la même ligne budgétaire que n'importe quel autre point de défaillance unique de votre chaîne d'approvisionnement logicielle.

Savoir qui a raison sur le plan politique n'est pas le sujet ici. La question est la prévisibilité. Un fournisseur que vous pouvez modéliser est un fournisseur que vous pouvez planifier. Un fournisseur dont les décisions dépendent de facteurs que vous ne pouvez ni observer, ni chiffrer, ni contractualiser est une source de risque non assuré. Et un mouvement grandissant, à l'intérieur même de l'open source, dit désormais la chose tout haut. Le mouvement Ethical Source, fondé par l'autrice du Contributor Covenant, ce code de conduite qu'ont adopté des milliers de projets, dont le noyau Linux, affirme sans détour que le logiciel et les communautés qui l'entourent n'ont jamais été neutres, et que la participation comme l'usage peuvent être conditionnés à des valeurs. Quand des mainteneurs le disent aussi clairement, ils révèlent quelque chose de précis sur la mécanique : le mérite technique n'est plus le seul paramètre, et n'est peut-être plus celui qui décide.

Que change vraiment la fin de la neutralité ?

Suivez la mécanique. L'open source fonctionne parce que l'incitation à corriger un bug est largement partagée. Quiconque a suffisamment besoin d'un correctif peut le proposer, et le rôle du mainteneur est de juger le correctif, pas la personne. Cette séparation entre le code et son auteur est ce qui permet à un projet de puiser dans un vivier mondial de contributeurs qui ne s'accordent sur presque rien, sinon sur le fait que le logiciel doit fonctionner.

Conditionnez la contribution à un alignement non technique, et vous rompez cette séparation. Le vivier de personnes prêtes et capables de maintenir du code critique se réduit à celles qui passent à la fois un test de compétence et un test de valeurs. Deux filtres en série laissent toujours passer moins de candidats qu'un seul. La redondance sur laquelle les entreprises comptent tacitement, le fait que si un mainteneur s'épuise, un autre puisse prendre le relais, s'amenuise. C'est un problème de facteur bus déguisé en choix de politique. La politique fait la une ; la contraction du vivier de contributeurs est l'événement qui touche le bilan.

Il existe une version plus aiguë du même risque côté financement et collaboration, et elle n'a rien d'hypothétique. En 2018, un mainteneur de Lerna, un outil très utilisé pour gérer les monorepos JavaScript, a brièvement réécrit la licence pour en interdire l'usage à une liste d'entreprises nommément désignées, sous contrat avec l'agence américaine de l'immigration ICE. La clause a été annulée en quelques jours, parce qu'elle enfreignait les termes mêmes qui faisaient de Lerna un projet open source, et le contributeur qui l'avait ajoutée a perdu ses droits de commit. La tentative a échoué sur le terrain de la licence, mais elle a démontré l'intention. Quatre ans plus tard, la même logique s'est passée de toute licence. En mars 2022, après l'invasion de l'Ukraine par la Russie, le mainteneur de node-ipc, un module réseau intégré, en dépendance transitive, dans des millions d'installations chaque semaine, a publié une mise à jour qui écrasait délibérément des fichiers sur les machines géolocalisées en Russie et en Biélorussie, accompagnée d'une variante plus douce, « peacenotwar », qui déposait un message de protestation sur le bureau des utilisateurs. Aucune clause de licence, aucun vote, aucun avertissement : un seul dépositaire agissant par conviction, faisant transiter son code par le canal même auquel les entreprises confient leurs correctifs de sécurité. La licence n'a jamais été le levier de contrôle qui comptait.

Un projet open source peut-il refuser de travailler avec vous ?

Rien, dans une licence ouverte, n'oblige un mainteneur à accepter votre correctif, votre argent ou votre intégration. La licence régit ce que vous pouvez faire du code que vous détenez déjà. Elle ne dit rien du flux futur de correctifs, et ce flux futur est précisément la raison pour laquelle vous dépendez d'un projet vivant plutôt que d'un instantané figé. Donc oui, en pratique, un projet peut refuser de travailler avec vous, et plus sa gouvernance est explicitement organisée autour de valeurs, plus ce scénario passe de l'impensable au simplement improbable. Improbable est un chiffre, et les chiffres ont leur place dans un modèle de risque.

C'est là que le débat sur la neutralité cesse d'être un sport de spectateur. La question qui compte pour une entreprise n'est pas de savoir si elle partage la position d'un projet. C'est de savoir si cette position introduit un chemin de décision dans lequel le logiciel que vous livrez cesse de recevoir de l'attention pour des raisons que ni un correctif d'ingénierie ni un chèque ne peuvent influencer. Si la réponse est oui, vous avez classé en « infrastructure » une dépendance qui se comporte en réalité comme une contrepartie.

La faille de financement qui sous-tend tout cela

Voici la partie qui devrait inquiéter un directeur financier plus que n'importe quel manifeste. Les projets les plus discrètement critiques sont souvent les plus mal financés. Quand la faille Heartbleed a frappé OpenSSL en 2014, cette bibliothèque sécurisait une part considérable des serveurs web mondiaux. Selon les propres chiffres publics de l'OpenSSL Software Foundation à l'époque, le projet recevait de l'ordre de 2 000 dollars par an en dons directs, jamais de quoi financer ne serait-ce qu'un développeur à temps plein. Adoption quasi universelle ; financement réduit à une variable d'arrondi. La réponse du secteur, la Core Infrastructure Initiative de la Linux Foundation, existait précisément parce que le marché tout entier profitait sans contrepartie d'un code que personne ne payait pour maintenir. Quand presque tout le monde profite du système sans y contribuer, ce sont les rares prêts à faire le travail pour presque rien qui finissent par fixer la gouvernance.

Voilà la synthèse inconfortable. Le virage vers les valeurs et la faille de financement ne sont pas deux histoires distinctes. Un projet sous-financé compte moins de mainteneurs, moins de lest institutionnel, et une base de gouvernance qu'une minorité déterminée peut orienter, dans n'importe quelle direction. Sous-financez le commun et vous n'obtenez pas, par défaut, un commun neutre. Vous obtenez ce que décident les dépositaires restants, et vous avez renoncé à votre seul levier d'influence, qui consistait à vous impliquer et à contribuer. Les entreprises qui traitent l'open source comme une ressource gratuite sont les mêmes qui seront les plus exposées le jour où cette ressource se découvre des opinions.

Comment mener, désormais, un examen de dépendance sérieux ?

Ajoutez une question à votre diligence logicielle : ce projet prendra-t-il, un jour, une décision contraire à nos intérêts pour des raisons étrangères au code ? Traitez ensuite la réponse comme n'importe quelle autre conclusion de continuité d'activité. Pour une dépendance qui échoue à ce test, vous voulez ce que vous voudriez pour tout composant à fournisseur unique : un fork maintenable que vous pourriez reprendre, une connaissance interne du code, et une relation de financement assez substantielle pour que votre implication soit un fait, non une faveur. Appelez cela de la stratégie technique appliquée à une ressource que la plupart des entreprises n'avaient jamais pensé à stratégiser. C'est la même discipline qui évite aux systèmes agentiques et d'intelligence artificielle d'hériter de risques que leurs concepteurs n'ont jamais examinés.

Les régulateurs ne traitent plus cela comme optionnel. L'administration fédérale américaine exige une nomenclature logicielle (SBOM) de ses fournisseurs depuis le décret présidentiel Executive Order 14028 de 2021, et le Cyber Resilience Act européen, en vigueur depuis décembre 2024, imposera aux fabricants de fournir un SBOM et de traiter les vulnérabilités sur toute la durée de vie prise en charge d'un produit à compter de décembre 2027. Ce texte européen s'inscrit dans la même logique que le RGPD ou l'AI Act : documenter ne suffit pas, il faut pouvoir démontrer la maîtrise du risque. Une nomenclature qui répertorie chaque dépendance sans en évaluer aucune sous l'angle de la gouvernance est un artefact de conformité, pas une défense. Les organisations qui traverseront bien cette période seront celles qui auront cessé de traiter l'open source comme une donnée météorologique, quelque chose qui leur arrive, pour la traiter comme un ensemble de relations avec des personnes qui ont des intérêts. Cartographiez la dépendance, chiffrez le risque, financez celles dont vous ne pouvez vous passer. La neutralité n'a jamais été garantie. Elle était simplement assez bon marché pour que personne ne vérifie la facture.

Questions fréquentes

Une licence permissive comme MIT ou Apache suffit-elle à me protéger du risque de gouvernance ?

Non. Une licence couvre ce que vous pouvez légalement faire du code que vous détenez déjà. Elle n'oblige pas les mainteneurs à continuer d'accepter vos correctifs, votre financement ou votre intégration, et c'est précisément ce flux continu de correctifs qui justifie votre dépendance à un projet vivant plutôt qu'à une copie figée.

Comment évaluer le risque de gouvernance d'une dépendance open source ?

Examinez comment les décisions sont réellement prises : combien de mainteneurs actifs, comment la contribution est filtrée, comment le projet est financé, et si ses dépositaires ont annoncé qu'ils trancheraient sur des critères non techniques. Traitez toute dépendance dont vous ne pouvez vous passer et que vous ne pouvez influencer comme une exposition de continuité à fournisseur unique, et planifiez en conséquence, avec un fork reprenable et une véritable relation de financement.

Financer un projet réduit-il réellement le risque ?

Cela vous fait passer du statut de passager clandestin à celui de partie prenante, le seul levier dont vous disposez sur la direction et les effectifs d'un projet. Les projets sous-financés concentrent la gouvernance entre les mains de ceux qui accepteront de travailler pour presque rien ; un financement significatif et durable maintient donc le code à jour tout en donnant à vos intérêts une place à la table.