Modèles de documentation d'exploitation¶

Ces modèles accompagnent le cours Knowledge Management : runbooks, postmortems, ADR & docs-as-code. Copiez-les dans le dépôt de la plateforme et adaptez-les : un modèle est un point de départ, pas un formulaire à remplir mécaniquement.

Modèle	Emplacement conseillé	Type Diátaxis
Runbook	`docs/runbooks/<alerte>.md`	Guide pratique
Postmortem	`docs/postmortems/AAAA-MM-JJ-<incident>.md`	Explication
ADR	`docs/adr/NNNN-<decision>.md`	Explication
Rapport d'audit croisé	`docs/audit/audit-<equipe-auditrice>.md`	Référence
Index du dossier de preuves	`docs/preuves/README.md`	Référence
Registre des risques	`docs/risques.md`	Référence
Matrice de conformité	`docs/conformite.md`	Référence

Conventions communes

Horodatages en UTC, au format AAAA-MM-JJ HH:MM
Un propriétaire et une date de dernière revue en tête de chaque document
Aucun secret : indiquez où et comment l'obtenir, jamais sa valeur

Runbook¶

# Runbook : <NomDeLAlerte>

Propriétaire : <équipe>  ·  Dernière revue : <AAAA-MM-JJ>
Alerte : `<NomDeLAlerte>`  ·  Sévérité : <critical | warning>  ·  Composant : <component>

## Symptôme et impact
- Ce que signifie l'alerte : <une phrase>
- Impact utilisateur : <qui est touché, comment>
- SLO concerné : <SLO et consommation d'error budget attendue>

## Diagnostic
1. Confirmer le symptôme : <lien dashboard, panneau>
2. Identifier le composant et la cause :
   ```bash
   kubectl -n <namespace> get pods
   kubectl -n <namespace> describe pod <pod> | grep -A5 "Last State"
   kubectl -n <namespace> get events --sort-by=.lastTimestamp | tail -20
   ```
3. Vérifier les changements récents : <historique ArgoCD, dernière MR fusionnée>

## Remédiation
| Cause identifiée | Action | Risque |
| :--- | :--- | :--- |
| <cause 1> | <action, idéalement par Git> | <faible / moyen / élevé> |
| <cause 2> | <action> | <risque> |

## Retour à la normale
- <critère mesurable, ex : aucun redémarrage depuis 15 min>
- <critère mesurable, ex : SLI de disponibilité au-dessus de l'objectif>

## Escalade
- Après <durée> sans amélioration : <rôle ou équipe, canal>
- Informations à transmettre : <alerte, heure de début, actions déjà tentées>

## Références
- Dashboard : <lien>
- ADR et postmortems liés : <liens>

Postmortem¶

# Postmortem : <titre factuel de l'incident>

Statut : <brouillon | revu | publié>  ·  Rédacteurs : <noms ou rôles>  ·  Date : <AAAA-MM-JJ>

## Résumé
<3 à 5 lignes : ce qui s'est passé, durée, impact, résolution>

## Impact
- Durée de l'impact : <début> → <fin> (UTC), soit <durée>
- Utilisateurs ou requêtes touchés : <chiffre>
- Error budget consommé : <pourcentage du budget de la fenêtre>

## Chronologie (UTC)
| Heure | Événement | Source |
| :--- | :--- | :--- |
| HH:MM | Début de l'impact | <métrique, log> |
| HH:MM | Détection : <alerte ou signalement> | <Alertmanager> |
| HH:MM | Prise en charge par <rôle> | <canal> |
| HH:MM | Atténuation : <action> | <commit, commande> |
| HH:MM | Résolution confirmée | <dashboard> |

Temps de détection : <durée>  ·  Temps d'atténuation : <durée>  ·  Temps de rétablissement : <durée>

## Cause racine et facteurs contributifs
- Déclencheur : <ce qui a déclenché l'incident>
- Facteurs techniques : <...>
- Facteurs de processus ou d'outillage : <...>
- Pourquoi la détection a pris ce temps : <...>

## Ce qui a bien fonctionné
- <...>

## Ce qui a mal fonctionné
- <...>

## Où nous avons eu de la chance
- <...>

## Actions
| Action | Type | Responsable | Échéance | Ticket |
| :--- | :--- | :--- | :--- | :--- |
| <action> | <prévenir / détecter / atténuer> | <rôle> | <AAAA-MM-JJ> | <lien> |

Ce postmortem est sans reproche : il décrit des systèmes et des décisions, pas des fautes individuelles.

ADR¶

# ADR NNNN : <décision formulée comme un choix>

