L'observabilité de la sécurité expliquée : des « inconnues connues » de la surveillance aux requêtes à haute cardinalité

L'observabilité de la sécurité est la discipline qui consiste à équiper les systèmes d'outils de mesure afin que les équipes de sécurité puissent répondre à des questions arbitraires et imprévues à partir de données télémétriques riches et à forte cardinalité — mettant ainsi en lumière les « inconnues inconnues » que les règles prédéfinies n'ont jamais anticipées. Alors que la surveillance se contente de détecter des signaux connus, l'observabilité vous permet de vous demander « pourquoi » et de poser des questions auxquelles aucun tableau de bord n'a été conçu pour répondre.

Cette distinction est importante car les attaquants se comportent rarement comme le prévoient les détections prédéfinies. Ils combinent des identifiants légitimes, des outils innovants et des mouvements en plusieurs étapes qu’aucun seuil isolé ne permet de signaler. La capacité à interroger les données télémétriques existantes — à poser une question à laquelle on n’a pensé qu’après le déclenchement d’une alerte — est ce qui transforme « nous avons reçu une alerte » en « nous pouvons reconstituer exactement ce qu’a fait l’attaquant ». Ce guide explique ce qu’est l’observabilité de la sécurité, en quoi elle diffère de la surveillance, de la visibilité et du SIEM, les piliers de télémétrie sur lesquels elle s’appuie, l’architecture de données moderne qui la sous-tend, ainsi que l’orientation que prend cette discipline avec la « détection en tant que code » et l’observabilité des agents IA. Il s’appuie sur le cadre plus large de surveillance de la sécurité que la plupart des SOC exploitent déjà.

Qu'est-ce que l'observabilité de la sécurité ?

L'observabilité de la sécurité est la discipline qui consiste à équiper les systèmes d'outils de mesure afin de pouvoir répondre à des questions liées à la sécurité, qu'elles soient arbitraires ou imprévues, à partir de données télémétriques riches et à forte cardinalité — mettant ainsi en évidence les « inconnues inconnues » — plutôt que de se fier uniquement aux signaux, tableaux de bord et alertes prédéfinis de la surveillance, qui ne répondent qu'aux « inconnues connues ».

Ce terme a des origines à la fois académiques et opérationnelles. Les chercheurs ont défini l’observabilité comme un moyen de renforcer l’architecture de sécurité des écosystèmes numériques complexes, en considérant les questions que l’on peut poser à un système comme un indicateur de son niveau de protection (arXiv). Dans la pratique, cette discipline s’inspire de l’ingénierie de fiabilité des sites (SRE), où l’observabilité décrit la capacité à comprendre l’état interne d’un système à partir des données qu’il émet. En cybersécurité, l’observabilité applique cette même propriété aux questions de sécurité : dans quelle mesure peut-on interroger ses données télémétriques, avec quelle exhaustivité et quelle souplesse, pour comprendre ce qu’un adversaire a fait ?

C'est justement là que réside toute la différence avec la surveillance. La surveillance répond aux « inconnues connues » — ces questions que vous aviez anticipées et pour lesquelles vous aviez mis en place des alertes à l'avance. L'observabilité, quant à elle, répond aux « inconnues inconnues » — ces questions que vous n'aviez pas pensé à poser jusqu'à ce qu'un incident vous y oblige. Un système de surveillance ne vaut que par les règles qu'un utilisateur a définies hier ; un système observable reste utile pour les questions que vous vous poserez demain.

Pourquoi l'observabilité est-elle importante en matière de cybersécurité ?

La surveillance s’articule autour de questions que vous savez déjà poser. Vous définissez un seuil — nombre d’échecs de connexion par minute, nombre d’octets sortants par hôte, malware connu — et le système vous alerte lorsque ce seuil est franchi. Cela fonctionne bien pour les « inconnus connus » : les problèmes que vous aviez anticipés et pour lesquels vous aviez mis en place des mesures de surveillance à l’avance. Le hic, c’est qu’une alerte vous indique seulement qu’un événement s’est produit, sans préciser pourquoi il s’est produit ni ce que cet acteur a pu toucher d’autre.

