5.4Documentation & procédures IT
L'essentiel en 30 secondes
- Un savoir gardé « dans la tête » est un risque : absence, départ, oubli — et l'activité se bloque faute de personne qui sait.
- Trois formes utiles : procédure (comment faire), runbook (que faire en cas de panne), base de connaissances (solutions capitalisées).
- Une bonne doc est vivante : à jour, trouvable et actionnable — sinon elle induit en erreur.
Mini-cas filé — Sofiane écrit un runbook avant son congé
Sofiane, technicien support dans une PME de distribution à Alger, est le seul à savoir remettre en route le serveur de fichiers quand il décroche. Il part bientôt en congé et ne veut pas laisser l'équipe en panique. Il applique la démarche de la section : il écrit un runbook « le serveur de fichiers ne répond plus », avec des étapes précises et dans l'ordre, compréhensibles par un collègue non expert. Il le fait tester par un autre technicien : là où ce dernier bloque, il corrige la doc. Il range le runbook dans un endroit trouvable, note la date de mise à jour, et réduit ainsi la dépendance à une seule personne.
Cas autonome de cette section : il revient dans le cours, le schéma, le script et le défi 48h de la section 5.4.
1. Le savoir dans la tête = un risque
Quand une opération n'existe que « dans la tête » d'une personne, l'entreprise dépend d'elle : absence, départ, oubli, et c'est le blocage. Documenter transforme un savoir personnel en savoir partagé. Sofiane le vit : seul à savoir remettre en route le serveur de fichiers, il prépare les autres. Ce n'est pas de la paperasse — c'est de la continuité, de la qualité et du temps gagné.
2. Procédures, runbooks, base de connaissances
Trois formes utiles. La procédure décrit comment réaliser une opération (installer un poste, créer un compte). Le runbook est une marche à suivre précise pour une situation donnée, souvent une panne (« que faire si le serveur X ne répond plus »). La base de connaissances capitalise les solutions aux problèmes déjà rencontrés, réutilisables par toute l'équipe et parfois par les utilisateurs. Sofiane combine les trois selon les besoins.
3. Une bonne doc est vivante
Une doc utile est à jour, trouvable et actionnable : des étapes claires, testées, que quelqu'un d'autre peut suivre sans vous. On la met à jour quand la réalité change — sinon elle induit en erreur — et on l'écrit pour le lecteur, pas pour soi. Documenter au fil de l'eau coûte peu ; reconstituer après coup coûte cher. Sofiane note systématiquement la date de mise à jour.
🔎 Exemple concret — 🔎 Exemple concret — Le collègue en congé
Sofiane imagine la panne du serveur de fichiers pendant son absence :
Sans runbook : blocage jusqu'à son retour, ou tâtonnements risqués
Avec runbook « Serveur fichiers ne répond plus » :
étapes testées → un collègue rétablit le service en 20 minLecture : le runbook rend l'équipe autonome face à la panne.
Leçon : documenter, c'est ne pas dépendre d'une seule personne.
Vocabulaire de la section
- Procédure
- Description pas à pas d'une opération à réaliser.
Exemple simple : Sofiane documente la création d'un compte utilisateur.
Ce que ce n'est pas : une explication vague laissée à l'oral.
Réflexe : procédure = comment faire.
- Runbook
- Marche à suivre précise pour une situation donnée (souvent une panne).
Exemple simple : Le runbook « serveur de fichiers ne répond plus » de Sofiane.
Ce que ce n'est pas : improvise quand la panne survient.
Réflexe : runbook = que faire en cas de panne.
- Base de connaissances
- Recueil réutilisable des solutions aux problèmes déjà rencontrés.
Exemple simple : Sofiane y consigne les solutions trouvées pour l'équipe.
Ce que ce n'est pas : résoudre le même incident dix fois de zéro.
Réflexe : capitaliser les solutions.
- Documentation vivante
- Doc à jour, trouvable et actionnable, mise à jour quand la réalité change.
Exemple simple : Sofiane date chaque doc et la corrige après test.
Ce que ce n'est pas : un document jamais actualisé qui trompe.
Réflexe : à jour, trouvable, actionnable.
- Bus factor
- Nombre de personnes qui, si elles manquaient, bloqueraient l'activité ; la doc l'augmente.
Exemple simple : Sofiane augmente le bus factor en partageant son savoir.
Ce que ce n'est pas : tout faire reposer sur une seule personne.
Réflexe : plus la doc est partagée, moins on dépend.
En pratique — En pratique — Écrire un runbook
- Choisissez une panne fréquente que vous savez résoudre (comme le serveur de fichiers de Sofiane).
- Écrivez les étapes précises, dans l'ordre, comme pour un collègue non expert.
- Faites-le tester par quelqu'un d'autre : s'il bloque, c'est la doc qu'il faut corriger.
- Rangez-le dans un endroit trouvable et notez sa date de mise à jour.
Script pas-à-pas — écrire un runbook comme Sofiane (10 min)
1) Choisissez une panne que vous savez résoudre. 2) Écrivez le titre tel qu'on la décrirait à l'oral. 3) Listez les étapes précises, dans l'ordre, avec les chemins et commandes exacts. 4) Ajoutez la fin heureuse : comment vérifier que c'est rétabli. 5) Donnez-le à tester à un collègue non expert. 6) Corrigez chaque endroit où il bloque, rangez-le et datez-le.
La question magique pour valider une doc : « quelqu'un d'autre réussit-il sans moi ? » Si non, corrigez.
Modèle copier-coller — mon runbook
Titre : ___ (ex. « Serveur de fichiers ne répond plus »)
Symptôme observé : ___
1. ___
2. ___
3. ___
Vérification que c'est rétabli : ___
Où le ranger : ___ (trouvable par l'équipe)
Dernière mise à jour : ___
Règle : à jour · trouvable · actionnable.Un runbook de panne
Sofiane écrit que faire si le serveur de fichiers ne répond plus, étape par étape.
Une procédure de routine
Sofiane documente l'installation d'un poste standard pour la PME.
Une base de connaissances
Sofiane capitalise les solutions déjà trouvées pour que l'équipe n'en reparte pas de zéro.
Une doc vivante
Sofiane date et corrige ses documents quand la configuration change.
✓ Bonnes pratiques
- Documenter au fil de l'eau : c'est bien moins coûteux qu'après coup.
- Écrire pour le lecteur : étapes claires, testées par un autre.
- Garder la doc à jour et trouvable.
✗ Pièges fréquents
- Garder le savoir dans sa tête.
- Écrire une doc jamais mise à jour : elle trompe.
- Documenter pour soi, illisible pour les autres.
Points clés à retenir
- Le savoir non documenté est un risque de blocage.
- Procédure (comment faire), runbook (que faire en cas de panne), base de connaissances (solutions capitalisées).
- Une bonne doc est à jour, trouvable et actionnable.
- Documenter au fil de l'eau coûte moins que reconstituer après coup.
Défi 48h — appliquez demain
Comme Sofiane, écrivez UN runbook pour une panne que vous savez résoudre : titre, symptôme, étapes précises dans l'ordre, et vérification finale. Faites-le tester par quelqu'un d'autre et corrigez là où il bloque. Rangez-le dans un endroit trouvable et datez-le.
- Je peux expliquer pourquoi le savoir non documenté est un risque.
- Je distingue procédure, runbook et base de connaissances.
- Je sais ce qui fait une bonne doc : à jour, trouvable, actionnable.
Questions fréquentes
Documenter ne fait-il pas perdre du temps ?
À court terme un peu ; à moyen terme cela en fait gagner beaucoup : moins de re-diagnostics, autonomie de l'équipe, continuité en cas d'absence. Le vrai coût est celui d'un savoir qui disparaît avec la personne qui le détenait.
Comment savoir si une doc est bonne ?
Faites-la exécuter par quelqu'un d'autre : si cette personne réussit sans vous solliciter, la doc est actionnable. Chaque blocage rencontré indique précisément quoi corriger.
Quel est l'intérêt majeur de documenter les procédures IT ?