Refonte d’une application : décider, chiffrer et migrer sans perdre le métier

Une application en production accumule des règles métier, des données et des habitudes que son code ne décrit pas toujours. Une refonte fait évoluer sa base technique, son expérience utilisateur ou les deux, tout en préservant les fonctions utiles. Un audit aide à choisir entre refactoring, reprise d’un module et remplacement progressif. Cet article détaille les signaux à examiner, les méthodes de migration, les étapes du projet et les coûts qui font varier le budget.

Qu’est-ce qu’une refonte d’application ?

Une refonte d’application remplace tout ou partie de son architecture, de son interface ou de ses fonctionnalités pour mieux répondre aux besoins actuels. Elle peut concerner un logiciel métier, un ERP, une application web ou un SaaS. Une refonte technique change la structure du code ou les technologies. Une refonte UX retravaille les parcours, les écrans et l’organisation de l’information. Un même projet peut réunir les deux.

Le mot « refonte » désigne plusieurs types de travaux. Le refactoring améliore le code tout en conservant le comportement attendu. Une reprise ciblée remplace un module ou une intégration. Une refonte complète reconstruit l’essentiel du produit, tout en conservant ses fonctions utiles et en reprenant ses données. La dette technique et ses effets sur les évolutions aident à distinguer une dette localisée d’un problème d’architecture.

Quand faut-il refondre un logiciel ?

L’âge de l’application ne suffit pas à justifier sa refonte. Une application ancienne peut rester fiable et simple à faire évoluer. À l’inverse, un produit récent peut déjà freiner les équipes si son architecture, ses règles de sécurité ou son expérience d’usage ne correspondent plus à l’activité.

Regardez les conséquences observables plutôt que la date de création :

• Les équipes mettent nettement plus de temps à livrer une évolution, même quand le besoin est limité.
• Des corrections provoquent souvent des régressions dans des fonctions éloignées.
• Certaines dépendances ou certains composants ne reçoivent plus de correctifs de sécurité.
• Les utilisateurs contournent l’application avec des tableurs, des doubles saisies ou des échanges manuels.
• Les intégrations échouent régulièrement ou reposent sur des scripts fragiles.
• L’interface impose des étapes qui ne correspondent plus au travail réel et génère des erreurs ou du support.
• L’architecture rend difficile l’ajout d’un nouveau canal, d’un nouveau rôle ou d’une règle métier.

Un signal isolé appelle souvent une correction ciblée. Plusieurs problèmes qui se renforcent mutuellement justifient un diagnostic plus large. Commencez par relier chaque difficulté à un effet concret : temps de traitement, erreurs, retards, incidents de sécurité ou fonctionnalités repoussées. Cette base aide à décider si le travail mérite son investissement.

Comment choisir entre refactoring, reprise ciblée et refonte ?

Un audit de code et de produit examine l’architecture, les dépendances, les tests, les données, les intégrations et les parcours utilisateurs. Il donne une image plus fiable que le seul ressenti de l’équipe qui travaille sur le logiciel depuis des années. L’audit doit aussi cartographier les règles métier : certaines ne vivent que dans les habitudes des utilisateurs ou dans des cas particuliers jamais documentés.

Un audit peut aussi conclure qu’une refonte ne se justifie pas. Quand le logiciel remplit son rôle et que ses limites restent supportables, quelques corrections et une meilleure maintenance peuvent suffire. L’audit applicatif de Lonestone examine le code, l’UX, l’IA ou la cybersécurité sur un périmètre défini, puis remet des recommandations priorisées.

Big bang ou migration progressive ?

Une bascule « big bang » remplace l’ancienne application par la nouvelle à une date fixée. Elle est envisageable si le périmètre reste limité, les comportements sont bien connus, les données se migrent proprement et le retour arrière a été préparé. Une bascule globale concentre toutefois les risques sur un moment : un écart de données ou une fonction oubliée peut toucher l’ensemble des utilisateurs.

Une migration progressive remplace des fonctions par étapes. L’ancienne application continue de gérer les parties qui n’ont pas encore migré. Une passerelle peut acheminer chaque demande vers l’ancienne ou la nouvelle version. Les utilisateurs et les équipes métier testent chaque partie avant de déplacer la suivante. Martin Fowler, auteur du concept « Strangler Fig », décrit la modernisation graduelle comme une manière de remplacer un système sans attendre la fin d’une réécriture complète. Microsoft recommande également cette méthode pour les systèmes complexes, avec une attention particulière aux dépendances et aux données partagées.

graph TD
  A[Application existante en production] --> B{Choix de migration}
  B -->|Périmètre réduit et connu| C[Bascule globale préparée]
  B -->|Plusieurs modules ou risques élevés| D[Passerelle entre ancien et nouveau]
  D --> E[Migrer une fonction]
  E --> F[Tester les usages et rapprocher les données]
  F --> G{Résultat validé ?}
  G -->|Non| E
  G -->|Oui| H[Basculer la fonction suivante]
  H --> I[Retirer l’ancien système après validation complète]
  C --> J[Surveiller et garder un plan de reprise]

La migration progressive réduit la taille de chaque bascule, mais demande de faire cohabiter deux versions et parfois deux représentations des données. Elle convient si l’application permet de séparer ses fonctions et si l’équipe peut gérer ces échanges. Martin Fowler décrit la modernisation graduelle d’un système comme une série de remplacements par étapes. Microsoft détaille aussi la gestion des dépendances entre versions.

Quelles sont les étapes d’une refonte d’application ?

Pour réussir une refonte, partez des usages et des résultats attendus. Une feuille de route centrée sur la nouvelle technologie ne précise pas le problème que le projet doit résoudre.

