Télémétrie de sécurité : la couche de données sur laquelle repose chaque détection

Aperçu de la situation

  • La télémétrie de sécurité désigne le flux continu de données liées à la sécurité (indicateurs, événements, journaux et traces) provenant de sources telles que endpoint, le réseau, cloud, les identités et les applications.
  • Le rapport DBIR 2026 a révélé que le modèle d'intrusion système multi-domaines était présent dans 61 % des violations de données, contre 53 % auparavant, ce qui rend la télémétrie mono-domaine structurellement insuffisante.
  • Gartner prévoit que 40 % de l'ensemble des données de télémétrie des journaux seront traitées via un produit de pipeline de télémétrie d'ici 2027, contre moins de 20 % en 2024.
  • MITRE ATT&CK son modèle « Data Sources » dans la version 18 (octobre 2025), et la version 19 associe désormais la falsification des données de télémétrie à T1685 sous la rubrique « Déficience de défense ».
  • La circulaire OMB M-26-14 (22 mai 2026) a abrogé la circulaire M-21-31 et a remplacé le principe de conservation systématique des documents par une hiérarchisation fondée sur les risques pour agences gouvernementales américaines.

La télémétrie de sécurité désigne la collecte et la transmission continues et automatisées de données pertinentes pour la sécurité (journaux, événements, métriques, traces, flux et métadonnées) depuis les terminaux, les réseaux, cloud , les identités et les applications vers les systèmes chargés de les analyser. Elle constitue la matière première sur laquelle reposent toutes les opérations de détection, de recherche, d'enquête et de reconstitution judiciaire.

Cette couche de données est désormais devenue un enjeu de conception majeur. Les volumes ne cessent d’augmenter, les pirates ciblent délibérément les failles, et les autorités de régulation redéfinissent les données qui doivent être collectées et conservées. Ce guide explique les types et les sources de télémétrie de sécurité, le fonctionnement de la collecte et de la normalisation, l’origine des angles morts, le coût de conservation des données, ainsi que la manière dont les référentiels, de MITRE ATT&CK à OMB M-26-14, définissent les exigences.

Qu'est-ce que la télémétrie de sécurité ?

La télémétrie de sécurité est davantage un flux de données qu’un produit : il s’agit du flux de signaux émis par les terminaux, les capteurs réseau, cloud , les fournisseurs d’identité et les applications au cours de leur fonctionnement. Une fois collecté et corrélé, ce flux constitue la base factuelle de la détection des menaces et constitue le fondement de toutes les opérations en aval, car ce qui n’a jamais été collecté ne peut jamais faire l’objet d’une requête. Les disciplines d’analyse et d’investigation qui s’appuient sur cette couche de données, notamment l’observabilité de la sécurité, sont abordées dans des pages dédiées.

Pourquoi la télémétrie de sécurité est-elle importante ?

En effet, les intrusions modernes s'étendent à plusieurs domaines, et les indices se trouvent rarement au même endroit. Un pirate peut, au cours d'un même incident, usurper une identité par hameçonnage, se déplacer au sein du réseau et stocker des données dans un cloud . La télémétrie mono-domaine est structurellement insuffisante face à cette réalité, et les chiffres montrent que les cas multi-domaines sont désormais la norme.

La preuve la plus solide est le rapport 2026 de Verizon sur les enquêtes relatives aux fuites de données (DBIR), qui porte sur les incidents survenus entre le 1er novembre 2024 et le 31 octobre 2025. Cette 19e édition a été publiée le 19 mai 2026 (communiqué de presse du DBIR 2026) et s'appuie sur plus de 31 000 incidents et plus de 22 000 violations confirmées dans 145 pays (résumé du DBIR 2026).

Au sein de cet ensemble de données, le modèle d’intrusion système en plusieurs étapes est apparu dans 61 % des incidents, contre 53 % et 36 % lors des deux éditions précédentes, tandis que les ransomwares ont représenté 48 % des incidents, contre 44 % (résumé du rapport DBIR 2026). Les attaques qui touchent plusieurs domaines laissent des traces dans plusieurs flux de télémétrie, ou n’en laissent nulle part. C’est là l’argument principal en faveur d’une approche de la télémétrie comme un ensemble de flux plutôt que comme un flux unique.

Quelle est la différence entre la télémétrie, la journalisation, la surveillance et l'observabilité ?

Commençons par la question qui divise véritablement les professionnels du domaine. Certaines sources considèrent la télémétrie comme un flux en temps réel et la journalisation comme un enregistrement a posteriori, deux concepts liés mais distincts. D’autres considèrent les journaux comme l’une des nombreuses formes que peut prendre la télémétrie. Le domaine tend à adopter cette seconde interprétation, plus large : la télémétrie englobe les métriques, les événements, les journaux et les traces, et la journalisation est la pratique qui produit l’une de ces formes. Cette page suit cette interprétation plus large et mentionne le débat là où cela s’avère pertinent.

