La documentation d'exploitation est un travail de création discret : on n'en voit l'utilité que le jour où elle manque. Bien conçue, elle se lit vite, se met à jour facilement et fait gagner des heures au moment critique. Elle sert aussi de mémoire collective : quand une personne change de poste ou part en congé, ses habitudes ne disparaissent pas avec elle, et chacun peut intervenir avec les mêmes repères.
Écrire pour quelqu'un de fatigué
Le lecteur type est une personne réveillée en pleine nuit, qui connaît mal le service. Phrases courtes, commandes exactes, une action par étape, résultat attendu après chaque étape. Évitez les explications longues au milieu d'une procédure : placez-les en annexe.
Une fiche par serveur
La fiche rassemble le rôle, l'emplacement, les adresses, le responsable, la sauvegarde, la supervision et la fin de garantie. Elle répond à la question « qu'est-ce que c'est et qui s'en occupe ? ». Ne notez jamais de secret : indiquez où il est rangé.
Un journal pour chaque incident
Pendant l'incident, notez les événements avec l'heure. Après, décrivez l'impact, la cause et les actions correctives. Le calcul du coût d'un incident aide à hiérarchiser les actions de prévention, et chaque enseignement devient une action avec un responsable.
Prévoir la reprise
Un plan de reprise d'activité consigne les objectifs de temps et de perte de données, l'ordre de redémarrage et les contacts. Testez-le régulièrement, imprimez-en un exemplaire hors de l'infrastructure qu'il protège.
Tenir à jour sans effort
Une documentation périmée est pire que l'absence de documentation. Rattachez la mise à jour à des événements : changement de configuration, incident, départ ou arrivée. Datez chaque version et nommez un propriétaire.
Mesurer l'utilité de la documentation
Une documentation se juge à l'usage. Demandez à chaque nouvel arrivant de suivre un runbook et de noter ce qui manque. Après chaque incident, vérifiez si le document a servi, s'il a été trouvé facilement et s'il était à jour. Supprimez ce que personne ne lit et complétez ce qu'on cherche souvent. Cette boucle courte garde la documentation vivante, alors qu'un grand projet de rédaction ponctuel vieillit mal et finit oublié dans un dossier que personne n'ouvre plus, faute de repères et de responsable identifié.
Checklist avant de commencer
- Une fiche par serveur, avec responsable
- Runbooks écrits avec commandes exactes
- Aucun secret dans les documents
- Journal d'incident tenu pendant l'incident
- Plan de reprise testé et imprimé
- Date et propriétaire sur chaque document
Questions fréquentes
Où conserver la documentation ?
À un endroit accessible même si l'infrastructure est tombée : copie imprimée ou stockage hors du système concerné.
Qui doit relire un runbook ?
Quelqu'un qui ne l'a pas écrit. Si cette personne peut l'exécuter sans aide, le document est bon.
Quel outil utiliser pour écrire ?
Celui que l'équipe ouvrira vraiment, accessible même quand l'infrastructure est tombée. Un document simple, versionné et daté vaut mieux qu'un outil sophistiqué que personne ne met à jour.
Ce guide présente des principes généraux : il ne note ni ne recommande aucun site de l'annuaire ni aucun prestataire. Les règles juridiques citées sont rappelées de manière simplifiée : vérifiez-les auprès des sources officielles.
Besoin de matériel ou de fournitures ? L'annuaire classe 22 sites dans la rubrique Baie loisirs créatifs.
Ouvrir la baieCalculateurs utiles
- 23RTO, RPO et coût de repriseComparer objectifs de reprise, temps estimé et perte attendue
- 16Coût d'un incident (heures et taux saisis)Mobilisation, analyse, chiffre d'affaires perdu et pénalités
- 13Rotation des journaux et volume occupéEspace disque occupé par des journaux compressés et archivés