Moderniser un logiciel hérité sans réécriture totale

Presque toute entreprise établie en a un : un logiciel que tout le monde déteste en silence. Il est lent, il est laid, la moitié de l'équipe connaît un contournement pour le bug que personne n'a jamais corrigé, et la seule personne qui le comprenait est partie en 2019. Le réflexe est toujours le même — tout raser et en construire un neuf. Et ce réflexe, plus souvent qu'on ne le croit, est précisément la manière dont de bonnes entreprises perdent une année et une petite fortune pour rien.

J'ai vu la grande réécriture mal tourner assez souvent pour en avoir développé un réflexe. Un dirigeant me montre son système de commandes qui grince ou son antique outil de planification, soupire et dit une version de « il faut juste tout remplacer ». Et peut-être qu'un jour vous le ferez. Mais la réécriture complète — arracher l'ancien système, en bâtir un neuf et reluisant en parallèle, basculer un interrupteur — est l'un des mouvements les plus risqués de tout le logiciel. C'est coûteux, cela prend bien plus de temps que promis, et pendant toute cette durée vous avancez à l'aveugle, en espérant que le nouveau couvre chaque cas tordu que l'ancien traitait en silence depuis quinze ans.

La bonne nouvelle, c'est que la réécriture totale n'est presque jamais la seule option, et rarement la meilleure. Il existe une façon plus sereine de moderniser — progressive, réversible et respectueuse de l'activité qui doit continuer à gagner de l'argent pendant que vous travaillez. Voici un guide de cette voie : comment repérer ce qui doit vraiment être réparé, comment remplacer les parties douloureuses sans mettre tout le système à terre, et comment savoir quand une réécriture complète est réellement le bon choix.

Pourquoi la réécriture totale est si tentante — et si dangereuse

La réécriture complète séduit parce qu'elle promet une page blanche. Fini le désordre hérité, finis les compromis, une base de code neuve bâtie comme il faut avec des outils modernes. Sur un tableau blanc, cela paraît évident. En réalité, vous vous engagez à reconstruire des années de logique métier accumulée — souvent non documentée, parfois logée seulement dans la tête de gens partis depuis longtemps — pendant que l'horloge tourne et que les factures arrivent.

Le piège plus profond est le problème de l'univers parallèle. Durant les mois ou les années nécessaires à bâtir le remplaçant, vous avez deux systèmes : l'ancien, qui doit encore faire tourner l'activité, et le nouveau, qui n'est pas prêt. Chaque changement dont l'entreprise a besoin doit être fait deux fois, sinon le nouveau système prend du retard sur la réalité avant même de démarrer. Les équipes s'épuisent à maintenir les deux en vie. Et comme personne n'a le droit de basculer tant que le nouveau système ne fait pas tout, il n'y a aucune victoire précoce, aucun retour, aucune preuve que cela fonctionne — juste une longue attente anxieuse jusqu'à un unique et énorme jour de lancement, tout ou rien.

Il existe ici un adage bien connu du secteur, et il est mérité : le second système, la grande réécriture, a tendance à prendre trois fois plus de temps que prévu et à arriver avec moins de fonctionnalités que ce qu'il remplace. L'estimation n'est pas fausse par négligence. Elle est fausse parce qu'au départ personne ne peut voir toutes les petites choses que l'ancien système fait bien sans rien dire.

Ce que « hérité » veut vraiment dire (ce n'est pas une question d'âge)

Nous employons le mot hérité comme s'il signifiait simplement « vieux ». Ce n'est pas le cas. Une foule de logiciels qui tournent depuis une décennie vont parfaitement bien — ennuyeux, stables, payés, faisant leur travail. L'âge à lui seul n'est pas une raison de toucher à quoi que ce soit. L'erreur la plus coûteuse de tout ce domaine est de moderniser une chose qui marchait tranquillement, juste parce qu'elle paraissait datée.

Un logiciel mérite l'étiquette hérité quand il vous gêne activement. Quand vous ne pouvez plus le modifier sans risque parce que personne ne le comprend entièrement. Quand il ne peut pas se connecter aux outils dont vous dépendez aujourd'hui. Quand une seule personne est la seule à pouvoir le maintenir en vie. Quand il est si lent ou si fragile que votre équipe a bâti tout un folklore de contournements autour de lui. Voilà la vraie définition — pas l'année où il a été écrit, mais le coût qu'il vous impose aujourd'hui et le risque qu'il porte vers demain.

Diagnostiquer avant de toucher à quoi que ce soit

