Conventions de nommage — SnakySec MSSP

Source unique de vérité pour le nommage des dossiers, fichiers, artefacts, identifiants et communications externes du projet SnakySec MSSP. Inspiré de la méthodologie blog-gestion-de-projet.com adaptée au contexte SaaS GRC multi-tenant : 220 contrôles, 50 clients potentiels, 8 docs GRC, audit log scellé Ed25519, DR Tier 2 BCMS-grade.

1. Principes fondamentaux

Principe	Règle	Justification
Date ISO 8601 universelle	`YYYY-MM-DD` (jamais DD/MM/YYYY ni MM-DD)	Tri chronologique automatique, compatible international, audit-friendly
Séparateurs hiérarchisés	Hyphen `-` pour parties d’un même élément, underscore `_` pour séparer les éléments principaux	Lecture rapide, cohérent avec l’article, compatible URL/CLI
Lowercase par défaut	Tout en minuscules sauf identifiants normés (CIS-ENTRA-x, MS.AAD.x, ISO 27001)	Évite les bugs case-sensitivity Linux/Docker, déterministe
ASCII strict	Pas d’accents, pas d’espaces, pas de caractères spéciaux dans les paths techniques	Compatibilité Linux container, S3, URL
Préfixe numérique pour ordre	`01-`, `02-` quand l’ordre de lecture compte (runbooks, IR docs)	Tri visuel naturel + cohérence sommaire
Slug client = identifiant stable	`snakysec`, `client-acme` (jamais `Client ACME` ni `acme-corporation`)	Foreign keys DB, Vault paths, S3 keys, audit log

Règle de base : un nom doit pouvoir être copié-collé dans un terminal Linux, une URL HTTPS, un path S3, et un message email sans transformation.

2. Format général d’un nom

2.1 Code (fichiers projet)

type-domain-feature.ext

Exemples :

audit-chain-worker.ts — worker BullMQ pour la chaîne audit
email-sender-worker.ts — worker email
frameworks-mappings.ts — lib mappings réglementaires
audit-diff-control-sheet.tsx — composant React Sheet

Convention Next.js / Prisma déjà en place : kebab-case pour fichiers, camelCase pour exports JS, snake_case pour colonnes DB via @@map.

2.2 Documentation (Markdown)

{ordre-numérique-optionnel}-{sujet-en-kebab-case}.md

Exemples :

00-policy.md (ordre = lecture séquentielle)
01-restore-postgres-pitr.md
iso-22301-mapping.md (sans ordre, alphabétique)
setup-notifications-app.md

2.3 Artefacts opérationnels (PV, rapports, exports)

YYYY-MM-DD_{type}_{sujet}_{client-slug}.ext

Exemples :

2026-04-26_pv-test_postgres-pitr_snakysec.md
2026-04-28_incident-report_chain-lockdown_snakysec.pdf
2026-Q1_test-restore_postgres-pitr.md (pour test trimestriel sans date précise)

Variante par client (Méthode B de l’article) quand on est dans un dossier déjà rangé par client :

{client-slug}/{type}/YYYY-MM-DD_{sujet}.ext

Exemple :

artifacts/grc/snakysec/pssi/2026-04-15_pssi-v2.docx

3. Conventions par type d’artefact

3.1 Git

Artefact	Convention	Exemple
Branche feature	`feat/{domain-en-1-2-mots}`	`feat/email-notifications`
Branche fix	`fix/{domain}-{symptom}`	`fix/audit-chain-lockdown`
Branche chore	`chore/{action}`	`chore/upgrade-prisma-7`
Branche docs	`docs/{sujet}`	`docs/dr-runbook`
Tag release	`vMAJOR.MINOR.PATCH` (SemVer)	`v0.1.0`, `v1.0.0`
Commit	Conventional Commits : `type(scope): subject`	`feat(audits): C6 — Evidence Diff UI (audit N vs N-1)`
Commit type	`feat`, `fix`, `chore`, `refactor`, `docs`, `test`, `perf`, `style`	—
Commit scope	Domaine fonctionnel : `audits`, `clients`, `audit-engine`, `dr`, `notifications`, `rbac`, `cis`, `scuba`	—
Pas de	`Co-Authored-By` (cf. CLAUDE.md), pas de signature AI	—

3.2 Code TypeScript / Next.js (platform/)

Type	Convention	Exemple
Fichier composant React	kebab-case	`audit-diff-control-sheet.tsx`
Fichier lib/util	kebab-case	`frameworks-mappings.ts`, `audit-log.ts`
Fichier page Next.js	`page.tsx`, `layout.tsx`, `loading.tsx`, `error.tsx`, `route.ts`	suit App Router
Dossier route segment	kebab-case ou `[param]`	`[id]`, `audit-log`, `client-portal`
Export const	UPPER_SNAKE_CASE pour constantes globales	`EMAIL_QUEUE_NAME`, `DEDUP_WINDOW_MS`
Export function/class	camelCase / PascalCase	`enqueueEmail`, `AuditDiffControlSheet`
Type/Interface	PascalCase	`EmailLog`, `DiffResult`, `RenderedEmail`
Test file	`*.test.ts` ou `__tests__/{name}.test.ts`	`audit-diff.test.ts`

3.3 Code PowerShell (audit engine src/)

