Un logiciel métier ne prévient pas avant de devenir une dépendance. Il ne tombe pas un matin : il vieillit, silencieusement, jusqu’au jour où plus personne ne sait comment le faire évoluer. Le bon moment pour vérifier son état, c’est maintenant, quand tout va bien.

Voici six signes à vérifier vous-même. Aucun n’est une catastrophe isolément, c’est leur nombre qui compte.

Les 6 signes

  1. Plus personne ne sait le modifier. Si un changement important fait appel à un prestataire extérieur, à un ancien développeur, ou que vous vous dites « on ne touche pas à ça », la connaissance a déjà quitté l’entreprise.
  2. Un seul outil est indispensable. Toute l’activité passe par ce logiciel, et vous n’avez aucune solution de repli si demain il s’arrête.
  3. On a peur de le faire évoluer. C’est le signe le plus révélateur : quand une équipe évite de toucher à son propre outil de peur de le casser, ce n’est plus un outil mais une dépendance.
  4. L’auteur d’origine est introuvable. Développeur parti, éditeur disparu, prestataire silencieux : si personne ne peut répondre à une question sur le fonctionnement interne, le risque est réel.
  5. La documentation n’existe pas ou plus. Pas de note, pas de schéma, pas de « comment on fait si… ». Tout le savoir est oral, donc fragile.
  6. Le logiciel ne suit plus l’activité. Il faut contourner une fonctionnalité, tenir un tableur « à côté », faire des choses manuellement parce que l’outil ne sait pas les faire.

Comment lire le résultat

Additionnez les signes qui vous concernent :

  • 1 à 2 — inquiétant. Le bon réflexe est de documenter tant que la connaissance est encore là.
  • 3 à 4 — fragile. La maîtrise commence à s’effriter. C’est le meilleur moment pour remettre la connaissance à plat, avant que ça ne devienne critique.
  • 5 à 6 — critique. Le risque existe aujourd’hui. Un départ, une panne ou une mise à jour peut révéler le problème sans préavis.

Ce que « s’en occuper » ne veut pas dire

S’occuper d’un logiciel métier ne veut pas dire le réécrire. C’est même l’inverse : la réécriture déplace la dépendance sans la réduire, pour un coût rarement justifiable car le logiciel rend encore service.

Ce qu’on propose, c’est remettre la connaissance à plat : une cartographie du système, un score de santé qui montre où est le risque réel et des recommandations priorisées. Ensuite, on met en place, on stabilise, puis on définit un contrat de continuité qui maintient la documentation à jour. On ne fait pas de réécriture systématique.

C’est notre service de maintenance logicielle : réduire la dépendance, pas la déplacer.

Si la personne qui connaît votre logiciel partait demain, que se passerait-il ?