Une refonte peut rester bloquée pendant des mois : nouvelle application presque terminée, ancienne version toujours en production, fonctionnalités présentes d’un côté mais pas de l’autre et date de bascule sans cesse repoussée. Changer d’équipe ne répond pas encore à la question essentielle : faut-il achever le travail, consolider l’ancien produit ou recommencer ?
La bonne décision se prend à partir de preuves techniques et produit, pas à partir du temps ou de l’argent déjà dépensé.
Pourquoi les refontes d’application se bloquent-elles ?
Une refonte échoue rarement à cause d’un seul mauvais choix technologique. Les causes se cumulent souvent :
- périmètre qui grandit pendant le développement ;
- reproduction à l’identique de fonctions peu utilisées ;
- absence de responsable capable d’arbitrer ;
- dette technique découverte trop tard ;
- migration des données sous-estimée ;
- API, mobile et infrastructure traités comme des projets séparés ;
- manque de tests sur les parcours essentiels ;
- équipe instable ou transmission incomplète ;
- déploiement final pensé seulement à la fin.
Avant de choisir une solution, il faut identifier le mécanisme qui bloque réellement les livraisons. Réécrire le code sans corriger l’organisation reproduira souvent le même résultat.
Première étape : établir deux états des lieux
L’audit doit comparer l’application en production et la refonte. Pour chacune, vérifiez les parcours disponibles, les bugs connus, les technologies, les dépendances, les tests, la sécurité, les données et la capacité de déploiement.
Il faut également dresser un état produit : quels parcours sont utilisés, lesquels génèrent de la valeur, quelles promesses ont été faites aux clients et quelles fonctions pourraient être retirées ? Une refonte bloquée peut parfois être livrée rapidement en réduisant son périmètre à ce qui est réellement nécessaire.
Option 1 : stabiliser l’application actuelle
Conserver temporairement l’ancienne version est pertinent lorsqu’elle remplit encore sa mission, que les incidents restent maîtrisables et que la refonte n’est pas assez avancée pour une mise en production proche.
Cette option permet de sécuriser les utilisateurs pendant que l’équipe clarifie la suite. Elle exige toutefois une limite : investir sans fin dans l’ancien produit peut repousser indéfiniment la transition. Les corrections doivent viser la disponibilité, la sécurité et la compatibilité indispensables.
Option 2 : terminer la refonte engagée
Terminer est souvent le meilleur choix lorsque :
- les principaux parcours sont déjà fonctionnels ;
- l’architecture peut évoluer sans obstacle majeur ;
- la migration des données est comprise ;
- les technologies restent maintenues ;
- le produit peut être livré par étapes ;
- le reste à faire peut être estimé après audit.
Il faut résister à la tentation d’ajouter « tant qu’on y est » toutes les améliorations imaginées pendant le retard. Un périmètre de bascule explicite, suivi d’itérations courtes, redonne une date vérifiable au projet.
Option 3 : réécrire progressivement
Repartir de zéro n’est justifié que si l’existant empêche réellement la suite : technologie abandonnée, architecture incompatible avec les besoins, modèle de données devenu incohérent ou niveau de risque impossible à réduire raisonnablement.
Même dans ce cas, une réécriture totale en tunnel est rarement souhaitable. Il est souvent possible de remplacer un composant à la fois : une API, un espace d’administration, un parcours mobile ou un traitement métier. Les deux versions coexistent alors pendant une période organisée.
Une grille de décision simple
| Question | Si la réponse est oui |
|---|---|
| La production est-elle actuellement dangereuse ou instable ? | Stabiliser avant toute autre décision |
| La refonte couvre-t-elle les parcours essentiels ? | Étudier une livraison à périmètre réduit |
| Le code peut-il être testé et déployé ? | Chiffrer le reste à faire |
| Une contrainte structurelle bloque-t-elle les évolutions ? | Remplacer progressivement le composant concerné |
| Le problème principal vient-il des priorités ? | Corriger la gouvernance avant l’architecture |
Le coût passé ne doit pas dicter la décision. Seuls comptent le risque futur, la valeur livrable et le coût restant de chaque scénario.
Comment reprendre la refonte avec une nouvelle équipe ?
La nouvelle équipe doit d’abord reproduire les environnements, lancer les tests, déployer une version et cartographier les écarts fonctionnels. Elle produit ensuite un plan avec trois horizons : sécurisation immédiate, bascule minimale et évolutions postérieures.
Le guide faire reprendre le développement d’une application existante détaille la transmission, les accès et le plan des 30 premiers jours. Un audit technique avant reprise permet d’objectiver la décision.
Ce que montre la reprise de MyTwiga
Lors de la reprise technique de MyTwiga, Farrago a trouvé plusieurs chantiers engagés simultanément : applications mobiles, nouvelle API et infrastructure. La réponse n’a pas été de tout recommencer. L’audit des dépôts, la clarification du backlog et des cycles de livraison courts ont permis de terminer les refontes utiles et de remettre les applications en production.
Une refonte bloquée n’est donc pas nécessairement perdue. Il faut retrouver un chemin de livraison, réduire le périmètre et décider composant par composant.