Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.snakysec.com/llms.txt

Use this file to discover all available pages before exploring further.

UX BRIEF — SnakySec MSSP

Synthèse 1 page pour consultant UX externe découvrant le projet en 5 min.

Ce que fait l’app — en 3 phrases

SnakySec MSSP est une plateforme SaaS multi-tenant pour MSSP qui audite la conformité Microsoft 365 de PME (220 contrôles CIS M365 v6.0.1 + CISA SCuBA v1.5.0, 6 zones M365), calcule un score de conformité par tenant et génère 8 documents GRC (PSSI, Charte IT, Procédure Incident, Plan de Remédiation, Politique de Classification, Notification de Violation, Politique d’Accès, Registre des Traitements) selon les méthodologies ANSSI / SecNumCloud / NIS2. Le MSSP pilote tout depuis un dashboard admin (/dashboard/*) tandis que chaque PME cliente accède en lecture à son portail white-label (/portal/*). La traçabilité est opposable : audit log scellé par hash chain SHA-256 + ancres journalières signées Ed25519 (eIDAS-ready), rapports certifiés signés.

Utilisateur principal et niveau technique

Persona 1 (utilisateur quotidien) — MSSP Operator : expert cyber/vCISO externalisé qui gère 5 à 30 tenants clients en parallèle. Niveau technique élevé (Graph API, PowerShell, ANSSI, ISO 27001). Aujourd’hui = solo founder Nicolas. Persona 2 (utilisateur ponctuel) — Client PME : DSI ou dirigeant 20-250 personnes, régulé NIS2, niveau technique très faible — vient seulement quand son assureur ou son comité demande une preuve de conformité.

Les 3 actions les plus fréquentes

  1. Trigger un audit + suivre sa progression live : depuis /dashboard/clients/[id] → bouton primary Trigger Audit → choix framework × productArea → pipeline GitLab → live monitor (SSE) → import → résultats sur /dashboard/audits/[id].
  2. Qualifier les findings et faire vivre le plan de remédiation : depuis /dashboard/audits/[id] (reviewer workflow sur contrôles manual) puis /dashboard/clients/[id]/remediation (milestones datées, actions multi-étapes, kanban OPEN → IN_PROGRESS → REMEDIATED → VERIFIED).
  3. Générer les livrables clients : rapports d’audit (PDF Executive / Technical / HTML / Excel / JSON, tracking et certification Ed25519) + 8 documents GRC (DOCX + PDF, FR/EN) depuis /dashboard/clients/[id]/documents.

Les 3 problèmes UX les plus bloquants actuellement

  1. Page détail client /dashboard/clients/[id] surchargée : 8 boutons d’action dans le header (Edit, Credentials, Findings, Remediation, Guide, Trajectory, CISO Assistant conditionnel, Trigger Audit) + 3 tabs + banner onboarding + banner active audit. Cognitive load élevé, débordement visuel sous 1280px. C’est la page la plus visitée et la plus dense.
  2. Doublons de navigation pour les Findings et la Remediation : 4 chemins distincts pour chaque (tab page client + bouton header + page dédiée + page portail). Le mapping mental “où je vais voir les findings de ce client” n’est pas évident — surface UI fragmentée pour la même donnée.
  3. AlertFeed hydration mismatch + PortalSidebar non-i18n : 2 bugs UX visibles. (a) Le composant AlertFeed calcule timeAgo() au render → écart SSR/CSR si timezone diffère, sourcing potentiel d’avertissements console. (b) La sidebar du portail client a ses labels (Overview, Audits, Findings, Remediation, Documents) hardcoded EN — alors que tout le reste de l’app est bilingue FR/EN. User PME francophone voit un mix langue confusing.

Ce qui ne doit surtout pas changer (ce qui fonctionne bien)

  • Architecture en deux contextes nets — /dashboard/* (MSSP) vs /portal/* (client) avec sidebars dédiées, même Header partagé qui adapte ses options. Sépare clairement les responsabilités, isolation tenant assurée par RBAC + scope clientId.
  • Layout 3-zones constant (sidebar 256px gauche · header 64px sticky · main scrollable). Familier et stable, déjà internationalisé.
  • Onboarding wizard 7 étapes avec sidebar steps : pattern classique mais bien implémenté, lock progressif des steps non-atteignables, resume URL persistée par étape (onboardingStep en DB).
  • Tampering banner audit log + rapports certifiés Ed25519 : c’est le différenciateur sécurité produit (eIDAS-ready, traçabilité opposable). Ne pas masquer ni adoucir.
  • Système DICT (Disponibilité · Intégrité · Confidentialité · Traçabilité — modèle ANSSI) transverse : tagging des 220 contrôles, radar 4 axes sur dashboard + page audit + portail + section dédiée des PDFs. Cohérence ANSSI = crédibilité commerciale PME France.
  • Composants shadcn/ui partout (25 primitives) + Recharts + TanStack Table : stack mature et stable, ne pas migrer.
  • Brand discipline : <Wordmark> typographique (sans pictogramme), couleurs cohérentes par statut (vert/rouge/jaune/gris/orange/amber). <StatusBadge> + <SeverityBadge> + <FeatureBadges> réutilisés partout.