Bancs d'essai

Un banc d'essai rejoue la journée d'un archétype vers de vraies intakes. C'est l'écran qui répond à la question que ni le workflow ni la couverture ne tranchent : à quoi ressemble réellement ce que cet archétype produit, et une intake l'accepte-t-elle ?

/essais liste les bancs ; chacun ouvre trois onglets.

Ce qu'un banc retient

Réglage	Ce qu'il décide
Archétype	Le workflow qui décrit la journée
Population	Les utilisateurs, serveurs et sites du rendu
Utilisateur	Un seul, ou toute la population — chacun avec sa propre journée
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
Fuseau	L'heure à laquelle la population vit — hérité d'elle, surchargeable ici

Un banc est enregistré. C'est tout l'intérêt : on l'ouvre, on règle une action dans l'archétype, on relance, on compare. Ressaisir huit clés d'intake à chaque essai rendrait ce geste impraticable — précisément celui pour lequel l'écran existe.

Les trois étendues

Étendue	Ce qu'elle produit	Pourquoi
Journée entière	De minuit à minuit	Voir la journée que l'archétype décrit
Fenêtre horaire	Un créneau, par exemple 08:00–09:00	Juger une matinée sans envoyer les 24 heures
Une minute	Une minute exacte	La tranche que l'ordonnanceur per-minute émettra

La journée est toujours calculée entière, puis tranchée. Ce n'est pas un détail d'implémentation : c'est ce qui garantit qu'une minute est littéralement un sous-ensemble de son heure, et de sa journée. Sans cela, le banc mentirait sur ce que l'ordonnanceur enverra — il rendrait à la même minute autre chose.

Le jour simulé est hier par défaut. Une journée entière datée d'aujourd'hui produirait des logs post-datés, qu'une intake indexerait dans le futur.

Aperçu puis envoi

Le geste est en deux temps, comme l'onglet Aperçu d'un message type.

L'aperçu construit la journée, la projette vers les technologies retenues, et n'en rend qu'un échantillon. Il ne refuse jamais : c'est là qu'on découvre le volume, avant de l'envoyer. Ses comptes sont exacts même au-dessus du plafond, parce que projeter ne coûte aucun rendu.

L'envoi rend tout, puis met en file. Le découpage par technologie n'est pas une optimisation : un lot porte une clé d'intake, et la clé est portée par la technologie.

Le bouton d'envoi vit dans une barre collée au bas de l'écran, avec le volume qui partira et ce qui empêcherait qu'il parte — plafond dépassé, messages déjà passés. Ce n'est pas un raccourci : le banc est un instrument d'itération, et l'aperçu qui sépare les deux boutons fait plusieurs écrans de haut dès qu'il rend ses vingt messages. La barre n'est pas un second bouton, c'est le bouton : un envoi part toujours des réglages de l'aperçu affiché, et deux contrôles pour un même geste finiraient par n'en plus porter les mêmes.

Ce que l'aperçu montre

• La chronologie — un geste par ligne, avec ce qu'il met en jeu et les technologies qui l'ont vu. C'est ici que se lit la corrélation : un même login apparaît au même instant dans l'EDR et dans le journal Windows, parce qu'il n'y a qu'un geste, projeté vers les deux. La colonne Objet nomme ce que ce geste joint — l'hôte, le processus, le document —, et c'est cette valeur-là que chaque charge utile porte. Aucun autre écran du produit ne montre cela.

• Les volumes par technologie — combien de messages, sur combien de messages types distincts.

