Dormant at the core: Inactivity, dependence and exit among the most downloaded npm packages

Le logiciel moderne est rarement construit à partir de zéro. Au lieu de cela, il est assemblé comme une structure massive composée de pièces préfabriquées, où chaque pièce est un petit morceau de code écrit par quelqu'un d'autre. Dans le monde de JavaScript, le système qui maintient ces pièces ensemble s'appelle npm, un entrepôt numérique où les développeurs téléchargent ces paquets de code pour construire tout, des sites web aux applications mobiles. La plupart de ces pièces sont entretenues par des bénévoles qui y travaillent pendant leur temps libre. Lorsqu'un bénévole cesse de travailler sur une pièce, ce morceau de code devient dormant. Il ne se casse pas immédiatement, mais il ne reçoit plus de mises à jour, de corrections de bugs ou de correctifs de sécurité. Cela crée un risque caché : si une pièce largement utilisée cesse d'être mise à jour, les milliers de projets qui dépendent d'elle se retrouvent avec un composant qui ne peut pas être réparé si quelque chose tourne mal. La question n'est pas seulement de savoir si ces pièces cessent d'être mises à jour, mais combien d'entre elles sont réellement dormantes, combien de personnes les utilisent, et si les personnes qui les utilisent savent qu'elles doivent cesser de les utiliser.

Un chercheur nommé Revanth Krishna Maddula s'est donné pour mission d'examiner les parties les plus populaires de ce système. Il a étudié près de seize mille paquets qui sont téléchargés au moins un million de fois chaque semaine. Ce sont les composants centraux de l'écosystème JavaScript, les pièces qui portent le plus de poids. En étudiant l'historique complet de ces paquets jusqu'en octobre 2026, il voulait voir combien d'entre eux avaient cessé de publier de nouvelles versions, combien de personnes les utilisaient encore, et comment le système réagissait lorsqu'une pièce devenait silencieuse. L'étude s'est concentrée sur une définition spécifique de la dormance : un paquet qui n'avait pas publié de version stable et finalisée au cours des deux dernières années. Ce laps de temps a été choisi pour distinguer les pièces qui sont simplement terminées de celles qui ont été abandonnées.

Les résultats révèlent que la dormance est bien plus courante que beaucoup ne pourraient l'imaginer. À la fin de la période d'étude, près de trente-cinq pour cent de ces paquets de premier plan n'avaient pas publié de nouvelle version en deux ans. Ce silence n'était pas limité aux outils obscurs ou rarement utilisés ; il atteignait le cœur même du système. Parmi les cent paquets les plus téléchargés, vingt-six pour cent étaient dormants. En fait, certains de ces paquets silencieux n'avaient pas été mis à jour depuis plus de huit ans. Malgré cette inactivité généralisée, le silence était presque toujours sans interruption. Lorsque le chercheur a vérifié les notes publiques attachées à ces paquets, connues sous le nom de fichiers README, il a constaté que seulement environ trois pour cent des paquets dormants indiquaient explicitement qu'ils n'étaient plus maintenus. La plupart du temps, le code cessait simplement de changer, laissant les utilisateurs deviner si le projet était terminé ou oublié.

Le danger de ce silence est que les parties actives du système sont profondément connectées à ces parties dormantes. L'étude a cartographié les relations entre les paquets et a découvert que plus d'un quart des paquets maintenus activement dépendaient directement d'au moins un paquet dormant. Certains de ces paquets silencieux étaient si centraux qu'ils étaient accessibles via des chaînes de dépendances à partir de plus de mille autres paquets à fort trafic. Beaucoup d'entre eux étaient de petits outils simples qui auraient pu être achevés il y a des années, mais d'autres étaient des modules substantiels qui formaient le fondement de nombreux outils logiciels. Le problème est que les utilisateurs ne peuvent pas facilement faire la distinction entre un outil qui est terminé et un qui a été abandonné, car le système n'offre aucun signal clair pour distinguer les deux.

Lorsqu'une dépendance devient dormante, les personnes qui l'utilisent ne réagissent généralement pas rapidement. L'étude a suivi le temps qu'il fallait aux utilisateurs pour supprimer une dépendance à un paquet qui avait cessé d'être mis à jour. Sur une période de deux ans, les utilisateurs n'ont supprimé qu'environ vingt-sept pour cent de leurs dépendances à des paquets dormants. Ce taux était seulement légèrement supérieur au taux auquel ils supprimaient les dépendances de paquets actifs, suggérant que le simple fait qu'un paquet ait cessé d'être mis à jour n'était pas suffisant pour inciter à l'action. Les chercheurs ont testé si différents types d'avertissements changeaient ce comportement. Ils ont découvert qu'une note dans la documentation du projet n'avait aucun effet détectable sur le fait que les utilisateurs suppriment le paquet. Le seul signal qui a véritablement provoqué une réaction chez les utilisateurs était un avis de dépréciation officiel émis par le registre lui-même. Lorsqu'un paquet dormant était formellement marqué comme obsolète par le système, les utilisateurs supprayaient les dépendances à son égard à un taux de soixante-cinq pour cent. Cet avertissement officiel, qui apparaît aux développeurs lorsqu'ils installent le logiciel, était le seul mécanisme qui a réussi à inciter l'écosystème à s'éloigner du code silencieux.

Il existe également une dimension de sécurité. Bien que la plupart des paquets dormants ne présentaient pas de failles de sécurité connues dans leurs dernières versions, ceux qui en avaient étaient dans une position précaire. L'étude a révélé qu'un petit nombre de paquets dormants portaient des vulnérabilités connues qui ne pouvaient plus être corrigées par leurs mainteneurs d'origine. Comme le code n'était plus mis à jour, ces failles ne pouvaient pas être colmatées par le haut. Les utilisateurs qui dépendaient de ces paquets devaient soit les supprimer, les remplacer par d'autres outils, ou réparer eux-mêmes les failles de sécurité. Cette situation met en évidence une lacune critique dans le système : lorsqu'une partie largement utilisée cesse d'être maintenue, la responsabilité de sa sécurité incombe entièrement aux personnes qui l'utilisent, souvent sans qu'elles ne le sachent.

L'étude conclut que la dormance est un état normal et silencieux pour une grande partie de l'écosystème logiciel. Ce n'est pas nécessairement un défaut si un petit outil est terminé, mais le manque de communication rend impossible pour les utilisateurs de faire la différence. La recherche suggère que le système actuel repose trop sur les suppositions des utilisateurs quant au statut de leurs outils. Le moyen le plus efficace de gérer ce risque est que les mainteneurs utilisent le mécanisme de dépréciation officiel lorsqu'ils cessent de travailler sur un paquet, idéalement en orientant les utilisateurs vers un remplacement. Pour que l'écosystème reste sain, le registre doit rendre la dormance et la dépréciation plus visibles, garantissant que le signal parvienne aux développeurs qui ont besoin de le voir avant qu'un paquet silencieux ne devienne un problème.