Archétypes d'utilisateurs simulés

Un archétype décrit un type d'utilisateur — comptabilité, administration système, direction, développement, commercial, contrôleur de domaine — par le workflow de sa journée : une suite d'actions abstraites, chacune avec sa temporalité, reliées entre elles. Un archétype est toujours une journée de travail : les menaces vivent dans la bibliothèque de scénarios.

Le workflow ne nomme aucune technologie. C'est délibéré : au moment d'instancier un archétype sur une community, on choisira les générateurs de logs, et le système saura quels messages types de chaque technologie réalisent chaque action. C'est ce croisement qui rend le workflow exploitable, et l'onglet Couverture le montre avant toute instanciation.

Le vocabulaire des actions

Le catalogue compte 32 actions, tirées des noms réellement présents dans les 470 messages types du corpus. Il vit en code (packages/shared-types/src/activity.ts) et non en base : une action créée depuis l'écran n'aurait aucun message type en face, et la déduction de couverture ne connaît que ces slugs.

Famille	Actions
Authentification	Ouverture de session locale, Fermeture de session, Verrouillage / déverrouillage, Connexion à un serveur, Authentification cloud, Second facteur, Échec d'authentification
Processus	Lancement d'application, Console d'administration, Exécution de script, Tâche planifiée, Chaîne de développement
Réseau et collaboration	Navigation web, Messagerie, Messagerie instantanée, Visioconférence, Usage d'une application SaaS, Connexion VPN, Transfert de fichiers
Résolution de noms	Résolution DNS
Fichiers et documents	Ouverture de document, Création ou modification, Suppression de fichier, Partage interne, Partage externe

La messagerie et le chat sont rangés sous la catégorie NETWORK plutôt que sous une catégorie propre : la catégorie d'une action ne sert qu'au groupement de l'interface, c'est la table de couverture qui fait autorité.

Connexion à un serveur est la seule action qui met en jeu deux entités : elle sera sautée si la population simulée ne compte aucun serveur.

La temporalité d'une action

Chaque action porte une fenêtre dans la journée (en minutes depuis minuit), des jours d'activité, une probabilité d'avoir lieu un jour donné, une dispersion aléatoire, et l'une des trois temporalités :

Temporalité	Ce qu'elle décrit	Exemple
Une fois par jour	Une occurrence tirée dans la fenêtre	Arrivée au bureau, 08:00–08:15
Régulièrement	Une occurrence en moyenne toutes les n minutes	Messagerie, toutes les 6 min de 08:15 à 18:00
Par rafale	n tirages groupés dans la fenêtre	4 réunions dans la journée

La dispersion n'est pas décorative : sans elle, une population entière se connecterait à la seconde près.

La fenêtre se lit à l'heure de la population, pas en UTC : un archétype ne sait pas où vivent ceux qui le jouent, c'est la population du banc — ou de la community — qui porte le fuseau. « 08:00 » veut donc dire 08:00 pour eux.

Les enchaînements

Une transition A → B se lit : B ne commence qu'après A, et chacune de ses occurrences suit un geste de A. Si A n'a pas eu lieu — son tirage de probabilité a échoué — B est sautée. Pas de connexion, pas de session.

C'est ce qui permet de décrire une journée de travail : pas de messagerie avant l'arrivée au bureau, pas de session du soir sans le VPN.

L'enchaînement prime sur la fenêtre

La chaîne est le squelette de la journée ; l'horaire déclaré n'est qu'une préférence. Trois règles en découlent.

La fenêtre glisse, elle ne refuse pas. Si l'horaire de B est déjà passé quand A a lieu — B se referme à 10:00, A arrive à 20:00 — la fenêtre de B glisse en gardant sa durée déclarée, au lieu d'être sautée. L'action a bien lieu, et l'aperçu d'essai le rapporte : Actions décalées. Le seul cas qui reste un saut est celui où il ne reste plus de journée du tout.

Chaque occurrence de B attend un geste de A. Une modification de document suit une ouverture, et une ouverture ne débloque qu'une modification. Quand A n'a lieu qu'une fois — l'arrivée au bureau — il n'y a plus rien à attendre après le premier geste : B reprend alors sa propre cadence, et une messagerie toutes les 8 minutes reste une messagerie toutes les 8 minutes.