• Les gestes par action — la symétrique de la carte précédente : les deux axes du même total. Pour chaque nœud du workflow, combien de gestes il a produits, combien de messages en sont sortis, et combien de technologies l'ont vu sur celles du banc. C'est la seule carte qui rend le fan-out lisible, et il est très inégal : sur sept technologies, une navigation web est vue par les sept, une résolution DNS par cinq, une tâche planifiée par deux. Un geste rare et peu observé — typiquement le bruit système qu'un super-archétype partagé apporte — se noie sinon dans le volume du métier, et son absence apparente se lit comme une panne. Sous le tableau, les actions dont aucun message n'est sorti sont nommées, avec les technologies qui n'en ont rien tiré : « vu par 2 sur 7 » dit qu'il y a quelque chose à regarder, le nom dit dans quelle intake regarder.

  Elle est montée avant la chronologie à dessein : celle-ci est tronquée à ses 120 premières lignes, et ne permet donc jamais de conclure une absence.

• Les bifurcations du jour — pour chaque bifurcation de l'archétype, combien d'utilisateurs ont pris chaque chemin : Soirée VPN — Accès distant du soir : retenu pour 9 des 25, et les issues vides de même — en heures pour une bifurcation horaire. Rendue même quand un chemin est retenu partout, parce que le tirage est un fait de la journée et pas seulement l'explication d'une absence : sans elle, un chemin retenu pour neuf utilisateurs sur vingt-cinq apparaîtrait uniquement dans la carte suivante, comme n'ayant rien produit.

• Ce qui n'a rien produit, et pourquoi. Deux causes opposées, qu'il faut distinguer :

  • une action sautée — « tirage de probabilité », « chemin non retenu », « enchaînement rompu », « aucun serveur dans la population » : cela se règle dans le workflow ;
  • un trou de couverture — aucune technologie retenue ne réalise l'action : cela se règle dans les messages types. Un profil commercial suivi par un EDR et un proxy verra ainsi son authentification cloud rester muette, faute d'annuaire parmi les technologies cochées : le banc le dit plutôt que de rendre l'action par un message type sans rapport.

• Les actions décalées — celles qui ont eu lieu après leur borne haute, parce que l'enchaînement prime sur la fenêtre. Ni un renoncement ni un défaut : une matinée rendue à 20 h passerait pour un dérèglement du moteur si personne ne disait que c'est l'arrivée tardive qui l'a repoussée.

• Les messages rendus, tels qu'ils partiront, répartis sur les technologies plutôt que pris en tête — les vingt premiers messages d'une journée viennent tous de l'arrivée au bureau.

Les faits d'un geste : ce que toutes les technologies nomment pareil

Un geste ne porte pas qu'un instant et une entité : il porte aussi ce qu'il met en jeu. Une navigation joint un hôte, à une adresse, pour une application ; un lancement d'application démarre un binaire, avec un pid ; une modification de document touche un fichier, dans un répertoire.

Ces faits sont calculés une fois, avant que le geste ne soit projeté vers les technologies. Toutes ses projections reçoivent donc les mêmes. Concrètement, pour une même navigation :

Technologie	Ce qu'elle écrit
Windows — requête DNS Sysmon	QueryName: www.lemonde.fr · Image: …\chrome.exe
Windows — connexion réseau Sysmon	DestinationHostname: www.lemonde.fr · DestinationIp: 151.101.1.91
Sekoia Agent — résolution DNS	question.name: www.lemonde.fr · resolved_ip: 151.101.1.91
Sekoia Agent — connexion réseau	destination.ip: 151.101.1.91 · port: 443 · executable: …\chrome.exe
Netskope	urlhost: www.lemonde.fr · dstip: 151.101.1.91 · app: Le Monde
Zscaler	hostname: www.lemonde.fr · serverip: 151.101.1.91 · action: Allowed
FortiGate — trafic	dst=151.101.1.91 · dpt=443 · FTNTFGTapp=Le Monde · dstcountry=France
Palo Alto NGFW — trafic	dst_ip: 151.101.1.91 · dst_port: 443 · url_category: news-and-media
SentinelOne Cloud Funnel	dst.ip.address: 151.101.1.91 · src.process.name: chrome.exe

Sekoia Agent ne nomme pas d'hôte dans sa connexion réseau : son format n'a pas ce champ. C'est la résolution DNS du même geste qui le nomme, et c'est ce couple qui rend la corrélation lisible — lui inventer un champ ferait dire à l'agent autre chose que ce qu'il émet réellement.

