Cas d'usage

Douze scénarios. Une seule appliance.

Chaque cas d'usage relie un problème concret d'acheteur à un workflow Zero Hunt. Trois par pilier : scénario, problème, solution, résultat, délai d'obtention de valeur. Chacun a sa propre ancre — envoyez à un collègue le lien direct vers celui qui correspond à sa situation.

Pilier 1 — Pentest génératif

Validation offensive continue. Code d'exploit généré par l'IA pour chaque cible.

Remplacer le pentest annuel par une validation continue

⌛ ROI en 30 jours face au coût annuel du prestataire

Scénario: Vous payez 50 à 150 k€ par an à un prestataire de pentest et le rapport est obsolète quelques semaines après sa livraison.
Problème: Le test d'intrusion manuel est une photographie. Quand le PDF arrive, la surface d'attaque a déjà changé : nouvelles IP sur le périmètre, nouveaux services, nouveaux identifiants. La prochaine échéance face au régulateur est dans six à douze mois, et vos preuves sont déjà dépassées.
Comment Zero Hunt le résout: Planifiez des campagnes continues sur l'appliance — quotidiennes, hebdomadaires ou déclenchées par un changement (nouvelle IP, nouveau service, nouvel identifiant). L'essaim de 10 agents travaille en autonomie ; chaque constat est signé et horodaté. Les pentesters seniors continuent de piloter les campagnes threat-led via l'Interactive Red Team Chat pour les arbitrages que les humains font mieux.
Résultat: Remplace l'équivalent de 1 à 2 ETP (FTE) d'heures de prestataire de pentest par mois. Les preuves sont à jour à chaque échéance face au régulateur, pas seulement au moment de l'audit. Le délai de validation d'un nouvel actif passe de « à la prochaine mission » à « dans l'heure ».

Pour aller plus loin:Finance · DORA art. 25 →Énergie et services publics · NIS2 →NIS2/DORA et la fin du pentest annuel →

Valider l'exposition à une CVE critique dans les heures qui suivent sa divulgation

⌛ Des heures, pas des trimestres, par CVE critique

Scénario: Une CVE critique tombe à 22 h 00 (ajout au CISA KEV, avis de l'éditeur, signalement d'exploitation massive). Votre stack tourne sur la version concernée. Et maintenant ?
Problème: La réponse habituelle est « attendre le prochain pentest planifié », qui peut être à plusieurs trimestres. Appliquer le correctif indique seulement que la version a changé, pas si le chemin d'attaque était réellement exploitable dans votre environnement. Sans preuve, la question du conseil d'administration « sommes-nous vulnérables ? » n'a pas de réponse défendable.
Comment Zero Hunt le résout: L'appliance ingère en continu le CISA KEV, la NVD et les avis des éditeurs (21 sources de renseignement). Lorsqu'une CVE pertinente tombe, l'essaim de 10 agents génère un exploit propre à votre environnement, l'exécute en sandbox contre votre inventaire et produit un artefact signé de preuve d'exploitation (ou de non-exploitabilité). Souvent avant le point du matin.
Résultat: Le délai entre la divulgation de la CVE et un verdict d'exposition défendable passe de plusieurs trimestres à quelques heures. La question du conseil reçoit un oui ou un non, preuves à l'appui, et non une probabilité.

Pour aller plus loin:Énergie et services publics · NIS2 →Santé →Cas CVE-2026-20182 + 31431 →

Mener des campagnes TLPT threat-led alignées sur TIBER-EU pour l'art. 26 de DORA

⌛ Cycle TLPT dans le même trimestre au lieu du minimum de 3 ans

