feat(e2e): add distributed E2E test framework with parametric traffic generation

Add run-e2e-test.sh with CLI parameters (--hits, --http-ratio, --dns, --tls,
--src-ips, --keep-analysis, --up) for configurable traffic generation. Traffic
runs from VM endpoints with multiple source IPs (alias IPs on eth0) to produce
distinct sessions for the ML pipeline. Fix curl TLS flags (--tlsv1.2 instead
of --tls-v1-2), skip redundant local verification in distributed mode, and
fix dashboard is_available() cache that never retried after ClickHouse recovery.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

docs/thesis/00_resume.md

@@ -11,7 +11,7 @@
 
 ## Résumé
 
-Ce document présente une architecture opérationnelle de détection et classification du trafic HTTP malveillant, s'inscrivant dans la continuité des approches de génération 3 (fingerprinting multi-protocole et ML comportemental). Le système exploite 96 features organisées en 8 familles couvrant les couches réseau L3 à L7, corrélant des signaux TCP, TLS et HTTP en un vecteur unifié par session. La détection repose sur un ensemble triple-voix combinant un Extended Isolation Forest (EIF), un Normalizing Flow (NF) et XGBoost, fusionnés par un méta-modèle MLP (Multi-Layer Perceptron) non-linéaire calibré sur les étiquettes accumulées. L'explicabilité est assurée par l'importance des features par profondeur d'isolation (EIF) et SHAP TreeExplainer (XGBoost). Le clustering de campagnes est réalisé par HDBSCAN dans l'espace latent 16 dimensions de l'autoencodeur, et la détection de flottes coordonnées par graphes bipartis via NetworkX. Le fingerprinting HTTP/2 passif — extraction des trames SETTINGS, WINDOW_UPDATE et de l'ordre des pseudo-headers côté serveur — exploite un signal déjà utilisé par des solutions industrielles (Akamai, Cloudflare, F5), ici implémenté via eBPF. L'infrastructure repose sur 16 modules Python (4 800 lignes), une base ClickHouse à double schéma (ja4_logs bruts TTL 2 h, ja4_processing agrégés TTL 7 j), des cycles d'analyse de 300 secondes, et traite en production plus de 3 millions de logs, environ 34 000 sessions par cycle, avec approximativement 777 anomalies détectées par cycle (≈ 2,3 % — chiffre opérationnel brut, non validé comme taux de détection). Le système intègre un moteur de profiling dynamique automatique des navigateurs (HDBSCAN sur les vecteurs H2 observés, centroïdes auto-appris, scoring temps réel par distance normalisée) qui s'adapte aux évolutions des piles HTTP/2 sans intervention manuelle.
+Ce document présente une architecture opérationnelle de détection et classification du trafic HTTP malveillant, s'inscrivant dans la continuité des approches de génération 3 (fingerprinting multi-protocole et ML comportemental). Le système exploite 96 features organisées en 8 familles couvrant les couches réseau L3 à L7, corrélant des signaux TCP, TLS et HTTP en un vecteur unifié par session. La détection repose sur un ensemble triple-voix combinant un Extended Isolation Forest (EIF), un Normalizing Flow (NF) et un Hoeffding Adaptive Tree (HAT, River), fusionnés par un MLP non-linéaire calibré sur les étiquettes accumulées. L'explicabilité est assurée par l'importance des features par profondeur d'isolation (EIF) et SHAP TreeExplainer (HAT). Le clustering de campagnes est réalisé par HDBSCAN dans l'espace latent du Normalizing Flow, et la détection de flottes coordonnées par GraphSAGE (PyTorch Geometric). Le fingerprinting HTTP/2 passif — extraction des trames SETTINGS, WINDOW_UPDATE et de l'ordre des pseudo-headers côté serveur — exploite un signal déjà utilisé par des solutions industrielles (Akamai, Cloudflare, F5), ici implémenté via eBPF. L'infrastructure repose sur 16 modules Python (4 800 lignes), une base ClickHouse à double schéma (ja4_logs bruts TTL 2 h, ja4_processing agrégés TTL 7 j), des cycles d'analyse de 300 secondes, et traite en production plus de 3 millions de logs, environ 34 000 sessions par cycle, avec approximativement 777 anomalies détectées par cycle (≈ 2,3 % — chiffre opérationnel brut, non validé comme taux de détection). Le système intègre un moteur de profiling dynamique automatique des navigateurs (HDBSCAN sur les vecteurs H2 observés, centroïdes auto-appris, scoring temps réel par distance normalisée) qui s'adapte aux évolutions des piles HTTP/2 sans intervention manuelle.
 
 **Mots-clés** : fingerprinting réseau, JA4+, HTTP/2 fingerprinting, détection de bots, Extended Isolation Forest, autoencodeurs, ensemble hybride, corrélation TCP/TLS/HTTP, WAF, classification de trafic, apprentissage semi-supervisé, clustering HDBSCAN
 

