# Dossier d'exploitation

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

---

## 1. Présentation de la solution

<!-- Le minimum pour comprendre ce qu'on exploite, sans lire le DAT. -->

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

*à compléter*

## 2. Contacts et escalade

<!-- Qui appeler, dans quel ordre, à quelle heure. -->

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

*à compléter*

## 3. Environnements et accès

<!-- Où se trouvent les choses et comment y accéder. -->

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

*à compléter*

## 4. Démarrage et arrêt

<!-- Les procédures ordonnées, avec les vérifications entre chaque étape. -->

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

*à compléter*

## 5. Traitements planifiés

<!-- Le calendrier d'exploitation, traitement par traitement. -->

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

*à compléter*

## 6. Supervision

<!-- Ce qui est surveillé, et ce que signifie chaque alerte. -->

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

*à compléter*

## 7. Incidents courants

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

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

*à compléter*

## 8. Reprise et retour arrière

<!-- Comment revenir à un état sain. -->

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

*à compléter*

## 9. Sauvegardes

<!-- Ce qui est sauvegardé, et la preuve que ça se restaure. -->

<!-- Points à couvrir :
     - Périmètre, fréquence, rétention, emplacement
     - Procédure de restauration détaillée
     - Date du dernier test de restauration réussi
-->

*à compléter*

## 10. Exploitation courante

<!-- Les gestes récurrents hors incident. -->

<!-- Points à couvrir :
     - Purges, archivages, rotation des journaux
     - Vérifications périodiques et leur fréquence
     - Échéances à surveiller : certificats, licences, mots de passe techniques
-->

*à compléter*

## 11. Gestion des changements

<!-- Comment la solution évolue sans casser la production. -->

<!-- Points à couvrir :
     - Procédure de déploiement et fenêtres autorisées
     - Prérequis de validation avant mise en production
     - Communication aux utilisateurs
-->

*à compléter*

---

## Notes de rédaction

**Quand produire ce document**

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

**Erreurs les plus fréquentes**

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

**Référentiel de rattachement**

ITIL 4, pratiques de gestion des services. Les rubriques attendues (gestion des incidents, des événements, des changements, continuité) suivent le découpage ITIL, qui reste le référentiel dominant en exploitation SI.

---

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

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.