Toutes les technologies ne lisent pas encore les faits. Onze le font aujourd'hui (Windows, Netskope, Zscaler, BIND, Sekoia Agent, HarfangLab, CrowdStrike Telemetry, FortiGate, Palo Alto NGFW, Palo Alto Cortex, SentinelOne Cloud Funnel) ; les autres tirent encore dans leur propre corpus, et deux d'entre elles décriront donc le même geste en le nommant différemment. C'est une dette connue, et elle se comble gabarit par gabarit.

Les quatre pare-feu et proxys de cette liste y sont entrés ensemble, et c'est le rattrapage le plus visible : ce sont eux que la répartition range sous les six gestes qui joignent une destination, si bien qu'ils décrivaient chaque navigation. FortiGate annonçait dst=10.0.1.100 dpt=3389 — une session RDP tirée dans ses quatorze lignes d'exemples — pendant que Windows et Netskope nommaient le site réellement consulté, à la même seconde et pour le même utilisateur.

Trois conséquences valent d'être connues.

Les faits ne dépendent ni de l'essai ni des technologies cochées. Ils se dérivent de l'identité du geste, laquelle se dérive de l'entité, du jour, du nœud du workflow et du rang de l'occurrence. Deux bancs qui rejouent la même journée du même utilisateur nomment donc les mêmes sites — et cocher une technologie de plus ne change pas un seul message des autres.

Un fait s'impose par groupe, jamais par champ. Imposer l'hôte en laissant l'application au hasard ferait dire « GitHub » sur drive.google.com : un message cohérent avec les autres et incohérent avec lui-même. La destination part donc entière — hôte, URL, adresse, port, application, catégorie, pays, politique, verdict. La règle vaut aussi pour les champs machine qui doublent un champ lisible : un pare-feu qui écrit « Le Monde » en clair et l'identifiant d'application du bureau à distance juste à côté se contredit dans deux champs voisins, et l'identifiant suit donc le nom.

Le verdict appartient au geste, pas à l'observateur. Deux proxies ne peuvent plus se contredire sur la même navigation. Dans le flux métier il vaut toujours « autorisé » : un geste que le workflow décrit est un geste qui a réussi. Les refus relèveront des scénarios de menace.

Une authentification aussi porte les siens. Une ouverture de session met en jeu une issue, un type de session — interactive, réseau, déverrouillage, bureau à distance — et un protocole. Les trois appartiennent au geste, pour la même raison que le verdict d'une navigation : Windows tirait son type de session parmi quatre valeurs pendant que Sekoia Agent en tirait deux, si bien que les deux outils décrivaient la même connexion distante avec le même horodatage, le même utilisateur, et deux types de session différents sept fois sur huit. Ils s'accordent désormais par construction, et l'issue suit la même règle que le verdict : elle vaut « succès » dans le flux métier, sauf pour l'action « Échec d'authentification », qui dit ce qu'elle nomme.

Le pid identifie un processus, pas un geste. Le pid et l'identifiant de processus se dérivent de l'utilisateur, du jour et du binaire — pas de l'occurrence. Le navigateur d'un même poste garde donc le même pid toute la journée, comme un vrai processus, et deux technologies qui décrivent le même geste en nomment le même. Une technologie ne se voit imposer le pid que si elle tient déjà le binaire du geste : lui imposer l'un sans l'autre ferait dire « pid 4048, svchost.exe » à côté de « pid 4048, OUTLOOK.EXE » — la contradiction déplacée d'un cran plutôt que corrigée.

Le processus suit la destination. Un navigateur parle HTTP(S) ; tout autre service désigne le client qui le parle nativement. Un accès au relais de soumission de la messagerie lance donc un client de messagerie, jamais un navigateur — un chrome.exe sortant sur le port 587 était un message qui se contredisait dans deux champs voisins, alors que les deux venaient du même fait. Une destination peut surcharger la règle quand du HTTPS est parlé par autre chose : outlook.office365.com est le point d'accès d'un Outlook lourd, quand outlook.office.com et mail.google.com sont bien consultés dans un onglet. Même distinction pour les gestes de machine — une mise à jour Windows relève d'un service système, pas d'une navigation.

