Notre logiciel métier ralentit l'entreprise : comment savoir s'il faut le refaire ?

Quand Excel devient le secours officiel du logiciel métier, le problème n'est plus seulement informatique. Les équipes ressaisissent les mêmes informations, attendent une réponse, contournent une règle ou demandent à une personne précise de débloquer la situation. Le temps perdu reste souvent invisible, mais il finit par toucher la qualité, les délais et la capacité à faire évoluer l'activité.

La question n'est pourtant pas « faut-il refaire le logiciel ? ». Elle est plus exigeante : quelle cause produit ces symptômes, quel risque crée-t-elle et quelle réponse le résout avec le moins d'incertitude ? Le logiciel, le processus, les données, l'hébergement ou la maintenance peuvent chacun être responsables. Voici une méthode pour comparer avant de choisir.

Avant de commencer : quelles preuves réunir ?

Un diagnostic solide part du travail réel, pas de l'impression de quelques personnes. L'objectif : une grille qui relie chaque irritant à une fréquence, un effet, une personne touchée et une preuve.

Réunissez la liste des utilisateurs, les processus critiques, les incidents, les demandes d'évolution et les fichiers satellites. Ajoutez les contrats de maintenance, les versions utilisées et les intégrations. Le cadrage et l'audit servent à mettre ces éléments dans le même périmètre.

Ne laissez pas le diagnostic à la personne qui connaît le mieux l'ancien outil. Faites parler ceux qui exécutent les tâches, ceux qui les pilotent et ceux qui maintiennent le système. Une règle métier peut être connue d'un service sans apparaître dans la documentation.

Pour chaque signal, notez ce qui est observé, ce qui est estimé et ce qui reste à vérifier. Cette séparation évite de transformer une impression en chiffre officiel. Elle donne aussi un point de départ pour mesurer l'amélioration.

1. Quels signaux montrent que le logiciel freine vraiment l'activité ?

Les contournements sont-ils devenus le vrai parcours de travail ?

Un fichier Excel qui complète l'application n'est pas automatiquement un problème. Il le devient quand il porte une étape indispensable, quand plusieurs versions circulent ou quand une ressaisie réintroduit des erreurs. Le parcours officiel ne correspond alors plus au parcours réel.

Ajoutez les signaux visibles : lenteurs sur une action précise, bugs récurrents, données incohérentes, évolutions de plus en plus longues et chères, connexion impossible avec vos autres outils, obligation réglementaire difficile à tenir ou maintenance laborieuse. La dépendance à une personne ou à un prestataire est également un signal. Elle ne prouve pas qu'il faut changer d'outil, mais elle révèle un risque de continuité.

Vérifiez aussi la version technique et ses dates de support. Pour les briques Microsoft, le catalogue officiel Microsoft Product and Services Lifecycle Information donne, produit par produit et version par version, les calendriers de support et les informations de migration : la date dépend de la version exacte, pas du nom du produit. Une fin de support constitue un risque à planifier, pas un verdict automatique de réécriture.

Quel signal est critique, et lequel est seulement pénible ?

Classez chaque problème selon son effet sur le chiffre d'affaires, la continuité, la qualité, la sécurité, la conformité et le service client. Une lenteur sur un écran peu utilisé ne pèse pas comme une indisponibilité pendant une opération critique. Une demande repoussée n'a pas la même portée qu'une règle non appliquée.

Signal	Impact sur l'activité	Preuve à réunir
Indisponibilité pendant une opération critique	Fort : continuité, chiffre d'affaires, service client	Incidents, durée, personnes touchées
Fichier Excel qui porte une étape indispensable	Fort : qualité, risque d'erreur à la ressaisie	Fichiers satellites, versions en circulation
Règle non appliquée, obligation difficile à tenir	Fort : conformité, sécurité	Règle concernée, cas réels
Évolutions de plus en plus longues et chères	Moyen : capacité à faire évoluer l'activité	Demandes d'évolution, délais constatés
Lenteur sur un écran peu utilisé	Faible : gêne ponctuelle	Fréquence d'usage, personnes touchées

