Quand un outil critique ne tient que grace a 2 personnes
Vous avez probablement le meme probleme dans votre entreprise — a une echelle differente. Un outil interne developpe au fil des annees, devenu indispensable, que plus personne ne sait vraiment maintenir. Un tableur Excel de 200 onglets, un script Access vieux de 15 ans, un outil maison dont le createur est parti il y a 5 ans.
Chez GE Healthcare, le probleme etait du meme ordre — mais les enjeux etaient considerablement plus eleves.
L’outil en question analyse les logs d’equipements d’imagerie medicale en milieu hospitalier. IRM, scanners, equipements de radiologie. Il detecte les anomalies de fonctionnement avant qu’elles ne deviennent des pannes. Dans ce contexte, une erreur d’analyse peut retarder un diagnostic medical. La fiabilite n’est pas un objectif technique — c’est une obligation ethique.
Et cet outil critique reposait sur les epaules de deux personnes. Deux ingenieurs qui approchaient de la retraite.
Le diagnostic : un risque existentiel deguise en probleme technique
10 000 lignes de regles empilees
L’outil existant, c’etait 10 000 lignes de regles textuelles empilees au fil des annees par des ingenieurs differents, dans des contextes differents, avec des conventions differentes. Chaque nouvelle regle etait ajoutee par-dessus les precedentes, sans refactoring, sans tests, sans documentation des interactions.
Martin Fowler, dans ses ecrits sur le refactoring, decrit ce phenomene comme le “code qui se fossilise” : chaque couche est le reflet d’une urgence passee, et l’ensemble forme un edifice que personne n’ose toucher.
Les 4 symptomes critiques
1. Opacite totale. Personne n’avait une vue d’ensemble du jeu de regles. Modifier une regle risquait d’en invalider trois autres. Les interactions entre regles etaient implicites, jamais documentees. Comme l’ecrit Michael Feathers dans Working Effectively with Legacy Code, le danger n’est pas le code que vous pouvez lire — c’est le code dont vous ne pouvez pas predire le comportement.
2. Tests systematiques impossibles. Chaque modification etait un pari. Pour valider une nouvelle regle, un ingenieur devait mentalement simuler son interaction avec les 9 999 autres regles. Aucun outil automatise ne pouvait le faire — le systeme n’avait pas ete concu pour etre testable.
3. Faux positifs endemiques. Les faux positifs faisaient perdre des heures aux equipes terrain. Les techniciens se deplacaient pour des pannes inexistantes, perdaient confiance dans l’outil, et finissaient par ignorer des alertes — y compris les vraies. C’est le scenario “cry wolf” : quand un systeme d’alerte crie trop souvent au loup, personne ne reagit le jour ou le loup est la.
4. Concentration des connaissances. 2 a 3 personnes dans toute l’organisation comprenaient le fonctionnement de l’outil. C’est ce que The Phoenix Project appelle un “Brent” — une personne sur laquelle tout repose, dont le depart mettrait l’organisation en peril. Sauf qu’ici, ces personnes approchaient de la retraite.
Le risque business etait limpide : un depart a la retraite et l’outil devenait une boite noire impossible a maintenir — dans un environnement hospitalier ou les consequences d’une defaillance ne sont pas financieres, mais humaines.
L’approche : changer de paradigme plutot que de reecrire
Pourquoi la reecriture classique ne fonctionnait pas
La premiere idee — la plus naturelle — etait de reecrire les 10 000 lignes une par une, en les “nettoyant.” Mais cette approche avait trois defauts majeurs :
- La connaissance etait dans les regles, pas dans le code. Les regles encodaient 15 ans d’expertise metier en imagerie medicale. Les reecrire sans cette expertise, c’etait les denaturer.
- Le risque de regression etait inacceptable. En milieu hospitalier, on ne peut pas deployer un systeme “presque equivalent.” Il doit etre identique en comportement — ou meilleur.
- Le delai serait trop long. Reecrire 10 000 lignes aurait pris des mois, pendant lesquels l’ancien systeme aurait continue de poser les memes problemes.
Le Strangler Fig Pattern applique a l’analyse de logs
Martin Fowler decrit le Strangler Fig Pattern comme une approche ou l’on construit progressivement un nouveau systeme autour de l’ancien, en redirigeant les flux un par un. L’ancien systeme ne meurt pas — il est progressivement remplace, branche par branche, comme un arbre enveloppe par un figuier etrangleur.
On a adapte ce pattern au contexte GE Healthcare avec une idee centrale : transformer du code en configuration.
Plutot que de reecrire des regles d’analyse en code, on a construit un moteur generique qui lit des fichiers de configuration structures. Les ingenieurs GE ne programment plus — ils decrivent “quoi chercher” dans un format standardise, et le moteur s’occupe de l’execution.
L’architecture en 3 couches
Couche 1 — Le moteur de regles. Une machine a etats configurable qui parcourt les logs equipement par equipement. Plutot que d’avoir des milliers de lignes de code procedurale, le moteur applique des regles declaratives : “si tu trouves ce motif dans les logs, declenche cette alerte avec ce niveau de severite.”
Couche 2 — Le mini-interpreteur arithmetique. Certaines regles necessitent des calculs : seuils, moyennes, ecarts. Plutot que de coder ces calculs en dur, on a cree un interpreteur qui evalue des expressions arithmetiques definies dans la configuration. Les ingenieurs ecrivent temperature > 38.5 AND uptime < 4h au lieu de modifier du code Ruby.
Couche 3 — Les fichiers de configuration. Un format structure (YAML) ou chaque regle est autonome, documentee, et testable individuellement. Plus besoin de toucher au code pour ajouter ou modifier une regle d’analyse.
Le detail technique complet (machine a etats, interpreteur arithmetique, architecture Ruby) est dans l’article du blog technique.
La migration : zero interruption, zero regression
Phase 1 — Execution en parallele
Le nouveau moteur a d’abord tourne en parallele avec l’ancien systeme. Chaque log etait analyse par les deux systemes simultanement, et les resultats etaient compares. Toute divergence declenchait une investigation.
C’est l’application directe du Strangler Fig Pattern : on ne coupe l’ancien systeme qu’une fois prouve que le nouveau donne des resultats identiques — ou meilleurs.
Phase 2 — Migration progressive des regles
Les 10 000 lignes de regles ont ete migrees par lots, du plus simple au plus complexe. Chaque lot migre etait valide par les ingenieurs GE, teste en conditions reelles, et deploye. La migration complete a pris plusieurs semaines — mais a aucun moment le systeme n’a ete indisponible ou degrade.
Phase 3 — Transfert de competence
Le nouveau systeme a ete concu pour etre autonome. Les ingenieurs GE creent et modifient les regles sans intervention de developpeur. La documentation d’utilisation a ete co-redigee avec les equipes terrain pour garantir qu’elle reponde a leurs questions reelles, pas aux questions qu’on imagine.
Les resultats mesurables
| Indicateur | Avant | Apres |
|---|---|---|
| Creer une nouvelle regle d’analyse | Plusieurs jours (+ dev) | Quelques heures (autonome) |
| Faux positifs | Frequents | Divises par 4 |
| Personnes capables de maintenir l’outil | 2-3 | Toute l’equipe (12+) |
| Chaque modification = risque de regression | Oui | Non (regles isolees) |
| Tests automatises sur les regles | Impossibles | Systematiques |
| Documentation des regles | Inexistante | Integree au format |
Le resultat le plus significatif n’est pas technique — il est organisationnel. La connaissance n’est plus concentree dans 2 tetes. Elle est externalisee dans des fichiers de configuration lisibles, versionnes et testables. Le risque du “bus factor” (que se passe-t-il si ces 2 personnes sont renversees par un bus ?) est elimine.
Les lecons pour votre entreprise
1. La bonne question n’est pas “comment reecrire ce code”
La bonne question est : “peut-on changer la facon de resoudre le probleme ?” Ici, transformer du code en dur en configuration a tout debloque. La solution n’etait pas de reecrire plus proprement — c’etait de repenser l’architecture.
C’est ce que Kent Beck appelle “faire que ce soit bien” : pas necessairement ecrire plus de code, mais trouver l’abstraction qui simplifie tout.
2. Les outils internes sont les plus dangereux
Contrairement a un produit commercial, un outil interne n’a pas de pression du marche pour rester maintenable. Il evolue par accumulation, sans refactoring, sans tests, sans documentation. Et un jour, il est devenu critique ET immaintenable. C’est le pire des deux mondes.
Si vous avez un outil interne dont une seule personne comprend le fonctionnement, c’est un risque — pas un atout.
3. Le transfert de competence est un livrable, pas un bonus
Un projet de reprise qui ne produit pas d’autonomie chez le client est un echec, meme si le code est parfait. L’objectif n’est jamais de creer une dependance — c’est de rendre votre equipe capable de maintenir le systeme seule.
4. L’execution en parallele elimine le risque de migration
Ne coupez jamais l’ancien systeme avant que le nouveau ait prouve son equivalence. C’est la regle d’or du Strangler Fig Pattern, et c’est la raison pour laquelle la migration GE Healthcare s’est faite sans aucune interruption de service.
Le cout de l’inaction : calculer le risque du “bus factor”
Le “bus factor” est un indicateur informel en ingenierie logicielle : combien de personnes peuvent etre renversees par un bus avant que le projet ne puisse plus avancer ? Pour GE Healthcare, ce chiffre etait 2. C’est un risque existentiel, pas un risque technique.
Comment evaluer le cout du risque pour votre outil interne :
| Element | Question a se poser |
|---|---|
| Impact d’une indisponibilite de 1 jour | Combien de personnes sont bloquees ? |
| Impact d’une indisponibilite de 1 semaine | Quel chiffre d’affaires est impacte ? |
| Cout de remplacement si la personne cle part | Combien pour former ou recruter quelqu’un ? |
| Cout d’une erreur non detectee | Quelles consequences metier/juridiques ? |
Pour GE Healthcare, une erreur d’analyse non detectee pouvait retarder un diagnostic medical. Le cout n’etait pas financier — il etait humain. Pour votre outil interne, le cout est peut-etre “seulement” financier. Mais il est reel.
Les auteurs de The Pragmatic Programmer ecrivent que tout systeme logiciel devrait etre traite comme un actif de l’entreprise — avec une maintenance, un cout d’amortissement, et un plan de succession. Un outil interne sans plan de succession est un passif deguise en actif.
Votre outil interne est-il un risque ?
Checklist rapide :
- L’outil est utilise quotidiennement par l’equipe
- Moins de 3 personnes comprennent son fonctionnement
- Il n’y a pas de tests automatises
- Il n’y a pas de documentation a jour
- Les modifications sont faites “a la main” par quelqu’un de specifique
- La derniere personne qui le connait approche de la retraite (ou du depart)
Si vous cochez 3 criteres ou plus, vous etes dans la meme situation que GE Healthcare — avec moins de temps devant vous que vous ne le pensez.
Vous avez un outil interne critique que 2 personnes savent maintenir ? Parlons-en avant qu’elles partent.