Dossier — BlogRefonte

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.

« 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.

01 — Le piègeTout refaire n'est pas une méthode

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.

Distinguer ce qui freine de ce qui gêne

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.

02 — La méthodeQuatre temps, dans cet ordre

Une refonte qui ne casse rien suit un ordre précis — et ne commence jamais par l'interface :

  1. Diagnostic : identifier ce qui freine réellement, ce qui coûte, ce qui mérite d'être gardé tel quel.
  2. Recadrage : remettre d'aplomb l'architecture de l'information et les parcours critiques, avant de toucher aux écrans.
  3. Refonte ciblée : retravailler l'expérience et le design system sur les seules zones identifiées.
  4. Découpage en incréments : livrer par chantiers priorisés, jamais en un seul big bang.

03 — Le socleCe qui limite la casse pendant la refonte

Deux éléments réduisent concrètement le risque de régression pendant une refonte progressive :

Un design system structuré
Un socle commun, pour ne pas reconstruire chaque écran isolément
Des chantiers priorisés
Livrés un par un, sans interrompre le service en cours

Sans ces deux garde-fous, chaque incrément de refonte recrée le risque qu'on cherchait justement à éviter en évitant le big bang.

04 — QuestionsAvant de lancer une refonte

Comment refondre un produit sans tout casser ?

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.

Faut-il tout refaire ou seulement une partie ?

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.

Comment éviter d'interrompre le service ?

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.

Un design system aide-t-il vraiment ?

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.

Un produit à recadrer, pas raser ?