ACRA — Augmented Cyber Risk Analysis

La plateforme open-source qui rend l'analyse de risques EBIOS RM accessible à tous

🌐 Langue / Language : 🇫🇷 Français · 🇬🇧 English · 🇩🇪 Deutsch · 🇪🇸 Español · 🇮🇹 Italiano

ACRA (Augmented Cyber Risk Analysis) est une application web guidée qui permet à n'importe quelle équipe sécurité — même sans expertise pointue — de conduire une analyse de risques complète selon la méthode EBIOS Risk Manager de l'ANSSI, compatible ISO 27005.

Les analyses de risques EBIOS RM sont exigeantes : la méthode comporte 5 ateliers interconnectés, des dizaines de concepts à maîtriser, et la moindre erreur de cohérence peut invalider toute la démarche. En pratique, les équipes s'appuient sur des tableurs Excel complexes, des consultants coûteux, ou renoncent à la rigueur méthodologique.

ACRA change ça : c'est un assistant méthodologique interactif qui guide pas à pas, propose des exemples cliquables à chaque étape, maintient la cohérence entre les ateliers, et produit automatiquement un rapport PDF structuré.

• Guidage méthodologique intégré : chaque champ dispose d'un tooltip, d'un lien vers le guide ANSSI, et d'exemples contextuels
• Cohérence automatique : les éléments d'un atelier alimentent automatiquement les ateliers suivants
• 14 référentiels de mesures : ISO 27001:2022, NIST CSF 2.0, NIST 800-53, CIS Controls v8, ANSSI Hygiène, HDS, PCI-DSS, DORA, IEC 62443, SOC 2, NIST SSDF, RGS, ReCyF, TISAX/VDA-ISA — depuis une seule interface
• Guidage sectoriel & conformité : exemples métier adaptés au secteur et au sous-secteur, recommandation de référentiels, détection du statut réglementaire (NIS2, OIV…) — voir le détail
• Méthode Flash (Club EBIOS) : déroulé guidé des 5 ateliers en une passe rapide, en s'appuyant sur la capitalisation (exemples, socle de sécurité) — idéal pour une première analyse ou un contexte contraint
• Guides Club EBIOS intégrés : la méthode Flash et la fiche méthode 5 (dangerosité des parties prenantes) sont implémentées directement dans le parcours
• Multi-organisation hiérarchique : cabinets de conseil (clients isolés), grands groupes (vision entité + consolidée), multi-sites, filiales — dans une seule instance — voir le détail
• 100% auto-hébergé : vos données ne quittent jamais votre infrastructure

• 5 ateliers guidés avec bibliothèque d'exemples cliquables (valeurs métier, sources de risque, scénarios, mesures…)
• Méthode Flash (Club EBIOS) : parcours rapide A1 → A2 → A3 → A4 → A5 en une passe, en capitalisant sur les exemples et le socle de sécurité, pour produire rapidement une liste de risques et un plan d'action
• Guide EBIOS RM interactif intégré avec liens directs vers les pages du guide officiel ANSSI, et intégration des guides du Club EBIOS (méthode Flash, dangerosité des parties prenantes)
• Matrice des risques visuelle (gravité × vraisemblance) avec niveaux résiduels et comparaison avant/après mesures
• Critères DICT (Disponibilité, Intégrité, Confidentialité, Traçabilité) sur valeurs métier et biens supports
• Liens MITRE ATT&CK sur les scénarios opérationnels
• Cartographie radar des couples source de risque / objectif visé (Atelier 2)
• Opérateurs logiques ET/OU dans les modes opératoires (Atelier 4)
• Trois méthodes d’évaluation de la vraisemblance : expresse, standard, avancée (cotation par action élémentaire et calcul de la vraisemblance globale)
• Catégorisation EBIOS des mesures : gouvernance, protection, défense, résilience
• Mention de protection du document d’analyse (non protégée → confidentielle), portée sur la page de garde et les exports
• Versionnage x.y des analyses et historique des révisions (cycle opérationnel/stratégique)
• Cartographie de menace de l'écosystème (Atelier 3, fiche méthode 5 ANSSI) : dangerosité des parties prenantes calculée sur 4 sous-critères, radar polaire à 3 zones, échelles configurables, marquage des tiers critiques — voir le détail
• Vue Tiers transverse : gestion des parties prenantes (third-party management) agrégée sur toutes les analyses, filtrable par zone et criticité