La surveillance et l'observabilité s'inscrivent au-dessus des données plutôt qu'au sein même de celles-ci. La surveillance de la sécurité consiste à surveiller en permanence des signaux connus afin de détecter des conditions d'attaque et de défaillance connues, tandis que la surveillance de la cybersécurité étend cette pratique à l'ensemble de l'environnement. L'observabilité décrit ce qu'une équipe peut faire avec la couche de données : poser de nouvelles questions sans avoir à déployer au préalable de nouveaux outils d'instrumentation. La télémétrie est la matière première utilisée par ces trois concepts, comme le résume le tableau ci-dessous.

Concept De quoi s'agit-il ? À quoi cela répond-il ? C'est ici qu'il vit
Télémétrie Le flux continu de signaux liés à la sécurité émis par un environnement Quelles sont les données brutes disponibles concernant l'activité dans l'environnement ? Toute cette page
Exploitation forestière La pratique consistant à enregistrer des événements distincts, ce qui génère une courbe de télémétrie Ce qui s'est passé, événement par événement Types et sources, ainsi que les aspects économiques liés à la rétention
Suivi Surveiller les signaux connus correspondant à des conditions connues et déclencher des alertes en cas d'apparition de ceux-ci Est-ce qu'un incident connu est en train de se produire en ce moment même ? Pages consacrées aux pratiques de surveillance de la sécurité
Observabilité La méthode consistant à analyser les données télémétriques pour expliquer des situations imprévues Pourquoi cela se produit-il, y compris les « inconnues inconnues » ? La page consacrée à l'observabilité de la sécurité

La télémétrie constitue la couche de données, la journalisation en est l'une des manifestations, tandis que la surveillance et l'observabilité sont des pratiques qui s'appuient sur celle-ci.

Types et sources de télémétrie de sécurité

La télémétrie de sécurité revêt quatre formes courantes et provient d'au moins cinq domaines. Aucune forme ni aucun domaine ne permet à lui seul de visualiser l'intégralité d'une attaque ; la planification de la couverture commence donc par une cartographie de ce que chaque source peut et ne peut pas révéler.

La taxonomie MELT

Dans le secteur, on utilise l'acronyme MELT pour désigner les différents types de données de télémétrie : métriques, événements, journaux et traces.

  • Les indicateurs sont des mesures chiffrées relevées à intervalles réguliers, comme le nombre d'échecs d'authentification par minute sur un concentrateur VPN. Ils sont concis et peu coûteux à conserver, ce qui les rend particulièrement adaptés à l'établissement de valeurs de référence et à la détection de tendances.
  • Les événements sont des enregistrements distincts d'un phénomène se produisant à un moment donné, comme le lancement d'un processus ou le blocage d'une connexion par un pare-feu. La plupart des logiques de détection s'appuient sur ces événements.
  • Les journaux sont des enregistrements horodatés générés par les systèmes d'exploitation, les applications et les services, qu'il s'agisse des journaux d'événements Windows ou des pistes cloud . Ils contiennent le contexte le plus riche et représentent le coût de stockage le plus élevé.
  • Les traces permettent de suivre une requête ou une transaction unique à travers des services distribués. Dans le domaine de la sécurité, elles aident à reconstituer la manière dont une action s'est propagée à travers les systèmes connectés.

Télémétrie par domaine

  • TélémétrieEndpoint EDR. Démarrages de processus, modifications de fichiers et du registre, chargements de modules et activité des scripts capturés par les agents hôtes. Il s'agit de la vue la plus complète du comportement sur l'hôte, et elle n'est disponible que lorsqu'un agent est installé et en cours d'exécution.
  • Télémétrie réseau. Les enregistrements de flux tels que NetFlow et IPFIX, les requêtes DNS et les attributs de la négociation TLS sont généralement extraits sous forme de métadonnées plutôt que de paquets complets. Les capteurs étant installés sur des prises de dérivation et des ports miroirs plutôt que sur des hôtes, l'analyse du trafic réseau permet de détecter des appareils non gérés et transitoires que les outils basés sur des agents ne peuvent pas identifier.
  • Cloud . Journaux d'audit du plan de contrôle, journaux de flux et signaux relatifs aux charges de travail provenant de l'infrastructure et des plateformes SaaS. Il s'agit du système de référence en matière de cloud , avec une réserve qui sera abordée plus loin : les fournisseurs filtrent ou échantillonnent certains types de journaux par défaut.
  • Télémétrie des identités. Enregistrements des connexions et des audits provenant des annuaires, des fournisseurs d'identité, des applications SaaS, des systèmes de gestion des accès privilégiés et des services de fédération. La couverture doit s'étendre aux identités non humaines, notamment les comptes de service, les clés API et les agents d'IA, qui constituent la base de données sur laquelle reposent la détection et la réponse aux menaces liées aux identités.
  • Télémétrie XDR et MDR. Les plateformes XDR établissent des corrélations entre les données de télémétrie issues de plusieurs domaines pour aboutir à des détections unifiées, tandis que les fournisseurs MDR exploitent leur service de détection à partir de toutes les données de télémétrie générées par l'environnement du client. Ces deux approches s'appuient sur les domaines mentionnés ci-dessus, sans en ajouter de nouveau.

