Une application mobile vieillit plus vite qu’un site web. Chaque année, Apple et Google publient une nouvelle version majeure de leur système d’exploitation, relèvent leurs exigences de publication, font évoluer leurs règles de design et déprécient des API. Pendant ce temps, les attentes des utilisateurs progressent au rythme des applications qu’ils utilisent tous les jours. Une app lancée il y a quatre ou cinq ans, même bien conçue à l’origine, finit presque toujours par accumuler de la dette technique, des parcours datés et des coûts de maintenance qui grimpent. Chez Aventique, nous concevons et faisons évoluer des applications mobiles depuis 2012 : nous avons repris des applications existantes pour Loox ou Citruce, publié des V2 complètes comme pour MelloPlot, et nous accompagnons aujourd’hui des produits à très forte audience comme l’application SEPHORA. Voici comment décider s’il faut refaire son application, et comment mener cette refonte sans casser ce qui fonctionne.

Refonte, évolution ou réécriture : de quoi parle-t-on ?

Le mot « refonte » recouvre en réalité trois niveaux d’intervention très différents, qu’il faut distinguer dès le départ car ils n’ont ni le même coût ni le même risque.

La refonte UX/UI porte sur l’interface et les parcours : nouvelle charte graphique, réorganisation de la navigation, simplification des écrans clés, mise en conformité avec les dernières guidelines iOS et Android. Le code métier et le backend restent en place. C’est ce que nous avons réalisé pour Loox, application de réservation de salons de beauté et de bien-être : reprise en main de la version existante, audit du code source, puis refonte de l’UI avant d’enrichir le produit (paiement Stripe, parrainage, codes promotionnels).

La refonte technique conserve globalement les fonctionnalités mais remplace le socle : changement de framework, réécriture d’un module critique, migration d’un backend vieillissant, montée de version majeure. L’utilisateur voit peu de différence, mais l’équipe gagne en vitesse, en stabilité et en sécurité.

La refonte complète combine les deux : on repart d’une page presque blanche, en capitalisant sur la connaissance du produit, les données et les retours utilisateurs de la version précédente. C’est l’option la plus lourde, à réserver aux cas où l’existant bloque réellement la croissance.

Les signaux qui doivent vous alerter

Il n’existe pas d’âge fixe au-delà duquel une application doit être refaite. En revanche, certains signaux reviennent systématiquement dans les audits que nous menons.

• Le taux de crash augmente à chaque nouvelle version d’iOS ou d’Android, et les correctifs s’enchaînent sans régler le fond du problème.
• Chaque évolution coûte de plus en plus cher : une fonctionnalité simple demande plusieurs semaines parce qu’elle touche du code fragile, non testé ou mal documenté.
• La technologie n’est plus maintenue par son éditeur ou sa communauté.
• Les stores durcissent leurs règles et l’application peine à s’y conformer : niveau d’API Android cible, SDK iOS récent, déclarations de confidentialité, suppression de compte in-app.
• Les notes baissent et les avis mentionnent la lenteur, l’ergonomie ou des bugs récurrents.
• Le produit a changé : nouvelle cible, nouveau modèle économique, nouvelles intégrations avec le SI, que l’architecture d’origine n’avait pas anticipées.

Le cas de la dépendance technologique mérite une attention particulière. Au début des années 2010, plusieurs frameworks multiplateformes promettaient de mutualiser le code iOS et Android. Nous avons nous-mêmes utilisé Appcelerator Titanium sur des projets comme BYMOV ou Push2Bank, avec de bons résultats à l’époque. L’éditeur ayant depuis arrêté son support commercial, les applications qui en dépendent encore sont aujourd’hui des candidates naturelles à une refonte vers Flutter, React Native ou le natif Swift et Kotlin. Le même raisonnement s’applique aux applications natives écrites en Objective-C et Java, comme la première version de Trading Sat : elles fonctionnent, mais recruter et maintenir sur ces langages devient plus difficile d’année en année.

Commencer par un audit, pas par des maquettes

L’erreur la plus fréquente consiste à démarrer une refonte par le design. Avant de dessiner le moindre écran, il faut objectiver l’état de l’existant. Notre audit de reprise couvre quatre dimensions.

L’audit technique

Nous analysons la qualité du code, la couverture de tests, les dépendances et leur niveau de maintenance, l’architecture (séparation des couches, gestion d’état, appels réseau), la sécurité du stockage local et des échanges avec le backend, ainsi que la chaîne de build et de publication. Les points de sécurité sont passés au crible des référentiels que nous détaillons dans notre guide pour sécuriser une application mobile.

L’audit produit et usage