docs/thesis/01_introduction.md

@@ -43,9 +43,9 @@ Ce document décrit une architecture opérationnelle s'inscrivant dans la contin
 1. **Corrélation TCP/TLS/HTTP** en temps réel via ja4ebpf (clé : `src_ip:src_port`, 256 shards, timeout orphelin 500 ms)
 2. **Fingerprinting HTTP/2 passif** : extraction des trames SETTINGS, WINDOW_UPDATE, PRIORITY et de l'ordre des pseudo-headers directement depuis le stream TCP — approche déjà exploitée par des solutions industrielles (Akamai, Cloudflare, F5), ici implémentée via eBPF
 3. **Architecture EIF bifurquée** : modèle complet (≈ 45 features L3→L7) et modèle applicatif (≈ 35 features L7 uniquement), évitant le biais de zérotage sur le trafic non corrélé — choix pragmatique de gestion des données manquantes
-4. **Ensemble triple-voix avec fusion par MLP non-linéaire** : combinaison EIF + NF + XGBoost avec méta-modèle MLP apprenant les interactions non-linéaires entre les trois voix
+4. **Ensemble triple-voix avec fusion par MLP non-linéaire** : combinaison EIF + NF + HAT (River) avec fusion MLP apprenant les interactions non-linéaires entre les trois voix
 5. **HDBSCAN dans l'espace latent AE** : clustering de campagnes par similarité de comportement compressé en 16 dimensions
-6. **Détection de dérive adversariale** : distinction entre dérive organique (mises à jour navigateur) et manipulation directionnelle coordonnée
+6. **Détection de dérive adversariale** : distinction entre dérive organique (mises à jour navigateur) et manipulation adversariale via incertitude épistémique de Deep Ensembles (NFEnsemble M=5)
 7. **8 features comportementales avancées** : application de statistiques standard (déviation de Benford, entropie de transition markovienne, autocorrélation lag-1, délai root-to-first-asset, diversité de hosts, uniformité de couverture cross-host) au domaine de la détection de bots
 8. **Graphes bipartis NetworkX** pour la détection de flottes
 

docs/thesis/02_etat_de_lart.md

