Bienvenue dans la simulation

PULSE met en scène une crise médiatique fictive en temps réel. Vous y entrez comme observateur d'un mur de publications - tweets, articles de presse, réactions du public - qui se déroulent sous vos yeux comme si la crise se passait maintenant. Votre mission : analyser la situation, identifier les messages clés et préparer des décisions de communication.

Anatomie de l'écran

L'interface du joueur est structurée en deux colonnes synchronisées et un bandeau de pilotage en haut.

Le bandeau de pilotage

• Chronomètre T+ - temps écoulé depuis le démarrage de l'exercice (ex. T+12:34).
• Voyant EN DIRECT - indique si le rafraîchissement automatique des sources réelles est actif.
• Filtres presse (Tous · France · Régionaux · Internationaux) - filtre la colonne presse par origine du média.
• Tri - bascule entre « Les plus récents » et « Les plus anciens ».
• Pilule « N nouvelles publications » - apparaît en haut d'une colonne lorsque vous avez scrollé vers le bas et que de nouveaux items sont arrivés. Cliquez-la pour remonter en douceur.
• Toggle de rafraîchissement - bouton accessible (rôle ARIA switch) pour activer/désactiver la mise à jour live.

Lire les indicateurs

Les chiffres flashent quand ils sautent significativement, et un petit +N s'affiche brièvement à côté du compteur. Sur un tweet haineux qui décolle, un pulse rouge accompagne la montée.

Reconnaître les types d'acteurs

Pendant l'exercice, vous croiserez plusieurs profils - chacun avec son ton et son intention. Apprendre à les distinguer rapidement est l'un des bénéfices pédagogiques de PULSE.

Cliquer, zoomer, ouvrir

• Cliquer sur un article presse ouvre une vue agrandie (image, titre, chapô, signature) en plein écran. Cliquez ailleurs ou sur la croix pour fermer.
• Cliquer sur l'image d'un tweet l'ouvre en grand.
• Cliquer sur le lien externe d'un tweet (si présent) ouvre l'URL d'origine dans un nouvel onglet.
• Les citations imbriquées dans un tweet sont elles-mêmes lisibles intégralement sans clic supplémentaire.

Votre mission pendant l'exercice

• Observer en continu : qui parle ? que dit-on ? à quelle vitesse cela monte ?
• Distinguer les sources officielles, les journalistes, les rumeurs et les réactions émotionnelles.
• Identifier les narratifs émergents (soutien, mise en cause, complotisme, ironie…).
• Repérer le basculement - moment où une rumeur devient dominante, ou un tweet anodin part en viral.
• Préparer des décisions de communication adaptées : réponse, silence, clarification, prise de parole publique, ton à adopter.

Ce que vous ne pouvez pas faire

Le mur joueur est en lecture seule. Vous ne pouvez ni publier, ni effacer, ni modifier les contenus, ni interagir directement avec les comptes affichés. Les outils de réponse sont propres aux animateurs et observateurs. Vos décisions se prennent autour de l'écran (cellule de crise, oral, écrit hors plateforme), pas sur l'écran.

Conseils pour une session efficace

• Prenez des notes séparément - sur papier, dans un éditeur ou dans la grille fournie par votre formateur.
• Marquez l'heure réelle régulièrement pour ne pas perdre le sens du temps simulé.
• Méfiez-vous des biais : effet de récence (le dernier tweet n'est pas toujours le plus important), confirmation (vous voyez ce que vous cherchez), polarisation (les haters attirent l'œil mais représentent peu).
• Distinguez fait, opinion, rumeur avant de citer une source dans une décision.
• Si vous travaillez en équipe, répartissez la veille : un sur X, un sur la presse, un sur les indicateurs.

FAQ

Glossaire express

Tweet

Publication courte (≤ 280 caractères) sur Twister.

Repost

Republication telle quelle d'un tweet existant pour le diffuser à son audience.

Citation

Republication accompagnée d'un commentaire - souvent pour soutenir, contredire ou ironiser.

Viral

Publication dont la diffusion explose en peu de temps. Marquée 🔥 dans PULSE pour signaler l'effet.

Narratif

Histoire dominante qui se forme autour d'un événement (« c'est un complot », « ils ont caché », « solidarité »).

EN DIRECT

Indique une source réelle (compte X surveillé, flux RSS d'un média).

T+

Temps écoulé depuis le démarrage de l'exercice. T+05:30 = 5 minutes 30 après le top départ.

Hater

Compte agressif, accusateur, parfois complotiste. Représente la part toxique d'un débat public.

Empathie

Réaction centrée sur les victimes : compassion, inquiétude, espoir.

Complotisme

Narratif affirmant qu'un acteur cache la vérité ou orchestre l'événement.

Démarrage rapide (5 minutes)

1. Depuis l'accueil, cliquez Salle de rédaction (mot de passe ou lien d'accès animateur requis).
2. Renseignez le Contexte de l'exercice (client, scénario, acteurs clés) - ce contexte alimente toute l'IA derrière les injects et les réactions.
3. Composez quelques publications manuellement ou cliquez ✨ Générer des injects IA.
4. Programmez les publications avec un décalage T+ minutes et activez les sources live pertinentes.
5. Cliquez ▶ Démarrer : le chronomètre démarre, les injects se déclenchent à l'heure et les sources live s'allument.

Checklist pré-exercice

• ☐ Contexte rempli (au minimum : client, objectif, scénario)
• ☐ 6 à 12 injects scénarisés sur les 30 premières minutes
• ☐ Une ou deux sources live activées (au moins un compte ou un flux pertinent)
• ☐ Liens d'accès générés et envoyés aux participants (rôles player / observer)
• ☐ État des APIs vérifié dans le Configurateur (Twister et Anthropic OK)
• ☐ Mur de crise testé sur l'écran de projection (si présentiel)
• ☐ Briefing pédagogique aux participants (mission, durée, débrief)

Connexion et accès

Deux moyens d'arriver dans la Salle de rédaction :

• Mot de passe applicatif - saisi sur la page de connexion. Rôle admin ou player selon le mot de passe utilisé.
• Lien d'accès signé (JWT) - généré par l'administrateur dans le Configurateur. Le lien encode votre rôle (facilitator, player, observer, admin) et expire après une durée définie (48 h par défaut).

Configurer le contexte de l'exercice

Le contexte est la matière première de toute l'IA. Plus il est précis, plus les injects et les réactions sont crédibles.

Composer une publication Twister

Composer un article Média Presse

Composer un prompt PNJ (cue animateur)

Le format Prompt n'apparaît pas sur le mur joueur - c'est une instruction privée pour l'animateur, pour mettre en scène un appel téléphonique, un mail interne, une remontée terrain, etc.

Génération IA d'injects

Cliquez ✨ Générer des injects IA. PULSE envoie le contexte de l'exercice au modèle claude-sonnet-4-6 (via l'API Anthropic) et reçoit en retour 5 publications variées : tweets officiels, journalistes, citoyens, articles de presse - équilibrées 50/50 entre X et presse.

Chaque inject est livré avec une justification pédagogique qui explique son intention. Cliquez Utiliser sur un inject pour pré-remplir le formulaire correspondant - vous pouvez ensuite l'éditer avant de le programmer.

Conseils pour des injects de qualité

• Renseignez un contexte concret (lieux, noms, chiffres) - l'IA brille avec des éléments factuels.
• Précisez la posture du client (transparent, défensif, en retrait, sur la défensive…) dans le scénario.
• Listez les acteurs clés avec leur ligne (ex. « Mme Roussel, association de victimes - exige des sanctions »).
• Régénérez (cliquez à nouveau) si le résultat ne colle pas - la production est non-déterministe.

Limites

• Quota Anthropic : 20 requêtes/min par défaut (modifiable via RATE_LIMIT_MAX_ANTHROPIC).
• Les injects sont persistés côté serveur et survivent à un rechargement de page.
• Un inject « utilisé » n'est pas effacé - il sert de matière jusqu'à ce que vous le supprimiez explicitement.

« Trouver une image » 🔍

Le bouton 🔍 Trouver une image, présent sous les champs Image URL des composeurs X et Presse, demande à l'IA de chercher en ligne (via la recherche web Anthropic) une image pertinente pour le contenu rédigé. La requête envoie le contenu du tweet ou le titre/chapô de l'article comme topic. PULSE filtre les résultats qui ressemblent à des logos.

Si aucune image n'est retournée, c'est généralement que le sujet est trop vague, trop sensible ou que la recherche web n'a pas trouvé de visuel pertinent. Saisissez alors une URL manuellement, ou laissez le champ vide (la publication s'affichera sans illustration).

Programmation T+ minutes

