Refondre ou stabiliser : comment décider sur un logiciel existant ?

"Notre outil interne nous fait perdre du temps, il faut le refaire" est une phrase qu'on entend souvent. La majorité du temps, ce n'est pas la bonne conclusion — pas parce que la frustration n'est pas légitime, mais parce que la cause des frictions n'est pas toujours celle qu'on croit, et que le coût réel d'une refonte est presque toujours sous-estimé.

Avant d'investir 50 000 € ou 100 000 € dans une refonte, voici les questions à se poser dans l'ordre, et les indicateurs qui devraient peser dans la décision.

Stabiliser ≠ ne rien faire

Première précision importante : "stabiliser" n'est pas synonyme de "ne rien faire et endurer". C'est une approche active qui consiste à intervenir chirurgicalement sur les vrais points de douleur, sans toucher au reste. Concrètement, cela peut inclure :

• Corriger les bugs récurrents qui pèsent le plus sur l'usage quotidien
• Améliorer les écrans les plus utilisés (sans toucher au reste du parcours)
• Ajouter une ou deux fonctionnalités manquantes critiques
• Mettre à jour les dépendances techniques pour réduire la dette de sécurité
• Améliorer les performances sur les opérations les plus lentes

L'objectif n'est pas de rendre le logiciel "parfait", mais de réduire significativement le coût d'usage pour quelques milliers d'euros, là où une refonte en coûterait 50 à 100 fois plus.

Indicateur 1 : la nature des problèmes

Avant tout, identifiez précisément ce qui frustre les utilisateurs. C'est rarement "tout", même si c'est ce qu'on dit. En pratique, il y a presque toujours trois à cinq points de douleur très précis qui concentrent 80 % de la frustration.

Si ces points de douleur sont localisés (un écran, un calcul, un workflow), la stabilisation gagne haut la main. On corrige ce qui fait mal et on garde le reste, qui fonctionne suffisamment.

Si les points de douleur sont structurels (le modèle de données ne correspond plus au métier, l'architecture empêche les évolutions, la stack technique n'est plus maintenable), la refonte peut devenir nécessaire — mais à condition que les autres indicateurs aillent dans le même sens.

Indicateur 2 : la qualité du code existant

C'est l'indicateur que les équipes techniques mettent souvent en avant, mais qu'il faut nuancer. "Le code est mauvais" n'est pas un argument suffisant pour une refonte. Beaucoup de logiciels critiques en production tournent sur du code qu'aucun ingénieur ne défendrait esthétiquement.

Les vrais critères qui justifient une refonte sont plus précis :