Scénario: Vous êtes une entité DORA significative (banque, assureur, établissement de paiement) tenue de mener des tests d'intrusion threat-led selon une méthodologie documentée, avec des preuves signées depuis l'entrée de threat intelligence jusqu'à la clôture.
Problème: Les missions TLPT confiées à des prestataires externes coûtent chacune 150 à 400 k€, le périmètre est figé au moment de l'achat et la piste d'audit méthodologique est assemblée à la main. Une deuxième mission la même année est rare, même lorsque le paysage des menaces change sensiblement.
Comment Zero Hunt le résout: L'appliance mène des campagnes TLPT compatibles TIBER-EU, alimentées par 21 flux de threat intelligence en temps réel. Les phases de la méthodologie (fourniture de la threat intelligence → test red team → purple team → clôture) sont suivies nativement ; chaque artefact est signé et chaîné par hachage dans l'ordre, ce qui produit une chaîne vérifiable remontant jusqu'à l'entrée de threat intelligence. L'exigence de preuve des RTS 2025 devient une requête, et non un projet.
Résultat: Des preuves de niveau TLPT à la demande, et non une fois tous les 3 ans. Le coût par campagne se réduit au temps de calcul. L'échange d'audit avec l'EBA ou la Banca d'Italia passe de « où est la documentation ? » à « quelle période ? ».

Pour aller plus loin:Finance · DORA art. 26 →vs Pentera (TLPT) →DORA + NIS2 en profondeur →

Pilier 2 — AI Traffic Analysis

Détection à la vitesse du réseau de l'activité que les outils endpoint ne voient pas.

Détecter le ransomware pendant le chiffrement, pas après

⌛ Détection en secondes au lieu d'heures ou de jours

Scénario: Vous exploitez un hôpital, un site industriel ou tout environnement 24/7 où le délai médian jusqu'à l'impact au T1 2026 est inférieur à 48 heures et où la phase de chiffrement, une fois lancée, se termine en 90 minutes.
Problème: Les signaux endpoint se déclenchent pendant la phase de chiffrement, mais il est alors trop tard : les fichiers sont verrouillés, les sauvegardes font la course avec la demande de rançon et les 6 heures suivantes sont consacrées à la communication de crise. La cadence par lots du SIEM (fenêtres de 15 minutes sur des requêtes de 24 h) manque entièrement la rafale.
Comment Zero Hunt le résout: Le pilier 2 est un modèle de deep learning à 4 têtes qui tourne sur le GPU de l'appliance à un débit de base de 2,7+ Gbit/s. Il détecte la signature comportementale d'un chiffrement en cours — démultiplication rapide des écritures SMB/NFS, schémas latéraux prévisibles, trafic d'élévation de privilèges qui précède — pendant que l'activité a lieu. Le résultat parvient à votre SOAR en quelques secondes ; la connexion au partage de fichiers peut être coupée avant la fin du chiffrement.
Résultat: La latence moyenne de détection, spécifiquement pour la phase de chiffrement, passe de plusieurs heures ou jours à quelques secondes ou minutes. La fenêtre de récupération s'ouvre avant la fin du chiffrement.

Pour aller plus loin:Santé · cible n° 1 du ransomware →vs Cymulate (simulation vs détection) →Ransomware sans chiffrement 2026 →

Détecter l'exfiltration massive de données pendant qu'elle a lieu

⌛ Détection pendant la rafale, pas le lendemain matin

Scénario: Vous faites face à la tendance 2026 : les affiliés ransomware sautent complètement le chiffrement, passent directement à l'exfiltration massive et silencieuse, puis font chanter leurs victimes sous la menace d'une publication. L'endpoint voit des lectures légitimes. Le SOC ne voit rien.
Problème: Le DLP fondé sur les volumes manque l'exfiltration par étapes (l'attaquant regroupe les données à l'intérieur du périmètre, puis les fait sortir sur plusieurs heures via des plages CDN légitimes). L'inspection TLS a reculé face au préchargement HSTS + ESNI + QUIC. Votre seul signal durable est le trafic sortant du réseau — et c'est précisément là que la plupart des défenseurs sont le plus faibles.
Comment Zero Hunt le résout: Le modèle ML d'inspection approfondie des paquets classe les métadonnées de flux (timing, fan-in/out, distribution des octets, ASN de destination, empreintes JA3/JA4) au passage des paquets. Un hôte qui passe d'importateur net à exportateur net, une rafale sortante soutenue vers un ASN jamais vu, un tunnel SD-WAN transportant 10× son volume habituel — tout s'allume pendant la rafale, à temps pour couper le lien.
Résultat: La découverte a lieu pendant la fenêtre d'exfiltration, et non le lendemain matin quand les données sont parties. Les délais réglementaires (art. 33 du RGPD, article 23 de NIS2) courent à partir de la prise de connaissance, et une prise de connaissance pendant l'exfiltration, et non après, est une date que vous pouvez défendre.

