La détection des menaces en temps réel expliquée : qu'entend-on par « temps réel » et pourquoi la latence est désormais déterminante en cas de violation de sécurité ?

La détection des menaces en temps réel est un aspect de la détection des menaces où la rapidité est primordiale — voir le pilier correspondant pour en comprendre le concept fondamental. Cette page se concentre sur une question à laquelle aucun concurrent n’apporte de réponse claire : à quelle vitesse correspond réellement le « temps réel » ? La détection des menaces en temps réel consiste à identifier les menaces au fur et à mesure qu’elles apparaissent dans un flux de données continu, afin que les défenseurs puissent agir en quelques secondes plutôt qu’en plusieurs jours. Elle se déclenche dès que les événements se produisent — et non pas par lots périodiques, ni a posteriori. Tout au long de ce guide, nous utilisons indifféremment les deux expressions : « détection des menaces en temps réel » et « détection des menaces en temps réel ». La réponse à la question « à quelle vitesse ? » s’avère être un spectre, et la position que vous occupez sur ce spectre détermine de plus en plus si une intrusion se transforme en violation de sécurité. À mesure que la vitesse des attaquants se rapproche de la limite « quasi-temps réel » de la surveillance continue, la latence cesse d’être un simple atout pour devenir un facteur de différenciation.

Qu'est-ce que la détection des menaces en temps réel ?

La détection des menaces en temps réel est un aspect de la détection des menaces où la vitesse est un facteur déterminant. Pour comprendre les principes fondamentaux du fonctionnement de la détection, qu’il s’agisse des signatures, du comportement ou de l’analyse, commencez par consulter la section « Piliers ». Cette page traite uniquement de la dimension de la latence : la rapidité avec laquelle la détection se déclenche, et pourquoi cette rapidité est importante.

La détection des menaces en temps réel consiste à identifier en continu les menaces dès leur apparition dans un flux de données en direct, ce qui permet aux responsables de la sécurité d'agir en quelques secondes plutôt qu'en plusieurs jours. Elle évalue les événements dès leur survenue — une connexion, le lancement d'un processus, un flux réseau — au lieu d'attendre qu'une tâche planifiée analyse les journaux accumulés. C'est cette différence qui fait toute la différence.

Concrètement, le terme « en temps réel » désigne une détection qui s'active sur un flux continu au fur et à mesure que les événements se produisent, plutôt que sur un lot périodique ou a posteriori. Une tâche par lots exécutée toutes les 15 minutes ne peut détecter une menace qu'avec 15 minutes de retard. Un processeur de flux évaluant chaque événement dès sa réception peut, quant à lui, mettre en évidence la même menace en quelques secondes. L'architecture que vous choisissez fixe une limite inférieure à la vitesse que vous pouvez atteindre — un point sur lequel nous reviendrons dans la section consacrée à la comparaison entre le traitement en flux et le traitement par lots.

Cette évaluation continue repose sur une base de surveillance continue. La référence faisant autorité en la matière est la norme NIST SP 800-137, qui définit la surveillance continue de la sécurité de l’information comme le processus permanent, « en temps réel ou quasi-temps réel », consistant à observer, détecter et réagir. C’est précisément la détection en temps réel que cette base permet : un examen minutieux, instant par instant, qui transforme un flux de données télémétriques en un signal opportun.

La question centrale à laquelle répond ce guide est d’une simplicité trompeuse : à quelle vitesse correspond le « temps réel » ? Les fournisseurs utilisent cette expression de manière assez vague. Certains entendent par là un blocage en ligne en moins d’une seconde. D’autres font référence à des analyses qui accusent un retard d’une minute ou deux par rapport au temps réel. D’autres encore l’appliquent à des tableaux de bord qui s’actualisent toutes les quelques minutes. Il s’agit là de vitesses réellement différentes, adaptées à des menaces réellement différentes, et les confondre conduit à des attentes inadaptées et à une architecture inadaptée.

Avant de choisir vos outils, définissez donc ce que le terme « temps réel » doit signifier pour chaque décision. Un contrôle préventif à débit maximal et une requête rétrospective de recherche de menaces ont tous deux leur place, mais ils se situent aux extrémités opposées d’un spectre de latence. La section suivante quantifie ce spectre à l’aide de seuils de temps concrets — il s’agit de la colonne vertébrale de l’ensemble de ce guide et du cadre sur lequel s’appuie le reste de cette page. Gardez une idée à l’esprit tout au long de votre lecture : c’est la latence, et non pas seulement la couverture, qui est au cœur même de la détection en temps réel.

