Refonte ou reconstruction

La décision se présente d’ordinaire comme une question de budget — la refonte serait l’option bon marché, la reconstruction l’option chère — et se tranche selon le chiffre que l’équipe peut défendre. Ce cadrage produit régulièrement la mauvaise réponse, parce que les deux ne sont pas deux tailles du même travail.

Une refonte change l’apparence du produit et son organisation. Une reconstruction change la matière dont il est fait. Elles corrigent des défauts différents, et appliquer l’une au problème de l’autre produit une version coûteuse de ce que vous aviez déjà.

La question qui les sépare

Demandez où se trouve réellement le problème : dans les décisions, ou dans la matière ?

Si les gens ne trouvent pas les choses, si la structure ne correspond à la façon dont personne ne pense le travail, si le produit a l’air assemblé plutôt que conçu — ce sont des décisions. Du code neuf les reproduira fidèlement.

Si chaque modification prend une semaine, si personne ne peut dire ce qui va casser, s’il existe des états que l’équipe ne peut pas atteindre pour les tester — c’est la matière. Une nouvelle couche de design se pose dessus et ne change rien à la lenteur de livraison.

Reconstruire pour corriger un problème de design vous donne le même produit dans du code plus récent. Refondre pour corriger un problème d’ingénierie vous donne un produit plus beau qu’on a toujours peur de modifier.

Les signaux d’une refonte

• Le support répond sans cesse à la même question « où est… ». C’est un problème de structure, et la structure est une décision de design.
• La navigation a vu apparaître un « Plus ». Presque toujours le moment où un modèle a cessé de convenir sans que personne n’y revienne.
• Le produit a débordé son propre vocabulaire. Il a été conçu pour une chose et en fait trois, avec les mots d’origine encore sur les boutons.
• L’équipe décrit le produit autrement que l’interface. Quand le discours et les écrans divergent, ce sont les écrans qui sont périmés.
• Cela fonctionne, mais personne n’en est fier. Un vrai signal, et pas de la vanité : sur un marché concurrentiel, avoir l’air non entretenu se lit comme ne pas être entretenu.

Les signaux d’une reconstruction

• Les estimations ont cessé d’avoir un sens. De petits changements visibles coûtent ce que devraient coûter de grands, et personne ne sait expliquer la différence à l’avance.
• Il existe du code que personne ne veut toucher. Non parce qu’il est complexe — parce que les conséquences d’y toucher sont inconnues.
• Le même bug revient ailleurs. Signe que l’on corrige des symptômes parce que la cause est hors d’atteinte.
• Vous ne pouvez pas l’exécuter de façon réaliste. Aucun moyen de voir les états qui comptent sans données de production, donc ils ne sont jamais vraiment testés.
• La plateforme en dessous arrive en fin de vie. Une dépendance sans chemin de mise à jour est une échéance, que quelqu’un l’ait écrite ou non.

Notez qu’aucun de ces points ne parle d’apparence, et qu’aucun de la liste précédente ne parle de vitesse. Quand un produit montre des signaux des deux listes, il a deux problèmes, et l’étape utile est de le dire à voix haute plutôt que de choisir un mot pour le projet.

L’option qui ne figure sur aucune diapositive

Les deux mots décrivent un remplacement total. La plupart des produits n’en ont pas besoin, et la version « tout d’un coup » est l’endroit où les réécritures meurent : une longue période avec deux produits, l’un qui rapporte et l’autre qui absorbe l’attention, et une date de lancement qui recule parce qu’il faut être complet avant d’être utile.

La version incrémentale remplace une surface à la fois, derrière le produit existant, si bien que chaque morceau est livré et rapporte de lui-même. C’est moins satisfaisant à planifier et bien plus difficile à abandonner à mi-chemin, ce qui est son principal avantage : une migration incrémentale à l’arrêt laisse un produit qui fonctionne, une réécriture à l’arrêt en laisse deux cassés.

Cela permet aussi de séparer les deux problèmes dans le temps. Reprenez la matière sous la pire surface d’abord, puis refondez-la ; ou refondez la structure sur la matière existante et reconstruisez dessous plus tard, une fois la forme stabilisée.

Quand il s’agit d’un site vitrine, pas d’un produit

Pour un site plutôt qu’une application, le calcul diffère : la matière est peu coûteuse et les décisions font presque tout. Un site vitrine est un ensemble fixe de pages dont le travail est d’être compris et d’être trouvé.

Là, la question de la reconstruction est plus étroite qu’elle n’en a l’air — non pas « quel framework » mais « que contient cette page avant qu’un script ne s’exécute », ce qui relève plus souvent de l’étape de build que de l’architecture. C’est développé dans React ou Next.js pour un site vitrine.

HYS Games illustre cette forme : un projet client, le site web d’un studio de jeu, conçu et développé de bout en bout, où la structure et la matière ont été décidées ensemble plutôt que l’une héritée de l’autre.

Comment trancher concrètement

1. 01Notez les cinq reproches que vous entendez le plus, dans les mots employés par les gens.
2. 02Classez chacun en décisions ou en matière. Ce que vous n’arrivez pas à classer est probablement un symptôme — suivez-le jusqu’à ce qu’il tombe d’un côté.
3. 03Si ce sont presque tous des décisions, vous avez une refonte, et reconstruire d’abord reviendrait à refaire le travail de design deux fois.
4. 04Si c’est presque tout de la matière, refondre d’abord repeint ce qui vous ralentit réellement.
5. 05Si c’est partagé, nommez les deux, prenez celui qui bloque l’autre, et faites-le en premier — de façon incrémentale, pour que l’autre puisse commencer avant la fin.

Si vous pesez ce choix et que la liste ressort partagée, dites-nous ce que vous construisez.