2. Le logiciel est-il vraiment coupable ? (c'est souvent plus compliqué)

Le problème vient-il de l'outil, du processus ou de la donnée ?

Comparez le parcours prévu avec celui que les équipes suivent réellement. Si elles contournent une étape, demandez pourquoi. La fonction est-elle absente, trop lente, trop complexe ou mal comprise ? Un besoin de formation ne se résout pas par une réécriture.

Examinez ensuite la donnée. Les doublons, les champs incomplets et les synchronisations manuelles peuvent donner l'impression que l'application est fautive. Or une nouvelle interface ne rend pas une information fiable. Elle peut même déplacer le problème dans une autre base.

Dans quel état est le code lui-même ?

C'est souvent le critère qui fait basculer entre modernisation et réécriture, et pourtant on l'examine rarement. Un code ancien n'est pas un mauvais code : ce qui compte, c'est la capacité à le faire évoluer sans casser le reste. Cinq points se vérifient avec un développeur extérieur à l'équipe d'origine :

• La dette technique : des correctifs empilés, du code dupliqué, des dépendances abandonnées. Se concentre-t-elle dans quelques modules ou touche-t-elle tout le logiciel ?
• Les tests : sans tests automatisés, chaque modification est un pari. Leur absence n'interdit pas de moderniser, mais il faudra en écrire d'abord.
• L'architecture : les modules sont-ils séparés ou tout dépend-il de tout ? Un logiciel découpable se modernise par morceaux, un bloc monolithique beaucoup moins.
• La documentation : les règles métier sont-elles écrites quelque part, ou seulement dans le code et dans la tête de quelques personnes ?
• La reprise : un développeur compétent peut-il comprendre et modifier le code en quelques semaines, sans l'auteur d'origine ? Si la réponse est non, la dépendance à une personne est le vrai risque.

À notre avis, un code médiocre mais découpable et testable se corrige presque toujours moins cher qu'il ne se réécrit. La réécriture ne se justifie que lorsque le code est devenu inexploitable, pas simplement désagréable.

L'hébergement et la maintenance ont-ils été écartés trop vite ?

Relevez les temps d'attente, les incidents, les sauvegardes, la supervision, la capacité disponible et les responsabilités. Une application correcte peut souffrir d'un hébergement mal dimensionné. À l'inverse, un serveur plus puissant ne corrige pas une règle métier incohérente.

La sécurité et la protection des données doivent être examinées séparément de la performance. La CNIL rappelle qu'une donnée personnelle est toute information se rapportant à une personne physique identifiée ou identifiable, directement ou indirectement (par un numéro client ou par recoupement de plusieurs données), et que le RGPD s'applique à tout organisme, public ou privé, qui en traite. Dès qu'il gère des clients, des salariés ou des contacts, un logiciel métier en contient. Une amélioration de vitesse ne dispense donc pas de vérifier les accès, les sauvegardes, les incidents et la capacité à expliquer les traitements.

Pour ces vérifications, le Guide d'hygiène informatique de l'ANSSI (Agence nationale de la sécurité des systèmes d'information) reste une bonne base en français : 42 mesures présentées comme un socle minimum, publiées en janvier 2017.

3. Combien le problème vous coûte-t-il vraiment ?

Que mesurer sans fabriquer un faux ROI ?

Choisissez une période d'observation définie. Comptez les incidents, les ressaisies, les attentes, les interventions manuelles et les demandes non livrées. Relevez le temps consacré et les personnes touchées. Toute durée estimée doit être identifiée comme telle.

Sur un processus critique, notez l'action, sa fréquence, les personnes concernées, le temps consommé, la conséquence et la preuve disponible. Vous avez surtout besoin de mesures comparables.

Quels risques mettre dans la même grille ?

Ajoutez les coûts récurrents, les indisponibilités, les erreurs, la dépendance, la sécurité, la conformité et les opportunités commerciales retardées. Pour structurer la discussion, le Cybersecurity Framework 2.0 du NIST américain, un cadre volontaire en six fonctions (gouverner, identifier, protéger, détecter, répondre, rétablir), peut servir de repère, sans fournir de seuil de refonte.

Projetez ensuite le coût de ne rien faire sur l'horizon utile à votre entreprise, par exemple 12 à 24 mois si cette période correspond à votre planification. Ce ne sont pas des statistiques générales. Ce sont des scénarios internes à comparer avec la correction, la modernisation, le progiciel et la réécriture.

Le résultat tient dans un seul tableau : une ligne par problème, avec sa fréquence, le temps perdu, les personnes touchées, le risque, la preuve disponible et une colonne « fait, estimation ou hypothèse ». Si une ligne n'a aucune preuve, elle ne pèse pas dans la décision tant qu'elle n'a pas été vérifiée.

4. Quelle option règle le problème sans recréer un problème plus grand ?

Corriger et stabiliser : quand est-ce suffisant ?

Cette voie convient si le périmètre reste pertinent et si les causes sont localisées. Il peut s'agir de corriger des incidents, de traiter une régression, de nettoyer des données, d'améliorer un parcours ou de clarifier la maintenance. Elle a souvent le mérite de réduire l'urgence et de produire des mesures avant une décision plus lourde.

La maintenance applicative devient alors un sujet de pilotage : incidents, versions, sauvegardes, supervision, délais de correction et documentation doivent avoir un responsable identifié. Si les preuves montrent que l'outil répond encore au besoin, le refaire reviendrait à payer cher pour résoudre un problème que personne n'a su nommer.

Moderniser progressivement : peut-on avancer par morceaux ?

Cette approche porte un nom dans la littérature : le Strangler Fig décrit par Martin Fowler. Plutôt que de tout remplacer d'un coup, on construit les nouveaux comportements à côté de l'ancien système et on y transfère peu à peu l'usage, jusqu'à pouvoir retirer l'ancien. La modernisation peut passer par une montée de version, une interface avec un autre outil, le remplacement d'un module ou la refonte d'un parcours critique. Cette approche réduit le périmètre initial, mais elle exige une architecture de transition et des tests réalistes.

Définissez une porte de retour, une mesure de succès et un critère d'arrêt avant de commencer. Une refonte par morceaux doit préserver les données et le fonctionnement quotidien pendant que les composants évoluent.

Remplacer ou réécrire : qu'est-ce qui justifie le saut ?

Un progiciel peut convenir lorsque le besoin est standardisable et que les écarts fonctionnels restent acceptables. Examinez la dépendance au fournisseur, l'accès aux données, la sécurité, les conditions de sortie et la capacité d'évolution.

Le sur-mesure devient pertinent quand une règle métier critique ne peut pas être couverte raisonnablement par une solution existante. Dans les deux cas, décrivez le périmètre avant le choix. Comparez le délai, la continuité, les données à reprendre et les risques d'adoption.

	Corriger et stabiliser	Moderniser par étapes	Remplacer par un progiciel	Réécrire sur mesure
Quand ?	Périmètre pertinent, causes localisées	Évolution possible par morceaux	Besoin standardisable, écarts acceptables	Règle métier critique non couverte par l'existant
Premier pas	Traiter les incidents, nettoyer les données	Tester un module ou un parcours critique	Comparer les écarts fonctionnels	Cadrer le périmètre
État du code attendu	Lisible, repris par un développeur sans l'auteur d'origine	Modules découpables, tests ajoutables	Sans objet, mais règles métier à documenter avant la sortie	Inexploitable, après avoir écarté la modernisation
Garde-fou	Un responsable identifié pour la maintenance	Porte de retour et critère d'arrêt	Conditions de sortie, accès aux données	Tests avec les métiers, reprise des données

5. Pourquoi les grands projets de refonte dérapent-ils si facilement ?

Le big bang a-t-il caché les règles métier ?

Une réécriture complète peut sembler plus simple sur un schéma. Elle devient risquée si les exceptions, les validations et les habitudes utiles ne sont pas documentées. Interrogez les équipes sur les cas réels. Une règle absente du cahier des charges réapparaîtra souvent au pire moment. C'est l'argument de Joel Spolsky dans Things You Should Never Do (2000) : un code qui paraît confus contient souvent des années de corrections, et tout réécrire revient à les perdre. Le texte est ancien et volontairement tranché, mais le risque qu'il décrit reste actuel.

La migration des données est-elle un projet à part entière ?

Préparez la qualité, l'historique, les correspondances, les doublons, les tests, la reprise et le plan de retour. Une donnée déplacée n'est pas automatiquement fiable. Faites valider les résultats par les métiers, avec des cas représentatifs.

Les utilisateurs ont-ils été oubliés entre deux comités ?

Impliquez les personnes qui travaillent dans l'outil. Testez des cas réels, organisez la formation et prévoyez un fonctionnement dégradé acceptable. La continuité inclut les décisions, les données et les gestes quotidiens.

Si l'un de ces trois points reste flou, la migration n'est pas prête. Mieux vaut décaler l'engagement que découvrir le trou en production.

6. Comment décider sans arrêter l'entreprise ?

Quel scénario obtient le meilleur rapport preuve / risque ?

Mettez en regard le coût de ne rien faire, le coût de chaque option, les dépendances, les bénéfices attendus, les risques et la capacité de l'organisation. Une option moins ambitieuse peut suffire si elle traite la cause principale. Une option plus large se justifie si une fin de support ou l'état des données rendent toute évolution locale fragile.

Quelle première étape peut être décidée maintenant ?

Choisissez une action réversible : stabiliser un incident, auditer un flux critique, expérimenter un module ou cadrer une migration. Fixez la preuve attendue, le responsable, la durée d'observation et la décision qui suivra.

La feuille de route peut tenir en trois horizons : sécuriser ce qui menace l'activité, éprouver une évolution sur un périmètre limité, puis décider de poursuivre, d'élargir ou de s'arrêter. Ce rythme protège l'exploitation et rend le choix plus lisible pour la direction. À notre avis, pour la plupart des PME, le bon réflexe est de commencer par stabiliser : c'est la voie la moins coûteuse pour obtenir des mesures fiables avant de s'engager plus loin.

La checklist avant de trancher

• Les symptômes, les causes et les preuves sont séparés.
• Les utilisateurs et les propriétaires des processus ont été entendus.
• Les versions, les dépendances, les données, la sécurité et la continuité sont documentées.
• L'état du code (dette, tests, architecture, documentation, capacité de reprise) a été examiné par quelqu'un d'extérieur à l'équipe d'origine.
• Le coût de ne rien faire est comparé aux quatre options.
• Une première étape mesurable, réversible et compatible avec l'activité est définie.

Ce qui fait varier le coût et le délai (la taille du logiciel ne suffit pas)

Qu'est-ce qui pèse vraiment dans l'estimation ?

Le nombre d'écrans ne suffit pas à estimer un projet. Regardez les parcours critiques, la qualité et le volume des données, les intégrations, les règles métier cachées, les exigences de sécurité, la disponibilité des experts et la stratégie de transition. Une petite application très connectée peut être plus délicate à faire évoluer qu'un outil plus vaste mais isolé.

La disponibilité des personnes compte aussi. Si les experts métier ne peuvent pas valider les règles, le calendrier devient théorique. Distinguez construction, migration, formation et conduite du changement.

FAQ : faut-il refaire son logiciel métier ?

Un logiciel lent doit-il forcément être remplacé ?

Non. Vérifiez d'abord l'hébergement, les données, les usages, la supervision et les traitements qui ralentissent le parcours. La cause peut être localisée.

Un logiciel ancien est-il forcément dangereux ?

Non. Vérifiez les dates de support, les correctifs, les accès, les sauvegardes, l'exposition et la capacité de maintenance. L'ancienneté est un signal, pas une conclusion.

Quand choisir un progiciel ?

Quand le besoin est suffisamment standard et que la dépendance au fournisseur, les données, les interfaces et les écarts fonctionnels restent acceptables.

Quand préférer le sur-mesure ?

Quand un différenciateur métier critique ne peut pas être couvert raisonnablement par une solution existante, et que l'entreprise peut maintenir la solution dans la durée.

Comment commencer ?

Par un diagnostic court, avec un périmètre précis, des preuves, des utilisateurs entendus et des critères de décision. Vous pouvez aussi relire les risques d'une application en PHP 7 ou Symfony 4 pour approfondir le sujet des versions, puis le remplacement d'Excel par une application web si les fichiers satellites sont devenus structurants.

Refaire n'est pas une décision technique : c'est une décision de risque. Le bon outil est celui qui laisse l'activité avancer avec des risques connus, qu'il soit corrigé, modernisé, remplacé ou réécrit.