Une refonte logiciel sans arrêter l’activité.
L’application qui gère vos commandes, votre stock ou votre facturation a été écrite il y a des années, sur un serveur et un framework que plus personne ne maintient. On la modernise par vagues. Chaque vague est comparée à l’ancien système sur des données réelles, et l’ancien continue de tourner jusqu’à ce que votre équipe valide la bascule.
Double exécution de la nuit
Vague 3, gestion des commandes
Les commandes d’hier sont passées dans l’ancienne application et dans la nouvelle. Compare chaque résultat avant la bascule de la vague 3, jeudi.
- 06:30:02A comparé 1 412 commandes. Totaux, TVA, remises et dates de livraison, ligne par ligne.
- 06:30:05A trouvé 3 écarts. Tous sur des commandes livrées en partie.
- 06:30:07En a rattaché 2 à l’ancien code. Une règle d’arrondi écrite nulle part, sauf dans une fonction de 2011.
- 06:30:09En a rattaché 1 au nouveau code. Une remise client absente des données migrées.
- 06:30:11A préparé le correctif et un test pour que la règle et la remise soient vérifiées à chaque livraison.
Bascule de la vague 3 : votre équipe décide. Rien ne passe sur la nouvelle application tant qu’un ingénieur et l’ADV n’ont pas vérifié les trois cas.
Ce que pourrait devenir votre vieux logiciel.
Les deux premiers sont des projets réels. Le nom des clients reste confidentiel ; les faits sont ceux publiés à la livraison. Les deux derniers décrivent les situations pour lesquelles on nous appelle le plus souvent.
Projet réel : un groupe de distribution international, plus de dix applications
AvantLes applications de gestion du groupe reposaient sur un socle mixte PHP et .NET, avec MariaDB, MongoDB et SQL Server, sur des systèmes d’exploitation et des middlewares en partie plus maintenus, et des serveurs différents d’une instance à l’autre.
AprèsAu sein de l’équipe projets de la DSI du groupe, plus de dix applications ont été modernisées par vagues, une application après l’autre, sur des systèmes maintenus et un hébergement cloud unifié, avec une contrainte : ne jamais interrompre l’exploitation.
Projet réel : une entreprise de génération de leads B2B qui a gardé sa base technique
AvantL’équipe produit ne livrait plus, et la direction ne savait plus quoi demander à ses développeurs.
AprèsLa base JavaScript a été gardée telle quelle, sans refonte technique. Le cadre autour a été reposé : un product owner interne recruté et formé, une équipe qui livre de nouveau, et plus aucune dépendance envers nous.
L’outil que seul un développeur parti à la retraite comprenait
AvantUne application critique, aucune documentation, et des règles métier que personne ne sait énoncer avant qu’elles cassent.
AprèsLes règles sont lues dans l’ancien code, écrites noir sur blanc et transformées en tests avant de refaire le moindre écran.
Le logiciel installé sur chaque poste, qui doit passer au web
AvantUne application installée poste par poste, une base partagée sur un serveur local, et aucun accès hors du bureau.
AprèsUne application web avec les mêmes données et les mêmes habitudes, accessible de partout avec de vrais droits d’accès.
Qu’est-ce qu’une refonte logiciel, ou modernisation applicative ?
La refonte logiciel, ou modernisation applicative, consiste à reprendre un logiciel métier qui fait encore son travail mais qui est devenu risqué ou coûteux à faire évoluer, pour l’amener sur des technologies maintenues. Selon le cas, on change son hébergement, on en réécrit une partie ou on le reconstruit, le plus souvent par étapes. Le but : pouvoir de nouveau le faire évoluer, sans perdre les règles que portait l’ancien.
Une migration d’application échoue rarement sur la technique. Elle échoue quand le savoir caché de l’ancien système se perd en route : la règle d’arrondi, l’exception pour un gros client, le traitement qui tourne le dernier jour du mois. C’est pourquoi on lit l’ancien code avant de planifier quoi que ce soit, et pourquoi chaque règle migrée devient un test automatique.
Tous les vieux logiciels n’ont pas besoin d’être réécrits. Certains demandent seulement un nouveau serveur, une version à jour du langage et une base de données remise en ordre. D’autres cachent un problème d’organisation qu’aucun code neuf ne réglera. Le premier travail consiste à savoir dans quel cas vous êtes : c’est l’objet de l’audit de code.
Réhéberger, remanier, reconstruire ou remplacer : quelle refonte pour votre application ?
Six options, de la plus légère à la plus radicale. La plupart des parcs applicatifs en combinent plusieurs, une par application.
| Critère | Ce qui change | Quand c’est adapté | Point de vigilance |
|---|---|---|---|
| Garder et sécuriser | Correctifs de sécurité et surveillance, rien d’autre | Un logiciel stable, appelé à être remplacé d’ici quelques années | Le risque grandit chaque année |
| Réhéberger | Nouvel hébergement, même code | Le serveur ou la salle machine pose problème | Le vieux code reste vieux |
| Changer de socle | Langage, base de données et système d’exploitation maintenus | Le code est sain, ses fondations ne sont plus maintenues | Des incompatibilités cachées, que seuls les tests révèlent |
| Remanier | Le code est réorganisé et nettoyé, morceau par morceau | Le logiciel fait ce qu’il faut, mais chaque évolution est lente et risquée | Demande des tests avant de commencer |
| Reconstruire | Un nouveau logiciel, les mêmes règles métier | La technologie est morte ou la conception bloque l’activité | Des règles perdues en route, si on ne les écrit pas d’abord |
| Remplacer par un progiciel | Un produit du marché à la place du sur-mesure | Le processus est standard et rien ne vous distingue | C’est votre processus qui s’adapte au produit |
Votre activité continue pendant que le logiciel change.
Sécurité et donnéesL’ancien système reste en service tant que le nouveau n’a pas fait ses preuves.
Chaque vague tourne en parallèle de l’ancienne application sur des données réelles, et c’est votre équipe qui décide de la bascule.
Les règles cachées sont écrites d’abord.
Ce que fait l’ancien code est documenté et transformé en tests avant toute reconstruction.
Des données migrées avec contrôles et retour arrière.
Chaque migration est répétée, comptée et rapprochée, avec un plan de retour arrière écrit avant la bascule.
Le résultat est à vous.
Code source, documentation et scripts de déploiement vous sont remis, sur des technologies répandues qu’une autre équipe peut reprendre.
L’hébergement que vous choisissez.
Vos serveurs, un cloud privé ou un cloud européen, selon les données que porte chaque application.
Comment se déroule votre modernisation, vague après vague.
D’abord
Faire l’état des lieux
On lit le code, les données et les serveurs, et on échange avec ceux qui utilisent et maintiennent le logiciel. Vous recevez l’état de chaque application et l’option qui lui convient.
Ensuite
Planifier les vagues
Les applications sont regroupées en vagues, ordonnées selon le risque et la valeur. Chaque vague a un périmètre écrit et un prix ferme avant de démarrer.
À chaque vague
Migrer et faire tourner en parallèle
La nouvelle version tourne à côté de l’ancienne sur des données réelles. Les écarts sont expliqués et corrigés jusqu’à ce que votre équipe valide la bascule.
À la fin
Arrêter l’ancien et transmettre
L’ancien système est archivé avec ses données. Vous gardez la documentation et choisissez qui maintient la suite.
De quoi dépend le coût d’une refonte logicielle.
Entre déplacer une application saine vers un nouvel hébergement et reconstruire un système de vingt ans, l’état des lieux place chacune de vos applications sur l’échelle, et chaque vague est chiffrée par écrit avant de démarrer.
Lire le guide des prix du logiciel sur mesure, avec les fourchettes du marché- 01Le nombre d’applications, et à quel point elles dépendent les unes des autres.
- 02La taille et l’état du code, et l’existence de tests.
- 03Le volume et la qualité des données à migrer.
- 04Les systèmes avec lesquels chaque application échange des données.
- 05Combien de temps l’ancien et le nouveau doivent tourner en parallèle.
- 06L’hébergement visé, et les règles de sécurité de votre secteur.
Modernisation applicative : les questions qu’on nous pose
Combien de temps dure une refonte logicielle ?
Cela dépend du nombre d’applications et de leur état, d’où l’état des lieux au départ. Un parc se modernise par vagues, et chaque vague a son périmètre et son prix ferme avant de démarrer : vous ne vous engagez jamais d’un bloc sur un projet de plusieurs années.
Faut-il réécrire l’application ou la remanier ?
On réécrit quand la technologie est morte ou que la conception bloque l’activité. On remanie quand le logiciel fait ce qu’il faut mais que chaque évolution est lente. Beaucoup d’applications n’ont besoin ni de l’un ni de l’autre : un socle à jour et un nouvel hébergement suffisent. L’état des lieux le dit, application par application.
L’ancien système peut-il continuer à tourner pendant la migration ?
Oui, et c’est ainsi qu’on travaille. L’ancienne et la nouvelle version tournent en parallèle sur des données réelles pendant chaque vague. Votre équipe ne bascule qu’une fois les résultats identiques, et l’ancien reste disponible jusqu’à la confirmation de la bascule.
Nous n’avons aucune documentation et les développeurs d’origine sont partis. Est-ce un problème ?
C’est la situation habituelle. Les règles sont lues dans le code et dans les données, puis vérifiées avec ceux qui utilisent le logiciel chaque jour. Ce qu’on trouve est écrit et devient un test : cette fois, le savoir reste chez vous.
Pouvez-vous migrer nos applications vers le cloud, ou les garder sur nos serveurs ?
Les deux. On peut migrer vers un cloud européen, un cloud privé ou vos propres serveurs, et mettre à jour au passage systèmes d’exploitation, langages et bases de données. Le choix dépend des données que porte chaque application.
Peut-on ajouter de l’IA au logiciel modernisé ?
Oui, là où elle retire du vrai travail : lire les documents qui arrivent, préparer les saisies, répondre à partir de vos données. Une application modernisée, avec un modèle de données propre, accueille l’IA bien plus sûrement que l’ancienne, et on le prévoit dès la première vague.
Services et guides liés
- Logiciel sur mesure Quand le logiciel doit être construit de zéro.
- Audit de code La première étape : connaître l’état de ce que vous avez.
- Tierce maintenance applicative Pour garder le logiciel modernisé à jour.
- Application métier Quand le vieil outil devient une nouvelle application interne.
- Intégration IA Pour ajouter l’IA au logiciel une fois modernisé.
- Prix du logiciel sur mesure Les fourchettes du marché, avec leurs sources.
- La dette technique, expliquée D’où elle vient, ce qu’elle coûte, comment la rembourser.
Le logiciel d’hier, redevenu un atout.
Dites-nous quelle application vous inquiète et ce qu’elle fait tourner aujourd’hui. On vous répond sous un jour ouvré pour caler votre audit gratuit de 30 minutes, avec une première idée de l’option qui lui convient.