Votre logiciel existe déjà, mais il devient difficile à maintenir, à faire évoluer ou à confier à une nouvelle équipe. Une refonte de logiciel peut alors devenir nécessaire, sans pour autant imposer de tout reconstruire.
Idéematic reprend l’existant, en évalue l’état et vous aide à déterminer ce qui doit être conservé, corrigé, refactoré ou entièrement refondu.
Un logiciel peut continuer à fonctionner tout en devenant difficile à maintenir ou à faire évoluer. La question d’une reprise ou d’une refonte se pose notamment lorsque :
Nous commençons alors par comprendre l’existant afin de déterminer ce qui peut être conservé, ce qui doit être corrigé et ce qui justifie une refonte plus profonde.
Tous les logiciels existants ne nécessitent pas d’être reconstruits. Selon leur architecture, leur dette technique, leurs usages et les évolutions attendues, plusieurs stratégies sont possibles.
Une reprise peut suffire lorsque le socle reste sain. Une refonte partielle permet de remplacer les composants devenus limitants sans toucher à l’ensemble. Une refonte complète devient pertinente lorsque l’architecture, les technologies ou l’organisation du logiciel empêchent durablement son évolution.
Notre rôle est de déterminer avec vous jusqu’où intervenir, sans engager une reconstruction plus lourde que nécessaire.
Un changement de prestataire ne signifie pas nécessairement qu’il faut repartir de zéro. La reprise commence par la récupération et la compréhension de ce qui permet réellement au logiciel de fonctionner : code source, architecture, base de données, dépendances, environnements, documentation et services externes.
Nous analysons ensuite le code et les principaux composants afin d’identifier les fragilités techniques, les éléments obsolètes et les dépendances critiques. Nous vérifions également les conditions de déploiement et les informations disponibles sur les anomalies déjà connues.
Cette phase de reprise de code nous permet d’intervenir avec une vision suffisamment claire de l’existant. Elle sert ensuite à décider ce qui peut être conservé, sécurisé ou refondu.
Lorsqu’un logiciel est utilisé chaque jour, une refonte ne peut pas toujours attendre qu’une nouvelle version soit entièrement reconstruite. Il faut parfois faire évoluer l’existant tout en maintenant le service disponible pour les utilisateurs.
Selon l’architecture et les dépendances du logiciel, nous pouvons organiser la refonte par étapes : remplacer certaines briques, faire coexister temporairement ancien et nouveau système, migrer progressivement les données ou basculer les fonctionnalités à mesure qu’elles sont prêtes.
Cette stratégie réduit les risques liés à une bascule unique et permet de tester chaque étape avant de poursuivre la transformation.
Les données, API et services tiers font souvent partie des éléments les plus sensibles d’une refonte. Une nouvelle application peut être techniquement réussie tout en créant des difficultés si elle rompt des échanges devenus indispensables avec le reste du système d’information.
Nous identifions donc les données à conserver, les flux à maintenir et les interfaces qui doivent être adaptées. Lorsque la structure des données évolue, nous préparons leur transformation et leur migration vers le nouvel environnement.
Des contrôles permettent ensuite de vérifier l’intégrité des données et le bon fonctionnement des échanges avant la bascule. L’objectif est de faire évoluer le logiciel sans perdre l’information ni casser les connexions dont dépendent les autres outils de l’entreprise.
Une application peut être techniquement vieillissante tout en restant profondément intégrée au fonctionnement de l’entreprise. Au fil des années, des règles métier, des circuits de validation et des habitudes de travail se sont parfois construits autour d’elle, sans être entièrement documentés.
Avant de les remettre en cause, nous cherchons à comprendre comment le logiciel est réellement utilisé. Nous distinguons les fonctions à préserver, celles qui peuvent être simplifiées et celles qui doivent être repensées pour répondre aux besoins actuels.
La refonte devient ainsi l’occasion d’améliorer l’outil, plutôt que de reproduire dans une nouvelle technologie les contraintes et les complexités accumulées dans l’ancien logiciel.
Le Conseil Général de l’Armement
disposait d’une application de suivi de carrières développée en Microsoft VB6 et reposant sur une base Oracle. Idéematic a repris cet existant pour réaliser une refonte complète du logiciel sous la forme d’une nouvelle application web.
Le projet a commencé par l’analyse de la solution en place et la récupération de ses données. Nous avons ensuite reconstruit le modèle de données sous PostgreSQL, transformé les données issues de l’ancienne base, redéveloppé les fonctionnalités et mis la nouvelle application en production.
Cette refonte devait respecter une contrainte forte : la nouvelle solution devait être réalisée dans un délai de six mois. Elle illustre concrètement notre capacité à reprendre un logiciel métier existant, préserver ses données et reconstruire son socle technique lorsqu’une refonte totale est justifiée.
La mise en production marque le passage vers une nouvelle phase. Le logiciel doit ensuite être suivi, corrigé et adapté lorsque de nouveaux besoins apparaissent.
Lorsque nous avons réalisé la reprise ou la refonte, nous conservons la connaissance acquise sur son architecture, ses données et son fonctionnement. Cette continuité facilite les évolutions futures et évite de repartir d’une nouvelle phase de découverte à chaque intervention.
Si le besoin devient principalement celui du suivi et de l’évolution courante de l’application, l’accompagnement peut alors se poursuivre dans le cadre d’une tierce maintenance applicative.
Témoignage client
Voir tous les avisMarc Maurer
Nous pouvons analyser avec vous l’existant, ses limites et vos nouveaux besoins afin de déterminer le niveau d’intervention pertinent : reprise de code, refonte partielle ou reconstruction plus profonde.