1. Définir les objectifs. Précisez ce qui doit s’améliorer : délais de livraison, stabilité, sécurité, adoption ou capacité à faire évoluer le produit. Choisissez des indicateurs observables, comme le nombre de régressions ou la durée d’un processus.
2. Auditer l’application. Examinez le code, les dépendances, l’architecture, les accès, l’hébergement, les tests, les données et les intégrations. Relevez aussi les fonctions réellement utilisées.
3. Cartographier les règles métier. Interrogez les personnes qui utilisent et administrent le logiciel. Listez les exceptions, les validations et les échanges avec d’autres outils, puis faites confirmer cette carte par les responsables métier.
4. Définir les frontières de migration. Choisissez un premier module qui apporte une amélioration tangible et peut être isolé. Identifiez les dépendances, les données qu’il lit ou modifie et les utilisateurs concernés.
5. Concevoir l’expérience et l’architecture. Dessinez les parcours prioritaires avec les utilisateurs. Fixez les principes de sécurité, les rôles, les intégrations et les modalités de coexistence des versions.
6. Migrer les données et développer par lots. Préparez des transformations répétables, des sauvegardes et des contrôles de cohérence. Livrez chaque fonction pour la tester avant d’élargir le périmètre.
7. Recetter, basculer et suivre. Vérifiez les scénarios métier, les droits, les intégrations et les données. Après la mise en production, suivez les anomalies et accompagnez les utilisateurs. Le cahier de recette et ses cas de test aide à définir les résultats attendus avant la bascule.

Validez les résultats métier en comparant les totaux, les statuts, les historiques et les règles de calcul. Microsoft recommande de vérifier la cohérence des bases avant de faire du nouveau système la référence d’un domaine, comme l’explique sa méthode de migration progressive des applications. Cette vérification compte particulièrement si les deux versions peuvent modifier les mêmes informations.

Comment préparer la migration des données ?

La migration de données mérite un chantier dédié. Les champs ont parfois changé de sens, des doublons se sont accumulés et certaines informations ne servent plus. Copier les données sans comprendre leurs règles peut déplacer les mêmes erreurs dans la nouvelle application.

Pour chaque catégorie, définissez le système de référence, les transformations, les contrôles de cohérence et la personne qui validera les résultats. Répétez l’import sur une copie de production et comparez les données de départ et d’arrivée. Pendant une migration progressive, attribuez clairement à un seul système le droit de modifier chaque donnée.

Préparez la continuité de service : les utilisateurs doivent savoir où effectuer chaque opération, quand une fonction change de version et qui contacter en cas de blocage. Précisez aussi les conditions d’un retour arrière. Une erreur sur un module ne doit pas remettre en cause ceux qui sont déjà validés.

Combien coûte une refonte d’application ?

Le prix dépend moins du nom du framework que du périmètre à reconstruire. Les facteurs qui pèsent le plus sont les règles métier à retrouver, les fonctions concernées, la qualité des tests, le volume et l’état des données, le nombre d’intégrations et la durée de coexistence des deux versions.

Les repères Lonestone sur le prix du développement d’un SaaS situent la refonte d’un SaaS existant entre 80 000 et 200 000 €, pour une durée indicative de 3 à 12 mois selon l’ampleur du chantier. Ces repères ne remplacent pas un audit ni un devis : une reprise d’un module isolé et une refonte complète avec migration de données ne décrivent pas le même projet. Une application métier ou un ERP peut aussi s’écarter de cette fourchette selon ses contraintes.

Un diagnostic détaillé précise le budget quand il sépare les lots et explicite ce qu’ils comprennent : audit, UX, développement, migration, tests, déploiement et maintenance. Un devis qui ne détaille pas les données et les intégrations laisse souvent les principaux risques hors périmètre. Le cadrage produit sert à clarifier les parcours et les choix avant le développement. Pour un produit existant, un audit est souvent le meilleur point de départ.

Exemple de refonte : le SaaS Greenloc

Greenloc, une solution de gestion locative, rencontrait des difficultés techniques et d’usage. La dette technique ralentissait les développements, les locataires ressaisissaient les données de leurs garants à chaque candidature et les agences avaient besoin d’aide pour configurer leur espace. Les connexions avec des outils tiers provoquaient aussi des dysfonctionnements.

Lonestone a audité l’application et choisi une refonte complète plutôt qu’un refactoring partiel. Le backend est passé d’Express et Sequelize à NestJS et MikroORM, avec une API GraphQL, des tests automatisés et un suivi des erreurs. L’équipe a aussi revu l’expérience utilisateur : les locataires peuvent réutiliser leurs dossiers et les agences configurent leur espace de manière autonome. La plateforme est restée en production pendant une transformation menée par phases.

La refonte de Greenloc a associé les choix techniques à la réutilisation des dossiers locataires et à l’autonomie des agences.

Comment choisir l’équipe qui va refondre l’application ?

Demandez qui réalisera l’audit et les développements, puis vérifiez des projets comparables. Regardez comment l’équipe documente les décisions, teste les migrations et prépare la reprise par l’équipe interne.

Lonestone a accompagné plus de 200 clients depuis 2014. La plupart de ses ingénieurs ont entre 10 et 25 ans d’expérience. Pour les projets de logiciel métier, l’équipe réunit l’UX, le produit et le développement avec les personnes qui utiliseront l’outil. Elle travaille principalement en TypeScript, React et Node.js. La refonte internationale de Desoutter Tools s’est déroulée sur six mois, avec recherche utilisateur et architecture modulaire. Après la remise en production, la maintenance applicative couvre les corrections, les mises à jour et les évolutions.

Lonestone audite les applications de PME et d’ETI avant de définir leur refonte d’outil métier. Pour un SaaS d’éditeur logiciel ou de startup, l’équipe intervient aussi sur la création et l’évolution de SaaS.