À quelle vitesse parle-t-on de « temps réel » ? Le spectre de la latence

Le « temps réel » ne correspond pas à une vitesse unique : il s’agit d’un spectre qui va de la détection en ligne en moins d’une seconde à la réanalyse rétrospective, en passant par l’analyse en temps quasi réel avec un léger délai. Chaque niveau correspond à une catégorie de menace différente, et il est plus important d’adapter le niveau à la menace que de chercher à tout prix à obtenir le chiffre le plus bas possible dans tous les cas.

Le cadre de référence fait autorité et émane de l'organisme de normalisation, et non d'un fournisseur quelconque. La norme NIST SP 800-137 décrit la surveillance continue comme un processus « en temps réel ou quasi-temps réel » — associant explicitement ces deux notions comme des éléments voisins sur un même continuum, plutôt que de considérer le « temps réel » comme une notion absolue unique. Cette formulation sert de point d'ancrage au spectre présenté ci-dessous.

À l’extrémité « rapide » se trouve la détection en temps réel proprement dite : un traitement en ligne qui se déclenche en moins d’une seconde ou en quelques secondes après un événement. À l’extrémité « lente » se trouve la détection rétrospective — la réanalyse des données historiques à l’aide de renseignements actualisés sur les menaces afin de repérer ce que la détection en temps réel a manqué. Entre les deux se situe le « quasi-temps réel », où les analyses s’exécutent avec un léger délai, de l’ordre de 1 à 2 minutes. Ce chiffre relatif au « quasi-temps réel » est donné à titre indicatif et ne fait référence à aucun produit en particulier ; considérez-le comme un ordre de grandeur approximatif plutôt que comme une référence publiée, et ne l’interprétez pas comme une valeur issue du NIST. Des travaux universitaires ont démontré la possibilité d’une détection en moins d’une seconde, mais il s’agit là d’une donnée indicative, et non d’une garantie de déploiement.

Le tableau ci-dessous illustre concrètement ce spectre.

Tableau : Spectre des délais de détection, allant de la détection en temps réel en ligne à la réanalyse rétrospective.

Une frise chronologique horizontale peut également s'avérer utile : imaginez que la latence augmente de gauche à droite, passant de moins d'une seconde à quelques secondes, puis à environ 1 à 2 minutes, jusqu'à plusieurs heures et plusieurs jours, chaque niveau étant clairement indiqué.

Le niveau rétrospectif mérite d’être souligné, car c’est celui que les équipes négligent le plus souvent. La détection rétrospective, parfois appelée « RetroHunt », consiste à réexaminer les données télémétriques historiques à la lumière de nouveaux indicateurs et d’informations actualisées sur les menaces. C’est ainsi que l’on détecte les intrusions lentes et furtives que la détection en temps réel n’a jamais signalées — car, à ce moment-là, le comportement semblait inoffensif. La détection en continu et la réanalyse rétrospective sont complémentaires, et non concurrentes : l’une détecte les attaques rapides en cours, l’autre détecte les attaques patientes a posteriori.

Pour en savoir plus sur les mécanismes de streaming au niveau de la couche réseau qui sous-tendent le niveau « temps réel » — c'est-à-dire la manière dont l'analyse des flux met en évidence les anomalies au fur et à mesure que les paquets circulent —, consultez la section consacrée à la détection des anomalies réseau. Ce qu'il faut retenir ici, c'est le spectre lui-même : le « temps réel » couvre une intervalle de temps inférieur à la seconde en ligne, le « quasi-temps réel » s'étend sur environ 1 à 2 minutes, et l'analyse rétrospective s'étend de quelques heures à plusieurs jours ; chaque niveau trouve sa place face à une menace différente.

Pourquoi le temps de détection est-il si important aujourd'hui ?

La latence est un facteur déterminant, car le rythme des attaquants et celui des défenseurs ont divergé. Les attaquants parviennent désormais à obtenir un accès initial en 22 secondes en moyenne — contre plus de huit heures en 2022 —, tandis que la durée moyenne d’une intrusion reste de 241 jours, du début à la fin. Lorsque les attaquants agissent en quelques secondes et que les défenseurs mesurent le temps en mois, c’est la fenêtre de détection qui fait la différence entre le succès et l’échec d’une intrusion.