Saisissez un décalage T+ (minutes) dans le champ offset-min et cliquez + Programmer. Une fois l'exercice démarré, les publications se déclenchent automatiquement à startTime + offsetMin, côté serveur – indépendamment de l'onglet animateur.

Dans la liste « Publications programmées » :

Boutons disponibles sur chaque entrée : ▶ Publier maintenant (force l'envoi immédiat), Modifier, Supprimer, et - sur les injects envoyés - les trois boutons de réactions (👍 / 💙 / 😡).

Export / Import JSON et chronogramme Excel

Le scénario complet (publications + offsets) peut être exporté/importé au format JSON depuis l'interface. Un import Excel (.xlsx chronogramme) est également supporté avec génération IA d'une couverture médiatique cohérente.

Sources live (Twister + RSS)

Les sources live sont activées automatiquement au démarrage de l'exercice et coupées au stop. Elles sont limitées à 20 entrées par type.

Réactions automatiques (👍 💙 😡)

Sur chaque publication envoyée, trois boutons déclenchent une vague de 6 réactions générées par l'IA. Les tweets n'arrivent pas tous d'un coup : ils sont distribués aléatoirement sur ~1 minute pour un effet de montée réaliste — pendant la distribution, le bouton pulse et son compteur grimpe au fil des arrivées.

Dosage pédagogique

• Une vague positive après une déclaration officielle réussie → renforce la perception de maîtrise.
• Une vague compatissante après l'évocation des victimes → recentre le débat sur l'humain.
• Une vague haineuse après un tweet ambigu → met les participants à l'épreuve de l'attaque.
• Évitez d'enchaîner trois vagues consécutives : laissez le mur respirer entre les pics.

Indicateurs de réputation

Le panneau Réputation de la salle de rédaction agrège tonalité (positif / négatif / neutre), volume et tendance, avec un sparkline temporel. La classification est faite par l'IA via /api/sentiment (5 catégories : very_negative, negative, neutral, positive, very_positive). Utilisez-le comme aide à la décision pour ajuster votre prochain inject.

Gestion de l'exercice

Inviter des participants

Depuis le Configurateur, page Accès, choisis l'exercice dans la liste déroulante (peuplée des exercices réels), puis génère un lien d'accès signé pour chaque rôle :

• player - accès au mur de crise (lecture seule).
• observer - accès à la salle d'observation (timeline, chat, KPIs).
• facilitator - accès animateur (composer, programmer, gérer l'exercice).
• admin - tous les droits, y compris Configurateur.

Durée de validité par défaut : 48 heures (configurable via ACCESS_TOKEN_TTL_HOURS). Un lien peut être révoqué à tout moment depuis la liste des liens actifs (la session du porteur est coupée en temps réel).

Bonnes pratiques pédagogiques

Briefing

• Annoncer la durée de l'exercice et la posture de l'équipe (cellule de crise, comité de pilotage…).
• Expliquer la nature fictive du contenu et la présence éventuelle de sources réelles.
• Définir les livrables : décisions, communiqués, posture face à un journaliste.

Escalade dramaturgique

• 0-10 min : faits, premières remontées terrain, articles courts.
• 10-25 min : montée de la pression - viral, journalistes qui appellent, premiers haters.
• 25-40 min : pic - rumeurs, théories, réactions politiques, déclencheurs critiques.
• 40 min+ : retombée orchestrée ou point de bascule sur un sujet adjacent.

Débriefing

• Faire identifier le point de bascule par les participants - quand la situation a changé de nature.
• Reprendre 3 à 5 publications-clés et discuter la décision prise (ou non).
• Noter ce qui a manqué : info, posture, réactivité, coordination.

Dépannage animateur

Raccourcis clavier

PULSE n'expose pas de raccourcis clavier globaux dans cette version. La navigation se fait au Tab sur les contrôles, et la touche Entrée dans les champs Source Twister et Source RSS ajoute la source.

Le rôle de l'observateur

L'observateur suit l'exercice sans pouvoir intervenir sur le mur de crise. Il dispose en revanche d'outils dédiés que les joueurs ne voient pas : timeline détaillée du scénario, indicateurs de fréquentation, bloc-notes personnel et chat avec l'animateur. Sa mission : évaluer, conseiller, capitaliser.

Différences avec la vue joueur

Se connecter en observateur

L'observateur arrive via un lien d'accès signé de rôle observer, généré par l'animateur ou l'administrateur depuis le Configurateur. Pas de mot de passe à retenir.

Si vous n'avez reçu qu'un jeton brut, collez-le dans l'onglet Lien d'accès de la page de connexion : PULSE le redirigera automatiquement vers la salle d'observation.

Timeline du scénario

La salle d'observation affiche les injects programmés en deux sections :

Cliquez un inject passé (X ou presse) pour ouvrir sa fiche détaillée. Les prompts animateur ouvrent une modale dédiée avec les champs Émetteur / Récepteur / Stimuli / Réaction attendue.

Chat observateur

Panneau collapsible relié à la route /api/observer-messages. Permet d'échanger avec l'animateur sans passer par les joueurs : poser une question, signaler un dysfonctionnement, proposer un inject.

• Un badge unread compte les messages reçus quand le panneau est replié.
• Les bulles sont alignées à gauche (animateur) ou à droite (observateur) selon l'auteur.
• L'historique est conservé tant que l'exercice n'est pas reset (max 200 messages).

Bloc-notes personnel

Notes locales, sauvegardées dans le localStorage du navigateur (clé pulse_observer_notes_v2). Maximum 100 entrées horodatées.

• + Ajouter : crée une nouvelle note datée (heure courante).
• × : supprime une note.
• 🗑 Effacer tout : vide toutes les notes.
• 📋 Copier : copie l'ensemble des notes au format [HH:MM] texte, prêt à coller dans un rapport.

KPIs en temps réel

Construire un rapport d'observation

PULSE n'inclut pas d'export automatique des observations. Voici la méthode recommandée :

1. Pendant l'exercice : prenez vos notes au fil de l'eau dans le bloc-notes (un événement clé = une note).
2. À la fin : 📋 Copier le bloc-notes dans votre traitement de texte.
3. Capturez les KPIs finaux et le statut de l'exercice (REPOS / TERMINÉ).
4. Notez 3 à 5 moments charnières repérés (basculement, raté, bonne décision, montée virale).
5. Ajoutez votre évaluation de l'équipe : posture, coordination, vitesse de réaction, qualité des décisions.

Bonnes pratiques d'observation

• Repérer les biais d'équipe : effet de tunnel sur un seul narratif, sous-estimation d'un acteur, sur-réaction à un viral isolé.
• Mesurer la latence entre l'arrivée d'un inject critique et la première décision.
• Distinguer signal et bruit dans les haters : un viral haineux peut être un faux drapeau du scénario.
• Ne pas spoiler via le chat : posez vos questions à l'animateur, pas aux joueurs.
• Préparez à l'avance une grille d'évaluation (critères : réactivité, qualité des arbitrages, communication interne, cohérence externe).

Limites connues

• Aucune intervention sur le mur n'est possible depuis la vue observateur.
• Le bloc-notes est strictement local - non sauvegardé côté serveur, non partageable depuis l'app.
• Les messages observateur sont plafonnés à 200 par exercice.
• Pas d'export PDF automatique : recopiez à la fin.

1. Vue d'ensemble

PULSE est une application Node.js / Express servie en SPA. Le backend expose une API REST (et un canal SSE) consommée par un frontend HTML/CSS/JS vanilla. Le stockage est dual : fichier data/store.json pour le développement local, Azure Cosmos DB en production. Les intégrations externes sont l'API Anthropic (Claude Sonnet 4) et l'API Twister v2, plus la lecture de flux RSS.

Cette doc couvre la version 2.1.0-rc.69. Vérifiez CHANGELOG.md pour les évolutions.

2. Architecture de déploiement

┌──────────────┐    HTTPS    ┌─────────────────────────────────┐
│  Navigateurs │────────────▶│         Express (Node 18+)      │
│  (joueurs,   │◀────────────│  ┌───────────────────────────┐  │
│   anim, obs) │  SSE / JSON │  │  Routes /api/*  + /auth   │  │
└──────────────┘             │  │  helmet · CORS · rate-lim │  │
                             │  └───────────────────────────┘  │
                             │  ┌───────────────────────────┐  │
                             │  │  memoryStore (in-process) │  │
                             │  └─────┬───────────────┬─────┘  │
                             └────────┼───────────────┼────────┘
                                      │               │
                              ┌───────▼─────┐  ┌──────▼──────┐
                              │ data/store  │  │  Cosmos DB  │
                              │   .json     │  │  (optional) │
                              └─────────────┘  └─────────────┘

           Externes :
           ┌────────────┐   ┌────────────┐   ┌────────────┐
           │ Anthropic  │   │  Twister   │   │  RSS feeds │
           │ Claude API │   │  v2 API    │   │  (HTTP)    │
           └────────────┘   └────────────┘   └────────────┘

• Port d'écoute : variable PORT (défaut 3000).
• Processus : un seul process Node (pas de cluster). Préférer un reverse-proxy (Nginx, Caddy, Azure App Service) pour HTTPS et la terminaison TLS.
• Trust proxy : si derrière un reverse proxy, exporter TRUST_PROXY=1 ou un range CIDR - sinon express-rate-limit et le logging d'IP seront erronés.
• Stockage authoritative : Cosmos DB si COSMOS_ENDPOINT et COSMOS_KEY sont définis ; sinon fichier local.

3. Prérequis

• Node.js ≥ 18 (déclaré dans package.json · engines).
• npm (livré avec Node).
• Compte Anthropic avec une clé API valide (modèle claude-sonnet-4-6).
• Compte Twister Developer avec un Bearer Token v2.
• Stockage : un disque inscriptible pour data/store.json, ou un compte Azure Cosmos DB (recommandé en production).
• Optionnel : Application Insights (Azure) pour la télémétrie.

4. Variables d'environnement

Toutes lues dans src/config/env.js. Mettez-les dans un fichier .env à la racine ou dans la configuration de votre PaaS.

Obligatoires

Réseau et runtime

Authentification – IAM passwordless (WebAuthn) depuis v2.1.0-rc.15

Rate limiting

Stockage Cosmos DB (optionnel)

Observabilité (optionnel)

5. Installation locale

git clone <repo>
cd simulateur-crise
cp .env.example .env       # à créer si absent
# éditer .env avec vos clés API
npm install
npm run dev                # nodemon, hot reload
# ou
npm start                  # mode production simple
npm test                   # jest

Au premier démarrage, data/store.json est créé s'il n'existe pas. L'application est disponible sur http://localhost:3000.

6. Déploiement en production

Pipeline officiel – push main → PROD/staging auto, slot swap manuel pour le live

Le dépôt déploie via un seul workflow GitHub Actions, sur le slot staging de l'App Service pulse-simulator-prod. Le slot production (live, https://pulse.secalys.fr) ne se met à jour qu'après un slot swap manuel.

Flux nominal :

1. PR mergée sur main → le workflow PROD/staging part automatiquement, version disponible sur le slot staging.
2. Validation fonctionnelle sur le slot staging (Cosmos PROD données réelles).
3. Slot swap dans Azure Portal → App Service → Deployment Slots → Swap (source: staging, target: production). Ou en CLI : az webapp deployment slot swap --resource-group <rg> --name pulse-simulator-prod --slot staging --target-slot production.
4. Swap instantané et réversible – re-swap dans l'autre sens pour rollback.

Azure App Service (provisionnement initial / fork)

1. Créer une App Service Linux avec le runtime Node 18 LTS.
2. Configurer les variables d'environnement dans Configuration → Paramètres applicatifs. Ne jamais committer .env.
3. Activer HTTPS uniquement et un domaine custom avec certificat managé.
4. Définir NODE_ENV=production. TRUST_PROXY est auto-détecté sur App Service (défaut 1) – ne le poser que si le setup utilise une chaîne de proxies non-standard.
5. (Recommandé) Provisionner un compte Cosmos DB et renseigner COSMOS_ENDPOINT / COSMOS_KEY.
6. (Recommandé) Lier une instance Application Insights - la string de connexion est lue automatiquement.
7. Déploiement par git push, GitHub Actions, ou ZIP deploy. Build = npm install --omit=dev, start = npm start.

Conteneur (Docker générique) à confirmer

Aucun Dockerfile n'est fourni dans le repo. Pour packager :

FROM node:20-alpine
WORKDIR /app
COPY package*.json ./
RUN npm ci --omit=dev
COPY . .
ENV NODE_ENV=production
EXPOSE 3000
CMD ["node", "src/server.js"]

Gestion des secrets

• Ne jamais commiter de .env contenant des clés réelles.
• Sur Azure, utiliser Key Vault (référencé depuis App Service Configuration).
• Documenter le canal de rotation des clés (Anthropic, Twister, JWT, mots de passe applicatifs).

Durcissement runtime des slots (état appliqué – 2026-05-17)

Les deux slots (production = slot par défaut, staging = --slot staging) sont configurés avec les paramètres runtime ci-dessous. À reporter à l'identique sur tout nouveau slot ou fork.

Logs plateforme – filet hors Application Insights (#137), activés sur les deux slots : applicationLogs.fileSystem = Information (le log stream montre la sortie pino / requestId), detailedErrorMessages = true (stack trace sur 5xx), failedRequestsTracing = true, httpLogs.fileSystem = true (cap 35 Mo déjà posé). Filet si Application Insights cesse d'ingérer (incident région, quota, mauvaise config workspace #138).

Vérifier l'état après tout (re)provisionnement ou passage du wizard OIDC (qui peut réécrire la config du site) :

RG=rg-pulse-prod ; APP=pulse-simulator-prod
for SLOT in "" "--slot staging"; do
  az webapp show   -g $RG -n $APP $SLOT --query "{httpsOnly:httpsOnly}" -o jsonc
  az webapp config show -g $RG -n $APP $SLOT --query "{alwaysOn:alwaysOn,use32:use32BitWorkerProcess,http20:http20Enabled,healthCheckPath:healthCheckPath}" -o jsonc
  az webapp log show -g $RG -n $APP $SLOT --query "{appLogFs:applicationLogs.fileSystem.level,detailedErrors:detailedErrorMessages.enabled,failedReqTracing:failedRequestsTracing.enabled,httpLogsFs:httpLogs.fileSystem.enabled}" -o jsonc
done

Accès SCM / Kudu – Basic Auth désactivé (AAD-only, 2026-05-17)

L'endpoint d'administration SCM/Kudu (déploiement ZIP, console, log stream, dump d'environnement) n'accepte plus que l'authentification Microsoft Entra (AAD) : le Basic Auth (publishing profile / mot de passe SCM, réutilisable depuis n'importe où) est désactivé sur les deux slots.

Le pipeline GitHub Actions déploie en OIDC (azure/login + token AAD, aucun publishing-profile) – il n'est pas impacté (validé par un déploiement de test après le changement). L'accès admin manuel passe par le Portail Azure ou az (AAD), sans secret statique.

Vérifier l'état (à rejouer après tout (re)provisionnement ou wizard OIDC) :

RG=rg-pulse-prod ; APP=pulse-simulator-prod
for SCOPE in "sites/$APP" "sites/$APP/slots/staging"; do
  for POL in scm ftp; do
    az resource show -g $RG --namespace Microsoft.Web \
      --resource-type basicPublishingCredentialsPolicies \
      --name $POL --parent "$SCOPE" --query properties.allow -o tsv
  done
done

7. Configurateur (UI admin)

Réservé au rôle admin. L'icône engrenage de l'en-tête a été retirée : le Configurateur s'ouvre désormais par navigation directe (deep-link #ws=configurator). Pages :

État

• Statut des APIs externes (Twister, Anthropic) : OK / KO avec dernier test.
• Métriques runtime : version, uptime, environnement, taille du feed/scénario, état de l'exercice.

Tests

• Test Twister : exécute une requête de recherche brute pour valider le bearer.
• Test Anthropic : envoie un prompt minimal pour valider la clé et la connectivité.
• Sortie en clair pour debug.

Accès & Sécurité

• Écran IAM nominatif (onglets Vue d'ensemble / Comptes / Accès applicatif / Sessions / Stratégies), piloté par public/js/iam.js, gardé par la session serveur nominative.
  • Vue d'ensemble : 4 KPI (comptes actifs, sessions actives, comptes avec passkey de secours en %, comptes désactivés) ; carte « État de sécurité » avec badge de conformité calculé (Conforme / Partiellement conforme / Non conforme) et 4 contrôles cliquables (passkey de secours, codes de récupération, sysadmins actifs, audit) renvoyant vers l'onglet Comptes ; cartes Actions rapides et Informations clés. La couverture « passkey de secours » mesure les comptes à ≥IAM_MIN_CREDENTIALS passkeys (défense en profondeur anti-lockout, pas un seuil bloquant) ; « codes de récupération » compte les comptes ayant au moins un code non consommé (2ᵉ filet, D12b).
  • Comptes : création ({ email, displayName?, role } → réponse { user, enrolToken, expiresAt } à transmettre hors-bande au titulaire pour son 1ᵉ enrôlement), liste avec compteur passkeys + état codes de récupération, reset assisté sysadmin (révoque passkeys + sessions, ré-émet un enrolToken usage-unique).
  • Sessions : liste + révocation autoritaire (le cookie applicatif iam_sid est lié à la session – révocation = coupe immédiate de tout /api/*, pas seulement de l'écran admin).
  • Stratégies : champs lecture seule (D10) – rpId, minCredentialsPerAccount, webauthnUvRequired, TTL sessions admin/sysadmin, fenêtre + seuil de lockout.
• Sur son propre compte, le panneau IAM expose : « Ajouter une passkey à cet appareil » (enrôle une 2ᵉ / 3ᵉ clé, indispensable pour rester sous IAM_MIN_CREDENTIALS), « Régénérer mes codes de récupération » (révélés une seule fois, à conserver hors-bande), liste + suppression de ses propres passkeys (garde min. impose ≥2 – refuse la suppression de l'avant-dernière).
• Mire de connexion (WU9 + v2.1.0-rc.19) : section passkey primaire avec boutons « Se connecter avec la passkey » + « Utiliser une autre passkey » (login usernameless, aucun champ – navigator.credentials.get, allowCredentials vide), entrée « Utiliser un code de récupération » (redeem du code → jeton d'enrôlement immédiat sans session → ré-enrôlement d'une passkey directement depuis la mire), et entrée « Activer mon accès avec un jeton d'enrôlement » (panel tab-activate) — un seul champ pour coller l'enrolToken reçu hors-bande après création de compte ou reset assisté, sans étape recovery/redeem préalable (un compte fraîchement créé n'a pas encore de codes de récupération).
• Greenfield / poule&œuf : sur une install vierge (BOOTSTRAP_SYSADMIN_EMAIL non posé ou compte sysadmin pas encore enrôlé), POST /iam/bootstrap { email } est ouvert tant qu'aucun sysadmin actif n'existe – il crée le compte vide et retourne un enrolToken pour son 1ᵉ enrôlement de passkey via /iam/webauthn/register/*. Auto-fermé ensuite (409 dès qu'un sysadmin existe).
• Onglet Accès applicatif : génération de liens JWT d'exercice (exerciseId, role, ttlHours) – gardée par votre session nominative (cookie iam_sid, plus aucune clé partagée). Contrat JWT inchangé (R6) : les liens existants émis avant la bascule passwordless restent valides jusqu'à expiration.
• Historique en mémoire des liens créés pendant la session.

Clés API

• Inputs masqués pour TWISTER_BEARER_TOKEN et ANTHROPIC_API_KEY.
• Rotation à chaud : la sauvegarde appelle POST /api/settings/keys, qui réécrit .env et met à jour les variables process en mémoire.
• Audit : événement API_KEY_UPDATED dans le journal d'activité.

Sources

• Personnalisation des suggestions (comptes Twister et URLs RSS) proposées aux animateurs.
• Stocké dans store.suggestedSources.

Journaux

• Onglet Activité : 500 dernières actions persistées (login, logout, password change, key update, state change, reset, feed cleared, access link). IPs tronquées.
• Onglet Erreurs : erreurs serveur en mémoire (effacées au redémarrage).
• Boutons : ↻ Actualiser, 🗑 Purger l'activité (admin), 🗑 Effacer les erreurs.

8. IAM nominatif – comptes admin/sysadmin (passwordless WebAuthn)

Sources : src/security/iamUsers.js, iamSession.js, iamWebauthn.js, iamRecovery.js, src/routes/iamAuth.js, iamAdmin.js. Depuis v2.1.0-rc.15 (WU11), l'auth humaine est exclusivement WebAuthn / passkey : tout mot de passe et TOTP a été retiré, l'écran de connexion ne propose plus que la passkey ou un code de récupération.

• Comptes : admin (« Administrateur fonctionnel » – opère & lit) et sysadmin (« Administrateur global » – gère aussi les comptes). Email + rôle, aucun mot de passe (champ users.pwd retiré du modèle, jeté au boot par _normalizeUser). D7 : l'UI ne montre les actions mutantes (créer/désactiver/supprimer/reset assisté/tout révoquer) qu'au sysadmin ; un admin est en lecture seule (le serveur refuse 403 de toute façon).
• Login passwordless WebAuthn (D2′/D3′) : POST /iam/webauthn/login/options|verify – usernameless (passkey découvrable, allowCredentials: [], l'OS/navigateur choisit la clé), User Verification = 2ᵉ facteur (biométrie/PIN), défi usage-unique lié IP (anti-rejeu R4), RP ID = IAM_WEBAUTHN_RP_ID (défaut secalys.fr). Session pleine émise à la vérification (plus de mfaPending).
• Enrôlement & gestion des passkeys : POST /iam/webauthn/register/options|verify + GET/DELETE /iam/webauthn/credentials – gardés par session pleine ou par enrolToken usage-unique (cf. bootstrap / reset / recovery). Garde minimum : ≥IAM_MIN_CREDENTIALS passkeys par compte (défaut 2, anti-lockout R1 / D12a) – refuse la suppression de l'avant-dernière.
• Récupération anti-lockout (codes – D12) : POST /iam/recovery/codes (session pleine) génère IAM_RECOVERY_CODE_COUNT codes à usage unique, hashés SHA-256 au repos, affichés une seule fois à conserver hors-bande (gestionnaire de mots de passe, coffre-fort). POST /iam/recovery/redeem (public, authLimiter, anti-énumération R4 – réponse générique en cas d'échec) → jeton d'enrôlement usage-unique pour ré-enrôler une passkey sans session après perte de tous les authentificateurs.
• Reset assisté sysadmin (D12c) : POST /iam/admin/users/:id/reset-credentials (réservé sysadmin, D7) – pour un compte verrouillé, révoque toutes ses passkeys + sessions actives et émet un enrolToken à usage unique, TTL IAM_ASSISTED_GRANT_TTL_MIN (défaut 30 min), à transmettre hors-bande. Le titulaire ré-enrôle ensuite une passkey via /iam/webauthn/register/* sans session.
• Sessions serveur persistées (cookie opaque iam_sid, httpOnly, Secure en prod, SameSite=Lax) : TTL 12 h (admin) / 8 h (sysadmin), inactivité 2 h, listables & révocables. Verrouillage compte après 5 échecs / 15 min (à la fenêtre près). Révocation autoritaire : le cookie applicatif est lié à la session – révoquer (ou expiration / inactivité / désactivation) coupe immédiatement tout /api/*, pas seulement l'écran admin.
• Bootstrap 1ᵉ sysadmin (greenfield) : POST /iam/bootstrap { email }, gardé par l'invariant « 0 sysadmin actif » – auto-fermé (409) dès qu'un sysadmin existe. Réponse { user, enrolToken, expiresAt } : le jeton émis sert à enrôler la 1ʳᵉ passkey via /iam/webauthn/register/*. Variante App Settings : BOOTSTRAP_SYSADMIN_EMAIL au démarrage crée un compte sysadmin vide au boot (idempotent) ; l'enrôlement initial passe alors par le même flow /iam/bootstrap.
• Break-glass (déblocage d'urgence) : POST /iam/break-glass { email } – mécanisme de dernier recours quand tous les sysadmins sont verrouillés (aucune passkey, aucun code de récupération) et que /iam/bootstrap est fermé. Désactivé par défaut : l'endpoint répond 404 tant que la variable d'environnement IAM_BREAK_GLASS_SECRET n'est pas posée. Une fois le secret configuré, un appel avec le header X-Break-Glass-Secret (comparé en timing-safe) émet un enrolToken pour le compte ciblé, injecté directement dans le store du worker. Le titulaire enrôle ensuite une passkey via l'écran « Activer mon accès ». À n'activer (poser le secret) que le temps de l'intervention, puis retirer le secret – l'endpoint redevient 404. Audité (IAM_BREAK_GLASS / IAM_BREAK_GLASS_DENIED).
• Invariant « dernier sysadmin » : impossible de désactiver, supprimer ou rétrograder le dernier sysadmin actif (refus serveur 409).
• Audit nominatif : création/maj de compte, reset assisté, génération/redeem de codes de récupération, enrôlement/suppression de passkey, révocation session, génération/révocation de lien d'exercice → journal d'activité (qui agit sur qui ; jamais de secret en clair, codes/clés jamais loggés).
• Cloisonnement : un JWT d'exercice (player/observer/facilitator) ne donne jamais accès au Configurateur ; l'IAM passe par la session serveur, pas par le JWT d'exercice.

9. Liens d'accès signés (JWT)

Source : src/security/accessTokens.js, src/routes/admin.js, src/routes/access.js.

• Algorithme : HS256 (signé avec ACCESS_TOKEN_SECRET).
• Payload : { exerciseId, role, jti, iat, exp }. Depuis la v2, exerciseId est un vrai id d'exercice du store (plus un texte libre) : POST /admin/access-link refuse (400) un exercice inconnu ou supprimé.
• Autorisation par exercice 🔒 (v2 / WU5) : le middleware requireExercise exige token.exerciseId === :id sur les routes RUN-DATA scopées /api/exercises/:id/… – sinon 403. Vaut pour tous les rôles, admin inclus. Un participant (player/observer) est aussi confiné en lecture de collection (GET /api/exercises filtré à son exercice, /:id → 404 sur un autre) ; un opérateur (facilitator/admin) garde la vue parc cross-exercice (mutations trainerAuth).
• Rôles valides : player, observer, facilitator, admin.
• Durée : ACCESS_TOKEN_TTL_HOURS (défaut 4 h ; ttlHours explicite possible à la génération).
• Génération : POST /admin/access-link – gardé par la session nominative IAM (admin|sysadmin, MFA validé ; cookie iam_sid). Plus aucun secret partagé (x-admin-key retiré). Le Configurateur choisit l'exercice dans un <select> peuplé de GET /api/exercises.
• Redemption : GET /access?token=<jwt> - valide, pose un cookie access_token (httpOnly, secure en prod, SameSite=Lax), redirige vers la page du rôle. Un anti-flood (accessRedeemLimiter) ne compte que les sondes à token invalide : les redemptions à token valide sont exemptées, donc une salle entière derrière une même IP n'est jamais bloquée.
• Révocation : liste de révocation par jti (DELETE /admin/access-links/:id) ; l'événement de révocation est diffusé sur le canal SSE GLOBAL (WU6) et coupe la session du porteur en temps réel, quel que soit son exercice. Changer ACCESS_TOKEN_SECRET invalide d'un coup tous les liens.

10. Logs et observabilité

Logger applicatif (pino)

• Niveau : debug en dev, info en prod.
• Format : JSON en prod, joliment formaté (pino-pretty) en dev.
• Source : src/utils/logger.js.

Application Insights

Initialisé dans src/app.js si APPLICATIONINSIGHTS_CONNECTION_STRING est défini. Auto-collecte requêtes HTTP, exceptions, dépendances et console. Le sampling est piloté par AI_SAMPLING_PERCENT (défaut 100%).

Journal d'activité

• Source : src/services/activityLog.js.
• Ring buffer de 500 entrées max, persisté dans le store.
• Schéma : { ts, type, severity, role, ip, message, meta }.
• IPs tronquées (/24 en IPv4, deux groupes en IPv6) pour limiter la collecte de données personnelles.
• Types nominatifs (passwordless) : LOGIN_SUCCESS (passkey vérifiée), LOGIN_FAILED (assertion invalide), LOGOUT, WEBAUTHN_REGISTER, WEBAUTHN_CREDENTIAL_REMOVED, RECOVERY_CODES_GENERATED, RECOVERY_REDEEMED, USER_RESET_CREDENTIALS (sysadmin → user), SESSION_REVOKED. Types applicatifs : API_KEY_UPDATED, ACCESS_LINK_CREATED, STATE_CHANGED, RESET_ALL.
• Lecture : GET /api/logs (rôles facilitator et admin).
• Purge : DELETE /api/logs/activity (admin).

Erreurs serveur

Buffer en mémoire, effacé au redémarrage (volatile). Lisible via GET /api/logs.

Consommation IA (Anthropic)

Source : src/services/anthropicMetrics.js, route GET /api/anthropic-metrics. Onglet Configurateur → Consommation IA.

• Capture du response.usage de chaque appel Anthropic (input, output, cache_creation, cache_read).
• Persistence dans store.anthropicMetrics – figures conservées au redémarrage et au /api/reset fonctionnel.
• Ring buffer des 50 derniers appels (catégorie, modèle, tokens, durée, statut) – base de l'activité récente affichée dans le panneau.
• Catégories internes : inject_generation, reactions_simulation, media_search, import_context, import_media, sentiment_analysis, tests_api, other. Les appels de l'onglet Tests API sont tracés sous tests_api avec un libellé display dédié « Tests API » – visible dans le panneau mais isolé visuellement (couleur grise) pour distinguer le diagnostic de la prod.
• Coût estimé : table de pricing par modèle (Sonnet 4, Haiku, Opus 4.7), conversion USD → EUR via EUR_USD_RATE (défaut 0.92). Le coût est agrégé par modèle (chaque modèle avec son propre tarif), ce qui reste juste depuis que les routes triviales tournent sur Haiku (cf. #144) : la tuile Modèle liste tous les modèles réellement utilisés, le plus appelé en tête.
• Cache hit rate = cache_read / (input + cache_create + cache_read). Cible ≥ 60 % depuis #16. Le panneau affiche le hit rate productif (restreint aux catégories qui posent cache_control : inject_generation, reactions_simulation, sentiment_analysis, import_media) avec le rate global en sous-ligne. Le hit rate global reste bas tant que le caching de media_search (web_search multi-tour, ~95 % du volume) n'est pas activé – voir #131.
• Économies = différence entre le coût réel et le coût équivalent si tous les tokens cache avaient été facturés au tarif input plein.
• Export : GET /api/anthropic-metrics/export.csv (50 derniers appels, séparateur point-virgule).
• Reset : DELETE /api/anthropic-metrics (admin uniquement) – purge cumulés, ring buffer et per-category. Lisible par admin et facilitator.

11. Sécurité

Helmet (CSP)

• scriptSrc : 'self' 'unsafe-inline' (rendu de templates dynamiques).
• styleSrc : 'self' 'unsafe-inline' https://fonts.googleapis.com.
• imgSrc : 'self' data: https:.
• connectSrc : 'self' (le SSE est en same-origin).

CORS

Liste blanche depuis ALLOWED_ORIGINS. En production, lister explicitement les domaines (pas de wildcard).

Rate limiting (express-rate-limit)

Cookies et sessions

• Cookie access_token (JWT d'exercice, lien /access?token=…) et iam_sid (session nominative opaque, ouverte par WebAuthn) : httpOnly, Secure en prod, SameSite=Lax.
• Rôles exercice (player/observer/facilitator) : état dans le JWT. Admin/sysadmin : session serveur persistée & révocable (iam_sid → lookup store ; révocation = coupure immédiate).

SSRF (route preview)

/api/preview résout les DNS de l'URL fournie et refuse toute IP privée, loopback ou link-local. Limite de fetch à 150 KB.

Durcissement

• NODE_ENV=production obligatoire en prod.
• HTTPS obligatoire (terminaison au reverse proxy).
• Restreindre les origines CORS au strict nécessaire.
• Tourner régulièrement Anthropic, Twister, ACCESS_TOKEN_SECRET (invalide tous les liens JWT d'exercice). ⚠ IAM_WEBAUTHN_RP_ID ne se tourne pas (invaliderait toutes les passkeys enrôlées – campagne de ré-enrôlement assisté requise sinon).

12. Sauvegarde et restauration

Mode local (store.json)

• Fichier unique : data/store.json.
• Sauvegarde : copie périodique du fichier (cron, sauvegarde du volume).
• Restauration : remplacer le fichier, redémarrer le process.

Mode Cosmos DB

• Document unique de partition type='state', id state.
• Activer le continuous backup Cosmos pour PITR (point-in-time restore).
• À la première lecture Cosmos vide, l'app migre store.json → Cosmos automatiquement.

Reset complet

POST /api/reset (rôle facilitator ou admin) - vide feed, scénario, sources, contexte, injects, messages observateur. Préserve l'auth et le journal d'activité.

13. Mise à jour

1. Lire CHANGELOG.md pour les changements et migrations éventuelles.
2. Pull du code : git pull.
3. npm install (réconcilie package-lock.json).
4. npm test (sanity check).
5. Redémarrer le service. Au 1ᵉʳ boot d'une version WU3+, Cosmos migre automatiquement l'ancien document unique « state » en multi-documents (1 par exercice) puis le supprime ; opération idempotente.
6. Vérifier /api/status : version mise à jour, APIs OK.

14. Runbook incidents

15. Monitoring et SLO suggérés

• Disponibilité de l'endpoint /api/status : SLO 99,5 % par mois.
• Latence p95 sur /api/feed et /api/state : < 300 ms.
• Taux d'erreur 5xx : < 0,5 %.
• Quota Anthropic : surveiller 429 dans App Insights (event Dependency).
• Connexions SSE : exposées dans le snapshot SSE ; alerte si chute brutale pendant un exercice.

16. RGPD et confidentialité

Données collectées

• Authentification : aucun mot de passe en base (auth exclusivement WebAuthn depuis v2.1.0-rc.15). Pour chaque passkey enrôlée : credentialId, clé publique (jamais privée), signCount, aaguid, transports, label utilisateur. Pour la récupération : codes hashés SHA-256 au repos (jamais en clair après affichage initial). Session opaque iam_sid (cookie).
• Journal d'activité : timestamp, type, rôle, IP tronquée (/24 en IPv4, 2 groupes en IPv6), message. Pas de nom, pas d'email.
• Bloc-notes observateur : localStorage du navigateur - jamais envoyé au serveur.
• Messages observateur : texte libre + horodatage, plafonné à 200 par exercice.
• Contenu d'exercice (publications, réactions IA, contexte) : pédagogique et fictif. Ne pas y faire figurer de données personnelles réelles.

Rétention

• Activity log : 500 entrées (rolling), purge manuelle possible.
• Erreurs serveur : volatile (effacées au redémarrage).
• Sessions : durée du JWT (48 h par défaut).
• Sauvegarde Cosmos : selon politique du compte Cosmos.

Droit à l'effacement

• Pas de comptes utilisateurs nominatifs - donc pas de profil à supprimer.
• Sur demande : purger l'activity log (DELETE), réinitialiser le store (POST /api/reset), supprimer la base Cosmos.

Sous-traitants externes

• Anthropic (USA) : reçoit le contexte d'exercice et les contenus saisis pour génération IA. Vérifier les CGU à jour avant tout usage avec données sensibles.
• Twister : requêtes de recherche en clair (queries publiques).
• Sources RSS : flux publics.
• Microsoft Azure (Cosmos, App Insights) : si activés.

17. Procédure de purge

1. Vider l'exercice en cours : Configurateur → Tests → Reset (ou POST /api/reset).
2. Effacer l'activity log : Configurateur → Journaux → 🗑 Purger l'activité.
3. Effacer les erreurs serveur : redémarrer l'instance OU bouton dédié dans Journaux.
4. Supprimer le stockage : rm data/store.json (mode local) ou supprimer le document Cosmos.
5. Faire tomber les sessions : changer ACCESS_TOKEN_SECRET + redéployer (invalide tous les JWT en cours).

18. FAQ admin

1. Vue d'ensemble du repo

simulateur-crise/
├── data/
│   └── store.json              # État applicatif (mode local)
├── public/                     # Assets servis statiquement
│   ├── index.html              # SPA (toutes les vues) – embarque la mire passkey
│   ├── css/style.css           # Design system unique
│   ├── assets/                 # Logos, illustrations
│   └── js/                     # Modules frontend (vanilla)
│       ├── bootstrap.js        # Patch fetch (X-Trainer-Token)
│       ├── auth.js             # Mire passkey + recovery (login/logout)
│       ├── iam.js              # Écran IAM admin (Comptes / Sessions / …)
│       ├── app.js              # Orchestration, modes, SSE/polling
│       ├── wall.js             # Mur joueur
│       ├── observer.js         # Salle d'observation
│       ├── newsroom.js         # Salle de rédaction (animateur)
│       ├── configurator.js     # Configurateur (admin) + modale Doc
│       ├── context.js          # Édition contexte d'exercice
│       ├── sources.js          # Gestion sources live
│       └── reputation.js       # Indicateurs de tonalité
├── src/
│   ├── server.js               # Bootstrap (charge config, init store)
│   ├── app.js                  # Express : middlewares, montage routes
│   ├── config/env.js           # Lecture & validation des variables d'env
│   ├── middleware/             # rateLimiter, trainerAuth, validate, …
│   ├── security/               # accessTokens (JWT exercices), iamUsers,
│   │                           # iamSession, iamWebauthn, iamRecovery
│   ├── routes/                 # voir §4 (iamAuth, iamAdmin, …)
│   ├── services/               # anthropicService, twisterService, activityLog
│   ├── repositories/           # storeRepository (Cosmos OU disque)
│   ├── store/                  # memoryStore + eventBus (pub/sub SSE)
│   ├── db/cosmos.js            # Client Cosmos + migration store.json
│   └── utils/                  # logger (pino), diskStore
├── src/__tests__/              # Suites Jest + supertest
├── package.json                # Scripts: start, dev, test
├── README.md
└── CHANGELOG.md

2. Architecture logique

Application en couches strictes :

┌────────────────────────────────────────────┐
│  Routes (src/routes/*.js)                  │  HTTP boundary
│  - parse body (zod)                        │
│  - apply middlewares (auth, rate-limit)    │
│  - 1 fichier = 1 ressource                 │
└────────────────┬───────────────────────────┘
                 │
┌────────────────▼───────────────────────────┐
│  Services (src/services/*.js)              │  Business logic
│  - composent plusieurs stores/APIs ext.    │
│  - sans dépendance Express                 │
└────────────────┬───────────────────────────┘
                 │
┌────────────────▼───────────────────────────┐
│  Store + Repository                        │  Persistance
│  memoryStore: source de vérité en mémoire  │
│  storeRepository: write-through Cosmos +   │
│                   disque                   │
└────────────────────────────────────────────┘

• Pourquoi cette séparation ? Tester sans Express (services purs), pouvoir changer de DB sans toucher aux routes, garder les routes minces (parse + dispatch).
• État partagé : memoryStore est un objet en mémoire. À chaque mutation, on appelle storeRepository.save() qui persiste vers Cosmos (si activé) puis vers disque en backup.
• Pub/sub cloisonné (WU6) : eventBus émet à chaque changement de feed/state/messages sur le canal de l'exercice muté (e.id) ; /api/exercises/:id/events souscrit au canal de cet exercice, /api/events (global) au seul canal GLOBAL (révocation de session). Plus aucune fuite SSE inter-exercice.

3. Modèles de données clés

Source de vérité du shape : les schémas zod dans src/routes/ (validation à l'entrée). Aperçus :

Feed item (publication sur le mur)

{
  "id": "x_1715180000_xy7k",
  "type": "x" | "of" | "prompt",
  "name": "BFMTV", "handle": "BFMTV", "verified": true,
  "content": "...", "img": "https://...",
  "likes": 1240, "reposts": 320, "views": 18400,
  "viral": false,
  "live": false,
  "_serverTime": 1715180000123,
  "tone": "neutral" | "very_negative" | "negative" |
          "positive" | "very_positive",
  "quoted":  { "author": { "name", "username", "verified" }, "content" },
  "replyTo": { "name", "handle", "content" },
  // type 'of' :
  "rubrique": "Société", "headline": "...", "chapo": "...",
  "byline": "Par A. Dupont", "city": "NANTES",
  // type 'prompt' :
  "sujet": "Technique", "resume": "...", "emetteur": "...",
  "recepteur": "...", "stimuli": "...", "reaction": "...",
  "comment": "..."
}

Inject programmé (scenario item)

{ "item": { ...feedItem }, "offsetMin": 5 }

Source live

// store.sources
{
  "twister": ["GouvernementFR", "AFP", ...],   // 20 max
  "media":   ["https://www.lemonde.fr/rss/...", ...]  // 20 max
}

Activity log entry

{
  "ts": 1715180000123,
  "type": "LOGIN_SUCCESS",
  "severity": "info" | "warn" | "error",
  "role": "admin" | "player" | "facilitator" | "observer",
  "ip": "203.0.113.0/24",
  "message": "Admin connecté",
  "meta": { /* libre */ }
}