Pour aller plus loin:Santé · art. 33 du RGPD →Finance · DORA art. 17-22 →Ransomware par exfiltration seule en profondeur →

Démasquer les C2 cachés via TLS, tunnels DNS et domain fronting

⌛ Détection en minutes sur les nouveaux protocoles C2

Scénario: Votre EDR repose sur des signatures. Votre NDR repose sur des règles. Tous deux manquent le trafic de commande et contrôle qui imite un comportement légitime — beacons HTTPS, tunnels DNS-over-HTTPS, trafic dissimulé derrière votre propre fournisseur CDN.
Problème: Les affiliés augmentés par l'IA réécrivent leurs protocoles C2 à chaque campagne. Les signatures statiques expirent au premier contact. La détection par règles exige un schéma connu. Le vrai signal — périodicité des beacons, jitter, fan-out, anomalies d'empreintes de certificats — n'est vu par aucune des deux couches.
Comment Zero Hunt le résout: L'une des 4 têtes d'inférence est dédiée à l'identification du type d'attaque, entraînée sur des milliards de séquences PCAP étiquetées, y compris des schémas de trafic C2 dissimulé. Le modèle classe à partir des seules métadonnées de flux — il fonctionne sans problème sur des charges chiffrées, sans inspection TLS. Le scoring des empreintes JA3/JA4 détecte les cas « qui ont l'air légitimes mais ne le sont pas ».
Résultat: Les canaux C2 apparaissent dans les minutes qui suivent leur activation, quels que soient la famille de protocoles ou la stratégie de fronting. L'équipe de threat hunting reçoit une liste courte à haute confiance au lieu d'un million d'alertes.

Pour aller plus loin:Chaîne d'approvisionnement de la défense →vs Cymulate →

Pilier 3 — Conformité automatique

Des preuves continues, signées et prêtes pour le régulateur, par conception.

Produire les preuves d'incident de l'article 23 de NIS2 comme sous-produit des opérations

⌛ De plusieurs jours par incident à une seule requête

Scénario: Vous êtes une entité essentielle ou importante au sens de NIS2 (en Italie, decreto legislativo 138/2024). Chaque incident important déclenche une alerte précoce sous 24 heures, une notification sous 72 heures et un rapport final dans le mois, à compter du moment où vous en avez connaissance.
Problème: Assembler à la main les preuves de l'article 23 représente plusieurs jours de travail par incident : reconstitution de la chronologie, mapping des contrôles, export signé, conversion au format du régulateur. L'autorité compétente — l'ACN en Italie — attend des preuves continues de mesures efficaces, et non des photographies annuelles.
Comment Zero Hunt le résout: Chaque action — scan, vulnérabilité, événement réseau, remédiation — est signée au moment de l'écriture et mappée automatiquement sur les contrôles des articles 21 et 23 de NIS2. Le Trust Center exporte en un clic un dossier prêt pour le régulateur. La chronologie 24 h / 72 h / 1 mois devient une requête sur des enregistrements signés, et non un exercice d'urgence.
Résultat: Le respect des délais de notification devient un workflow interrogeable. L'échange avec l'auditeur passe de « montrez-moi la documentation » à « sélectionnez une période ». Les organes de direction, personnellement responsables au titre de l'article 20 de NIS2, disposent d'un enregistrement signé de ce qui était connu, de ce qui a été fait et à quel moment.

Pour aller plus loin:Énergie et services publics · NIS2 entités essentielles →Administration publique italienne · decreto 138 →NIS2 + DORA en profondeur →