Les destinations vivent dans un jeu de données partagé (« Destinations web »), modifiable depuis l'écran des jeux de données : un parc applicatif qui n'est pas celui du catalogue s'y ajoute sans déploiement. Les clients de messagerie ont le leur (« Clients de messagerie »), pour la même raison — le corpus n'en porte aucun. Les navigateurs, les processus système et les documents réutilisent les pools du corpus.

Quelle technologie voit quel geste

Une technologie ne réalise pas toutes les actions d'un workflow, et c'est ce qui rend un essai lisible : cocher un annuaire et un pare-feu ne doit pas produire deux fois le même log.

Le partage se fait en deux familles.

Les journaux qui nomment leur geste. lightning-page-view chez Salesforce parle d'une page Salesforce, sysmon-dns-query d'une résolution DNS, nspolicy-download d'un téléchargement. Ils réalisent une action, celle que leur nom décrit.

Les journaux de transaction. Un proxy, un pare-feu, un agent au niveau socket ne voient pas quel geste métier ils transportent : ils voient une requête sortante. nspolicy-allow de Netskope, sysmon-network-connection de Windows, network-connection de Sekoia Agent réalisent donc toutes les actions qui joignent une destination — navigation, CRM, messagerie, messagerie instantanée, visioconférence, transfert de fichier. Ce sont les faits du geste qui distinguent les six : une même ligne Netskope dira app: Salesforce / category: CRM pour un accès au CRM et app: Le Monde pour une lecture d'actualité.

Deux conséquences.

Le sens du flux compte. Un serveur web — Apache, IIS, un pare-feu applicatif — décrit le trafic entrant vers les sites de l'entreprise. Son journal ressemble trait pour trait à celui d'un proxy, et décrit l'inverse : il ne réalise donc que la navigation, jamais la famille entière.

Toute technologie qui couvre l'action voit le geste, dès qu'elle sait le décrire. Il n'y a pas de part d'observation : si une technologie est cochée et qu'elle réalise l'action, elle produit un message, à chaque occurrence. C'est ce qui rend la corrélation lisible — un même instant décrit par toutes les sources à la fois, exactement ce qu'un SOC rapproche.

La nature du flux compte, elle aussi. Un journal de proxy web ne décrit que du HTTP(S) : il n'a rien à dire d'une soumission SMTP. Un geste de messagerie sur quatre joint smtp.office365.com en 587, et Netskope comme Zscaler s'y taisent — ils n'ont aucun autre message type à offrir sur ce geste. Ils continuent de décrire les trois autres, ceux qui passent par le web. Les pare-feu et les agents, eux, voient les quatre : un flux SMTP est un flux comme un autre pour qui observe la socket. Ce n'est donc pas une part d'observation retrouvée par la bande : le repli se lit sur les faits du geste, et la technologie ne se retire que là où aucun de ses journaux ne sait décrire ce qu'elle voit.

Une technologie rend un message type par geste, le plus lourd de ceux qui réalisent l'action. Un même login ne produit pas trois lignes dans le même EDR ; le poids d'un message type sert à départager, et un poids nul le réserve aux alertes.

La table est modifiable : l'écran d'un message type permet d'ajouter ou de retirer une action, et la correction survit au réimport du corpus. Ce que le produit déduit du nom n'est qu'un point de départ.

La cadence : quand chaque message part

Un message porte son propre instant. Tout envoyer d'un coup fait donc arriver dix heures de journée dans la même seconde : l'heure portée et l'heure d'arrivée se contredisent, et l'intake indexe la contradiction. Trois cadences répondent à cela. Elle se règle sur le banc, dans Réglages, et se surcharge à chaque essai.