User (IAM nominatif, passwordless)

{
  "id": "usr_…", "email": "alice@…", "displayName": "Alice",
  "role": "admin" | "sysadmin",
  "active": true,
  "createdAt": "…", "createdBy": "usr_…",
  "lockoutUntil": null,
  "webauthn": {
    "userHandle": "uh_…",            // ID stable de l'utilisateur côté WebAuthn
    "credentials": [{
      "credId": "…",                  // base64url
      "publicKey": "…",               // base64url COSE
      "signCount": 42,
      "aaguid": "…",
      "transports": ["internal", "hybrid"],
      "label": "iPhone d'Alice",
      "createdAt": "…", "lastUsedAt": "…"
    }]
  },
  "recovery": {
    "codes": [{ "hash": "sha256:…", "usedAt": null }],
    "generatedAt": "…"
  }
}
// pwd / mfa : retirés depuis v2.1.0-rc.15 (WU11). sanitize() les masque toujours.

Challenge (slice éphémère)

{
  "id": "ch_…",
  "kind": "login" | "register" | "enrol" | "bootstrap",
  "challenge": "…",       // base64url (32 octets)
  "userId": "usr_…" | null,
  "ip": "203.0.113.0/24",
  "expiresAt": 1715181000000,
  "consumedAt": null      // usage unique R4
}