Les données d'alerte et d'inspection viennent compléter le tableau. Les pare-feu et les systèmes de détection et de prévention des intrusions émettent leurs propres verdicts et détections, et ils restent des sources incontournables pour la sécurité du réseau, même s'ils se contentent d'observer les comportements plutôt que de les reconstituer.

Un aspect est véritablement nouveau. Le rapport DBIR 2026 a révélé que 45 % des employés utilisent régulièrement l’IA sur les appareils de l’entreprise, contre 15 % l’année précédente (résumé du rapport DBIR 2026). Les données télémétriques relatives à l’utilisation des navigateurs et des outils d’IA deviennent donc une source d’information de premier ordre, car l’utilisation non autorisée de l’IA se concentre précisément là où les agents traditionnels cherchent le moins.

Domaine Sources représentatives Ce qu'il révèle de manière unique Écart courant
Endpoint Agents EDR et journaux d'événements du système d'exploitation Comportement au niveau des processus sur les hôtes gérés Pas d'agent, pas de données : les appareils non gérés sont invisibles
Réseau NetFlow et IPFIX, DNS, métadonnées TLS provenant de points de captage et de miroirs Activité de chaque appareil connecté au câble, qu'il soit géré ou non Les données utiles chiffrées limitent l'inspection aux métadonnées
Cloud Journaux d'audit du plan de contrôle, journaux de flux, signaux de charge de travail Chaque action d'administration et chaque appel d'API au sein du tenant Filtrage et échantillonnage de certains types de journaux côté fournisseur
Identité Connexions via un fournisseur d'identité, modifications apportées à l'annuaire, accès privilégiés et événements de fédération Quelle identité (humaine ou machine) a été authentifiée, depuis où, et pour quoi faire ? Les identités non humaines échappent souvent à toute surveillance
Demande Pistes d'audit, journaux des serveurs Web, événements du pare-feu des applications Web Abus de logique métier invisible pour les couches d'infrastructure Manque d'uniformité dans l'instrumentation des logiciels sur mesure

Cinq domaines de télémétrie, ce que chacun d'entre eux révèle de manière spécifique, et les lacunes de couverture que chacun laisse lorsqu'il est utilisé seul.

Fonctionnement de la télémétrie de sécurité

Les signaux bruts sont transformés en données de télémétrie exploitables grâce à un processus en plusieurs étapes : collecte, transmission, normalisation, acheminement, stockage, analyse. Chaque étape relève d'un choix de conception, et plusieurs d'entre elles constituent à elles seules des surfaces d'attaque.

La collecte s'effectue via des agents sur les hôtes, des capteurs sur les prises réseau et les ports miroirs, l'interrogation par API des plateformes cloud SaaS, ainsi que des exportateurs de flux intégrés aux logiciels modernes. La collecte via les prises réseau se distingue par son caractère passif : un capteur observant un port miroir ne nécessite aucune installation sur le endpoint, ce qui offre aux défenseurs un canal que les attaquants ne peuvent pas atteindre facilement à partir d'un hôte compromis. La transmission achemine ensuite les données vers les outils d'analyse en utilisant le traitement par lots, la mise en mémoire tampon et la contre-pression, afin que les pics de trafic n'entraînent pas la perte silencieuse d'événements.

Dans son ensemble, le processus se présente comme suit :

  1. Sources d'instruments comprenant des agents, des capteurs, des exportateurs et des intégrations d'API.
  2. Collectez en continu les événements, les métriques, les journaux et les traces.
  3. Transmission avec contrôle du traitement par lots, de la mise en mémoire tampon et de la contre-pression.
  4. Tout normaliser dans un schéma commun.
  5. Acheminez chaque flux vers un outil d'analyse, un système de stockage, ou les deux.
  6. Conserver par catégorie de température : chaud, tiède et froid.
  7. Effectuer des analyses à des fins de détection, d'enquête et de recherche.