Les données analytics disent ce que les utilisateurs font vraiment : écrans les plus visités, points d’abandon, fonctionnalités jamais utilisées. Les avis des stores et les retours du support disent ce qu’ils ressentent. Croiser les deux permet souvent de supprimer 20 à 30 % des fonctionnalités d’une V1 sans que personne ne s’en plaigne, ce qui allège d’autant la refonte.

L’audit du backend et des intégrations

Une application mobile n’est que la partie visible d’un système. Si les API sont lentes, mal versionnées ou couplées à un monolithe difficile à faire évoluer, refaire uniquement le front mobile ne résoudra rien. Selon les cas, nous recommandons une évolution progressive du backend, par exemple en exposant de nouvelles API en Node.js ou NestJS devant un système existant, une approche que nous détaillons dans notre article sur la migration d’une application legacy.

L’audit de conformité stores

Nous vérifions enfin l’écart entre l’application et les exigences actuelles d’Apple et Google : version d’API cible, déclarations de confidentialité, gestion des permissions, format de publication. Cet écart détermine souvent l’urgence de la refonte.

Refonte progressive ou « big bang » ?

Une fois l’audit posé, deux stratégies s’offrent à vous.

La refonte progressive remplace l’application écran par écran ou module par module. En natif, on peut par exemple introduire SwiftUI ou Jetpack Compose dans une application UIKit ou Android View existante. Avec Flutter ou React Native, il est possible d’intégrer des modules dans une application native existante (« add-to-app » côté Flutter, intégration brownfield côté React Native). Cette approche limite le risque, permet de livrer de la valeur en continu et convient aux applications dont l’architecture reste saine.

La refonte « big bang » consiste à développer une nouvelle version en parallèle, puis à la publier en remplacement de l’ancienne. Elle s’impose lorsque le socle est obsolète ou que le changement de framework est total. Elle exige un gel fonctionnel partiel de l’ancienne version, une gestion rigoureuse de la migration des données et un plan de bascule soigné.

Dans la pratique, nous combinons souvent les deux : un nouveau socle technique livré d’un bloc, puis une refonte fonctionnelle par itérations successives une fois l’application en production.

Choisir la stack de la nouvelle version

La refonte est le bon moment pour réinterroger les choix technologiques. Nos architectes s’appuient sur trois critères : la nature du produit, la capacité de l’équipe à maintenir la solution dans la durée, et le coût total de possession.

• Flutter est souvent notre recommandation pour une refonte complète iOS et Android avec une interface très personnalisée : un seul code source, un rendu identique sur les deux plateformes et d’excellentes performances d’animation.
• React Native est pertinent lorsque l’entreprise dispose déjà de compétences JavaScript ou TypeScript côté web, comme chez Clariane où nos développeurs interviennent à la fois sur React, React Native et NestJS.
• Le natif Swift et Kotlin reste le meilleur choix pour les applications qui exploitent intensivement les capacités du terminal ou qui doivent intégrer les nouveautés d’Apple et Google dès leur sortie. C’est le socle de l’application SEPHORA, sur laquelle nos développeurs iOS et Android interviennent.
• Kotlin Multiplatform permet de partager la logique métier tout en gardant des interfaces natives, une option intéressante pour les refontes progressives que nous analysons dans notre article sur Kotlin Multiplatform.

Pour arbitrer entre ces options, notre comparatif Flutter ou React Native et notre guide des frameworks de développement mobile donnent une grille de lecture détaillée.

Repenser l’expérience sans perdre vos utilisateurs

Une refonte UX réussie n’est pas celle qui change le plus de choses, mais celle qui améliore les parcours clés sans désorienter les utilisateurs fidèles. Quelques principes guident notre travail.

Nous partons des parcours à plus forte valeur (inscription, recherche, réservation, paiement) et mesurons leur taux de complétion avant et après. Nous prototypons les nouveaux écrans et les testons auprès d’utilisateurs réels avant développement, selon la démarche décrite dans notre article sur la maquette d’application mobile. Nous alignons l’interface sur les guidelines actuelles (Human Interface Guidelines côté Apple, Material Design 3 côté Android) et intégrons l’accessibilité dès la conception, désormais attendue pour de nombreux services depuis l’entrée en application de l’European Accessibility Act. Nous détaillons cette démarche dans notre guide consacré à l’UX/UI design d’application mobile.

Pour TSA Algérie, par exemple, notre travail de design a consisté à adapter l’identité du site web mobile existant vers une interface pensée pour l’application, plutôt que de tout réinventer : les lecteurs retrouvaient leurs repères, avec une ergonomie propre au mobile.

Réussir la bascule : données, stores et communication

Le jour de la mise en production concentre la plupart des risques d’une refonte. Trois sujets doivent être préparés en amont.

