DEX - Dossier d'exploitation

À quoi sert ce document

Le DEX s'écrit pour une personne d'astreinte, à trois heures du matin, qui n'a jamais vu la solution. Il complète le DAT : là où le DAT explique comment le système est construit, le DEX dit quoi faire quand il se comporte mal. Le test de qualité est simple et sans appel : quelqu'un d'extérieur au projet doit pouvoir relancer un traitement échoué en suivant le document, sans appeler personne. C'est habituellement une condition d'acceptation par la production.

Quand le produire

• Avant toute mise en production, comme livrable exigé par l'exploitation.
• Sur toute solution comportant des traitements planifiés ou des flux automatisés.
• Lors d'un transfert vers une TMA ou un nouveau prestataire.
• Après un incident majeur, pour intégrer la procédure de reprise qui a manqué.

Le plan, rubrique par rubrique

1. Présentation de la solution

   Le minimum pour comprendre ce qu'on exploite, sans lire le DAT.

   • Rôle métier de la solution et conséquence d'une indisponibilité
   • Schéma d'architecture simplifié
   • Périmètre couvert par le document

2. Contacts et escalade

   Qui appeler, dans quel ordre, à quelle heure.

   • Support niveau 1, 2, 3 avec coordonnées et plages de couverture
   • Référent métier et référent technique
   • Éditeurs et prestataires, avec numéros de contrat et engagements de support
   • Règle d'escalade par niveau de gravité

3. Environnements et accès

   Où se trouvent les choses et comment y accéder.

   • Inventaire des serveurs, services et URLs par environnement
   • Comptes techniques, rôles, et procédure de demande d'accès
   • Gestion des secrets : où ils sont stockés, jamais leur valeur

4. Démarrage et arrêt

   Les procédures ordonnées, avec les vérifications entre chaque étape.

   • Séquence de démarrage et ordre des dépendances
   • Séquence d'arrêt propre
   • Contrôle de bon fonctionnement après démarrage

5. Traitements planifiés

   Le calendrier d'exploitation, traitement par traitement.

   • Nom, planification, durée normale, durée maximale acceptable
   • Dépendances amont et aval
   • Fenêtre d'exécution et conséquence d'un dépassement
   • Procédure de relance et caractère rejouable du traitement

6. Supervision

   Ce qui est surveillé, et ce que signifie chaque alerte.

   • Indicateurs supervisés, techniques et fonctionnels
   • Seuils, criticité, destinataires
   • Pour chaque alerte : signification et première action à mener
   • Tableaux de bord et emplacement des journaux

7. Incidents courants

   Le catalogue des pannes déjà vues et de leur traitement. Section la plus consultée.

   • Symptôme observé, cause probable, diagnostic à mener, résolution
   • Fichier rejeté, flux en échec, saturation d'espace, expiration de certificat, blocage de base
   • Conditions dans lesquelles il ne faut surtout pas relancer

8. Reprise et retour arrière

   Comment revenir à un état sain.

   • Procédure de reprise après incident, par type de traitement
   • Retour arrière d'une livraison
   • Restauration à partir de sauvegarde et durée observée de l'opération
   • Objectifs de perte de données et de délai de remise en service

9. Sauvegardes

   Ce qui est sauvegardé, et la preuve que ça se restaure.

   • Périmètre, fréquence, rétention, emplacement
   • Procédure de restauration détaillée
   • Date du dernier test de restauration réussi

10. Exploitation courante

    Les gestes récurrents hors incident.

    • Purges, archivages, rotation des journaux
    • Vérifications périodiques et leur fréquence
    • Échéances à surveiller : certificats, licences, mots de passe techniques

11. Gestion des changements

    Comment la solution évolue sans casser la production.

    • Procédure de déploiement et fenêtres autorisées
    • Prérequis de validation avant mise en production
    • Communication aux utilisateurs

Les erreurs qui coûtent cher

• Écrire le DEX pour quelqu'un qui connaît déjà la solution. Le lecteur cible est d'astreinte, la nuit, et découvre le système.
• Documenter la sauvegarde sans avoir testé la restauration. Une sauvegarde jamais restaurée est une hypothèse, pas une garantie.
• Omettre les cas où il ne faut pas relancer. Un traitement qui ne supporte pas d'être relancé produit, au deuxième passage, des doublons qu'il faudra corriger à la main.
• Renvoyer vers le DAT pour les procédures. Le DEX doit être autoportant sur tout ce qui s'exécute en urgence.
• Ne pas dater le document ni le mettre à jour après chaque incident. Le DEX se maintient à chaud, sinon il ment.