Refonte et reprise d'application mobile

Reprendre une application, ça s'audite d'abord

La plupart des demandes de refonte arrivent avec la même phrase : « l'app marche, mais on ne peut plus rien faire dessus ». Derrière, on trouve presque toujours les mêmes causes — une version d'Expo ou de React Native restée bloquée trois ans en arrière, des dépendances abandonnées par leurs auteurs, aucun test, et une architecture où chaque nouvelle fonctionnalité casse la précédente.

On commence donc par un audit, pas par une réécriture. Réécrire est la décision la plus chère du métier ; elle doit être prise sur des faits, pas sur l'inconfort de lire du code écrit par quelqu'un d'autre.

Ce que l'audit regarde

• Les versions — React Native, Expo, React, et l'écart avec la New Architecture. C'est ce qui détermine si une montée de version est une semaine ou deux mois de travail.
• Les dépendances — bibliothèques non maintenues, modules natifs incompatibles avec les nouvelles architectures, paquets dupliqués.
• Les performances réelles — temps de démarrage à froid, fluidité des listes, taille du bundle, consommation mémoire, sur un appareil d'entrée de gamme et pas sur un simulateur.
• La sécurité — clés d'API embarquées dans le bundle, règles d'accès à la base de données, stockage local de données sensibles.
• La conformité stores — ce qui vous expose à un refus Apple ou Google à la prochaine soumission.
• La reprenabilité — documentation, tests, cohérence de l'architecture, capacité d'un nouveau développeur à être productif rapidement.

Migrer vers la New Architecture

C'est le chantier le plus fréquent aujourd'hui. La New Architecture de React Native — Fabric pour le rendu, TurboModules pour les modules natifs — n'est plus optionnelle à moyen terme, et beaucoup d'applications sont restées sur l'ancienne. La migration ouvre l'accès au React Compiler, à Reanimated 4 et aux versions récentes d'Expo, avec un gain de fluidité immédiat.

La difficulté n'est presque jamais le cœur de l'application : ce sont les modules natifs tiers restés incompatibles. On les identifie pendant l'audit, on cherche les remplaçants, et quand il n'y en a pas, on réécrit le module nous-mêmes en Swift ou en Kotlin.

Quand la réécriture est vraiment la bonne réponse

Elle l'est parfois. Quand l'application a été développée par plusieurs prestataires successifs sans direction technique, quand il n'existe aucune séparation entre l'interface et la logique métier, ou quand la technologie de départ ne permet tout simplement pas ce que vous voulez faire maintenant. Dans ce cas, on repart d'une base propre — mais en récupérant ce qui a de la valeur : le design, les parcours éprouvés, les données, et surtout les enseignements sur ce que vos utilisateurs font réellement.

Le reste du temps, une reprise progressive coûte moins cher, comporte moins de risques, et vous laisse continuer à livrer pendant les travaux. On a déjà repris un prototype en données simulées pour l'emmener jusqu'à une application complète en production — c'est le cas de Dressedups.

Questions fréquentes

Vous reprenez du code que vous n'avez pas écrit ?

Oui, c'est une part importante de notre activité. On demande simplement un accès en lecture au dépôt avant de s'engager, pour que l'estimation repose sur le code réel et pas sur une description.

Et si le prestataire précédent n'est plus joignable ?

C'est fréquent, et ce n'est pas bloquant tant que vous avez le dépôt et vos comptes développeur. Si les comptes Apple ou Google sont détenus par le prestataire, c'est le premier point à régler — avant toute question technique.

Combien de temps prend l'audit ?

Quelques jours selon la taille du projet. Vous repartez avec un document qui liste les problèmes par gravité, les options possibles et leur coût respectif. Ce document vous appartient, même si vous ne poursuivez pas avec nous.

Peut-on migrer sans interrompre les livraisons ?

Dans la grande majorité des cas, oui. On travaille par étapes courtes en gardant l'application publiable, quitte à faire cohabiter temporairement l'ancien et le nouveau code.