Type	Convention	Exemple
Module	`Mssp.{Domain}.psm1` (PascalCase)	`Mssp.Graph.psm1`, `Mssp.Auth.psm1`, `Mssp.Output.psm1`
Runner	`Invoke-{Framework}Audit.ps1`	`Invoke-CISAudit.ps1`, `Invoke-SCuBAAudit.ps1`
Helper exporté	`Verb-MsspNoun` (Verb-Noun PowerShell + préfixe Mssp)	`Get-MsspAuthenticationMethodConfig`, `Test-MsspTenantHybrid`
Helper interne	`{Action}-MsspInternal{Noun}` ou minuscule sans préfixe	(selon style existant)

3.4 Prisma / DB

Type	Convention	Exemple
Model	PascalCase	`AuditRun`, `EmailLog`, `UserPermissionGrant`
Field	camelCase	`clientId`, `triggeredAt`, `unsubscribeToken`
DB column (via @@map)	snake_case	`client_id`, `triggered_at`, `unsubscribe_token`
DB table (via @@map)	snake_case pluriel	`audit_runs`, `email_logs`, `user_permission_grants`
Enum value	UPPER_SNAKE_CASE	`MSSP_ADMIN`, `SCORE_DEGRADED`, `EmailStatus.SENT`
Index	implicite Prisma, ou `@@index([col1, col2(sort: Desc)])`	—

3.5 Permissions catalog

{DOMAIN}_{ACTION}

Exemples :

AUDIT_VIEW, AUDIT_TRIGGER, AUDIT_DELETE
CLIENT_CREATE, CLIENT_UPDATE_DOMAIN, CLIENT_UPDATE_SECRETS
INTERNAL_DOCS_VIEW, INTERNAL_COVERAGE_VIEW
REMEDIATION_ACTION_CREATE, REMEDIATION_ACTION_CLOSE_WITH_EVIDENCE

Règle : verbe transitif au premier niveau (CREATE/UPDATE/DELETE/VIEW), précisions au niveau 3.

3.6 Audit log actions

{resource}.{verb}[_qualifier]

Exemples :

client.create, client.update, client.delete
audit.trigger, audit.cancel, audit.retry
email.sent, email.failed, email.unsubscribed
client.onboarding_credentials_uploaded (verb composé snake_case)

Règle : noun.verb en lowercase, dot-separated. Verbes composés en snake_case.

3.7 Frameworks JSON — Identifiants de contrôle

Framework	Format	Exemple
CIS M365 v6.0.1	`CIS-{ProductArea}-{x.x.x}` (UPPER, hyphen, dotted version)	`CIS-ENTRA-5.3.4`, `CIS-EXO-2.1.1`
CISA SCuBA v1.5.0	`MS.{ProductArea}.{x.xv1}` (PascalCase, dotted, version suffix)	`MS.AAD.3.3v2`, `MS.EXO.7.1v1`
Templates internes	`INT-{Domain}-{N}`	`INT-CISO-001` (à venir)

3.8 Vault paths

mssp/data/{scope}/{key_name}

Conventions :

Scope : platform (global), clients/<slug> (per-client), dr (backups), notifications (emails)
Key name : snake_case (auth_secret, entra_cert_pem, notifications_client_id)
Slug client : exactement le Client.slug en DB (ex: snakysec, acme-corp)

Exemples :

mssp/data/platform/auth_secret
mssp/data/clients/snakysec/entra_cert_pem
mssp/data/dr/pgbackrest_cipher_pass

3.9 Docker / Compose

Type	Convention	Exemple
Service compose	kebab-case minuscule	`next-app`, `worker-chain`, `dr-runner`
Container name	`mssp-{service}`	`mssp-app`, `mssp-postgres`, `mssp-worker-email`
Volume named	`mssp-{purpose}` ou `{service}-data`	`mssp-approle`, `postgres-data`, `vault-data`
Network	`{purpose}-net`	`mssp-net` (services communiquent), `data-net` (internal DB)
Image registry	`registry.gitlab.com/snakysec/mssp-snakysec-multi-tenants/{component}:vX.Y.Z`	—

3.10 Email templates

{category}_{trigger}

Exemples :

alert_score_degraded, alert_new_critical_finding, alert_deadline_approaching
onboarding_credentials_uploaded, onboarding_completed
dr_chain_lockdown, dr_backup_failure
digest_monthly

Règle : snake_case, category puis trigger. Pour tester : un nouveau dev doit deviner le contexte rien qu’au nom.

3.11 Email subjects (communications externes)

[{Brand}{ Sub-context}] {Sujet humain}

Exemples :

[SnakySec] Score de conformité dégradé — Acme Corp
[SnakySec DR] Verrouillage chaîne audit log déclenché
[SnakySec MSSP] Pré-notification incident — 2026-04-28T16:32 UTC
[SnakySec smoke test] Graph SendMail end-to-end

Règle : préfixe identifiant bracketé pour filtrage Outlook/Gmail, sujet humain en français.

4. Artefacts opérationnels (PV, rapports, communications)

4.1 Procès-verbaux de tests DR (Tier 2 BCMS)

docs/dr/test-results/YYYY-{Q|MM}-{type-test}.md

Exemples :

docs/dr/test-results/2026-Q1-postgres-pitr.md
docs/dr/test-results/2026-Q3-shamir-rotation.md
docs/dr/test-results/2026-04-monthly-smoke.md

4.2 Post-incident reports

