La plainte arrive généralement comme un ressenti, pas comme un rapport de bug. L'app va bien. Elle fonctionne. Elle fait juste vieux, livre lentement, et chaque petit changement prend trois semaines et casse autre chose.
Ce ressenti est un vrai signal — et il mérite un vrai diagnostic avant que quiconque prononce le mot réécriture.
Les symptômes qui indiquent vraiment la pourriture
La plupart des apps qui font datées souffrent de l'une de ces quatre choses — et elles appellent des réponses différentes.
La dérive visuelle. L'app suit un langage de design vieux de deux générations d'OS. Polices, espacements, schémas de navigation et animations disent tous une année précise. C'est le problème le moins cher à corriger — et le plus souvent diagnostiqué à tort comme nécessitant une reconstruction.
La livraison lente. Chaque changement prend plus de temps qu'il ne devrait. Personne ne veut toucher certains fichiers. Les estimations ont discrètement triplé en trois ans. Ça, c'est l'architecture, et elle ne s'améliore pas toute seule.
Le retard de plateforme. Vous ne pouvez pas adopter les nouvelles capacités de l'OS parce que la base de code leur est antérieure, et chaque version annuelle coûte plus cher à absorber que la précédente.
La dégradation des performances. L'app a ralenti à mesure que les fonctionnalités s'accumulaient, le démarrage à froid a grimpé, le taux de crash sur les vieux appareils aussi.
Seuls le deuxième et le troisième plaident réellement pour un travail structurel. Le premier et le quatrième se corrigent généralement dans l'app que vous avez — pour une fraction du coût.
La question qui tranche
Pouvez-vous livrer un changement significatif, en sécurité, dans un sprint normal ?
Si oui, l'app a un problème d'interface ou de performance — corrigez-les directement. Une refonte visuelle sur une base de code saine, c'est des semaines, pas des trimestres, et presque aucun risque.
Si non — si chaque changement touche du code que personne ne comprend, s'il n'y a pas de tests autour des parties qui comptent, si une seule personne peut modifier la couche de synchronisation sans danger — alors vous avez un problème d'architecture, et aucun travail visuel n'y répondra.
La distinction compte parce qu'une réécriture est énormément plus chère et risquée que les équipes ne s'en souviennent. L'app que vous avez gère des centaines de cas limites découverts au fil d'années d'usage réel. La plupart ne sont pas documentés. Certains sont porteurs.
Fig. — La plupart des conversations « il nous faut une réécriture » s'arrêtent à la première branche.
L'incrémental bat le big-bang, presque toujours
Quand le travail structurel est réellement nécessaire, l'approche qui survit au contact du réel est de remplacer écran par écran plutôt que tout d'un coup.
Les deux grands frameworks cross-platform peuvent s'embarquer dans une app native existante : vous pouvez donc reconstruire un écran dans la nouvelle stack, le livrer, et laisser tout le reste tranquille. Les utilisateurs reçoivent une app qui s'améliore progressivement. Vous recevez un vrai retour sur la nouvelle architecture avant de parier le produit dessus.
Commencez par un écran autonome et à faible risque — une page de réglages, une vue de contenu statique — et délibérément pas le paiement. C'est sur le premier écran migré que vous découvrez ce que votre pipeline de build, vos ponts de navigation et votre gestion d'état exigent vraiment.
L'alternative — construire le remplaçant en parallèle et basculer — semble plus propre et ne l'est généralement pas. Deux bases de code, c'est deux séries de correctifs pendant toute la durée, et la bascule est un instant unique où tout fonctionne ou pas, devant tous les utilisateurs à la fois.
L'exception honnête : si l'app existante est petite, ou réellement inmaintenable, ou bâtie sur un framework qui ne reçoit plus de mises à jour, une reconstruction propre peut coûter moins cher. Cette décision demande quelqu'un qui a lu le code — pas quelqu'un qui a lu les plaintes.
Ce que ça coûte, et ce que personne ne chiffre
Les estimations de reconstruction sont systématiquement trop basses pour une raison : l'estimation couvre les fonctionnalités visibles, et le coût est dans celles qu'on ne voit pas.
La logique métier non documentée. Le contournement pour la bizarrerie du prestataire de paiement. Le comportement de retry que quelqu'un a ajouté après une mauvaise semaine en production. La façon précise dont la synchronisation résout les conflits — que personne n'a écrite et dont les clients dépendent.
Budgétez l'archéologie comme une vraie phase. Quelqu'un lit le vieux code et note ce qu'il fait réellement, y compris les parties qui ressemblent à des erreurs et n'en sont pas. Les équipes qui la sautent livrent une app techniquement supérieure qui récolte de moins bonnes notes que celle qu'elle remplace, parce qu'elle a perdu un comportement dont personne ne savait qu'il était important.
Le backend a souvent plus besoin de la conversation
Un détail qui fait dérailler beaucoup de modernisations : l'app n'est souvent pas la chose la plus vieille de l'histoire.
Les apps qui font datées parlent fréquemment à des API conçues il y a dix ans — endpoints bavards, pas de pagination, réponses moulées sur une mise en page qui n'existe plus, authentification antérieure à tous les standards actuels. Reconstruire le client là-dessus donne une app moderne qui fait les mêmes douze appels pour afficher un écran — et la plainte de lenteur survit intacte à la reconstruction.
Vérifiez avant de chiffrer. Ouvrez le journal réseau pendant une session typique et comptez les requêtes, leurs tailles, et combien d'allers-retours auraient pu n'en être qu'un. Si la réponse n'est pas flatteuse, une partie de votre budget de modernisation appartient au côté serveur — et dépensée là, elle produit souvent une amélioration perçue plus grande que tout ce que vous ferez à l'interface.
Ça change aussi l'ordre. Un nettoyage d'API peut être livré indépendamment, profite immédiatement à l'app existante, et dérisque tout ce que vous construirez ensuite.
Migrer sans perdre les gens
Gardez les données. Les utilisateurs doivent ouvrir la nouvelle version et retrouver leur contenu, leurs réglages, leur historique. Une migration qui remet l'état de quelqu'un à zéro est indiscernable d'une mise à jour cassée.
Livrez en mise à jour, pas en nouvelle fiche. Une nouvelle entrée sur le store jette vos avis, votre classement et chaque utilisateur installé. Cette erreur est rare — et catastrophique.
Déployez progressivement. Les deux stores permettent les sorties par paliers ; utilisez-les. Un crash sur un appareil de niche est un incident gérable à cinq pour cent et un désastre à cent.
Et ne redessinez pas tout à la fois. Les utilisateurs tolèrent une meilleure version de l'app qu'ils connaissent. Une app qui a entièrement changé d'allure, déplacé chaque bouton et renommé les sections génère de la charge support et des avis une étoile qui n'ont rien à voir avec la qualité du code.
Une dernière chose à convenir avant de commencer : ce que « terminé » veut dire. Les projets de modernisation dérivent parce que l'objectif était un ressenti plutôt qu'une condition. Choisissez du mesurable — démarrage à froid sous deux secondes, un changement livrable par sprint, sessions sans crash au-dessus d'un seuil donné — et arrêtez-vous quand vous l'atteignez, pas quand le budget s'épuise.
Rafraîchir ou reconstruire est une décision que nous aidons à prendre avec des données, pas avec de la nostalgie — demandez l'évaluation.