Les données relatives à la rapidité des attaquants sont sans appel. Selon les rapports de veille sur les menaces résumés dans le rapport « M-Trends 2026 » de Mandiant, le délai médian entre l’accès initial et le transfert de contrôle est tombé à 22 secondes en 2025 (Help Net Security). D'autres rapports du secteur ont fait état d'une intrusion record de 27 secondes et d'un temps moyen d'intrusion pour la cybercriminalité de 29 minutes — soit une accélération de 65 % d'une année sur l'autre —, 82 % des détections malware comportant malware(CyberScoop). Une troisième source indépendante vient corroborer ces données : selon les recherches d’Unit 42, les attaques les plus rapides parviennent désormais à l’exfiltration de données en environ 72 minutes — une forte réduction par rapport aux près de cinq heures enregistrées l’année précédente —, un constat observé sur plus de 750 incidents (TechHQ). Le rapport « 2026 Global Incident Response Report » de l’Unit 42 souligne en outre que la part des attaques aboutissant à une exfiltration en moins d’une heure est passée de 19 % à 22 %, le délai médian jusqu’à l’exfiltration s’établissant à environ deux jours.

Passons maintenant au « compte à rebours des défenseurs ». L’étude du Ponemon Institute intitulée « Le coût d’une fuite de données » fait état d’un cycle de vie moyen d’une fuite de 241 jours — 158 jours pour l’identifier et 83 jours pour la contenir —, soit son niveau le plus bas depuis neuf ans (Network World). La même étude estime le coût moyen d’une fuite à 4,44 millions de dollars, en baisse de 9 % (Morgan Lewis). Des progrès, certes. Mais 241 jours contre un délai de transfert de 22 secondes, c’est un décalage catastrophique.

Ici, les données appellent à la nuance : c’est le paradoxe de la durée de présence. Alors même que les attaques se lancent plus rapidement, la durée médiane globale de présence a en réalité augmenté pour atteindre 14 jours en 2025, contre 11 auparavant. Ces deux faits sont vrais en même temps. Le cyberespionnage furtif fait grimper la médiane : ces campagnes affichent une durée médiane de 122 jours, et les cas BRICKSTORM les plus longs ont duré en moyenne entre 393 et 400 jours environ. Le paysage ne se résume donc pas simplement à « tout va plus vite ». La propagation rapide de la cybercriminalité et l’espionnage patient coexistent, et une stratégie en temps réel doit tenir compte des deux.

La question « et alors ? » s'impose d'elle-même. Lorsque les attaquants se relaient toutes les 22 secondes et parviennent à s'échapper en 29 minutes, une fenêtre de détection mesurée en jours ne peut pas suivre le rythme — et c'est dès le début qu'il faut intervenir, avant que le déplacement latéral ne permette à l'intrusion de dépasser le premier système. C'est la latence, et pas seulement la couverture, qui fait la différence.

Comment fonctionne la détection en temps réel : traitement en continu ou par lots

Le principal facteur déterminant du délai de détection est d’ordre architectural : le traitement en continu (streaming) par opposition au traitement par lots (batch). Le traitement en continu traite les données de télémétrie de manière continue, au fur et à mesure de leur arrivée, ce qui permet une détection immédiate à mesure que les événements se produisent. Le traitement par lots accumule les données sur un certain intervalle, puis les traite en bloc, ce qui rend ce mode de traitement intrinsèquement plus lent et rétrospectif. Il est impossible de transformer un traitement par lots en traitement en temps réel par simple optimisation ; c’est le modèle lui-même qui fixe la limite inférieure.

La plupart des pipelines bien établis n’optent pas exclusivement pour l’un ou l’autre. L’architecture hybride la plus documentée est l’architecture lambda : un chemin de streaming en temps réel pour l’immédiateté, associé à un chemin par lots pour l’exhaustivité et la réanalyse. Le chemin de streaming met en évidence la menace en cours dès maintenant ; le chemin par lots réconcilie l’historique complet et permet la recherche rétrospective. Des travaux évalués par des pairs ont montré que le traitement en flux continu était jusqu’à 15 fois plus rapide que le traitement par micro-lots pour les charges de travail à faible latence — une constatation architecturale datant de 2022 qui reflète le compromis permanent entre les deux modèles, et non un benchmark sensible au facteur temps (Wiley).