Un pipeline de gauche à droite comportant six nœuds étiquetés reliés par des flèches directionnelles étiquetées : « Collect » (agents, prises réseau et ports miroirs, interrogation d’API, exportateurs de flux) est relié par une flèche intitulée « signaux bruts » à « Transmit » (traitement par lots, mise en mémoire tampon et contre-pression), qui est relié par une flèche intitulée « flux mis en mémoire tampon » à « Normalize » (schémas partagés tels que OCSF, OpenTelemetry, ECS, et CIM), qui est relié par une flèche intitulée « enregistrements joignables » à « Route » (filtrer, enrichir et diriger chaque flux), qui est relié par une flèche intitulée « flux hiérarchisés » à « Store » (niveaux « hot », « warm » et « cold »), qui est relié par une flèche intitulée « télémétrie interrogeable » à « Analyze » (détection, investigation et recherche) ; la couleur à elle seule ne véhicule aucune signification.
Six étapes permettent de transformer les signaux bruts provenant de chaque domaine en données de télémétrie de sécurité normalisées, hiérarchisées et exploitables.

C'est la normalisation qui permet de regrouper les données de télémétrie provenant de différents fournisseurs. L'Open Cybersecurity Schema Framework (OCSF) confère aux événements de sécurité une structure commune et indépendante des fournisseurs. OpenTelemetry normalise la manière dont les logiciels sont instrumentés et dont leurs métriques, journaux et traces sont exportés ; le projet propose par ailleurs des recommandations de sécurité spécifiques pour renforcer la sécurité de ses composants de collecte. L’Elastic Common Schema (ECS) et le Common Information Model (CIM) poursuivent le même objectif au sein de leurs propres écosystèmes. Ces quatre éléments décrivent la forme que prennent les données une fois normalisées ; il ne s’agit pas d’outils d’analyse.

De là, les données parviennent à une couche d'analyse. Un système SIEM établit des corrélations entre les données télémétriques normalisées et des règles ainsi que des modèles comportementaux afin de générer des alertes, et cette page s'arrête à son seuil. Les pratiques d'interrogation et d'investigation ouvertes qui s'exécutent sur la même couche de données relèvent de la discipline de l'observabilité, à laquelle incombe ce travail.

Le suivi des indicateurs de télémétrie permet de garantir la fiabilité du pipeline. Quatre indicateurs sont essentiels : la couverture, c'est-à-dire les techniques de détection que vos sources sont en mesure de mettre en œuvre ; le volume d'ingestion et son coût ; la latence entre la génération d'un événement et son analyse ; et l'exhaustivité, c'est-à-dire que les flux arrivent sans lacunes ni pertes silencieuses. Des résultats médiocres sur l'un de ces quatre indicateurs se traduiront par la suite par des angles morts. Suivez-les source par source, et non sous la forme d'une moyenne globale.

La télémétrie de sécurité en pratique

Trois cas, répartis sur une période de 13 ans, illustrent la différence entre le simple fait qu’une télémétrie existe, qu’elle soit complète et qu’elle donne lieu à une action. Chacun d’entre eux montre également pourquoi les analystes considèrent la télémétrie comme une preuve : elle doit exister, couvrir le champ d’application approprié et parvenir à quelqu’un ou à quelque chose qui agisse.

  • Hugging Face (2026) : données télémétriques exploitées. L'entreprise a indiqué que son « pipeline de détection des anomalies utilise un triage basé sur un modèle de langage de grande envergure (LLM) appliqué aux données télémétriques de sécurité afin de distinguer les signaux réels du bruit quotidien, et que c'est la corrélation de ces signaux qui a permis de signaler la compromission » (déclaration de Hugging Face). Ce compte-rendu a été fourni par la partie victime de la violation elle-même et ne précise pas la chronologie de l’intrusion. Il a été rendu public le 16 juillet 2026 et a fait l’objet d’une couverture médiatique neutre plus large le 20 juillet (Help Net Security). Les informations ont confirmé l’impact sur les ensembles de données internes et les identifiants (TechCrunch).
  • SolarWinds SUNBURST (2020) : télémétrie incomplète. L'implant de la chaîne d'approvisionnement, rendu public le 13 décembre 2020, dissimulait son trafic de commande et de contrôle sous la forme de données de télémétrie légitimes et contournait endpoint (analyse SUNBURST de Mandiant). Une télémétrie Endpoint peut ne pas détecter les activités transitant par des canaux de confiance.
  • Target (2013) : télémétrie ignorée. Un rapport rédigé le 26 mars 2014 par les services de la commission du commerce du Sénat américain a révélé que Target semblait ne pas avoir réagi aux multiples alertes automatiques émises par son logiciel anti-intrusion alors que des pirates installaient malware, avant que les données ne quittent le réseau (analyse « Kill Chain » du Sénat). Une capacité de détection sans triage n’est pas une détection.