Le problème, c’est que les attaques sophistiquées sont, presque par définition, celles auxquelles on ne s’attendait pas. Une nouvelle technique de type « living-off-the-land », un parcours en plusieurs étapes qui semble inoffensif à chaque étape, ou un schéma d’abus d’identifiants pour lequel aucun signal d’alerte isolé ne permettra de contourner les règles prédéfinies. C’est là l’argument central en faveur de l’observabilité de la sécurité : lorsque les données télémétriques sont suffisamment riches et interrogeables, un analyste peut poser une question inédite — « montre-moi tous les processus qui ont écrit dans ce répertoire puis établi une connexion sortante vers une nouvelle région » — sans avoir besoin d’avoir prédéfini de règle à cet effet. C’est cette capacité à interroger l’inconnu qui permet à l’observabilité de mettre au jour des attaques inédites et en plusieurs étapes sur une surface d’attaque tentaculaire.

Il y a un deuxième avantage : la rapidité et la certitude lors de l’enquête. Lorsque toutes les données pertinentes sont accessibles en un seul et même endroit, un analyste peut passer d’un simple indicateur à une vue d’ensemble de la situation en quelques minutes plutôt qu’en plusieurs jours — ce qui lui permet de confirmer la portée de l’incident, d’écarter les fausses pistes et de reconstituer la chronologie des événements. C’est là toute la différence entre savoir qu’une alerte s’est déclenchée et savoir exactement ce qu’un attaquant a fait ; c’est pourquoi l’observabilité est devenue une capacité essentielle du centre d’opérations de sécurité moderne.

Il est essentiel de noter que l'observabilité de la sécurité est une discipline générique, et non une fonctionnalité propre à un fournisseur en particulier. La définition ci-dessus reste délibérément indépendante de tout fournisseur : elle porte sur les propriétés d'un système et les pratiques adoptées par une équipe, et non sur une catégorie de produits.

Observabilité de la sécurité vs surveillance, visibilité et SIEM

La surveillance vous indique qu'il y a un problème ; l'observabilité vous permet de vous demander pourquoi — et de poser des questions auxquelles aucune règle n'avait prévu de réponse. Ces termes sont souvent utilisés de manière imprécise ; il est donc utile d'examiner rigoureusement chaque contraste, car ces distinctions ont une incidence réelle sur les décisions en matière d'architecture et de dotation en personnel. L'observabilité n'est pas en concurrence avec la surveillance de la sécurité; elle vient la compléter.

Une analogie utile nous vient du domaine médical. La surveillance s’apparente à un moniteur de signes vitaux qui émet un bip lorsqu’une valeur sort de la fourchette de sécurité — elle vous indique qu’un patient est en détresse. L’observabilité, quant à elle, correspond au bilan diagnostique qui permet au clinicien d’en rechercher la cause, en suivant les symptômes où qu’ils mènent, y compris sur des pistes que personne n’avait anticipées. Les deux sont importantes ; aucune ne remplace l’autre.

Ces différences s'articulent autour de quatre axes : le champ d'application (signaux prédéfinis ou questions arbitraires), l'analyse (seuils ou exploration), la prise de conscience des problèmes (inconnues connues ou inconnues inconnues) et le niveau de capacité (alerte ou enquête). Le tableau ci-dessous résume les liens entre la surveillance, l'observabilité et la visibilité.

Tableau : En quoi la surveillance, l'observabilité et la visibilité diffèrent-elles ? La surveillance surveille les signaux connus, l'observabilité interroge tout, et la visibilité fournit les données sous-jacentes.

La surveillance est-elle un sous-ensemble de l'observabilité ?

Une formulation plus claire consiste à considérer qu’il s’agit de propriétés complémentaires, plutôt que de voir l’une comme un sous-ensemble strict de l’autre. La surveillance correspond à la couche des signaux prédéfinis — c’est-à-dire l’action de surveiller des métriques spécifiques. L’observabilité est la propriété d’un système qui permet de répondre à des questions arbitraires. Les programmes aboutis exploitent les deux : la surveillance détecte rapidement les problèmes connus, tandis que l’observabilité gère tout ce que la surveillance ne peut pas anticiper. L’observabilité ne remplace pas la surveillance ; elle élargit l’éventail des questions qu’une équipe peut se poser. La bonne question n’est donc pas « laquelle choisir », mais « comment ces deux approches se renforcent-elles mutuellement ? »

Observabilité vs visibilité