Attendre raréfie, et c'est assumé. Deux récurrences enchaînées ne produisent pas le volume que leurs cadences annonceraient séparément : « toutes les 25 min, après une ouverture qui a lieu toutes les 20 min » produit moins que 25 minutes ne le promettent, puisque chaque échéance attend son déclencheur. C'est le prix de la corrélation — et la contrepartie d'une journée qui se lit.

La séquence se vérifie sur l'instant émis, dispersion comprise : une action dispersée de +40 minutes reste avant celles qu'elle débloque.

Après le premier geste, ou après le dernier

Une flèche porte un mode, qui dit lequel des gestes de A ouvre B.

Mode	Ce qu'il décrit
après le premier geste	Le défaut, et le comportement de toujours : B démarre au premier geste de A, et chacune de ses occurrences en suit un.
après le dernier geste	B attend que A ait fini. Elle n'a alors qu'une seule ancre — le dernier geste — puis reprend sa propre cadence.

Le second sert à fermer une séquence. Une déconnexion enchaînée « après le premier » au CRM tombe au milieu de la série, et le CRM continue une heure après le départ : la journée se ferme avant sa fin. « Après le dernier » la place là où elle a un sens.

Le mode se règle en choisissant la flèche : le panneau de propriétés la décrit et propose la bascule. Sans JavaScript, il se règle dans la liste Enchaînements. Une flèche réglée sur « après le dernier » porte l'étiquette sur le graphe — les autres restent nues, pour que la seule qui dise autre chose se remarque.

Le graphe doit rester acyclique. Un cycle rendrait la journée insoluble : aucune action ne pourrait démarrer. L'éditeur refuse la liaison avant l'enregistrement, et le backend la refuse aussi.

Poser un enchaînement

Chaque carte porte deux points à la teinte de l'archétype : en bas, le départ, en haut, l'arrivée. On relie le point bas d'une carte au point haut d'une autre — au glisser, ou en cliquant l'un puis l'autre. La flèche qui apparaît porte une pointe : elle dit le sens, et donc laquelle des deux actions attend l'autre.

Pour défaire un enchaînement, on choisit sa flèche — elle s'épaissit — et l'on appuie sur Suppr.

Un enchaînement refusé ne disparaît pas en silence : le motif s'affiche au-dessus du graphe, en plein écran comme en pleine page.

Les bifurcations

Une bifurcation est une brique du graphe qui choisit, pour chaque utilisateur et chaque jour, lequel des chemins qui la suivent a lieu. Chaque flèche qui en part ouvre un chemin, et chaque chemin relié dilue les autres : deux chemins, un jour sur deux chacun ; trois chemins, un jour sur trois. C'est ce qu'il faut pour dire « de temps en temps, le soir, il ouvre le VPN et relève ses mails ».

Un chemin, c'est tout ce que la bifurcation est seule à atteindre : ses actions partent ensemble ou pas du tout. C'est ce qui la distingue d'une chance posée sur chaque nœud : trois actions à une chance sur trois chacune donneraient une soirée sur trois sans connexion VPN, et la séquence entière n'arriverait qu'un jour sur vingt-sept.

• La rareté ne se saisit jamais : elle se lit dans le nombre d'issues. Une bifurcation porte aussi des issues vides, qui comptent dans le tirage et ne mènent nulle part : un chemin et deux issues vides font « un jour sur trois ». Une bifurcation à une seule issue la retient toujours — l'éditeur le signale.
• La bifurcation compose avec la chance propre de l'action : le chemin est retenu un jour sur sept, et ce jour-là une action à 0,5 a encore une chance sur deux.
• Une action que deux chemins de la bifurcation atteignent — une jonction — a lieu après celui qui a été retenu. Une action qu'un autre parent atteint aussi n'est pas retirée avec le chemin non plus : une bifurcation ne retire que ce qu'elle seule atteint.
• Une bifurcation est transparente pour l'horaire : c'est l'enchaînement qui y entre qui dit quand ses chemins démarrent, et les flèches qui en sortent ne portent pas de mode — elle n'a pas de geste à elle.
• Sur le graphe, une bifurcation est une carte tiretée marquée d'un losange ; chaque flèche qui en part porte sa part — 1/3 —, et chaque issue vide se dessine en amorce pointillée sous la carte.
• L'aperçu d'essai rapporte le tirage — retenu pour 9 des 25 utilisateurs — même quand un chemin est retenu partout. Sans cela, un chemin qui tombe pour une partie de la population se lirait comme n'ayant rien produit.

