« On garde l’application, on rafraîchit juste l’interface. » Dans un projet mobile, cette phrase tient rarement jusqu’à la fin du cadrage. Sur un site web, un relookage peut effectivement s’arrêter au thème et aux feuilles de style, parce que le navigateur de vos visiteurs est resté rétrocompatible pendant ce temps. Une application, elle, est un binaire compilé un jour donné, avec les bibliothèques de ce jour-là, qui doit continuer à tourner sur des téléphones dont le système a changé quatre fois depuis.
Derrière « on refait l’appli », il y a donc trois projets possibles et non un : un relookage d’interface, une migration de framework, une reconstruction complète. Ils portent le même nom dans la conversation commerciale, mais ils n’ont ni le même prix, ni le même délai, ni les mêmes risques. La plupart des mauvaises surprises sur les refontes mobiles viennent de là : un devis de relookage signé pour un projet qui était, depuis le départ, une reconstruction.
Une application mobile ne vieillit pas comme un site web
Trois horloges tournent en parallèle sans vous demander votre avis. Celle d’Apple et de Google, qui relèvent régulièrement la version minimale du SDK ou le niveau d’API cible exigé pour publier une mise à jour : une application qui n’a pas été rebuildée depuis deux ans peut tout simplement ne plus être publiable en l’état. Celle des frameworks : une base Flutter ou React Native de 2021 est souvent deux ou trois versions majeures en retard, avec des paquets communautaires abandonnés entre-temps. Celle de vos fournisseurs techniques, enfin : passerelle de paiement, SDK de notifications, bibliothèque de cartes, chacun impose ses propres ruptures de compatibilité.
Autrement dit, une application sans mise à jour pendant deux ans n’est pas « stable ». Elle est figée, ce qui n’est pas la même chose. Les équipes qui ont tenu un budget de maintenance application mobile régulier arrivent à la refonte avec un chantier de design. Les autres arrivent avec un chantier de design plus une remise à niveau technique complète, et c’est précisément là que les devis doublent.
Le signal qui déclenche la question, et ce qu’il dit vraiment
Trois symptômes reviennent chez les PME marocaines dont l’application a trois à cinq ans : la note du store qui glisse sans remonter, un écran qui s’affiche de travers depuis la dernière version d’Android, et des utilisateurs qui installent, ouvrent une fois et disparaissent. Ils arrivent souvent ensemble, et ce n’est pas une coïncidence de calendrier.
Avant de choisir un type de refonte, il faut sortir cinq chiffres des consoles plutôt que d’une réunion :
- Le taux de sessions sans crash et le taux d’ANR, dans la Play Console et dans App Store Connect ou votre outil de crash reporting. Google Play applique des seuils de mauvais comportement au-delà desquels la visibilité de la fiche est affectée.
- Les avis des douze derniers mois, triés par version de l’application. La note affichée sur Play donne plus de poids aux évaluations récentes, donc une version ratée laisse une trace qui s’efface lentement.
- La rétention à J1, J7 et J30, et le taux de désinstallation. C’est la différence entre « l’application est laide » et « l’application ne sert plus ».
- La répartition réelle de votre parc : versions d’OS, modèles, mémoire disponible. Au Maroc, la part d’Android d’entrée de gamme est suffisante pour qu’un écran chargé en animations devienne un problème de rétention et pas un détail esthétique.
- Le taux de conversion de la fiche store, vues vers installations. Il dépend des captures, de l’icône et de la description, pas du code.
Ce travail prend deux ou trois jours. Il oriente ensuite des dizaines de milliers de dirhams de budget.
Relookage, migration, reconstruction : trois projets qu’on confond
Le relookage d’interface
Même architecture, même code métier, nouveau système de design : couleurs, typographie, composants, parfois la navigation. Cela suppose que la base actuelle compile, se publie et repose sur des dépendances encore maintenues. Comptez quatre à huit semaines sur une application de quinze à vingt écrans. C’est le seul des trois scénarios où le mot « relookage » est honnête.
La migration de framework
Deux bases natives qu’on regroupe en une seule base Flutter, un vieux projet Cordova ou Ionic qu’on reprend en React Native, ou une version majeure qu’on rattrape avec une refonte de l’architecture interne. Le backend reste, la logique métier est réécrite, l’interface est refaite au passage parce qu’il serait absurde de la reproduire à l’identique. Trois à six mois, et un risque concentré sur les données et les intégrations, pas sur le design.
La reconstruction complète
Nouveau modèle de données, nouvelles API, parfois nouvelle authentification et nouveau tunnel de paiement. On garde le nom, les utilisateurs et la fiche store, le reste change. Cinq à neuf mois selon le périmètre. Si quelqu’un vous propose ça en six semaines, le périmètre n’a pas été lu.
Erreur n°1 : redessiner l’application sans savoir pourquoi les gens la désinstallent
La refonte visuelle est la plus facile à vendre et la plus facile à valider en comité : tout le monde a un avis sur une maquette. Le problème est que la cause du départ des utilisateurs est rarement visuelle. Dans les applications que j’ai auditées, elle se logeait plus souvent dans la connexion (code OTP par SMS qui n’arrive pas ou arrive en retard), dans le temps de démarrage sur un appareil modeste, dans le comportement en réseau instable, ou dans un paiement qui échoue une fois sur cinq sans message clair.
Le correctif n’est pas coûteux : lisez cent à deux cents avis récents à la main, classez-les par motif, et croisez avec l’entonnoir de votre analytics. Supposons qu’une application de commande affiche 62 % de ses avis à une étoile sur le thème « je ne reçois pas le code de vérification ». Une nouvelle charte graphique ne déplacera pas cette courbe d’un point. Refaire le design est presque toujours justifiable à terme. Le faire en premier, rarement.
Erreur n°2 : migrer vers Flutter ou React Native sans auditer les données existantes
Une migration technique se prépare côté serveur, et c’est côté téléphone qu’elle se casse. Vos utilisateurs ont des choses sur leur appareil : une base locale SQLite, Room ou Realm, des préférences, un jeton d’authentification dans le Keychain ou le Keystore, une file d’attente d’actions hors ligne, des fichiers téléchargés, un historique de commandes consultable sans réseau.
Si la nouvelle version arrive avec un schéma local différent et aucune reprise, l’utilisateur qui met à jour rouvre l’application déconnecté, avec un historique vide et un panier perdu. Ce que vous recevez dans les quarante-huit heures, ce sont des avis à une étoile sur la version que vous venez de livrer, au moment exact où vous aviez besoin d’une bonne note.
Les points à inventorier avant de chiffrer : schéma de la base locale et script de migration, format des jetons et renouvellement de session, configuration des liens profonds et des liens universels, jetons de notifications push, identifiants analytics, et les consentements déjà collectés. Ce dernier point n’est pas cosmétique : si la migration change les SDK embarqués, les permissions demandées et les destinataires des données changent aussi, ce qui vous ramène aux obligations décrites dans notre article sur les permissions et SDK face à la CNDP.
La recette doit se faire sur le vrai chemin de mise à jour : installer la version publiée depuis le store, l’utiliser, puis installer le nouveau build par-dessus. Tester le nouveau build sur un téléphone vierge ne prouve rien. Et si le choix de la cible technique n’est pas encore arrêté, il se discute avant le cadrage, pas pendant : nous détaillons les critères dans le guide application native ou Flutter.
Erreur n°3 : changer de bundle ID ou de compte développeur
C’est l’erreur la plus chère, parce qu’elle est irréversible. L’identifiant de bundle sur iOS et l’applicationId sur Android ne se changent pas une fois l’application publiée. Si le nouveau prestataire publie sous un nouvel identifiant, vous n’avez pas mis à jour votre application : vous en avez créé une deuxième. Zéro avis, zéro note, zéro historique de téléchargements, aucun signal d’ancienneté pour le classement, et vos utilisateurs actuels qui gardent sur leur téléphone une application que personne ne mettra plus à jour. Les liens profonds de vos campagnes SMS et e-mail pointent encore vers l’ancienne. Trois ans de notes accumulées partent avec.
Le même piège existe au niveau des comptes. Beaucoup d’applications marocaines ont été publiées sous le compte développeur du prestataire, avec le keystore Android conservé chez lui. Tant que la relation est bonne, personne ne s’en aperçoit. Le jour du changement, vous découvrez que la fiche ne vous appartient pas. Apple et Google proposent tous les deux une procédure officielle de transfert d’application entre comptes, sous conditions : c’est le chemin à suivre, pas une republication. Nous avons détaillé la mécanique de ce genre de reprise dans notre guide pour changer de prestataire IT.
À vérifier avant de signer quoi que ce soit : le compte Apple Developer est au nom de votre société, le compte Google Play aussi, vous avez accès à la signature d’application (ou au keystore), et le devis écrit noir sur blanc que l’identifiant de bundle reste inchangé. Prévoyez aussi une version minimale supportée et un écran de mise à jour obligatoire, sinon vous maintiendrez deux API pendant deux ans.
Ce que coûte vraiment une refonte application mobile Maroc en 2026
Les fourchettes ci-dessous correspondent à ce qu’on observe sur le marché de Casablanca et Rabat, hors taxes, pour une équipe de deux à quatre personnes et une application de complexité moyenne (quinze à vingt-cinq écrans, authentification, API métier, notifications). Elles bougent vite avec le périmètre, donc elles servent à cadrer une discussion, pas à remplacer un chiffrage.
- Audit préalable (code, dépendances, données locales, comptes et stores, analytics) : 15 000 à 35 000 MAD, une à deux semaines.
- Relookage d’interface sur une base saine : 50 000 à 120 000 MAD.
- Migration de framework avec reprise des données locales et des intégrations : 180 000 à 450 000 MAD.
- Reconstruction application mobile complète, backend inclus : rarement sous 350 000 MAD, souvent entre 500 000 et 900 000 MAD.
- Après la mise en ligne : 15 à 25 % du coût de construction par an pour rester publiable, selon le niveau de service attendu.
Un devis qui annonce un prix pour « la refonte » sans dire laquelle des trois catégories il couvre n’est pas un devis, c’est une intention. Les lignes qui manquent le plus souvent et qui coûtent le plus cher ensuite : la migration des données locales, le plan de mise à jour obligatoire, les tests sur anciens appareils Android, la recette du parcours de mise à jour, et la reprise des fiches store. Si vous voulez moderniser une application mobile au Maroc sans acheter un chèque en blanc, demandez ces cinq lignes explicitement et comparez les réponses plutôt que les totaux.
Le test en trois questions avant de lancer le projet
Première question : est-ce que la base actuelle compile et se publie aujourd’hui, sans contournement ? La façon de le savoir n’est pas de le demander, c’est de faire produire un build signé et de soumettre une mise à jour mineure sur les deux stores. Si ça passe en quelques jours, votre projet est probablement un relookage. Si ça bloque sur des dépendances, vous êtes dans une migration et le budget change de catégorie.
Deuxième question : qui possède les comptes, les clés de signature et l’identifiant de bundle ? Tant que la réponse n’est pas « nous », aucune refonte ne doit démarrer.
Troisième question : qu’est-ce qui fait partir les utilisateurs, mesuré et non supposé ? Si vous ne pouvez répondre aux trois, ce qu’il faut acheter n’est pas une refonte mais un audit de deux semaines, qui coûte le prix d’un sprint et évite d’en gaspiller six. C’est aussi le meilleur moment pour décider qui portera la maintenance applicative après la livraison, parce que ce choix influence l’architecture retenue.
Chez Arrowlancer, nous commençons les projets d’applications mobiles (iOS/Android, Flutter/React Native) par cet audit, puis nous chiffrons la catégorie réelle du projet : relookage, migration ou reconstruction, avec la reprise des données et la préservation des fiches store dans le périmètre. Vous pouvez voir l’ensemble de nos services, et si votre application a trois à cinq ans et que les notes baissent, décrivez-nous l’existant via le formulaire de contact : on vous dira lequel des trois projets vous avez sur les bras avant de parler de prix.