La visibilité correspond à la couche des sources de données : ce sont les données que vous pouvez réellement voir et collecter à partir d’un domaine donné, tel que le réseau. La visibilité réseau, par exemple, est une source de données ; l’observabilité est la discipline analytique qui l’interroge parallèlement à tous les autres flux de télémétrie. En termes simples, la visibilité fournit les données brutes, et l’observabilité consiste à les exploiter. Les mécanismes de collecte par paquets, TAP, SPAN et est-ouest qui produisent les données réseau relèvent de la visibilité réseau ; l’observabilité exploite ces données comme une source d’information parmi d’autres, au même titre que les journaux, les métriques, les traces, les données d’identité et cloud . Il est impossible d’obtenir une observabilité pertinente sans visibilité sur les données sous-jacentes — mais la visibilité seule, sans la capacité de les interroger, laisse les questions difficiles sans réponse.

Observabilité vs SIEM

Les systèmes de gestion des informations et des événements de sécurité (SIEM) centralisent et corrèlent les données de sécurité à l'aune de règles de détection prédéfinies. L’observabilité est une discipline plus large qui consiste à poser des questions arbitraires à partir de données télémétriques à haute cardinalité. Plutôt que de parler d’un choix binaire, il vaut mieux considérer cette relation comme un spectre : l’observabilité peut compléter un SIEM, dissocier le stockage peu coûteux de la couche d’analyse du SIEM ou, dans certains cas cloud, remplacer entièrement un SIEM traditionnel. La question de savoir si l’observabilité de la sécurité constitue une alternative viable au SIEM dépend de cloud de l’organisation, de ses besoins en matière de conservation des données et de son modèle de coûts, et non d’une réponse universelle. De nombreuses équipes optent pour une solution intermédiaire : elles conservent le SIEM comme couche de requêtes et de corrélation tout en transférant le stockage de masse vers un niveau découplé et moins coûteux, ce qui leur permet de conserver et d’interroger bien plus de données télémétriques que ne le permettrait une indexation facturée à l’ingestion.

Les piliers de l'observabilité de la sécurité

Ces trois piliers — les journaux, les métriques et les traces — s'étendent, dans le domaine de la sécurité, aux événements, aux détections, aux flux réseau, ainsi qu'à cloud d'identité et cloud . Le modèle canonique issu du domaine plus large de l'observabilité comporte exactement trois éléments : les journaux enregistrent ce qui s'est passé, les métriques quantifient l'ampleur et la fréquence des événements, et les traces montrent comment une requête a circulé au sein d'un système distribué.

En matière de sécurité, ce modèle est généralement étendu au modèle MELT (métriques, événements, journaux et traces), qui accorde aux événements un statut de premier plan. Les trois piliers restent la norme ; MELT constitue une extension adaptée à la sécurité, car les événements de sécurité distincts, tels qu’un déclenchement de détection, une modification de politique ou l’octroi d’un privilège, méritent un statut de premier plan plutôt que d’être noyés dans des journaux généraux. Une critique plus récente, celle des « événements larges », soutient que les enregistrements d’événements riches et à forte cardinalité peuvent avoir plus d’importance que la division rigide en trois piliers — un débat qui mérite d’être suivi, mais les piliers restent un point d’entrée utile pour les équipes novices dans ce domaine.

La véritable valeur ajoutée pour les équipes de sécurité réside dans l’extension de chaque pilier générique à son contexte de sécurité, afin que les signaux de sécurité deviennent des données d’observabilité de premier plan plutôt que des éléments secondaires. Un journal n’est pas seulement un message d’application, mais une piste d’audit ; une métrique n’est pas seulement un chiffre de latence, mais un taux d’échecs de connexion ; une trace n’est pas seulement une carte de performances, mais un enregistrement des mouvements « est-ouest » qu’un attaquant pourrait exploiter. Le tableau ci-dessous met en correspondance chaque pilier avec son extension de sécurité, accompagnée d’un exemple de signal.

Tableau : Les trois piliers de l'observabilité appliqués à la sécurité, avec un exemple de signal pour chacun.

Quelles sont les sources de données qui alimentent l'observabilité de la sécurité ?

