C'est l'objection universelle contre la documentation, et elle contient une part de vérité — le temps manque — mais elle repose sur une erreur de raisonnement : opposer « documenter » et « faire son travail », alors que documenter fait partie du travail et en fait gagner à terme. Plusieurs façons de sortir de ce faux dilemme. D'abord, comprendre que l'absence de documentation coûte du temps, en permanence et de façon invisible : re-chercher une solution déjà trouvée, refaire une configuration de mémoire, expliquer oralement à un collègue ce qui serait écrit une fois, reconstituer un système que personne ne comprend, gérer une crise sans savoir comment restaurer. Ce temps perdu, dispersé et récurrent, dépasse largement le temps qu'aurait pris la documentation. Ne pas documenter, ce n'est pas gagner du temps, c'est le reporter et le multiplier. Ensuite, la clé pratique est de documenter pendant qu'on fait, pas « plus tard ». Le « plus tard » n'arrive jamais (il y a toujours plus urgent), et documenter à froid une tâche déjà réalisée est fastidieux et incomplet. En revanche, noter au fur et à mesure qu'on installe un poste, qu'on résout un ticket, qu'on configure un service coûte quelques minutes et capture l'information tant qu'elle est fraîche et exacte. Résoudre un problème puis noter la solution en deux lignes dans la base de connaissances (niveau 1) transforme un effort ponctuel en actif réutilisable. C'est un réflexe à prendre, pas une tâche séparée à caser dans un agenda déjà plein. Autre levier : prioriser. On ne documente pas tout de la même façon. Concentrez l'effort là où le retour est maximal : les procédures des tâches récurrentes (ce qu'on refait souvent, ce qui gagne le plus à être écrit), les éléments critiques (l'infrastructure dont dépend tout, les accès importants, les procédures de restauration), et les solutions des problèmes qui reviennent. Inutile de viser une documentation exhaustive parfaite d'emblée — mieux vaut une documentation partielle mais utile et à jour, enrichie au fil de l'eau, qu'un projet monumental jamais commencé. Autre approche : documenter en résolvant. Quand vous traitez un incident nouveau ou complexe, votre investigation est déjà la matière de la documentation ; il suffit de la consigner. Vous ne rajoutez pas une tâche, vous captez ce que vous faites de toute façon. Enfin, c'est une question de culture et de discipline d'équipe : dans un service où documenter est valorisé et attendu (et où l'on constate les bénéfices), cela devient naturel ; dans un service où c'est vu comme une corvée optionnelle, cela ne se fait jamais — jusqu'à la crise qui rappelle brutalement son utilité. Le vrai obstacle n'est donc pas tant le manque de temps que le manque de priorité accordée à quelque chose qui ne paraît jamais urgent mais qui est important. La bonne posture : intégrer la documentation au flux de travail (documenter en faisant), la prioriser sur le critique et le récurrent, viser l'utile plutôt que l'exhaustif, et considérer le temps qu'elle prend non comme une perte mais comme un investissement qui se rembourse largement — le jour où vous, ou un collègue, retrouvez en trente secondes une information qui aurait sinon coûté une heure, ou le jour où une documentation à jour permet de reprendre un système ou de restaurer après un sinistre.

Cette pensée — « je connais mon système, donc à quoi bon l'écrire ? » — est l'un des principaux freins à la documentation, et elle repose sur plusieurs illusions qu'il est utile de démonter. Première illusion : que vous vous souviendrez toujours. La mémoire est faillible et sélective. Ce que vous savez parfaitement aujourd'hui, vous l'aurez partiellement oublié dans six mois, surtout pour les configurations rares ou les décisions dont vous ne vous rappellerez plus la raison. Combien de fois un technicien se retrouve face à un réglage qu'il a lui-même fait et se demande « pourquoi ai-je configuré cela ainsi ? ». La documentation, c'est aussi une note à votre futur vous-même, qui aura oublié. Deuxième illusion, plus grave : que vous serez toujours là. C'est le fameux « facteur bus » (que se passe-t-il si vous êtes absent, malade, en congé, ou si vous partez ?). Si toute la connaissance de l'infrastructure est dans votre seule tête, votre absence — même temporaire — paralyse le service : personne ne peut dépanner, reprendre, ou même comprendre le système. Vous devenez un point unique de défaillance, ce qui n'est bon ni pour l'organisation (fragile) ni pour vous (impossible de déléguer, de prendre des vacances sereines, d'être remplacé). Documenter, c'est libérer l'organisation — et vous-même — de cette dépendance. Troisième point : la documentation ne sert pas qu'à vous, elle sert au collectif et à l'avenir. Un collègue qui doit intervenir sur votre périmètre, un nouvel arrivant à former, un prestataire qui prend le relais, votre successeur le jour où vous évoluerez — tous dépendent de ce qui est écrit. Sans documentation, chaque transmission repart de zéro, dans la douleur (l'arrivée dans un environnement non documenté est un cauchemar bien connu de tout technicien). Quatrième point : la documentation est indispensable dans les moments critiques, précisément ceux où l'on ne peut pas se permettre de tâtonner. Restaurer après un sinistre (section 5.2), rétablir un service en urgence, reconstruire une configuration — sous pression, dans la panique, la mémoire flanche et l'improvisation coûte cher. Une procédure écrite, suivie pas à pas, sauve la situation. C'est justement quand tout va mal qu'on regrette amèrement de ne pas avoir documenté à froid. Cinquième point : documenter force à clarifier. Mettre par écrit une infrastructure ou une procédure révèle souvent des incohérences, des angles morts, des choses qu'on croyait comprendre mais qu'on ne maîtrise pas vraiment. L'exercice améliore la connaissance qu'on a de son propre système. En résumé, la documentation ne sert pas « à vous qui savez déjà », elle sert à vous plus tard (qui aurez oublié), à vous absent (pour que le service continue), à vous en crise (pour agir sûrement sous pression), à vos collègues et successeurs (pour reprendre sans souffrir), et à l'organisation (pour ne pas dépendre d'une seule personne). La connaissance dans une seule tête est un risque ; la même connaissance écrite et partagée est un actif. Le fait que vous connaissiez votre infrastructure n'est pas une raison de ne pas la documenter — c'est précisément parce que vous la connaissez que vous êtes la personne la mieux placée pour le faire, maintenant, avant que cette connaissance ne se perde.