La rapidité seule ne suffit pas : les alertes rapides doivent également être exploitables. Cela implique d’enrichir les données télémétriques dès leur ingestion : en associant aux événements, au fur et à mesure de leur arrivée, des informations contextuelles sur les actifs, la géolocalisation, l’identité, les renseignements sur les menaces et les étiquettes MITRE ATT&CK . Les signaux hautement prioritaires sont acheminés vers une réponse immédiate ; les données présentant un risque moindre sont orientées vers une analyse rétrospective. C’est l’enrichissement qui fait la différence entre une alerte rapide mais inutile et une alerte rapide et décisive. L’analyse comportementale alimente ce pipeline en tant que source d’information parmi d’autres — pour comprendre comment l’établissement de références comportementales fonctionne en tant que discipline, voir la détection comportementale des menaces.

Prenons un exemple au niveau conceptuel. T1059.001, PowerShell dans le cadre du cadre MITRE ATT&CK Interpréteur de commandes et de scripts technique (T1059, TA0002 Execution, framework v17), figurait parmi les techniques les plus fréquemment observées dans le rapport Red Report 2026, apparaissant dans 27 % des 1,1 million malware analysés (Picus). Un détecteur en temps réel établit une corrélation entre les événements de création de processus et d'enregistrement des blocs de script au fur et à mesure qu'ils se produisent, ce qui lui permet de repérer les exécutions suspectes dès qu'elles se produisent. À l'inverse, une analyse par lots des journaux ne permet de détecter cette même activité qu'une fois l'intervalle terminé — moment auquel le script a déjà été exécuté. C'est précisément cet écart qui explique pourquoi la détection en temps réel est plus efficace que l'analyse par lots pour détecter les exécutions en cours.

Le tableau ci-dessous résume les compromis architecturaux.

Tableau : Comparaison entre les architectures de détection en continu et par lots.

Les outils de détection couvrent plusieurs catégories — SIEM, EDR, détection et réponse aux incidents NDR) et XDR — et chacun présente une surface de latence différente selon qu’il transmet ses données télémétriques en continu ou par lots. Cette page traite ces catégories uniquement sous l’angle des surfaces de latence, et non comme une liste de produits à considérer ; pour comparer les produits, consultez la section « Logiciels de détection des menaces ». Pour en savoir plus sur les mécanismes réseau sous-jacents liés à la transmission en continu, consultez la section « Détection des anomalies réseau ».

Détection en ligne ou hors bande

Après le choix entre le traitement en continu et le traitement par lots, la deuxième décision à prendre en matière de latence concerne le déploiement : en ligne ou hors bande. Les références classiques sont les systèmes de détection et de prévention des intrusions — IDS pour la détection, IPS pour la prévention — et cette distinction se répercute directement sur la latence de détection.

La détection en ligne, dans le modèle de type IPS, s'insère directement dans le flux de trafic. Son avantage est déterminant : elle permet de bloquer immédiatement un flux malveillant. Sa contrainte est tout aussi déterminante : elle doit traiter chaque paquet au débit de la ligne, sous peine de devenir un goulot d'étranglement, ce qui ajouterait de la latence au trafic légitime et créerait un point de défaillance unique potentiel. La puissance de prévention s'accompagne d'une contrainte de traitement au débit de la ligne.

La détection hors bande, dans le modèle de type IDS, s'appuie sur un flux passif provenant d'un TAP réseau ou d'un port SPAN. Elle inspecte une copie du trafic ; elle n'ajoute donc aucune latence au chemin actif et n'a aucun impact sur le débit. Son inconvénient est l'inverse : elle peut détecter et signaler, mais ne peut pas bloquer de manière autonome. La visibilité sans latence se fait au détriment de la capacité de blocage direct.

Le tableau ci-dessous présente les différentes options.

Tableau : Détection en ligne et hors bande, et leurs implications en termes de latence.

Ces deux modèles ne s’excluent pas mutuellement dans une architecture mature, et la détection hors bande présente un atout particulier qui mérite d’être souligné. L’analyse hors agent des flux et des journaux permet d’inspecter efficacement chaque flux en quelques millisecondes sans s’interposer sur le chemin, détectant ainsi les signes avant-coureurs d’un mouvement latéral en temps quasi réel et sans aucune latence en ligne. La détection hors bande constitue donc un puissant complément à faible latence à la prévention en ligne : une visibilité totale, un blocage uniquement là où cela est nécessaire.

Le compromis entre vitesse et précision

