Fiche de consigne d'exploitation
Une page, une situation, une procédure numérotée : ce qu'on exécute à trois heures du matin sans réveiller personne.
9 rubriques, consignes de rédaction incluses. Sans inscription. Le tableur contient une grille « Procédure » prête à remplir.
À quoi sert ce document
Là où le dossier d'exploitation décrit l'ensemble du système, la fiche de consigne traite une situation et une seule : ce flux en échec, ce disque saturé, cette relance mensuelle. C'est l'unité que l'exploitation manipule réellement, parce qu'en incident personne ne lit un dossier de quarante pages. Sa règle de conception tient en une phrase : elle doit être exécutable par quelqu'un qui ne connaît pas l'application, sans jugement à porter. Chaque fois qu'une fiche demande d'apprécier une situation, elle a échoué et il faut la découper.
Quand le produire
- Pour chaque incident récurrent identifié en recette ou survenu en production.
- Pour chaque opération manuelle périodique : relance, purge, clôture, ouverture de période.
- Quand une action est confiée à un niveau 1 qui n'a pas la connaissance applicative.
- Après chaque incident traité en urgence, pour que la solution trouvée ne reste pas dans la tête de celui qui l'a trouvée.
Le plan, rubrique par rubrique
-
Identification
L'en-tête qui permet de retrouver la bonne fiche en trente secondes.
- Numéro de fiche et intitulé formulé comme le symptôme observé
- Application et composant concernés
- Criticité et impact métier si l'action n'est pas menée
- Niveau de support habilité à l'exécuter
- Durée estimée de l'opération
-
Quand appliquer cette consigne
Le déclencheur, décrit tel qu'il se présente à l'opérateur, pas tel que le concepteur le comprend.
- Alerte de supervision reçue, avec son libellé exact
- Symptôme observé ou message d'erreur, cité littéralement
- Situations voisines à ne pas confondre, avec renvoi vers la bonne fiche
-
Prérequis
Ce qu'il faut avoir sous la main avant de commencer.
- Accès, comptes et habilitations nécessaires
- Outils, consoles ou serveurs de rebond à utiliser
- Informations à collecter avant d'agir (heure, identifiant du traitement, volumétrie)
-
Ce qu'il ne faut pas faire
Les gestes qui aggravent la situation. Placés avant la procédure, pas après.
- Actions destructrices ou non réversibles à proscrire
- Traitements qu'il ne faut surtout pas relancer, et pourquoi
- Seuil au-delà duquel il faut escalader sans agir
-
Procédure
Les étapes numérotées, une action par étape, commandes citées exactement.
- Une seule action par étape, à l'impératif
- Commandes et chemins donnés en toutes lettres, pas décrits
- Résultat attendu après chaque étape, pour savoir si on peut continuer
- Point d'arrêt explicite si le résultat attendu n'est pas obtenu
-
Contrôle de bon déroulement
Comment vérifier que la situation est réellement rétablie.
- Vérification technique : état du service, du traitement, du fichier
- Vérification fonctionnelle : ce que le métier doit pouvoir constater
- Délai à respecter avant de considérer l'incident clos
-
Si la procédure échoue
Le chemin d'escalade, avec les informations à transmettre.
- Niveau à solliciter et coordonnées, avec les plages de couverture
- Éléments à joindre : journaux, horodatage, actions déjà tentées
- Mesure conservatoire à prendre en attendant
-
Traces à conserver
Ce qui doit être consigné une fois l'opération terminée.
- Ticket à renseigner et informations attendues
- Journaux à archiver et durée de conservation
- Information à remonter au métier, le cas échéant
-
Suivi de la fiche
Ce qui garde la fiche vivante.
- Auteur, date de création, date de dernière revue
- Date du dernier test de la procédure et par qui
- Historique des modifications
Les erreurs qui coûtent cher
- Écrire un récit au lieu d'étapes numérotées. En incident, un paragraphe ne s'exécute pas : il se relit trois fois et se comprend de travers.
- Ne pas tester la fiche avec quelqu'un d'extérieur. Une consigne validée par son auteur valide surtout ce qu'il avait déjà en tête.
- Omettre la rubrique « ce qu'il ne faut pas faire ». C'est elle qui évite le geste qui transforme un incident en sinistre.
- Décrire les commandes au lieu de les citer. « Relancer le job d'intégration » laisse l'opérateur deviner ; la commande exacte ne se devine pas.
- Laisser une fiche demander un jugement. Si l'opérateur doit apprécier la gravité, découpez en plusieurs fiches ou faites escalader.
- Ne jamais réviser la fiche après un incident. Une consigne périmée fait perdre plus de temps qu'une absence de consigne, parce qu'on lui fait confiance.
Documents complémentaires
Besoin d'un cadrage, pas seulement d'un modèle ?
Nous rédigeons et challengeons ces documents en mission, sur des projets d'intégration, de migration de données et de décisionnel. Parlons de votre projet.