Un client me transmet l’an dernier un projet PHP avec une consigne nette : faire passer le framework de la version 5 à la 9 « d’ici la fin du sprint ». Quatre versions majeures d’écart, deux jours au calendrier. Intenable. Nous avons fait 5 vers 6, lancé les tests, puis 6 vers 7, tests de nouveau, et ainsi de suite jusqu’au bout. Quatre paliers, étalés sur deux semaines. Chacun a livré sa petite surprise, jamais deux le même jour, et c’est exactement ce qui a rendu l’opération tenable. Voilà la méthode, et pourquoi je m’y tiens.
Sur un projet hérité, le grand nettoyage des dépendances en une seule fois mène au mur : trop de ruptures à démêler en même temps. J’avance par paliers, la sécurité en premier, et je relance les tests après chaque étape.
Pourquoi le grand saut casse
Les dépendances se tiennent par la main. Vous montez l’une, elle en réclame une autre, qui en appelle une troisième. Chaque version majeure traîne ses ruptures de compatibilité : une fonction qui disparaît, un comportement qui change sans prévenir. Montez tout d’un coup et ces ruptures s’additionnent ; plus rien ne vous dit laquelle a cassé quoi. Le débogage tourne à l’archéologie. Vous y laissez plus de temps que l’ensemble des paliers réunis.
Le filet d’abord
Avant de toucher quoi que ce soit, je veux des tests sur les chemins critiques. Pas une couverture parfaite. De quoi caractériser le comportement actuel, voilà tout. Sans ce garde-fou, une mise à jour qui décale subtilement une logique passe inaperçue, puis ressort en production trois semaines plus tard, un soir où personne ne fait le lien avec le changement. Avec lui, la bascule se voit sur-le-champ, à l’endroit précis où vous venez d’intervenir.
Trier par le risque, pas par la facilité
Toutes les montées ne pèsent pas pareil, et l’ordre dans lequel je les attaque compte autant que la méthode. Les dépendances porteuses de failles de sécurité connues passent en premier, sans discussion : c’est ce qui expose réellement le projet, aujourd’hui, à quelqu’un qui chercherait la porte. Viennent ensuite les paquets abandonnés, encore fonctionnels mais sans personne aux commandes ; rien d’urgent ce mois-ci, sauf que ça finit toujours par mordre, alors je les planifie plutôt que de les découvrir en catastrophe. Le reste, les montées de confort sans enjeu de sûreté, attend que tout le reste soit stabilisé. La tentation inverse existe : commencer par les mises à jour faciles pour se sentir avancer. Mauvais réflexe. Elle donne l’illusion du mouvement et laisse la vraie dette intacte.
Un palier à la fois
Sauter de la version 2 à la version 7 d’une bibliothèque, c’est s’offrir une journée perdue. Je progresse version majeure par version majeure quand le projet le permet, tests à l’appui après chacune. C’est plus lent. Je ne le cache pas. Mais chaque rupture se traite seule, dans un contexte que je comprends encore. Quand des paquets sont soudés et doivent bouger ensemble, je prends le groupe d’un bloc, en gardant le lot aussi petit que possible.
Là où la méthode atteint sa limite
Reste un cas qu’aucun découpage ne résout : la dépendance sans chemin de sortie. Un paquet mort, aucune version compatible avec le reste de votre pile, aucun successeur évident. Cul-de-sac. Les paliers ne servent plus à rien puisqu’il n’y a nulle part où aller. Il faut alors trancher autrement, trouver un remplaçant ou isoler le morceau derrière une couche maison, et accepter que cette partie du projet reste une dette ouverte, documentée, qu’on rouvrira un jour. La progression prudente vous mène loin ; elle ne vous dispense pas des décisions difficiles quand la route s’arrête.