Plus rapide ne signifie pas forcément meilleur. La dure réalité de la détection en temps réel est que plus on va vite, plus le coût de chaque faux positif augmente — et l’objectif est de trouver la latence adéquate pour chaque décision, et non pas d’atteindre une latence minimale dans tous les cas. Une fausse alerte est agaçante ; un faux blocage au débit de la ligne a un coût opérationnel réel, car il entraîne la perte de trafic légitime et sape la confiance dans le système.

Il existe également un véritable compromis entre précision et latence au sein même de la logique de détection. En règle générale, les approches analytiques les plus précises sont souvent celles qui présentent la latence la plus élevée, tandis que les approches les plus rapides sacrifient une partie de la précision au profit de la vitesse. Il s’agit là d’une tension conceptuelle à gérer, et non d’un problème pouvant être résolu par une technique unique — d’autant plus que les méthodes d’apprentissage automatique sous-jacentes relèvent d’une discipline distincte. Pour comprendre comment les modèles d’IA pilotent concrètement la détection, consultez la section « Détection des menaces par l’IA » ; dans ce contexte, l’IA est un catalyseur de vitesse, et non le sujet principal.

Les professionnels gèrent ce compromis à l'aide de quelques leviers concrets :

• Un seuil dynamique qui adapte la sensibilité au contexte plutôt que d'appliquer un seuil statique partout.
• Une automatisation sélective qui achemine uniquement les signaux présentant un niveau de confiance élevé vers le blocage automatisé, tandis que les détections présentant un niveau de confiance plus faible sont soumises à un examen humain.
• Une approche combinée rétrospective qui associe une détection rapide en temps réel à une réanalyse plus lente, de sorte que la rapidité et la rigueur se complètent mutuellement.

Le lien avec la fatigue liée aux alertes est direct et implacable. Accélérer le processus sans l’ajuster ne multiplie pas le signal, mais le bruit. Un pipeline qui génère davantage d’alertes, plus rapidement, mais avec le même taux de faux positifs, ne fait que submerger les analystes plus vite. La rapidité n’a de valeur que lorsqu’elle va de pair avec la précision ; c’est pourquoi « l’instantanéité partout » n’est pas le bon objectif. Le véritable objectif est une latence calibrée : rapide là où une décision rapide est sans risque, réfléchie là où la précision prime.

Indicateurs, temps de séjour et détection en temps réel : mise en pratique

Trois indicateurs de latence permettent de quantifier l'efficacité de la détection en temps réel. Le MTTD (temps moyen de détection) mesure le délai moyen entre la compromission et la détection. Le MTTR (temps moyen de réponse) mesure le délai moyen entre la détection et la maîtrise de l'incident. Le temps de présence mesure le laps de temps entre l'accès initial de l'attaquant et le moment de la détection — il s'agit de l'indicateur le plus clair de la latence de détection en conditions réelles.

La référence à battre est un temps de persistance médian mondial de 14 jours en 2025, contre 11 l’année précédente (Mandiant M-Trends 2026). Comme indiqué précédemment, cette augmentation est paradoxale : l’espionnage furtif fait grimper la médiane alors même que la cybercriminalité s’accélère. Le MTTR relève de la phase de réponse plutôt que de la détection — il s’agit d’un indicateur de latence, mais pour ce qui est des mécanismes de réponse, voir la réponse aux incidents et le cycle de vie plus large de détection, d’enquête et de réponse aux menaces (TDIR).

Tableau : Indicateurs de latence et tests de performance pour 2026.

Ces indicateurs prennent tout leur sens dans des cas d’utilisation concrets. En cas d’attaque par ransomware, la détection en temps réel signale les premiers signes avant-coureurs — reconnaissance, mouvement latéral et préparation — afin que les équipes puissent réagir avant que la charge utile de chiffrement massif ne se déclenche. Dans le cadre de la défense contre le piratage de comptes, la vitesse de connexion, la non-correspondance des identifiants d’appareils et la géolocalisation sont évaluées au moment de la connexion, ce qui permet de soumettre automatiquement les connexions suspectes à une authentification multifactorielle (MFA). Dans le cadre de la détection réseau sans agent à débit en ligne, l’analyse hors bande des flux détecte les signes avant-coureurs de mouvements latéraux sans latence en ligne. Dans le secteur des services financiers — un secteur réglementé et à forte valeur ajoutée où cela revêt une importance capitale —, l’évaluation en temps réel des signaux d’identité, alimentée par des outils de veille sur les menaces, empêche l’utilisation abusive des identifiants avant même que la session ne soit établie.

