Combien coûte une application mobile en 2026 ?
7 min de lecture
À retenir
- Réécrire coûte 70 à 110 % du prix d’origine ; réparer coûte 25 à 40 %.
- La réécriture est justifiée par l’impossibilité de livrer, pas par le déplaisir de lire le code.
- Une application qui n’a pas de tests n’est pas « à réécrire » : elle est à instrumenter d’abord.
- La stratégie la plus rentable est presque toujours le remplacement progressif, écran par écran.
- Faites un audit chiffré avant de trancher : trois à cinq jours qui évitent souvent six chiffres d’erreur.
« Le code est illisible, on repart de zéro. » Cette phrase est prononcée dans à peu près tous les projets de reprise que nous rencontrons, généralement dans les deux premières heures, et elle coûte en moyenne le prix d’une application complète.
Parfois elle est juste. Le plus souvent, elle traduit l’inconfort naturel qu’on ressent devant du code écrit par quelqu’un d’autre. Voici comment trancher avec des chiffres plutôt qu’avec une impression.
Les trois scénarios et leurs coûts
Prenons une application développée il y a trois ans pour 90 000 €.
| Scénario | Coût | Durée | Risque |
|---|---|---|---|
| Réparer — montées de version, correction ciblée, rafraîchissement visuel | 22 000 – 36 000 € | 6 à 10 semaines | Faible : l’application reste en production |
| Remplacer progressivement — écran par écran, à périmètre constant | 55 000 – 85 000 € | 5 à 9 mois | Moyen : deux bases coexistent un temps |
| Réécrire — repartir d’une page blanche | 65 000 – 100 000 € | 6 à 12 mois | Élevé : rien n’est livré avant la fin |
Le chiffre qui surprend est le troisième. Réécrire coûte rarement moins cher que le développement d’origine, pour une raison simple : vous ne réécrivez pas l’application d’il y a trois ans, vous réécrivez celle d’aujourd’hui, avec les fonctionnalités ajoutées depuis, les cas particuliers accumulés et les règles métier que personne n’a documentées mais que les utilisateurs connaissent par cœur.
Le coût invisible de la réécriture : pendant six à douze mois, vous ne livrez rien à vos utilisateurs. Vos concurrents, eux, continuent. Ce coût d’opportunité n’apparaît sur aucun devis et dépasse souvent le coût du projet lui-même.
Les six signaux qui justifient réellement la réécriture
Un seul suffit. Aucun d’eux n’est « le code est moche ».
1. La technologie n’est plus supportée. Le cadre de développement n’est plus maintenu, ou les magasins imposent une version minimale que votre pile ne peut plus atteindre. Là, il n’y a pas de choix.
2. Personne ne parvient à compiler. Si un développeur compétent ne réussit pas à produire un binaire en une journée, l’application n’est plus maintenable — indépendamment de la qualité du code lui-même.
3. Le coût d’ajout a plus que doublé. Mesurez : une fonctionnalité moyenne coûtait cinq jours il y a deux ans, elle en coûte douze aujourd’hui. C’est le signal économique le plus fiable qui existe.
4. Le modèle de données ne supporte plus le métier. Vous contournez la structure à chaque nouvelle demande, avec des champs détournés de leur usage et des règles codées en dur. C’est la seule forme de dette qu’on ne peut pas rembourser progressivement.
5. Un changement de plateforme est décidé. Passer du natif au cross-platform, ou l’inverse, pour des raisons documentées — le sujet de notre comparatif React Native, Flutter ou natif.
6. Le produit lui-même a changé de nature. L’application ne fait plus ce pour quoi elle avait été conçue. Ce n’est alors pas une refonte, c’est un nouveau produit qui porte le même nom.
Ce qui ne justifie pas une réécriture
« Le code est mal écrit. » C’est presque toujours vrai, et presque jamais suffisant. Du code laid qui fonctionne et qu’on peut modifier vaut mieux que du code élégant qui n’existe pas encore.
« Il n’y a pas de tests. » Ce n’est pas une raison de réécrire, c’est une raison d’écrire des tests — en commençant par les trois parcours critiques. Deux semaines, et la reprise devient possible.
« Ce n’est pas la technologie que nous aurions choisie. » La technologie utilisée par vos concurrents n’a jamais fait vendre un produit. Le seul critère qui compte est de savoir si vous trouvez des gens capables de la faire vivre.
« C’est plus rapide de repartir de zéro. » Dans les faits, ça l’est jusqu’au moment où il faut retrouver les deux cents cas particuliers que l’ancienne application gérait silencieusement. Cette phase représente régulièrement 40 % du projet.
La stratégie qui gagne dans la plupart des cas
Le remplacement progressif combine les avantages des deux approches.
- Auditer et instrumenter (2 à 3 semaines). Remonter les plantages, mesurer les performances, écrire des tests sur les parcours critiques. Vous savez enfin ce qui casse réellement, ce qui est souvent très différent de ce que l’équipe croyait.
- Stabiliser (3 à 5 semaines). Monter les versions, corriger les dix anomalies les plus coûteuses, remettre la chaîne de publication en état. À ce stade, beaucoup de projets s’arrêtent là — et c’est une bonne nouvelle.
- Remplacer par zones (en continu). Un écran ou un module à la fois, avec la nouvelle approche, en gardant l’ancien fonctionnel jusqu’au basculement. Chaque étape est livrable, mesurable et réversible.
Le coût total est comparable à celui d’une réécriture, mais il est étalé dans le temps, et vous livrez en permanence. Surtout, vous pouvez vous arrêter à tout moment si le retour sur investissement n’est plus au rendez-vous — ce qu’une réécriture ne permet jamais.
70–110 %Du coût d’origine pour une réécriture complète
25–40 %Du coût d’origine pour une remise à niveau ciblée
≈ 40 %D’une réécriture consacrée à retrouver les cas particuliers oubliés
Le comparatif sur trois ans
Reprenons l’application à 90 000 €, sur trois ans.
Option « réparer puis maintenir » : 30 000 € de remise à niveau, puis 15 000 € par an. Total : 75 000 €. L’application reste en ligne pendant toute la période et s’améliore par petites touches.
Option « réécrire » : 85 000 € de réécriture sur neuf mois, pendant lesquels rien n’évolue pour les utilisateurs, puis 14 000 € par an de maintenance sur deux ans. Total : 113 000 €, plus neuf mois d’immobilisme.
L’écart est de près de 40 000 €, et il se creuse encore si l’on valorise les fonctionnalités non livrées pendant la réécriture. Ces ordres de grandeur s’articulent avec ceux de notre article sur le coût d’une application mobile et celui sur la maintenance.
Une réécriture se décide sur un chiffre : le coût d’ajout d’une fonctionnalité. Tant que ce chiffre reste acceptable, réécrire revient à payer très cher pour se sentir mieux.
Avant de décider : l’audit
Trois à cinq jours suffisent pour produire une décision documentée : état réel du code, dette chiffrée par module, échéances à risque, et le coût comparé des trois scénarios sur votre cas précis.
C’est le meilleur investissement possible avant un engagement à six chiffres. Nous le réalisons de façon indépendante, y compris quand la conclusion est qu’il n’y a rien à faire — ce qui arrive plus souvent qu’on ne le croit.
