Il y a un moment que la plupart des équipes IT ont connu un jour ou l’autre, et qui fait toujours le même bruit : celui du silence. Un incident majeur est en cours. La production est à genoux, la war room est ouverte, les dashboards clignotent, le management demande un ETA toutes les dix minutes. Et quelqu’un finit par poser la seule question qui compte : « Qui connaît ce système ? »
Et là, rien. Un grand blanc.
Pas un blanc d’hésitation, pas un blanc de réflexion. Un blanc d’absence. Celui qui savait est parti il y a huit mois, lors du plan de restructuration. Celle qui avait repris une partie du sujet a démissionné au printemps, usée. Le N3 qu’on escalade connaît le périmètre voisin, pas celui-là. Le PO connaît le produit tel qu’il est décrit dans le backlog, pas le système tel qu’il existe. La documentation, elle, décrit un monde qui n’a jamais tout à fait existé.
Ce moment-là, les organisations IT devraient le regarder en face, parce qu’il révèle ce que beaucoup d’entre elles refusent de comprendre : la connaissance qui les fait tenir debout n’habite pas où elles croient.
Le système réel n’est écrit nulle part
Il y a le système qu’on a conçu, celui des schémas d’architecture et des spécifications. Et il y a le système réel : celui qui s’est sédimenté au fil des années, correction après correction, incident après incident, workaround après workaround. Celui où un batch ne doit jamais tourner avant tel autre, pour une raison que plus personne ne sait justifier mais que tout le monde a appris à respecter. Celui où une alerte précise, sur un composant précis, annonce un problème ailleurs, trois couches plus loin. Celui où ce comportement étrange, qu’aucun monitoring ne qualifie, est en réalité le signe avant-coureur que quelqu’un, quelque part, a appris à reconnaître.
Cette connaissance-là ne se lit pas dans le code. Le code dit ce que le système fait ; il ne dit pas pourquoi il le fait ainsi, ni ce qui se passe quand il cesse de le faire, ni dans quel ordre le remettre sur pied. Elle ne se trouve pas davantage dans la documentation, et ce n’est pas seulement une question de discipline ou de wiki mal tenu. Le philosophe Michael Polanyi l’a formulé il y a soixante ans : we know more than we can tell. Nous savons plus que ce que nous pouvons dire. Une partie du savoir d’un être humain est tacite par nature : elle s’acquiert par l’expérience, se mobilise par l’intuition, et résiste à toute tentative de mise par écrit exhaustive. L’opérateur qui « sent » qu’un incident ressemble à celui de l’an dernier ne suit pas une procédure ; il reconnaît une forme. On ne documente pas une reconnaissance de forme.
Voilà pourquoi cette connaissance n’est dans les mains d’aucun N1, d’aucun N2, d’aucun N3 pris isolément, ni dans la tête de ceux qui sont censés « connaître le système ». Elle est distribuée, incarnée, tissée dans les personnes qui ont vécu avec lui. Elle s’est construite en années. Elle disparaît en un préavis.
La connaissance part sur deux jambes
Les développeurs ont une mesure pour cela, mi-blague mi-avertissement : le bus factor. Combien de personnes faudrait-il perdre, du jour au lendemain, pour que le projet soit en péril ? Quand la réponse est « une », tout le monde rit jaune, on promet de faire du partage de connaissance, et on retourne livrer la prochaine feature.
Mais le bus factor est presque optimiste, parce qu’il imagine un accident. Dans la vraie vie, ce n’est pas un bus qui emporte les sachants. C’est un plan social. C’est une vague de départs après un changement de management. Ce sont des conditions de travail qui se durcissent jusqu’à ce que les plus expérimentés, ceux qui ont précisément le plus d’options ailleurs, finissent par les prendre. L’organisation, elle, regarde partir des « ressources » et compte des coûts évités. Elle ne voit pas ce qui sort par la porte en même temps : la carte mentale du système réel.
Et le pire, c’est que cette perte est silencieuse. Le lendemain du départ, rien ne casse. La production tourne, les dashboards sont verts, le management se félicite. La connaissance perdue ne manque pas tant qu’on n’en a pas besoin. Elle manque le jour de l’incident. Elle manque le jour où il faut faire évoluer un module que plus personne n’ose toucher. Elle manque par à-coups, des mois plus tard, sans qu’on relie jamais vraiment la cause à l’effet.
Itérer sur un système que personne ne comprend plus
Car il ne s’agit pas seulement de réparer. Il faut continuer à construire. Le business ne s’arrête pas, la roadmap non plus. Et l’on arrive à cette situation que j’ai vue de près : une équipe qui doit faire évoluer un système dont plus aucun de ses membres ne comprend le fonctionnement d’ensemble.
Ce qui se passe alors est prévisible. Chaque modification devient un pari. On code au plus près du happy path, on évite les zones sombres, on contourne plutôt que de refactorer, parce que refactorer suppose de comprendre. Les revues de code valident la forme faute de pouvoir juger le fond. Les régressions se multiplient, et chaque régression, ironie comprise, aurait été du savoir en plus pour ceux qui ne sont plus là. L’équipe ralentit, non par incompétence, mais parce qu’elle avance dans le brouillard, et que dans le brouillard, les gens prudents ralentissent. Les autres provoquent des accidents.
J’insiste sur ce point : les personnes qui restent ne sont pas le problème. Elles font souvent des merveilles avec ce qu’on leur a laissé. Le problème est structurel. On leur demande de porter un système dont la mémoire a été licenciée.
La spirale
Et c’est ici que le tableau devient cruel. Parce que les organisations qui perdent le plus de connaissance sont précisément celles qui peuvent le moins se le permettre.
Une organisation en difficulté coupe dans les effectifs ou laisse les conditions se dégrader. Elle perd ses sachants. Privée de leur connaissance tacite, elle voit ses incidents durer plus longtemps, revenir plus souvent, toucher des clients qui finissent par partir. Les revenus baissent. Et que fait une organisation dont les revenus baissent ? Elle coupe encore. La recherche sur les restructurations, notamment les travaux de Sandra Sucher à Harvard, le confirme : la perte de savoir institutionnel, le désengagement et le turnover induit figurent parmi les coûts cachés des licenciements, et il faut parfois des années pour s’en remettre. Mais ces coûts n’apparaissent sur aucune ligne du plan d’économies. La masse salariale, si.
C’est une boucle de rétroaction parfaitement logique et parfaitement destructrice. Chaque tour de vis détruit un peu de la stabilité qui restait, et l’instabilité nouvelle justifie le tour de vis suivant. De l’extérieur, on dira que l’entreprise a décliné parce que son produit vieillissait ou que son marché se retournait. De l’intérieur, on aura vu autre chose : une organisation qui a amputé sa propre mémoire, puis s’est étonnée de ne plus savoir marcher.
Ce que l’ITSM vient faire là-dedans
On pourrait conclure par l’injonction habituelle : documentez. Elle n’est pas fausse, elle est insuffisante. Si la connaissance la plus précieuse est tacite, alors aucun wiki, aussi bien tenu soit-il, ne capturera tout. Croire qu’on peut tout écrire, c’est déjà se tromper sur la nature du savoir.
Ce qui m’a amené vers l’ITSM, et vers ITIL en particulier, c’est justement que ces cadres prennent le sujet au sérieux sans le réduire à la documentation. ITIL 4 fait de la gestion de la connaissance une pratique à part entière, dont l’objet est de maintenir et d’améliorer l’usage effectif du savoir à travers l’organisation ; et la pratique reconnaît explicitement que la connaissance ne se résume pas à de l’information stockée, qu’il y a dans l’expérience des personnes une profondeur que les bases de données n’atteignent pas. La gestion des problèmes, de son côté, transforme chaque incident en occasion d’apprendre collectivement plutôt qu’individuellement : un post-mortem honnête, une base d’erreurs connues vivante, c’est de la connaissance qui cesse d’appartenir à une seule tête.
Mais je veux être clair : aucune pratique ne sauvera une organisation qui traite ses sachants comme des lignes de coût. La gestion de la connaissance commence par une prise de conscience qui n’a rien de technique : certaines personnes portent un savoir du système qui dépasse de très loin leur fiche de poste, ce savoir a mis des années à se construire, et il ne se reconstituera pas en quelques semaines d’onboarding, quel que soit le talent du remplaçant. Une organisation qui comprend cela ne renoncera pas à toute restructuration ; mais elle saura ce qu’elle s’apprête à perdre, elle organisera le transfert tant qu’il est possible, elle élèvera son bus factor avant d’en avoir besoin. Une organisation qui ne le comprend pas continuera de découvrir, un incident à la fois, tout ce qu’elle ne sait plus.
La résilience opérationnelle ne tient pas qu’aux architectures redondantes et aux plans de continuité. Elle tient aussi, peut-être d’abord, à la mémoire vivante des systèmes. Cette mémoire a des visages. Le jour où on l’oublie, le grand blanc nous attend.