« Le site répond en HTTP 200, donc l’incident est terminé. »
La disponibilité ne démontre ni l’intégrité, ni l’absence de persistance, ni la qualité de la télémétrie, ni la stabilité de la reprise.
01Définis l’état de confiance
lab=/tmp/soria-ir-final-project-$USER
column -s, -t "$lab/source/recovery/trusted-state.csv"Un actif n’est pas « sain » par défaut. Le critère doit être explicite et relié à une source de preuve.
02Teste les fonctions attendues
column -s, -t "$lab/source/recovery/recovery-tests.csv"Le corpus représente la disponibilité du service applicatif, l’authentification privilégiée contrôlée, les flux d’administration autorisés et le chemin de données.
03Surveille la récidive
column -s, -t "$lab/source/recovery/post-monitoring.csv"PASS, WATCH et NOT_TESTABLE ne sont pas interchangeables. WATCH demande une observation prolongée; NOT_TESTABLE signale une preuve encore absente.
04Refuse la clôture prématurée
column -s, -t "$lab/source/assurance/closure-criteria.csv"Plusieurs critères exigent une preuve réelle. Le cas de référence reste donc MONITORING.
Livrable D — fiche de reprise
Présente les critères de trusted state, les tests fonctionnels, la fenêtre de surveillance et les conditions qui imposeraient de rouvrir ou maintenir le cas.
✓À retenir
La reprise est une validation progressive. Le retour du service est une donnée utile, mais ce n’est pas à lui seul un critère de clôture.