Les applications métier ont, par nature, besoin d’évoluer. Nouvelles fonctionnalités, intégration à d’autres outils, mise en conformité technique ou simplement amélioration de l’expérience utilisateur : elles doivent s’adapter pour rester utiles et performantes.
Lorsqu’un logiciel a bénéficié de mises à jour régulières, il est généralement facile de le faire évoluer. Dans ce cas, une modernisation suffit souvent à lui redonner un second souffle (voir notre article Peut-on moderniser sans tout reconstruire ?).
Mais lorsque les mises à jour se sont faites rares, ou que la dette technique est devenue trop lourde, l’application peut finir par être bloquante, voire inmaintenable. À ce stade, une refonte devient souvent la seule voie possible pour repartir sur des bases saines. Pour comprendre les signaux d’alerte et les enjeux associés, vous pouvez aussi consulter notre article Pourquoi faire une refonte de son application métier ?.
Reste à choisir comment refondre. Car il existe plusieurs approches, plus ou moins ambitieuses, chacune avec ses avantages, ses risques et ses implications.
Parfois, on parle de refonte alors qu’il ne s’agit en réalité que d’un lifting. Cette méthode n’est envisageable que lorsque les changements concernent exclusivement la partie visible de l’application — par exemple pour moderniser l’interface utilisateur — sans toucher aux technologies ou au socle technique.
Dans ce cas, on modifie directement le code existant, page par page, en ajoutant de nouvelles API pour faire le lien avec les données si nécessaire. Cela permet, en théorie, de revenir en arrière à tout moment.
Sur le papier, l’approche semble rassurante. Elle reste dans la continuité de l’application actuelle, sans prise de risque majeure. En pratique, elle est rarement recommandée : elle conserve toutes les limites techniques et failles de sécurité d’origine, nécessite des développeurs connaissant d’anciennes technologies souvent obsolètes (et donc coûteuses), et s’appuie sur une documentation devenue rare. Résultat : des délais qui s’allongent, et un résultat souvent décevant.
En résumé, on ne choisit cette voie que si l’on n’a vraiment pas le choix — ou pour gagner un peu de temps avant un vrai projet de refonte.
La méthode la plus radicale consiste à reconstruire l’application entièrement, en listant toutes les fonctionnalités existantes et en les recréant sur une base technologique neuve. Une fois le développement terminé et les tests validés, la nouvelle version remplace l’ancienne d’un seul coup.
Cette approche a le mérite de la clarté : elle offre une application entièrement rénovée, plus performante, plus sécurisée, et souvent enrichie de nouvelles fonctionnalités. L’effet “wahou” à la mise en production est garanti.
Mais le revers de la médaille, c’est le temps et le coût. Le projet est long, mobilise fortement les équipes et demande une gestion rigoureuse pour éviter les régressions ou les écarts fonctionnels. En somme, le Big Bang est une excellente option si le calendrier n’est pas contraint, que le budget est solide, et que la dette technique ou fonctionnelle est trop importante pour envisager une refonte progressive.
C’est aussi une méthode adaptée aux organisations qui préfèrent un mode projet classique, avec une livraison finale plutôt qu’un déploiement itératif.
La refonte applicative n’est pas une dépense, c’est un investissement dans la longévité de votre outil métier.
Entre la rustine et le grand saut, il existe une approche plus équilibrée : la refonte progressive, parfois appelée Dual Run.
Le principe est simple : au lieu d’attendre que la nouvelle application soit entièrement terminée pour la livrer, on la déploie par étapes. Une passerelle technique relie alors l’ancienne et la nouvelle version : à chaque fois qu’une fonctionnalité est refondue, l’utilisateur est automatiquement redirigé vers la nouvelle page, tandis que le reste continue de tourner sur l’ancien système.
Cette approche permet des livraisons plus fréquentes, une meilleure visibilité sur les progrès réalisés, et la possibilité de corriger rapidement les régressions. Elle offre aussi un certain confort : en cas de problème, il est toujours possible de revenir en arrière puisque l’ancien code coexiste temporairement avec le nouveau.
Son principal inconvénient tient à la complexité supplémentaire à gérer : il faut maintenir une cohérence entre deux environnements, ce qui demande un peu de rigueur et quelques ajustements techniques. Mais pour les organisations qui souhaitent avancer pas à pas, en méthodologie agile, et étaler les coûts dans le temps, c’est souvent la voie la plus efficace.
Et pour un exemple concret de refonte progressive à grande échelle : Refonte d’applications métiers progressive au sein d’un ERP pour SALTI
Il n’existe pas de recette universelle : chaque projet de refonte dépend du contexte métier, du niveau d’obsolescence technique et des contraintes de l’entreprise.
- Si votre application a accumulé trop de dette technique et que vous pouvez vous permettre un chantier global, la refonte Big Bang offrira un résultat homogène et durable.
- Si vous préférez avancer progressivement, tout en assurant la continuité du service et en sécurisant chaque étape, la refonte progressive (Dual Run) sera plus adaptée.
- Quant à la “fausse refonte”, elle ne peut être qu’un pis-aller, un compromis temporaire en attendant un vrai projet de modernisation.
Dans tous les cas, pensez continuité et pérennité : une fois la refonte engagée, il faut maintenir l’élan avec la mise en place d’une stratégie de maintenance (corrections/évolutions/veille) ou d’un contrat de Tierce Maintenance Applicative.
Refondre une application métier, ce n’est pas seulement une question technique : c’est un choix stratégique, qui engage l’entreprise pour plusieurs années. D’où l’importance de bien poser le diagnostic avant de se lancer.
Chez Access it, nous accompagnons nos clients dès cette phase de réflexion, pour définir la trajectoire la plus adaptée : analyse de l’existant, identification des risques, choix des technologies, planification des livraisons et accompagnement des équipes internes.
Refondre, ce n’est pas “repartir de zéro”, c’est se donner les moyens d’aller plus loin — de transformer un outil devenu rigide en une application à nouveau vivante, agile et pérenne.
Et si vous hésitez encore entre moderniser ou refondre, notre article Rénover ou reconstruire : de quoi parle-t-on exactement ? vous aidera à y voir plus clair vous aidera justement à y voir plus clair.
