Achetez l'extension ennuyeuse, pas l'excitante

L'affirmation

Quand vous ajoutez une extension, un module ou une bibliothèque tierce au logiciel qui fait tourner votre entreprise, la liste de fonctionnalités est le critère le moins important à évaluer. Le nombre qui prédit si vous regretterez la décision, c'est le signal d'entretien — à quel point la chose est mise à jour récemment et régulièrement — et à cette aune, la nouvelle extension excitante au jeu de fonctions parfait est généralement le mauvais choix, et l'ennuyeuse qui fait le même travail discrètement depuis six ans est généralement le bon.

Pourquoi l'extension abandonnée est la coûteuse

Une extension n'est pas un achat ; c'est une dépendance que vous portez désormais. Quand la plateforme qui l'exécute publie une mise à jour de sécurité, une extension non entretenue casse, et vous voilà devant un mauvais choix : garder l'extension et sauter la mise à jour, laissant un trou connu ouvert, ou appliquer la mise à jour et perdre une fonction dont votre entreprise dépend. Ni l'un ni l'autre n'est une décision à prendre sous pression, et une extension abandonnée garantit que vous la prendrez un jour.

Les coûts sont concrets. Une extension de commerce non entretenue est un point d'entrée courant dans les rapports de brèche que nous lisons, car les attaquants recherchent précisément les versions vulnérables connues des extensions populaires. Et quand une extension bloque une mise à niveau de plateforme, le contournement — la bifurquer, ou payer quelqu'un pour la corriger — coûte fréquemment plus qu'une année de licence du concurrent entretenu.

Les signaux qui prédisent vraiment la longévité

Avant la liste de fonctions, vérifiez ceci, la plupart en deux minutes :

• Date de la dernière publication. Pas le dernier commit — la dernière vraie publication. Sous six mois, c'est sain ; au-delà de dix-huit mois, c'est un avertissement, aussi fini que le projet paraisse. « Achevé » et « abandonné » produisent des graphes de commits identiques.
• La cadence, pas seulement la fraîcheur. Un rythme régulier de petites publications signale un mainteneur actif. Une rafale d'activité il y a deux ans suivie du silence signale un projet secondaire dont l'auteur est passé à autre chose.
• La rapidité de fermeture des derniers problèmes de sécurité. Regardez le suivi des problèmes. Une vulnérabilité restée ouverte huit mois vous dit exactement quel délai de réponse attendre quand ce sera votre urgence.
• Le facteur d'autobus. Un seul mainteneur est un risque ; quand il se lasse, le projet s'arrête. Plusieurs contributeurs actifs, et le projet survit au départ de n'importe qui.
• Est-ce le métier de quelqu'un. Une extension appuyée par une entreprise à offre payante a une raison financière de continuer à la corriger. Un projet bénévole a de la bonne volonté, réelle mais non contractuelle.

Une comparaison chiffrée

La nouvelle extension n'est pas mal construite. Elle n'a simplement pas d'antécédents, et les antécédents sont la seule chose qui prédit son comportement pendant l'incident que vous n'avez pas encore eu. L'ennuyeuse a répondu à cette question soixante fois.

Quand le neuf est quand même le bon choix

Parfois, la titulaire est réellement pire : elle domine le marché par inertie, elle a des problèmes d'architecture que les mainteneurs ne corrigeront pas, ou le nouveau venu règle un vrai problème que l'ancien ne peut structurellement pas régler. Dans ces cas, adoptez le neuf sciemment — et budgétez le risque. Figez la version, lisez le code dont vous dépendez, et ayez une réponse écrite à « que fait-on si c'est abandonné dans un an ». L'erreur n'est pas de choisir le neuf ; c'est de le choisir pour la liste de fonctions et de découvrir le risque d'entretien plus tard.

Réduisez votre exposition quel que soit le choix

Chaque extension ajoutée est de la surface d'attaque ; la réduction de risque la moins chère, c'est donc moins d'extensions. Avant d'en ajouter une, demandez si la fonction vaut une dépendance permanente ou si un peu de code que vous possédez suffirait. Une fonction de 30 lignes que vous entretenez représente souvent moins de risque total qu'une extension de 30 000 lignes que vous n'entretenez pas, précisément parce que vous pouvez lire les trente lignes et aucune des trente mille.

Vérifiez ce que vous portez déjà :

npm outdated          # a quel point chaque dependance est en retard
npm audit             # vulnerabilites connues dans l'arbre

Faites-le chaque trimestre. La dépendance en retard de trois versions majeures est celle qu'il sera impossible de mettre à jour dans l'urgence, car deux ans de changements cassants se sont accumulés entre vous et la sécurité.