Communautés

Une communauté fait vivre une population toute seule : chaque utilisateur joue le métier qui lui est attribué, et les messages partent minute après minute vers de vraies intakes.

C'est l'autre moitié du banc d'essai. Un banc se joue à la main — on ouvre, on règle une action, on relance, on compare. Une communauté n'a pas de bouton « envoyer » : elle tourne. Les deux partagent la même forme, et c'était voulu — le banc a été écrit comme sa préfiguration.

/communautes liste les communautés ; chacune ouvre six onglets.

Ce qu'une communauté retient

Réglage	Ce qu'il décide
Population	Les utilisateurs, serveurs et sites — et le fuseau où la journée se joue
Profil d'entreprise	Le repli du mapping, pour ceux qu'aucune unité ne classe
Technologies	Les générateurs retenus, et une clé d'intake par technologie
Destination	Une des 7 régions SEKOIA, ou une URL personnalisée
API Sekoia	Une clé — inventaires, intakes et connecteurs — dans l'onglet Réglages
Fuseau	Hérité de la population, surchargeable ici — choisi dans une liste
Week-end	Samedi et dimanche joués comme un jour ouvré — décoché par défaut
Menace	Des scénarios greffés en rotation sur des postes et serveurs compromis
Assets	Les connecteurs de l'inventaire OCSF quotidien

Une communauté naît arrêtée. L'activer est le geste qui dit que les chiffres annoncés conviennent — et l'écran les annonce avant.

La menace est une greffe et non une attribution : un poste compromis continue sa journée de travail, et le bruit de l'attaquant s'y ajoute. Trois façons de désigner les compromis — un nombre et toujours les mêmes hôtes, des hôtes nommés, ou une cohorte du jour où la menace change d'hôte chaque heure. L'onglet Menaces lance aussi un scénario maintenant, pour une durée bornée. Le détail est dans Bruit de fond pirate.

Le mapping : quel archétype chaque utilisateur joue

C'est ce que le banc ne savait pas faire. Là-bas, toute la population joue le même workflow ; une entreprise n'est pas cela. Un commercial fait une journée de commercial pendant qu'un administrateur fait la sienne, et c'est ce mélange qui rend la corrélation inter-technologies représentative.

Deux règles, dans cet ordre, et l'ordre est tout :

1. L'unité d'organisation de l'utilisateur (org.ou_name), quand un archétype la revendique. C'est le seul signal métier que le corpus porte — et il le porte sur les 419 utilisateurs des six populations de démonstration, en 21 valeurs distinctes.
2. Le mélange du profil d'entreprise, en repli, pour ceux qu'aucune unité ne classe.

L'inverse donnerait un archétype Développement à quelqu'un du service Finance dont l'unité le disait.

Chaque ligne dit d'où vient son archétype — Unité, Profil, ou Manuel. Ce n'est pas un détail d'affichage : « son unité le dit » se vérifie, « tiré dans le mélange » se discute, et les confondre rendrait les deux muettes.

Sur les six populations, quatre utilisateurs sur cinq reçoivent leur archétype de leur unité — donc d'un fait de la population, pas d'un tirage.

Ce qu'on ne devine pas

Trois unités du corpus ne sont revendiquées par aucun archétype : Intelligence, Security et Research. Aucun des neuf archétypes métier ne décrit une cellule de renseignement, une équipe sécurité ni un laboratoire. Les leur donner de force serait un pari.

Sans profil d'entreprise, ces utilisateurs restent donc non attribués — et l'écran les nomme, plutôt que de se contenter de les compter. Le levier est là : choisir un profil, ou les corriger un à un.

Un conflit se refuse, il ne s'arbitre pas

Une unité revendiquée par deux archétypes n'attribue rien. Trancher au premier trouvé ferait dépendre la journée d'un ordre de lecture en base, et l'auteur du second archétype ne saurait jamais que le sien ne joue pas. L'écran nomme le conflit et les deux prétendants.

Corriger, et que la correction survive