docs/dr/test-results/YYYY-MM-DD-incident-{type-court}.md

Exemples :

docs/dr/test-results/2026-04-28-incident-chain-lockdown.md
docs/dr/test-results/2026-Q4-incident-blanc-ransomware.md (exercice annuel)

4.3 Documents GRC générés (livrables client)

artifacts/grc/{client-slug}/{doc-type}/YYYY-MM-DD_{doc-type}_v{version}.{docx|pdf}

Exemples :

artifacts/grc/snakysec/pssi/2026-04-15_pssi_v2.docx
artifacts/grc/acme-corp/charte-it/2026-03-01_charte-it_v1.pdf

8 types autorisés (cf. platform/src/lib/grc/) :

pssi, access-policy, incident-procedure, remediation-plan, data-classification, breach-notification, it-charter, processing-register

4.4 Audits artifacts JSON

artifacts/audit/{client-slug}/{run-id}/{framework}-{product-area}.json

Exemples :

artifacts/audit/snakysec/cmoiugsnm00014zrnzjaznzk2/cis-entra.json
artifacts/audit/snakysec/cmoiugsnm00014zrnzjaznzk2/scuba-aad.json

Le run-id est le AuditRun.id Prisma (cuid, format cm{...}).

4.5 Backups DR

Type	Convention
pgbackrest	géré natif par pgbackrest, format `{stanza}-{timestamp}I/D/F`
Vault snapshot restic	tags `vault-snapshot` + `run={DR_RUN_ID}`
Artifacts restic	tags `artifacts` + `run={DR_RUN_ID}`
DNS zone export	`artifacts/dns-zones/snakysec.com.YYYY-MM.bind`
Pre-restore snapshot	`/opt/mssp/snapshots/pre-restore-YYYYMMDDTHHMMSSZ.tar.gz`

4.6 Plans projet (~/.claude/plans/)

{slug-court}.md (plan actif)
archive/{slug-court}.md (plan exécuté)

Exemples :

~/.claude/plans/jazzy-sauteeing-babbage.md (master plan V1, actif)
~/.claude/plans/archive/dr-runbook.md (exécuté, archivé)
~/.claude/plans/archive/permissions-granular.md (exécuté)

Règle : nom court, descriptif. Pas de date dans le nom (le plan suit le projet, pas un événement).

5. Lexique projet (abréviations autorisées)

Abréviation	Signification	Contexte
ACP	Application Access Policy	M365 Exchange Online
BIA	Business Impact Analysis	DR / BCMS
CA	Conditional Access	Entra ID
CMMI	Capability Maturity Model Integration	Maturité contrôles
DICT	Disponibilité / Intégrité / Confidentialité / Traçabilité	ANSSI framework
DPA	Data Processing Agreement	Sous-traitance RGPD
DR	Disaster Recovery	Continuité d’activité
FP	Faux Positif	Audit engine
GA	Global Administrator	Entra ID rôle
IR	Incident Response	DR
MSSP	Managed Security Service Provider	Modèle commercial
MTPD	Maximum Tolerable Period of Disruption	BCMS
MTTR	Mean Time To Resolve	KPI ops
PCA	Plan de Continuité d’Activité	DR
PIM	Privileged Identity Management	Entra ID
PIR	Post-Incident Report	DR / IR
PRA	Plan de Reprise d’Activité	DR
PSSI	Politique de Sécurité du Système d’Information	Doc GRC
RPO	Recovery Point Objective	BCMS
RTO	Recovery Time Objective	BCMS
SPN	Service Principal Name	Entra ID
WRT	Work Recovery Time	BCMS

Règle : avant d’introduire une nouvelle abréviation, l’ajouter ici. Si elle n’est pas évidente pour un dev rejoignant l’équipe, prévoir un glossaire docs/GLOSSARY.md (à venir).

6. Caractères interdits / à éviter

6.1 Interdits dans les paths techniques

