Un logiciel peut encore fonctionner tout en devenant difficile à maintenir, à sécuriser ou à faire évoluer. Nous commençons par auditer l’existant pour comprendre son architecture, ses dépendances, ses données et les usages métier à préserver.
Cette analyse permet de choisir la bonne trajectoire : reprise du code, refonte partielle, migration ou reconstruction complète, sans repartir de zéro lorsqu’il n’y a aucune raison de le faire.
Un logiciel peut continuer à fonctionner tout en devenant progressivement difficile à maintenir, à sécuriser ou à faire évoluer. Avec le temps, certaines contraintes techniques peuvent ralentir les développements, augmenter les risques de régression ou limiter les possibilités d’évolution.
Plusieurs signaux doivent alors alerter :
Les données, API et connexions au système d’information peuvent également rendre un remplacement brutal particulièrement risqué. Avant de décider d’une refonte, il est donc essentiel d’identifier ce qui doit réellement être remplacé, modernisé ou conservé.
Un audit du logiciel permet d’évaluer les points de blocage, les composants encore fiables et les dépendances critiques. Cette analyse permet ensuite de choisir une stratégie de reprise adaptée, plutôt que d’engager une reconstruction complète par principe.
La stratégie dépend de l’état réel du logiciel, de son architecture et des évolutions attendues. Trois approches peuvent être envisagées :
Le choix entre ces différentes trajectoires repose sur l’analyse de l’existant, mais aussi sur les contraintes de continuité de service, le niveau de risque acceptable et les objectifs d’évolution du logiciel.
Changer de prestataire ou d’équipe technique ne signifie pas qu’il faut reconstruire le logiciel. Nous pouvons reprendre une application sans avoir participé à sa conception initiale, à condition de commencer par reconstituer une compréhension fiable de son fonctionnement.
Nous examinons notamment le code source, les technologies et dépendances utilisées, la structure des données, les API et services connectés, les environnements d’hébergement, les procédures de déploiement, les tests et la documentation disponible. Lorsque celle-ci est incomplète, l’analyse du code et du fonctionnement réel de l’application permet d’identifier progressivement les zones maîtrisées, les dépendances critiques et les points de vigilance.
Lorsque l’état de l’application nécessite une analyse plus approfondie, un audit technique permet d’objectiver les fragilités, la dette technique et les risques avant de décider des travaux à engager.
La reprise consiste ensuite à sécuriser la capacité à maintenir et faire évoluer le logiciel : reproduire les environnements nécessaires, vérifier les principaux parcours métier, fiabiliser les déploiements et documenter les éléments indispensables à la nouvelle équipe.
Ce travail permet de reprendre progressivement la maîtrise du projet avant de décider des corrections, modernisations ou refontes réellement nécessaires.
Lorsqu’un logiciel est utilisé quotidiennement, sa refonte ne peut pas toujours attendre qu’une nouvelle version complète soit prête. Nous pouvons alors organiser la transformation par étapes, en définissant les composants ou fonctionnalités à reprendre en priorité.
L’ancien et le nouveau système peuvent coexister temporairement. Les données, interfaces ou fonctionnalités sont migrées progressivement, puis validées avant chaque nouvelle bascule. Cette approche permet de limiter les risques, de conserver les usages indispensables et de corriger rapidement un problème sans remettre en cause l’ensemble du projet.
Le découpage dépend de l’architecture existante, des dépendances entre les modules et des contraintes d’exploitation. L’objectif est de moderniser le logiciel tout en maintenant autant que possible la continuité de service pour ses utilisateurs.
Dans un logiciel métier, une partie essentielle de la valeur se trouve dans les données accumulées au fil des années et dans les échanges établis avec le reste du système d’information. Leur préservation doit donc être pensée dès le début de la refonte.
Nous cartographions les bases de données, API, fichiers échangés, services externes et mécanismes d’authentification utilisés par l’application. Pour chaque élément, nous déterminons ce qui peut être conservé en l’état, ce qui doit être adapté et ce qui mérite d’être remplacé.
La migration des données est préparée et testée avant la bascule. Les correspondances entre anciens et nouveaux modèles sont vérifiées, ainsi que l’intégrité des informations et le bon fonctionnement des interfaces avec les autres outils.
Cette approche permet de moderniser le logiciel sans perdre son historique ni rompre les échanges dont dépendent ses utilisateurs et les autres applications de l’entreprise.
La refonte d’une application métier ne doit pas remettre en cause les usages et les fonctionnalités qui répondent encore correctement aux besoins des utilisateurs. Derrière une interface parfois vieillissante se trouvent souvent des années de règles métier, de parcours, d’automatismes et de cas particuliers qui participent directement au fonctionnement de l’entreprise.
Avant de modifier les interfaces ou les processus, nous identifions :
Nous distinguons ainsi ce qui mérite d’être conservé de ce qui peut être simplifié ou repensé.
La modernisation peut alors être profonde sur le plan technique sans imposer inutilement de nouveaux usages. Lorsque certains parcours doivent évoluer, ils sont repensés en tenant compte du fonctionnement réel des équipes et validés sur des scénarios représentatifs avant leur mise en production.
L’objectif n’est pas de reproduire l’ancien logiciel à l’identique, mais de préserver sa valeur métier tout en supprimant les contraintes qui limitaient son évolution.
Pour le Conseil Général de l’Armement (CGARM), Idéematic a réalisé la refonte complète d’un logiciel métier de suivi de carrières. L’application existante avait été développée en Microsoft VB6 et reposait sur une base de données Oracle.
L’objectif était de la remplacer par une nouvelle application web, tout en conservant les données et les fonctionnalités indispensables aux utilisateurs.
Le projet a commencé par l’analyse de la solution existante et de son modèle de données. Les informations de l’ancienne base Oracle ont été extraites, retraitées puis adaptées au nouveau modèle PostgreSQL. En parallèle, les fonctionnalités métier ont été redéveloppées dans le nouveau socle applicatif, avec notamment un moteur de recherche interne et plusieurs optimisations destinées à rendre l’application plus rapide et plus simple à utiliser.
La refonte devait être réalisée dans un calendrier particulièrement contraint, avec une échéance de six mois. Après la mise en production, Idéematic a poursuivi l’accompagnement avec la maintenance évolutive de l’application et l’assistance aux utilisateurs.
Ce projet illustre ce qu’implique une refonte de logiciel métier :
La mise en production d’un logiciel refondu ne marque pas la fin du projet. Les premiers mois permettent de confirmer son fonctionnement dans les conditions réelles d’utilisation, de traiter les éventuels ajustements et d’accompagner les évolutions qui apparaissent après la bascule.
Lorsque nous poursuivons l’accompagnement, nous conservons la connaissance acquise pendant la reprise et la refonte. Cette continuité facilite le diagnostic des incidents, les corrections, les mises à jour techniques et le développement de nouvelles fonctionnalités.
Notre équipe reste également force de proposition. Les retours utilisateurs, les nouveaux besoins métier et l’usage réel de l’application permettent d’identifier de nouvelles pistes d’amélioration : simplification de certains parcours, évolution de l’expérience utilisateur, automatisation de tâches, ajout de fonctionnalités ou adaptation à de nouveaux processus internes.
Le logiciel peut ainsi continuer à évoluer sur une base désormais maîtrisée, avec une équipe qui connaît son architecture, ses règles métier et ses interconnexions, et qui peut accompagner son amélioration dans la durée.
Cet accompagnement peut ensuite s’inscrire dans une tierce maintenance applicative (TMA) afin d’organiser la maintenance corrective, les évolutions et le suivi technique du logiciel.
Témoignage client
Voir tous les avisMarc Maurer
Votre logiciel montre ses limites, mais la bonne approche n’est pas encore évidente ? Nous pouvons analyser l’existant avec vous, identifier ce qui mérite d’être conservé et déterminer s’il faut le reprendre, le moderniser ou le refondre plus en profondeur.