• Mesures de sécurité issues de 14 référentiels : ISO 27001:2022 · NIST CSF 2.0 · NIST 800-53 · CIS Controls v8 · ANSSI Hygiène · HDS · PCI-DSS · DORA · IEC 62443 · SOC 2 · NIST SSDF · RGS · ReCyF · TISAX/VDA-ISA + contrôles personnalisés — contrôles localisés dans les 5 langues
• Politique de mot de passe configurable (longueur, complexité, expiration, historique, verrouillage)
• MFA configurable (OTP à usage unique par e-mail ou SMS) avec fenêtre de confirmation de 60 min pour éviter tout verrouillage accidentel
• SSO configurable (SAML 2.0 ou OIDC) — provisioning automatique des comptes
• Piste d'audit complète exportable (CSV)

• RBAC 7 niveaux : SUPER_ADMIN · ADMIN · RSSI · RISK_MANAGER · DIRECTION_METIER · ANALYSTE · LECTEUR
• Multi-organisation : arbre d'organisations avec périmètres hiérarchiques (nœud / sous-arbre) ; un ADMIN administre uniquement les comptes de son organisation, un SUPER_ADMIN gère l'instance
• Workflow d'approbation : soumission → révision → approbation (RSSI ou Risk Manager), avec séparation des tâches — un approbateur ne peut pas approuver sa propre analyse (principe des quatre-yeux) — et auto-validation pour les organisations mono-utilisateur (cabinet libéral, où le quatre-yeux est impossible)
• Acceptation des risques résiduels par la Direction métier (rôle dédié, lecture seule sur les analyses), distincte de la validation de l'analyse (acceptation du livrable)
• Dérogations — acceptation temporaire d'une non-conformité au socle de sécurité : rattachée à un contrôle d'un référentiel ou à un risque, justifiée, compensée, bornée dans le temps et surveillée. Workflow configurable par organisation (autonomie / validation RSSI / RSSI + Direction métier, double regard « RSSI groupe » optionnel), alertes avant expiration, clôture avec preuves, et registre des dérogations transverse — un livrable de conformité (ISO 27001, registre d'exceptions DORA, dossier d'homologation ANSSI)
• Partage d'accès par analyse avec permissions individuelles
• Dashboard admin : gestion des utilisateurs (périmètre de l'organisation), création de comptes, suspension, logs d'audit
• Récupération (corbeille) : une analyse supprimée par un utilisateur reste restaurable par un administrateur pendant 30 jours avant purge définitive

• Export PDF structuré multi-pages (synthèse executive, KPIs, ateliers, mesures, annexes méthodologiques)
• Export Excel (.xlsx) avec toutes les données tabulaires par onglet
• Export JSON (sauvegarde complète, réimportable) et CSV (données tabulaires)
• Import d'analyse depuis JSON ou CSV

• Interface en 5 langues : Français · English · Deutsch · Español · Italiano
• Auto-save à chaque modification (aucune perte de données)
• Tableau de bord avec KPIs, graphiques, alertes risques critiques, recherche globale
• Thème clair / sombre / automatique
• Conforme RGAA : navigation clavier, ARIA, contrastes accessibles

	Thème clair	Thème sombre
Tableau de bord
Mes analyses
Atelier 1 — Cadrage & socle
Atelier 5 — Traitement du risque
Cartographie des risques
Atelier 3 — Cartographie de l'écosystème
Configuration (échelles & matrice)
Administration
Journal d'audit

🆕 Voir aussi la cartographie de menace de l'écosystème (radar de dangerosité des tiers) et le module Récupération (corbeille 30 jours).

Aucune installation locale de Node, npm ou Prisma n'est requise : l'image Docker embarque toutes les dépendances et le client Prisma, et applique les migrations automatiquement au démarrage (service migrator).

git clone https://github.com/votre-org/acra.git
cd acra
make setup        # génère .env + secrets aléatoires (interactif)
docker compose up -d

Pas de make ? Utilisez directement : ./scripts/setup.sh (ou npm run setup). Installation automatisée / CI (aucune question posée) : ./scripts/setup.sh --auto.

setup.sh génère pour vous des secrets forts (NEXTAUTH_SECRET, mot de passe PostgreSQL, SECRETS_ENCRYPTION_KEY) et ne régénère que les valeurs manquantes s'il est relancé (détails en section « Installation détaillée » ci-dessous).

L'application est disponible sur http://localhost:3000. Créez votre compte sur /auth/register — le premier compte créé devient automatiquement SUPER_ADMINISTRATEUR d’instance.

Pour charger les données de démonstration (optionnel, jamais en production) :

docker compose exec app npx prisma db seed
# Compte démo créé : admin@chu-metropole.fr / Acra@Admin2024!
# ⚠️ Tests uniquement — changez/supprimez ce compte avant toute mise en production

Sans Docker (développement local) : Node.js 20+ et PostgreSQL 14+ requis — voir Développement local.

git clone https://github.com/votre-org/acra.git
cd acra

Le script de setup crée le fichier .env et génère des secrets forts. Il est idempotent : relancé, il conserve les valeurs déjà définies et ne complète que ce qui manque.

./scripts/setup.sh          # interactif (demande l'URL publique)
# ou, sans aucune interaction (secrets aléatoires, URL par défaut) :
./scripts/setup.sh --auto

Le script renseigne automatiquement :

Configuration manuelle (alternative) : cp .env.example .env puis remplacez toutes les valeurs CHANGEZ_MOI. Générez un secret avec openssl rand -base64 48.

⚠️ Production : NEXTAUTH_URL doit être en HTTPS. Ne committez jamais .env (déjà dans .gitignore). Si SECRETS_ENCRYPTION_KEY change, les secrets déjà chiffrés en base devront être ressaisis dans l'interface d'administration.

docker compose up -d

Docker lance 5 services :

• db — PostgreSQL 16 (port 5432)
• migrator — exécute prisma migrate deploy au démarrage (s'arrête ensuite)
• app — Application Next.js (port 3000)
• scheduler — planifie les tâches périodiques /api/cron/* (voir ci-dessous)
• backup — sauvegardes PostgreSQL automatiques (rotation 7 jours)

Le service scheduler appelle en interne (http://app:3000, sans exposition réseau) les endpoints /api/cron/*, authentifiés par le jeton CRON_SECRET (généré automatiquement par scripts/setup.sh). Cadence par défaut (cf. scripts/scheduler.sh, fuseau TZ, UTC par défaut) :

Sans CRON_SECRET, les endpoints répondent 503 et le scheduler reste inactif (aucune boucle de redémarrage). Les traitements sont idempotents : un double déclenchement éventuel est sans effet de bord. Pour un planificateur externe (cron système…), appelez les mêmes URL avec l'en-tête Authorization: Bearer $CRON_SECRET.

Pour un déploiement sans sidecar (PaaS, serverless…), le workflow .github/workflows/scheduled-tasks.yml assure les mêmes cadences en appelant l'instance déployée. Deux secrets de dépôt suffisent (Settings → Secrets and variables → Actions) :

Tant que ces secrets sont absents, le workflow se termine en succès sans rien appeler. Chaque tâche est aussi déclenchable à la main (Actions → Scheduled tasks → Run workflow), ce qui permet de valider la configuration immédiatement.

N'activez qu'une seule variante — soit le service scheduler, soit ce workflow : sinon le digest mensuel partirait deux fois. La cadence de GitHub Actions est « best effort » (déclenchement parfois décalé, et suspendu après 60 jours d'inactivité du dépôt) ; pour une ponctualité stricte, gardez le sidecar.

Vérifier que tout est opérationnel :

docker compose ps
# Tous les services doivent être en status "running" (sauf migrator : "exited 0")

curl http://localhost:3000/api/health
# {"status":"ok","db":"connected","timestamp":"..."}

# Voir les logs en temps réel
docker compose logs -f app

# Arrêter les services
docker compose down

# Arrêter ET supprimer les volumes (efface la base de données)
docker compose down -v

# Rebuild après modification du code
docker compose up -d --build

# Accéder à la base de données via psql (utilise les identifiants du conteneur)
docker compose exec db sh -c 'psql -U "$POSTGRES_USER" "$POSTGRES_DB"'

# Exécuter un seed de données de démonstration
docker compose exec app npx prisma db seed

# Lancer les migrations manuellement
docker compose exec app npx prisma migrate deploy

git pull origin main
docker compose up -d --build
# Les migrations sont appliquées automatiquement au démarrage

Les sauvegardes PostgreSQL sont automatisées dans docker-compose.yml (rotation 7 jours) :

# Sauvegarde manuelle
docker compose exec db sh -c 'pg_dump -U "$POSTGRES_USER" "$POSTGRES_DB"' > backup_$(date +%Y%m%d).sql

# Restauration
docker compose exec -T db sh -c 'psql -U "$POSTGRES_USER" "$POSTGRES_DB"' < backup_20240115.sql

Pour contribuer ou personnaliser ACRA sans Docker :

• Node.js 20+ (node --version)
• PostgreSQL 14+ (ou Docker pour la DB uniquement)
• npm 10+

# 1. Cloner le dépôt
git clone https://github.com/votre-org/acra.git
cd acra

# 2. Installer les dépendances (génère aussi le client Prisma via postinstall)
npm install

# 3. Démarrer PostgreSQL via Docker (option la plus simple)
docker run -d --name acra-db \
  -e POSTGRES_USER=acra_user \
  -e POSTGRES_PASSWORD=acra_secret \
  -e POSTGRES_DB=acra_rm \
  -p 5432:5432 postgres:16-alpine

# 4. Configurer l'environnement (génère .env avec des secrets)
./scripts/setup.sh --auto
# En local sans Docker pour l'app, pointez la base sur localhost :
sed -i 's/@db:5432/@localhost:5432/' .env

# 5. Appliquer les migrations et générer le client Prisma
npx prisma migrate deploy
npx prisma generate

# 6. (Optionnel) Charger les données de démonstration
npx prisma db seed

# 7. Démarrer en mode développement (hot reload)
npm run dev

L'application est disponible sur http://localhost:3000

npm run dev          # Serveur de développement (hot reload)
npm run build        # Build de production
npm run start        # Serveur de production (après build)
npm run setup        # (Ré)génère le fichier .env (secrets manquants)
npm test             # Tests unitaires Vitest (run once)
npm run test:watch   # Tests en mode watch
npm run test:coverage # Rapport de couverture
npx tsc --noEmit     # Vérification TypeScript sans compilation

TDD obligatoire : chaque nouvelle fonctionnalité doit être accompagnée d'un test écrit avant l'implémentation. Voir CONTRIBUTING.md.

# 1. Écrire le test (il doit échouer)
# → src/__tests__/unit/lib/ma-feature.test.ts

# 2. Lancer en watch pour voir le rouge
npm run test:watch

# 3. Implémenter jusqu'au vert
# 4. Refactorer

ebios-rm/
├── src/
│   ├── app/                          # Pages Next.js (App Router)
│   │   ├── page.tsx                  # Landing page
│   │   ├── dashboard/                # Tableau de bord KPIs
│   │   ├── analyses/                 # Liste, création, détail
│   │   │   └── [id]/atelier/[num]/  # Les 5 ateliers EBIOS RM
│   │   ├── risques/                  # Vue globale des risques
│   │   ├── tiers/                     # Vue transverse des parties prenantes
│   │   ├── actions/                  # Plan d'action global (filtres)
│   │   ├── auth/                     # Login / Register / Reset
│   │   ├── admin/                    # Administration (ADMIN uniquement)
│   │   │   ├── users/                # Gestion des utilisateurs
│   │   │   ├── security/             # Politique MFA, SSO, mot de passe
│   │   │   ├── smtp/                 # Configuration SMTP
│   │   │   ├── audit/                # Journal d'audit
│   │   │   └── recovery/             # Récupération des analyses (corbeille 30 j)
│   │   ├── configuration/            # Échelles, matrice, référentiels, écosystème
│   │   └── profile/                  # Profil, langue, thème
│   │   └── api/                      # Routes API REST (Next.js)
│   ├── components/
│   │   ├── workshops/                # Atelier1.tsx → Atelier5.tsx
│   │   ├── Navbar.tsx                # Navigation principale + recherche
│   │   ├── RiskMatrix.tsx            # Matrice des risques interactive
│   │   ├── EcosystemRadar.tsx        # Radar de menace de l'écosystème (Atelier 3)
│   │   ├── MenaceFormulaDiagram.tsx  # Schéma HTML du calcul de la menace
│   │   ├── WorkshopProgress.tsx      # Barre de progression ateliers
│   │   ├── EbiosGuide.tsx            # Guide interactif EBIOS RM
│   │   ├── FrameworkControlsPanel.tsx # Panel mesures multi-référentiel
│   │   └── AnalysesChart.tsx         # Graphiques dashboard
│   └── lib/
│       ├── ebios-data.ts             # Bibliothèque EBIOS RM (suggestions)
│       ├── frameworks-data.ts        # Contrôles ISO 27001, NIST, CIS…
│       ├── ecosystem-radar.ts        # Géométrie + zones du radar (testé)
│       ├── ecosystem-echelles.ts     # Échelles configurables de dangerosité
│       ├── recovery.ts               # Rétention 30 j de la corbeille (testé)
│       ├── permissions.ts            # Matrice RBAC centralisée
│       ├── logger.ts                 # Logs structurés Winston + audit trail
│       ├── useAutoSave.ts            # Hook React auto-save
│       ├── password-policy.ts        # Validation politique mot de passe
│       ├── prisma.ts                 # Client Prisma singleton
│       └── i18n/                     # Traductions (fr/en/de/es/it)
├── prisma/
│   ├── schema.prisma                 # Modèle de données PostgreSQL
│   └── migrations/                   # Migrations SQL versionnées
├── src/__tests__/                    # Tests unitaires Vitest
├── docker-compose.yml
├── Dockerfile
└── .env.example

• Mots de passe hashés bcrypt (coût 12)
• Sessions JWT signées (NEXTAUTH_SECRET)
• Middleware d'authentification Next.js sur toutes les routes protégées
• Headers HTTP sécurité : X-Frame-Options, CSP, X-Content-Type-Options, Referrer-Policy, HSTS
• Validation des entrées côté serveur : schémas Zod (authentification, politiques admin) et sanitizers par allowlist sur les ateliers et imports (anti mass-assignment, CWE-915)
• Isolation des données par utilisateur + RBAC par analyse + suppression douce (corbeille 30 j) au lieu d'un effacement immédiat
• Piste d'audit complète (table AuditLog) pour toutes les actions sensibles, exportable CSV
• Rate limiting sur les routes d'authentification
• MFA configurable avec fenêtre de sécurité (auto-désactivation si non confirmé sous 60 min)
• SSO SAML 2.0 / OIDC configurable

# 1. Générer tous les secrets (NEXTAUTH_SECRET, mot de passe PostgreSQL,
#    SECRETS_ENCRYPTION_KEY) en une commande — idempotent :
./scripts/setup.sh --auto

# 2. Définir l'URL publique HTTPS dans .env
#    NEXTAUTH_URL=https://acra.mondomaine.fr   (HTTPS obligatoire)

# 3. Placer derrière un reverse proxy HTTPS (Nginx, Caddy, Traefik + TLS)

# 4. Ne PAS charger le seed de démo en production. S'il l'a été par erreur :
#    connectez-vous sur /admin/users et supprimez/réinitialisez admin@chu-metropole.fr

# 5. Démarrer et vérifier le health check
docker compose up -d
curl https://votre-domaine.com/api/health
# {"status":"ok","db":"connected",...}

Le premier compte créé sur /auth/register devient ADMINISTRATEUR. Créez-le immédiatement après le déploiement pour éviter qu'un tiers ne s'attribue ce rôle (l'inscription est ouverte par défaut).

Un audit de sécurité OWASP/WSTG complet a été conduit sur l'application. Voir le rapport dans docs/.

ACRA traite des données sensibles (analyses de risques, cartographie de l'écosystème). Le déploiement doit suivre les principes du guide d'hygiène informatique de l'ANSSI : cloisonnement, défense en profondeur, moindre privilège, authentification forte, journalisation.

Hébergement dans votre datacenter, derrière un pare-feu, sans exposition directe sur Internet. C'est le scénario à privilégier pour les données les plus sensibles.

flowchart LR
  U["Postes internes<br/>(LAN / VPN)"] -->|HTTPS / TLS 1.2+| FW["Pare-feu + WAF"]
  subgraph DC["Datacenter interne — zone de confiance cloisonnée"]
    FW --> RP["Reverse proxy TLS<br/>Nginx / Caddy / Traefik<br/>HSTS, en-têtes sécurité"]
    RP --> APP["ACRA (Next.js)<br/>conteneur Docker"]
    IDP["IdP SSO<br/>SAML 2.0 / OIDC<br/>+ MFA admins"] -.->|fédération| APP
    APP --> DB[("PostgreSQL<br/>réseau privé<br/>chiffré au repos")]
    APP --> BK[("Sauvegardes<br/>chiffrées, hors-ligne")]
    APP --> SIEM["Journaux / SIEM"]
  end

Mesures clés :

• Réseau cloisonné (VLAN dédié), application non exposée sur Internet ; accès via LAN ou VPN.
• Pare-feu + WAF en amont ; reverse proxy TLS 1.2+ terminant le HTTPS (NEXTAUTH_URL=https://…), HSTS activé.
• SSO (SAML/OIDC) + MFA obligatoire pour les administrateurs (OTP e-mail/SMS).
• PostgreSQL jamais exposé publiquement, chiffré au repos, accès restreint à l'app.
• Sauvegardes chiffrées régulières et testées (cf. section Sauvegarde) ; secrets via coffre (SECRETS_ENCRYPTION_KEY).
• Journalisation centralisée (piste d'audit ACRA + logs Winston → SIEM) ; revue d'accès périodique.

Si l'hébergement se fait sur un cloud externe (IaaS/PaaS), réduisez la surface d'exposition et renforcez l'authentification pour tous les comptes.

flowchart LR
  U["Utilisateurs"] -->|"VPN SSL **ou** liste blanche d'IP"| GW["Passerelle<br/>WAF + TLS"]
  subgraph CL["Cloud PaaS / IaaS — zone exposée"]
    GW --> APP["ACRA conteneurisé"]
    IDP["IdP SSO + MFA<br/>pour TOUS les comptes"] -.->|fédération| APP
    APP --> DB[("PostgreSQL managé<br/>accès privé, chiffré")]
    APP --> SIEM["Journaux exportés<br/>vers SIEM"]
  end

Mesures clés (en plus du cas 1) :

• Accès restreint par liste blanche d'adresses IP ou VPN SSL — pas d'accès public ouvert.
• SSO + MFA pour TOUS les utilisateurs (pas seulement les admins).
• Base de données managée en réseau privé (jamais d'IP publique), chiffrement en transit et au repos.
• Secrets dans un coffre managé (KMS / Secrets Manager) ; rotation régulière.
• Journaux exportés vers un SIEM ; alerting sur les événements sensibles (connexions, exports, suppressions).

⚡ Méthode Flash (Club EBIOS) : parcours rapide A1 → A2 → A3 → A4 → A5 disponible depuis le dashboard. Conformément à la démarche « Flash » du Club EBIOS, tous les ateliers sont déroulés en une seule passe en capitalisant sur les exemples et le socle de sécurité, en se concentrant sur les scénarios les plus pertinents (≈ 5 max). L'échelle et la matrice restent celles configurées par l'administrateur. Idéal pour une première analyse ou un contexte contraint.

ACRA implémente la fiche méthode 5 de l'ANSSI / Club EBIOS (« construire l'estimation de la dangerosité des parties prenantes ») pour prioriser les tiers de l'écosystème : fournisseurs, prestataires, clients, partenaires, régulateurs.

Le niveau de menace d'un tiers se calcule à partir de 4 sous-critères cotés sur des échelles qualitatives :

                Dépendance × Pénétration            (exposition, ↑ menace)
menace  =  ───────────────────────────────────
                Maturité cyber × Confiance           (fiabilité, ↓ menace)

Les tiers sont positionnés sur un radar polaire : plus un point est proche du centre, plus la menace est élevée. Trois zones d'égale largeur — danger / contrôle / veille — guident la priorisation (les tiers en danger ou contrôle sont critiques et entrent dans les scénarios stratégiques).

Radar de menace	Schéma de calcul (aide intégrée)

Lecture du radar :

• Couleur du point = fiabilité cyber (rouge faible → vert forte)
• Taille du point = exposition (plus gros = plus exposé)
• Anneaux = zones de menace (danger orange · contrôle jaune · veille vert)
• ★ = tiers marqué critique (manuel)
• Libellé = nom court éditable (clic ou double-clic sur le point) ou réf T1, T2…
• Survol d'un point → détail des 4 sous-critères, exposition/fiabilité et menace (info-bulle au-dessus des points)
• Export PNG / SVG du radar depuis son en-tête

Tiers de rang 2 / 3 (profondeur d'écosystème) — conformément à la fiche méthode 5 du Club EBIOS, un tiers critique peut être décomposé en parties prenantes connexes (ex. l'hébergeur d'un prestataire, le sous-traitant d'un partenaire). ACRA gère trois rangs de profondeur :

• depuis un tiers critique, le bouton « + PP connexe » ajoute une partie prenante de rang 2, elle-même décomposable en rang 3 ;
• sur le radar, une case « Rangs 2/3 » affiche ces tiers connexes (masqués par défaut), atténués et reliés à leur tiers parent par un trait pointillé, avec évitement automatique des chevauchements de points et de libellés ;
• la synthèse exécutive (PDF) reste centrée sur les tiers de rang 1 pour la lisibilité.

Échelles configurables — chaque niveau des 4 critères (1→4 par défaut) est renommable dans Configuration → Écosystème, avec ajout/suppression de niveaux (réservé ADMIN). Le calcul du radar s'adapte automatiquement à l'échelle.

Vue Tiers transverse — la page Tiers agrège les parties prenantes de toutes les analyses, filtrables par zone et par criticité (★), pour une gestion des tiers (third-party management) à l'échelle de l'organisation. Un même tiers peut y apparaître plusieurs fois (sa dangerosité dépend du périmètre analysé).

Le radar, les étoiles de criticité et le tableau des parties prenantes (4 sous-critères + colonne Critique) sont également présents dans l'export PDF.

ACRA adapte la démarche au contexte réglementaire et sectoriel de l'organisation, sans jamais l'imposer.

Exemples adaptés au secteur — le secteur choisi au cadrage (et, pour les secteurs réglementés, un sous-secteur) alimente des bibliothèques d'exemples métier ciblés dans les ateliers 1 à 3 (valeurs métier, biens supports, événements redoutés, sources de risque, scénarios, parties prenantes). 16 familles couvrent les 20 secteurs : santé, banque/finance, industrie & énergie (dont ENR : éolien/PV/BESS), transport, télécom, administration, agroalimentaire, immobilier/BTP, médias, tourisme, associations/ESS, juridique, numérique, éducation/recherche, commerce, défense. Les sous-secteurs affinent encore le contenu : un notaire ne voit pas les exemples propres aux avocats, le ferroviaire diffère de l'aérien, la construction/BTP de l'agence immobilière.

Recommandation de référentiels — le secteur, la taille de l'organisation (TPE/PME/ETI-GE) et le sous-secteur orientent les référentiels recommandés (ex. Banque → DORA, Santé → HDS, Industrie/Énergie → IEC 62443, Administration → RGS, éditeur logiciel → NIST SSDF/SOC 2). DORA n'est proposé qu'aux entités financières réglementées (pas à une TPE fintech pré-agrément).

Module Conformité (optionnel, activable par organisation)

• Qualification de l'analyse (criticité, données personnelles, exposition, RSSI interne…) produisant des orientations ;
• Statut réglementaire : détection proactive du régime NIS2 (entité essentielle / importante selon le secteur), marqueurs OSE / EEI / OIV avec sélection de la filière OIV (12 filières SAIV), signalement du cumul OIV (LPM) + EEI (NIS2) et du fait que DORA prime sur NIS2 pour la finance ;
• obligations contextualisées (enregistrement, notification d'incident au CSIRT/ANSSI — ou au CERT Santé/ANS pour la santé, exercice de crise SIIV…) ;
• classification de l'information (marqueur IGI-1300 : NP / DR / Secret / Très Secret) ;
• alerte RGPD art. 9 en présence de données sensibles ;
• notes de valorisation du rapport : documentation du risque ICT (DORA art. 8), pièce d'un dossier d'homologation SSI (PSSIE / RGS / IGI 1300), évaluation ORSA (Solvabilité II) pour l'assurance ;
• couverture NIS2 Art. 21 du référentiel de mesures choisi.

IA générative — les risques émergents liés à l'IA générative (deepfakes, hameçonnage assisté, fuite de données via « Shadow AI », prompt injection) figurent dans les exemples par défaut, tous secteurs.

Ces éléments sont documentaires et non bloquants : ils guident et alertent, mais l'analyste reste libre de ses choix.

ACRA gère plusieurs organisations dans une seule instance, organisées en arbre (chemin matérialisé). Une seule installation couvre quatre cas d'usage :

Appartenances & portée — chaque membre a un rôle par organisation et une portée NODE (cette organisation) ou SUBTREE (organisation + descendants, pour la vision consolidée). L'isolation est centralisée : toutes les vues filtrent les analyses sur le périmètre de l'organisation active (sélecteur d'organisation dans l'en-tête).

Vue consolidée — lorsqu'un périmètre couvre plusieurs organisations (RSSI groupe), le tableau de bord, les risques et les tiers indiquent l'entité d'origine de chaque élément.

Configuration par organisation — chaque organisation peut avoir ses propres échelles d'écosystème, exemples, référentiels et options ; une organisation sans valeur hérite de ses ancêtres, puis des défauts.

Échelles de risque — réglage d'instance modifiable par le super-administrateur :

• Communes (mode groupe) : même échelle gravité/vraisemblance/matrice pour tous ;
• Par organisation (mode consultant) : chaque organisation définit ses propres échelles.

Rôles — un rôle d'instance SUPER_ADMIN gère les organisations et traverse tous les périmètres ; l'ADMIN devient administrateur d'une organisation. Le 1ᵉʳ compte d'une nouvelle installation est SUPER_ADMIN ; sur une instance existante, le plus ancien administrateur est promu automatiquement au premier démarrage. Un super-administrateur peut promouvoir d'autres comptes (au moins un super-administrateur est toujours préservé).

Logos — chaque organisation reçoit par défaut un logo généré automatiquement (dégradé déterministe + monogramme), affiché dans le sélecteur d'organisation et l'administration.

Administration : Admin → Organisations (réservé au super-administrateur) — arbre, création d'organisations, gestion des appartenances, mode des échelles.

L'interface est disponible en 5 langues, sélectionnable à tout moment dans le profil :

Pour ajouter une langue, copier src/lib/i18n/fr.ts, traduire toutes les clés et enregistrer le fichier avec le code ISO 639-1 correspondant. TypeScript vérifiera automatiquement que toutes les clés sont présentes.

En multi-organisation, le rôle est porté par organisation (un même compte peut être ADMIN d'un client et ANALYSTE d'un autre) et limité au périmètre de l'organisation active. Les accès peuvent également être accordés analyse par analyse (partage ponctuel avec n'importe quel utilisateur).

# Vérifier l'état des conteneurs
docker compose ps

# Voir les logs détaillés
docker compose logs app
docker compose logs migrator

# Vérifier que les ports sont libres
lsof -i :3000
lsof -i :5432

# Forcer la régénération des migrations
docker compose exec app npx prisma migrate resolve --applied "nom_migration"
docker compose exec app npx prisma migrate deploy

# Vérifier la connectivité
docker compose exec app npx prisma db execute --stdin <<< "SELECT 1;"

# Vérifier la variable DATABASE_URL dans .env
docker compose exec app env | grep DATABASE

# ⚠️ Efface toutes les données
docker compose down -v
docker compose up -d

Voir CONTRIBUTING.md pour le guide complet.

TL;DR :

1. Forker le dépôt et créer une branche feature/ma-feature
2. Écrire les tests d'abord (TDD obligatoire — voir CLAUDE.md)
3. Implémenter et vérifier que npm test passe en vert
4. Ajouter les traductions dans les 5 fichiers i18n si des chaînes UI sont ajoutées
5. Lancer npx tsc --noEmit — zéro erreur TypeScript
6. Ouvrir une Pull Request avec une description claire

MIT — voir LICENSE

La méthode EBIOS RM est développée et maintenue par l'ANSSI. Cette application n'est pas affiliée à l'ANSSI.