Caractère	Pourquoi
Espaces	Casse les commandes shell, URL, S3 keys
Accents `é à ç ù`	Encoding inconsistant Linux/Windows
Caractères spéciaux `! @ # $ % & * ( ) [ ] { } < > ? "`	Caractères shell réservés ou problématiques URL
Apostrophe `'`	Casse les chaînes SQL et bash
Slash inversé `\`	Spécifique Windows, casse cross-platform
Deux-points `:`	Drive Windows + sépare host:port URL
Points multiples `..`	Path traversal possible

6.2 À éviter dans la documentation et les communications

Pratique	À éviter	Préférer
Dates européennes	`27/04/2026`	`2026-04-27`
Casing aléatoire	`MyDocument.PDF`	`mon-document.pdf` ou `MON_DOCUMENT.pdf`
Articles redondants	`le-rapport-de-la-securite`	`rapport-securite`
Versions implicites	`rapport-final.pdf`	`rapport-final-v3.pdf` ou `rapport_2026-04-27.pdf`
Initiales sans contexte	`JS-rapport.docx`	`2026-04-27_rapport_jean-sevre.docx`

7. Hiérarchie recommandée — Arbre projet

mssp-snakysec-multi-tenants/
├── src/                          # Audit engine PowerShell
│   ├── frameworks/
│   │   ├── cis/{product-area}.json
│   │   └── scuba/{product-area}.json
│   ├── modules/Mssp.{Domain}.psm1
│   └── runners/Invoke-{Framework}Audit.ps1
│
├── platform/                     # SaaS Next.js
│   ├── src/
│   │   ├── app/dashboard/        # routes UI
│   │   ├── app/api/v1/           # routes API versionnées
│   │   ├── components/{domain}/  # composants par domaine
│   │   ├── lib/{domain}/         # libs par domaine
│   │   └── jobs/{name}-worker.ts # workers BullMQ
│   ├── prisma/schema.prisma
│   ├── compose/{service}.{env}.yml
│   └── docker/{service}/
│
├── clients/{client-slug}/        # Configurations per-client
│   └── client.config.json
│
├── artifacts/                    # Outputs runtime (gitignored partiel)
│   ├── audit/{client-slug}/{run-id}/
│   ├── grc/{client-slug}/{doc-type}/
│   └── dns-zones/{domain}.YYYY-MM.bind
│
├── docs/                         # Documentation projet
│   ├── dr/{NN-policy.md, runbooks/, incident-response/, compliance/, templates/, test-results/}
│   ├── runbooks/                 # Runbooks ops (hors DR)
│   ├── adr/{NNN-decision.md}
│   ├── tracking/V1-Q2-2026-roadmap.xlsx
│   └── {SECURITY.md, LOGGING.md, NAMING-CONVENTIONS.md, ...}
│
├── pipelines/                    # GitLab CI
│   └── {pipeline-name}.yml
│
└── scripts/                      # Scripts ops
    ├── dr/{lib/, backup/, restore/, verify/, setup/}
    └── setup/{name}.sh

Règle : la profondeur doit refléter la séparation de responsabilités, pas une nostalgie organisationnelle. Maximum 4 niveaux à partir de la racine.

8. Auto-vérification — Checklist avant commit

Avant chaque commit, vérifier :

Date : si présente, format YYYY-MM-DD
Casing : kebab-case pour les fichiers, snake_case pour DB, UPPER_SNAKE pour enums et permissions
Pas d’espaces ni d’accents dans les paths
Slug client identique partout (DB, Vault, S3, paths)
Préfixe identifié pour le type d’artefact (NN-pour ordre, type pour catégorie)
Identifiant normé pour CIS / SCuBA respecté (UPPER pour CIS, PascalCase.dotted pour SCuBA)
Lexique consulté pour abréviations
Conventional commits pour le message git

9. Maintenance du document

Ce document est versionné Git. Toute évolution :

Pull request explicite avec exemples avant/après
Si breaking change (ex: renommage d’un type d’artefact existant) : créer un script de migration + entrée dans docs/adr/ documentant le pourquoi
Mettre à jour docs/GLOSSARY.md si nouvelle abréviation introduite

Version	Date	Auteur
1.0	2026-04-28	Nicolas Schiffgens

10. Références

blog-gestion-de-projet.com — Règles de nommage — méthodologie générale
Conventional Commits — format commits
SemVer — versioning releases
ISO 8601 — dates
docs/SECURITY.md — DICT framework + threat model
docs/dr/ — DR Runbook (référence pour artefacts opérationnels)

11. Taxonomie complète des documents projet

5 grandes catégories couvrant l’intégralité des documents non-code du projet SnakySec MSSP. Chaque catégorie a son arborescence, ses conventions de nommage spécifiques, son cycle de vie et sa politique de rétention.

11.1 Vue d’ensemble — Arbre `docs/` cible

docs/
├── legal/                        # 11.2 — Documents juridiques contractuels
│   ├── statuts/                  # Statuts SASU + procès-verbaux notariés
│   ├── cgu-cgv/                  # CGU, CGV B2B, mentions légales
│   ├── dpa-rgpd/                 # Data Processing Agreements clients
│   ├── nda/                      # Accords de confidentialité
│   ├── contrats-clients/         # Contrats signés (1 dossier par client)
│   ├── assurance/                # Polices Stoik, attestations RC pro
│   └── registres/                # Registre traitements RGPD, registre violations
│
├── compliance/                   # 11.3 — Conformité réglementaire (top-level)
│   ├── certifications/           # ISO 27001, SecNumCloud, ExpertCyber
│   ├── attestations/             # Attestations clients (livrables RFP)
│   ├── audits-externes/          # Pentest reports, audits ISO, etc.
│   ├── notifications/            # Notifications CSIRT-FR, CNIL passées
│   └── auto-evaluations/         # Self-assessments NIS2 / RGPD / SecNumCloud
│
├── risks/                        # 11.4 — Gestion des risques
│   ├── threat-models/            # Threat models par composant
│   ├── risk-register/            # Registre des risques + plans de mitigation
│   ├── bia/                      # Business Impact Analysis (référence DR)
│   └── pca-pra/                  # Renvoi vers docs/dr/ + index
│
├── tech/                         # 11.5 — Documentation technique (existant + nouveau)
│   ├── architecture.md           # (existant — racine docs/, à migrer)
│   ├── api/                      # OpenAPI specs / contrats API
│   ├── deps/                     # Dépendances + supply chain SBOM
│   ├── performance/              # Baselines + load tests
│   ├── observability/            # OBSERVABILITY.md, LOGGING.md (existants)
│   └── security/                 # SECURITY.md (existant)
│
├── project/                      # 11.6 — Gestion de projet
│   ├── plans/                    # Plans actifs (master + sprints)
│   ├── retros/                   # Retros sprint / mensuelles / trimestrielles
│   ├── decisions/                # Decision logs (autres que ADR technique)
│   ├── roadmap/                  # Roadmaps versionnées + tracking XLSX
│   └── state-reports/            # Status reports périodiques (clients, board)
│
├── adr/                          # (existant) — ADR technique uniquement
├── dr/                           # (existant) — DR runbook BCMS-grade
├── runbooks/                     # (existant) — Runbooks ops
├── tracking/                     # (existant) — XLSX pilotage projet
└── NAMING-CONVENTIONS.md         # (ce document)

Règle de migration : ne pas casser l’existant. Les docs déjà en place restent à leur emplacement actuel, on ajoute uniquement les nouveaux dossiers quand un premier document de la catégorie arrive. Migration éventuelle au cas par cas via PR documentée.

11.2 Légal — `docs/legal/`

Périmètre : tout document contractuel, statutaire, ou émanant d’un notaire / avocat / assureur. Diffusion restreinte (DR Owner + mandataire SASU + tiers concernés).

Sous-dossier	Convention	Exemple
`statuts/`	`YYYY-MM-DD_statuts-{nature}_v{N}.pdf`	`2026-05-15_statuts-sasu-snakysec_v1.pdf`, `2026-05-15_pv-deposit-shamir_notaire-{etude}.pdf`
`cgu-cgv/`	`YYYY-MM-DD_cgu_v{N}.pdf`	`2026-04-28_cgu-saas_v1.pdf`, `2026-04-28_cgv-b2b_v1.pdf`
`dpa-rgpd/`	`{client-slug}_dpa_v{N}_YYYY-MM-DD.pdf`	`acme-corp_dpa_v1_2026-05-12.pdf`
`nda/`	`{partie}_nda-{type}_YYYY-MM-DD.pdf`	`vaadata_nda-mutual_2026-06-15.pdf`
`contrats-clients/{client-slug}/`	`YYYY-MM-DD_contrat-{type}_v{N}.pdf`	`acme-corp/2026-05-20_contrat-saas-mssp_v1.pdf`
`assurance/`	`{assureur}_{police}_{periode}.pdf`	`stoik_rc-pro-cyber_2026-2027.pdf`
`registres/`	`registre-{type}_{periode}.{md\|xlsx}`	`registre-traitements-rgpd_2026.xlsx`, `registre-violations-rgpd_2026.md`

Lifecycle : draft → review (avocat / notaire) → signed → archived Versioning : v1, v2 pour les contrats. Préserver toutes les versions signées (pas écraser un PDF signé). Les drafts vivent dans une sous-arbo drafts/{nom}_draft.docx et disparaissent une fois signés. Rétention : 10 ans minimum (obligation comptable + prescription contractuelle française), sauf NDAs (rétention pendant durée NDA + 5 ans). Sécurité :

Aucun contrat client en plaintext dans Git (chiffrer ou stocker hors-repo)
Si dans Git : *.pdf OK pour CGU/CGV (publics) ; pour les contrats clients, chiffrer via Vault transit ou git-crypt
Backup obligatoire dans le DR pipeline (cf. §4.5 backups)

11.3 Conformité — `docs/compliance/`

Périmètre : tout document attestant d’une conformité (audit externe, certification, notif réglementaire). Diffusion contrôlée (publication RFP avec NDA pour les rapports complets, résumé public OK).

Sous-dossier	Convention	Exemple
`certifications/`	`{norme}_{niveau}_{periode}.pdf`	`iso-27001_certificat_2027-2030.pdf`, `expertcyber_label_2026.pdf`
`attestations/`	`{type}_{client-slug-ou-public}_YYYY-MM-DD.pdf`	`attestation-conformite_acme-corp_2026-06-30.pdf`, `attestation-securite_public_2026-Q2.pdf`
`audits-externes/{prestataire}/`	`YYYY-MM-DD_{type}_{scope}.pdf`	`vaadata/2026-09-15_pentest_platform.pdf`, `iso-auditor/2027-Q1_audit-iso27001_full.pdf`
`notifications/`	`YYYY-MM-DD_{autorite}_{type}_{ref}.{md\|pdf}`	`2026-04-28_csirt-fr_pre-notif_AVI-2026-001.md`, `2026-04-28_cnil_breach_REF12345.pdf`
`auto-evaluations/`	`auto-eval_{norme}_YYYY-MM-DD_v{N}.{md\|xlsx}`	`auto-eval_nis2_2026-04-28_v1.md`, `auto-eval_secnumcloud_2026-Q1_v1.xlsx`

Lifecycle : pending → submitted → received-confirmation → expired-or-renewed Pour les notifications :

Pré-notif → notif complète → rapport intermédiaire J+30 → rapport final J+90 → tous archivés ensemble dans notifications/{ref-incident}/
Référence interne : INC-YYYY-NNN (cf. template post-incident report)

Rétention :

Certifications + attestations : durée validité + 3 ans (audit trail)
Audits externes : 5 ans minimum
Notifications CSIRT-FR / CNIL : 10 ans (obligation traçabilité incident)
Auto-évaluations : 3 ans (révision annuelle attendue)

Liens vers existing :

docs/dr/compliance/ couvre les mappings (qui couvre quoi) — distinct des certifications obtenues. Les deux sont complémentaires : mapping = ce qu’on prétend couvrir, certificat = ce qu’on a fait valider.

11.4 Risques — `docs/risks/`

Périmètre : threat models, risk register, BIA. Doc interne (DR Owner + DPO Phase 1+).

Sous-dossier	Convention	Exemple
`threat-models/`	`threat-model_{composant}_v{N}.md`	`threat-model_audit-engine_v2.md`, `threat-model_notifications_v1.md`
`risk-register/`	`risk-register_YYYY-Q{N}.{md\|xlsx}`	`risk-register_2026-Q2.md`
`bia/`	`bia_{scope}_YYYY-MM-DD.md`	`bia_platform_2026-04-26.md` (référencé par `dr/02-asset-inventory.md`)
`pca-pra/index.md`	Index pointant vers `dr/00-policy.md`	(1 fichier, juste un renvoi)

Lifecycle threat model : draft → reviewed → approved → updated-on-arch-change Mise à jour obligatoire à chaque :

Nouveau composant majeur (worker, page, intégration)
Nouveau flux externe (API, webhook)
Incident réel (post-incident → leçons → mise à jour modèle)

Risk register : actualisé trimestriellement, format tabulaire :

| ID risque | Description | Probabilité (1-5) | Impact (1-5) | Score | Mitigation actuelle | Mitigation cible | Owner | Date revue |

ID format : R-YYYY-NNN (R-2026-001, R-2026-002, …). Rétention : 5 ans minimum. Les risques mitigés ne sont pas supprimés — ils passent en statut closed avec date + référence preuve.

11.5 Technique — `docs/tech/`

Périmètre : doc d’architecture, contrats d’API, dépendances, performance, observabilité, sécurité. Doc team interne + extracts publiables en RFP (résumé architecture).

Sous-dossier	Convention	Exemple
`architecture.md`	(déjà à `docs/architecture.md`, à migrer)	`docs/tech/architecture.md`
`api/`	`{service}_v{majeur}_openapi.yaml`	`platform_v1_openapi.yaml`, `audit-engine-cli_v3_schema.json`
`deps/`	`sbom_{date}.{json\|xml}`	`sbom_2026-04-28.json` (généré automatiquement par `npm audit` ou syft)
`performance/`	`baseline_{scenario}_YYYY-MM-DD.md`	`baseline_audit-trigger-cis-entra_2026-04-28.md`
`observability/`	(déjà à `docs/OBSERVABILITY.md`, `docs/LOGGING.md`)	`docs/tech/observability/`
`security/SECURITY.md`	(déjà à `docs/SECURITY.md`)	`docs/tech/security/SECURITY.md`

Convention ADR (déjà active dans docs/adr/) :

NNN-{decision-courte-en-kebab-case}.md

Exemples existants : 001-bullmq-vs-pg-queues.md, 002-vault-runtime-secrets.md. Lifecycle ADR : proposed → accepted → superseded-by-NNN (jamais supprimer un ADR — superseded reste référencé). Versioning API : SemVer dans le nom du fichier (v1, v2). Breaking changes impliquent nouvelle version, anciennes versions conservées tant qu’elles sont supportées contractuellement. Rétention : ADR = à vie (preuve historique des décisions). Baselines performance = 2 ans (référence régression). SBOM = 5 ans (chaîne fournisseur).

11.6 Gestion de projet — `docs/project/`

Périmètre : plans, retros, decision logs (non-techniques), roadmaps, status reports. Doc interne + parts publiables côté board / investisseurs.

Sous-dossier	Convention	Exemple
`plans/`	`{slug-court}_v{N}.md` (plans actifs) ou archive (plans exécutés)	`master-plan-v1-q2-2026_v3.md`
`retros/`	`retro_{periode}_YYYY-MM-DD.md`	`retro_sprint-23_2026-04-28.md`, `retro_q2-2026_2026-06-30.md`
`decisions/`	`DEC-NNN_{slug-court}_YYYY-MM-DD.md`	`DEC-001_pivot-icp-pme-france_2026-03-15.md`
`roadmap/`	`roadmap_{periode}_v{N}.{md\|xlsx}`	`roadmap_v1-q2-2026_v4.xlsx` (déjà partiellement à `docs/tracking/`)
`state-reports/{audience}/`	`state-report_{audience}_YYYY-MM-DD.md`	`board/state-report_board_2026-04-30.md`, `clients/state-report_clients_2026-Q2.md`

Convention plans :

Plans en cours : {slug-court}.md (ex: master-plan-v1.md)
Plans archivés : déplacer vers archive/ avec date complétion : archive/{slug-court}_completed-YYYY-MM-DD.md
Pour SnakySec, les plans Claude Code sont à ~/.claude/plans/ (hors repo, scope outil dev)

Decision logs (DEC-NNN) distincts des ADR :

ADR = décision technique (architecture, pattern, lib)
DEC = décision business / produit / projet (pivot, pricing, GTM)

Format DEC :

# DEC-NNN : Titre court

**Date** : YYYY-MM-DD
**Statut** : proposée / acceptée / révisée par DEC-XXX
**Décideur** : Nicolas Schiffgens

## Contexte
## Options envisagées
## Décision
## Conséquences (positives + négatives)
## Plan de revue (date)

Status reports périodiques :

Mensuel interne : state-report_internal_YYYY-MM.md (KPIs MRR, chantiers, dette)
Trimestriel client : state-report_client_{slug}_YYYY-Q{N}.pdf (livrable contractuel)
Trimestriel board (Phase 1+) : state-report_board_YYYY-Q{N}.pdf

Rétention : plans + retros + decisions à vie (continuité historique projet). State reports : 3 ans minimum.

11.7 Plan de migration vers la taxonomie complète

Phase 1 — État actuel (V1) :

Existant conservé : dr/, runbooks/, adr/, tracking/, architecture.md, SECURITY.md, LOGGING.md, OBSERVABILITY.md
Pas de migration de fichiers existants (risque de casser les liens dans la doc)

Phase 2 — V1 + 1er client (legal/ activé) :

Création docs/legal/ avec premiers contrats signés
Souscription Stoik → legal/assurance/stoik_rc-pro-cyber_2026-2027.pdf
DPA template prêt → legal/dpa-rgpd/template_dpa_v1.docx
Statuts SASU déposés → legal/statuts/2026-MM-DD_statuts-sasu_v1.pdf

Phase 3 — Pentest + DPO (compliance/audits-externes/ activé) :

1er pentest annuel → rapport dans compliance/audits-externes/{prestataire}/
Auto-évaluations formalisées dans compliance/auto-evaluations/

Phase 4 — ISO 27001 démarche (compliance/certifications/) :

Documents préparation
Audit certification → certificat signé archivé

Phase 5 — Cabinet RP / board (project/state-reports/) :

Rapports trimestriels formalisés

À chaque activation d’une nouvelle catégorie : créer un README.md dans le sous-dossier expliquant le périmètre + lifecycle + rétention.

11.8 Synthèse — table de correspondance par cas d’usage

Tu cherches…	Va dans…
Statuts SASU + clauses succession	`docs/legal/statuts/`
CGU plateforme	`docs/legal/cgu-cgv/`
DPA RGPD signé avec un client	`docs/legal/dpa-rgpd/`
Contrat MSSP signé avec Acme Corp	`docs/legal/contrats-clients/acme-corp/`
Contrat assurance cyber Stoik	`docs/legal/assurance/`
Registre RGPD violations	`docs/legal/registres/`
Certificat ISO 27001 (Phase 2+)	`docs/compliance/certifications/`
Attestation conformité produite pour un client	`docs/compliance/attestations/`
Rapport pentest Vaadata 2026	`docs/compliance/audits-externes/vaadata/`
Pré-notification CSIRT-FR sur un incident	`docs/compliance/notifications/`
Auto-évaluation NIS2 trimestrielle	`docs/compliance/auto-evaluations/`
Threat model audit-engine	`docs/risks/threat-models/`
Registre des risques Q2 2026	`docs/risks/risk-register/`
BIA plateforme	`docs/risks/bia/` (référencé par `dr/02-asset-inventory.md`)
ADR technique (BullMQ, Vault, etc.)	`docs/adr/`
Architecture générale	`docs/architecture.md` (futur : `docs/tech/architecture.md`)
Threat model + DICT	`docs/SECURITY.md`
Logging + observability	`docs/LOGGING.md`, `docs/OBSERVABILITY.md`
DR Runbook complet	`docs/dr/`
Runbook ops (audit failure, key rotation)	`docs/runbooks/`
Master plan V1	`~/.claude/plans/jazzy-sauteeing-babbage.md` (hors repo) ou `docs/project/plans/`
Retros sprint	`docs/project/retros/`
Decision business (pivot, pricing)	`docs/project/decisions/DEC-NNN_*.md`
Roadmap XLSX V1	`docs/tracking/V1-Q2-2026-roadmap.xlsx` (futur : `docs/project/roadmap/`)
Status report mensuel	`docs/project/state-reports/internal/`

12. Rétention globale — Tableau de synthèse

Catégorie	Rétention min	Justification
Code (Git history)	À vie	Audit trail + git blame forensic
Audits clients (DB ControlResult)	12 mois roll	Decision Q1 chantier 1 (rétention worker)
Audit log scellé Ed25519	À vie	Intégrité chaîne, jamais purger
EmailLog SENT/DRY_RUN	90 jours	Cf. retention-worker B.S2
EmailLog FAILED	365 jours	Forensic incident
Backups DR (pgbackrest WAL)	~3 mois (12 archives)	Cf. dr/03-backup-strategy.md
Backups DR (vault snapshots restic)	30 derniers	Idem
Backups DR (artifacts restic)	90 jours	Idem
Plans projet actifs	À vie	Continuité projet
Plans archivés	À vie	Référence historique
Threat models	5 ans après dernière révision	Audit ANSSI / ISO
Risk register	5 ans	Idem
ADR	À vie	Trace décisions techniques
Decisions business (DEC)	À vie	Trace décisions stratégiques
Statuts SASU	À vie + 30 ans après dissolution	Obligation légale française
CGU/CGV en cours	À vie + version actuelle accessible	Preuve contractuelle
DPA signés clients	Durée contrat + 5 ans	Prescription RGPD art. 32 + obligation art. 28
Contrats clients signés	Durée contrat + 10 ans	Prescription commerciale FR (art. L110-4 C. com.)
NDAs	Durée NDA + 5 ans	Idem
Polices d’assurance	10 ans après expiration	Prescription civile
Registres RGPD (traitements + violations)	10 ans	Obligation CNIL
Notifications CSIRT-FR / CNIL	10 ans	Audit trail incident
Certificats / attestations	Durée validité + 3 ans	Audit successeur
Audits externes (pentest)	5 ans	Audit trail sécurité
Auto-évaluations	3 ans	Cycle revue
Status reports	3 ans (interne) / durée contrat (client)	Audit trail projet
Procès-verbaux tests DR	À vie + 10 ans	Tier 2 BCMS preuve
PIR (post-incident reports)	10 ans	Obligation NIS2 (cascade) + RGPD

Règle générale : en cas de doute, conserver. Le coût de conservation (stockage chiffré) est négligeable face au coût d’absence en cas d’audit / contentieux.

13. Templates par catégorie (à créer Phase 2)

À déposer dans chaque sous-dossier au moment de son activation :

docs/legal/dpa-rgpd/_template_dpa.docx
docs/legal/cgu-cgv/_template_cgu-saas.md
docs/legal/registres/_template_registre-violations.md
docs/compliance/notifications/_template_csirt-pre-notif.md (existe déjà dans dr/incident-response/02)
docs/risks/threat-models/_template_threat-model.md
docs/risks/risk-register/_template_risk-register.xlsx
docs/project/decisions/_template_DEC.md
docs/project/retros/_template_retro.md
docs/project/state-reports/_template_state-report.md

Convention template : préfixe _ (sort en haut de l’arborescence) + suffixe _template. À copier-renommer pour chaque nouvelle instance.

Get Started

Conventions

Architecture Decisions (ADR)

Catalogs & Mappings

Operations

Project

Documentation Index

​Conventions de nommage — SnakySec MSSP

​1. Principes fondamentaux

​2. Format général d’un nom

​2.1 Code (fichiers projet)

​2.2 Documentation (Markdown)

​2.3 Artefacts opérationnels (PV, rapports, exports)

​3. Conventions par type d’artefact

​3.1 Git

​3.2 Code TypeScript / Next.js (platform/)

​3.3 Code PowerShell (audit engine src/)

​3.4 Prisma / DB

​3.5 Permissions catalog

​3.6 Audit log actions

​3.7 Frameworks JSON — Identifiants de contrôle

​3.8 Vault paths

​3.9 Docker / Compose

​3.10 Email templates

​3.11 Email subjects (communications externes)

​4. Artefacts opérationnels (PV, rapports, communications)

​4.1 Procès-verbaux de tests DR (Tier 2 BCMS)

​4.2 Post-incident reports

​4.3 Documents GRC générés (livrables client)

​4.4 Audits artifacts JSON

​4.5 Backups DR

​4.6 Plans projet (~/.claude/plans/)

​5. Lexique projet (abréviations autorisées)

​6. Caractères interdits / à éviter

​6.1 Interdits dans les paths techniques

​6.2 À éviter dans la documentation et les communications

​7. Hiérarchie recommandée — Arbre projet

​8. Auto-vérification — Checklist avant commit

​9. Maintenance du document

​10. Références

​11. Taxonomie complète des documents projet

​11.1 Vue d’ensemble — Arbre docs/ cible

​11.2 Légal — docs/legal/

​11.3 Conformité — docs/compliance/

​11.4 Risques — docs/risks/

​11.5 Technique — docs/tech/

​11.6 Gestion de projet — docs/project/

​11.7 Plan de migration vers la taxonomie complète

​11.8 Synthèse — table de correspondance par cas d’usage

​12. Rétention globale — Tableau de synthèse

​13. Templates par catégorie (à créer Phase 2)

Conventions de nommage — SnakySec MSSP

1. Principes fondamentaux

2. Format général d’un nom

2.1 Code (fichiers projet)

2.2 Documentation (Markdown)

2.3 Artefacts opérationnels (PV, rapports, exports)

3. Conventions par type d’artefact

3.1 Git

3.2 Code TypeScript / Next.js (platform/)

3.3 Code PowerShell (audit engine src/)

3.4 Prisma / DB

3.5 Permissions catalog

3.6 Audit log actions

3.7 Frameworks JSON — Identifiants de contrôle

3.8 Vault paths

3.9 Docker / Compose

3.10 Email templates

3.11 Email subjects (communications externes)

4. Artefacts opérationnels (PV, rapports, communications)

4.1 Procès-verbaux de tests DR (Tier 2 BCMS)

4.2 Post-incident reports

4.3 Documents GRC générés (livrables client)

4.4 Audits artifacts JSON

4.5 Backups DR

4.6 Plans projet (~/.claude/plans/)

5. Lexique projet (abréviations autorisées)

6. Caractères interdits / à éviter

6.1 Interdits dans les paths techniques

6.2 À éviter dans la documentation et les communications

7. Hiérarchie recommandée — Arbre projet

8. Auto-vérification — Checklist avant commit

9. Maintenance du document

10. Références

11. Taxonomie complète des documents projet

11.1 Vue d’ensemble — Arbre `docs/` cible

11.2 Légal — `docs/legal/`

11.3 Conformité — `docs/compliance/`

11.4 Risques — `docs/risks/`

11.5 Technique — `docs/tech/`

11.6 Gestion de projet — `docs/project/`

11.7 Plan de migration vers la taxonomie complète

11.8 Synthèse — table de correspondance par cas d’usage

12. Rétention globale — Tableau de synthèse

13. Templates par catégorie (à créer Phase 2)