Refonte d'application mobile : quand et comment la faire ?

Votre application a 3 ans. Elle fonctionne, mais quelque chose cloche. Les utilisateurs se plaignent de lenteurs. Votre équipe met des semaines à ajouter une fonctionnalité simple. Le design commence à paraître daté. Et chaque mise à jour iOS vous donne des sueurs froides.

Faut-il refondre ? Ou simplement améliorer l'existant ?

C'est une question qu'on nous pose régulièrement chez Eurus. Et la réponse n'est jamais simple. Une refonte, c'est un investissement majeur. La lancer trop tôt, c'est gaspiller de l'argent. La retarder trop longtemps, c'est s'enliser dans une dette technique qui finira par tout bloquer.

On a migré le backend DrMilou de PHP vers Java. 3 mois de travail, mais les temps de réponse ont été divisés par 4. Cette refonte était nécessaire. Mais j'ai aussi vu des projets où on aurait pu éviter une refonte complète avec quelques optimisations ciblées.

Alors comment savoir ? Et si la refonte s'impose, comment la mener sans tout casser ?

Les signes qui ne trompent pas

Avant de parler refonte, il faut diagnostiquer. Tous les problèmes ne nécessitent pas une réécriture complète. Certains se règlent avec des corrections ciblées. D'autres, non.

La dette technique est devenue ingérable

La dette technique, c'est l'accumulation de tous les raccourcis pris pendant le développement. Au début, c'est invisible. Puis ça ralentit chaque nouvelle fonctionnalité. Et un jour, ça paralyse complètement le projet.

Comment savoir si vous en êtes là ? Posez-vous ces questions :

Est-ce que l'ajout d'une fonctionnalité simple prend des semaines au lieu de jours ? Est-ce que chaque modification casse quelque chose ailleurs dans l'app ? Est-ce que vos développeurs passent plus de temps à comprendre le code existant qu'à en écrire du nouveau ?

Si vous répondez oui à ces questions, la dette technique a probablement atteint un point de non-retour. Rembourser cette dette bout par bout coûterait plus cher que repartir sur des bases saines.

Les technologies sont obsolètes

Le monde mobile évolue vite. Une app développée il y a 4-5 ans utilise peut-être des technologies qui ne sont plus maintenues. Des frameworks abandonnés. Des versions de langages dépréciées. Des patterns de développement devenus anti-patterns.

Concrètement, ça pose deux problèmes. D'abord, la sécurité : des dépendances non maintenues peuvent contenir des failles connues. Ensuite, la maintenabilité : trouver des développeurs compétents sur des technologies obsolètes devient difficile et coûteux.

Un exemple typique : les apps développées en Objective-C avant la généralisation de Swift. Ou les apps Android en Java avant Kotlin. Elles fonctionnent encore, mais leur évolution devient compliquée.

L'architecture ne supporte plus la charge

Votre app a été conçue pour 1000 utilisateurs. Vous en avez maintenant 50 000. L'architecture qui fonctionnait au début montre ses limites : temps de réponse qui explosent, crashs sous charge, coûts d'infrastructure qui s'envolent.

On peut optimiser, ajouter du cache, scaler horizontalement. Mais parfois, l'architecture de base n'a pas été pensée pour cette croissance. Et aucune optimisation ne suffira.

Les cabinets vétérinaires qui utilisent DrMilou ont des contraintes qu'on n'imaginait pas au départ : connexion internet instable, PC sous Windows XP, urgences qui arrivent pendant qu'on tape une ordonnance. L'architecture initiale ne gérait pas ces cas. Il a fallu repenser certains modules en profondeur.

L'expérience utilisateur est dépassée

Les standards UX évoluent constamment. Selon Forrester, chaque dollar investi en UX génère un retour de 100 dollars (ROI de 9 900%). Ce qui semblait moderne il y a 3 ans peut paraître archaïque aujourd'hui. Navigation complexe, temps de chargement visibles, absence de micro-interactions... Les utilisateurs comparent votre app à celles qu'ils utilisent quotidiennement.