Cadence	Ce qu'elle fait	Quand la choisir
Immédiat séquencé (défaut)	Tout part maintenant, un message par requête, espacés de l'intervalle	Itérer : régler, relancer, comparer
Chronologique	Chaque message part à l'heure qu'il porte ; ce qui est déjà passé est écarté	Voir ce que fera l'ordonnanceur per-minute
Rejeu en direct	La tranche est recalée sur maintenant, et les horodatages réécrits à l'instant d'envoi	Démonstration, rejeu à l'échelle 1:1

L'aperçu annonce ce que la cadence fera du temps — nombre de requêtes, premier et dernier envoi, durée — avant qu'on envoie. 25 000 messages à une seconde, ce sont 25 000 requêtes et près de sept heures : c'est le genre de chose qu'il vaut mieux découvrir à l'aperçu.

En cadence chronologique, le lot d'une minute part à la fin de cette minute. Ce n'est pas un détail : c'est exactement la tranche que le futur ordonnanceur émettra à chaque tick, si bien que le banc préfigure le planificateur au lieu de le contredire d'une minute.

En rejeu en direct, les horodatages sont décalés avant le rendu. Ne retarder que la livraison enverrait à 16 h un message se disant de 9 h ; ici, le message est daté de son arrivée. Une tranche d'une heure occupe donc une heure, et une journée entière vingt-quatre.

Un essai programmé peut s'arrêter : Annuler les envois programmés retire de la file les lots qui n'ont pas encore été envoyés, et dit combien. Ce qui est parti, lui, ne l'est plus.

Programmer pour plus tard

Une date à venir est acceptée sans réserve : rien n'est en retard, donc rien n'est écarté. C'est la façon normale d'utiliser la cadence chronologique — on prépare le soir la journée du lendemain, et elle se déroule toute seule.

Ce qui se passe alors mérite d'être connu, parce que rien de tout cela n'est visible :

• Tout est rendu au moment où vous cliquez. Les messages ne sont pas fabriqués à l'échéance : ils partent dormir dans Redis, charge utile complète, jusqu'à quarante-huit heures. Un essai de journée entière, ce sont un millier de lots en attente.
• Ils survivent aux redémarrages — de l'envoyeur comme de Redis, qui persiste sur disque. Un envoyeur relancé après l'échéance rattrape les lots mûrs et les poste d'un coup.
• La clé d'intake n'est lue qu'à l'instant de poster. C'est ce qui évite qu'un secret dorme des heures dans la file — mais cela veut dire qu'effacer la clé, ou supprimer le banc, entre la programmation et l'échéance fait échouer les lots restants. L'échec est définitif, sans réessai, et laisse une ligne d'historique qui le dit.
• Annuler reste possible tant que le lot n'est pas parti, et l'écran annonce en permanence combien de lots attendent encore dans la file.

La journée simulée est à l'heure de la population

La journée d'un archétype est ancrée sur minuit chez la population qui la joue. Une action réglée sur 08:00 a lieu à 08:00 pour ses utilisateurs — où qu'ils vivent, et quelle que soit la saison.

Le fuseau se règle sur la population (/datasets/…, carte « Métadonnées ») : c'est elle qui habite quelque part, pas le banc qui la rejoue. Un banc en hérite, et peut le surcharger dans ses réglages — de quoi rejouer la même population à deux heures différentes sans la dupliquer. Aucun fuseau réglé nulle part = UTC, c'est-à-dire le comportement d'origine.

Un fuseau IANA (Asia/Tokyo, Europe/Paris) et non un décalage en heures : le décalage est résolu pour le jour simulé, donc l'heure d'été suit toute seule. Un décalage figé serait faux six mois par an, et il faudrait retoucher chaque banc deux fois par an.

Trois référentiels, et l'écran les nomme tous

Ce qu'on lit	Dans quel fuseau
La tranche, la chronologie, la fenêtre qu'on saisit	Celui de la population
L'horodatage dans la charge utile	Toujours UTC
Les échéances d'envoi	Le vôtre, celui du navigateur