Une ligne se corrige à la main. Elle passe alors en Manuel, et le recalcul ne la touche plus jamais — même règle que la couverture d'un message type, où une correction survit au réimport du corpus.

Le repli, lui, est un tirage stable : ajouter un utilisateur à la population n'en redistribue aucun autre. Ajouter un archétype au mélange, si — c'est inévitable, et c'est un geste délibéré.

Le rythme : plan la nuit, envoi minute par minute

La journée est calculée une fois, au basculement du jour calendaire chez la population, et figée — jusqu'à ce que sa configuration change. Un réglage de la communauté, ou l'enregistrement d'un archétype qu'elle joue (attribué, greffé, ou appelé par l'un d'eux), la fait reconstruire au tic suivant : seules les minutes pas encore envoyées changent, et les compteurs de la carte « Journée du … » suivent. Un tic par minute en rend la tranche révolue et l'enfile aussitôt.

Ce partage n'est pas un détail d'implémentation. Une communauté de cent utilisateurs produit de l'ordre de 130 000 messages par jour : les rendre tous à minuit pour les faire dormir dans Redis jusqu'à leur minute, ce seraient cent trente mégaoctets de charge utile en attente. Le plan tient en quelques milliers de compteurs ; le tic rend la minute qu'il envoie.

Le fuseau se choisit dans une liste et non un champ libre, comme sur un banc : Asia/Tokio serait accepté par le formulaire et refusé par le serveur, ce qui ferait découvrir la faute une requête trop tard. L'indice sous le champ nomme sa provenance — « hérité de la population » se corrige sur la population, « réglé sur cette communauté » ici.

Le plan naît à 00:00 locale, pas à 01:00. Les archétypes produisent des gestes dès minuit — le « Bruit système » résout des noms en continu —, et planifier une heure plus tard perdrait la première heure en silence, chaque jour.

Un seul mécanisme couvre les trois cas : le passage de minuit, un redémarrage à trois heures du matin, et une activation à quatorze heures.

Le week-end : une conséquence devenue un réglage

Les neuf archétypes métier vivent du lundi au vendredi — c'est le défaut de chaque action du workflow. Une communauté produisait donc une journée vide le samedi, et ce n'était pas un choix : c'était une conséquence, que rien à l'écran ne permettait de changer.

La case Week-end joué comme un jour ouvré l'ouvre. Cochée, le samedi et le dimanche lèvent le filtre des jours actifs : chaque action part comme un mardi. Ce n'est pas un second filtre au-dessus de celui du workflow — il le contredirait —, c'est la levée du premier, deux jours sur sept.

Les jours, pas les heures. Les fenêtres horaires des actions ne bougent pas : un samedi se joue de 8 h à 18 h comme un mardi, nuit creuse comprise. Le libellé le dit lui-même, et le champ s'appelle weekendGeneration plutôt que roundTheClock : ni l'un ni l'autre ne promet une journée continue.

Un jour ouvré, lui, reste inchangé au bit près : le filtre des jours ne consomme aucun tirage, si bien que cocher la case ne déplace aucun horodatage d'une journée déjà simulée. C'est ce qui permet de la cocher sur une communauté qui tourne.

Cocher un samedi en cours de journée

L'émission suit dans la minute — le plan en cache se périme sur la configuration —, et les compteurs de la carte « Journée du … » aussi : la journée se recalcule sur le nouveau plan. Ce qui est déjà parti l'a été sous l'ancienne configuration, si bien que le reste à envoyer mêle les deux jusqu'au soir ; l'écart tient à la seule tranche déjà partie.

Activer à 14 h n'envoie pas la matinée

Et c'est dit. Les gestes déjà passés au moment du plan sont écartés, et comptés : l'écran annonce « 9 406 écartés (déjà passés à la planification) ». Retrancher en le disant n'est pas rogner dans le dos — c'est la règle que le banc tient déjà pour une tranche révolue.

Un rattrapage est borné, et compté