Si votre taux de rétention chute, si les avis sur les stores mentionnent une interface "vieillotte" ou "compliquée", c'est un signal. Une refonte UX peut parfois se faire sans tout réécrire, mais souvent l'interface et le code sont tellement entremêlés qu'il faut toucher aux deux.

Le pivot business impose de nouveaux besoins

Votre entreprise a évolué. Votre app devait faire X, maintenant elle doit faire X, Y et Z. Et l'architecture actuelle n'a jamais été prévue pour ça.

En 3 ans chez Eurus, j'ai vu des projets échouer non pas à cause du code, mais parce que personne n'avait vraiment compris le besoin métier initial. Et quand le besoin change radicalement, l'app qui répondait à l'ancien besoin devient un frein.

Refonte totale ou refonte progressive ?

Une fois le diagnostic posé, reste à choisir l'approche. Deux écoles s'affrontent.

La refonte "Big Bang"

On arrête tout. On repart de zéro. On reconstruit l'app complètement, puis on bascule d'un coup.

Les avantages : pas de compromis avec l'existant, architecture moderne dès le départ, code propre et cohérent.

Les risques : projet long et coûteux, pas de valeur livrée pendant des mois, risque de découvrir des problèmes seulement au lancement, effet tunnel.

Cette approche fonctionne quand l'app existante est vraiment irrécupérable et que vous pouvez vous permettre une période sans évolution.

La refonte progressive (Strangler Pattern)

On remplace l'app morceau par morceau. On isole un module, on le réécrit, on l'intègre. Puis le suivant. Jusqu'à ce que tout l'ancien code ait disparu.

Les avantages : livraison de valeur continue, risques répartis, possibilité d'ajuster en cours de route, pas d'effet "tout ou rien".

Les risques : cohabitation temporaire de deux architectures, complexité de la transition, discipline requise pour ne pas éterniser le processus.

Chez Eurus, on privilégie cette approche quand c'est possible. Elle demande plus de rigueur, mais elle permet de garder le contrôle.

Comment choisir ?

Quelques critères de décision :

Si l'app actuelle est encore utilisable et génère de la valeur, privilégiez la refonte progressive. Vous continuez à servir vos utilisateurs pendant la transition.

Si l'app est tellement cassée qu'elle fait fuir les utilisateurs, une refonte Big Bang peut être justifiée. Mieux vaut une pause temporaire qu'une hémorragie continue.

Si vous changez complètement de technologie (par exemple, passer de natif à Flutter), la refonte progressive devient techniquement compliquée. Le Big Bang s'impose souvent.

Notre règle d'or : un MVP en 6 semaines max. Au-delà, on perd le feedback terrain. Cette règle s'applique aussi aux refontes. Découpez en phases de 6 semaines max avec des livrables concrets à chaque fois.

Méthodologie pour réussir sa refonte

Une refonte, ça se prépare. Voici les étapes clés.

Étape 1 : Auditer l'existant

Avant de reconstruire, comprenez ce que vous avez. Pas seulement le code, mais aussi :

Les fonctionnalités réellement utilisées. Regardez les analytics. Souvent, 80% de l'usage se concentre sur 20% des features. Inutile de refondre des fonctionnalités que personne n'utilise.

Les points de friction utilisateurs. Quels parcours génèrent des abandons ? Quelles fonctionnalités font l'objet de plaintes ?

Les contraintes techniques actuelles. Quelles sont les dépendances critiques ? Les intégrations tierces ? Les spécificités de déploiement ?

DrMilou gère des milliers de dossiers animaux. La plus grosse leçon de notre audit ? Les vétérinaires ont besoin d'accéder aux infos critiques en 2 clics max, pas 5. Cette contrainte a guidé toute la refonte.

Étape 2 : Définir le périmètre

