Reprendre ou réécrire une application existante ?

01

Distinguer reprise, refonte et réécriture

Une application lente, difficile à maintenir ou devenue peu pratique peut appeler plusieurs réponses. Commencez par décrire les problèmes : une action qui échoue, un traitement trop long, une évolution impossible à livrer ou une interface qui ne correspond plus au métier. L’âge de la technologie ne suffit pas à expliquer leur origine.

Changer de prestataire ne demande pas, à lui seul, de changer toute l’application. Une refonte UX/UI peut améliorer les parcours en conservant une partie de la technique. Une réécriture peut concerner un composant, le serveur ou l’ensemble du produit. Il faut nommer précisément ce qui sera conservé, modifié ou remplacé pour comparer les propositions.

02

Commencer par un audit du produit et de sa réalisation

Un audit utile relie les constats techniques aux parcours de l’application. Il examine le code, les dépendances, les environnements, les données, les connexions et la façon de livrer une modification. Il doit aussi recueillir les difficultés rencontrées par les utilisateurs et les changements attendus par votre organisation.

Vérifiez que l’équipe peut préparer un environnement de travail, lancer l’application et comprendre comment la version en service est produite. Rassemblez les accès nécessaires selon les rôles, la documentation disponible, les incidents connus et les comptes utiles à l’exploitation. Si certains éléments manquent, leur absence et les limites du diagnostic doivent être indiquées.

Demandez des preuves : un problème reproduit, une mesure de temps de réponse, une dépendance identifiée ou un parcours de test. Le livrable doit distinguer les actions urgentes, les améliorations possibles et les inconnues à lever. Une liste de défauts sans conséquences ni priorités ne permet pas encore de choisir une trajectoire.

03

Quand reprendre la base existante reste pertinent

Une reprise mérite d’être privilégiée dans l’étude lorsque le produit couvre encore les usages essentiels, que le code peut être compris et que les problèmes sont localisables. Une lenteur d’accès aux données, des écrans confus ou des tests insuffisants peuvent parfois être traités par des interventions ciblées. Il faut vérifier cette possibilité sur un premier changement représentatif.

La dette technique désigne ici le travail nécessaire pour rendre les modifications plus fiables et soutenables : clarifier une responsabilité, mettre à jour une dépendance, ajouter un test ou documenter une règle. Son existence ne suffit pas à condamner toute la base. Examinez son effet concret sur les incidents, les délais d’évolution et les risques du produit.

Un premier lot peut combiner une amélioration utile et les protections nécessaires autour de ce parcours. Comparez les résultats à l’état initial : comportement, régressions, facilité de livraison et capacité de l’équipe à expliquer le changement. Si les blocages restent structurels malgré cette évaluation, la trajectoire doit être réexaminée.

04

Envisager une modernisation progressive

Pour un serveur ou un service web, le modèle « Strangler Fig » documenté par Microsoft consiste à remplacer des fonctions par étapes en orientant les requêtes vers l’ancienne ou la nouvelle réalisation. Cette approche suppose de pouvoir délimiter les fonctions et organiser leur coexistence. Elle ne convient pas automatiquement à toutes les applications.

Dans votre projet, commencez par identifier un périmètre qui peut évoluer avec des limites compréhensibles : une recherche, un espace de consultation ou un traitement particulier. Décrivez les échanges avec le reste du produit et les responsabilités sur les données. Le découpage doit être démontré sur un cas concret avant de devenir un planning de migration.

La coexistence demande aussi du travail : maintenir les connexions, tester les échanges et décider quand retirer l’ancienne partie. Intégrez cet effort transitoire à la comparaison. Un découpage apparent de l’interface ne prouve pas que les règles ou les données peuvent être séparées de la même manière.

05

Quand une réécriture mérite une étude complète

La réécriture peut devenir pertinente lorsque des contraintes structurelles empêchent les évolutions indispensables, qu’une technologie ne peut plus être maintenue dans des conditions acceptables ou que le fonctionnement du produit doit changer profondément. Une petite application bien délimitée peut aussi se prêter à un remplacement complet. Ces hypothèses doivent être comparées au travail nécessaire pour conserver et améliorer l’existant.

Définissez le nouveau périmètre à partir des usages à préserver et des besoins actuels. Certaines fonctions anciennes ne sont plus utiles ; d’autres contiennent des règles implicites que les utilisateurs appliquent au quotidien. Recueillez les exceptions, les droits, les calculs et les échanges avant de considérer qu’un écran résume tout le comportement attendu.

Le budget d’une réécriture comprend aussi la compréhension de l’ancien produit, la reprise des données, les tests de correspondance, la transition des utilisateurs et le maintien du service pendant la réalisation. Le financement d’une nouvelle base ne fait pas disparaître ces tâches. Précisez également ce qui déclencherait une réduction du périmètre ou une révision de la décision.

06

Comparer les options avec six critères concrets

Pour chaque option, indiquez les éléments connus, les preuves recueillies et les incertitudes restantes. Comparez le même service attendu, avec un horizon commun incluant la réalisation, la transition et la maintenance. Évitez de mettre face à face le coût d’une correction isolée et celui d’une nouvelle application couvrant davantage de fonctions.

La grille ci-dessous sert à organiser les arbitrages. Une contrainte bloquante doit être traitée explicitement ; elle ne se compense pas par une moyenne de notes. Les situations qui suivent sont fictives et illustrent la démarche, sans décrire des résultats clients.

07

Préparer la migration et les conditions de bascule

Commencez par les données : informations à reprendre, relations, documents, droits et historique. Réalisez des essais sur un environnement adapté, vérifiez les correspondances et définissez les critères d’acceptation. Une sauvegarde disponible doit être accompagnée d’un essai de restauration ; sa présence seule ne prouve pas que la reprise du service est maîtrisée.

Prévoyez les modifications qui surviennent pendant la transition : quel système enregistre une nouvelle demande, comment éviter une perte ou un doublon et comment rapprocher les informations après un échec ? Un retour à l’ancienne version peut demander un traitement des données déjà créées ou modifiées. Cette procédure doit être testée et attribuée à une personne responsable.

Pour les services qui le permettent, Google SRE décrit une diffusion limitée dans le temps et à une partie des utilisateurs, évaluée avant une extension du déploiement. Définissez les signaux à observer et les conditions d’arrêt. Ce mécanisme complète les tests réalisés avant la mise en service.

Le mobile demande une attention particulière : Google Play précise que l’arrêt d’une diffusion progressive ne retire pas la version déjà reçue par les utilisateurs concernés. Préparez la compatibilité des échanges avec le serveur et la façon de corriger une version installée. La bascule d’une application mobile ne se gère donc pas exactement comme celle d’un site web.

08

Définir une première intervention utile avec Gaspa

Une première intervention doit produire une compréhension exploitable de l’application : état des lieux, risques prioritaires et options argumentées. Si un doute technique détermine le choix, prévoyez un essai ciblé. Vous pourrez ensuite définir un premier lot, ses critères de validation et l’organisation de son suivi.

Gaspa accompagne l’audit UX et technique, la refonte et la maintenance d’applications. Le projet Hummingbird illustre une mission de modernisation : refonte UX/UI, développement iOS et Android, back-office et publication sur les stores. Cette référence documente le périmètre livré ; elle ne permet pas de déduire la trajectoire technique adaptée à une autre application.

Le livrable attendu est une décision compréhensible par votre équipe : ce qui est conservé, ce qui change, les conditions de transition et les responsabilités après livraison. L’application doit pouvoir continuer à évoluer avec des accès, une documentation et des critères de qualité partagés.