Votre application tourne, mais sa stack a pris un coup de vieux. AngularJS, une version de PHP en fin de vie, une bibliothèque qui n’est plus maintenue depuis des années. Recruter devient difficile, chaque changement prend plus de temps qu’avant, et les correctifs de sécurité se font rares. La question n’est plus de savoir s’il faut moderniser, mais comment le faire sans casser ce qui marche.
Le piège de la réécriture complète
La tentation, c’est de tout jeter et de repartir propre. C’est presque toujours une erreur. Une réécriture complète, c’est des mois sans aucune nouvelle valeur pour vos utilisateurs, un risque réel que la nouvelle version ne reproduise pas tous les comportements de l’ancienne, et un projet qui, une fois sur deux, s’enlise avant d’aboutir. Votre application actuelle contient des années de règles métier, y compris celles que personne n’a documentées.
La méthode progressive
Il existe une meilleure approche : entourer l’ancienne application et la remplacer morceau par morceau. On construit le nouveau code à côté de l’ancien, on redirige un parcours à la fois vers la version moderne, et l’ancienne partie disparaît une fois qu’elle n’est plus utilisée. À chaque étape, l’application reste en production et continue de servir vos clients. Le risque est découpé en petits morceaux au lieu d’un seul grand saut.
Par où commencer
Commencez par ce qui fait le plus mal, ou par ce qui est le plus dangereux. Une dépendance qui présente une faille de sécurité connue passe avant une refonte esthétique. Un module que vous modifiez toutes les semaines vaut mieux qu’un coin de l’app que personne ne touche jamais. On modernise là où ça rapporte, pas là où c’est le plus visible.
Gardez l’application en service
Le principe non négociable : à aucun moment vos utilisateurs ne doivent subir une coupure. Chaque bascule est réversible, testée sur les parcours critiques, et déployée progressivement. Une migration réussie, c’est une migration que personne ne remarque de l’extérieur.
Quand une réécriture complète se justifie quand même
Il y a des exceptions. Une application minuscule, ou une stack si morte qu’on ne parvient même plus à la faire tourner, peut se refaire d’un bloc. Mais c’est rare, et cela se décide après un audit, pas par principe. Dans la grande majorité des cas, la migration progressive coûte moins cher et met bien moins en danger.
Une stack obsolète n’oblige pas à tout recommencer. Elle demande un plan, de la patience, et une modernisation par étapes. C’est exactement ce que je mets en place sur une reprise de projet : j’audite l’existant, je définis l’ordre des étapes, et je modernise sans jamais arrêter votre application.
Votre stack est devenue un frein ? Faites un audit. Je vous donne un plan de migration réaliste, étape par étape.
Questions fréquentes
Peut-on migrer sans arrêter l’application ? Oui. C’est même le but de l’approche progressive : l’ancienne et la nouvelle version coexistent, et la bascule se fait parcours par parcours.
Combien de temps prend une migration progressive ? Plus longtemps qu’une réécriture sur le papier, mais sans les mois d’arrêt et sans le risque de tout perdre. Vous gardez de la valeur livrée en continu.
Faut-il changer toute la stack d’un coup ? Non. On remplace les couches une par une, en commençant par les plus risquées ou les plus coûteuses à maintenir.