Refondre ou maintenir un logiciel vieillissant

Un logiciel métier vieillit de deux façons. La première se voit : l'interface date, les écrans sont lents sur téléphone, les nouveaux arrivants mettent des semaines à s'y faire. La seconde ne se voit pas : personne n'ose plus toucher au code, chaque correction en casse une autre, et le prestataire d'origine ne répond plus.

Devant ce constat, la demande est presque toujours la même : « on refait tout ». C'est parfois la bonne réponse. C'est aussi la plus coûteuse, et rarement la plus rapide. Voici comment nous départageons.

Première question : le logiciel fait-il encore le bon travail ?

Un logiciel peut être vieux et juste. S'il modélise encore votre activité telle qu'elle est, si les règles qu'il applique sont les bonnes, si les données qu'il tient sont celles dont vous avez besoin, alors le problème est technique, pas fonctionnel. Une refonte complète referait le même outil avec un autre habillage.

À l'inverse, si vos équipes ont installé des tableurs à côté pour tenir ce que le logiciel ne sait pas tenir, si des étapes de votre processus se font par mail parce que l'outil ne les connaît pas, alors le modèle a décroché de l'activité. Là, maintenir revient à entretenir un écart qui grandit.

Le test est concret : listez ce que vos équipes font en dehors du logiciel pour compenser le logiciel. Si la liste tient sur une ligne, on maintient. Si elle décrit un second outil, on reconstruit ce périmètre.

Deuxième question : peut-on encore y toucher sans risque ?

Un logiciel se maintient tant que trois choses existent : son code source, quelqu'un qui le comprend, et un moyen de vérifier qu'une modification n'a rien cassé.

Quand nous reprenons un logiciel existant, nous commençons par ces trois points. Le code est-il accessible et complet ? Ses dépendances sont-elles encore supportées par leurs éditeurs ? Existe-t-il des tests, ou peut-on en écrire sur les fonctions critiques en quelques jours ? Quand les réponses sont oui, la maintenance est saine : on corrige, on met à jour, on ajoute par petites étapes, et le logiciel repart pour des années.

Quand une réponse est non, chaque intervention devient un pari. Le coût de la maintenance n'est plus le temps passé, c'est le risque pris. C'est à ce moment que la refonte devient rentable, même si le logiciel fonctionne encore.

Troisième question : que faut-il refaire, exactement ?

Une refonte n'est pas un bloc. Un logiciel de gestion se découpe en parties qui vieillissent à des vitesses différentes : la base de données lentement, l'interface plus vite, les intégrations avec les outils extérieurs plus vite encore.

Nous préférons refondre par périmètre. On isole la partie qui bloque, on la reconstruit à côté de l'existant, on la branche sur les mêmes données, et on bascule les utilisateurs quand elle tient. L'ancien logiciel continue de tourner pendant ce temps. Personne ne vit six mois sans outil, et le budget se dépense sur ce qui rapporte en premier.

La reconstruction complète reste la réponse dans deux cas : quand la technologie d'origine n'a plus personne pour la maintenir, et quand le modèle de données lui-même est faux. Dans les deux cas, on le dit avant le devis, et on le chiffre sur un périmètre précis. Notre devis public d'une refonte, poste par poste et jour par jour, est dans le guide des prix.

Ce qu'on fait avant de répondre

Avant de proposer l'une ou l'autre voie, nous passons du temps dans le logiciel avec les personnes qui s'en servent. Il raconte le fonctionnement réel de l'entreprise, et il porte des règles que personne n'a écrites ailleurs. Une refonte qui les perd coûte plus cher que la refonte elle-même.

Cette lecture prend quelques jours. Elle se termine par une recommandation écrite : maintenir, refondre un périmètre, ou reconstruire, avec le coût et le délai de chaque option. La suite est décrite sur la page développement sur mesure et logiciel de gestion, et notre méthode dit comment un projet se déroule ensuite, de la compréhension à la production.