Un backend arrêté trois heures ne rejoue pas 180 minutes : cela ferait arriver trois heures de journée dans la même minute, en se disant du matin. Au plus cinq minutes sont rattrapées ; le reste est compté et affiché.

Suivre les générateurs

L'onglet Aujourd'hui montre, par technologie : ce qui est prévu, ce qui est envoyé, ce qui est en échec, et si elle est coupée.

Le prévu vient du plan du jour ; l'envoyé et l'échec sont comptés sur les envois réellement postés, jamais sur un compteur tenu à part. Deux colonnes pour un seul nombre finissent par diverger, et celle qui aurait divergé est celle qu'on regarde.

La page se met à jour d'elle-même à chaque envoi terminé, sans rechargement — le même mécanisme que Envois : une annonce sert de signal pour relire les données, qui restent lues en base. Une annonce perdue ne laisse donc jamais l'écran dans un état faux.

La coupure : cent échecs d'affilée

Au-delà de 100 envois définitivement en échec d'affilée, une technologie se coupe d'elle-même, et l'écran affiche la raison — ce que l'intake a répondu, mot pour mot.

Trois choses valent d'être connues.

Le grain est la technologie, jamais la communauté. Une clé d'intake fausse est de loin la cause la plus probable d'une série d'échecs, et couper les sept technologies qui fonctionnent pour l'unique qui échoue serait une panne bien pire que celle qu'on répare. La communauté ne s'arrête que lorsqu'il ne reste plus rien qui émette — et sa raison nomme alors les technologies.

Le compte porte sur des envois, pas des messages. Un lot en porte jusqu'à mille : compter des messages ferait franchir un seuil de cent en un seul lot. Cent lots, c'est de l'ordre de deux minutes d'une communauté active — assez pour absorber une indisponibilité d'intake, trop peu pour laisser marteler une intake qui refuse la clé.

Le rallumage est un geste manuel, et il est essentiel : la coupure est automatique, la remise en route ne peut pas l'être — il faut que quelqu'un dise que la cause est traitée. Rallumer remet la série à zéro ; sans cela, le premier échec suivant recouperait aussitôt, et corriger une clé n'aurait servi à rien.

Un envoi qui aboutit remet la série à zéro. Les tentatives intermédiaires ne comptent pas : un envoi qui réussira au coup suivant ne dit rien de la santé de l'intake.

Les clés d'intake

Le contrat est exactement celui d'un banc : une clé enregistrée n'est jamais réaffichée, l'écran n'en montre que le masque — ••••1a2b —, et laisser le champ vide la conserve. L'effacer demande un geste explicite : vider le champ ne peut pas vouloir dire « efface », puisque c'est ce que veut dire « conserve ».

La clé est lue à l'instant de poster, jamais avant. Un lot ne porte que la provenance de sa clé.

Créer les intakes dans Sekoia

Plutôt que de créer chaque intake à la main dans Sekoia et d'en recopier la clé, SekoiaCraft peut la créer, avec la clé d'API Sekoia de la communauté. Il n'y en a qu'une : réglée dans la carte API Sekoia de l'onglet Réglages, elle envoie aussi les inventaires et crée les connecteurs d'assets — voir Créer un connecteur dans Sekoia. Elle doit donc avoir le droit de configurer les intakes de l'espace de la communauté, en plus de ses droits sur les assets ; le refus de Sekoia le dit sinon. Elle suit le contrat des autres clés — seul son masque revient, et laisser le champ vide la conserve. La carte montre aussi l'entité Sekoia à laquelle les intakes se rattachent, dès que la première l'a créée.

Une fois la clé enregistrée, une technologie sans clé d'intake porte un bouton Créer dans Sekoia dès qu'on la coche — sans enregistrer la liste d'abord. Un clic :

1. lit le compte de la clé (GET /v1/me) pour trouver sa communauté Sekoia ;
2. crée, la première fois seulement, l'entité de la communauté — nommée <communauté> Entity ;
3. crée l'intake — nommée d'après le format Sekoia et la communauté, HarfangLab EDR Team3 par exemple — et en pose la clé.

