Refaire son application de zéro ou la sauver ? Comment décider

Pour décider s'il faut refaire une application de zéro ou la sauver, il faut mesurer l'état réel du code, puis comparer trois options : stabiliser l'existant, le remplacer progressivement module par module, ou tout réécrire. La modernisation progressive est en général la moins risquée, car une réécriture complète gèle les évolutions pendant des mois et jette des années de corrections. Refaire de zéro se justifie quand la technologie n'est plus maintenue, quand l'architecture ne peut pas porter la suite du produit ou quand l'app est enfermée dans une plateforme. Cette décision doit suivre un audit, pas le précéder.

Les informations ci-dessous sont à jour à la date d'octobre 2026.

Pourquoi la question « sauver ou refaire » revient-elle si souvent ?

La question « faut-il refaire notre application ? » revient quand chaque évolution devient lente, risquée ou chère : développeur parti, app qui ne compile plus avec les outils exigés par les stores, corrections qui en cassent d'autres, technologie qui bloque une fonctionnalité.

Souvent aussi, un nouveau développeur propose de bonne foi de tout reprendre « proprement ». Joel Spolsky, dans Things You Should Never Do, Part I, en donne la raison : « It's harder to read code than to write it. » L'envie de réécrire n'est pas, à elle seule, un diagnostic.

Quelles sont les trois options possibles ?

Face à une application en difficulté, il existe trois options : la sauver en la stabilisant, la refaire progressivement module par module, ou la refaire de zéro.

1. Sauver et stabiliser. On garde le code et on le remet en état : montée de versions, dépendances remplacées, tests sur les parcours critiques. C'est souvent l'option la plus rentable quand le problème vient du retard accumulé plutôt que de la conception. Pour une app React Native, c'est typiquement une migration vers une version récente et vers la New Architecture, détaillée dans notre article sur la New Architecture.

2. Refaire progressivement. On construit le nouveau à côté de l'ancien et on y déplace les fonctions une par une, jusqu'à pouvoir retirer l'ancien code. Martin Fowler a popularisé ce principe sous le nom de Strangler Fig, le figuier étrangleur qui pousse autour d'un arbre hôte jusqu'à le remplacer. Sur mobile, on peut ajouter des écrans React Native dans une app native existante, ce que prévoit la documentation React Native, ou installer Capacitor à côté de Cordova, qui peuvent cohabiter selon le guide officiel de Capacitor. Deux systèmes cohabitent un temps, mais chaque étape livre de la valeur.

3. Refaire de zéro. On reconstruit toutes les fonctions dans un nouveau projet, puis on bascule les utilisateurs. C'est l'option la plus risquée. Elle reste parfois la seule raisonnable, par exemple pour une app no-code dont on ne peut pas exporter le code, comme expliqué dans notre article sur la sortie de Bubble.

Pourquoi la réécriture complète est-elle si risquée ?

Une réécriture complète est risquée parce qu'elle jette des corrections invisibles, gèle le produit et oblige à reproduire des comportements non documentés.

Les corrections invisibles. Selon Joel Spolsky, chaque ligne qui paraît inutilement compliquée est souvent la correction d'un bug rencontré par un utilisateur : « When you throw away code and start from scratch, you are throwing away all that knowledge. »

Le temps perdu. Son exemple est Netscape : quand il écrit, la version 6.0 entre en bêta publique, il n'y a jamais eu de version 5.0, et la 4.0 date de presque trois ans. La part de marché de Netscape s'est effondrée entre-temps. Spolsky qualifie la décision de réécrire de « single worst strategic mistake that any software company can make ».

Les comportements à redécouvrir. Martin Fowler, dans la version d'août 2024 de son article, note que les détails du comportement existant sont difficiles à retrouver ; ce plan d'apparence simple, écrit-il, « go down in flames most of the time », et les utilisateurs ne peuvent pas attendre les nouvelles fonctionnalités pendant tout le remplacement.

Quels critères regarder pour décider ?

Six critères comptent pour décider entre sauver et refaire une application : la qualité du code et ses tests, l'état de la technologie, l'architecture face aux besoins futurs, la valeur de l'existant, la connaissance de l'équipe, et le budget comparé au risque sur le délai.

1. Code et tests. La question n'est pas « le code est-il beau ? » mais « peut-on le modifier sans tout casser ? ». La dette est-elle localisée ou généralisée ?
2. Technologie. Une technologie vivante mais en retard de plusieurs versions se migre. Une technologie abandonnée, ou une plateforme sans export du code, impose tôt ou tard une reconstruction.
3. Architecture. Listez ce que le produit doit faire dans les dix-huit prochains mois (hors ligne, temps réel, nouvelles plateformes) et vérifiez si l'existant peut l'accueillir. Si une seule zone bloque, on refait cette zone, pas toute l'app.
4. Valeur de l'existant. Utilisateurs actifs, données, fiche store bien notée : plus ce capital compte, plus une bascule brutale est dangereuse.
5. Équipe. Si l'équipe connaît le code, le sauver coûte beaucoup moins cher. Sinon, reconstituer cette connaissance par un audit reste en général moins coûteux qu'une réécriture.
6. Budget et délai. Une réécriture se paie deux fois : le projet, et les évolutions qui n'auront pas lieu pendant ce temps. Demandez-vous ce qui se passe si le projet prend deux fois plus de temps que prévu.

