Votre application existante ne suit plus le rythme : technologie obsolète, fonctionnalités qui manquent, performances qui dégradent. Faut-il la refondre complètement ou la faire évoluer par étapes ? Voici comment trancher selon l'état réel du code et les enjeux business.
Refonte vs évolution : poser la question
La décision entre refondre une app et la faire évoluer ne se prend pas par préférence : c'est un calcul. Coût et durée de chaque option, vs valeur business attendue, vs risque technique acceptable.
La refonte totale est coûteuse, longue et risquée, mais parfois la seule option viable. L'évolution est moins risquée mais peut s'avérer une fuite en avant si la dette technique est vraiment trop lourde.
Quand la refonte s'impose
| Signal | Ce que ça veut dire |
|---|---|
| Stack technique obsolète | Versions plus maintenues, sécurité fragile, recrutement difficile |
| Dette technique bloquante | Chaque feature prend 3× plus de temps qu'au début, instabilité fréquente |
| Performances dégradées | L'app rame, plante, frustre les utilisateurs, perte d'adoption |
| Architecture inadaptée | Le besoin a fondamentalement changé, l'archi initiale ne convient plus |
| Connaissance perdue | Personne ne connaît plus le code, doc inexistante, accès perdus |
Quand mieux vaut faire évoluer
Si l'app tourne, le code est sain, la stack est maintenue, la dette est gérable : évolution par étapes presque toujours.
- L'app rend toujours service à ses utilisateurs.
- Les nouvelles features peuvent être ajoutées sans tout casser.
- La stack est moderne (ou modernisable progressivement).
- Le coût d'évolution est raisonnable par rapport au gain.
- Vous avez accès au code, à la doc, à l'équipe qui a construit (ou un nouveau prestataire qui peut reprendre).
Le strangler pattern : refonte progressive
Avantage : pas de big bang, valeur livrée en continu, possibilité de pivoter en cours. Limite : demande une architecture pensée pour la coexistence (API en façade, état partagé). Pas toujours applicable mais souvent la meilleure option.
La méthode en 3 étapes
Audit technique de l'existant
État du code, dépendances, dette, architecture, performances. Évaluation honnête de ce qui est récupérable et de ce qui doit partir.
Scénarios chiffrés
Refonte totale (coût + durée + risque), évolution par étapes (coût + durée + limites), strangler progressif (coût + durée). Comparer aux enjeux business.
Plan d'exécution choisi
Mise en œuvre du scénario retenu : refonte d'un coup, évolution continue ou strangler. Suivi serré pour ajuster.
Pour faire auditer une application existante et arbitrer entre refonte et évolution, prévoyez un premier appel. Voir aussi Applications & SaaS.
Questions fréquentes
Quels signaux indiquent qu'une refonte totale est nécessaire ?
Plusieurs cumulés : la stack est obsolète(versions plus maintenues), la dette techniqueempêche d'avancer (chaque feature prend 3× plus de temps qu'au début), les performances sont dégradées au point de bloquer les utilisateurs, le besoin a fondamentalement changé. Un seul signal ne suffit pas.
Combien coûte une refonte totale ?
Souvent autant qu'un build initial, parfois plus (il faut comprendre l'existant). Comparer le coût d'une refonte au coût d'une évolution douloureuse étalée sur 2 ans : parfois la refonte est plus économique sur la durée. À cadrer au cas par cas.
Que faire si le prestataire original n'est plus là ?
Récupérer le code source (repository Git), la documentation, les accès. Faire faire un audit technique par un nouveau prestataire pour évaluer la dette et les options. Si tout est propre : évolution possible. Si c'est cassé ou opaque : refonte souvent obligatoire.