La clé d'intake va de Sekoia à la base sans traverser l'écran : seul son masque revient. Les vingt-huit technologies du corpus se provisionnent toutes, et Nozomi Vantage, que SekoiaCraft sème lui-même, aussi :

Technologie	Format Sekoia
HarfangLab EDR	HarfangLab EDR
Fortinet FortiGate	Fortinet FortiGate
Sekoia Agent	Sekoia.io Endpoint Agent
Windows	Windows
Microsoft Entra ID	Microsoft Entra ID
Office 365 Message Trace	Microsoft 365 Message Trace
Netskope	Netskope
Zscaler ZIA	Zscaler Internet Access
VMware vCenter	VMware vCenter
VMware ESXi	VMware ESXi
Veeam Backup & Replication	Veeam Backup
Systancia Cleanroom	Systancia Cleanroom
Palo Alto NGFW	Palo Alto NGFW
Microsoft IIS	Microsoft IIS
Bind	Bind
Apache HTTP Server	Apache HTTP Server
Microsoft Defender XDR	Microsoft Defender XDR
Office 365	Microsoft 365
Akamai WAF	Akamai WAF
CrowdStrike Falcon	CrowdStrike Falcon
CrowdStrike Falcon Telemetry	Crowdstrike Falcon Telemetry
Github Audit Logs	Github Audit logs
Google Workspace	Google Workspace
Palo Alto Cortex	Palo Alto Cortex
Salesforce	Salesforce
SentinelOne	SentinelOne EDR
SentinelOne Cloud Funnel	SentinelOne Cloud Funnel
SentinelOne Identity	SentinelOne Singularity Identity
Nozomi Vantage	Nozomi Vantage

Une technologie créée par Nouveau générateur, sur l'écran Générateurs, n'a pas de bouton : sa clé se saisit toujours à la main.

Sur un pool, la grille de livraison crée aussi toutes les intakes possibles d'une équipe, ou de toutes, d'un geste — voir Créer toutes les intakes d'un geste.

Dans Sekoia, seize de ces intakes sont alimentées par un connecteur de collecte, qui tire les journaux de l'éditeur : Microsoft Entra ID, Office 365 Message Trace, Microsoft Defender XDR, Office 365, et les douze à configuration de module ci-dessous. Sekoia en exige un pour créer l'intake : SekoiaCraft le crée donc sur une configuration factice, puis l'arrête cinq secondes plus tard (POST /v1/symphony/connector-configurations/<uuid>/stop) — c'est SekoiaCraft qui envoie lui-même les journaux à l'intake. Si Sekoia répond que le connecteur démarre encore (Cannot stop a starting connector), SekoiaCraft attend cinq secondes de plus et réessaie, quinze secondes au plus. La clé est posée d'abord, avant l'attente : une création à connecteur prend donc de cinq à quinze secondes de plus. Si l'arrêt échoue, la création réussit quand même, et un avertissement sous l'avis dit que le connecteur tourne encore, avec sa configuration et la réponse de Sekoia : arrêtez-le dans Sekoia.

Les connecteurs de Netskope, d'Akamai WAF, de CrowdStrike Falcon, de CrowdStrike Falcon Telemetry, de Github Audit Logs, de Google Workspace, de Palo Alto Cortex, de Salesforce, de SentinelOne, de SentinelOne Cloud Funnel, de SentinelOne Identity et de Nozomi Vantage exigent en outre une configuration de module, créée d'abord (POST /v1/symphony/module-configurations) sous le nom de l'intake, puis référencée par elle. Elle n'est jamais réutilisée : chaque clic crée la sienne. Si l'intake est ensuite refusée, la configuration de module reste dans Sekoia, et le motif la nomme, avec son UUID, pour qu'on l'y supprime.

