Méthode & produit
Refonte d'une application mobile : réparer, refondre ou tout réécrire ?
✱ En résumé
Les signaux qu’une refonte s’impose
Une application ne se dégrade pas du jour au lendemain. Elle accumule des problèmes jusqu'à atteindre un point de bascule. Voici les signaux qui doivent vous alerter — si plusieurs sont réunis, il est temps d'agir.
Les bugs reviennent en boucle
L'app est lente ou plante
La technologie est obsolète
Impossible de faire évoluer le produit
Le prestataire est parti
La note sur les stores chute
L’audit technique d’abord, la décision ensuite
La pire erreur est de décider de réécrire l'app « au feeling » parce qu'elle agace. Avant tout engagement budgétaire, un audit technique pose un diagnostic objectif. Concrètement, on ouvre le capot et on regarde cinq choses.
| Ce qu’on examine | Pourquoi c’est décisif |
|---|---|
| Qualité du code | Lisibilité, structuration, conventions, présence de tests automatisés. Un code propre peut être repris ; un code spaghetti coûte plus cher à comprendre qu'à réécrire. |
| Dette technique | Quantité de raccourcis accumulés, de code dupliqué et de correctifs empilés. C'est elle qui détermine si chaque évolution future sera fluide ou douloureuse. |
| Architecture | Séparation des responsabilités, modularité, dépendance au backend. Une architecture saine permet d'isoler et de remplacer un morceau ; une architecture monolithique impose le tout ou rien. |
| Sécurité & RGPD | Stockage des données sensibles, gestion de l'authentification, fuites potentielles, conformité. Un audit révèle souvent des failles invisibles au quotidien mais critiques en cas de contrôle ou d'incident. |
| Dépendances & maintenabilité | Versions des bibliothèques tierces, support à venir, compatibilité avec les dernières versions d'iOS et d'Android. Une dépendance abandonnée est une bombe à retardement. |
À l'issue de cet audit, vous savez précisément ce qui est récupérable et ce qui ne l'est pas. C'est le socle de toute décision sensée.
Réparer, refondre ou réécrire : la grille de décision
Tout n'est pas blanc ou noir. Entre la rustine et le repart-de-zéro, il existe une voie intermédiaire souvent ignorée : la refonte partielle. Voici comment trancher selon l'état réel de votre application.
| Option | Quand la choisir | Délai | Budget |
|---|---|---|---|
| Réparer | Le code est globalement sain, l'architecture tient la route, mais quelques bugs ou lenteurs gâchent l'expérience. | 1 à 4 semaines | Quelques jours à ~5 000 € |
| Refondre partiellement | Le socle est récupérable mais certains modules sont à bout de souffle, ou l'interface a vieilli et l'app doit gagner de nouvelles fonctionnalités. | 1 à 3 mois | 10 000 – 25 000 € |
| Réécrire de zéro | Techno obsolète, dette technique ingérable, aucune documentation, ou objectifs produit incompatibles avec l'existant. | 2 à 4 mois | 15 000 – 30 000 €+ |
Un piège classique : surestimer le coût de la réécriture par attachement à l'existant. Quand la dette technique est trop lourde, repartir sur une base saine en React Native revient souvent moins cher sur deux ans que de maintenir indéfiniment un code à bout de souffle.
Reprendre un projet legacy proprement
Quand on hérite d'une application développée par un autre prestataire — surtout s'il a disparu — la moitié du travail est administrative avant d'être technique. Quatre chantiers à sécuriser, dans l'ordre.
Étape 1
Récupérer le code source
Étape 2
Reprendre les comptes stores
Étape 3
Récupérer les accès techniques
Étape 4
Préserver les données et les utilisateurs
Si vous êtes en train de choisir le partenaire qui reprendra votre app, nos critères pour bien choisir une agence de développement s'appliquent à l'identique — avec un point en plus : demandez une expérience concrète de reprise de code existant.
Notre approche chez CNTL DIGITAL
Basés près de Toulouse, nous reprenons régulièrement des applications héritées d'autres prestataires. Notre première proposition n'est jamais « on réécrit tout » : c'est un audit gratuit puis une session de cadrage qui aboutit à une recommandation chiffrée et honnête — parfois la conclusion est qu'une simple réparation suffit.
Quand une refonte est justifiée, nous travaillons en sprints de 2 semaines avec des livraisons régulières, en préservant vos utilisateurs et vos données. Vous gardez la maîtrise du code, des comptes stores et de chaque accès — pour ne plus jamais être prisonnier d'un prestataire.
FAQ
Questions fréquentes
1. Peut-on reprendre une application développée par un autre prestataire ?+
Oui, à condition de récupérer le code source complet (idéalement le dépôt Git avec son historique), les accès aux comptes Apple Developer et Google Play, ainsi que le backend et les services tiers. Un audit technique permet d'évaluer en quelques jours si le code existant est récupérable ou s'il vaut mieux repartir sur des bases neuves. Reprendre un projet hérité est une situation très courante : c'est tout à fait faisable avec une méthode rigoureuse.
2. Combien coûte la refonte d'une application mobile ?+
Cela dépend de l'ampleur. Réparer des bugs ciblés peut coûter de quelques jours à environ 5 000 €. Une refonte partielle (modules ou interface) se situe généralement entre 10 000 et 25 000 €. Une réécriture complète d'une app iOS + Android avec backend démarre autour de 15 000 € et monte à 30 000 € ou plus selon la complexité. Un audit préalable est indispensable pour chiffrer juste.
3. Va-t-on garder nos utilisateurs et leurs données lors d'une refonte ?+
Oui, si la refonte est conduite proprement. Tant qu'on conserve les comptes stores existants, l'app est publiée en mise à jour : vos utilisateurs n'ont rien à refaire et gardent leurs comptes. Les données sont migrées de l'ancienne base vers la nouvelle. Le seul cas où l'on perd des utilisateurs, c'est une republication sous un nouveau compte store, à éviter absolument.
4. Faut-il un audit avant de décider de refondre ?+
C'est vivement recommandé. Un audit technique (qualité du code, dette, architecture, sécurité, dépendances) coûte généralement entre 490 et 990 € et vous évite d'engager un budget de refonte à l'aveugle. Il tranche objectivement entre réparer, refondre partiellement ou réécrire, et débouche sur une roadmap chiffrée. C'est le meilleur investissement avant tout chantier de refonte.
5. Combien de temps prend une refonte d'application ?+
Une réparation de bugs prend de 1 à 4 semaines. Une refonte partielle s'étale sur 1 à 3 mois. Une réécriture complète demande généralement 2 à 4 mois en sprints de 2 semaines, avec des livraisons régulières pour valider chaque étape. La durée dépend surtout de la complexité fonctionnelle et de l'état du projet existant.