PROJECT VISION

PROJECT VISION — SnakySec MSSP

Document de vision projet pour audit UX externe. Source : CLAUDE.md, docs/architecture.md, docs/project-state.md, docs/SECURITY.md, docs/competitive-analysis-2026.md, docs/roadmap-2026-Q2.md. Dernière compilation : 2026-04-28.

---

1. Vision produit

1.1 Positionnement

SnakySec MSSP est une plateforme SaaS GRC multi-tenant pour fournir un service managé de conformité Microsoft 365 clé-en-main aux PME. La plateforme combine :

• Audit : 220 contrôles automatisés (CIS M365 v6.0.1 — 140 contrôles + CISA SCuBA v1.5.0 — 94 contrôles) couvrant 6 zones M365 (Entra ID, Exchange Online, Teams, SharePoint, Defender, Purview).
• GRC documentaire : 8 documents générés à partir des résultats d’audit (PSSI, Charte Informatique, Procédure Incident, Plan de Remédiation, Politique de Classification, Notification de Violation, Politique d’Accès, Registre des Traitements). Méthodologies ANSSI / SecNumCloud / EBIOS.
• vCISO assistance : pilotage de la trajectoire conformité (CMMI 1-5), priorisation par DICT (Disponibilité · Intégrité · Confidentialité · Traçabilité — modèle ANSSI), suivi des jalons (Milestones), preuves opposables (rapports certifiés Ed25519).
• Portail client white-label : visibilité read-only pour le client final sur sa posture, ses findings, son plan de remédiation, ses documents.

Inspiration concurrentielle : CoreView ONE (positionnement entreprise) — SnakySec se positionne 1 cran en dessous, sur la PME française régulée NIS2 sans cellule cyber interne. Cf. docs/competitive-analysis-2026.md section 11.

1.2 Cible utilisateur — personas

Persona 1 — MSSP Operator (utilisateur principal de la plateforme)

• Profil : expert cyber MSSP (consultant senior, vCISO externalisé, RSSI mutualisé). Connait Graph API, sait lire un JSON d’audit, gère 5 à 30 tenants clients en parallèle.
• Quotidien : déclencher des audits, qualifier les findings, produire les rapports clients, faire vivre le plan de remédiation, livrer les documents GRC, justifier la facturation par des KPIs lisibles.
• Niveau technique : élevé (PowerShell, M365, ANSSI, ISO 27001).
• Contexte solo founder : Nicolas Schiffgens (fondateur SnakySec) est aujourd’hui l’unique opérateur. La plateforme doit absorber la charge cognitive d’un MSSP solo qui scale.

Persona 2 — Client final PME (utilisateur du portail)

• Profil : DSI / Office Manager / Dirigeant d’une PME 20-250 personnes. Régulé NIS2 (10 000 à 15 000 entités françaises nouvellement régulées), assurance cyber qui exige des preuves d’audit, secteur exposé (santé, industrie, services).
• Quotidien : aucun. La PME ne se connecte que ponctuellement — quand l’assurance demande un rapport, quand un commercial demande “êtes-vous conforme”, quand le RSSI mutualisé a alerté sur une dégradation.
• Niveau technique : très faible. Ne sait pas ce qu’est une CA policy, ne lit pas un JSON, voit un score “78%” et veut comprendre s’il doit s’inquiéter.
• Demande implicite : “rassure-moi” + “donne-moi un PDF que je peux montrer à mon assureur ou mon comité de direction”.

Persona 3 — Analyste / Consultant tiers (futur)

• Profil : analyste salarié d’un MSSP partenaire, consultant freelance qui audite des sous-traitants. Accès ANALYST dans la plateforme (read + reviewer workflow, pas d’admin global).
• Quotidien : revue manuelle des contrôles non automatisables (manual review workflow), qualification de findings, rédaction de notes de revue.
• Note V1 : ce persona n’est pas encore activement utilisé (équipe = 1 personne). L’infrastructure RBAC est en place pour le scaler dès le 1er recrutement.