Le deuxième mérite d'être souligné : le fuseau déplace quand un geste a lieu, jamais comment il s'horodate. Un poste de travail à Tokyo expédie lui aussi ses logs en UTC — sa matinée de 08:00 arrive donc datée de 23:00 la veille, et c'est exactement ce que le banc envoie.

Deux conséquences à connaître

Le jour de la semaine se lit dans le fuseau de la population. Un archétype dont les actions sont réglées sur les jours ouvrés produit donc un aperçu vide si vous demandez un samedi : ce n'est pas une panne, c'est le workflow qui n'a rien à faire ce jour-là, et les lignes « Ce qui n'a rien produit » le disent. Un samedi japonais reste un samedi, même si sa matinée tombe un vendredi UTC.

C'est aussi ce qu'on ne veut pas subir quand on règle un archétype : le banc est un instrument d'itération, et attendre lundi pour voir ce qu'une journée produit n'en est pas un. La case « Ignorer les jours actifs des actions », sous le champ Jour simulé, lève le filtre pour cet essai. Trois choses à en savoir :

• c'est un réglage de l'essai, pas du banc. Il n'est pas enregistré, exactement comme la date dont il dépend — on le coche parce que ce jour-là tombe un samedi ;
• c'est une seule règle, quel que soit le jour : les jours actifs ne filtrent plus. La contrepartie est assumée — une action réservée au week-end partira aussi un mardi ;
• rien n'est forcé en silence. Les actions concernées sont listées sous « Actions forcées », et la tuile Jour simulé rappelle l'option même les jours où elle n'a rien changé.

Elle ne lève que le filtre des jours. Un tirage de probabilité manqué, un chemin non retenu, un enchaînement rompu restent ce qu'ils sont, et « Ce qui n'a rien produit » continue de le dire.

Un jour de bascule d'heure d'été est traité comme une journée de 24 heures, au décalage qu'il vaut à minuit local. Après la bascule, les gestes de cette seule journée sont donc décalés d'une heure. Une journée de 23 ou 25 heures serait insoluble dans un moteur dont toute l'arithmétique est en minutes depuis minuit ; le taire serait pire.

Une tranche déjà passée est écartée, jamais rattrapée

En cadence chronologique, un message dont l'heure est passée ne peut pas partir « à l'heure ». Rattraper en silence mentirait : dix heures de journée arriveraient dans la même seconde, en se disant du matin.

Ces messages-là sont donc écartés, et le reste de la tranche part normalement. Lancer à 10 h une journée commencée à 8 h envoie donc l'après-midi, et laisse la matinée. C'est le compte rendu qui fait la différence avec une fenêtre rognée dans le dos : l'aperçu annonce ce qui sera écarté avant l'envoi, et le résultat le redit après, en chiffres.

Le refus subsiste dans un seul cas : quand il ne reste rien à programmer. Il n'y a alors pas de troncature à annoncer, et un envoi qui réussirait sans rien envoyer serait plus déroutant qu'un refus.

L'avertissement nomme le levier d'une tranche complète, et ce levier dépend de l'étendue : en fenêtre horaire, décaler la borne basse à l'heure indiquée ; en journée entière, passer en fenêtre horaire — la journée entière, elle, n'a pas de borne réglable. Dans les deux cas, le rejeu en direct reste l'autre réponse : il recale la tranche sur maintenant et n'écarte rien.

Conséquence à connaître : la date par défaut d'un essai est hier, et une journée d'hier est révolue par construction. Un essai chronologique laissé sur la date par défaut est donc refusé, faute de reste à envoyer — pas envoyé à vide.

Le plafond : un refus, pas une troncature

Au-delà de 25 000 messages, l'envoi est refusé, en nommant les nombres et les deux leviers : réduire l'étendue, ou choisir un seul utilisateur.