Le temps de persistance est un indicateur clé, et il évolue dans la mauvaise direction. Le rapport M-Trends 2026, qui couvre l’année civile 2025 et s’appuie sur plus de 500 000 heures consacrées à la réponse aux incidents, a révélé que le temps de persistance médian mondial est passé de 11 à 14 jours, le cyberespionnage et les incidents impliquant des informaticiens nord-coréens affichant quant à eux une médiane de 122 jours (M-Trends 2026). L’édition précédente, M-Trends 2025, qui couvre l’année civile 2024, est à l’origine de cette référence de 11 jours. Pour combler cet écart, il s’agit moins d’une question de volume de données brutes que d’une question de couverture permettant la recherche active des menaces entre les alertes, et de rigueur dans le triage, qui transforme les signaux en interventions avant que la durée de présence ne s’aggrave.

Les failles de télémétrie et la manière dont les pirates les exploitent

Il est impossible de détecter ce qui n’a jamais été enregistré. Les angles morts se présentent sous deux modes de défaillance radicalement différents : les lacunes de couverture, où l’événement n’est jamais généré, et la falsification, où il est généré puis supprimé. Ces deux phénomènes aggravent la surcharge d’alertes : les équipes du SOC reçoivent plus d’alertes qu’elles ne peuvent en trier, et la fatigue liée aux alertes noie les rares signaux d’attaquants sous un volume bien plus important d’alertes décrivant des opérations normales. Le rapport DBIR 2026 met en évidence le coût d’une résolution trop lente : le délai médian pour parvenir à une résolution complète a atteint 43 jours, et seules 26 % des vulnérabilités critiques figurant sur la liste des vulnérabilités connues pour avoir été exploitées de la CISA ont été entièrement corrigées, contre 38 % auparavant (résumé du rapport DBIR 2026).

Lacunes de couverture : ces données ne sont jamais produites

Les appareils non gérés, en périphérie, IoT et de technologie opérationnelle (OT) n’exécutent aucun agent ; il n’existe donc pas de télémétrie d’hôte provenant de ces appareils. Le rapport DBIR 2026, couvrant les incidents jusqu’en octobre 2025, a révélé que l’exploitation de vulnérabilités représentait désormais 31 % des violations de données, ce qui en fait le vecteur d’accès initial le plus courant (résumé du rapport DBIR 2026). Le rapport DBIR 2025 attribuait déjà 22 % des actions d’exploitation de vulnérabilités aux périphériques en périphérie et aux VPN (rapport DBIR 2025). Le filtrage et l’échantillonnage effectués côté fournisseur créent le même type de lacune dans cloud .

La télémétrie d’identité peut également échouer de manière silencieuse. Une étude sur les menaces menée par un fournisseur et publiée en juillet 2026 a mis en évidence une usurpation d’identifiant client OAuth dans les environnements Entra ID : un identifiant client usurpé laisse le champ « nom de l’application » vide, de sorte que les systèmes de détection configurés pour une application nommée peuvent ignorer complètement cette activité (Help Net Security). Une campagne suivie depuis décembre 2025 a utilisé plus de 3,7 millions d’identifiants d’application usurpés contre plus de deux millions de comptes utilisateurs, testant la validité des identifiants « sans générer d’événement de connexion réussi » (The Hacker News). Aucun identifiant de technique ATT&CK ne couvre ce comportement : il s’agit d’une lacune de couverture, et non d’une altération, car rien n’a jamais été documenté.

Falsification : les données sont générées, puis supprimées

Lorsque des données télémétriques sont générées, les attaquants les suppriment. Le catalogue MITRE ATT&CK classe cela dans la catégorie T1685 Désactiver ou modifier les outils dans le cadre de la tactique dite « Defense Impairment » (TA0112) : les adversaires neutralisent ou modifient les logiciels de défense eux-mêmes, notamment les outils EDR, les systèmes de détection d'intrusion (IDS), les antivirus, ainsi que les agents et capteurs de journalisation ; cette course à l'armement est couverte par Contournement de l'EDR. Ces six sous-techniques visent l'enregistrement lui-même ou la perception qu'en a l'analyste : désactivation ou modification du journal des événements Windows, cloud ou du journal d'audit du système Linux ; modification ou usurpation de l'interface utilisateur d'un outil ; et effacement des journaux d'événements Windows ou des journaux système Linux et Mac.

La pression est bien réelle. Un rapport sur les menaces dans le secteur portant sur l'année 2025 a révélé qu'environ 82 % des détections malware concernaient malware, la pénétration la plus rapide enregistrée ayant été de l'ordre de 27 secondes. Les intrus qui agissent aussi rapidement en utilisant des identifiants et des outils légitimes ont tout intérêt à désactiver la télémétrie de l'hôte.

La couche de collecte est elle-même un logiciel