Avant qu'une seule ligne ne soit réécrite, il vous faut une carte honnête de l'endroit où la douleur se loge réellement. La plupart du temps, le système que tout le monde déteste va bien à 80 %. Les ennuis se concentrent à quelques endroits précis — un écran lent, une intégration cassée, un flux qui force la double saisie — et ces quelques endroits génèrent la quasi-totalité des plaintes. Trouvez-les, et vous avez trouvé tout votre projet.

La manière de les trouver n'est pas d'abord un audit technique — c'est une conversation. Asseyez-vous avec les gens qui utilisent l'outil chaque jour et demandez-leur où ça fait mal. Où attendent-ils ? Que retapent-ils ? Qu'évitent-ils parce que c'est pénible ? Où tiennent-ils un tableur privé pour contourner le système officiel ? Ces contournements sont de l'or : chacun est une radiographie précise d'un problème qui vaut la peine d'être corrigé.

• Les écrans et les étapes dont les gens se plaignent le plus — pas en théorie, dans leur travail quotidien réel.
• Chaque endroit où les données sont saisies deux fois parce que deux systèmes ne se parlent pas.
• Les intégrations qui ont cassé, ou qui n'ont jamais existé, et qui forcent le copier-coller manuel entre outils.
• Tout ce qu'une seule personne sait faire fonctionner ou réparer — vos points uniques de défaillance.
• Les parties qui vont réellement bien, afin de les protéger et de les laisser tranquilles.
• Ce dont l'entreprise aura besoin l'an prochain et vers quoi le système actuel ne peut tout simplement pas grandir.

Quand vous faites cela honnêtement, le projet rétrécit le plus souvent. Le dirigeant qui était entré en disant « remplacez tout » ressort en réalisant qu'il doit corriger trois choses. Ce n'est pas une déception — c'est un soulagement. Trois choses réparables, c'est un projet que vous pouvez terminer ce trimestre. Un remplacement complet, c'est une année à laquelle vous ne survivrez peut-être pas.

L'approche strangler : remplacez pièce par pièce

Il existe un patron pour faire cela en sécurité, et il porte un nom un peu sinistre mais mémorable : l'approche strangler, d'après le figuier étrangleur — une liane qui pousse autour d'un arbre et s'empare peu à peu de sa structure jusqu'à ce que, finalement, la nouvelle croissance tienne seule et que le vieux tronc ait disparu. Appliquée au logiciel, l'idée est merveilleusement pratique : vous ne remplacez pas l'ancien système d'un seul échange héroïque. Vous faites pousser le nouveau autour de lui, pièce par pièce, jusqu'à ce qu'il ne reste rien de l'ancien dont quiconque ait besoin.

En pratique, cela fonctionne ainsi. Vous choisissez une pièce douloureuse — disons le module de facturation que tout le monde déteste. Vous bâtissez un remplaçant moderne pour cette seule pièce. Vous redirigez la facturation vers le nouveau module tandis que tout le reste continue de tourner sur l'ancien système, intact. Vous l'observez un moment. Quand il est solide, cette partie de l'ancien système s'éteint, et vous passez à la pièce suivante. L'ancien système rétrécit petit à petit, comme une bougie, au lieu d'être abattu d'un coup.

Ce qui rend cela bien plus sûr qu'une réécriture, c'est que chaque étape est petite, en production et réversible. Vous n'avancez jamais à l'aveugle. Chaque nouvelle pièce entre vite en usage réel, si bien que vous découvrez rapidement si elle fonctionne vraiment. Si quelque chose tourne mal, vous n'avez risqué qu'un module, pas toute l'entreprise — et vous pouvez en général revenir à l'ancien chemin pendant que vous le réparez. Vous engrangez des victoires en cours de route au lieu d'un unique lancement terrifiant à la fin. Et l'activité continue de tourner, normalement, tout du long.

À quoi ressemble vraiment le rythme

1. 1
   Choisissez la pièce la plus douloureuse et la plus autonome

   Vous voulez une forte douleur et des bords nets — un module qui fait beaucoup mal et qui n'a pas les doigts dans tout le reste. C'est votre première cible.
2. 2
   Placez une fine couche devant l'ancien système

   Une petite couche de routage décide quelles requêtes vont à l'ancien système et lesquelles vont à la nouvelle pièce. C'est la couture qui rend tout le reste possible.
3. 3
   Construisez et lancez cette seule pièce

   Remplacez un module, mettez-le entre de vraies mains et ne dirigez vers lui que cette tranche de travail. Des semaines, pas des années — et le reste du système n'a jamais bougé.