Tronquer en silence serait pire que refuser. Un essai coupé aux 25 000 premiers messages rendrait une matinée en se présentant comme une journée, et on en tirerait une conclusion fausse. Un refus chiffré coûte un clic. C'est la même règle qui laisse écarter une tranche déjà passée : ce qui est interdit, c'est de retrancher sans le dire — pas de retrancher.

Une population de plus de 25 utilisateurs est bornée et rapportée : on ne peut rien à sa taille, mais l'écran ne fait jamais passer 25 journées pour 415.

Les clés d'intake

Une clé enregistrée n'est jamais réaffichée. L'écran n'en montre que le masque — ••••1a2b — et l'état « renseignée ».

Cela révise la règle « l'intake key n'est jamais persistée », qui reste vraie de l'envoi manuel et de l'historique. La contrepartie est structurelle, pas disciplinaire : un omit global du client Prisma retire la colonne de toutes les lectures du monorepo, et il faut un omit délibéré, visible en relecture, pour la faire réapparaître. Un seul appelant en pose un, au moment de poster — et non au moment de composer le job : un lot programmé pour 18 h ferait sinon dormir un secret dans la file pendant des heures. Le job ne porte donc que la provenance de la clé, et le service d'envoi la relit en base juste avant de la poster.

Conséquence directe dans l'écran : laisser le champ vide conserve la clé en place. L'effacer demande un geste explicite — vider le champ ne peut pas vouloir dire « efface », puisque c'est exactement ce que veut dire « conserve ».

Suivre les envois

L'envoi rend ce qui est parti en file, par technologie. Les issues réelles s'observent sur Envois : un essai pose jusqu'à une trentaine de lots, et les attendre tous ferait expirer la requête pour rien.

Chaque lot y nomme sa technologie. Un lot d'essai porte plusieurs messages types d'une même technologie — son origine est donc la technologie seule, et c'est une origine complète.

Ce qui n'est pas encore parti ne figure pas dans cette liste : la ligne d'historique naît quand le lot est posté. La page d'un banc et celle des envois annoncent donc, à part, combien de lots attendent leur heure dans la file et à quand vont la première et la dernière échéance. Sans ce décompte, un essai programmé pour le lendemain se lit le matin venu comme un essai jamais lancé.

Le déterminisme, et pourquoi il compte

Deux essais du même banc, le même jour, rendent exactement la même chose. C'est ce qui rend un essai comparable au précédent — le seul usage d'un banc.

Deux propriétés le garantissent, et elles sont testées :

• régler une action n'en déplace aucune autre — chaque action tire dans son propre flux aléatoire, sinon retoucher la probabilité du déjeuner décalerait les 74 relevés de messagerie de la journée, et l'écran passerait pour non déterministe ;
• cocher une technologie de plus n'en change aucune autre — chaque couple (geste, technologie) tire dans le sien.

Ce que le banc ne simule pas

Il ne joue que la couche corrélée : les gestes du workflow, projetés vers les technologies. Le trafic ambiant propre à chaque technologie et les alertes viendront avec les étapes qui les produisent. Les volumes d'un essai sont donc plus bas que ceux d'une production réelle.

Les trois générateurs alertHeavy (CrowdStrike Falcon, Microsoft Defender XDR, SentinelOne Identity) ont une couverture métier vide par construction : retenus sur un banc, ils n'émettront rien. L'écran le signale à la sélection.

Les faits d'un geste ne se transmettent pas d'un geste à l'autre : une résolution DNS et une navigation sont deux gestes distincts, avec deux destinations. Rien ne dit encore que la première résout ce que la seconde joint — au sein d'un geste, en revanche, la requête DNS et la connexion réseau nomment bien le même hôte.

Enfin, tous les gabarits ne lisent pas encore les faits : la migration se fait technologie par technologie. Un message type non migré tire dans son propre pool, comme avant, et l'écran le montre — sa ligne porte un objet que sa charge utile ne nomme pas.

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 }, et GET /received rend ce qu'il a reçu.