Système legacy : la méthode pour avancer sans en connaître l'histoire

Le jour où plus personne ne sait pourquoi cette règle existe

Dans un système hérité, il existe presque toujours une règle que personne, dans l'équipe actuelle, ne sait expliquer. Un champ « statut » à cinq valeurs dont deux ne servent plus depuis deux ans. Un calcul qui applique un coefficient de correction sans qu'aucune documentation n'en précise l'origine. Un blocage qui empêche une saisie dans un cas précis, sans que personne ne sache s'il protège contre une vraie erreur ou s'il reproduit une contrainte devenue obsolète.

Le réflexe naturel, face à ce genre de découverte, est de chercher à comprendre d'abord. Éplucher d'anciens échanges de mails, interroger des collaborateurs qui ont peut-être connu le système à ses débuts, chercher un cahier des charges qui, la plupart du temps, n'a jamais existé sous une forme exploitable. Cette quête part d'une bonne intention : ne rien casser en touchant à quelque chose qu'on ne comprend pas encore. Elle se heurte pourtant à un mur régulier, celui d'une histoire qui n'est simplement plus reconstituable.

Ce mur n'est pas propre au code sur mesure. Un paramétrage ERP configuré par un intégrateur qui n'existe plus, un tableur de règles tarifaires transmis d'un gestionnaire à l'autre sans jamais être réécrit, une macro Excel dont l'auteur a quitté l'entreprise, tous produisent le même symptôme : un comportement observable, une justification introuvable. La nature technique du système importe moins que l'absence de mémoire humaine qui l'entoure.

Pourquoi l'archéologie documentaire est le mauvais réflexe

Le temps passé à reconstituer un historique complet est presque toujours disproportionné par rapport à ce qu'il rapporte. La vraie question n'est pas « pourquoi cette règle a-t-elle été écrite ainsi », elle est « cette règle s'applique-t-elle encore, et à quoi sert-elle aujourd'hui ». Ce sont deux questions différentes. La première demande une source qui, par définition, n'est plus disponible. La seconde se répond en observant le système tel qu'il fonctionne réellement.

Le turnover, première cause de connaissance perdue

Cette perte d'historique n'est pas un accident rare. Dans une PME confrontée à un taux de renouvellement de personnel élevé sur les fonctions techniques, la personne qui maîtrisait un système part, remplacée par une autre qui reste un an avant de repartir à son tour. Personne, en interne, ne conserve la compréhension du système dans la durée, de son évolution, de ses choix passés. Cette connaissance ne disparaît pas d'un coup : elle s'effrite à chaque départ, jusqu'à ce que plus personne ne puisse répondre à la question la plus simple qu'on lui pose sur le système qu'elle utilise chaque jour.

« Ils ont des difficultés de conservation de leurs compétences RH. La personne avec qui on travaillait pendant un certain temps est partie, remplacée par une autre qui reste un an et qui est en train de repartir. Ils ont un problème de stabilité du personnel, ce qui fait que finalement, qui a la compréhension dans la durée du système, de son évolution et de son historique, ce n'est plus en interne, c'est nous qui l'avons. »

Ce constat déplace le problème. Si la connaissance du système ne peut plus être retrouvée en interrogeant des personnes, elle doit être reconstruite à partir de ce que le système lui-même peut montrer, et de ce que des sources extérieures à l'entreprise peuvent confirmer. Chercher à tout prix un interlocuteur qui n'existe plus revient à retarder indéfiniment une décision qui pourrait être prise dès maintenant, sur la base de ce qui est directement observable.

Le coût de cette attente est rarement chiffré, mais il est réel. Chaque mois passé à chercher une explication introuvable est un mois pendant lequel le système continue d'appliquer une règle qui n'a peut-être plus de raison d'être, sans que personne n'ose y toucher par précaution. L'immobilisme prudent finit par coûter plus cher que l'erreur qu'il cherchait à éviter.

Observer, pas reconstituer : la méthode en trois temps

Face à un système dont l'histoire est perdue, la méthode qui fonctionne avance par couches successives plutôt que par archéologie. Chez Leando, ce principe s'appelle observer, pas reconstituer : on documente d'abord ce qui est observable, on confronte ensuite ces observations à des sources de vérité qui ne dépendent pas de la mémoire humaine, et on ne challenge la règle qu'une fois ces deux premières étapes posées.