1.3 Valeur principale pour l’utilisateur

Pour le MSSP Operator

• Industrialisation : 1 click Trigger Audit → 220 contrôles évalués → résultats en DB → rapport PDF + 8 documents GRC générés.
• Traçabilité opposable : audit log scellé par chaîne de hash + signature Ed25519 (eIDAS-ready). Permet de défendre une décision de conformité face à un auditeur, un assureur, un expert judiciaire.
• Multi-tenant natif : 1 tenant = 1 client = 1 sous-domaine custom (white-label) → SSO Entra ID résolu par hostname.
• Pré-flight permissions + faux positifs minimisés : limite le coût opérationnel des “et là, pourquoi ce contrôle est rouge ?”.

Pour le client PME

• Conformité comme service : aucun outil à installer côté client. Cert X.509 dans son tenant Entra → la plateforme audit en push. Zero ops.
• Documents prêts pour assurance + NIS2 : PSSI personnalisée, charte IT opposable juridiquement (signature collaborateur), registre RGPD.
• Lecture exécutive : score % + jauge DICT + top 5 critiques + remediation guide PDF avec étapes pas-à-pas.

---

2. Architecture fonctionnelle

2.1 Features implémentées (V1, ~95% complet — état 2026-04)

Audit Engine (PowerShell)

• ✅ 220 contrôles évalués (CIS M365 v6.0.1 + CISA SCuBA v1.5.0) — 87% automatisés, 13% manual review documenté.
• ✅ 6 product areas — Entra ID · Exchange Online · Teams · SharePoint · Defender · Purview.
• ✅ Schema v3.0 (schemaVersion: "3.0", 7 statuts : compliant | finding | manual | not_applicable | insufficient_perms | not_assessed | error).
• ✅ Auth Graph par OIDC Workload Identity Federation (CI) + cert X.509 (production).
• ✅ Pre-flight permissions check (Test-MsspRequiredPermissions).
• ✅ Hybrid detection (Test-MsspTenantHybrid) avec gate applicability.hybridOnly.
• ✅ Manual validation guides intégrés au JSON pour les contrôles non automatisables.
• ✅ Pipeline GitLab CI parametré : FRAMEWORK (cis|scuba|all) × PRODUCT_AREA (entra|exchange|teams|sharepoint|defender|purview|all).

Plateforme SaaS (Next.js 16)