Mapper les vulnérabilités sur 34 référentiels en une seule passe

⌛ ~70 % de travail en double en moins entre référentiels

Scénario: Vous êtes soumis à des régimes d'audit simultanés — NIS2 + DORA + RGPD + ISO 27001 + PCI-DSS + SOC 2 — qui partagent des contrôles sous-jacents mais exigent chacun leur propre format de preuve.
Problème: Les équipes GRC tiennent des chaînes de preuves parallèles, une par référentiel. La même vulnérabilité est remappée à la main 3-6 fois. La déduplication entre référentiels reste théorique ; en pratique, le travail est multiplié par le nombre de régimes concernés.
Comment Zero Hunt le résout: Le moteur de conformité mappe automatiquement chaque vulnérabilité sur 34 référentiels, avec une déduplication des contrôles entre référentiels intégrée. Un scoring pondéré par la sévérité, propre à chaque référentiel, reflète le modèle de matérialité de chaque régulateur. Les rapports sont générés par référentiel à partir du magasin partagé d'enregistrements signés.
Résultat: Le travail d'audit redondant diminue jusqu'à 70 %. Une seule vulnérabilité satisfait plusieurs référentiels sans remapping manuel. Les entités soumises à plusieurs régimes passent de « construire les preuves pour chaque audit » à « publier une tranche du magasin d'enregistrements pour chaque audit ».

Pour aller plus loin:Finance · multi-réglementation →Administration publique italienne · NIS2 + AgID →

Export de dossiers pour l'auditeur — signés, vérifiables, reproductibles

⌛ Export en un clic au lieu de plusieurs jours d'assemblage