• L'absence totale de tests automatisés rend chaque modification risquée — mais c'est rattrapable
• Une dépendance critique abandonnée par son éditeur sans alternative compatible (par exemple un framework qui n'est plus mis à jour depuis 5 ans avec faille de sécurité non corrigée)
• Une stack technique tellement ancienne que plus aucun développeur ne veut y toucher (coût de recrutement multiplié par 2 ou 3)
• Un modèle de données qui force des contournements sur chaque nouvelle fonctionnalité

Si vous avez trois de ces quatre critères, la refonte devient légitime. Sinon, la stabilisation peut traiter le problème pour beaucoup moins cher.

Indicateur 3 : l'écart fonctionnel

Voici l'indicateur qui pèse le plus, et qu'on sous-estime presque toujours. Posez-vous la question : si on refaisait le logiciel aujourd'hui, à quel point la cible serait-elle différente de l'existant ?

Si la cible est essentiellement la même fonctionnellement (même processus métier, mêmes utilisateurs, mêmes données, juste "en mieux"), la refonte est un pari perdant. Vous allez payer pour refaire ce que vous avez déjà, avec le risque permanent de perdre des subtilités métier non documentées qui sont enfouies dans le code existant.

Si la cible est significativement différente — par exemple, vous voulez maintenant supporter la mobilité, ouvrir le système à des partenaires externes, gérer des cas métier impossibles dans l'architecture actuelle — alors la refonte se justifie, parce que vous payez pour quelque chose qui n'existe pas encore.

Une bonne règle empirique : si l'écart entre l'existant et la cible représente moins de 30 % de différence fonctionnelle, n'envisagez pas la refonte. Stabilisez et évoluez incrémentalement.

Indicateur 4 : la fenêtre de tolérance au risque

Une refonte, c'est un projet long (souvent 6 à 18 mois pour un outil métier sérieux), pendant lequel vos équipes continuent à utiliser l'ancien outil et où la productivité dédiée au nouveau est consommée par les développeurs. Vous payez deux fois : l'ancien continue de coûter en maintenance, le nouveau coûte en développement.

Ce qui rend la situation tenable, c'est la fenêtre de tolérance au risque : combien de temps pouvez-vous accepter que votre métier soit en transition, avec des arbitrages permanents sur où mettre l'effort ?

Cette fenêtre se mesure à plusieurs facteurs :

• L'état de votre trésorerie (un projet long absorbe du cash)
• La pression concurrentielle (si vos concurrents avancent vite, vous n'avez pas 12 mois devant vous)
• La capacité d'attention de vos équipes (un projet de refonte impose une charge cognitive importante)
• L'urgence des points de douleur actuels (si l'outil casse, c'est trop tard pour une refonte)

Si votre fenêtre de tolérance est inférieure à 6 mois, la refonte est probablement hors-jeu. Visez la stabilisation, quitte à refaire le sujet dans deux ans.

Grille de décision rapide

Pour résumer, voici les quatre indicateurs en tableau de décision :

• Problèmes localisés (1-3 points de douleur précis) → Stabiliser. Problèmes structurels (modèle de données, architecture) → Refondre.
• Code médiocre mais maintenable → Stabiliser. Dépendances critiques abandonnées ou stack ingérable → Refondre.
• Écart fonctionnel < 30 % (même métier, en mieux) → Stabiliser. Écart > 50 % (cible significativement différente) → Refondre.
• Fenêtre de tolérance courte ou floue → Stabiliser. Fenêtre > 12 mois, budget confirmé → Refondre.

Trois "Refondre" ou plus sur les quatre : la refonte est probablement justifiée. Sinon : stabilisez en priorité. Vous gagnerez en sérénité, en temps, et vous traiterez quand même 80 % du sujet.

Les trois pièges les plus fréquents

Piège 1 : confondre frustration et obsolescence

Un logiciel peut être très frustrant à utiliser sans être obsolète. La frustration vient souvent de quelques écrans précis ou d'un workflow mal pensé. C'est rattrapable pour un coût raisonnable. Le réflexe "tout casser et tout refaire" est émotionnel — il soulage, mais il ne résout généralement pas le vrai problème, qui finit par revenir dans la nouvelle version.

Piège 2 : sous-estimer la connaissance enfouie

Un logiciel métier en place depuis 5 ans contient des dizaines de petites règles métier qui ne sont pas documentées et que personne ne sait reproduire. Lors d'une refonte, vous allez en redécouvrir 60 % au fur et à mesure (dans la douleur), et il en restera toujours 5 à 10 % que vous identifierez seulement quand un utilisateur se plaindra trois mois après le déploiement. C'est un coût caché majeur.

Piège 3 : surestimer la cible

"On va en profiter pour tout faire bien." Pendant la phase de cadrage, la cible se gonfle de toutes les fonctionnalités qui auraient dû être dans l'existant. Le périmètre triple, le délai aussi, et le projet devient ingérable. Si vous partez en refonte, contraignez la cible au minimum vital et reportez tout le reste à des itérations ultérieures.

Comment trancher en pratique

Si vous hésitez entre les deux, voici le test simple que nous appliquons en premier échange : essayez de chiffrer une stabilisation avant de chiffrer une refonte. Identifiez les 3 à 5 vrais points de douleur, demandez un devis pour les traiter, et comparez au coût d'une refonte complète.

Dans 80 % des cas, la stabilisation représente 5 à 15 % du coût d'une refonte, pour traiter 70 à 80 % des frustrations réelles. C'est arithmétiquement le meilleur retour sur investissement, presque toujours.

La refonte se justifie quand cette équation s'inverse — c'est-à-dire quand les points de douleur sont tellement diffus ou structurels qu'on ne peut pas les traiter chirurgicalement, ou quand l'écart entre l'existant et la cible justifie de payer pour reconstruire.

Si vous avez un logiciel existant qui pèse au quotidien et que vous hésitez sur la trajectoire, un premier échange de 30 à 45 minutes suffit en général à trancher l'orientation : on identifie ensemble les vrais points de douleur, on évalue la nature des problèmes, et on positionne la décision sur la grille ci-dessus.