Comment refondre un produit sans tout casser.
La refonte la plus risquée n'est pas celle qui va trop loin — c'est celle qui commence par l'écran plutôt que par le diagnostic.
La refonte la plus risquée n'est pas celle qui va trop loin — c'est celle qui commence par l'écran plutôt que par le diagnostic.
« Il faut tout refaire » est souvent la première phrase qu'on entend face à un produit qui freine. C'est presque toujours la mauvaise réponse. Une refonte qui rase tout jette autant de valeur qu'elle en crée — et prend le risque d'interrompre un service qui, pour l'essentiel, fonctionne encore.
Face à un produit vieillissant, la tentation du grand soir est forte : tout reconstruire, sur une stack propre, avec une interface repensée de zéro. Sur le papier, c'est séduisant. Dans les faits, c'est le scénario qui casse le plus souvent : le projet s'étire, le service se dégrade pendant la transition, et une partie de ce qui fonctionnait déjà se perd en route.
Refondre sans tout casser part d'un principe inverse : on ne jette que ce qui freine réellement. Le reste continue de tourner pendant qu'on répare ce qui coince.
Ce n'est pas la refonte qui est risquée. C'est de la lancer sans savoir précisément ce qu'elle doit réparer.
Tout ce qui semble daté ne mérite pas d'être refait. Un produit peut avoir une interface vieillissante et rester parfaitement fonctionnel sur le fond. Le travail commence par trier : ce qui bloque réellement les utilisateurs ou l'équipe, et ce qui n'est qu'une gêne esthétique — traitable plus tard, ou pas du tout.
Une refonte qui ne casse rien suit un ordre précis — et ne commence jamais par l'interface :
Deux éléments réduisent concrètement le risque de régression pendant une refonte progressive :
Sans ces deux garde-fous, chaque incrément de refonte recrée le risque qu'on cherchait justement à éviter en évitant le big bang.
En diagnostiquant avant de refaire : identifier ce qui freine, isoler ce qui doit être gardé, recadrer la logique et les parcours critiques, puis refondre par incréments plutôt qu'en un seul big bang.
Rarement tout. La plupart des refontes réussies isolent ce qui fonctionne déjà et concentrent l'effort sur les parcours et l'architecture qui freinent réellement le produit.
En découpant la refonte en chantiers priorisés et en les livrant par incréments, plutôt qu'en tentant un remplacement complet en une seule fois.
Oui. Un design system structuré sert de socle stable pendant la refonte : il évite de reconstruire chaque écran à partir de zéro et limite les régressions visuelles d'un chantier à l'autre.