Scénario: Le cycle d'audit commence. L'auditeur demande « toutes les preuves liées au contrôle X.Y.Z pour la période du T1 ». Vous avez 5 jours pour les rassembler à partir des journaux du SIEM, du SOAR, de l'EDR, de l'outil GRC et du ticketing.
Problème: L'assemblage manuel des preuves est la plus grande source de perte de temps en GRC. L'authenticité est remise en question (la capture d'écran a-t-elle été manipulée ?). La chaîne de conservation est un récit, pas une preuve. Le rapprochement entre outils introduit des erreurs que les auditeurs examinent ensuite à la loupe.
Comment Zero Hunt le résout: Le Trust Center exporte un dossier autonome, signé ECDSA, délimité par contrôles + période + référentiel. Le dossier comprend les vulnérabilités, les fichiers de preuve, les événements réseau et les journaux de remédiation — chaque artefact porte sa signature d'origine, apposée au moment de l'écriture. L'auditeur peut vérifier cryptographiquement sans avoir à faire confiance à notre infrastructure.
Résultat: La préparation de l'audit passe de plusieurs jours à une seule action d'export. Les questions de l'auditeur sur l'authenticité et la chaîne de conservation trouvent leur réponse dans une vérification cryptographique plutôt que dans un récit.

Pour aller plus loin:Défense · CMMC/TRANSEC →Administration publique italienne · AgID/ACN →

Pilier 4 — AI Remediation Advisor

De la vulnérabilité prouvée au correctif vérifié, classés par risque réel.

Corriger ce qui a été prouvé exploitable, dans l'ordre qui compte

⌛ Un plan de correction priorisé dès la fin de la campagne

Scénario: Votre dernière évaluation a produit des centaines de vulnérabilités, et votre équipe peut en fermer quelques dizaines ce mois-ci.
Problème: Une liste triée par CVSS place des vulnérabilités critiques théoriques au-dessus de la faille qu'un attaquant a réellement utilisée, et les faux positifs possibles consomment autant d'heures que les vrais. Trois hôtes exécutant la même bibliothèque obsolète apparaissent comme trois tickets, et personne ne peut dire quels correctifs réduisent le plus le risque.
Comment Zero Hunt le résout: L'AI Remediation Advisor ne travaille que sur les vulnérabilités que la campagne a prouvées : vérifiées ou exploitées. Il les classe par exploitabilité réelle — CISA KEV d'abord, puis ce qui a été exploité dans cette campagne, puis CVSS, EPSS et sévérité —, les regroupe par CVE en actions de remédiation et organise celles-ci en vagues P1–P4, les correctifs rapides à fort impact en premier.
Résultat: La première vague ferme les chemins qu'un attaquant pourrait utiliser aujourd'hui, pas ceux qui ont simplement un score élevé. Aucun effort n'est consacré à des vulnérabilités non confirmées, et chaque action couvre tous les hôtes concernés.

Pour aller plus loin:Playbook : fenêtre de correctif d'urgence KEV →Entreprise · équipes de sécurité réduites →

Vérifier chaque correctif avec la preuve même qui a révélé la faille

⌛ Correctif vérifié le jour de son déploiement

Scénario: Une vulnérabilité critique a été corrigée, et l'auditeur — ou votre conseil d'administration — vous demande comment vous savez que la brèche est fermée.
Problème: Les avis génériques disent « mettez à jour », pas quel endpoint, quel paramètre ou quel payload le correctif doit bloquer. Le retest attend la prochaine mission, si bien que « corrigé » est un statut de ticket plutôt qu'un fait démontré.
Comment Zero Hunt le résout: Lorsque l'Exploit Forge a produit une preuve de concept pour l'hôte, l'advisor la lit avant de proposer le correctif, de sorte que celui-ci cible le chemin réel : l'endpoint, le paramètre, le payload — et le fichier et la ligne lorsque les agents avaient accès au code source (boîte grise). Chaque correctif se termine par une étape de vérification ; relancer la même preuve, ou la campagne contre cet hôte, montre si l'exploit fonctionne encore.
Résultat: La fermeture est démontrée le jour où le correctif est déployé, et non au prochain test annuel, et la campagne relancée en laisse une preuve signée pour le dossier d'audit.

Pour aller plus loin:Boîte noire vs boîte grise →Finance · preuves de remédiation DORA →

Donner à une petite équipe le plan de correction d'un ingénieur senior

⌛ De la vulnérabilité à un script de correction vérifiable en une seule conversation

Scénario: Vous gérez la sécurité à deux ou trois personnes sur Linux, Windows, les conteneurs et une couche web, avec des fenêtres de changement que vous ne maîtrisez pas.
Problème: « Mettre à jour vers la version X » ne dit pas comment déployer en toute sécurité, quoi faire en attendant la fenêtre de maintenance, ni comment revenir en arrière si le service tombe. Rédiger ce plan pour chaque vulnérabilité est un travail de senior pour lequel l'équipe n'a pas le temps.
Comment Zero Hunt le résout: Pour chaque élément, l'advisor fournit la cause racine, le correctif exact, des commandes prêtes à copier-coller pour votre plateforme, une note de déploiement sûr avec l'étape de retour arrière, et une mesure compensatoire à appliquer dès maintenant si le vrai correctif doit attendre. Sur demande, il rédige un script de correction idempotent — bash, PowerShell, Ansible, Dockerfile ou configuration de serveur web — qui sauvegarde chaque fichier modifié et se termine par un contrôle PASS/FAIL. Vos ingénieurs le relisent et l'exécutent : l'advisor ne dispose que d'outils en lecture seule et n'exécute jamais rien.
Résultat: Chaque changement est livré avec un chemin de retour arrière, et chaque correctif est mappé sur le contrôle qu'il satisfait — ISO 27001 Annex A, NIS2, DORA, art. 32 du RGPD, PCI DSS, CIS — pour le dossier d'audit.

Pour aller plus loin:Entreprise · équipes de sécurité de 1-2 FTE →Énergie et services publics · fenêtres de changement →

Voyez-le dans votre environnement

Choisissez le cas d'usage le plus proche de votre problème actuel : nous préparons une démo technique de 30 minutes sur une portion enregistrée de votre stack.

Demander une démo Parcourir les secteurs

Pas encore prêt pour une démo ?