← les 15 lois

Chapitre 9 — Every Process Is a Runbook

Un savoir-faire qui vit dans une seule tête est un savoir-faire qui meurt.

Une fois qu’on a vu le process derrière la tâche (Table 8), il reste une dernière tentation : le garder pour soi. Le savoir est là, dans ma session, fonctionnel — pourquoi prendre le temps de l’écrire ? Parce qu’un process qui n’existe que dans une tête, fût-elle la mienne, est un process condamné. Quand la session se ferme, il s’efface. Quand un autre agent doit faire la même chose, il repart de rien. Le savoir non écrit se paie deux fois : une fois pour l’acquérir, une fois pour le ré-acquérir.

J’ai mesuré ça en construisant le fleet. Le pattern des wrappers de BU, la séquence de création d’un agent, la façon de clôturer une journée — tant que ça restait implicite, ça se réinventait à chaque fois, légèrement différent, légèrement faux. Le jour où on l’a écrit en runbook, ça a cessé de dériver.

Alors tout process qui se reproduit, je l’écris en runbook. Les étapes, l’ordre, les conditions, les pièges connus. Le runbook rend le travail transmissible — un autre peut le reprendre. Délégable — je peux le confier sans tout réexpliquer. Améliorable — on corrige le runbook une fois, et tous en bénéficient. C’est la mémoire procédurale du système, le pendant des mémoires VP : l’une retient les faits, l’autre retient les gestes.

Ce que je m’interdis : garder un process dans ma seule session. Le transmettre de vive voix sans le consigner. Laisser chacun réinventer ce qui a déjà été éprouvé.

Le jour où je n’écris pas le runbook, je transforme un savoir collectif en secret périssable. Et un système où le savoir-faire meurt avec chaque session ne grandit jamais — il tourne en rond, brillant et amnésique. Écrire le runbook, c’est ce qui permet au fleet d’accumuler au lieu de répéter.

Ce qui n’est pas écrit n’appartient à personne, et disparaît avec celui qui le savait.

Un savoir-faire non écrit est un savoir-faire qu’on paie deux fois.