Refonte d'une application métier : faire évoluer l'existant ou repartir de zéro ?

Votre application métier fonctionne encore. Les équipes s’en servent tous les jours, les données sont là, les processus tournent. Pourtant, chaque nouvelle demande prend plus de temps que prévu, chaque mise en production fait un peu plus peur, et la question finit par arriver en comité : faut-il continuer à faire évoluer cet outil ou le reconstruire ?

La refonte d’une application métier n’est jamais une décision purement technique. Elle engage un budget, un calendrier, la continuité de votre activité et, souvent, des années de règles métier accumulées dans le code. La donne a aussi changé récemment : l’IA générative modifie le coût et la vitesse des deux options, sans pour autant décider à votre place.

Dans cet article, nous vous proposons des critères concrets pour trancher, un éclairage sur ce que l’IA apporte réellement aujourd’hui, et un retour d’expérience sur une refonte que nous avons menée.

Les signaux qui posent vraiment la question de la refonte

Une application métier tombe rarement en panne d’un seul coup. Elle se dégrade par petites touches, et c’est justement ce qui rend la décision difficile. Quatre signaux reviennent dans la plupart des situations que nous rencontrons.

Des évolutions de plus en plus longues et coûteuses

Une modification qui semblait simple mobilise désormais plusieurs jours de travail. Les développeurs passent plus de temps à comprendre l’existant et à éviter les effets de bord qu’à produire de la valeur. Ce glissement est un indicateur économique avant d’être un problème technique : vous payez de plus en plus cher pour obtenir de moins en moins.

Une technologie obsolète qui devient un risque de sécurité

Un framework qui n’est plus maintenu ne reçoit plus de correctifs de sécurité. Tant que l’application fonctionne, ce risque reste invisible. Il devient très concret le jour où une faille est découverte, où un audit de conformité est exigé par un partenaire, ou où l’hébergeur refuse de maintenir une ancienne version de langage. Pour les applications qui traitent des données sensibles, l’obsolescence logicielle n’est plus une question de confort.

Un savoir-faire concentré sur une seule personne

Lorsque seul un développeur, interne ou prestataire, sait encore comment fonctionne l’application, l’entreprise est exposée. Un départ, une indisponibilité ou la fin d’un contrat suffit à bloquer toute évolution. Ce risque se double souvent d’une absence de documentation : les règles métier n’existent que dans le code. C’est le profil typique d’une application legacy.

Un outil qui ne suit plus le métier

C’est le signal le plus parlant pour une direction métier. Les équipes exportent les données dans des tableurs pour les retraiter, multiplient les saisies manuelles ou contournent l’outil pour aller plus vite. L’application a été conçue pour l’entreprise d’il y a dix ans, pas pour celle d’aujourd’hui.

Un seul de ces signaux ne justifie pas forcément une refonte. Plusieurs signaux cumulés imposent en revanche de regarder la situation en face.

Deux voies, deux logiques

Faire évoluer l’existant consiste à conserver le socle et à l’améliorer par étapes. Repartir de zéro consiste à reconstruire un nouveau socle, puis à basculer. Les deux sont légitimes. Elles ne répondent simplement pas au même problème.

Faire évoluer l’existant : corriger, mettre à jour, améliorer par lots

Cette voie regroupe plusieurs actions : monter de version le framework et le langage, réécrire les parties du code les plus fragiles, ajouter des tests automatisés, retravailler les écrans les plus utilisés, documenter ce qui ne l’est pas. Le tout se fait pendant que l’application continue de servir.

Son principal atout est la continuité. Vos équipes ne changent pas d’outil du jour au lendemain, les données restent en place et chaque amélioration produit un bénéfice rapide. Elle convient bien lorsque l’architecture reste saine et que les difficultés tiennent surtout au retard de maintenance accumulé.

Sa limite apparaît quand les fondations elles-mêmes posent problème. Si la structure du code empêche d’ajouter une fonctionnalité sans en casser une autre, les efforts de maintenance s’accumulent sans jamais faire baisser la dette. Vous financez alors une remise à niveau permanente.

Repartir de zéro : reconstruire un socle sain

Reconstruire permet de repenser l’architecture, les modèles de données et les parcours utilisateurs à partir des besoins actuels, plutôt que de ceux d’il y a dix ans. C’est aussi l’occasion de choisir une technologie maintenue et répandue, de mettre en place des tests dès le départ et de répondre à des exigences de sécurité que l’ancien outil ne pouvait pas satisfaire.

