# Fiche de consigne d'exploitation

| | |
| --- | --- |
| **Projet** | *à compléter* |
| **Version** | *à compléter* |
| **Date** | *à compléter* |
| **Auteur** | *à compléter* |
| **Rédigé par** | MOE, validée par la production |
| **Destinataires** | Exploitation niveau 1, astreinte, support |
| **Statut** | Brouillon / En relecture / Validé |

---

## 1. Identification

<!-- L'en-tête qui permet de retrouver la bonne fiche en trente secondes. -->

<!-- Points à couvrir :
     - 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
-->

*à compléter*

## 2. 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. -->

<!-- Points à couvrir :
     - 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
-->

*à compléter*

## 3. Prérequis

<!-- Ce qu'il faut avoir sous la main avant de commencer. -->

<!-- Points à couvrir :
     - 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)
-->

*à compléter*

## 4. Ce qu'il ne faut pas faire

<!-- Les gestes qui aggravent la situation. Placés avant la procédure, pas après. -->

<!-- Points à couvrir :
     - 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
-->

*à compléter*

## 5. Procédure

<!-- Les étapes numérotées, une action par étape, commandes citées exactement. -->

<!-- Points à couvrir :
     - 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
-->

*à compléter*

## 6. Contrôle de bon déroulement

<!-- Comment vérifier que la situation est réellement rétablie. -->

<!-- Points à couvrir :
     - 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
-->

*à compléter*

## 7. Si la procédure échoue

<!-- Le chemin d'escalade, avec les informations à transmettre. -->

<!-- Points à couvrir :
     - 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
-->

*à compléter*

## 8. Traces à conserver

<!-- Ce qui doit être consigné une fois l'opération terminée. -->

<!-- Points à couvrir :
     - Ticket à renseigner et informations attendues
     - Journaux à archiver et durée de conservation
     - Information à remonter au métier, le cas échéant
-->

*à compléter*

## 9. Suivi de la fiche

<!-- Ce qui garde la fiche vivante. -->

<!-- Points à couvrir :
     - Auteur, date de création, date de dernière revue
     - Date du dernier test de la procédure et par qui
     - Historique des modifications
-->

*à compléter*

---

## Notes de rédaction

**Quand produire ce document**

- 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.

**Erreurs les plus fréquentes**

- É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.

---

Modèle « Fiche de consigne d'exploitation » (Exploitation & run), publié par DataALC.
Version en ligne, commentée : https://www.dataalc.com/boite-a-outils/templates/fiche-consigne/

Ce modèle est fourni comme base de travail : adaptez-le à votre contexte, supprimez les rubriques sans objet plutôt que de les laisser vides.