Retirer une bifurcation contracte le graphe : ce qui menait à elle mène désormais à chacun de ses chemins, qui deviennent inconditionnels. La chaîne dessinée autour reste entière.

Par jour ou par heure

Une bifurcation a une cadence. Par jour, le chemin se choisit une fois pour la journée entière. Par heure, un chemin l'emporte à chaque heure : la bifurcation partage les vingt-quatre heures entre ses issues — sans recouvrement ni trou —, et une issue vide laisse des heures sans aucun d'eux.

C'est la forme d'un attaquant, qui fait une chose à la fois et change d'heure en heure. Une rareté ne le dirait pas : six campagnes tirées chacune « un jour sur six » donneraient une journée sans aucune campagne une fois sur trois, et deux campagnes simultanées presque aussi souvent. Cf. Bruit de fond pirate.

• Chaque bifurcation horaire tourne de son côté : deux bifurcations horaires d'une même journée ne changent pas de chemin au même pas.
• Une action dont la fenêtre ne rencontre aucune des heures de son chemin est sautée et nommée : le motif dit laquelle des deux causes joue — aucune heure gagnée, ou des heures hors fenêtre.
• Une jonction après plusieurs chemins d'une bifurcation horaire attend un geste de chacun d'eux : ils vivent tous le même jour, à des heures différentes. L'éditeur le signale.
• Poser une action derrière une bifurcation ne déplace aucun horodatage du reste de la journée : le tirage vit dans son propre flux, et le filtre horaire s'applique après le placement — il retient, il ne rejoue pas.

Le lieu d'un geste

Chaque action porte un lieu : au bureau, le cas ordinaire, ou hors bureau — télétravail, mobilité. Ce n'est pas une propriété de l'action du catalogue : relever ses mails se fait au bureau comme au domicile. C'est une propriété du nœud, parce que c'est le workflow qui dit où l'on est à ce moment de la journée.

Ce que le lieu change dans les logs :

• au bureau, l'utilisateur sort par l'IP publique de son site géographique — la même pour tous ses collègues, comme derrière un vrai NAT d'entreprise ;
• hors bureau, il sort par la sienne (user.desktop_public_ip), qui n'appartient qu'à lui ;
• la ville et le pays, eux, suivent l'utilisateur dans les deux cas. Une seule technologie fait exception, et c'est la bonne réponse : le location de Zscaler redevient Road Warrior, le terme du produit pour un poste nomade.

Tout cela vaut pour un geste sortant. Un geste dirigé vers une machine de l'entreprise — une session RDP ou SSH sur un serveur, un ticket Kerberos, un accès à un partage — ne traverse aucun NAT : le journal en est écrit par la machine jointe, qui voit son client sur le réseau interne. Le lieu y joue quand même, mais entre deux autres adresses : user.desktop_ip au bureau, et l'adresse personnelle dès que le geste part d'ailleurs.

Le lieu est sur l'action et non sur la bifurcation, bien que la soirée de télétravail du Commercial en descende d'une. Une bifurcation est une rareté, pas un lieu : un archétype en télétravail permanent n'en aurait aucune où l'accrocher. Il n'est pas non plus déduit du graphe — « tout ce qui descend d'une connexion VPN » se tromperait dès qu'un VPN est monté depuis une agence.

Sur le graphe, un geste hors bureau porte une ligne « Hors bureau ». Pas de bordure tiretée ni doublée : celles-là appartiennent aux bifurcations et aux appels de super-archétype.

L'écran

/archetypes liste les archétypes ; chacun ouvre trois onglets.

Workflow