• ✅ Auth multi-tenant : NextAuth v5 + Entra ID SSO, cert X.509 via Vault, résolution hostname → Client.domain → secrets Vault → SSO config.
• ✅ Plateforme fallback (sentinel slug __platform__) pour login MSSP admin sans client domaine.
• ✅ RBAC granulaire : 60 permissions, 3 rôles système (MSSP_ADMIN / ANALYST / CLIENT_USER) + custom roles éditables, scope clientId pour CLIENT_USER.
• ✅ User permission grants PIM-style (TTL, scope optionnel par tenant, justification, access-review).
• ✅ Onboarding wizard 7 étapes (platform/src/components/onboarding/steps/) : identity → credentials → preflight → test-connection → scope → users → schedule → done.
• ✅ Trigger d’audit depuis l’UI → GitLab CI → webhook HMAC → BullMQ queue audit-import → Prisma → alertes.
• ✅ Live monitor d’audit (SSE stream) avec stages pipeline.
• ✅ Reviewer workflow (ControlReviewHistory) — un MSSP_ADMIN peut overrider un statut manual en compliant | non_compliant avec notes + evidence URLs.
• ✅ 8 documents GRC (DOCX + PDF, FR + EN) — générateurs React PDF dans platform/src/lib/grc/components/.
• ✅ Rapports d’audit : PDF Executive, PDF Technical, HTML, Excel, JSON.
• ✅ Rapports certifiés Ed25519 (AuditReport type CERTIFICATION, signature 64 bytes, manifest, public key publié).
• ✅ Audit log scellé : hash chain SHA-256 + ancres journalières signées Ed25519 (LogAnchor), tampering detection + ACK procedure (AuditLogAcknowledgement).
• ✅ Tampering banner : si la chaîne est cassée, banner rouge en haut de toutes les pages dashboard (components/tampering-banner.tsx).
• ✅ Portail client (/portal/*) : Overview, Audits list, Findings, Remediation (kanban), Documents (liste + download).
• ✅ Impersonation portal (MSSP_ADMIN peut “voir comme client” → bandeau orange persistant).
• ✅ Scheduling audits : cron expression (cron-builder UI) + BullMQ repeatable job.
• ✅ Gestion credentials (cert X.509 par client, AES-256-GCM en DB, jamais en clair).
• ✅ API Keys (SHA-256 hash, scope optionnel par client, rotation sans downtime).
• ✅ DICT scoring transverse (radar 4 axes sur dashboard MSSP + page audit + portail client + section dédiée du PDF).
• ✅ CMMI maturity scoring (1-5 par contrôle, agrégation par framework, distribution).
• ✅ Trajectory dashboard (components/trajectory/trajectory-dashboard.tsx) : courbe de score sur N mois, comparaison runs, regression alerts.
• ✅ Remediation workflow : GapFinding (status OPEN → IN_PROGRESS → REMEDIATED → VERIFIED → ACCEPTED_RISK) + RemediationAction (steps multi-étapes) + Milestone (jalons datés avec dépendances).
• ✅ CISO Assistant integration (sync findings vers instance externe CISO Assistant).
• ✅ Notifications email transactionnelles : Microsoft Graph Mail.Send + BullMQ + EmailLog avec retention 90j + EmailPreference par utilisateur (opt-out granulaire).
• ✅ Observabilité Sentry full-pipeline (DSN via Vault, scrubbing PII, denylist secrets, release = commit SHA).
• ✅ Internationalisation FR/EN — next-intl, fichiers messages/fr.json + messages/en.json, language switcher dans le header.
• ✅ Documentation DR (Disaster Recovery) intégrée à l’app (/dashboard/help/dr/[...slug]) avec gating INTERNAL_DOCS_VIEW.

Infrastructure

• ✅ Docker Compose overlays par service (postgres, redis, vault, app, traefik, openproject).
• ✅ Vault Shamir seal 5/3 (3 DR Owner + 2 trustee notaire) + AppRole mssp-app / mssp-worker.
• ✅ Prisma 7 + prisma.config.ts + regenerate au container startup.
• ✅ Traefik v3 : mkcert en dev, Let’s Encrypt en prod.
• ✅ Notifications app dédiée (Entra app reg séparée du SSO, scope Mail.Send Application via Application Access Policy, mailbox [e-mail]).

2.2 Features partielles / en cours

• ⏳ 14 faux positifs audit identifiés (1 résolu sur 14) — impacte la crédibilité du score client. Bloquant V1.
• ⏳ 26 contrôles SCuBA EXO encore en manual_review (Attachment filtering, Malware scanning, Anti-Phishing, Spam, Safe Links, DLP, Alerts, Audit Logging) — automatisation à finaliser.
• ⏳ Tests Vitest/Playwright : 0 couverture aujourd’hui — bloquant V1, risque régression.
• ⏳ Intégration DICT complète : tagging des 220 contrôles fait, radar dashboard fait. Reste : pondération du score par axe DICT, intégration au PSSI, filtre multi-axes sur table contrôles.
• ⏳ Déploiement VPS production OVH : actuellement en pré-prod Docker Desktop Windows. Cible : MacBook Pro pré-prod + VPS prod.
• ⏳ Migration Sentry self-hosted : planifiée Q3-Q4 2026 (post-V1, déclencheur = 1er client payant).

2.3 Features prévues mais non codées

• 📋 Auto-remediation CA policies : déploiement automatique de Conditional Access policies (~18 templates, naming CA{NNN}). Différenciateur commercial fort. Non implémenté V1.
• 📋 VulnWatch : surveillance vulnérabilités (Defender Secure Score, recommandations Defender for Cloud Apps, alertes SIEM). Différé Q3 2026.
• 📋 Obsidian KB : base de connaissance interne MSSP (procédures remédiation, runbooks incidents, veille CVE). Différée Q4 2026.
• 📋 Wiring User.roleId → Role FK : aujourd’hui le rôle effectif vient de l’enum User.role, pas de la table Role (cache). V2.
• 📋 MilestoneDependency UI + cycle detection : schéma DB en place, API + UI absentes (différé V2, cf. schema.prisma:575).
• 📋 Documents GRC roadmap : Politique de Gestion des Risques, PCA/PRA, Registre RGPD (form), Privacy Policy, DPIA, Évaluation NIS2, ISO 27001 SoA — statut coming_soon ou planned dans la nav.
• 📋 3 product areas additionnels : Fabric, Intune (DB ready, contrôles non écrits) et la 8e zone documentée mais pas exposée dans la nav.

---

3. Flux utilisateur principaux

3.1 Parcours d’un nouveau client — Onboarding wizard (admin SnakySec)

Trigger : POST /api/v1/clients avec name + slug + domain + tenantId optionnel.

[/dashboard/clients/new]
  └─ Form minimal : name, slug auto-généré, domain (sous-domaine custom), tenantId
  └─ Submit → crée Client en status PENDING, onboardingStep=1
  └─ Redirect → /dashboard/clients/[id]/onboarding/1

[Wizard 7 étapes — sidebar steps avec lock progressif]
  Step 1: Identity         — name, slug, domain, tenantId, environment
  Step 2: Credentials      — upload cert X.509 (PEM + private key) → écriture Vault
  Step 3: Preflight        — vérification scopes Graph requis
  Step 4: Test-Connection  — probe /v1.0/organization → status=TESTED
  Step 5: Scope            — feature toggles (entra, intune, defender, purview, sharepoint, teams)
  Step 6: Users            — invitations CLIENT_USER (ClientUserAccess)
  Step 7: Schedule         — cron expression + timezone + enable/disable
  Step Done                — récap + bouton "Lancer 1er audit" (trigger ONBOARDING)
                            → status COMPLETED, onboardingCompletedAt = now

Pages concernées :

• /dashboard/clients/new/page.tsx — entry form
• /dashboard/clients/[id]/onboarding/page.tsx — resume redirect
• /dashboard/clients/[id]/onboarding/[step]/page.tsx — un fichier par étape
• Sidebar onboarding : components/onboarding/wizard-stepper.tsx

Banner permanent sur la page client tant que onboardingStatus !== "COMPLETED" (cf. page.tsx lines 109-130). Card amber dans la liste clients avec deep-link cardHref = /onboarding.

3.2 Parcours quotidien d’un client existant (portail PME)

Trigger : login SSO Entra ID via Client.domain (custom domain → resolveClientFromCookie → Vault config).

[/login] → SSO Entra ID → callback → JWT NextAuth
  └─ Si user.role === CLIENT_USER → /portal/

[/portal] — Overview
  └─ KPIs : Compliance score, Last audit, Open findings, Unread alerts
  └─ Recent audits (5 derniers, table)

[/portal/audits] — Liste audits
  └─ Table 50 derniers : date, status, score, passed/failed, lien détail

[/portal/audits/[id]] — Détail audit
  └─ Score % + summary cards
  └─ DICT radar
  └─ Liste contrôles non-conformes (read-only, pas de reviewer workflow)
  └─ Download Reports : PDF Executive, PDF Technical, HTML, Excel
  └─ Reports certifiés (Ed25519) listés à part

[/portal/findings] — Findings
  └─ Liste GapFinding scope clientIds
  └─ Filter par severity / status / productArea
  └─ Détail : control + recommandation + remediation actions

[/portal/remediation] — Remediation kanban
  └─ Colonnes : OPEN | IN_PROGRESS | REMEDIATED | VERIFIED | ACCEPTED_RISK
  └─ Drag-and-drop status (read-only sur portail ? — à vérifier)

[/portal/documents] — Documents GRC + rapports
  └─ Liste documents générés : PSSI, Charte IT, Procédure Incident, etc.
  └─ Download DOCX + PDF
  └─ Indication "généré le DD/MM/YYYY"

Pages : /portal/page.tsx (overview), /portal/audits/page.tsx, /portal/findings, /portal/remediation, /portal/documents.

Layout : sidebar épurée 5 items (Overview, Audits, Findings, Remediation, Documents) — cf. components/portal-sidebar.tsx.

3.3 Parcours d’un admin SnakySec — workflow type “audit + remédiation”

[/dashboard] — Hub MSSP
  └─ KPIs (8 cards row 1 + 4 row 2) : tenants, score moyen, alerts, audits, findings
  └─ Tabs Overview / Analytics
  └─ Section "Top critical findings" cross-tenant
  └─ Alert feed + Recent audits table
  └─ Filters : client, period

[/dashboard/clients] — Liste clients (cards 3 colonnes)
  └─ Carte par client : score %, last audit timeAgo, open gaps badge, feature badges
  └─ Banner onboarding si en cours
  └─ Bouton "Impersonate" (voir comme client → /portal en lecture)

[/dashboard/clients/[id]] — Détail client
  └─ Header : 8 boutons (Edit, Credentials, Findings, Remediation, Guide, Trajectory, CISO Assistant, Trigger Audit)
  └─ Banner active audit (si PENDING/RUNNING/IMPORTING) → lien live monitor
  └─ Stats : score / passed/total / open findings
  └─ Tabs : Overview (features, config) | History (20 derniers runs) | Findings

[/dashboard/clients/[id]/trigger-audit (button)] → /api/v1/audits/trigger
  └─ Modal : choix framework + product area
  └─ POST → GitLab pipeline trigger → AuditRun PENDING

[/dashboard/audits/[id]] — Détail audit (live ou complété)
  └─ Live monitor (SSE stream) si PENDING/RUNNING/IMPORTING
  └─ Summary cards 7 : passed, failed, manual pending/reviewed, NA, not assessed, no-perm, error
  └─ DICT radar
  └─ AuditReportsPanel : tracking + certification (Ed25519)
  └─ CompareSelector : diff avec run précédent
  └─ ControlResultsTable : 220 lignes filtrable (status, severity, product area, framework, DICT axes)
  └─ Reviewer workflow par contrôle : Sheet de review (notes + evidence upload)

[/dashboard/clients/[id]/remediation] — Workspace remédiation
  └─ Milestone cards (jalons datés) + actions multi-étapes
  └─ Dialog création milestone, dialog création action, drag reorder

[/dashboard/clients/[id]/trajectory] — Trajectoire conformité
  └─ Courbe score mensuel (KpiSnapshot)
  └─ CMMI distribution radar
  └─ Regression alerts

[/dashboard/clients/[id]/documents] — Documents GRC client
  └─ 8 docs : génération + download DOCX/PDF
  └─ Régénération à la demande (à partir du dernier audit)

[/dashboard/documents] — Hub documents (multi-client)
  └─ 7 catégories : Governance, Compliance, Access, Incidents, Monitoring, Onboarding, Technical
  └─ Liste statique des templates avec status (available | coming_soon | planned)

[/dashboard/alerts] — Inbox alertes (cross-client)
  └─ Liste 50 dernières, marker comme lu
  └─ 8 types : SCORE_DEGRADED, NEW_CRITICAL_FINDING, AUDIT_FAILED, AUDIT_COMPLETED, DEADLINE_APPROACHING, DEADLINE_OVERDUE, CMMI_REGRESSION, PERMISSION_EXPIRING_SOON

[/dashboard/integrations] — Intégrations externes
  └─ Carte CISO Assistant (status: connected | not_configured | unreachable | auth_failed)
  └─ Test connection, Refresh

[/dashboard/settings] — Settings hub
  └─ 6 cards : Users, Roles, Access Review, API Keys, Audit Log, Notifications
  └─ Card DR Runbook (gated INTERNAL_DOCS_VIEW)

---

4. Contraintes connues / dette technique

4.1 Dette technique identifiée

• 0 test automatisé côté plateforme (Vitest/Playwright) — bloquant V1 explicite. Cf. project-state.md ligne 56.
• Hydration mismatch dans alert-feed.tsx : composant "use client" qui fait timeAgo(new Date(alert.createdAt)) au render → écart serveur/client si timezone diffère. Bug récent identifié, fix en cours.
• Schema legacy + new fields cohabitent : PlatformAuditLog a des colonnes userId, resource, details, ipAddress legacy retained for backward compat avec lib/audit-log.ts v1 callers. Migration progressive.
• User.roleId → Role FK pas wirée : la source de vérité runtime reste User.role (enum). Role.permissions[] est un cache du ROLE_BASELINES de permissions/catalog.ts. Wiring V2.
• 59 checks $count >= 0 placeholder dans le moteur d’audit (cf. roadmap-2026-Q2.md §2 phase A). Élimine de faux compliants.
• Pas de Row-Level Security PostgreSQL : isolation tenant assurée applicative (Prisma queries filtrées par clientId + requireClientAccess côté route). RLS planifié P2.
• evidence legacy en JSON string sur ControlResult retained pour backward compat — backfill dans evidencePrimary (Json) typé.
• Schema v3.1 playbook fields (remediationAction, remediationImpact, rationale, method) null pour pre-v3.1 audits importés avant rollout (no backfill, rerun audit pour populater).
• MilestoneDependency : table créée, FK matérialisée, mais API + UI + cycle detection deferred V2 (schema.prisma:575).
• Permissions catalog drift risk : 60 permissions enum Prisma ↔ ROLE_BASELINES TS. Drift possible si une perm est ajoutée à un seul des deux endroits. Pas de test de cohérence automatisé.

4.2 Limitations UI actuelles

• Sidebar dashboard très chargée : 5 top-level + sub-nav Documents (7 sous-entrées dont 1 roadmapOnly) + Settings → 14 entrées visibles ouvertes. Risque de scroll vertical sur petit écran.
• Page détail client header surchargé : 8 boutons d’action dans le header (Edit, Credentials, Findings, Remediation, Guide remediation, Trajectory, CISO Assistant conditionnel, Trigger Audit). En écran 1280px certains débordent.
• Pas de breadcrumbs sur le portail client — on a un breadcrumb sur /dashboard/* (ex: Dashboard > Clients > [name]), mais le portail n’en a pas. Navigation plus pauvre pour le client final.
• Header Title “Admin” / “Portal” est statique — pas de breadcrumb adaptatif dans le header, c’est dans la page que vit le breadcrumb.
• Mobile sidebar : Sheet de gauche déclenché par menu hamburger. La logique isPortal = pathname.startsWith("/portal") switch entre <Sidebar /> et <PortalSidebar />. Pas testé exhaustivement sur mobile.
• Empty states inconsistants : certains pages ont un <EmptyState> propre, d’autres juste un <p> (ex: /portal/audits ligne 49 vs dashboard ligne 230).
• Tampering banner persistant en haut → si la chaîne d’audit log est cassée, banner rouge sur toutes les pages (pas dismissable sans ACK admin). Comportement voulu mais peut surprendre.
• Doublon Findings cross-context : /dashboard/clients/[id]/findings (admin scope client) + /portal/findings (client scope user) + Tab findings sur /dashboard/clients/[id]. Trois routes différentes pour la même donnée filtrée.
• Doublon Remediation : 4 entrées — /dashboard/clients/[id]/remediation (workspace), /dashboard/clients/[id]/remediation-plan (plan view), /portal/remediation (kanban client), bouton GuideFilterDialog sur la page client. Le mapping mental n’est pas trivial.

4.3 Points de friction connus

• L’opérateur MSSP doit jongler entre /dashboard/clients et /dashboard/audits : pour suivre un audit en cours, il faut soit revenir sur la page client (banner active audit) soit aller dans /dashboard/audits. Pas de “audits in progress” globalement filtrable.
• Le “Trigger audit” est sur la page client, pas globalement : pour relancer un audit en masse sur N clients, l’opérateur doit cliquer client par client.
• CISO Assistant integration : 4 états (connected, not_configured, unreachable, auth_failed) → chaque carte client peut afficher un sync status différent. Charge cognitive sur la page audit detail.
• 8 GRC documents + 7 catégories : la nomenclature catégorie/document n’est pas toujours intuitive (ex: Breach Notification = “Compliance” ; Incident Procedure = “Incidents”). Le hub /dashboard/documents doit être lu pour comprendre.
• Onboarding wizard 7 steps + step Done : le sidebar montre STEP_ORDER: [1, 2, 3, 4, 5, 6, 7] mais la résolution de step utilise Math.max(client.onboardingStep, minStep) — si l’opérateur quitte au step 4 puis revient via la card client, il atterrit au step persisté, pas forcément au step “logique suivant”.
• Onboarding banner toujours présent tant que COMPLETED : même quand l’audit a tourné, la banner amber reste tant qu’on n’a pas explicitement cliqué “Done” sur le wizard.
• Permission denied logs : requirePermission() écrit un row permission.denied au audit log à chaque refus. L’UI peut générer des denials silencieux (ex: hasPermission OR check, mais utilisé requirePermission au lieu de hasPermission) → bruit dans le log.
• AuditActions a 2 variantes ("dropdown" | "buttons") selon le contexte (table vs page header) → 2 chemins UI à maintenir, risque de divergence des actions disponibles.
• Reports : 5 formats (PDF Executive, PDF Technical, HTML, Excel, JSON) × 2 types (TRACKING, CERTIFICATION) → 10 combinaisons potentielles, gérées par AuditReportsPanel mais pas toutes systématiquement générées.
• Notifications email par défaut tout activé (opt-in transactionnel MSSP) → un nouveau user reçoit toutes les alertes catégories sans curation. Opt-out via settings ou unsubscribe link footer.
• Les EMERGENCY_TEMPLATES (alertes tampering chain) bypassent les preferences user — comportement voulu (security floor) mais pas signalé dans l’UI.

---

5. Méthodologies & frameworks

• DICT (ANSSI) : Disponibilité · Intégrité · Confidentialité · Traçabilité — référence transverse pour classification des contrôles, scoring des risques, génération PSSI.
• CMMI 1-5 : niveau de maturité par contrôle, agrégé par framework.
• CIS M365 v6.0.1 : 140 contrôles sur 6 product areas.
• CISA SCuBA v1.5.0 : 94 contrôles sur 6 product areas (mapping AAD→Entra, EXO→Exchange).
• ANSSI / SecNumCloud / EBIOS / NIS2 / LPM : méthodologies sources des 8 documents GRC.
• eIDAS-ready : audit log + reports certifiés signés Ed25519 → opposable tiers.

---

6. Échéances commerciales

• V1 commercial : Q2 2026.
• Solo founder : Nicolas Schiffgens, expert MSSP cyber.
• Cible go-to-market : PME France/Europe régulées NIS2, sans cellule cyber interne, qui veulent un service managé clé-en-main (pas un outil).

---

7. Liens utiles pour le consultant UX

• Code dashboard MSSP : platform/src/app/dashboard/
• Code portail client : platform/src/app/portal/
• Composants UI réutilisables : platform/src/components/ui/
• Composants métier : platform/src/components/
• Modèle DB : platform/prisma/schema.prisma
• i18n (FR/EN) : platform/messages/fr.json · platform/messages/en.json
• Sidebar admin : components/sidebar.tsx
• Sidebar portal : components/portal-sidebar.tsx
• Header (commun aux deux contextes) : components/header.tsx
• État projet et roadmap : docs/project-state.md, docs/roadmap-2026-Q2.md
• Threat model + DICT : docs/SECURITY.md
• Analyse concurrence : docs/competitive-analysis-2026.md