Cas d’usage
Votre logiciel fonctionne encore. Le faire évoluer devient le problème.
L'application rend toujours le service pour lequel elle a été construite. Mais chaque modification demande plus de temps, plus de précautions, et repose sur de moins en moins de personnes. La question n'est pas de savoir si elle est « vieille » : c'est de savoir ce qu'elle vous coûte pour avancer.
Vous vous reconnaissez peut-être
Il suffit rarement que tout soit vrai. Deux ou trois de ces points suffisent à ralentir durablement une équipe.
- Chaque modification risque de casser autre chose, et personne ne sait vraiment quoi avant de livrer.
- Certaines briques techniques ne reçoivent plus de mises à jour, y compris de sécurité.
- Une partie du code n'est plus touchée : on contourne plutôt que d'y entrer.
- Les mises en production sont manuelles, longues, et se font en dehors des heures ouvrables.
- Ajouter une fonctionnalité qui semble simple demande un effort anormalement élevé.
- Les intégrations avec les autres outils sont devenues fragiles et se réparent au cas par cas.
- La connaissance du système tient dans la tête d'une ou deux personnes.
Ce qui se passe si on ne fait rien
Rien ne s'effondre du jour au lendemain. C'est justement ce qui rend la situation difficile à arbitrer.
- Le coût du changement augmente en silence
- Chaque évolution demande un peu plus de précautions que la précédente. Le budget de maintenance grignote celui des nouveautés, sans qu'aucune décision n'ait été prise.
- Les dépendances non maintenues deviennent un sujet de sécurité
- Une bibliothèque ou un composant qui ne reçoit plus de correctifs ne devient pas un problème progressivement : il le devient le jour où une faille est publiée.
- Le système devient un argument contre le métier
- Les demandes des équipes sont refusées parce qu'elles sont techniquement coûteuses, pas parce qu'elles sont mauvaises. Le logiciel finit par décider de ce que l'entreprise peut faire.
- Le départ d’une personne devient un risque d’exploitation
- Quand la compréhension du système n'est écrite nulle part, une démission ou une absence longue transforme une évolution ordinaire en chantier d'investigation.
Réécrire n’est pas toujours la bonne réponse
Quatre trajectoires sont défendables selon la situation. La réécriture complète est la plus visible, rarement la plus raisonnable.
| Réécrire n’est pas toujours la bonne réponse | Quand c’est le bon choix | Ce que cela implique |
|---|---|---|
| Maintenir | Le système répond encore au besoin, les évolutions attendues sont limitées et le risque technique est maîtrisé. | Mettre à jour les dépendances, documenter l'essentiel, et accepter que l'application ne soit pas un chantier. C'est une décision, pas de l'inaction. |
| Moderniser progressivement | Le système reste pertinent sur le fond, mais certaines parties bloquent : couplage, absence de tests, déploiement manuel, interface dépassée. | Isoler les zones à risque, exposer des interfaces stables, remplacer morceau par morceau. L'ancien et le nouveau cohabitent pendant toute la transition. |
| Refondre | Une contrainte fondamentale empêche réellement d'avancer : modèle de données inadapté, plateforme abandonnée, architecture qui interdit ce que le métier demande. | Un projet long, avec reprise de données et double fonctionnement. À n'engager qu'avec un périmètre cadré et une trajectoire par étapes. |
| Remplacer par un produit du marché | Le processus supporté ne constitue plus un avantage distinctif et un produit existant couvre le besoin sans contorsion. | Accepter de plier certains usages au produit, et traiter sérieusement la reprise des données et des règles métier accumulées. |
Nous ne recommandons pas systématiquement la trajectoire la plus lourde. Dans plusieurs situations, maintenir proprement pendant deux ans est la meilleure décision économique.
Ancien et nouveau peuvent cohabiter
La modernisation progressive ne consiste pas à arrêter un système pour en démarrer un autre. À chaque étape, les deux tournent, et la part portée par l'application d'origine diminue.
- 01
Stabiliser
Remettre en place tests, déploiement automatisé et surveillance. Rien ne change pour les utilisateurs.
- 02
Isoler
Délimiter les zones à risque et couper les dépendances croisées qui rendent tout changement global.
- 03
Exposer
Sortir les données et les règles derrière une interface stable, que l'ancien comme le nouveau peuvent appeler.
- 04
Remplacer
Reconstruire une fonction à la fois, en bascule contrôlée et réversible.
- 05
Retirer
Supprimer le code devenu inutile. Tant qu’il reste, il faut continuer à le maintenir.
La dernière étape est celle qu'on oublie le plus souvent. Un ancien composant laissé en place « au cas où » continue de coûter en maintenance et en surface d'exposition.
Comment nous abordons le problème
Avant de proposer une trajectoire, il faut savoir ce que le système fait réellement — ce qui n'est presque jamais ce que la documentation en dit.
- 01
Comprendre l’existant
Lecture du code, cartographie des dépendances, inventaire de ce qui est déployé et testé. Nous parlons aussi aux utilisateurs : certaines règles métier ne vivent que dans leurs habitudes.
- 02
Identifier les zones de risque
Où une modification se propage, quelles dépendances ne sont plus maintenues, quelles parties n'ont ni test ni documentation, et où la connaissance est concentrée.
- 03
Décider ce qui doit rester
Toutes les parties d'un système ne méritent pas le même effort. Certaines sont stables et bien écrites : elles restent. La discussion porte sur le reste.
- 04
Sécuriser les interfaces et les données
Avant de remplacer quoi que ce soit, on stabilise les points d'échange et on vérifie l'état réel des données : doublons, champs détournés de leur usage, historique incomplet.
- 05
Moderniser par incréments
Une zone à la fois, mise en production régulièrement, avec un retour arrière possible. Le système reste utilisable pendant toute la durée du chantier.
- 06
Migrer les données
La reprise se prépare tôt, se répète à blanc, et se vérifie par des contrôles de cohérence avant la bascule. C'est la partie la plus sous-estimée de ce type de projet.
- 07
Retirer la dette devenue inutile
Suppression des composants remplacés, des accès qui ne servent plus et des environnements oubliés. Sans cette étape, la modernisation ajoute une couche au lieu d'en enlever une.
Sur un système ancien, la migration des données mérite souvent son propre cadrage : c'est là que se trouvent les surprises, pas dans le code.
Et si personne ne connaît plus vraiment le code ?
C'est une situation fréquente, et elle ne bloque pas un projet. Elle change simplement la manière de commencer.
Le système exécuté fait référence
Ce qui tourne en production est la spécification la plus fiable disponible. On l'observe, on trace les appels, on reconstitue les comportements réels avant de toucher à quoi que ce soit.
Les données racontent les règles
Un champ toujours rempli de la même façon, une valeur qui ne devrait pas exister, une table qui ne sert plus : le contenu réel révèle des règles métier que personne ne sait plus énoncer.
Les tests se posent avant les modifications
Sur un code non testé, la première livraison utile consiste souvent à écrire des tests qui décrivent le comportement actuel — sans le corriger, pour pouvoir le changer ensuite sans deviner.
Ce que cela peut donner
Quelques formes que prend concrètement ce type de trajectoire, selon la situation de départ.
- Une chaîne de tests et de déploiement automatisée sur une application qui se livrait à la main
- Une API stable devant un système ancien, pour que les autres outils cessent de taper dans sa base
- Une interface reconstruite sur les écrans les plus utilisés, le reste étant conservé tel quel
- Un module critique isolé puis réécrit, pendant que le reste de l’application continue de tourner
- Une migration de données avec contrôles de cohérence et répétition à blanc avant bascule
- Un plan de retrait des composants remplacés, avec les accès et environnements associés
Ces exemples décrivent des formes de solution possibles, pas des projets réalisés présentés comme références.
Cette trajectoire peut mobiliser
Selon le point de départ, un ou plusieurs de nos domaines interviennent. Le cadrage détermine lesquels.
Questions fréquentes
Faut-il forcément réécrire une vieille application ?
Non, et c'est rarement le meilleur choix. Une réécriture complète fait perdre des années de règles métier accumulées, coûte cher et ne produit rien d'utilisable avant longtemps. Dans la majorité des cas, il vaut mieux isoler la partie qui pose réellement problème et la remplacer, pendant que le reste continue de fonctionner.
Peut-on moderniser sans arrêter le système ?
Oui, et c'est le principe même de la modernisation progressive : à chaque étape, l'ancien et le nouveau tournent en parallèle. Les bascules se font fonction par fonction, avec un retour arrière possible. Cela demande plus de rigueur qu'un remplacement en une fois, mais cela évite d'arrêter l'activité.
Comment reprendre un logiciel dont la documentation est incomplète ?
En partant de ce qui tourne plutôt que de ce qui est écrit. Lecture du code, observation du système en production, analyse des données réelles et entretiens avec les utilisateurs permettent de reconstituer le comportement effectif. Le résultat de cette phase devient la documentation qui manquait.
Comment gérer la migration des données ?
En la traitant comme un chantier à part entière, pas comme une étape finale. Cela suppose d'analyser tôt l'état réel des données, de définir des règles de transformation explicites, de répéter la migration à blanc autant de fois que nécessaire, et de prévoir des contrôles de cohérence après bascule. C'est là que se produisent la plupart des mauvaises surprises.
Combien de temps cela prend-il ?
Cela dépend entièrement de la taille du système et de la trajectoire retenue, et aucune de ces deux données n'est connue avant le cadrage. Ce que nous pouvons dire : une modernisation progressive produit des résultats utilisables en continu, là où une refonte ne livre rien avant la fin.
Parlons de votre application
Décrivez-nous ce qui bloque aujourd'hui. Nous vous dirons franchement quelle trajectoire nous semble raisonnable — y compris celle de ne pas lancer de projet maintenant.