Reprise ou refonte d'une application : comment décider

La réponse courte

Dans la plupart des cas, reprendre ce qui fonctionne coûte moins cher et comporte moins de risques que tout réécrire. Une refonte complète se justifie quand la structure empêche toute évolution, ou quand la plateforme interdit d'en sortir. Un diagnostic de quelques jours permet de trancher avec des éléments précis, plutôt qu'au ressenti.

Trois décisions possibles

Après un diagnostic, une application se retrouve dans l'une de ces trois situations.

• Stabiliser : le fond est sain. On corrige les points fragiles, on ajoute des tests, on sécurise les accès et on documente.
• Migrer par étapes : une partie reste, une autre est remplacée progressivement, par exemple en changeant de base de données ou de plateforme.
• Reconstruire : la structure empêche toute évolution raisonnable. On repart d'une base propre en réutilisant la logique métier.

Quatre questions pour décider

1. La logique métier est-elle correcte ? Si les règles sont justes, elles se conservent même si le code change. Si elles sont fausses ou inconnues, il faut d'abord les écrire.
2. Les données sont-elles exploitables ? Une base propre se migre. Une base incohérente ajoute un chantier de nettoyage, quelle que soit la décision.
3. Peut-on modifier sans tout casser ? Si oui, la stabilisation suffit. Si non, il faut d'abord ajouter des tests sur les parcours qui comptent.
4. La plateforme est-elle un verrou ? Une application construite sur un outil sans export du code oblige à reconstruire la logique ailleurs.

Ce que change l'outil utilisé

• Lovable, Bolt, Replit. Le code se récupère le plus souvent via GitHub ou un export. Il se lit, se teste et se corrige : une reprise est presque toujours possible.
• Cursor, Claude Code. Le code existe et reste lisible, mais il est rarement testé ou documenté. La reprise consiste à sécuriser, tester et documenter.
• Bubble et autres outils no-code. L'outil ne fournit pas d'export du code de l'application. On reconstruit la logique ailleurs et on migre les données : c'est une migration par étapes ou une reconstruction.
• Automatisations assemblées au fil de l'eau (Zapier, Make, tableurs). Le sujet est moins le code que les règles : on les écrit avant de décider.

Le coût d'une réécriture complète

Une réécriture est plus longue que prévu, parce qu'elle doit retrouver toutes les règles que l'ancien outil appliquait sans qu'elles soient écrites. Pendant ce temps, l'ancien outil continue de tourner, de se dégrader et de recevoir des demandes de modification. C'est la raison pour laquelle un diagnostic précis précède toute décision de reconstruction.

Cinq vérifications avant de décider

1. Quels sont les parcours qui font vivre l'activité (inscription, paiement, import, envoi) ?
2. Qui connaît les règles métier, et sont-elles écrites quelque part ?
3. Quand la dernière sauvegarde a-t-elle été restaurée ?
4. Peut-on modifier une fonction sans casser les autres ?
5. Que coûte la plateforme chaque mois, et que coûterait la sortie ?

Si deux réponses ou plus sont « on ne sait pas », un diagnostic est utile avant toute décision.

Comment procéder

Le diagnostic de 3 jours donne une décision écrite avec les risques, les options et le coût de chacune. Son prix est déduit de la mise en production si vous poursuivez. Voir reprise et mise en production d'application et, pour les applications générées par IA, du vibe coding à la production. Pour vérifier vous-même l'état de votre application, lisez l'article 20 points à vérifier avant la mise en production.