Ce que « observable » veut dire concrètement

La première couche ne cherche pas à savoir pourquoi une règle existe, elle documente ce qu'elle fait réellement. Quelles entrées produisent quelles sorties. Quelles valeurs sont effectivement utilisées dans la base de production, et lesquelles n'apparaissent plus jamais depuis des mois. Quels cas déclenchent un comportement différent du cas nominal. Ce travail se fait par le test et par la lecture des données réelles, jamais par supposition sur l'intention d'origine.

La deuxième couche interroge des sources de vérité externes à l'entreprise : textes réglementaires du secteur, documentation d'un fournisseur ou d'un partenaire, contrats en vigueur. Ces sources ont un avantage décisif sur la mémoire humaine : elles ne s'effacent pas quand quelqu'un quitte l'entreprise. Une règle de calcul qui correspond exactement à une contrainte réglementaire documentée n'a plus besoin d'être expliquée par une personne, elle est expliquée par le texte lui-même.

La troisième couche ne s'ouvre qu'une fois les deux premières posées : challenger ce qui peut être simplifié. Une règle observable qui ne correspond à aucune source de vérité externe identifiée, et dont la désactivation en environnement isolé ne casse rien d'observable, est un candidat sérieux à la suppression. Inverser l'ordre, en simplifiant avant d'avoir posé les deux premières couches, revient à parier sur une intuition plutôt que sur une observation.

Cet ordre a une raison précise : une règle simplifiée trop tôt, avant d'avoir été confrontée aux sources externes, peut supprimer une contrainte réglementaire que personne n'avait identifiée comme telle. Les deux premières couches ne sont pas des étapes de prudence excessive, elles réduisent le risque que la simplification en supprime plus qu'elle n'en résout.

Pour aller plus loin sur la manière de faire émerger les règles métier qu'une équipe applique sans les avoir jamais formalisées, notre méthode pour sortir les règles métier implicites détaille le travail de terrain qui s'applique quand la connaissance existe encore chez des collaborateurs en poste, plutôt que perdue avec ceux qui sont partis.

Ce que ce principe exclut

Observer, pas reconstituer, ne remplace jamais une source humaine encore disponible. Si la personne qui a conçu le système, ou un prestataire qui l'a maintenu, reste joignable, la questionner directement est toujours plus rapide et plus fiable que d'observer et déduire. Cette méthode est un pis-aller pour la situation où cette option n'existe plus, pas un premier réflexe à appliquer par principe. Confondre les deux revient à se priver, par excès de méthode, de la source la plus simple.

La méthode a aussi une limite de taille. Sur un système restreint, quelques dizaines de règles, l'observation directe suffit. Sur un système de grande ampleur, des centaines de règles enchevêtrées, elle devient trop lente pour être praticable seule, et un audit outillé, capable d'analyser automatiquement les chemins effectivement empruntés en production, devient nécessaire avant de pouvoir appliquer les trois couches à l'échelle.

Un moteur de tarification que personne ne pouvait plus expliquer

Un fournisseur d'énergie ETI, filiale d'un groupe suisse, faisait tourner un moteur de calcul de prix hérité d'un ancien prestataire. Plusieurs règles de tarification n'étaient documentées nulle part, et personne dans l'équipe actuelle ne pouvait justifier leur origine. Plutôt que de chercher à retrouver le raisonnement initial, l'équipe a documenté le comportement observable du moteur, quelles entrées produisaient quelles sorties, confronté ces observations aux textes qui encadrent une partie de la tarification de l'énergie, puis simplifié les règles qui ne correspondaient à aucune contrainte identifiée. Le moteur a pu évoluer sans que l'équipe attende, plusieurs mois durant, un historique qui n'allait jamais revenir. Pour un système technique qu'on hésite à faire évoluer faute de comprendre ses limites réelles, tester à bas coût avant de remplacer un composant propriétaire suit une logique complémentaire : observer par l'expérimentation plutôt que par la documentation absente.

Cette semaine, listez les règles de votre système que personne dans l'équipe actuelle ne sait expliquer. Vous serez probablement surpris du nombre, et c'est précisément la liste par laquelle commencer à observer, plutôt qu'à chercher un historique qui n'existe plus.