Cette voie a un coût que l’on sous-estime souvent : la réappropriation des règles métier. Une application en production depuis des années contient des centaines de cas particuliers, parfois connus d’une seule personne, parfois de personne. Les retrouver, les valider et les reproduire représente une part importante du travail. La bascule de l’ancien vers le nouvel outil est l’autre moment sensible : migration des données, formation des équipes, période de stabilisation.

Reconstruire n’est donc pas un raccourci. C’est un investissement qui se justifie lorsque l’existant ne peut plus porter l’avenir de l’activité.

Les critères pour choisir votre voie

Aucun critère ne suffit seul. C’est leur combinaison qui oriente la décision, et c’est précisément ce que permet de faire un audit.

La santé du code et de l’architecture

La première question est simple : le socle peut-il encore être consolidé ? Une application bien structurée mais en retard de mises à jour se modernise. Une application monolithique, où la logique métier est dispersée dans tout le code, se répare beaucoup plus difficilement. La technologie compte aussi : un framework encore maintenu offre une trajectoire d’évolution, une technologie abandonnée vous condamne à terme à la quitter.

La valeur de la logique métier enfouie dans l’existant

Votre application contient vos règles de gestion, vos exceptions, vos calculs. Si cette logique est juste et que seule la technique a vieilli, la faire évoluer préserve ce capital. Si au contraire les processus ont changé et que l’outil impose des contournements, reconstruire devient l’occasion de remettre le métier au centre.

La criticité de l’application pour l’activité

Plus une application est critique, plus la bascule doit être préparée. Cela ne plaide pas forcément contre une refonte, mais impose une méthode : recette par profil d’utilisateur, période de fonctionnement en parallèle, plan de retour en arrière. Un outil qui gère la facturation ou des données de santé ne se remplace pas comme un intranet.

Les contraintes de sécurité et de conformité

Certaines obligations ne peuvent pas être satisfaites par l’existant. C’est le cas lorsqu’un hébergement certifié devient nécessaire, lorsqu’il faut tracer les accès ou ajouter une authentification renforcée sur une architecture qui ne le permet pas. Dans ces situations, la conformité peut à elle seule faire pencher la balance.

Votre capacité à porter le projet

Une refonte mobilise vos équipes métier : ateliers, validation des règles, recette. Faire évoluer l’existant les sollicite moins intensément, mais plus longtemps. Avant de choisir, demandez-vous qui, chez vous, pourra arbitrer les priorités et valider les livrables au fil du projet.

En résumé

Ce que l’IA change dans l’équation, et ce qu’elle ne change pas

L’IA générative ne crée pas une troisième voie. Elle modifie le coût et la vitesse des deux existantes. Faire évoluer une application devient moins risqué, la reconstruire devient moins long. La décision, elle, reste à prendre avec les mêmes critères.

Chez Spiriit, nous utilisons déjà l’IA au quotidien dans nos projets de développement, et nous l’appliquons désormais à la reprise d’applications existantes. Voici ce que l’on peut raisonnablement en attendre aujourd’hui dans un projet de modernisation applicative.

Comprendre et documenter un code hérité plus vite

C’est probablement l’apport le plus utile. Une IA peut parcourir un code ancien, expliquer ce que fait chaque partie, cartographier les dépendances et produire une première documentation. Le travail d’analyse qui précède toute décision s’en trouve fortement accéléré. McKinsey rapporte par exemple un projet où l’étape de cartographie des relations entre composants est passée de 30 à 40 heures à environ cinq heures (McKinsey, décembre 2024).

Accélérer les montées de version et les tâches répétitives

Les migrations très standardisées, comme le passage d’une version de langage ou de framework à la suivante, se prêtent bien à l’automatisation. L’exemple le plus cité vient d’Amazon : en août 2024, son dirigeant Andy Jassy indiquait que la montée de version d’une application vers Java 17 était passée d’environ 50 jours-développeur à quelques heures en moyenne. Ce résultat est obtenu à une échelle et sur une tâche très particulières. Il montre néanmoins que le coût des travaux de mise à jour, longtemps repoussés faute de budget, est en train de baisser.

Sécuriser l’existant grâce aux tests

Toucher à une application sans tests est risqué : on ne sait pas ce que l’on casse. L’IA aide à générer des tests qui décrivent le comportement actuel de l’application avant toute modification. Ces tests servent ensuite de filet de sécurité, que l’on fasse évoluer l’existant ou que l’on vérifie qu’un nouvel outil reproduit fidèlement l’ancien.

Les limites à garder en tête

L’IA lit ce que fait le code, pas pourquoi il le fait. Une règle métier contre-intuitive peut être une erreur ancienne ou une exigence réglementaire : seul un échange avec les équipes métier permet de trancher.