Le graphe se dessine sur un canvas occupant toute la largeur de l'écran : un nœud par action, une arête par enchaînement. On le déplie en plein écran (Agrandir le graphe, Échap pour en sortir) le temps d'organiser une journée chargée.

La bibliothèque d'actions est posée sur le canvas, en haut à gauche : les 32 actions y sont rangées par catégorie — Authentification, Processus, Réseau, Fichier, DNS, Alerte — et une seule catégorie est ouverte à la fois. Sous elles, le groupe Structure porte la brique Bifurcation. Le panneau entier se replie sur son en-tête quand le graphe a besoin de la place. Poser une action la sélectionne : ses propriétés s'ouvrent aussitôt.

Les enchaînements se posent sur le graphe, en reliant les cartes à la souris (cf. Poser un enchaînement). Il n'y a pas de panneau pour les décrire : lire deux listes déroulantes pour dire quelle carte suit quelle autre, alors que les deux sont sous les yeux, était le tour de main qu'il fallait retirer.

Sous le canvas, le panneau de propriétés ne règle que l'action sélectionnée : temporalité, fenêtre, cadence, jours, probabilité, lieu. Tout voir en tableau rend la journée entière, une ligne par action, et Revenir à la sélection referme. Les deux vues ne sont jamais affichées ensemble, mais lisent le même état que le canvas — elles ne peuvent pas diverger. Choisir une bifurcation montre ses issues et la part de chacune ; choisir une flèche plutôt qu'une carte y substitue les propriétés de l'enchaînement, dont son mode.

La carte Bifurcations vit sous le graphe, dans les deux modes : on y nomme une bifurcation, on y choisit sa cadence — par jour ou par heure —, on y règle ses issues vides, et on l'y retire. Ses chemins, eux, se tirent sur le graphe comme n'importe quel enchaînement.

Sans JavaScript, le canvas ne monte pas : la bibliothèque s'affiche alors dans le flux de la page, toutes catégories dépliées, et le tableau devient le seul moyen d'éditer — colonne Lieu comprise. Le panneau Enchaînements — « Après … démarrer … » — réapparaît alors sous le tableau : sans graphe à la souris, il redevient le seul chemin, et c'est là que se règle le mode de chaque flèche et que se relient les chemins d'une bifurcation. L'ensemble reste entièrement fonctionnel, boutons d'ajout, de retrait et d'enchaînement compris. Les onglets, qui sont des boutons, sont doublés de liens ?onglet=….

Une action affichée en ambre dans la bibliothèque n'est réalisée par aucun message type : la poser dans un workflow ne produira aucun log.

L'enregistrement atteint dans la minute les communautés qui jouent l'archétype. Attribué à une entité, ou super-archétype qu'appelle l'un d'eux : le plan du jour de la communauté se périme, et le tic suivant le reconstruit. Seules les minutes pas encore envoyées changent — ce qui est parti reste tel qu'il est parti —, et les compteurs de la carte « Journée du … » de la communauté suivent. Un renommage compte aussi, le nom libellant les gestes ; la Description et la Teinte ne touchent pas la journée, ni donc aucune communauté.

Couverture

Le croisement demandé : une ligne par action du workflow, une colonne par technologie retenue. Chaque case donne le nombre de messages types qui réalisent l'action sur cette technologie, et se déplie sur leur liste.

• Une case remplie signifie que la technologie voit chaque occurrence de l'action : il n'y a pas de part d'observation, et une technologie cochée qui réalise l'action produit un message à chaque geste. De plusieurs messages types listés, c'est le plus lourd qui décrit le geste — les autres attendent la couche ambiante propre à chaque technologie.
• Les gestes qui démarrent un processus — lancement d'application, tâche planifiée ou service, console d'administration, outillage de développement — sont tous décrits par le journal de création de processus de la technologie : un agent ne voit pas qui a lancé le binaire, il voit un processus qui démarre. Toutes les technologies retenues nomment alors le même exécutable, le même chemin et le même identifiant de processus. L'exécution de script fait exception : trois technologies portent un journal dédié, qui décrit le geste plus précisément.
• Une case « Aucun » est un trou : l'action ne produira aucun log sur cette technologie. Ce n'est pas une erreur en soi — c'est ce qu'il faut voir avant d'instancier l'archétype.