4. 4
   Stabilisez, puis passez à la pièce suivante

   Une fois le nouveau module digne de confiance, la partie correspondante de l'ancien système se met en sommeil. Recommencez avec la pièce douloureuse suivante, en apprenant au fur et à mesure.
5. 5
   Retirez l'ancien système quand il est vide

   Avec le temps, le système hérité ne fait plus rien dont quiconque dépende. C'est seulement alors que vous l'éteignez — discrètement, sans drame, parce que tout l'important a déjà déménagé.

Remarquez ce qui distingue ceci de la réécriture : il n'y a pas un unique jour de lancement à redouter. Il n'y a pas d'univers parallèle à entretenir. Le nouveau système est en production dès la troisième semaine, il gagne sa croûte et vous apprend des choses, au lieu d'attendre en laboratoire un lancement qui ne cesse de glisser.

Parfois, vous n'avez même pas besoin de le remplacer

Avant de remplacer quoi que ce soit, il vaut la peine de se demander si l'ancien système a besoin d'être remplacé ou seulement de cesser d'être une île. Un nombre surprenant de problèmes « il nous faut un nouveau système » sont en réalité des problèmes « nos systèmes ne se parlent pas ». Le vieux logiciel fait bien son travail — il est juste dans un silo, forçant les gens à transporter les données à la main d'un côté et de l'autre.

Dans ces cas-là, la solution la moins chère et la plus rapide n'est pas un nouveau système. C'est un pont. Vous enveloppez le vieux logiciel d'une connexion — une intégration qui lui permet d'échanger automatiquement des données avec vos autres outils — et d'une couche moderne par-dessus pour les parties que les gens touchent vraiment. Le moteur daté continue de ronronner en dessous ; l'équipe obtient une surface propre et la fin du copier-coller. Ce n'est pas glamour, mais c'est souvent le meilleur retour par euro de tout l'effort.

Quand une réécriture complète est vraiment le bon choix

J'ai passé tout ce guide à vous dissuader de la grande réécriture, alors soyons justes : parfois, c'est vraiment la réponse. Il existe des fondations si pourries qu'aucun rustine, pont ou remplacement pièce par pièce ne les sauve, et prétendre le contraire ne fait que retarder l'inévitable pendant que vous dépensez de l'argent à étayer un cadavre.

Les signes honnêtes sont précis. La technologie sur laquelle le système est bâti est morte ou mourante — plus de support, plus de mises à jour de sécurité, plus personne capable d'y travailler. L'activité a tellement changé que l'ancien modèle ne correspond plus du tout à la réalité. Ou le système est si emmêlé que même de petits changements cassent régulièrement des choses sans rapport, ce qui signifie en général qu'il n'y a pas de coutures propres pour appliquer une approche strangler au départ. Quand deux ou trois de ces conditions sont vraies en même temps, le travail progressif cesse d'être le choix le plus sûr.

Et voici la récompense discrète de faire d'abord le travail progressif, même si vous finissez par reconstruire : le temps d'y arriver, vous comprendrez le système bien mieux qu'au départ. Chaque module que vous avez remplacé vous a appris quelque chose que les auteurs d'origine n'ont jamais consigné. Une réécriture éclairée par ce savoir est un animal tout à fait différent, bien plus sûr, que celle lancée sur l'optimisme du premier jour.

La part dont personne ne parle : c'est surtout une question de personnes

Voici une chose que les guides techniques sautent. Le plus difficile dans la modernisation d'un vieux logiciel, ce n'est en général pas le code — ce sont les gens qui ont passé des années à s'y adapter. Ils en connaissent les bizarreries. Ils ont une mémoire musculaire de ses raccourcis étranges. Un nouveau module objectivement meilleur peut tout de même paraître pire pendant les deux premières semaines, simplement parce qu'il est inconnu. Si vous ignorez cela, même une migration technique parfaite peut échouer.

L'approche progressive aide là aussi, presque par accident. Parce que le changement arrive par petites pièces, les gens l'absorbent peu à peu au lieu de devoir tout réapprendre un seul lundi matin. Associez tôt les utilisateurs quotidiens. Laissez-les façonner le remplaçant avant qu'il soit fini. L'équipe qui a aidé à concevoir le nouvel écran de facturation s'en fera la championne ; l'équipe à qui on l'a imposé le rejettera, même s'il est identique. La modernisation est un projet de conduite du changement déguisé en logiciel.

Questions fréquentes