@@ -58,7 +58,7 @@ La deuxième couche de défense statique repose sur des dictionnaires de réputa
 [Anubis](https://github.com/TecharoHQ/anubis) est un système de règles communautaire en YAML permettant de définir des actions granulaires par bot identifié. Les quatre actions disponibles sont :
 
 - **ALLOW** : autorisation explicite (bots légitimes : Googlebot, Bingbot, bots de recherche académique)
-- **DENY** : blocage avec retour 403 Forbidden — signal de vérité terrain fort pour l'entraînement XGBoost
+- **DENY** : blocage avec retour 403 Forbidden — signal de vérité terrain fort pour l'entraînement HAT (River)
 - **WEIGH** : ajout d'un score de pondération sans blocage — signal auxiliaire dans le vecteur de features
 - **CHALLENGE** : redirection vers un challenge (PoW ou CAPTCHA)
 
@@ -69,7 +69,7 @@ La deuxième couche de défense statique repose sur des dictionnaires de réputa
 **Priorité de correspondance** : `COALESCE(IP match, ASN match)` — une correspondance CIDR précise sur l'IP prend la priorité sur la correspondance ASN plus générale. Cela reflète le principe que l'information la plus spécifique est la plus fiable.
 
 **Valeur pour le pipeline ML** :
-- Les sessions `DENY` fournissent des étiquettes de bot à haute confiance pour l'entraînement supervisé de XGBoost, sans nécessiter d'annotation manuelle.
+- Les sessions `DENY` fournissent des étiquettes de bot à haute confiance pour l'entraînement incrémental du HAT (River), sans nécessiter d'annotation manuelle.
 - Les sessions `WEIGH` contribuent une feature binaire `anubis_is_flagged` dans la famille F7, enrichissant le vecteur de features sans déclencher de blocage.
 
 ---
@@ -292,7 +292,7 @@ XGBoost ([Chen & Guestrin, 2016](https://arxiv.org/abs/1603.02754)) est un algor
 **Limites des approches supervisées** :
 - **Concept drift** : un modèle entraîné sur des bots de 2024 peut être aveugle aux nouvelles techniques de 2025
 - **Rareté des étiquettes** : annoter manuellement des millions de sessions HTTP est coûteux et sujet à erreur
-- **Bruit des étiquettes** : les labels fournis par les analystes SOC contiennent des erreurs systématiques (faux positifs mal corrigés, biais de confirmation). Ces étiquettes bruitées empoisonnent le modèle supervisé — un problème bien documenté par [Northcutt et al., 2021 (Cleanlab)](https://arxiv.org/abs/1911.00068) qui montre que les jeux de données réels contiennent 8 à 20 % de labels incorrects. Pour mitiger ce risque, notre pipeline intègre un filtre Cleanlab avant l'entraînement XGBoost (détail §3.8).
+- **Bruit des étiquettes** : les labels fournis par les analystes SOC contiennent des erreurs systématiques (faux positifs mal corrigés, biais de confirmation). Ces étiquettes bruitées empoisonnent le modèle supervisé — un problème bien documenté par [Northcutt et al., 2021 (Cleanlab)](https://arxiv.org/abs/1911.00068) qui montre que les jeux de données réels contiennent 8 à 20 % de labels incorrects. Pour mitiger ce risque, notre pipeline intègre un filtre Cleanlab avant l'apprentissage incrémental du HAT (détail §3.8).
 - **Biais de jeu de données** : les modèles entraînés sur des données de laboratoire (CICIDS2017, NSL-KDD) généralisent mal au trafic en production, comme documenté dans la littérature sur les benchmarks de détection d'intrusions
 - **Attaque par évasion adversariale** : un attaquant ayant accès ou connaissance du modèle peut crafting des sessions qui maximisent le score de légitimité
 
@@ -413,20 +413,19 @@ Le système de détection combine trois « voix » complémentaires :
               ┌──────────────┼──────────────┐
               │              │              │
         ┌─────▼─────┐  ┌─────▼─────┐  ┌────▼──────┐
-        │   EIF     │  │    NF     │  │ XGBoost   │
-        │ (semi-    │  │ (Normal-  │  │(supervisé)│
-        │supervisé) │  │ izing     │  │           │
-        │           │  │  Flow)    │  │           │
+        │   EIF     │  │    NF     │  │ HAT       │
+        │ (semi-    │  │ (Normal-  │  │ (River,   │
+        │supervisé) │  │ izing     │  │ supervisé │
+        │           │  │  Flow)    │  │ online)   │
         └─────┬─────┘  └─────┬─────┘  └────┬──────┘
               │              │              │
-        eif_norm       nf_norm          xgb_prob
+        eif_norm       nf_norm          hat_prob
               │              │              │
               └──────────────┼──────────────┘
                              │
                     ┌────────▼────────┐
-                    │  Meta-Model     │
-                    │  Stacking MLP   │
-                    │  (non-linéaire) │
+                    │  Fusion MLP     │
+                    │  non-linéaire   │
                     └────────┬────────┘
                              │
                     ┌────────▼────────┐
@@ -437,7 +436,7 @@ Le système de détection combine trois « voix » complémentaires :
 
 **Limites de la fusion linéaire**
 
-Une fusion linéaire — combinaison convexe pondérée ou régression logistique — ne peut capturer que des frontières de décision linéaires dans l'espace des scores intermédiaires. Or les signaux EIF, NF et XGBoost peuvent exhiber des interactions non-linéaires impossibles à modéliser par une combinaison linéaire :
+Une fusion linéaire — combinaison convexe pondérée ou régression logistique — ne peut capturer que des frontières de décision linéaires dans l'espace des scores intermédiaires. Or les signaux EIF, NF et HAT peuvent exhiber des interactions non-linéaires impossibles à modéliser par une combinaison linéaire :
 
 ```
 Problème XOR des scores :
@@ -450,18 +449,18 @@ Problème XOR des scores :
                     NF bas
 ```
 
-Exemple concret : un bot utilisant un outilHeadless avec un JA4 fingerprint légitime (NF bas) mais un comportement de navigation atypique (EIF élevé). Le XGBoost peut compenser, mais la fusion linéaire ne peut apprendre la relation *« EIF élevé ET XGB élevé MAIS NF bas = bot »* — elle ne fait que sommer les contributions indépendantes.
+Exemple concret : un bot utilisant un outilHeadless avec un JA4 fingerprint légitime (NF bas) mais un comportement de navigation atypique (EIF élevé). Le HAT peut compenser, mais la fusion linéaire ne peut apprendre la relation *« EIF élevé ET HAT élevé MAIS NF bas = bot »* — elle ne fait que sommer les contributions indépendantes.
 
 **Stacking OOF (Out-of-Fold) et MLP méta-modèle**
 
 Pour résoudre cette limitation, le système utilise un méta-modèle non-linéaire de type MLP (*Multi-Layer Perceptron*) entraîné via stacking Out-of-Fold :
 
-1. **Prédictions OOF** : les modèles de base (EIF, NF, XGBoost) produisent des prédictions sur des plis de validation croisée temporelle, garantissant que le méta-modèle n'a jamais vu les données d'entraînement des modèles de base — évitant le surapprentissage (*information leakage*).
+1. **Prédictions OOF** : les modèles de base (EIF, NF, HAT) produisent des prédictions sur des plis de validation croisée temporelle, garantissant que le méta-modèle n'a jamais vu les données d'entraînement des modèles de base — évitant le surapprentissage (*information leakage*).
 
 2. **Méta-modèle MLP** : un réseau de neurones à 2 couches apprend la fonction de fusion optimale :
 
 ```
-MetaFusionMLP : [eif, nf, xgb] → Linear(3,16) → BatchNorm → ReLU → Dropout(0.2)
+MetaFusionMLP : [eif, nf, hat] → Linear(3,16) → BatchNorm → ReLU → Dropout(0.2)
                 → Linear(16,1) → Sigmoid → P(bot)
 ```
 
@@ -470,7 +469,7 @@ MetaFusionMLP : [eif, nf, xgb] → Linear(3,16) → BatchNorm → ReLU → Dropo
 - **Early stopping** (patience = 5 epochs) : arrête l'entraînement dès que la loss de validation ne s'améliore plus, évitant le surapprentissage.
 - **Weight decay** ($\lambda = 10^{-4}$) : pénalité L2 sur les poids du MLP pour une régularisation supplémentaire.
 
-Le MLP apprend des frontières de décision non-linéaires dans l'espace 3D `[eif_norm, nf_norm, xgb_prob]`, capable de résoudre les patterns XOR et les interactions conditionnelles entre les trois voix. Le système de détection peut ainsi combiner automatiquement les signaux de manière optimale en fonction du type de trafic observé en production.
+Le MLP apprend des frontières de décision non-linéaires dans l'espace 3D `[eif_norm, nf_norm, hat_prob]`, capable de résoudre les patterns XOR et les interactions conditionnelles entre les trois voix. Le système de détection peut ainsi combiner automatiquement les signaux de manière optimale en fonction du type de trafic observé en production.
 
 **Calendrier de retraining** :
 - HAT (supervisé) : apprentissage incrémental à chaque cycle (300s) sur les étiquettes accumulées, après filtrage Cleanlab des labels SOC bruyants (voir ci-dessous)
@@ -479,18 +478,22 @@ Le MLP apprend des frontières de décision non-linéaires dans l'espace 3D `[ei
 
 **Filtrage des labels SOC bruyants (Cleanlab)** :
 
-Avant chaque entraînement XGBoost, les labels fournis par les analystes SOC sont filtrés via [Cleanlab](https://cleanlab.ai/) ([Northcutt et al., 2021](https://arxiv.org/abs/1911.00068)). Ce framework de *confident learning* identifie les exemples dont l'étiquette est probablement erronée en comparant les prédictions out-of-fold d'un modèle aux labels observés.
+Avant chaque cycle d'apprentissage incrémental du HAT, les labels fournis par les analystes SOC sont filtrés via [Cleanlab](https://cleanlab.ai/) ([Northcutt et al., 2021](https://arxiv.org/abs/1911.00068)). Ce framework de *confident learning* identifie les exemples dont l'étiquette est probablement erronée en comparant les prédictions out-of-fold d'un modèle aux labels observés.
 
 ```python
-# 1. Obtenir pred_probs via cross-validation (3 folds)
-quick_model = XGBClassifier(n_estimators=80, max_depth=4)
-pred_probs = cross_val_predict(quick_model, X, y, cv=3, method='predict_proba')
+# 1. Obtenir pred_probs via cross-validation (3 folds) sur les labels accumulés
+from river import tree
+quick_model = tree.HoeffdingAdaptiveTreeClassifier()
+# Les labels accumulés ce cycle sont filtrés avant injection dans le HAT
+pred_probs = cross_val_predict(quick_model, X_accumulated, y_accumulated,
+                               cv=3, method='predict_proba')
 
 # 2. Identifier les labels douteux
 issues = find_label_issues(labels=y, pred_probs=pred_probs)
 
-# 3. Exclure les exemples bruités avant l'entraînement final
-X_clean, y_clean = X[~noisy_mask], y[~noisy_mask]
+# 3. N'injecter que les labels propres via learn_one()
+for x_clean, y_clean in clean_samples:
+    hat_model.learn_one(x_clean, y_clean)
 ```
 
 Ce mécanisme protège le modèle contre l'empoisonnement par des faux positifs mal corrigés ou des biais de confirmation des analystes. Le taux de labels filtrés est loggé pour surveillance. En cas d'échec de Cleanlab (erreur mémoire, dépendance manquante), le pipeline revient aux données brutes sans interruption.
@@ -577,7 +580,20 @@ Le passage au stream mining élimine trois problématiques majeures du batch tra
 
 **Validation gate** : conservée — si le taux d'anomalie sur le jeu de validation dépasse 20% après retraining EIF/NF, le nouveau modèle est rejeté et le modèle précédent conservé.
 
-#### 2.4.4 Modélisation des phases d'attaque
+**Quantification d'incertitude par Deep Ensembles**
+
+La détection adversariale par ADWIN reposait sur l'heuristique suivante : si plus de 50% des features driftent simultanément, le drift est qualifié d'adversarial. Cette heuristique est non fondée — un pic de légitime trafic (ex. mise à jour navigateur majeure) peut déclencher un drift massif sur de nombreuses features sans pour autant être adversarial. À l'inverse, une attaque furtive ne touchant que quelques features ne serait jamais détectée.
+
+Cette heuristique est remplacée par une mesure d'incertitude épistémique via **Deep Ensembles** ([Lakshminarayanan et al., 2017](https://arxiv.org/abs/1612.01474)) : le Normalizing Flow unique est remplacé par un ensemble de $M=5$ modèles indépendants, chacun entraîné sur un échantillon bootstrap (avec remise) de la baseline humaine. L'incertitude est mesurée par la variance inter-modèles :
+
+$$\sigma^2(x) = \frac{1}{M} \sum_{m=1}^{M} \left( -\log p_m(x) - \overline{-\log p(x)} \right)^2$$
+
+La logique de détection repose sur l'intuition suivante :
+
+- **Dérive organique** (changement naturel du trafic) : les 5 modèles s'accordent sur la nouveauté → variance faible. Tous les manifolds ont capturé les mêmes structures dans la baseline, donc un nouveau pattern légitime est traité de manière cohérente.
+- **Dérive adversariale** (évasion délibérée) : les 5 modèles ne s'accordent pas → variance qui explose. Un échantillon adversarial tombe dans une région de l'espace où chaque manifold a appris une frontière légèrement différente (diversité induite par le bootstrap), produisant des scores de vraisemblance très dispersés.
+
+Le seuil `NF_UNCERTAINTY_THRESHOLD` (défaut : 1.0) est appliqué sur $\sigma^2(x)$ : tout échantillon au-dessus est tagué `is_adversarial_drift = True`. Cette approche est fondée statistiquement (variance sur un ensemble) et ne dépend pas d'un seuil arbitraire sur le nombre de features en drift.
 
 La modélisation des phases d'attaque (Reconnaissance → Mouvement latéral → Intrusion → Exfiltration) par des modèles d'état-espace ou des processus de Markov cachés constitue une piste de recherche. L'enrichissement du clustering HDBSCAN avec ce signal de phase permettrait de distinguer des campagnes en phase de reconnaissance de campagnes en phase d'exploitation active.
 

docs/thesis/03_architecture.md

@@ -69,8 +69,8 @@
                   │  │ 3b. dynamic H2 profiling scoring │  │
                   │  │ 4. EIF bifurqué (complet/appli)  │  │
                   │  │ 5. NF log-likelihood scoring       │  │
-                  │  │ 6. XGBoost probabilité           │  │
-                  │  │ 7. Meta-Model MLP fusion         │  │
+                  │  │ 6. HAT probabilité (River online)│  │
+                  │  │ 7. Fusion MLP non-linéaire       │  │
                   │  │ 8. HDBSCAN clustering (NF latent) │  │
                   │  │ 9. Écriture résultats ClickHouse  │  │
                   │  └──────────────────────────────────┘  │
@@ -240,7 +240,7 @@ Session entrante
         ├── asn_label == 'human' ?
         │   ── OUI → baseline EIF training (sans étiquette bot)
         │
-        └── Sinon → Triple-voix : EIF + NF + XGBoost + Meta-Model Stacking (MLP non-linéaire)
+        └── Sinon → Triple-voix : EIF + NF + HAT (River) + Fusion MLP non-linéaire
 ```
 
 #### Seuil adaptatif
@@ -258,7 +258,7 @@ La valeur `percentile_5` du historique des scores négatifs (anomalies confirmé
 | EIF Complet | ≈ 45 features L3→L7 | Données L3/L4 disponibles | eif_score_full |
 | EIF Applicatif | ≈ 35 features L7 | L3/L4 absentes (CDN/proxy) | eif_score_app |
 | NF | Même dimensionnalité que EIF actif | Toutes sessions | nf_log_likelihood |
-| XGBoost | Ensemble complet 96 features | Toutes sessions | xgb_probability |
+| HAT (River) | Ensemble complet 96 features | Toutes sessions | hat_probability |
 
 #### Niveaux de sévérité
 

docs/thesis/07_discussion_limites.md

@@ -21,6 +21,7 @@ La détection de bots s'inscrit dans une dynamique de course aux armements où c
 | asset_ratio | Playwright/Puppeteer chargeant toutes ressources | Détectable via resource dependency tree (§5.4) |
 | IP reputation | Proxies résidentiels (Bright Data, Oxylabs) | Contournement partiel mais coût élevé par requête |
 | Comportement navigation | Scripts imitant les patterns de clic humain | Détectable via cadence fingerprint et entropy de séquence |
+| Deep Ensembles (NF M=5) | Perturbation continue des features | L'évasion par perturbation continue est difficile car l'attaquant doit tromper 5 manifolds différents simultanément |
 
 #### Architecture multi-couches comme contre-mesure structurelle
 
@@ -71,7 +72,7 @@ Cependant, des proxies résidentiels persistants apparaissant dans **chaque cycl
 | 2 | Signaux orthogonaux (§5.2, §5.3) résistants à contamination | Détecte bots résistants à l'EIF par des axes indépendants |
 | 3 | Validation : `anomaly_rate > 20%` → rejet du modèle | Détecte les cycles d'entraînement pathologiques |
 | 4 | Feedback SOC : FP → reclassification "human" ; TP → exclusion baseline | Correction manuelle des erreurs systématiques |
-| 5 | Triple ensemble : XGBoost corrige les erreurs systématiques EIF | Supervisé corrige les biais de l'non-supervisé |
+| 5 | Triple ensemble : HAT (River) corrige les erreurs systématiques EIF | Supervisé online corrige les biais de l'non-supervisé |
 
 #### Impact du feedback SOC
 
@@ -109,14 +110,14 @@ Le fingerprinting réseau opère sans déchiffrement TLS (les métadonnées TLS
 | Composant | Temps d'exécution | Conditions |
 |-----------|------------------|------------|
 | EIF training | < 2 secondes | ~34 000 sessions, 96 features |
-| AE inference | ~50 ms | Batch de 34 000 sessions |
-| XGBoost inference | ~30 ms | Batch de 34 000 sessions |
+| NF (Normalizing Flow) inference | ~50 ms | Batch de 34 000 sessions |
+| HAT (River) inference | ~30 ms | Batch de 34 000 sessions |
 | HDBSCAN (anomalies) | ~100 ms | ~34 000 sessions, espace latent AE |
 | HDBSCAN (profiling) | ~2–5 s | Quotidien, ~200k sessions H2 dédupliquées, min_cluster=1000 |
 | Dynamic matcher scoring | < 1 ms | Par session, lookup en mémoire contre ~5–10 profils |
 | GraphSAGE (fleet.py) | ~80 ms | Graphe d'IPs, 2 couches SAGEConv, GPU/CPU |
 | Fusion MLP | < 10 ms | MLP 2 couches, négligeable |
-| **Cycle complet** | **~300 secondes** | EIF + AE + XGBoost + HDBSCAN + GraphSAGE |
+| **Cycle complet** | **~300 secondes** | EIF + NF + HAT + HDBSCAN + GraphSAGE |
 
 La durée du cycle (300 s = 5 minutes) est contrainte principalement par la **fenêtre d'agrégation ClickHouse** (1 heure glissante avec recalcul toutes les 5 minutes), non par les temps d'exécution ML.
 
@@ -133,7 +134,7 @@ La durée du cycle (300 s = 5 minutes) est contrainte principalement par la **fe
 - À 34 000 sessions/cycle : ~100 ms — acceptable
 - À 500 000 sessions/cycle (scaling ×15) : ~2 s — encore tolérable
 
-**Fusion MLP** : O(n × d) inférence avec d = 3 features d'entrée (scores EIF, NF, XGBoost), MLP 2 couches (16 neurones). Temps négligeable quelle que soit la taille.
+**Fusion MLP** : O(n × d) inférence avec d = 3 features d'entrée (scores EIF, NF, HAT), MLP 2 couches (16 neurones). Temps négligeable quelle que soit la taille.
 
 **Limite architecturale principale** : le modèle supervisé (Hoeffding Adaptive Tree) s'améliore incrémentalement à chaque cycle via `learn_one()`, mais nécessite un flux continu de labels fiables. À faible volume de labels (< 500 sessions étiquetées), le HAT converge lentement. Ce problème est partiellement atténué par le filtrage Cleanlab qui élimine les labels douteux (détail §3.8), mais la qualité du feedback SOC reste le goulot d'étranglement principal.
 
@@ -176,7 +177,7 @@ Ce document présente un système opérationnel déployé en production, mais so
 
 **Le chiffre de "777 anomalies par cycle (≈ 2,3 %)"** est un compteur opérationnel brut : il mesure le nombre de sessions dépassant le seuil d'anomalie configuré, mais ne distingue pas les vrais positifs des faux positifs. En l'absence de ground truth systématique, ce chiffre ne constitue pas un indicateur de performance de détection.
 
-**Conséquence** : les choix architecturaux (EIF bifurqué, ensemble triple-voix, poids de la fusion LR) sont motivés par des arguments qualitatifs et l'expérience opérationnelle, mais ne sont pas validés par une évaluation quantitative contrôlée. La priorité immédiate pour les travaux futurs est l'établissement d'un protocole d'évaluation sur un dataset labellisé, avec comparaison contre des baselines (Isolation Forest seul, XGBoost seul, LOF, One-Class SVM).
+**Conséquence** : les choix architecturaux (EIF bifurqué, ensemble triple-voix, poids de la fusion MLP) sont motivés par des arguments qualitatifs et l'expérience opérationnelle, mais ne sont pas validés par une évaluation quantitative contrôlée. La priorité immédiate pour les travaux futurs est l'établissement d'un protocole d'évaluation sur un dataset labellisé, avec comparaison contre des baselines (Isolation Forest seul, HAT seul, LOF, One-Class SVM).
 
 ### 6.7 Travaux futurs et roadmap
 

docs/thesis/08_conclusion_references.md

@@ -19,13 +19,13 @@ Un système de détection à couverture complète couvrant cinq couches réseau
 
 Un pipeline ML combinant :
 - **Isolation Forest Étendu (EIF)** ([Hariri et al., 2021](https://ieeexplore.ieee.org/document/8888179)) : modèle non-supervisé fondé sur l'isolation aléatoire d'instances anormales dans des espaces de features basse-dimension
-- **Autoencodeur variationnel (AE)** ([Mirsky et al., NDSS 2018](https://www.ndss-symposium.org/ndss-paper/kitsune-an-ensemble-of-autoencoders-for-online-network-intrusion-detection/)) : détection d'anomalies par reconstruction, capturant les corrélations entre features
-- **XGBoost supervisé** : correction des erreurs systématiques des modèles non-supervisés via labels SOC accumulés
-- **Fusion par MLP méta-modèle** : fusion non-linéaire des trois scores en un score final calibré
+- **Normalizing Flow (RealNVP)** : détection d'anomalies par vraisemblance, capturant les corrélations jointes entre features via Deep Ensemble (M=5)
+- **HAT supervisé (Hoeffding Adaptive Tree, River)** : correction des erreurs systématiques des modèles non-supervisés via labels SOC accumulés, apprentissage incrémental par `learn_one()`
+- **Fusion MLP non-linéaire** : fusion non-linéaire des trois scores en un score final calibré
 
-Le pipeline intègre un mécanisme de **détection de dérive conceptuelle** (basé sur le percentile 5 des scores négatifs) distinguant la dérive organique (évolution naturelle du trafic) de la dérive adversariale (manipulation intentionnelle de la distribution).
+Le pipeline intègre un mécanisme de **détection de dérive conceptuelle** via ADWIN (Adaptive Windowing) distinguant la dérive organique (évolution naturelle du trafic) de la dérive adversariale (variance épistémique élevée du NFEnsemble).
 
-L'**explainabilité** est assurée par l'importance des features par profondeur d'isolation (approche de type ExIFFI) pour l'EIF et SHAP ([Lundberg & Lee, 2017](https://shap.readthedocs.io/)) pour XGBoost, permettant l'audit des décisions de blocage par l'équipe SOC.
+L'**explainabilité** est assurée par l'importance des features par profondeur d'isolation (approche de type ExIFFI) pour l'EIF et SHAP ([Lundberg & Lee, 2017](https://shap.readthedocs.io/)) pour le HAT, permettant l'audit des décisions de blocage par l'équipe SOC.
 
 #### Composant 3 : Fingerprinting HTTP/2 passif structuré (browser_matcher)
 
@@ -76,7 +76,7 @@ Architecture de données fondée sur ClickHouse avec **AggregatingMergeTree view
 
 ### Perspective
 
-Le système atteint ses objectifs opérationnels actuels. La capture HTTP/2 passive est intégrée avec 12 colonnes individuelles dans `ja4_logs.http_logs`, et le module `browser_matcher` est opérationnel avec ses 7 dimensions de scoring statique. Le moteur de profiling dynamique automatique (§3.9.6) complète le système statique en apprenant les signatures H2 à partir du trafic réel, éliminant la dépendance aux signatures codées en dur. Les axes d'amélioration prioritaires sont le monitoring de la convergence des clusters dynamiques, l'extension DNS Shadow Analysis pour la couverture DNS (`[todo]` → `[partiel]`), et le passage à l'apprentissage en ligne pour XGBoost. À plus long terme, le support HTTP/3 (QUIC) deviendra nécessaire à mesure que la proportion de trafic HTTP/3 augmente dans la baseline.
+Le système atteint ses objectifs opérationnels actuels. La capture HTTP/2 passive est intégrée avec 12 colonnes individuelles dans `ja4_logs.http_logs`, et le module `browser_matcher` est opérationnel avec ses 7 dimensions de scoring statique. Le moteur de profiling dynamique automatique (§3.9.6) complète le système statique en apprenant les signatures H2 à partir du trafic réel, éliminant la dépendance aux signatures codées en dur. Les axes d'amélioration prioritaires sont le monitoring de la convergence des clusters dynamiques et l'extension DNS Shadow Analysis pour la couverture DNS (`[todo]` → `[partiel]`). Le passage à l'apprentissage en ligne via HAT (River) est effectif depuis la section 6.7. À plus long terme, le support HTTP/3 (QUIC) deviendra nécessaire à mesure que la proportion de trafic HTTP/3 augmente dans la baseline.
 
 La modélisation des phases d'attaque séquentielles par des modèles d'état-espace constitue une piste de recherche prometteuse, qui permettrait de modéliser explicitement les phases d'attaque séquentielles — comblant la lacune actuelle entre la détection de sessions individuelles et la détection de campagnes d'attaque coordonnées multi-phases.
 
@@ -236,8 +236,8 @@ arXiv preprint arXiv:1210.0921.
 [35] **HDBSCAN Python library** — Implémentation performante de l'algorithme HDBSCAN.
 [https://hdbscan.readthedocs.io/en/latest/](https://hdbscan.readthedocs.io/en/latest/)
 
-[36] **XGBoost** — Bibliothèque de gradient boosting optimisée.
-[https://xgboost.readthedocs.io/en/stable/](https://xgboost.readthedocs.io/en/stable/)
+[36] **River** — Bibliothèque d'apprentissage incrémental et stream mining.
+[https://riverml.xyz/](https://riverml.xyz/)
 
 ---