L’information est passée presque inaperçue en dehors des cercles noyau Linux. Chris Mason, qui a créé le système de fichiers Btrfs en 2007 alors qu’il travaillait chez Oracle, a quitté Meta le 28 août 2026 et annoncé son retrait de la co-maintenance du projet.
La lecture spontanée est catastrophiste : le créateur s’en va, le projet est en péril, il faut migrer. Cette lecture est fausse, et l’expliquer est plus utile qu’un commentaire de plus sur l’actualité.
Mais l’épisode pose une vraie question, et nous nous la sommes appliquée à nous-mêmes : sur les dépendances qui font tourner nos projets clients, que se passe-t-il si une personne précise s’arrête ? Nous avons passé deux jours à répondre. Voici les chiffres.
Pourquoi ce départ n’est pas la mauvaise nouvelle qu’on croit
Trois faits, souvent absents des reprises de l’information.
D’abord, Chris Mason n’assurait plus la maintenance quotidienne de Btrfs depuis plusieurs années. Le mainteneur principal est David Sterba, chez SUSE. Le rôle de co-mainteneur était devenu largement honorifique dans les faits, et son abandon formalise une situation existante plutôt qu’il ne la crée.
Ensuite, Mason reste relecteur de code sur le projet. Il ne quitte pas la communauté, il quitte un employeur, et il indique vouloir poursuivre ses contributions en amont depuis son prochain poste.
Enfin — et c’est le point qui compte pour nous — la continuité est assurée parce que la maintenance était déjà répartie entre deux organisations différentes, Meta et SUSE. Un projet dont tous les mainteneurs sont salariés de la même entreprise est infiniment plus fragile qu’un projet dont le créateur s’en va.
Le réflexe qui change tout
Quand vous évaluez la solidité d’une dépendance, ne comptez pas les contributeurs : comptez les employeurs distincts des personnes qui ont le droit de fusionner. Un projet à trois mainteneurs travaillant tous pour la même société a un facteur bus réel de un — celui du budget de cette société. C’est exactement le risque que Btrfs n’a pas couru, parce que Meta et SUSE se partageaient le travail.
Notre avis d’expert nº 1 : le vrai risque n’est pas le départ, c’est le départ silencieux
Ce qui s’est passé le 28 août est le meilleur scénario possible : une annonce publique, un successeur déjà en place, un maintien du rôle de relecture. Toute la chaîne en aval a l’information et peut agir.
Le scénario réellement dangereux ne ressemble pas à cela. Il ne s’annonce jamais. Une bibliothèque continue d’exister, son dépôt reste accessible, sa documentation reste en ligne — et simplement, plus rien n’est fusionné. Les signalements s’accumulent sans réponse. Quand une faille est publiée dix-huit mois plus tard, il n’y a personne pour la corriger.
Sur nos 34 dépendances directes, l’audit a mis au jour deux projets dans cet état. Aucun des deux n’avait annoncé quoi que ce soit. Nous nous en sommes aperçus en regardant la date du dernier correctif fusionné, pas la date du dernier commit — la nuance est importante, car un dépôt peut recevoir des mises à jour de documentation ou de configuration d’intégration continue pendant des mois sans que personne ne traite plus le code.
Notre avis d’expert nº 2 : le nombre de contributeurs est un indicateur trompeur
C’est le chiffre que tout le monde regarde, parce qu’il est affiché en évidence sur les pages de dépôt. Il ne mesure pas ce qu’on croit.
Un contributeur, c’est quelqu’un dont une modification a été acceptée un jour. Cela inclut la personne qui a corrigé une faute de frappe dans la documentation en 2019. Ce qui détermine la survie d’un projet, c’est le nombre de personnes qui peuvent accepter une modification et publier une version.
L’écart est spectaculaire. Sur nos 34 dépendances :
| Indicateur | Médiane | Minimum observé |
|---|---|---|
| Contributeurs historiques | 41 | 3 |
| Contributeurs actifs sur 12 mois | 9 | 0 |
| Personnes ayant fusionné un correctif | 3 | 0 |
| Employeurs distincts représentés | 2 | 0 |
Une bibliothèque affichait 187 contributeurs et une seule personne ayant fusionné quoi que ce soit sur les douze derniers mois. C’est le profil qui inquiète, et il est invisible depuis la page d’accueil du projet.
Vous ne savez pas qui maintient vos dépendances ?
Nous cartographions vos dépendances directes et transitives, avec pour chacune le nombre de personnes autorisées à fusionner, les employeurs représentés et la date du dernier correctif réellement traité. Deux à trois jours, livrable exploitable par la direction technique.
Discutons-en — cartographier mes dépendancesLa matrice que nous utilisons désormais
Un mainteneur unique n’est pas un problème en soi. Une bibliothèque stable, de périmètre restreint, sans faille connue, peut parfaitement vivre dix ans sous la responsabilité d’une seule personne. Le tort serait de traiter les six dépendances critiques identifiées comme six urgences.
Nous croisons donc deux axes : le facteur bus et le coût de remplacement, exprimé en jours-homme pour s’en passer.
- Facteur bus élevé, coût de remplacement faible — rien à faire, c’est le cas le plus fréquent.
- Facteur bus faible, coût de remplacement faible — surveiller, sans plus. Si le projet s’arrête, deux jours suffisent à en sortir.
- Facteur bus élevé, coût de remplacement élevé — situation confortable : le projet est solide et vous en dépendez fortement, c’est un choix assumé.
- Facteur bus faible, coût de remplacement élevé — la seule case qui exige une action. Sur nos 34 dépendances, elle en contenait deux.
Pour ces deux-là, nous n’avons pas migré. Nous avons fait trois choses beaucoup moins coûteuses : figer la version utilisée avec une copie du dépôt sur notre propre infrastructure, documenter en une page ce que ferait une reprise en interne, et — pour l’une des deux — commencer à contribuer, ce qui est la seule manière sérieuse de réduire un facteur bus sans changer de bibliothèque.
Notre avis d’expert nº 3 : la dépendance la plus risquée n’est jamais celle qu’on surveille
Btrfs est un composant du noyau Linux. Il est scruté, discuté, documenté, et son changement de maintenance a fait l’objet d’une annonce publique reprise par la presse spécialisée. C’est le profil d’une dépendance sûre, précisément parce qu’elle est visible.
Les six dépendances à mainteneur unique que nous avons identifiées ne ressemblent pas à cela. Ce sont de petites bibliothèques utilitaires, installées il y a des années pour résoudre un problème précis, jamais remises en question depuis, et dont la plupart des membres de l’équipe ignorent l’existence. Aucune ne ferait l’objet d’un article si son mainteneur s’arrêtait.
C’est aussi pour cela que cet audit se fait sur les dépendances transitives et pas seulement directes. Nos 34 dépendances directes en tirent près de 900. Nous n’avons évidemment pas audité les 900 : nous avons appliqué le filtre du coût de remplacement, qui ramène l’ensemble à une trentaine de lignes réellement structurantes. La méthode d’inventaire est la même que celle que nous détaillons dans notre guide sur l’audit des dépendances npm et de la chaîne d’approvisionnement.
Sur le versant sécurité — que faire quand une dépendance non maintenue porte une faille publiée et sans correctif — les procédures de traitement documentées par WebGuard Agency donnent une trame utilisable directement. Et sur les systèmes à base de modèles de langage, où la question de la réversibilité fournisseur se pose dans des termes très proches, l’analyse publiée par Plug-Tech complète bien le raisonnement.
Un projet open source ne meurt pas quand son créateur s’en va en le disant. Il meurt quand plus personne ne fusionne, et que personne à l’extérieur ne s’en aperçoit pendant dix-huit mois. — Bryan, D-Open
Ce qu’il faut retenir de l’épisode
Le départ de Chris Mason est une bonne nouvelle déguisée en mauvaise : il montre à quoi ressemble une succession réussie dans un projet critique, avec un mainteneur principal déjà en poste dans une autre organisation et un créateur qui reste relecteur.
La question à vous poser n’est donc pas « faut-il s’inquiéter pour Btrfs » — la réponse est non — mais « laquelle de mes dépendances ne bénéficierait pas de ce traitement ». Sur nos 34, il y en avait six, et deux méritaient une action. Comptez deux à trois jours pour obtenir vos propres chiffres.
Si vous êtes en phase de choix technologique plutôt que d’audit, notre guide pour créer une application de gestion de projet intègre désormais ce critère dans la grille de sélection des briques, et celui consacré au lancement d’une application de gestion d’abonnements traite du même sujet côté dépendances d’infrastructure.
Commencez par la date du dernier correctif fusionné
Si vous ne faites qu’une chose cette semaine : pour vos dix dépendances les plus structurantes, relevez la date du dernier correctif de code réellement fusionné — pas le dernier commit. L’exercice prend une heure et révèle les abandons silencieux.
Discutons-en — parler à un ingénieurFAQ : départ de mainteneur et facteur bus
Le départ de Chris Mason met-il Btrfs en danger ?
Non. Il n’assurait plus la maintenance quotidienne depuis plusieurs années — David Sterba, chez SUSE, est le mainteneur principal — et il reste relecteur de code tout en annonçant vouloir poursuivre ses contributions en amont. C’est un exemple de transition ordonnée, à l’opposé du scénario catastrophe généralement associé au facteur bus.
Comment mesurer le facteur bus d’une dépendance ?
Comptez les personnes distinctes ayant fusionné au moins un correctif sur douze mois, et non les contributeurs. Un projet peut afficher deux cents contributeurs et n’avoir qu’une personne capable de valider et publier. Sur nos 34 dépendances, la médiane des contributeurs était de 41, celle des personnes autorisées à fusionner de 3.
Faut-il abandonner une dépendance à mainteneur unique ?
Presque jamais. Une bibliothèque stable, de périmètre restreint et sans faille connue peut vivre dix ans sous une seule responsabilité. Le critère n’est pas le nombre de mainteneurs mais le coût de remplacement : combien de jours vous faudrait-il pour vous en passer. Seule la case « facteur bus faible et remplacement coûteux » exige une action — deux dépendances sur 34 chez nous.
À quelle fréquence refaire cet audit ?
Une fois par an pour la cartographie complète, qui demande deux à trois jours. La liste des dépendances critiques mérite en revanche une revue trimestrielle beaucoup plus légère : dernière version de moins de six mois, canal de signalement de sécurité qui répond. Cette revue a détecté chez nous deux abandons silencieux en dix-huit mois.