La couche de collecte est également un logiciel. Deux vulnérabilités d'OpenTelemetry datant de 2026, CVE-2026-40182, une réponse illimitée détectée dans l'implémentation .NET susceptible d'épuiser la mémoire (NIST CVSS 5.9), et CVE-2026-45287, une fuite de descripteurs de fichiers dans OpenTelemetry-Go pouvant entraîner un déni de service, constituent à la fois des problèmes de disponibilité et d'épuisement des ressources. Un collecteur en panne bloque tout le flux en aval. Les scores attribués à ce dernier illustrent également pourquoi le triage basé sur un seul score est fragile : le NIST lui a attribué une note de 5,5 selon le CVSS 3.1, tandis que la CVE Numbering Authority lui a attribué une note de 2,1 selon le CVSS 4.0 ; ainsi, un même bug est interprété de manière très différente selon la source d’information.

Toutes les sources de compensation figurant dans le tableau ci-dessous partagent une caractéristique commune : leur indépendance vis-à-vis de l'hôte compromis. Lorsque les agents sont absents, désactivés ou falsifient les données, la télémétrie réseau issue des points de captage et des miroirs constitue la trace que les intrus ne peuvent pas faire taire ; c'est là l'argument central en faveur de la visibilité réseau et de la détection et réponse aux incidents.

Angle mort Pourquoi ces données manquent-elles ? Avantage pour l'attaquant Source de compensation
Appareils non gérés, périphériques, IoT et OT Aucun agent ne peut être installé ; par conséquent, aucune télémétrie de l'hôte n'est jamais générée. Accès initial et persistance sans enregistrement sur l'hôte Télémétrie réseau à partir de points de prélèvement et de miroirs
cloud filtrés ou échantillonnés Les paramètres par défaut des fournisseurs omettent ou n'incluent qu'un échantillon de certains types de journaux L'activité dans les intervalles n'atteint jamais le SOC Niveaux d'audit complets, ainsi que la corrélation des flux et des identités
Identifiants de client OAuth falsifiés Aucun événement de connexion réussie n'est enregistré Les détections liées à une application ne se déclenchent jamais Références comportementales des comptes et télémétrie des sorties du réseau
Falsification des journaux (T1685) Les événements sont générés, puis désactivés, modifiés ou effacés Les actions post-intrusion disparaissent du journal Transfert en temps réel vers des systèmes inaccessibles aux pirates
Panne ou surcharge du collecteur La couche de collecte elle-même présente une défaillance ou a planté Tout ce qui se trouve en aval s'éteint d'un seul coup Surveillance de l'état des canalisations et réparation rapide des collecteurs

Cinq angles morts courants en télémétrie, le mode de défaillance à l'origine de chacun d'entre eux et la source de compensation qui rétablit la visibilité.

Les aspects économiques de la télémétrie de sécurité

La croissance des données de télémétrie constitue désormais un poste budgétaire ayant des répercussions sur la sécurité. Le rapport « Telemetry Trends » de Cribl a révélé que les flux de données principaux (syslog, TCP et TCP JSON) ont chacun augmenté de plus de 60 % en glissement annuel sur la période allant d’avril 2024 à avril 2025 (Cribl Telemetry Trends). La tarification des services d’analyse s’effectue généralement au gigaoctet ingéré ; cette croissance pèse donc directement sur le budget opérationnel du SOC. La pression sur les coûts devient alors un problème de sécurité déguisé : les équipes qui suppriment en masse des sources pour réaliser des économies se créent un angle mort, et non une économie.

La couche de pipeline de télémétrie apparaît comme la solution d’avenir. Le « Market Guide for Telemetry Pipelines » de Gartner, publié le 2 septembre 2025, prévoit que « d’ici 2027, 40 % de l’ensemble des données de télémétrie de journaux seront traitées via un produit de pipeline de télémétrie, contre moins de 20 % en 2024 » (Gartner Market Guide for Telemetry Pipelines). Un pipeline s'intercale entre les producteurs et les destinations pour ingérer, traiter et acheminer les données : il filtre le bruit, enrichit les enregistrements, remodèle les schémas et hiérarchise chaque flux avant que les données n'atteignent la couche d'analyse.

Ce niveau d’analyse correspond généralement à un SIEM, et c’est précisément le volume d’ingestion de données SIEM par gigaoctet que les pipelines sont censés protéger. Pour situer le marché dans son contexte, l’analyse du marché des SIEM réalisée par l’agrégateur syndiqué Mordor Intelligence estime la taille du marché à 12,06 milliards de dollars en 2026, pour atteindre 20,78 milliards de dollars d’ici 2031, soit un taux de croissance annuel composé de 11,50 %. Cette même analyse affirme, de sa propre initiative et sans s'appuyer sur des données primaires indépendantes, que les organisations comptant plus de 10 000 employés ingèrent plus de 10 téraoctets de données de journaux chaque jour. Il convient de considérer ces deux chiffres comme des indications générales plutôt que comme des mesures précises.

La hiérarchisation de la conservation des données constitue l'autre volet de la maîtrise des coûts. Conservez les données de détection en temps réel dans le niveau « chaud », les données d'investigation dans le niveau « tiède » et les données de conformité dans le niveau « froid », puis dissociez le stockage du moteur d'analyse afin que l'historique reste consultable sans être soumis à la tarification du niveau « chaud ».