Traduire automatiquement un vieux code dans une technologie récente ne règle pas non plus le problème de fond. McKinsey met justement en garde contre cette approche, qui revient selon le cabinet à transporter la dette technique dans un environnement moderne. Une architecture mal conçue reste mal conçue, même réécrite dans un langage récent.

Enfin, tout code produit par une IA doit être relu, testé et validé par des développeurs. Les gains annoncés sont réels, mais ils reposent toujours sur une supervision humaine et un cadrage solide. McKinsey évoque une accélération de 40 à 50 % des délais de modernisation, tout en précisant qu’il s’agit d’observations encore précoces.

En pratique, l’IA rend aujourd’hui accessibles des chantiers qui ne l’étaient pas il y a deux ans. Elle ne dispense ni de l’audit, ni des arbitrages métier, ni d’une méthode de bascule rigoureuse.

Retour d’expérience : quand l’audit oriente vers la refonte

ACI BIL est une mutuelle spécialisée dans l’assurance santé des expatriés, principalement en Afrique. Sa plateforme métier gère les contrats, les cotisations, les remboursements et la transmission de données médicales sensibles.

Lorsque l’équipe ACI BIL nous a sollicités, l’outil historique, développé en Node.js, était devenu instable et difficile à maintenir. L’audit a confirmé une dette technique importante : une application monolithique, peu structurée, dont la logique métier était dispersée. Corriger à la marge aurait prolongé le problème sans le résoudre. Nous avons donc recommandé de repartir de zéro, sur Symfony.

Plusieurs critères décrits plus haut ont pesé dans ce choix. L’architecture ne permettait plus d’évoluer sereinement. Les données de santé imposaient un hébergement certifié HDS, mis en place avec Claranet. Et la mutuelle avait besoin d’un socle capable d’accueillir de nouveaux services, comme la souscription en ligne.

La méthode a compté autant que la technologie. La refonte s’est déroulée sur deux ans, domaine métier par domaine métier, avec un product owner côté client et une roadmap partagée. Les tests ont été menés profil par profil : comptabilité, gestion, sinistres. Une phase de double saisie de plusieurs semaines a permis de comparer les résultats de l’ancien et du nouveau système, puis d’ajuster les règles métier avant la bascule définitive.

Aujourd’hui, la plateforme est en production et la collaboration se poursuit avec une nouvelle roadmap fonctionnelle, pilotée par des objectifs business et des indicateurs de réussite. Pour découvrir le projet en détail, consultez l’étude de cas ACI BIL.

Notre recommandation : décider sur la base d’un audit

Le choix entre faire évoluer et repartir de zéro se fait trop souvent sur une intuition : l’agacement des équipes face à un outil vieillissant, ou au contraire la crainte de perdre des années de travail. Ni l’une ni l’autre ne constitue un bon critère.

Nous recommandons de commencer par un audit, qui examine à la fois le code, l’architecture, la sécurité et l’usage réel de l’application par les équipes. C’est ce diagnostic qui permet de chiffrer honnêtement les deux options et de comparer leurs risques. Dans le cas d’ACI BIL, c’est lui qui a montré que des corrections ponctuelles ne suffiraient pas à stabiliser l’outil.

L’IA rend ce diagnostic plus rapide et les deux voies plus accessibles qu’auparavant. Elle ne change pas la question de fond : de quel outil votre activité aura-t-elle besoin dans cinq ans, et lequel des deux chemins vous y mène avec le moins de risque ?

Questions fréquentes

L’IA peut-elle réécrire seule une application métier ?

Non. L’IA accélère fortement l’analyse du code existant, la documentation, la génération de tests et certaines migrations répétitives. Elle ne comprend pas l’intention derrière les règles métier et ne remplace ni les arbitrages des équipes, ni la relecture et la validation par des développeurs. Une traduction automatique d’un code ancien reproduit aussi ses défauts d’architecture.

Peut-on conserver les données lors d’une refonte ?

Oui, et c’est même l’un des enjeux centraux du projet. La reprise des données se prépare en amont : analyse de la qualité des données existantes, adaptation au nouveau modèle, puis vérification. Une période de fonctionnement en parallèle, comme la double saisie mise en place pour ACI BIL, permet de comparer les résultats des deux systèmes avant la bascule.

Combien de temps dure une refonte complète ?

Tout dépend du périmètre fonctionnel, du volume de règles métier à reprendre et de la disponibilité de vos équipes. À titre d’exemple, la refonte de la plateforme d’ACI BIL s’est déroulée sur deux ans, domaine métier par domaine métier. Seul un audit permet d’établir une estimation fiable pour votre application.