Votre socle open source a un conseil d'administration. Personne n'exerce son devoir de vigilance.
Linux 6.15 a supprimé un support que trois décennies d'utilisateurs avaient intégré dans leurs calculs, sans que ceux qui en paieraient le prix aient voix au chapitre. Les entreprises auditent chaque fournisseur commercial et aucune des fondations sur lesquelles repose réellement leur infrastructure.
En mai 2025, le noyau Linux 6.15 a été publié sans prise en charge des processeurs Intel 486 et des premiers 586, mettant fin à une promesse de compatibilité tenue depuis le début des années 1990 et qui n'avait jamais été couchée noir sur blanc. L'argument avancé était pragmatique : maintenir la couche d'émulation nécessaire à ces puces mobilisait une attention de mainteneurs que le projet jugeait mieux employée ailleurs, et la liste de diffusion du noyau débattait ouvertement de cette suppression depuis 2022. Défendable, à l'échelle du projet. Reste à savoir qui a été consulté. Les entreprises qui font encore tourner ce silicium (automates industriels, instruments de laboratoire, systèmes embarqués qui survivent à leurs fournisseurs) n'ont eu ni préavis, ni calendrier publié, ni voix au chapitre. Combler cet angle mort, c'est précisément l'objet d'un audit de diligence open source. Et presque personne ne le fait.
Votre entreprise ne signerait jamais un contrat de cinq ans avec un fournisseur sans vérifier qui le détient, qui le finance et ce qu'il adviendrait si ses intérêts changeaient. Elle bâtira pourtant une décennie d'infrastructure sur une plateforme open source sans poser une seule question sur l'organisation qui en tient la barre. Quand l'audit existe, il s'arrête au fichier de licence, lequel ne régit que ce que vous avez le droit de faire avec le code tel qu'il existe aujourd'hui. Ce que le mainteneur a le droit de faire au code demain reste entièrement hors champ. Personne n'envoie de facture pour une dépréciation. La ligne budgétaire, elle, apparaît quand même.
Les projets open source vous doivent-ils la compatibilité ascendante ?
Non. Feuille de route, politique de dépréciation et supports de plateforme relèvent entièrement du bon vouloir du mainteneur, un point c'est tout. Face à un fournisseur commercial, vous auriez des préavis contractuels, des niveaux de service et des voies de recours ; face à un mainteneur amont, vous avez une influence proportionnelle à votre financement et à votre participation, et la plupart des entreprises n'apportent ni l'un ni l'autre. En langage de gouvernance, vous êtes le client non payant d'un fournisseur qui ne vous doit rien. Cet arrangement fonctionne à merveille tant que les intérêts s'alignent par hasard, et l'erreur consiste à traiter cet alignement comme une propriété intrinsèque de l'open source plutôt que comme une coïncidence à surveiller. Le mainteneur n'est pas non plus une abstraction neutre : les membres platine de la Linux Foundation forment un who's who de fabricants de puces, d'opérateurs cloud et de constructeurs, chacun porteur de ses propres intérêts commerciaux, et les instances de gouvernance du secteur se ressemblent presque toutes sur ce point, y compris les fondations qui structurent une partie de l'écosystème French Tech.
Quel préavis les dépréciations open source donnent-elles réellement ?
Autant que la politique du mainteneur le prévoit, pas un jour de plus. La comparaison mérite d'être lue en détail, tant l'écart est immense. À l'extrémité la plus généreuse, Python. La PEP 373, publiée en 2008, programmait le retrait de Python 2.7 pour 2015 ; l'écosystème n'étant manifestement pas prêt, le projet a repoussé l'échéance au 1er janvier 2020. Plus d'une décennie de préavis écrit et public, révisé une fois, en faveur des utilisateurs.
À l'autre extrémité, CentOS. Les entreprises avaient adopté CentOS 8 en 2019 sur la foi d'un cycle de vie publié, calqué sur celui de Red Hat Enterprise Linux, avec une fin de support annoncée pour 2029. En décembre 2020, le projet a annoncé que CentOS Linux 8 s'arrêterait finalement fin 2021, le travail se réorientant vers CentOS Stream. Un horizon que les utilisateurs avaient budgété sur près d'une décennie s'est effondré à environ douze mois de préavis, et chaque plan de migration bâti dessus est arrivé à échéance sept ans en avance.
Node.js se situe entre les deux et enseigne la leçon la plus subtile. Node 16 avait une fin de vie publiée en avril 2024 selon le calendrier de publication du projet ; celui-ci a ensuite avancé cette date de sept mois, au 11 septembre 2023, parce que la bibliothèque OpenSSL 1.1.1 sous-jacente arrivait en fin de support avant lui, et que personne ne voulait faire tourner un runtime sur une cryptographie non corrigée. Le calendrier était réel et le mainteneur a honoré son propre processus. Les utilisateurs ont quand même perdu sept mois, parce que l'horloge d'un autre mainteneur, plus haut dans la chaîne, s'est arrêtée en premier.
Mettez ces trois trajectoires côte à côte avec celle du noyau, et le schéma saute aux yeux : le préavis relève de la politique, pas de la physique. Il va d'une décennie à un an, les dates publiées bougent dans les deux sens, et votre préavis réel correspond à la fenêtre la plus courte de toute votre chaîne de dépendances. Le retrait du support 486 n'est pas un scandale ; c'est le point le plus extrême de cette fourchette. Aucun document de cycle de vie n'existait pour le support matériel du noyau, et le seul préavis disponible était un fil de discussion technique que quasiment aucune direction achats sur terre ne surveillait.
Quand la paperasse fabrique le problème
Un risque distinct émerge, et il faut le dire clairement : il n'a joué aucun rôle dans la décision sur le 486, débattue en public pendant des années sur des bases purement techniques. Le risque, c'est que la preuve d'une « charge de maintenance » puisse désormais se fabriquer à la demande. Du code tourne en production pendant des années sans la moindre plainte humaine ; un outil de scan automatisé produit un défaut théorique à l'apparence plausible ; le signalement atterrit dans le gestionnaire de tickets ; le code porte désormais des tickets ouverts, et sa suppression se lit comme de l'hygiène plutôt que comme une dépréciation. Le projet curl vit en première ligne de ce phénomène. Son mainteneur, Daniel Stenberg, alertait déjà en janvier 2024 sur les rapports de sécurité assistés par IA, et en juillet 2025 il rapportait qu'environ un cinquième des signalements de sécurité reçus par curl étaient générés par IA, sans qu'un seul rapport valide n'en soit jamais sorti, chacun consommant des heures de relecture de mainteneurs qualifiés. La suppression par la paperasse est un risque bien réel pour tout projet dont le triage ne sait pas distinguer une spéculation générée par machine d'un défaut réellement rencontré par un utilisateur.
Méfiez-vous particulièrement de l'argument « à cause de l'IA » dans les débats de périmètre : la même prémisse sert tour à tour de justification à une extension de capacité (moins de mainteneurs peuvent porter plus de code) et à une réduction de périmètre (le gestionnaire de tickets déborde de scories générées) dans l'argument suivant. Une prémisse qui soutient une conclusion et son contraire ne fait aucun travail analytique.
À quoi ressemble concrètement un audit de diligence open source ?
Au même exercice que la diligence fournisseur, appliqué un cran plus bas dans la pile, et le panorama comparatif ci-dessus vous donne directement les questions à poser.
Politique de cycle de vie écrite. Le mainteneur en publie-t-il une ? La décennie de préavis de Python existait parce que la PEP 373 existait. Le noyau n'a aucun document équivalent pour le support matériel, ce qui annonçait d'avance que le préavis serait ce que la liste de diffusion déciderait qu'il soit.
Antécédents et tendance. Quand ce mainteneur a déjà déplacé une échéance, dans quel sens l'a-t-il fait ? Python a révisé en faveur des utilisateurs ; CentOS a révisé contre eux, de près d'une décennie. La dernière révision d'un mainteneur est le meilleur indicateur disponible de la prochaine.
Préavis transitif. Votre fenêtre de préavis réelle est le minimum de toute la chaîne, pas le chiffre affiché sur l'emballage. Le calendrier de Node 16 a tenu jusqu'à ce que celui d'OpenSSL s'arrête. Cartographiez les horloges amont dont héritent vos plateformes.
Gouvernance et argent. Qui finance le mainteneur, et ces financeurs profitent-ils du jour où vous devrez renouveler du matériel ou migrer en urgence ?
Exposition et sortie. Sachez quelles fonctionnalités, plateformes et générations de matériel de votre parc se situent dans la zone plausible du « legacy » côté amont, et chiffrez dès maintenant, à froid, le fork, l'épinglage de version ou la migration, plutôt que pendant le trimestre où tombe l'arrêt du support. Une porte de sortie déjà chiffrée est la seule qui renforce votre position de négociation.
Rien de tout cela n'est exotique. C'est exactement la même cartographie des incitations que nous appliquons dans nos revues de stratégie technique, pointée vers une contrepartie que la plupart des organisations n'ont jamais pensé à examiner, et cela relève du même plan de cycle de vie que les plateformes sur lesquelles repose votre activité. Cette discipline rejoint aussi celle que nous défendons à propos de la préparation à l'IA : toute affirmation se vérifie avant d'être actionnée, quelle que soit sa source, en amont comme dans votre propre comité de direction. Les start-ups labellisées French Tech, hébergées à Station F ou ailleurs, n'échappent pas à la règle : elles héritent des mêmes dépendances et des mêmes horloges amont que les grands comptes. Les fondations sous votre pile sont des fournisseurs sans aucune des obligations d'un fournisseur. Auditez vos mainteneurs comme vos fournisseurs. Ils peuvent changer d'avis, et la facture atterrit chez vous.
Questions fréquentes
Comment savoir si un projet open source amont risque de supprimer un support dont je dépends ?
Surveillez le mainteneur, pas seulement le code. L'absence de politique de cycle de vie écrite, un financement et une composition du conseil qui basculent vers de nouvelles priorités commerciales, des débats de dépréciation présentés comme une « réduction de la charge de maintenance », et une couverture de mainteneurs trop mince sur les chemins de code que vous utilisez sont autant de signaux avant-coureurs. Le retrait du support 486 était annoncé dans les discussions du noyau près de trois ans avant sa sortie effective. Traitez les fils de gouvernance d'un projet comme vous traiteriez les conférences de résultats d'un fournisseur : ennuyeux, publics, et pleins de signal.
Les rapports de bugs générés par IA représentent-ils un risque réel pour la stabilité des logiciels ?
Oui, et l'expérience du projet curl en montre la mécanique : une large part des signalements de sécurité entrants est désormais générée par machine, et pratiquement aucun ne s'est révélé valide. Le danger se loge dans le triage. Un défaut théorique généré par IA constitue une preuve plus faible qu'un incident réellement rencontré par un utilisateur en production, et un projet qui traite les deux de façon identique finira par requalifier peu à peu du code qui fonctionne en simple charge à éliminer. Face à une dépendance, demandez si son processus de triage distingue la spéculation générée par machine des défaillances signalées par des humains.
Que doit couvrir une revue de gouvernance open source ?
Quatre points : le mainteneur publie-t-il une politique de cycle de vie, et comment a-t-il honoré ou révisé ses échéances par le passé (la fourchette va de la décennie de préavis de Python 2 à l'effondrement de CentOS 8, de 2029 à fin 2021) ; qui gouverne et finance le mainteneur, et vers où va son chiffre d'affaires ; une cartographie des systèmes de votre parc qui dépendent de fonctionnalités susceptibles d'être classées comme legacy, fenêtres de préavis héritées de l'amont comprises ; et une voie de sortie déjà chiffrée (fork, épinglage de version ou migration). Actualisez-la chaque année, car les incitations des mainteneurs évoluent plus vite que vos cycles de refonte.
À 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.