La sélection des technologies vit dans l'URL : le croisement est partageable par un lien.

Identité

Nom, description et teinte d'affichage.

D'où vient la couverture

Le corpus source ne porte aucune notion d'action. La couverture est donc déduite du nom de chaque message type à l'import, sur le même principe que la catégorie (inferActionCoverage, dans packages/log-engine/src/authoring/activity-coverage.ts) : des motifs ordonnés, le premier qui matche l'emporte, et aucune action quand rien ne tranche — une action inventée passerait pour un fait.

Sur les 470 messages types du corpus, 529 couvertures sont déduites et 26 messages types restent sans action. Aucun n'est un défaut :

• 13 sont les messages types métier des trois générateurs alertHeavy (CrowdStrike Falcon, Microsoft Defender XDR, SentinelOne Identity). Ils sont exclus du flux per-minute par décision d'architecture : leur couverture métier doit rester vide, sans quoi un archétype « comptabilité » les ferait émettre en continu.
• 13 décrivent le fonctionnement de la machine — agent-log, endpoint-stats, health-check, scan-initiated, filtering-platform-listen, le rpc de Cortex XDR. Ils ne traduisent aucun geste d'utilisateur et n'auront jamais d'équivalent abstrait.

Le piège du nom : un journal d'audit n'est pas une session

La déduction ne lit qu'un nom, et deux gestes très différents portent parfois presque le même. Le message type audit-login-success de Netskope en est l'exemple : il porte « login-success », mais ce n'est pas l'ouverture de session d'un poste — c'est le journal d'audit du tenant, qui enregistre qu'un administrateur s'est connecté à la console Netskope ("type": "admin_audit_logs", "user_category": "admin"). Rangé sous « Ouverture de session locale », il faisait ouvrir la console d'administration à chaque arrivée au bureau d'un utilisateur simulé.

Il relève donc de Console d'administration, comme les autres gestes de cette console — fermeture de session, modification d'un compte administrateur, suppression d'une politique inline, changement de mot de passe. Ces quatre-là n'existent pas dans le corpus source : ils sont écrits dans le dépôt (packages/database/prisma/seed/netskope-admin.ts) et semés à côté du corpus, comme le catalogue des destinations web.

La leçon vaut au-delà de Netskope : quand un motif de déduction se trompe, la correction se fait dans la règle — et sa carte par technologie, figée en instantané, montre alors ce qu'elle a déplacé ailleurs.

Corriger une couverture

L'onglet Actions d'un message type (/generators/:id/event-types/:id) coche les actions qu'il réalise. Enregistrer marque la couverture corrigée (MANUAL), et l'import ne la recalcule plus : une correction survit au pnpm db:seed suivant. Sans cette distinction, l'édition n'aurait aucun sens — tout serait défait au prochain import.

Éprouver un archétype

L'onglet Couverture dit ce qui pourrait réaliser chaque action ; il ne dit pas à quoi ressemble la journée. C'est le rôle des bancs d'essai : « Essayer cet archétype » ouvre un banc préréglé sur lui, où l'on choisit une population, des technologies et leurs clés d'intake, puis où l'on voit la journée avant de l'envoyer réellement.

Le serveur qu'un geste joint

Certains gestes mettent en jeu deux entités : l'utilisateur qui agit, et le serveur qu'il joint. Le catalogue le dit, et il dit aussi avec quelle exigence.

Action	Exigence	Rôle par défaut
Connexion à un serveur	Sans serveur, l'action est sautée	aucun — l'archétype décide
Ouverture de session locale	Facultative	contrôleur de domaine
Résolution DNS	Facultative	serveur DNS
Visite d'un site public	Facultative	serveur web

Les trois dernières surprennent, et c'est le point : le journal qui décrit ces gestes n'est pas émis par le poste. Le message type que Windows retient pour une ouverture de session est le 4768, une demande de ticket Kerberos que le contrôleur de domaine journalise. La ligne BIND d'une résolution est écrite par le résolveur. La ligne W3C d'une visite est écrite par le serveur web. Sans pair, ces journaux ne pourraient nommer aucune de ces machines.