Enfin, associez la détection par streaming à une réanalyse rétrospective. Les cas d’espionnage BRICKSTORM les plus longs ont duré en moyenne entre 393 et 400 jours, ce qui dépasse largement la période standard de conservation des journaux de 90 jours (SecurityWeek). Sans conservation des données et sans RetroHunt, les preuves ont disparu avant même que la menace ne soit identifiée.

Approches modernes de la détection des menaces en temps réel

Le secteur s'oriente vers une détection axée sur le streaming pour cloud réseau, d'identité et cloud , l'IA et l'automatisation servant de multiplicateurs de force pour des équipes réduites. La voie à suivre est claire : traiter la télémétrie dès son arrivée, l'enrichir en temps réel et réserver le traitement par lots à des fins de complétude et de réanalyse.

L'IA est le moteur de cette accélération. Les entreprises qui ont largement recouru à l'IA et à l'automatisation ont réduit le cycle de vie des violations dedonnées d'environ 80 jours et économisé en moyenne quelque 1,9 million de dollars (étude du Ponemon Institute sur le coût d'une violation de données, rapportée par Network World). C'est là l'argument de fond en faveur de l'automatisation — et non des affirmations exagérées selon lesquelles elle serait « plus rapide ». Pour savoir comment l'IA procède concrètement à la détection, voir la section « Détection des menaces par l'IA » ; les méthodes utilisées ne font pas l'objet de cet article.

La latence constitue de plus en plus une contrainte en matière de conformité, et non plus seulement un indicateur d’efficacité. La fonction « DETECT » du cadre de cybersécurité 2.0 du NIST — catégories DE.CM (surveillance continue) et DE.AE (analyse des événements indésirables) — définit la détection en temps opportun comme une capacité fondamentale, tandis que la norme NIST SP 800-137 fournit le critère de référence « en temps réel ou quasi-temps réel ». La réglementation resserre encore davantage les délais : l’article 23 de la directive NIS2 de l’UE impose une obligation d’alerte précoce dans les 24 heures, et le projet de loi britannique sur la cybersécurité et la résilience propose un modèle comparable comprenant une alerte précoce dans les 24 heures suivie d’un rapport complet dans les 72 heures — bien que ce projet de loi soit resté en commission au 23 juin 2026 et n’ait pas été adopté (Bibliothèque de la Chambre des communes britannique). Lorsque la loi exige un signalement dans un délai d’un jour, le temps de latence de détection devient un risque juridique, ce qui renforce l’importance de la posture globale de sécurité du réseau dont dépend la détection en temps réel.

Vectra AI en matière de détection des menaces en temps réel

Vectra AI la détection en temps réel comme un problème de rapport signal/bruit. Plutôt que de déclencher davantage d’alertes plus rapidement, Attack Signal Intelligence™ met en évidence les comportements des attaquants qui comptent réellement, à la vitesse même des signaux d’attaque. Ainsi, une équipe réduite peut agir en quelques secondes sur un signal clair et hiérarchisé, au lieu de passer des jours à trier des alertes de faible valeur. L’objectif n’est pas la vitesse maximale pour elle-même, mais le bon signal, transmis suffisamment vite pour permettre d’agir avant qu’une intrusion ne se transforme en violation de sécurité.

Conclusion

« À quelle vitesse parle-t-on de "temps réel" ? » Il n'y a pas de réponse unique à cette question — et c'est justement là tout l'intérêt. La détection des menaces en temps réel couvre un large spectre allant du blocage en ligne en moins d’une seconde à la réanalyse rétrospective s’étalant sur plusieurs heures ou jours, en passant par l’analyse quasi-temps réel avec un délai de 1 à 2 minutes. L’architecture que vous choisissez, en continu ou par lots, définit le seuil minimal de rapidité que vous pouvez atteindre ; le modèle de déploiement, en ligne ou hors bande, détermine le compromis entre la capacité de blocage et la latence supplémentaire. Alors que les attaquants transfèrent l’accès en 22 secondes tandis que l’espionnage patient s’étend sur plus d’un an, la discipline ne consiste pas à rechercher une latence minimale en toutes circonstances — il s’agit d’adapter le niveau de latence approprié à chaque menace, en associant une détection rapide en streaming à une recherche rétrospective, et en optimisant la précision afin que la vitesse produise un signal plutôt que du bruit. C’est désormais la latence, et non plus seulement la couverture, qui fait la différence. Pour découvrir comment fonctionne la détection en streaming à faible latence au niveau de la couche réseau, explorez la détection des anomalies réseau.