• Le bouton suit la case, pas la liste enregistrée : cocher l'affiche, décocher le masque — sans JavaScript aussi. Le clic retient cette technologie, et elle seule, avant de créer son intake ; le reste de la liste attend toujours Enregistrer les technologies. Si Sekoia refuse, la technologie reste retenue, sans clé, et le bouton reste offert.
• Une technologie munie d'une clé n'a jamais de bouton. Pour créer une nouvelle intake, effacez d'abord la clé — la précédente reste dans Sekoia.
• L'adresse suit la région de la communauté — https://app.sekoia.io/api/v1/… pour FRA1 —, ou la base d'API d'une destination personnalisée, réglée à côté de la clé dans l'onglet Réglages. Sans elle, le bouton est désactivé et dit pourquoi.
• L'entité est réutilisée pour les technologies suivantes. Si la clé mène à un autre espace Sekoia, une nouvelle entité y est créée.
• Un refus s'affiche dans la carte : l'étape que Sekoia a refusée (le compte, l'entité, l'intake), le statut HTTP, une piste — un 403 dit que la clé n'a pas les droits —, le point d'entrée, et la réponse de Sekoia, la clé masquée.
• Rien n'est rejoué de soi-même : une création restée sans réponse a pu avoir lieu dans Sekoia. Vérifiez-le là-bas avant de recliquer.

Le volume, découvert avant

Avant activation, l'écran sait chiffrer ce qu'une journée entière produira : utilisateurs attribués, messages, requêtes. C'est un geste — « Chiffrer la journée » —, pas un calcul d'office : dérouler la journée de chaque utilisateur prend de l'ordre d'une seconde pour une population de cent, et api-activity ne ferait rien d'autre pendant ce temps, ni ordonnancer, ni envoyer. Le chiffre vit dans l'URL, donc l'écran reste partageable et le geste marche sans JavaScript.

Aucun plafond ne refuse — une communauté est faite pour tourner, et la borne de 25 utilisateurs du banc existait pour un geste manuel. Mais on découvre le volume avant, pas après ; c'est la même règle que l'aperçu d'un banc, qui ne refuse jamais et compte toujours juste.

Sur demo-metacortex — 101 utilisateurs, trois technologies — une journée pèse environ 37 800 messages et 2 400 requêtes.

Les trois tranches

Une communauté déroule trois tranches : ses utilisateurs, les serveurs auxquels un archétype de sujet SERVER a été attribué, et les sites auxquels un archétype de sujet WEBSITE l'a été.

Les serveurs

Les archétypes de sujet SERVER ne décrivent pas le geste d'un employé mais ce qu'une machine fait d'elle-même — la réplication d'annuaire d'un contrôleur de domaine, les transferts de zone d'un serveur DNS, la tâche de nuit d'un serveur de sauvegarde, et sur tout serveur Windows le rapport de santé de l'antivirus et le service dont son rôle ouvre le port. Personne ne les déclenche, et aucun poste ne les écrit.

L'attribution suit le rôle que le nom de la machine annonce (SRV-DC-01 → directory), déduit à l'import. Chacun des seize rôles est revendiqué par un archétype semé : seules les machines dont le nom n'annonce rien restent non attribuées. Trois différences avec celle des utilisateurs, et chacune porte :

• aucun repli par profil. Un profil d'entreprise est un mélange de métiers ; en inventer un de serveurs ferait écrire une réplication d'annuaire par le serveur de fichiers. Sans rôle revendiqué, la machine n'est pas attribuée — et l'écran la nomme ;
• un serveur non attribué est normal, là où un utilisateur non attribué est un défaut. Les deux listes sont donc séparées à l'écran : une machine dont le nom n'annonce aucun rôle — treize des 110 serveurs de démonstration — ne joue rien, et c'est attendu ;
• un rôle revendiqué par deux archétypes n'attribue rien et se signale, exactement comme une unité d'organisation.

Le volume reste négligeable : un serveur Windows écrit une trentaine de messages de socle par jour, un contrôleur de domaine ou un serveur DNS quelques centaines — environ un millier de messages par jour pour les vingt serveurs de Metacortex, contre ~130 000 pour cent utilisateurs.