Le rôle visé

Chaque nœud du workflow peut viser un rôle précis — c'est la colonne « Serveur joint » du tableau, et la ligne du même nom dans le panneau de propriétés. Laissé sur « rôle du catalogue », le nœud prend celui que l'action propose ; c'est ce qui fait qu'un archétype écrit avant ce réglage garde son sens.

Le rôle est dérivé du nom de chaque machine à l'import : SRV-DC-01 est un contrôleur de domaine, ZION-DNS-01 un serveur DNS, SRV-JUMP-01 un serveur de rebond. Ce n'est pas une convention qu'on ajoute — c'est déjà ainsi que le générateur BIND du projet source choisissait son résolveur. Une machine dont le nom n'annonce aucun rôle n'en reçoit pas : treize des 110 serveurs des populations de démonstration sont dans ce cas, et l'écran des jeux de données permet de le corriger.

Quand le rôle n'existe pas dans la population

Trois populations de démonstration sur six n'ont aucun contrôleur de domaine. L'archétype Administration de l'annuaire y joue quand même : le geste se replie sur les autres machines plutôt que d'être sauté. Mais il se replie en le disant — la carte « Serveurs joints par défaut » de l'aperçu nomme le nœud, le rôle absent, et le nombre de machines sur lesquelles il se rabat. Refuser rendrait le profil injouable sur la moitié des populations ; se taire ferait passer un serveur RDP pour un contrôleur de domaine.

Les archétypes de démonstration

pnpm db:seed crée les archétypes de démonstration s'ils sont absents : le super-archétype Bruit système, les journées métier Comptabilité, IT — administration système, Direction, Développement, Commercial, Support et assistance à distance, Administration de l'annuaire, Exploitation DNS et réseau et Bureautique et partages, le Visiteur du site public, et un archétype par rôle de serveur sur un Socle serveur Windows partagé. Ils ne sont jamais réécrits : un archétype de démonstration modifié depuis l'interface survit au seed suivant, au même titre qu'un template édité à la main.

Les archétypes de serveur

Chacun des seize rôles de serveur est revendiqué par exactement un archétype : toute machine dont le nom annonce un rôle joue donc une journée. Trois d'entre eux jouent des journaux qui leur sont propres : le Contrôleur de domaine (réplication d'annuaire), le Serveur DNS (transferts et entretien de zone, échecs de résolution récursive, DNSSEC, rechargements RPZ) et le Serveur de sauvegarde (la tâche de nuit, une machine après l'autre, chacune suivie de son point de restauration).

Les treize autres — bureau à distance, fichiers, impression, web, base de données, temps… — n'ont aucun journal propre dans le corpus source : ni W32Time, ni PrintService, ni TerminalServices, ni journal SQL Server. Leur archétype ne joue que le Socle serveur Windows, que tous les archétypes de serveur appellent : le rapport de santé de l'antivirus, une fois par heure, et le service du rôle qui ouvre son port d'écoute. C'est dans ce dernier journal que le rôle se lit — TermService sur 3389, SMB sur 445, http.sys sur 443, SQL Server sur 1433. Un rôle qui ne dit pas quel service il fait tourner (applicatif, supervision, temps…) nomme l'Endpoint Mapper RPC sur 135, qui écoute sur tout serveur Windows. Chacun de ces archétypes le dit dans sa description, plutôt que de promettre un serveur d'impression là où ne part qu'un rapport de santé.

Le Commercial illustre les trois mécanismes de cette page. Sa fermeture de session attend le dernier geste de son CRM et de sa messagerie — sans quoi elle tomberait à 17 h pendant que le CRM tourne jusqu'à 18 h. Sa bifurcation Soirée VPN — un chemin et deux issues vides, un jour sur trois — ouvre sur l'accès distant, la messagerie du soir et le CRM du soir : les trois partent ensemble, ou aucun ne part. Et ces trois gestes-là sont marqués hors bureau : ils sortent par l'adresse personnelle du commercial, quand sa journée sort par celle de son bureau — dans la même journée simulée, pour le même utilisateur.