Dans la pratique, les sources d’informations sont variées. Les journaux d’application et de système fournissent les données brutes d’activité ; les événements de sécurité et les détections ajoutent les occurrences ponctuelles les plus significatives ; la télémétrie réseau et de flux capture la manière dont les hôtes et les services communiquent ; les journaux d’identité et d’audit indiquent qui a fait quoi ; et cloud endpoint cloud complète le tableau pour l’ensemble des charges de travail. Les signaux comportementaux — qui constituent le fondement de la détection des anomalies réseau — sont particulièrement précieux, car ils décrivent le comportement réel des entités plutôt que de se contenter de comparer les données à une liste de menaces connues, ce qui les rend efficaces contre les techniques inédites. La caractéristique déterminante de toutes ces sources d’informations est qu’elles sont traitées comme des données de télémétrie interrogeables, et non comme des flux d’alertes cloisonnés ; ainsi, un analyste peut établir des corrélations entre elles à la demande, au lieu de devoir basculer entre des consoles déconnectées les unes des autres. L’objectif est de disposer d’un ensemble logique de données de télémétrie accessible à toute requête, quel que soit l’outil à l’origine de ces données.

Comment fonctionne l'observabilité de la sécurité : l'architecture moderne des données

L'observabilité moderne en matière de sécurité consiste à collecter des données via OpenTelemetry, à les normaliser avec OCSF, à les stocker dans un lac de données découplé, puis à les interroger à la demande. C'est la compréhension de ce pipeline qui permet de faire la distinction entre un simple mot à la mode et une fonctionnalité opérationnelle ; c'est également cette couche qui distingue le plus clairement l'observabilité des disciplines de surveillance et de visibilité qui l'entourent.

Les étapes se déroulent comme suit :