Statut : <proposé | accepté | déprécié | remplacé par ADR NNNN>  ·  Date : <AAAA-MM-JJ>
Décideurs : <rôles>

## Contexte
<Les forces en présence : besoin, contraintes techniques, sécurité, coût, compétences de l'équipe>

## Options envisagées
1. <Option A> : <avantages, inconvénients>
2. <Option B> : <avantages, inconvénients>
3. <Option C> : <avantages, inconvénients>

## Décision
Nous retenons <option>, parce que <raison principale>.

## Conséquences
- Positives : <...>
- Négatives ou acceptées : <ce que l'on perd, la dette assumée>
- Actions induites : <supervision, documentation, formation>

Rapport d'audit croisé¶

# Rapport d'audit croisé : <plateforme auditée>

Équipe auditrice : <noms ou rôles>  ·  Équipe auditée : <noms ou rôles>
Date : <AAAA-MM-JJ>  ·  Version auditée : <tag ou commit>

## Périmètre et règles d'engagement
- Cibles autorisées : <namespaces, dépôts, machine>
- Actions interdites : <destruction de données, de VM ou de dépôt, déni de service>
- Référentiel : <registre des risques, matrice de conformité, grille d'audit>

## Synthèse
| Sévérité | Nombre de constats |
| :--- | :---: |
| Critique | <n> |
| Majeure | <n> |
| Mineure | <n> |

## Constats

### AUD-01 : <titre factuel>
- Sévérité : <critique | majeure | mineure>
- Contrôle visé : <exigence ou contrôle du référentiel>
- Preuve : <fichier de preuve> et commande rejouable :
  ```bash
  <commande exacte>
  ```
- Résultat observé : <sortie significative>
- Impact : <conséquence concrète en cas d'exploitation>
- Recommandation : <action corrective>
- Statut : <ouvert | corrigé et contre-vérifié | dérogation argumentée>

## Points forts constatés
- <contrôles efficaces, bonnes pratiques à souligner>

Index du dossier de preuves¶

# Dossier de preuves

Nommage : `AAAA-MM-JJ_HHMM_<scenario>.<ext>` (UTC). Empreintes calculées avec `sha256sum`.

| Exigence | Scénario | Preuve | Résultat | SHA-256 (8 premiers caractères) |
| :--- | :--- | :--- | :--- | :--- |
| <ex : SLO tenu en charge nominale> | <load-nominal> | [2026-11-04_1015_load-nominal.png](2026-11-04_1015_load-nominal.png) | <validé : 99,9 %, p95 180 ms> | <a1b2c3d4> |
| <ex : image non signée refusée> | <admission-unsigned> | [2026-11-03_1432_admission-unsigned.png](2026-11-03_1432_admission-unsigned.png) | <validé : refus Kyverno> | <e5f6a7b8> |

Registre des risques¶

# Registre des risques

Méthode : STRIDE  ·  Échelles : vraisemblance et impact de 1 (faible) à 4 (critique)

| ID | Catégorie STRIDE | Scénario de menace | Actif | V | I | Contrôle prévu | Preuve attendue | Statut |
| :--- | :--- | :--- | :--- | :---: | :---: | :--- | :--- | :--- |
| R-01 | Information disclosure | Secret committé dans le dépôt | Clé de passerelle de paiement | 3 | 4 | Détection de secrets bloquante en CI | Pipeline bloquée sur un faux secret | <à faire / en place / vérifié> |
| R-02 | Tampering | Image modifiée entre build et déploiement | Image de l'API | 2 | 4 | Signature Cosign vérifiée à l'admission | Refus d'une image non signée | <statut> |
| R-03 | Denial of service | Pic de charge non absorbé | API de paiement | 3 | 3 | HPA, PDB, tests de stress | Point de rupture mesuré | <statut> |

Matrice de conformité¶

# Matrice de conformité

Référentiels : <PSSI interne, CIS Benchmark Ubuntu 24.04 niveau 1, CIS Kubernetes, OWASP>

| Exigence | Référence | Contrôle mis en place | Outil | Preuve | Statut |
| :--- | :--- | :--- | :--- | :--- | :--- |
| Pas de connexion SSH root | <CIS 5.x / PSSI §x> | `PermitRootLogin no` (rôle Ansible ssh) | Ansible, Lynis | <fichier de preuve> | <conforme> |
| Conteneurs non-root | <PSSI §x> | PSA `restricted` et politique Kyverno | Kyverno | <fichier de preuve> | <conforme> |
| IP forwarding désactivé | <CIS 3.x> | Non appliqué : requis par Docker et Kubernetes | — | ADR NNNN | <dérogation> |

Toute dérogation renvoie vers un ADR qui la justifie et décrit sa mesure compensatoire.