Votre application mobile a grossi trop vite. Chaque nouvelle fonctionnalité prend plus de temps que la précédente, les bugs reviennent, et l'équipe hésite à toucher au code. Arrive la question qui coûte cher dans les deux sens : faut-il tout réécrire de zéro, ou migrer progressivement l'existant ? J'ai vécu ce choix chez WeMoms, où j'ai piloté la réécriture complète d'une app Android vieillissante vers Kotlin et Jetpack Compose pour viser le marché américain. Voici les critères qui permettent de trancher sans se tromper.
Les deux vrais chemins : réécriture ou migration progressive
Ce ne sont pas deux niveaux d'ambition, mais deux stratégies avec des risques opposés. La réécriture parie sur un saut net au prix d'une longue période sans livrer de valeur visible. La migration livre en continu mais oblige à faire cohabiter ancien et nouveau code pendant des mois. Le bon choix dépend de l'état réel de votre codebase, pas d'une préférence de principe.
Quand la réécriture complète se justifie
L'architecture est un cul-de-sac. Quand les fondations empêchent toute évolution (couplage total, aucune séparation des responsabilités, technologie abandonnée), rustiner coûte plus cher que reconstruire.
La technologie n'est plus maintenue. Un framework mort ou une version de plateforme que les stores refusent bientôt force la main.
Le produit change de nature. Si l'app doit viser une nouvelle échelle ou un nouveau marché, comme WeMoms visant les États-Unis, les exigences de performance et de qualité changent de catégorie.
Personne ne comprend plus le code. Quand l'auteur d'origine est parti et que chaque modification est une loterie, la dette est devenue ingérable. Attention : réécrire suppose de disposer du temps et du budget pour tenir plusieurs mois sans livrer de nouveauté visible aux utilisateurs.
Quand la migration progressive est le bon choix
L'app fonctionne et a des utilisateurs. Tant que le produit vit et rapporte, l'arrêter des mois pour une réécriture est un risque business majeur.
L'architecture est récupérable. Si la base est saine mais mérite une modernisation (passage à Jetpack Compose ou SwiftUI, remise à plat d'un module), on remplace par zones.
L'équipe doit continuer à livrer. La migration permet de mêler modernisation et nouvelles fonctionnalités, sans geler la feuille de route.
Sur Android, Jetpack Compose est conçu pour cohabiter avec l'ancien système de vues : on peut migrer écran par écran. Côté iOS, SwiftUI s'intègre de la même façon dans une app UIKit existante. Cette interopérabilité est précisément ce qui rend la migration progressive réaliste aujourd'hui.
Réécriture ou migration : le comparatif
| Critère | Réécriture complète | Migration progressive |
|---|---|---|
| Risque business | Élevé : longue période sans valeur livrée | Maîtrisé : le produit reste en production |
| Rapidité des premiers résultats | Lente : rien de visible avant des mois | Rapide : chaque zone migrée est livrée |
| Complexité technique | Concentrée au démarrage | Étalée : ancien et nouveau doivent cohabiter |
| Idéal quand | Architecture morte, changement d'échelle | App vivante, base récupérable |
| Coût de renoncement | Tout ou rien si le projet s'arrête | Chaque étape livrée est déjà un gain |
Aucune stratégie n'est meilleure dans l'absolu. Le bon choix dépend de l'état de votre code, de votre trafic et de votre capacité à tenir une période sans livraison visible.
Le piège du grand soir : pourquoi tant de réécritures échouent
Le périmètre enfle. On veut en profiter pour tout améliorer, et la nouvelle app n'atteint jamais la parité avec l'ancienne.
On oublie les cas limites. L'ancienne app contient des années de correctifs invisibles pour des situations réelles. Repartir de zéro, c'est risquer de tous les réintroduire un par un.
Le business n'attend pas. Pendant la réécriture, les concurrents avancent et les utilisateurs réclament des nouveautés que l'équipe ne peut pas livrer. Quand la réécriture est vraiment nécessaire, il faut la cadrer strictement : viser d'abord la parité fonctionnelle, geler les ajouts, et livrer par lots plutôt qu'en un seul basculement.
Ce que la refonte WeMoms a appris
La leçon vaut au-delà de ce cas : une refonte réussie garde toujours un pied dans le produit qui tourne. Que vous réécriviez ou migriez, la question n'est jamais seulement technique, c'est un arbitrage entre risque, délai et valeur livrée. Pour situer le budget d'une telle opération, voyez combien coûte une application mobile.
Questions fréquentes sur la refonte d'application mobile
Vaut-il mieux réécrire ou migrer une application mobile existante ?
Dans la majorité des cas, la migration progressive est plus sûre : elle garde l'app en production et livre de la valeur en continu. La réécriture complète ne se justifie que lorsque l'architecture est un cul-de-sac, que la technologie n'est plus maintenue, ou que le produit change d'échelle. Le critère décisif est votre capacité à tenir plusieurs mois sans livrer de nouveauté visible.
Combien de temps prend la refonte d'une application mobile ?
Cela dépend de la stratégie et du périmètre. Une migration progressive s'étale mais livre des résultats dès les premières semaines, écran par écran. Une réécriture complète demande souvent plusieurs mois avant d'atteindre la parité avec l'app existante. Le facteur le plus déterminant est la taille de la surface fonctionnelle à couvrir, pas la technologie choisie.
Peut-on migrer vers Jetpack Compose ou SwiftUI sans tout réécrire ?
Oui, c'est précisément ce que ces frameworks permettent. Jetpack Compose cohabite avec l'ancien système de vues Android, et SwiftUI s'intègre dans une app UIKit existante. On peut donc migrer écran par écran, en gardant l'app fonctionnelle à chaque étape. C'est ce qui rend la modernisation progressive réaliste aujourd'hui.
Pourquoi les réécritures complètes échouent-elles souvent ?
Trois raisons reviennent : le périmètre enfle car on veut tout améliorer en même temps, on oublie les années de correctifs invisibles pour des cas limites réels, et le business n'attend pas pendant que l'équipe reconstruit. Une réécriture réussie vise d'abord la parité fonctionnelle, gèle les ajouts, et livre par lots plutôt qu'en un seul basculement.
Faut-il refaire le design en même temps que la refonte technique ?
Pas nécessairement, et souvent il vaut mieux séparer les deux. Mêler une refonte technique et une refonte visuelle multiplie les variables et rend les régressions difficiles à isoler. Une approche prudente modernise d'abord les fondations, puis fait évoluer le design par étapes une fois la base saine.
David Silvera
Développeur mobile & web freelance · 15 ans · Android, iOS, React Native, Next.js
15 ans à développer des applications mobiles pour Mappy, WeMoms, Accor, Voodoo, le WFP (ONU) et d'autres. J'interviens à distance pour des clients à Paris, en Île-de-France et partout en France.
Discutons de votre projet