Les mises à jour qu'on ne peut pas repousser, et celles qui peuvent attendre

Les deux postures qu’on rencontre sur les mises à jour sont également mauvaises et elles se renforcent l’une l’autre. La première consiste à vouloir tout tenir à jour en permanence : c’est ingérable sur un projet moderne qui compte plusieurs centaines de dépendances publiant chacune à son rythme, et personne ne le fait réellement plus de trois mois. La seconde, qui suit généralement l’abandon de la première, consiste à ne rien toucher tant que rien ne casse. Elle fonctionne un certain temps, puis produit un chantier de rattrapage dont le coût n’a plus aucun rapport avec le travail qu’il aurait fallu faire au fil de l’eau.

La règle que j’applique tient en trois classes, et son mérite principal est qu’elle permet de décider en trente secondes, sans réunion, ce qui part cette semaine.

Les trois classes

Classe	Critère	Quand	Qui décide
Sécurité	Vulnérabilité publiée touchant un composant exposé	Cette semaine, sans arbitrage	L’alerte automatisée
Compatibilité	Fin de support annoncée, ou rupture imposée par un tiers	Planifiée avant l’échéance	Revue mensuelle
Confort	Nouvelle fonctionnalité, refactorisation, version mineure sans enjeu	Quand on touche déjà ce composant	Personne — ça se fait ou pas

La force de ce découpage est qu’il retire l’arbitrage là où il coûte cher. Une mise à jour de sécurité ne se discute pas : elle part. Une mise à jour de confort ne se planifie pas : elle se fait à l’occasion, ou pas du tout, sans que cela crée de dette.

La sécurité doit être détectée par un automate

Le point le plus important de cette classe n’est pas la rapidité d’application, c’est la détection.

Une veille de sécurité qui repose sur quelqu’un qui lit des bulletins n’est pas une pratique, c’est une intention. Elle tient tant que la personne est disponible et attentive, et elle cesse silencieusement pendant les vacances, les périodes chargées, ou après un départ.

L’automatisation est un réglage, pas un chantier : un outil d’analyse branché sur le dépôt compare en continu les versions installées aux vulnérabilités publiées. Deux conditions pour qu’il serve : l’alerte doit arriver sur un canal que quelqu’un lit — pas un rapport hebdomadaire dans une boîte partagée — et elle doit distinguer ce qui est réellement exposé de ce qui ne l’est pas. Une vulnérabilité dans un outil de développement qui ne tourne jamais en production ne mérite pas de réveiller quelqu’un ; la même dans une dépendance servant des requêtes publiques, si.

Sans cette distinction, l’équipe reçoit trop d’alertes, apprend à les ignorer, et le dispositif devient pire qu’inexistant puisqu’il donne l’illusion d’une couverture.

Le coût d’une montée de version croît beaucoup plus vite que le temps qui passe. Trois versions majeures de retard ne coûtent pas trois fois une version : elles coûtent un projet.

La compatibilité se planifie, elle ne s’improvise pas

La deuxième classe est celle qui produit les mauvaises surprises, parce que l’échéance vient de l’extérieur.

Une plateforme de commerce retire une version d’API. Un fournisseur de paiement annonce la fin d’un protocole. Un environnement d’exécution atteint sa fin de support. Dans chacun de ces cas, une date est publiée à l’avance — souvent des mois — et l’organisation ne la découvre qu’au moment où quelque chose cesse de fonctionner.

Le dispositif qui l’évite est modeste : une revue mensuelle de trente minutes portant sur trois questions. Qu’est-ce qui a été publié depuis la dernière fois. Qu’est-ce qui accuse plus d’une version majeure de retard. Qu’est-ce qui approche d’une fin de support annoncée.

Cette revue produit un calendrier plutôt qu’une liste de tâches. Une montée de version majeure prévue trois mois à l’avance est un chantier borné ; la même découverte deux semaines avant l’échéance est une urgence qui déplace tout le reste.

La règle du retard maximal

Un seul seuil suffit à gouverner cette classe, et je le formule toujours de la même manière : jamais plus d’une version majeure de retard sur les composants structurants.

Le raisonnement est arithmétique. Une montée d’une version majeure suppose de lire les notes de rupture d’une version, d’adapter le code concerné, de tester. Deux versions de retard supposent de faire la même chose deux fois, mais sans pouvoir valider entre les deux — les ruptures s’empilent, les interactions se multiplient, et le diagnostic d’une régression ne dit plus laquelle des deux montées l’a causée.

Le coût ne croît donc pas linéairement avec le retard. C’est pourquoi une équipe qui a trois versions majeures de retard ne fait plus de la maintenance : elle a un projet, avec un budget et une date, et il faut le nommer comme tel.

Ce qui rend tout cela possible

Aucune de ces trois classes ne se pratique sereinement sans deux capacités préalables, et il faut le dire franchement à un client qui veut acheter de la maintenance sans les avoir.

Un retour arrière dont on connaît le délai. Appliquer une mise à jour sans savoir revenir en arrière transforme chaque montée de version en pari. C’est ce qui pousse les équipes à ne rien toucher — et le fait de ne rien toucher est précisément ce qui rend la prochaine montée dangereuse.

Des tests qui couvrent le chemin d’achat. Pas une couverture exhaustive, qui n’existe nulle part : le parcours qui va de la fiche produit à la confirmation de commande, exécuté automatiquement après chaque mise à jour. C’est ce qui permet d’appliquer une montée de version un mardi matin sans mobiliser personne pour cliquer partout.

Ces deux capacités sont les mêmes qui rendent le jour de la semaine indifférent pour un déploiement¹. Une équipe qui les possède applique ses mises à jour en continu et n’a jamais de chantier de rattrapage. Une équipe qui ne les possède pas les repoussera, quelle que soit la qualité de son contrat de maintenance — et c’est par là qu’il faut commencer.

---

Footnotes

1. Sur le retour arrière mesuré, le découplage entre déploiement et activation, et ce qu’ils changent au risque, voir Le déploiement du vendredi. ↩