Mettre à jour ou figer : le calcul qui manque
Repousser les mises à jour semble prudent à court terme. Le coût est reporté, avec intérêts, sur une migration devenue impossible à découper.
Une mise à jour peut casser quelque chose. Ne pas la faire ne casse rien aujourd’hui. Le calcul paraît évident, et il est faux — parce qu’il compare un coût immédiat à un coût différé jamais chiffré.
Le coût croît plus vite que le temps
Passer d’une version à la suivante est un travail limité : quelques changements documentés, une recette ciblée.
Rattraper quatre versions de retard n’est pas quatre fois ce travail. Les changements se sont composés, les guides de migration se chaînent, les bibliothèques annexes ne suivent plus, et l’ensemble ne se découpe plus en étapes livrables. Ce qui aurait été quatre chantiers d’une journée devient un chantier de trois semaines — que personne n’ose lancer, ce qui aggrave encore la situation.
Trier par exposition, pas par numéro de version
Toutes les dépendances ne demandent pas la même vigilance.
Prioritaires : ce qui traite une entrée venant de l’extérieur — le langage lui-même, le serveur web, la couche de traitement des requêtes, la bibliothèque de rendu des gabarits, tout ce qui manipule un fichier envoyé par un visiteur. Une faille y est directement exploitable.
Secondaires : les outils qui ne tournent qu’en développement, ou une bibliothèque de calcul qui ne voit jamais de donnée externe.
Ce tri permet de mettre à jour souvent là où ça compte, sans imposer un rythme irréaliste partout.
Le tableau qui suffit à décider
Une page, quatre colonnes : dépendance, version utilisée, dernière version disponible, statut de maintenance du projet amont.
Ce tableau se produit automatiquement, se relit sans compétence technique, et rend visible la seule information qui compte vraiment : cette version reçoit-elle encore des correctifs de sécurité ?
Une dépendance dont le projet amont est abandonné est un sujet à traiter, quelle que soit sa stabilité apparente.
Ce qui rend la mise à jour supportable
Des tests automatisés, même partiels. Sans eux, chaque montée de version impose une recette manuelle complète, ce qui explique la plupart des reports.
Couvrir les trois ou quatre parcours critiques suffit à changer la nature de l’exercice : lancer les tests, voir ce qui échoue, corriger. Le filet n’a pas besoin d’être complet pour supprimer la peur.
Quand figer est le bon choix
Un système clos, sans accès réseau, dont la fonction ne changera pas : le figer est défendable, à condition que la décision soit écrite, datée, et accompagnée de son échéance de réexamen.
La différence entre figer et négliger tient entièrement dans cette écriture.