Review cadence
Cadence de revue des documents de la plateforme Nex. Chaque page a un champ
last_reviewdans son frontmatter qui doit être maintenu selon les règles ci-dessous.
1. Principe
- Toute page Nex est revue au minimum tous les 90 jours, plus souvent pour les pages sensibles ou très évolutives.
- La revue est de la responsabilité de l'
owner(cf. /governance/document-ownership). - Une revue consiste à : vérifier l'exactitude, mettre à jour les sections obsolètes, rafraîchir
last_review. - Une page revue mais sans changement matériel met quand même
last_reviewà jour — ça documente qu'elle a été vue.
2. Cadence par section
| Section | Cadence cible | Justification |
|---|---|---|
/overview/ | Trimestrielle | Vue d'ensemble — doit toujours refléter l'état actuel |
/architecture/ (hors ADR) | Trimestrielle | C4, monorepo, services-catalog évoluent |
/architecture/adr/ | À l'événement | Un ADR est figé sauf décision explicite de superseder (revue annuelle de cohérence) |
/services/<service>/ | À chaque release majeure du service (ou trimestrielle) | Doit suivre les évolutions de chaque service |
/flows/ | Trimestrielle ou à chaque évolution du flow | Critique pour QA et audits |
/security/ | Mensuelle pour Known Gaps, trimestrielle pour le reste, annuelle pour ISP | Sensibilité forte |
/security/known-gaps | Mensuelle | Reflet de l'état en temps réel |
/security/information-security-policy | Annuelle + après tout incident majeur | Policy master, approuvée par direction |
/compliance/ | Trimestrielle + à chaque évolution réglementaire ou audit | Sensibilité réglementaire |
/compliance/iso-27001-soa | Trimestrielle | Suit l'avancement gap analysis |
/operations/ | Trimestrielle | Stack et procédures évoluent |
/operations/incident-response | Annuelle + après chaque incident P1/P2 | Critique en cas de crise |
/qa/ | Trimestrielle | Évolue avec le périmètre testé |
/dev/ | Semestrielle | Conventions stables |
/usage/ | Trimestrielle | Procédures CMMS évoluent |
/governance/ | Annuelle | Méta-documentation stable |
3. Pages à revue spéciale
| Page | Cadence |
|---|---|
| ISP — Information Security Policy | Annuelle (signée direction) + exceptionnelle si incident majeur |
| BCP — Business Continuity Plan | Annuelle + après chaque exercice |
| DRP — Disaster Recovery Plan | Annuelle + après chaque restauration test |
| IRP — Incident Response Plan | Annuelle + après chaque incident P1/P2 |
| SoA ISO 27001 | Trimestrielle pendant la phase de certification |
| AML/CFT program | Annuelle minimum + à chaque évolution réglementaire |
| Customer funds safeguarding | Semestrielle |
| Third-party vendors | Annuelle par vendor (cf. /compliance/third-party-vendors) |
| Data protection (RGPD) | Annuelle + à toute nouvelle finalité de traitement |
| PCI-DSS scope | Annuelle ou à tout changement produit majeur |
4. Mécanique de revue
Format suggéré
- Lecture rapide de la page.
- Vérification des claims factuels (le service mentionné existe-t-il toujours ? la version est-elle correcte ? le ticket est-il toujours ouvert ?).
- Mise à jour des sections obsolètes (ou ouverture d'une MR dédiée si effort substantiel).
- Mise à jour de
last_review: YYYY-MM-DD. - Commit avec message clair :
docs(review): refresh <chemin/page>.
Outil de suivi
Aujourd'hui : revue manuelle, suivi via last_review.
Évolutions possibles :
- Script qui liste les pages dont
last_reviewdépasse la cadence cible. - Job CI hebdomadaire qui ouvre une issue par page en retard.
- Dashboard owner → pages en retard.
5. Revue post-incident
Toute incident P1 ou P2 (cf. /operations/incident-response) déclenche :
- Revue de l'IRP dans les 14 jours suivant le RCA.
- Revue du runbook concerné si applicable.
- Revue des pages security pertinentes (Known Gaps, threat models, etc.).
6. Audit cadence
Avant un audit externe (banque, pentest, ISO), revue ciblée :
- Audit banque → priorité compliance + security + flows + operations.
- Pentest → priorité security + architecture + services + flows.
- ISO 27001 → priorité SoA + governance + security policies.
Une freeze de la documentation peut être déclenchée 1 à 2 semaines avant un audit pour stabiliser le contenu.
7. Indicateurs
- % de pages avec
last_review< cadence cible (objectif : 100 %). - Nombre de pages en draft (objectif : décroissance dans le temps).
- Délai moyen entre modification du code et mise à jour de la doc associée.