Niveau Fenêtre type Utilisation principale Profil des coûts
Chaud De quelques jours à plusieurs semaines Détection en temps réel, triage et corrélation Meilleur rapport prix/gigaoctet, requête la plus rapide
Chaud De quelques semaines à plusieurs mois Enquêtes et recherches à court terme Modéré, requête plus lente acceptable
Froid De un à sept ans Conformité, audits et définition rétrospective du périmètre Stockage de classe « archive », au coût le plus bas

La conservation par niveaux associe chaque utilisation de la télémétrie à une classe de stockage, ce qui permet de maintenir la couverture sans avoir à appliquer les tarifs des niveaux « hot » à l'ensemble des données.

La stratégie qui permet de coordonner tout cela repose sur une journalisation ciblée : définir d’abord les objectifs de détection, les mettre en correspondance avec les données télémétriques nécessaires à ces détections, puis hiérarchiser ou éliminer tout le reste. Les conseils destinés aux professionnels, tels que le guide de stratégie télémétrique de Security Blue Team, encadrent cette même approche : chaque décision de collecte doit répondre à un objectif de détection ou d’enquête, et non à une simple habitude.

Télémétrie de sécurité, cadres de référence et conformité

Les exigences en matière de télémétrie sont de plus en plus souvent imposées par les cadres réglementaires et les autorités de régulation, et l'année 2026 marquera un tournant décisif sur deux points de référence clés.

Mise en correspondance des données télémétriques avec le modèle MITRE ATT&CK

Cartographie télémétrique à l'intérieur MITRE ATT&CK a été modifiée à deux reprises en six mois. La version 18, publiée le 28 octobre 2025, a rendu obsolète l'ancien composant « Sources de données » au profit des stratégies de détection (DET) et d'analyse (AN) (Notes de mise à jour de MITRE ATT&CK 2025). La version 19, publiée le 28 avril 2026, a ensuite scindé la catégorie « Évasion défensive » en deux sous-catégories : « Furtivité » (TA0005) et « Affaiblissement défensif » (TA0112) (Notes de mise à jour de MITRE ATT&CK 2026). Les identifiants de sources de données héritées, tels que DS0029, DS0038et DS0002 circulent encore dans les ressources destinées aux professionnels, mais il s’agit d’identifiants historiques issus d’un modèle obsolète, et non de recommandations actuelles. Pour ingénierie de détection Pour les équipes, la cartographie de la couverture commence désormais par les stratégies de détection et les analyses qui leur sont associées, chacune précisant les données télémétriques dont elle a besoin.

La directive OMB M-26-14 et la révision des quotas d'exploitation forestière fédéraux pour 2026

La note de service M-26-14 de l’OMB, datée du 22 mai 2026, stipule : « Avec effet immédiat, la note de service M-21-31 de l’OMB est abrogée. » La hiérarchisation des priorités en fonction des risques remplace la conservation systématique de tous les journaux, et s’articule autour de deux objectifs : la surveillance continue des événements (CEM) et la recherche de menaces, les enquêtes, les interventions et l’analyse forensic (THIRF). Le modèle de maturité comporte cinq niveaux, allant du niveau 0 « Inefficace » au niveau 4 « Optimal », et le mémorandum lui-même désigne le niveau 1 de manière incohérente : « Basique » dans son tableau des délais de mise en conformité, « Initial » dans l’annexe C. Le champ d’application couvre les systèmes civils fédéraux américains, incluant explicitement l’IoT et l’OT, et exclut les systèmes relevant de la sécurité nationale, du ministère de la Défense et de la communauté du renseignement.

La note de service charge la CISA d'élaborer une architecture de référence en matière de journalisation (LRA) qui, au 20 juillet 2026, n'a toujours pas été publiée. La page dédiée à cette ressource sur le site de la CISA est une page provisoire datée du 26 mai 2026, indiquant qu'elle sera mise à jour lorsque la LRA sera finalisée et que le délai de 90 jours aura expiré, vers le 20 août 2026.

La révision fédérale de 2026 relative à l'exploitation forestière a abrogé la directive M-21-31 et a laissé l'architecture de référence de la CISA en suspens à compter de juillet 2026.

Normes et facteurs favorisant la fidélisation

La norme NIST SP 800-92, guide de référence en matière de gestion des journaux, date de septembre 2006 ; son projet de révision 1 a fait l’objet d’une consultation publique qui s’est achevée le 29 novembre 2023 sans aboutir à une version définitive, de sorte que la version originale de 2006 reste la référence. Le NIST CSF 2.0 intègre la télémétrie dans sa fonction « Détection » (Detect), au sein de la catégorie « Surveillance continue » (DE.CM). L’OWASP a renommé la norme A09:2021 « Défaillances de la journalisation et de la surveillance de sécurité » en A09:2025 « Défaillances de la journalisation et des alertes de sécurité », tout en la conservant à la 9e place. Le modèle Zero Trust de la CISA désigne la « Visibilité et l’analyse » comme l’une de ses capacités transversales.