Comment combiner ces critères dans un tableau de décision ?

Ce tableau associe les situations les plus fréquentes à l'option qui y répond le mieux ; une même app peut relever de deux lignes.

Qu'est-ce qui change quand l'application est sur les stores ?

Une application publiée sur l'App Store et Google Play doit être refaite comme une mise à jour de la même fiche, sinon vous perdez la base installée, les notes et les avis. Quatre points se vérifient avant d'écrire la première ligne.

Le même bundle ID et le même package name. Selon la documentation Apple, une fois un build envoyé dans App Store Connect, le bundle ID d'une fiche ne peut plus être modifié : changer d'identifiant oblige à créer une nouvelle fiche. Selon Android Developers, si l'application ID change, Google Play traite l'envoi comme une application complètement différente. La nouvelle app reprend donc ces identifiants.

La même clé de signature Android. Une mise à jour Android n'est acceptée que si elle est signée avec le même certificat. Selon la documentation de signature Android, une clé perdue sans Play App Signing empêche de publier toute mise à jour. Vérifiez qui détient la clé et les comptes Apple Developer et Google Play.

Les notes et les avis. Ils sont attachés à la fiche, pas au code, et une mise à jour les conserve. Apple propose de réinitialiser la note globale à la sortie d'une version ; selon l'aide App Store Connect, c'est irréversible une fois la version publiée, et les avis écrits restent affichés.

Les données, y compris sur le téléphone. Les données serveur se migrent par un script testé à blanc. On oublie plus souvent celles stockées sur l'appareil (session, préférences, brouillons) : une app dans une autre technologie ne les lit pas forcément au même endroit, il faut donc un code de reprise.

Enfin, déployez progressivement : Apple propose une publication par phases sur 7 jours, de 1 % à 100 % des utilisateurs en mise à jour automatique, et Google Play des déploiements progressifs que l'on peut interrompre.

Que change une réécriture en React Native ou Capacitor ?

Réécrire en React Native ou en Capacitor donne une base de code commune pour iOS et Android, mais ne supprime ni la migration des données ni le travail natif.

React Native convient quand on part d'apps natives séparées (Swift, Kotlin) ou d'une ancienne version de React Native. Il produit des interfaces natives et s'intègre écran par écran dans une app existante : c'est la voie naturelle d'un remplacement progressif.

Capacitor convient quand l'essentiel de l'app est du code web (Cordova, Ionic, site React, Vue ou Angular). Il garde ce code web et remplace la couche native autour, souvent sans réécrire l'interface.

Dans les deux cas, les modules natifs spécifiques (paiement, Bluetooth, SDK tiers) se reprennent un par un.

Pourquoi décider après un audit, et pas avant ?

La décision de sauver ou refaire une application doit suivre un audit, parce que les critères ci-dessus se mesurent dans le code. Un audit établit le retard de versions, les dépendances abandonnées, la localisation de la dette, les tests existants, et qui détient les comptes et les clés.

Il évite deux erreurs symétriques : lancer une réécriture alors qu'une migration aurait suffi, ou rafistoler pendant des années une app dont la technologie est condamnée.

Check-list avant de choisir entre sauver et refaire

• J'ai accès au code, aux comptes Apple Developer et Google Play, et à la clé de signature Android.
• Je connais le retard de versions, les dépendances abandonnées et les tests existants.
• J'ai listé les besoins produit des dix-huit prochains mois.
• Je connais le bundle ID et le package name à conserver.
• Je sais quelles données du téléphone doivent être reprises.
• J'ai fait réaliser un audit avant de choisir.

Pour repérer les problèmes avant de trancher, voyez les 10 signes d'une application mobile mal construite. Si le projet a déjà déraillé, commencez par Refonte d'application ratée : que faire maintenant ?

Se faire accompagner

Pour trancher entre sauver, reprendre en partie et refaire, l'Audit de reprise d'application de GUIGUI Tech coûte 1 500€ HT et est livré en 5 jours ouvrés, pour une app React Native, Expo, Capacitor, Ionic ou Cordova, une application web React, Next.js ou Vue.js, ou du code généré avec Lovable ou Bolt : récupération des accès, analyse du code, de l'architecture, des dépendances et de la sécurité, conformité aux stores, verdict avec plan chiffré et priorisé, rapport PDF et appel de restitution. L'audit est déduit du prix des travaux si vous confirmez dans les 30 jours.

Si votre app React Native fonctionne et qu'il s'agit seulement de la faire monter de version, l'Audit Migration React Native, au même prix, débouche directement sur un plan de migration ; il est déduit de la Migration React Native complète (à partir de 18 000€ HT, 4 à 8 semaines, au forfait) ou de la mise à jour Expo / New Architecture si vous confirmez dans les 30 jours.

Pour une app Cordova ou Ionic, la Migration Cordova / Ionic vers Capacitor démarre à 9 500€ HT, sur 3 à 6 semaines, en gardant votre code web et le même bundle ID. Pour une app Bubble, Adalo ou FlutterFlow, l'offre Sortir du no-code démarre à 15 000€ HT, sur 6 à 12 semaines ; le prix ferme est fixé après un audit de faisabilité à 800€ HT sur 2 jours.