Ne refondez pas tout "parce qu'on y est". Chaque fonctionnalité reconstruite doit être justifiée.

Listez ce qui doit impérativement être refait (problèmes techniques bloquants, dette ingérable). Listez ce qui pourrait être amélioré mais fonctionne. Listez ce qui peut être abandonné.

Cette priorisation évite l'effet "on en profite pour ajouter X, Y, Z" qui transforme une refonte de 3 mois en projet de 18 mois.

Étape 3 : Choisir les technologies

C'est le moment de moderniser votre stack. Mais attention aux effets de mode. Choisissez des technologies :

Éprouvées. Pas la dernière framework sortie il y a 6 mois. Préférez des outils avec un écosystème mature et une communauté active.

Adaptées à vos besoins. Flutter est génial pour le cross-platform, mais si vous avez besoin d'accès hardware pointus, le natif reste pertinent.

Maîtrisées par votre équipe. Ou prévoyez le temps de montée en compétence.

Avec Getaway, on a choisi Flutter pour le cross-platform. Résultat : une seule codebase pour iOS et Android, et 60% de temps dev économisé. Mais ce choix n'est pas universel. Pour DrMilou, le natif était plus adapté aux contraintes métier.

Étape 4 : Planifier les phases

Découpez la refonte en phases autonomes. Chaque phase doit :

Livrer de la valeur utilisateur. Pas juste du refactoring invisible.

Être testable indépendamment. Vous devez pouvoir valider que ça fonctionne avant de passer à la suite.

Avoir une durée maîtrisée. 4 à 6 semaines max par phase.

Exemple de phasage pour une app e-commerce :

• Phase 1 : Refonte du parcours de navigation et catalogue (6 semaines)
• Phase 2 : Refonte du panier et checkout (4 semaines)
• Phase 3 : Refonte de l'espace compte et historique (4 semaines)
• Phase 4 : Refonte du backoffice (6 semaines)

Étape 5 : Gérer la transition

Si vous faites une refonte progressive, la cohabitation ancien/nouveau est délicate.

Prévoyez des feature flags pour basculer progressivement. Testez d'abord sur un groupe restreint d'utilisateurs (beta). Gardez la possibilité de rollback en cas de problème.

Et communiquez avec vos utilisateurs. Prévenez-les des changements à venir. Recueillez leurs retours pendant la transition.

Étape 6 : Migrer les données

Souvent négligée, la migration de données peut faire échouer une refonte. Vos utilisateurs ont des comptes, des historiques, des préférences. Tout doit être préservé.

Prévoyez des scripts de migration. Testez-les sur des copies de production. Prévoyez un plan B si la migration échoue.

Le plus gros challenge sur Getaway ? Gérer les photos offline quand les voyageurs sont dans des zones sans réseau. Lors de la refonte, il a fallu migrer des milliers de photos stockées localement vers la nouvelle architecture. Un cauchemar logistique qu'on avait sous-estimé.

Les erreurs classiques à éviter

En accompagnant des refontes, on voit souvent les mêmes erreurs.

Sous-estimer la complexité

"C'est juste refaire la même chose en mieux." Non. Refaire, c'est comprendre ce qui existe, le repenser, le reconstruire, migrer les données, former les utilisateurs. C'est toujours plus long que prévu.

Multipliez vos estimations initiales par 1.5 minimum. Ce n'est pas du pessimisme, c'est du réalisme.

Vouloir tout améliorer

La refonte n'est pas le moment d'ajouter 50 nouvelles features. Concentrez-vous sur reconstruire l'existant proprement. Les améliorations viendront après, sur des bases saines.

J'ai appris à mes dépens qu'un client qui dit "on en profite pour ajouter ceci" et un client qui tient son planning, c'est rarement le même.

Négliger les tests

Vous reconstruisez une app qui fonctionne (même mal). Les utilisateurs s'attendent à retrouver ce qui marchait. Une régression fonctionnelle dans la nouvelle version, c'est pire que le bug original.