Les obligations de conservation s'inscrivent dans un cadre plus large. Les normes PCI DSS, RGPD, NIS2, HIPAA et SOC 2 déterminent toutes la durée de conservation des données de télémétrie, et les rapports de conformité mobilisent les niveaux d'archivage, ce qui rappelle utilement que la norme M-26-14 relève de la politique fédérale américaine, alors que ces facteurs s'appliquent à l'échelle mondiale.

Le cadre Référence Comment fonctionnent les cartes de télémétrie Statut/date
MITRE ATT&CK Stratégies de détection (DET) et analyse (AN) Chaque analyse précise les données de télémétrie nécessaires pour valider une technique Version 19 publiée le 28 avril 2026 ; sources de données obsolètes depuis la version 18.0 (28 octobre 2025)
OMB M-26-14 Objectifs du CEM et du THIRF, modèle de maturité à cinq niveaux Collecte, suivi et conservation des données fondés sur les risques pour agences gouvernementales américaines Publié le 22 mai 2026 ; abroge la décision M-21-31
Architecture de référence de la CISA en matière de journalisation Conformément à la directive M-26-14 Présentera en détail l'architecture fédérale en matière d'exploitation forestière En attente ; page provisoire au 20 juillet 2026
NIST SP 800-92 Guide de planification de la gestion des journaux Références en matière de création, de stockage et d'élimination des fichiers journaux Septembre 2006 ; projet de révision 1 non finalisé
NIST CSF 2.0 Fonction de détection, catégorie DE.CM La surveillance en continu repose sur la couverture télémétrique Version 2.0, publiée en 2024
Top 10 de l'OWASP A09:2025 Enregistrement et notification des défaillances en tant que catégorie de risque applicatif Anciennement A09:2021 ; reste à la 9e place
Modèle Zero Trust » de la CISA Visibilité et analyse La télémétrie est à la base des décisions zero trust » Version 2

Comment les principaux cadres réglementaires et réglementations font référence à la télémétrie de sécurité, avec la version ou le statut de chacun d'entre eux en juillet 2026.

Approches modernes de la télémétrie de sécurité

La tendance est aux signaux moins nombreux mais de meilleure qualité, issus d’une couverture plus étendue. Quatre axes définissent l’approche moderne : des architectures « pipeline-first » qui filtrent et acheminent les données avant la couche d’analyse, des schémas de normalisation ouverts qui garantissent la jointabilité et la portabilité des données, un stockage découplé qui permet de conserver l’historique à un coût raisonnable, et un tri assisté par l’IA qui exploite directement les données de télémétrie au lieu d’ajouter un nouveau flux d’alertes. Pour les équipes opérationnelles des SOC, le critère permettant d’évaluer chacune de ces approches est de savoir si l’écart entre le signal brut et une décision fiable se réduit.

La toute dernière source de télémétrie est l’IA elle-même. Le rapport DBIR 2026 a classé l’utilisation de l’IA « fantôme » comme la troisième action interne non malveillante la plus courante dans son ensemble de données sur la prévention des pertes de données (résumé du rapport DBIR 2026), et les agents d’IA ainsi que d’autres identités non humaines deviennent des producteurs et des consommateurs de télémétrie à part entière. Les plans de couverture qui se limitent aux utilisateurs humains et aux hôtes gérés sont déjà dépassés.

Vectra AI en matière de télémétrie de sécurité

Vectra AI du principe que la sécurité est compromise : des attaquants compétents finiront par s'introduire dans le système ; la question déterminante est donc de savoir à quelle vitesse leur comportement se manifeste dans les données. La couverture télémétrique de l'ensemble du réseau moderne, englobant le campus, le centre de données, cloud et l'identité, est nécessaire mais non suffisante. Ce qui importe, c'est de transformer cette couverture en un petit nombre de signaux d'attaque très fiables sur lesquels un analyste peut s'appuyer en toute confiance pour agir.

Foire aux questions

Quelle est la différence entre la télémétrie et la journalisation ?

Quelle est la différence entre la télémétrie et l'observabilité ?

Pendant combien de temps faut-il conserver les données de télémétrie et les journaux de sécurité ?

Comment réduire les coûts liés à l'ingestion des données de télémétrie dans un système SIEM ?

Qu'est-ce qu'OpenTelemetry et comment est-il utilisé dans le domaine de la sécurité ?

Comment les pirates contournent-ils ou altèrent-ils les données de télémétrie de sécurité ?

Comment mesure-t-on la télémétrie de sécurité ?