• Collecte. OpenTelemetry (OTel) est la norme ouverte pour la collecte de données de télémétrie — journaux, métriques et traces — sur des systèmes hétérogènes. Il a obtenu son statut de projet mature au sein de la Cloud Computing Foundation (CNCF) le 21 mai 2026 et compte désormais plus de 12 000 contributeurs issus de plus de 2 800 entreprises, consolidant ainsi son statut de norme open source de facto en matière d’observabilité (CNCF, documentation sur la sécurité d’OpenTelemetry). L’Extended Berkeley Packet Filter (eBPF) est un mécanisme complémentaire au niveau du noyau qui capture des données de télémétrie riches sur le système et le réseau avec une faible surcharge, alimentant souvent le même pipeline.
• Normalisation. Le cadre OCSF (Open Cybersecurity Schema Framework) harmonise les données de télémétrie provenant de nombreux fournisseurs au sein d'un schéma unique indépendant des fournisseurs ; ainsi, un événement de connexion a la même signification quelle que soit sa source (OCSF). L'OCSF a publié la version 1.8.0 (journal des modifications daté du 16 mars 2026), qui a ajouté un ai_opération profil permettant de modéliser les charges de travail liées à l'IA en tant que télémétrie de sécurité de premier ordre (Journal des mises à jour de l'OCSF). Cette norme a également reçu le soutien des États membres de l'Union internationale des télécommunications (UIT) en décembre 2025, en vue de sa ratification en tant que norme internationale d'ici juin 2026 (Blog AWS consacré à l'open source).
• Stockage. Les architectures modernes dissocient le stockage de l'analyse, en acheminant les données de télémétrie brutes vers un « data lake » de sécurité sous forme de stockage d'objets à faible coût, plutôt que vers un index dont l'ingestion est onéreuse. Un « data lake » de sécurité permet de stocker à moindre coût et à grande échelle des données à forte cardinalité, le moteur d'analyse servant de couche de requête par-dessus (Guide du marché « Software Analyst »).
• Requêtes et analyses. Une fois les données normalisées et stockées, les analystes et les ingénieurs en détection effectuent des requêtes arbitraires — ce qui constitue le cœur de l'observabilité.
• La détection sous forme de code. Les détections sont alors exprimées sous forme de code soumis au contrôle de version et testable, déployé via le même pipeline.

« Schéma à la lecture » et stockage découplé

Le changement qui rend cela possible est le « schema-on-read ». Les SIEM traditionnels appliquent le « schema-on-write » : ils structurent et indexent les données lors de leur ingestion, ce qui est rigide et coûteux. Le « schema-on-read », en revanche, applique la structure au moment de la requête, ce qui permet aux équipes de stocker à moindre coût des données télémétriques brutes à forte cardinalité et de les interpréter de manière flexible par la suite. C’est le seul aspect financier pris en compte ici : plutôt que la question économique « construire ou acheter » abordée dans les modèles de déploiement de la surveillance de la cybersécurité, la question des coûts liés à l’observabilité porte sur le compromis entre stockage, analyse et durée de conservation. Une plateforme de pipeline de données de sécurité s’intercale entre la collecte et le stockage pour acheminer, enrichir et réduire les données télémétriques avant leur archivage.

Réduire les angles cloud

Les environnements Cloud — conteneurs éphémères, charges de travail Kubernetes, identités de courte durée — génèrent précisément le type de télémétrie à forte cardinalité et en constante évolution avec laquelle la surveillance par seuils peine à composer. C’est là que l’observabilité prend tout son sens, et qu’elle est directement liée à cloud . Les obstacles sont bien réels : dans l’enquête SANS 2025 sur la détection et la réponse, 58 % des personnes interrogées ont cité le manque cloud et 53 % la complexité du multicloud comme principaux cloud (couverture de l’enquête SANS). cloud étant, par nature, à haute cardinalité et éphémère, l’observabilité réduit les angles morts en permettant de continuer à interroger ces données même après la disparition de la charge de travail. Il convient de noter que le paysage des pipelines de données de sécurité et les conventions d’IA générative d’OpenTelemetry évoluent rapidement ; les choix architecturaux doivent donc être réexaminés périodiquement.

La « détection sous forme de code » et l'analyse à cardinalité élevée

Le concept de « détection sous forme de code » permet de gérer les détections comme on gère les logiciels ; les requêtes à cardinalité élevée mettent en évidence les attaques que les règles prédéfinies n’avaient jamais anticipées. Ensemble, ces deux éléments relient la discipline de l’observabilité au flux de travail quotidien des professionnels.

Le concept de « détection en tant que code » applique la philosophie de l’« infrastructure en tant que code » aux détections. Au lieu de configurer des règles dans une console, les équipes écrivent les détections sous forme de code qui est :

• Sous contrôle de version, ce qui permet de suivre chaque modification et de la vérifier.
• Déploiement via CI/CD: les détections sont ainsi transmises via un pipeline testé.
• Testable: la détection est donc validée à l'aide d'échantillons connus avant la mise en production.
• Portable, ce qui évite que la logique ne soit enfermée dans le format propriétaire d'un seul outil.

Il s'agit là du pilier technique de l'ingénierie moderne de la détection, qui s'associe naturellement à la recherche active de menaces, dans le cadre de laquelle les analystes utilisent des requêtes exploratoires pour identifier ce qu'aucune règle n'a encore détecté. Ces deux approches contribuent à améliorer globalement les résultats en matière de détection des menaces.

Qu'entend-on par « données à cardinalité élevée » ?

Les données à haute cardinalité sont des données de télémétrie comportant de nombreuses valeurs uniques : identifiants utilisateur, identifiants de conteneur, jetons de session, adresses IP sources. C’est cette haute cardinalité qui rend possible les requêtes arbitraires : lorsque vous pouvez segmenter les données de télémétrie selon n’importe lequel des milliers d’attributs uniques, vous pouvez poser une question qui vient tout juste de vous traverser l’esprit. Les « événements larges » — des enregistrements riches comportant de nombreux attributs par événement — constituent le format qui permet de répondre à ces questions à cardinalité élevée. C’est précisément ainsi que l’observabilité aide à détecter les menaces inconnues : cette capacité de requête permet aux analystes de poser des questions qui ne sont codées dans aucune règle prédéfinie.

Pourquoi les détections prédéfinies sont-elles intrinsèquement incomplètes ?

Les arguments en faveur de l'observabilité exploratoire s'appuient sur des données concrètes. Les solutions SIEM d'entreprise couvrent environ 21 % des MITRE ATT&CK , laissant de côté 79 % d'entre elles, alors même qu'elles exploitent une infrastructure capable, en théorie, de détecter plus de 90 % de ces techniques (CardinalOps, juin 2025; Article de Help Net Security). Cette même étude a révélé que 13 % des règles de détection sont enfreintes en moyenne, soit une baisse de 5 % par rapport à 2024. Il ne faut pas en conclure que « votre surveillance est défaillante », mais plutôt que les détections prédéfinies sont structurellement incomplètes ; vous avez donc besoin d’une observabilité à haute cardinalité pour poser les questions que les règles n’ont jamais anticipées. MITRE ATT&CK ici MITRE ATT&CK référence : la valeur de l’observabilité réside dans la possibilité d’effectuer des requêtes sur l’ensemble des techniques telles que la découverte (0007) et la découverte des services réseau (T1046) que ces lacunes de couverture prédéfinies (MITRE ATT&CK).

Deux exemples d'utilisation

La vulnérabilité Log4Shell (CVE-2021-44228) constitue un exemple concret et pérenne de l'utilisation des données d'observabilité comme source d'enquête. Les analystes qui ont repéré des processus fils Java suspects ont pu reconstituer le chemin de l'exploitation à l'aide de traces issues de la surveillance des performances des applications — un service backend apparaissant brièvement dans la carte des services — ainsi que des journaux d'application montrant des charges utiles encodées en base64 dans les en-têtes de requête, confirmant ainsi l'existence de bibliothèques vulnérables (CISA AA21-356A). Ce cas est un exemple de méthodologie datant de 2021, et non une statistique actuelle, mais la leçon reste valable : la télémétrie unifiée permet de transformer une alerte en une reconstitution complète.

Un schéma plus courant consiste en un déplacement latéral cloud » à partir d’un identifiant divulgué. Un signal isolé — une tentative de connexion infructueuse, une connexion réseau — peut sembler anodin. L’observabilité met en évidence la brèche en corrélant les échecs de connexion, le trafic réseau inhabituel, les schémas d’accès aux fichiers et les lectures provenant d’une région inhabituelle au sein d’une seule requête à haute cardinalité. C’est grâce à cette corrélation que l’observabilité améliore les temps de réponse aux incidents et favorise la détection proactive des menaces : elle permet de détecter des attaques en plusieurs étapes que la surveillance basée sur un seuil appliqué à un seul signal ne pourrait pas repérer. Une analyse de 2026 portant sur plus de 750 incidents, réalisée par l’équipe de recherche Unit 42, va dans le même sens : les enquêteurs devaient souvent assembler des données provenant de sources disparates, ce qui ralentissait la détection ; le rapport établissait un lien entre 90 % des violations et des erreurs de configuration ou des failles de sécurité (PR Newswire).

IA et observabilité des agents

L'observabilité de l'IA étend ses piliers aux invites, aux appels d'outils et aux traces — car 48 % des agents IA fonctionnent sans surveillance. Il s'agit de l'extension la plus récente de cette discipline, qui évolue à un rythme soutenu.

L'observabilité des agents IA consiste à étendre les piliers de l'observabilité aux signaux propres à l'IA : les invites, les appels d'outils, la provenance des données récupérées, les métriques relatives aux jetons et aux tours de parole, les autorisations en vigueur lors d'une action, ainsi que les traces de bout en bout du raisonnement et des actions d'un agent. L'observabilité des systèmes d'IA repose sur le même principe appliqué à tout composant d'IA probabiliste, et pas uniquement aux agents autonomes.

La raison pour laquelle une nouvelle télémétrie est nécessaire tient au fait que les systèmes d’IA probabilistes remettent en cause les hypothèses déterministes sur lesquelles repose la surveillance. Une attaque contre un agent d’IA peut réussir en toute discrétion — en manipulant l’agent pour qu’il commette une action nuisible — sans jamais déclencher de seuil d’erreur ou de latence standard. Seule une télémétrie native à l’IA permet de déterminer ce que l’agent a fait, pourquoi il l’a fait, et quels outils et autorisations ont été utilisés, afin qu’un défenseur puisse reconstituer l’incident a posteriori.

L'exposition est considérable. Environ 80 % des entreprises du classement Fortune 500 utilisaient des agents d'IA actifs en février 2026. Pourtant, la couverture moyenne de la surveillance de ces agents n'était que de 52 %, ce qui signifie que 48 % d'entre eux fonctionnaient sans protection (Gravitee, 2026). Pour mettre en place des outils de surveillance d'un agent d'IA, les équipes collectent généralement les données suivantes :

• Invites et réponses, y compris les invites du système.
• Appels de fonctions et d'outils, avec leurs arguments et leurs résultats.
• Provenance de la recherche — quels documents ou données ont servi de base à une réponse.
• Statistiques relatives aux tokens et aux tours de parole au cours d'une conversation.
• L'identité et les autorisations applicables à chaque action.

Les normes et la réglementation rattrapent leur retard. L'OCSF ai_opération profile (v1.8.0, mars 2026) offre aux charges de travail d'IA une prise en charge optimale des schémas (Journal des mises à jour de l'OCSF). Le NIST a lancé, le 17 février 2026, son initiative sur les normes relatives aux agents d'IA, qui comprend des travaux de recherche sur la sécurité et l'identité de ces agents (NIST), et le projet COSAiS du NIST, qui y est lié, élabore actuellement des superpositions de contrôle conformes à la norme SP 800-53 visant à sécuriser les systèmes d’IA à agent unique et à agents multiples (NIST COSAiS). Ces chiffres et ces normes évoluant rapidement, il faut s'attendre à ce qu'ils changent d'ici environ six mois ; veillez donc à indiquer la date de toute affirmation que vous réutilisez.

Approches modernes de l'observabilité de la sécurité

Une observabilité de la sécurité aboutie va au-delà de la simple surveillance pour s'orienter vers une détection corrélée, à haute cardinalité et assistée par l'IA — en s'intégrant à la pile existante, sans la remplacer. Savoir où va cette discipline aide les équipes à tracer une feuille de route réaliste.

Les défis courants liés à la mise en œuvre sont toujours les mêmes : la facturation basée sur l’ingestion rend la collecte à grande échelle coûteuse, les environnements cloud créent des angles morts, et la surabondance de faux positifs submerge les analystes — 73 % des professionnels ont cité les faux positifs comme leur principal défi en matière de détection dans l’enquête SANS 2025 (couverture de l’enquête SANS). Les bonnes pratiques indépendantes des fournisseurs qui permettent d’y remédier sont tout aussi constantes : commencer par une stratégie de collecte de données mûrement réfléchie et des références claires avant de se lancer à la recherche d’outils ; mettre en place des instruments adaptés à une cardinalité élevée afin que les questions arbitraires restent répondables ; et intégrer la solution à endpoint SIEM et endpoint existants plutôt que de tout remplacer, en considérant l’observabilité comme la couche d’analyse superposée à une télémétrie unifiée. Si la question suivante du lecteur porte sur l’économie de mise en œuvre ou la posture de sécurité, ces aspects relèvent de disciplines adjacentes : la gestion de la posture de sécurité pour la posture elle-même, et les modèles de mise en œuvre pour le choix entre développement en interne et achat de solutions.

En matière de conformité, la journalisation exhaustive et la détection s'inscrivent parfaitement dans les référentiels reconnus : les fonctions du NIST CSF 2.0, notamment DETECT (DE.CM « surveillance continue » et DE.AE « analyse des événements indésirables »), RESPOND et IDENTIFY, tandis que RGPD, l'HIPAA, le PCI DSS, la loi SOX et la directive NIS2 définissent les exigences en matière de journalisation d'audit et de conservation des données (Cadre de cybersécurité du NIST). Il s'agit ici d'une liste non exhaustive, et non d'un catalogue complet : la taxonomie complète du cadre est disponible dans la section « Cadres de sécurité ».

Une échelle de maturité en matière d'observabilité de la sécurité

Les équipes peuvent se situer sur une échelle simple à cinq niveaux, qui permet également de mesurer les progrès réalisés en matière d'observabilité de la sécurité :

1. Surveillance — alertes prédéfinies sur des signaux connus.
2. Journalisation centralisée — données de télémétrie regroupées en un seul endroit.
3. Télémétrie corrélée — signaux mis en relation entre différentes sources de données.
4. Observabilité exploratoire à cardinalité élevée — requêtes arbitraires à grande échelle.
5. Observabilité de type « détection en tant que code » assistée par l'IA — détection automatisée et gérée par contrôle de version.

Vectra AI en matière d'observabilité de la sécurité

Vectra AI l’observabilité comme le fondement de la résilience — la combinaison de l’observabilité, du signal et de l’action. Cela implique une couverture de l’ensemble de la surface d’attaque moderne afin que l’activité des attaquants ne puisse nulle part se dissimuler, un signal généré par l’IA qui donne la priorité aux attaques réelles par rapport au bruit, et une action éclairée qui transforme les résultats en réponse. L’accent est mis sur la méthodologie, et non sur les outils : une télémétrie riche ne crée de la résilience que lorsque le signal qu’elle produit est suffisamment clair pour permettre d’agir en toute confiance.