La migration des données et des sessions. Les utilisateurs ne doivent ni perdre leurs données locales (favoris, brouillons, préférences), ni être déconnectés sans raison. Nous prévoyons des scripts de migration du stockage local et une compatibilité ascendante des tokens d’authentification.

La continuité sur les stores. Pour conserver les notes, les avis et le référencement acquis, la nouvelle version doit être publiée comme une mise à jour de la fiche existante, avec le même identifiant d’application et le même certificat de signature. Un déploiement progressif (phased release sur l’App Store, déploiement par paliers sur Google Play) permet de surveiller les crashs sur une fraction des utilisateurs avant d’ouvrir à tous. Notre guide pour publier une application sur l’App Store et Google Play détaille ces mécanismes.

La cohabitation des versions. Tous les utilisateurs ne mettent pas à jour immédiatement. Le backend doit donc servir l’ancienne et la nouvelle version pendant une période de transition, avec, si nécessaire, un mécanisme de mise à jour forcée pour les versions trop anciennes.

Combien coûte et combien de temps dure une refonte ?

Le budget d’une refonte dépend du niveau d’intervention retenu. Une refonte UX/UI sur une base technique saine représente généralement une fraction du coût initial de l’application. Une refonte complète s’approche du coût d’un nouveau développement, avec un avantage : le périmètre fonctionnel est connu et peut être rationalisé grâce aux données d’usage. Notre article sur le prix d’une application mobile donne des ordres de grandeur par fonctionnalité.

Côté délais, comptez quelques semaines pour un audit et un cadrage, puis de deux à six mois de développement selon le périmètre. Nous détaillons ces fourchettes dans notre article combien de temps pour développer une application mobile. Pour maîtriser à la fois le budget et le calendrier, nous privilégions une approche par lots : un premier lot livrable rapidement, puis des itérations mensuelles pilotées par les indicateurs.

Après la refonte : ne pas recréer la dette

Une refonte n’a de sens que si la nouvelle version reste saine dans la durée. C’est pourquoi nous l’accompagnons systématiquement de fondations d’industrialisation : tests automatisés sur les parcours critiques, pipeline de CI/CD pour des livraisons fréquentes et fiables, monitoring des crashs avec Firebase Crashlytics, et contrat de maintenance d’application mobile adapté au rythme de votre produit. Pour Citruce, application de gestion locative que nous avons reprise et restructurée, c’est cette continuité qui permet aujourd’hui de livrer chaque année des améliorations majeures sans repartir de zéro.

Si votre application montre des signes de fatigue, le plus efficace est de commencer par un audit. Notre équipe d’agence de développement d’applications mobiles peut établir un diagnostic factuel et vous proposer le scénario de refonte le plus adapté à vos enjeux.

FAQ sur la refonte d’application mobile

À quelle fréquence faut-il refaire une application mobile ?

Il n’y a pas de règle fixe. Une application bien maintenue peut vivre de nombreuses années avec des évolutions régulières. En pratique, une refonte UX significative intervient souvent tous les trois à cinq ans, et une refonte technique lorsque la technologie devient obsolète ou freine les évolutions.

Va-t-on perdre les notes et les avis des stores lors d’une refonte ?

Non, à condition de publier la nouvelle version comme une mise à jour de l’application existante, avec le même identifiant de bundle iOS, le même package Android et la même clé de signature. La fiche, l’historique des avis et le référencement sont alors conservés.

Peut-on refaire uniquement l’application sans toucher au backend ?

Oui, si les API existantes sont performantes, documentées et sécurisées. Si ce n’est pas le cas, une refonte purement mobile déplace le problème. L’audit initial permet de trancher et, souvent, de prévoir une évolution progressive du backend.

Faut-il passer au cross-platform lors d’une refonte ?

C’est souvent pertinent pour réduire le coût de maintenance de deux bases de code, mais ce n’est pas systématique. Une application qui dépend fortement des capacités natives du terminal ou des dernières nouveautés iOS et Android peut rester en natif. Le choix se fait au cas par cas.

Aventique peut-elle reprendre une application développée par un autre prestataire ?

Oui. Une grande partie de nos refontes démarre par la reprise d’une application existante, comme pour Loox ou Citruce : audit du code, sécurisation, remise à niveau de la chaîne de build, puis refonte. Nous pouvons intervenir au forfait ou en renfort de votre équipe via notre offre d’IT outsourcing.

Comment limiter les risques le jour de la bascule ?

En combinant une phase de bêta-test (TestFlight, tests fermés Google Play), un déploiement progressif sur les stores, un monitoring renforcé des crashs et un backend capable de servir temporairement les deux versions de l’application.