JWT payload

{ "exerciseId": "ex_3f2a…", "role": "player", "jti": "…", "iat": ..., "exp": ... }
// exerciseId = vrai id store ; requireExercise exige token.exerciseId === :id (403 sinon)

Contexte d'exercice

{ "client": "...", "objectif": "...", "scenario": "...", "acteurs": "..." }

4. API HTTP - référence

Préfixes : /iam (auth passwordless / bootstrap / récupération + /iam/admin/* gestion comptes ; session iam_sid), /access (redemption JWT exercice), /admin (liens exercice, session IAM), /api (reste, globalLimiter). Auth applicative par cookie access_token (JWT exercice) ou Authorization: Bearer. Phase 1 (mdp + TOTP) retirée en v2.1.0-rc.15 (WU11) : les routes /login, /login/mfa, /auth/logout, /iam/login, /iam/mfa/*, /iam/me/password, /iam/admin/users/:id/reset-{password,mfa} répondent 404.

Erreurs standard : 400 (validation zod), 401 (non authentifié), 403 (rôle insuffisant), 429 (rate limit), 500 (erreur serveur). Format : { error: "...", details? }.

5. Frontend

Modules et ordre de chargement

Tous les scripts sont chargés en bas de public/index.html, dans cet ordre :

1. api-url.js · csrf.js · header-widgets.js – chokepoint API, jeton CSRF, widgets de l'en-tête.
2. auth.js – mire de connexion passkey + entrée code de récupération (helpers WebAuthn base64url ↔ ArrayBuffer, navigator.credentials.get/create, exports window.WA). Wire wireLogout() sur /iam/logout.
3. bootstrap.js – patch window.fetch pour injecter X-Trainer-Token depuis localStorage (cas dev / tests).
4. app.js – état global, connexion SSE, polling fallback, restrictions de rôle, fonctions d'écran (_viewWall, _viewNewsroom…).
5. router.js – app-shell : routeur hash centralisé (registre de 6 vues, PulseRouter.go(), gardes de rôle, historique pushState + popstate/hashchange). Les show*() historiques y délèguent.
6. exercices.js, sources.js, context.js, newsroom.js, reputation.js, wall.js, observer.js, configurator.js.
7. iam.js – écran IAM admin (onglets Vue d'ensemble / Comptes / Sessions / Stratégies), pilote l'enrôlement de passkey et le reset assisté côté UI.

Conventions

• Pas de framework - JS vanilla, fonctions globales sur window.
• État côté client via variables globales préfixées _ pour les internes (_accessRole, _wallSSE).
• Communication serveur : fetch (avec patch bootstrap) + EventSource pour le SSE.
• Navigation pilotée par le routeur router.js (popstate / hashchange) ; les autres syncs restent des appels directs aux renderers.
• Cache-busting via ?v=YYYYMMDDx sur chaque <script> et <link>.

Polling vs SSE

/api/events est l'option par défaut. En cas d'échec, app.js bascule en polling toutes les 2 s sur /api/feed + /api/state. L'observateur a un fallback à 3 s (_startObsPoll).

6. Scheduler d'injects

Scheduler côté serveur (WU8) – src/services/injectScheduler.js. Le déclenchement n'est plus calculé dans le navigateur animateur (throttling / onglet fermé). Mécanisme :

• Le serveur stocke, par exercice, scenario: [{ item, offsetMin }], l'état { status, startTime, pausedAt } et firedInjectIds (sent-tracking persisté, hors scénario).
• Un unique setInterval (tick 3 s) itère tous les exercices running. Pour chaque entrée échue (Date.now() - startTime ≥ offsetMin*60000) non encore déclenchée : insertion via le chemin store withExercise(id).addToFeed (idempotent sur item.id, persist coalescé, broadcast SSE par exercice).
• Rattrapage au boot : après store.init(), un passage rejoue en rafale les injects échus pendant l'arrêt (idempotent – triple garde firedInjectIds + _feedIds + filtre). Arrêt propre du timer au shutdown gracieux.
• Pause : un exercice paused n'est pas tické (décompte gelé) ; à la reprise le client rebase startTime (temps en pause non compté) et le scheduler repart au même offset.
• Cloisonnement : un tick sur l'exercice A ne déclenche jamais les injects de B. Le frontend ne fait plus que reconstruire l'affichage « envoyées » depuis l'appartenance au feed (reçu par SSE).
• Limite connue : en multi-instance (≥ 2 réplicas, hors périmètre Azure single-slot actuel), chaque instance schedule ; addToFeed dédoublonne le feed mais le sent-tracking est last-write-wins. WU8 améliore strictement le cas « onglet fermé = rien ne part ».

7. Intégration Anthropic

• Modèle : sélection par route (#144). Défaut claude-sonnet-4-6 (constantes MODEL_SONNET / MODEL_HAIKU en tête de src/services/anthropicService.js, override via callClaude(..., { model })). Génération d'injects + réactions sur Sonnet 4.6 ; classification de sentiment + distillation de requête visuelle sur Haiku 4.5 (~3× moins cher, tâches déterministes sans raisonnement).
• Client : SDK officiel @anthropic-ai/sdk (singleton partagé). Le passage en SDK donne pooling de connexions, retry transitoire, mapping d'erreurs typé, et surtout support natif de cache_control.
• Tool use : recherche web via le tool web_search_20250305 (header beta anthropic-beta: web-search-2025-03-05) pour les injects et la recherche d'images.
• Boucle d'outils : implémentée dans _callWithWebSearch (max 10 tours, chaque tour passe par client.messages.create du SDK). Depuis #131, un cache_control: ephemeral est posé à chaque tour sur le dernier bloc du dernier message (helper _withCacheBreakpoint) : le tour N+1 relit depuis le cache le préfixe accumulé du tour N (prompt + tool_uses + tool_results précédents) au lieu de le payer plein tarif. C'est le levier qui fait redescendre la part de media_search dans la facture totale (95 % du volume avant #131).
• Prompts : structurés en system blocks (persona + format spec + contexte d'exercice) pour la portion stable, user message pour la portion variable. Sources inline dans src/routes/inject.js, src/routes/sentiment.js, src/routes/anthropic.js et src/routes/importChronogramme.js.
• Prompt caching : activé via cache_control: { type: 'ephemeral' } sur (a) les blocs system des routes productives (#16 – /api/inject, /api/inject/replenish, /api/inject/reactions, /api/sentiment, /api/import/chronogramme batches média) et (b) le dernier bloc du dernier message à chaque tour de _callWithWebSearch (#131). /api/inject et /api/inject/replenish partagent volontairement la même entrée de cache → cache réutilisé sur toute la session d'exercice. Anthropic ne cache effectivement qu'au-delà de 1024 tokens cumulés (Sonnet) ; en deçà le breakpoint dégrade silencieusement en no-op. Limite Anthropic : 4 breakpoints max par requête – la stratégie courante en utilise au plus 3 (jusqu'à 2 system blocks + 1 sur le tool-loop).
• Mesure : tokens et hit rate visibles sur l'onglet Configurateur → Consommation IA (tracé via response.usage.cache_creation_input_tokens / cache_read_input_tokens).
• Tokens : limites max_tokens par appel - 2500 (injects), 2000 (réactions), 1200 (sentiment), 600 (replenish), 4000 (média import), 2000 (web search).

8. Sécurité côté code

• Validation : zod sur tous les body POST (src/middleware/validate.js wrapper).
• Auth IAM (passwordless) : requireSession() (session pleine, cookie iam_sid) – cf. src/security/iamSession.js ; vérification WebAuthn déléguée à @simplewebauthn/server (verifyAuthenticationResponse / verifyRegistrationResponse) dans src/security/iamWebauthn.js – D11 / D13 (RP-ID = secalys.fr ou env) / D14 (attestation none) / R8 (signCount toléré à 0 et exigé monotone après).
• Auth applicative : requireAccess([roles]) et trainerAuth – voir src/security/accessTokens.js et src/middleware/trainerAuth.js.
• Comparaisons sensibles : crypto.timingSafeEqual sur les codes de récupération hashés (anti-timing-leak) ; signCount monotone strict (anti-clone R8) ; défis & jetons d'enrôlement usage-unique + TTL + liés IP (R4).
• Anti-énumération (R4) : réponses génériques sur /iam/webauthn/login/verify et /iam/recovery/redeem (aucune fuite « compte inexistant » vs « code invalide »).
• SSRF : src/routes/preview.js filtre les IPs privées et limite la taille de fetch.
• Cookies : httpOnly, secure en prod, SameSite=Lax.
• Helmet : configuration explicite dans src/app.js (CSP avec unsafe-inline à terme à durcir).

9. Tests

npm test          # jest, testTimeout 10s, testEnvironment node – 32 suites / 449 tests verts

Suites présentes dans src/__tests__/ (sélection) :

• iamWebauthnE2E.test.js – WU12 : E2E avec vraie crypto P-256/ES256, authentificateur factice qui produit des signatures DER vérifiables. Couvre login + register + recovery + reset-credentials sans mocker @simplewebauthn/server.
• iamWebauthnModelStore.test.js – slice store WebAuthn / recovery (invariants D9 « pas de PII en clair » / D12a garde min credentials).
• helpers/seedSession.js – sème une session IAM directement dans le store, pour les tests qui n'auditent pas la chaîne d'auth elle-même (exerciseAuthz, tenancyE2e, etc.).
• accessTokens.test.js – émission/validation JWT d'exercice, expiration, rôles.
• security.test.js – protections SSRF, validation URLs.
• feed.test.js, scenarioRoutes.test.js, stateRoutes.test.js, injectScheduler.test.js – mutations/state/scheduler.
• activityLog.test.js · activityLogRoutes.test.js – structure des entrées, troncature IP, contrôle d'accès.
• storeRepository.test.js, multiExerciseStore.test.js, storeBroadcastChannel.test.js – Cosmos enabled/disabled, migration, fallbacks, pub/sub par canal.
• tenancyE2e.test.js, exerciseAuthz.test.js, eventBusChannels.test.js – cloisonnement par exercice (WU5/WU6).

Suites retirées en WU11 (testaient des routes/modules Phase 1 retirés) : iamAuth, iamMfa, iamHardening, iamE2e, iamUsersStore, appPasswords, logout, plus les redondances couvertes par WU12 E2E (iamWebauthnLogin/Register/Recovery, iamAdmin, iamAdminResetCredentials, iamAccessLinksPasswordless, iamSessionsPasswordless, iamSecurityWebauthnKpi).

Conventions : supertest pour les tests d'intégration HTTP, mocks Anthropic/Twister par stubs locaux. Pas de couverture mesurée à ce jour.

10. Conventions

• Style JS : ES2022, const par défaut, fonctions nommées, pas de TypeScript dans le code (mais tsconfig.json pour JSDoc/IDE).
• Erreurs : pas de classes d'erreur custom - on renvoie un statut HTTP + JSON. Les exceptions imprévues sont attrapées par un middleware error handler.
• Logging : logger.info / warn / error, jamais console.log en code applicatif.
• Commits : style minuscule, type entre parenthèses ou tag docs:, ui(brand):, feat:, fix:. Voir git log.
• Branche principale : main.

11. Comment ajouter…

Une nouvelle route HTTP

1. Créer src/routes/maRoute.js avec un express.Router().
2. Définir un schéma zod pour le body si POST.
3. Appliquer les middlewares trainerAuth ou requireAccess([…]) selon les besoins.
4. Monter dans src/app.js avec le préfixe /api/ma-route.
5. Ajouter un test dans src/__tests__/.

Un nouveau type de publication

1. Étendre l'enum type dans src/routes/feed.js (zod) et dans le schéma scenario.
2. Ajouter le rendu correspondant dans public/js/wall.js (nouvelle fonction myCard()).
3. Ajouter le composeur dans public/js/newsroom.js + le formulaire HTML.
4. Mettre à jour la timeline observateur (_obsItemDisplay).

Une nouvelle source live

1. Ajouter une clé dans store.sources (zod schema).
2. Créer la route de fetch (src/routes/maSource.js).
3. Ajouter le polling client dans app.js (intervalle dédié).
4. Ajouter le rendu côté wall.js avec le badge EN DIRECT.

Une nouvelle vague de réactions

1. Étendre le validateur tone dans src/routes/inject.js.
2. Ajouter le bloc de prompt correspondant.
3. Ajouter un bouton dans la timeline animateur (newsroom.js).
4. Définir un mapping de tone dans wall.js et reputation.js.

Une traduction

Pas d'i18n actuellement (UI 100 % française). Pour l'introduire : extraire les chaînes en dictionnaires, choisir une lib (i18next) ou un mécanisme léger maison.

12. Build et assets

• Pas de build step côté frontend - les fichiers JS/CSS sont servis tels quels depuis public/.
• Cache-busting manuel : suffixe ?v=YYYYMMDDx sur chaque <script> et <link> de index.html. À bumper dès qu'un asset est modifié.
• Service statique : express.static('public') avec Cache-Control: no-store en dev, etag désactivé.

13. Performance

• Mur joueur : rendu incrémental (patchFeed) - seuls les nouveaux items sont insérés en tête, pas de re-render complet.
• Stats croissantes : un seul setInterval à 1.8 s pour tout le mur, avec décroissance par âge (multiplier ×0.04 au-delà de 60 min).
• RSS : cache serveur 60 s, fetch parallèles via Promise.allSettled.
• Cosmos : 1 document par exercice + 1 document partagé ; seuls les exercices modifiés sont réécrits (dirty-tracking, WU3).
• Pagination : timeline animateur paginée (15 / page). Le mur joueur n'est pas paginé (rolling display).

14. Comment debugger

• npm run dev : nodemon + pino-pretty (logs colorés horodatés).
• node --inspect src/server.js : breakpoints via Chrome DevTools.
• Côté client : DevTools > Network > EventStream pour voir le flux SSE en clair.
• Mocks Anthropic/Twister dans les tests : stubs des modules (Jest).
• /api/status : aperçu rapide de l'état.
• localStorage.setItem('pulseTrainerToken', '...') : injecte automatiquement X-Trainer-Token sur toutes les requêtes (utile en tests manuels).

15. Contribuer

1. Brancher depuis main (git checkout -b feat/ma-feature).
2. Coder + ajouter des tests + bump du ?v= sur les assets touchés.
3. npm test doit passer.
4. Mettre à jour CHANGELOG.md sous une nouvelle entrée si user-visible.
5. PR vers main, revue par un mainteneur.
6. Style des messages de commit : voir git log récent.

Pour les changements visuels (UI, branding), capturer un avant/après dans la PR.

16. Glossaire technique

SSE

Server-Sent Events - flux HTTP unidirectionnel serveur → client. Utilisé pour pousser feed/state/messages.

Inject

Publication programmée dans le scénario de l'exercice, avec un offset T+ minutes.

Tone

Catégorie de sentiment : very_negative · negative · neutral · positive · very_positive.

Trainer auth

Garde des routes mutantes /api : rôle facilitator/admin ou X-Trainer-Token.

access_token

Cookie JWT HS256 { exerciseId, role, jti, exp }. Délivré uniquement par /access?token=… (redemption d'un lien JWT d'exercice).

iam_sid

Cookie opaque de session serveur nominative (admin/sysadmin), ouvert par WebAuthn → lookup store ; révocable, TTL/inactivité par rôle.

Passkey

Identifiant FIDO2 / WebAuthn – clé asymétrique générée par l'authentificateur (Touch ID, Windows Hello, clé USB, etc.) ; PULSE stocke la clé publique + métadonnées, jamais la clé privée. RP-ID = secalys.fr (D13).

RP-ID

Relying Party Identifier WebAuthn : domaine auquel la passkey est liée. Une passkey enrôlée sous secalys.fr fonctionne pour tout sous-domaine, mais pas si on change de RP-ID (cf. IAM_WEBAUTHN_RP_ID).

UV (User Verification)

Vérification utilisateur côté authentificateur (biométrie / PIN). Exigée par PULSE – c'est ce qui sert de 2ᵉ facteur (D3′), il n'y a plus de TOTP.

enrolToken

Jeton d'enrôlement usage-unique (TTL IAM_ASSISTED_GRANT_TTL_MIN min) émis par POST /iam/bootstrap, création de compte, reset-credentials ou recovery/redeem. Permet d'enrôler une passkey via /iam/webauthn/register/* sans session.

Codes de récupération

10 codes (par défaut, IAM_RECOVERY_CODE_COUNT) générés sur demande, hashés SHA-256 au repos, affichés une seule fois. À conserver hors-bande. Redeem public anti-énumération (réponse générique en cas d'échec).

memoryStore

Objet en mémoire centralisant tout l'état serveur. Persisté à chaque mutation vers Cosmos puis disque.

Web search tool

Outil Anthropic web_search_20250305, activé en beta pour la recherche d'images et l'enrichissement d'injects.

SSRF guard

Module qui résout les DNS et refuse les IPs privées avant fetch côté serveur (route /api/preview).

Cache-bust

Suffixe ?v=YYYYMMDDx sur les assets pour forcer le rechargement client.