Investissez dans les tests automatisés dès le début. Ils vous sauveront pendant la refonte et après.

Oublier le mobile-first

Si vous refondez une app mobile, pensez mobile d'abord. Pas "on fait le web et on adapte". Les contraintes mobile (écran, réseau, batterie) doivent guider les choix d'architecture.

Perdre les utilisateurs en route

Vos utilisateurs actuels sont habitués à l'app existante. Une refonte qui change tout d'un coup peut les perdre, même si objectivement c'est mieux.

Introduisez les changements progressivement quand possible. Proposez des tutoriels pour les nouvelles interfaces. Et écoutez les retours : si tout le monde se plaint du même changement, c'est peut-être vous qui avez tort.

Combien coûte une refonte ?

La question qui fâche. La réponse honnête : ça dépend.

Une refonte légère (modernisation UX, optimisations techniques ciblées) peut coûter 20 à 40% du budget de développement initial.

Une refonte majeure (changement de technologie, réécriture complète) coûte souvent autant, voire plus, que le développement initial. Logique : vous refaites tout, avec en plus la contrainte de migrer l'existant.

En ordre de grandeur :

• Refonte légère d'une app simple : 15 000 à 30 000€
• Refonte majeure d'une app simple : 30 000 à 60 000€
• Refonte d'une app complexe : 60 000 à 150 000€+

Ces chiffres sont indicatifs. Seul un audit précis de votre situation permet une estimation fiable.

Questions fréquentes

Peut-on refondre par phases tout en gardant l'app en production ?

Oui, c'est le principe de la refonte progressive. Mais ça demande une architecture qui le permet (API bien découplée, modules indépendants) et une rigueur dans l'exécution. Si l'app actuelle est monolithique, il faudra d'abord la modulariser.

Faut-il garder la même équipe de développement ?

Idéalement, oui. L'équipe qui a construit l'app connaît son histoire, ses choix, ses pièges. Mais si l'équipe d'origine n'est plus disponible ou si vous voulez changer de prestataire, assurez-vous d'une bonne passation de connaissances.

Combien de temps dure une refonte ?

Une refonte légère : 2 à 4 mois. Une refonte majeure : 4 à 8 mois, parfois plus pour les apps complexes. Méfiez-vous des promesses de refonte complète en quelques semaines.

Peut-on refondre une partie de l'app seulement ?

Absolument. C'est même souvent la meilleure approche. Identifiez le module le plus problématique, refondez-le, mesurez l'impact, puis décidez de la suite.

La refonte va-t-elle perturber mes utilisateurs ?

Potentiellement, oui. Mais une refonte bien menée minimise la perturbation : migration transparente des données, introduction progressive des changements, communication claire. À terme, les utilisateurs apprécient une app plus rapide et plus moderne.

Et si je reconstruisais tout avec du no-code ?

Ça peut être tentant pour simplifier, mais attention : le no-code a ses limites (performances, personnalisation, scalabilité). Si votre app actuelle a atteint ces limites, le no-code les atteindra aussi. Évaluez honnêtement vos besoins avant de vous lancer.

Conclusion

Une refonte d'application mobile est une décision importante. Ni à prendre à la légère, ni à repousser indéfiniment quand les signaux sont là.

Les clés du succès : un diagnostic honnête de la situation actuelle, un périmètre bien défini, une approche progressive quand c'est possible, et une exécution rigoureuse.

Et surtout, gardez l'utilisateur au centre. Une refonte réussie, c'est une refonte que les utilisateurs ne subissent pas, mais dont ils bénéficient.

---

Vous vous demandez si votre application a besoin d'une refonte ? Ou vous savez qu'il faut y aller mais vous ne savez pas par où commencer ?

Contactez l'équipe Eurus pour un audit gratuit de votre application. On vous dira honnêtement ce qui peut être sauvé et ce qui doit être refait.