Un runbook vaut mieux qu'un expert indispensable

Il y a une phrase qui devrait alarmer tout dirigeant quand elle est prononcée en réunion : « il faut demander à Julien, c'est lui qui gère ça ». Si Julien est en vacances, malade, ou parti chez un concurrent, l'entreprise s'arrête sur ce point précis. Ce n'est pas un problème de personne, c'est un problème d'organisation qui a laissé la connaissance opérationnelle vivre uniquement dans une tête.

Le réflexe naturel est de valoriser l'expert indispensable : on le complimente, on le paie mieux, on lui confie toujours plus. Le résultat est pervers — plus il devient central, plus l'entreprise devient fragile, et moins lui-même a intérêt à documenter, puisque son irremplaçabilité est sa meilleure protection.

Le bus factor, un indicateur de risque trop souvent ignoré

Le « bus factor » mesure le nombre de personnes qui, en cas d'indisponibilité soudaine, ferait s'effondrer une partie critique du système. Dans beaucoup de PME et de scale-ups que nous auditons, ce chiffre est 1 pour des sujets entiers : la base de données de production, le pipeline de déploiement, la configuration réseau, parfois même les accès aux comptes cloud.

Un bus factor de 1 n'est pas une anomalie rare. C'est le mode par défaut d'une équipe qui grandit vite sans discipline opérationnelle : celui qui a construit le système est celui qui le comprend, et personne n'a de raison de challenger cet état de fait tant que rien ne casse.

Le problème n'est visible qu'au pire moment — un incident en production, un départ non anticipé, une absence prolongée — c'est-à-dire précisément quand l'entreprise ne peut pas se permettre d'apprendre en marchant.

Ce qu'un runbook fait que la mémoire d'un expert ne fait pas

Un runbook est un document opérationnel qui décrit, étape par étape, comment diagnostiquer et résoudre une situation donnée : un service qui ne répond plus, une bascule de base de données, une procédure de rollback, un renouvellement de certificat. Il n'explique pas la théorie, il donne les commandes exactes, les liens vers les tableaux de bord, les seuils d'alerte, et la liste des personnes à prévenir.

Sa valeur ne tient pas à son exhaustivité mais à sa fiabilité sous stress. Un ingénieur d'astreinte à trois heures du matin ne veut pas réfléchir, il veut exécuter une procédure vérifiée. C'est précisément ce que la mémoire d'un expert, même excellent, ne peut pas garantir : la fatigue, le stress et l'absence dégradent la mémoire humaine bien avant de dégrader un document bien écrit.

Un bon runbook a trois qualités :

• Il est testé, pas seulement écrit — quelqu'un d'autre que l'auteur l'a suivi à la lettre et l'a vu fonctionner.
• Il est daté et versionné, pour qu'on sache s'il correspond encore à l'infrastructure actuelle.
• Il commence par le symptôme, pas par l'architecture — on cherche « le site répond en 502 » et non « comprendre notre reverse proxy ».

Documenter n'est pas un projet, c'est un rituel

La documentation échoue le plus souvent parce qu'elle est traitée comme un chantier ponctuel : un sprint « documentation », une semaine dédiée, puis plus rien pendant un an, jusqu'à ce que tout soit obsolète. Le format qui fonctionne est différent : chaque incident résolu donne lieu à un post-mortem court, et chaque post-mortem alimente ou crée un runbook. La documentation devient un sous-produit du travail réel, pas une tâche séparée qu'on repousse toujours.

Une règle simple accélère cette dynamique : aucune intervention manuelle répétée deux fois ne reste sans procédure écrite. La première fois, on découvre. La deuxième fois, on documente avant de recommencer.

Réduire la dépendance sans dévaloriser l'expertise

L'objectif n'est pas de rendre les experts interchangeables ni de nier la valeur de leur expérience — c'est de séparer la connaissance qui doit rester dans une tête (le jugement, l'architecture, les arbitrages) de celle qui doit être transférable (les procédures, les diagnostics, les gestes récurrents).

Concrètement :

• Binômer systématiquement les interventions critiques, même quand cela semble plus lent sur le moment.
• Faire tourner les astreintes parmi plusieurs personnes formées, pas une seule qu'on sollicite par réflexe.
• Auditer les accès : si un seul compte détient les clés de production, c'est un runbook manquant qui se cache derrière un problème de sécurité.
• Valoriser la transmission dans les objectifs individuels au même titre que la production de code.

Cette transformation fait partie de ce que nous mettons en place dans nos missions de CTO à temps partagé : sortir la connaissance critique des têtes pour la mettre dans des systèmes que l'entreprise garde, quel que soit qui la quitte.

FAQ

Combien de temps faut-il pour réduire une dépendance critique à un expert unique ?

Comptez entre six et douze semaines pour les procédures les plus critiques — production, sauvegardes, accès — à condition d'y consacrer un temps dédié chaque semaine plutôt que d'attendre une disponibilité complète qui n'arrivera jamais. Les sujets secondaires peuvent suivre sur plusieurs mois, au rythme des incidents et des rotations d'astreinte.

Comment convaincre un expert de documenter s'il y voit une perte de pouvoir ?

Recadrez la conversation sur la valeur ajoutée réelle : un expert qui passe son temps à répondre à des urgences répétitives n'a pas le temps de travailler sur des sujets à plus forte valeur. Documenter n'efface pas son expertise, cela la libère des tâches mécaniques pour la concentrer sur le jugement et l'architecture, ce qui reste, lui, difficile à transférer.