Les sites

Un site de la population joue les visites qu'il reçoit : la requête vient d'Internet, elle n'est pas émise par un employé. C'est la seule tranche qui alimente les technologies servantes — Apache HTTP Server, Microsoft IIS, le WAF Akamai —, dont les 56 messages types de portée EXTERNAL_CLIENT ne partent d'aucune autre. Sans site attribué, ces trois technologies restent muettes même activées, et rien d'autre ne l'explique.

L'attribution suit le site_role que le jeu de données déclare — c'est le contraire exact du serveur, dont le rôle est déduit de son nom. Le reste est identique : appariement exact, pas de repli par profil, pas de tirage, refus d'un rôle que deux archétypes revendiquent, sites sans rôle non attribués et nommés. Un rôle que le vocabulaire ne connaît pas n'est ni refusé ni rattrapé : il ne s'apparie à rien, et l'écran le range parmi les rôles sans preneur.

L'archétype semé « Visiteur du site public » revendique les treize rôles du corpus, intranet et extranet compris. Contrepartie assumée : un intranet reçoit donc des visiteurs venus d'Internet. Le levier n'est pas de rogner cette liste mais un second archétype aux faits de visiteur interne — et il faudra alors retirer ces deux rôles du premier, deux archétypes qui revendiquent le même rôle n'attribuant rien.

Le volume est modeste et se compte en requêtes : une visite toutes les cinq minutes, jour et nuit, soit 288 gestes par site — environ 1 700 par jour pour six sites, contre ~130 000 pour cent utilisateurs. Mais chaque minute peuplée fait un lot par technologie : les requêtes, elles, montent d'un bon tiers. C'est le chiffre que l'onglet « Aujourd'hui » donne avant l'activation.

Le sujet, des deux côtés

Un archétype ne joue que les gestes de son sujet. L'éditeur ne propose à un serveur que les gestes d'un serveur, et l'enregistrement refuse le reste : une action hors sujet ne produirait rien du tout, et l'auteur croirait avoir décrit un geste. Le sujet se choisit à la création et ne se change plus ensuite — en changer sur un graphe déjà peuplé viderait sa journée en silence.

Plusieurs équipes, le même contenu

Pour une session de Capture The Flag, une communauté devient le modèle d'un pool — son gabarit : ses équipes reçoivent exactement les journaux, les assets et les menaces qu'elle aurait produits, chacune vers ses intakes, pendant qu'elle-même est arrêtée et n'envoie rien. Les réglages de production — population, fuseau, week-end, menace, attributions — se règlent alors sur le modèle ou sur n'importe laquelle des équipes et valent pour toutes ; un bandeau le dit sur chaque onglet. Les technologies se choisissent sur l'écran du pool, et l'onglet Technologies d'une équipe n'en règle que les clés d'intake. « En faire un pool », en tête d'une communauté, est l'endroit d'où un pool naît.

Ce qu'une communauté ne simule pas encore

• La couche ambiante et les alertes : comme le banc, elle ne joue que la couche corrélée. Les volumes réels d'une production seraient plus élevés.
• Les rôles ne s'éditent pas depuis l'écran : les unités d'organisation, les rôles de serveur et les rôles de site que chaque archétype dessert vivent dans le seed. L'écran sait nommer un rôle que personne ne dessert ; il ne sait pas encore le combler.
• Le trafic ne varie pas selon le rôle du site : un CDN et un blog reçoivent la même cadence.
• L'activité SOC viendra avec le module qui la produit. Les assets OCSF, eux, sont en place : voir Assets OCSF.

Essayer en local

Avec un intake bouchon plutôt qu'une vraie région :

node apps/web/e2e/mock-intake.mjs

Destination « URL personnalisée », http://localhost:4599/batch. Le bouchon accepte le corps { intake_key, jsons }, GET /received rend ce qu'il a reçu, et POST /batch?status=500 permet d'éprouver la coupure.