DefenceLevel Index · Méthodologie v1.30

Comment est calculé le DefenceLevel Index

Cette page décrit intégralement, sans simplification, la règle par laquelle le DefenceLevel Index attribue chaque jour un niveau de 5 à 1. La règle est déterministe : à données identiques, elle produit toujours le même résultat, et chaque niveau est accompagné des raisons qui l'ont déterminé.

Version de la méthodologie : 1.30 · En vigueur depuis le 4 novembre 2026 · Dernière mise à jour de cette page : 4 novembre 2026

1. Ce qu'il mesure, ce qu'il ne mesure pas

Le DefenceLevel Index mesure l'urgence des nouvelles menaces cyber : la probabilité qu'un jour donné une organisation doive agir rapidement sur des vulnérabilités de logiciels et d'équipements d'usage courant, parce que de vrais attaquants les exploitent ou sont sur le point de le faire.

Il ne mesure pas :

• le risque d'une organisation donnée, qui dépend des produits qu'elle utilise, de leur configuration et de son exposition sur internet ;
• le volume total des vulnérabilités publiées : des milliers chaque mois, la plupart sans conséquence pratique ;
• les attaques ciblant des victimes précises, les campagnes d'hameçonnage, les vols d'identifiants ou les incidents qui ne passent pas par une vulnérabilité logicielle publique.

Un niveau bas ne signifie pas que le monde est sûr : il signifie qu'au cours de ces 24 heures rien de nouveau n'est apparu qui exige une intervention exceptionnelle au-delà de la maintenance normale.

2. L'échelle de 5 à 1

L'échelle reprend l'échelle militaire américaine DEFCON : 5 est la situation ordinaire, 1 la plus grave. DefenceLevel n'est affilié ni au département de la Défense des États-Unis ni à la conférence DEF CON®, marque de Def Con Communications, Inc.

Les conditions exactes de chaque niveau figurent dans la section 8.

3. Les sources

Le système lit des sources publiques, regroupées par rôle. Le rôle détermine deux choses : le poids de la source dans le signal d'attention et sa capacité à confirmer une vulnérabilité ou son exploitation. Seuls les organismes officiels, les CERT et les éditeurs peuvent confirmer l'existence d'une vulnérabilité ; les laboratoires de recherche peuvent aussi confirmer une exploitation active ; la presse et les réseaux sociaux contribuent à l'attention mais ne confirment rien à eux seuls.

Les données de VulnCheck KEV sont utilisées selon les conditions de VulnCheck, qui demandent de citer la source : VulnCheck KEV (vulncheck.com). Les données du catalogue européen des vulnérabilités exploitées sont réutilisées selon les mentions légales de l'ENISA, en citant la source : ENISA EUVD (euvd.enisa.europa.eu).

Enrichissement : pour chaque vulnérabilité, le système lit aussi la probabilité d'exploitation EPSS publiée par FIRST et la fiche officielle sur cve.org.

La console en direct de la page d'accueil indique combien de sources ont répondu au cours des dernières 24 heures. La liste s'enrichit au fil du temps : chaque ajout est consigné dans la section 14.

4. Le cycle de collecte

• Toutes les 30 minutes : sources rapides (recherche, presse, exploits publics, code, réseaux sociaux).
• Toutes les heures : sources officielles et éditeurs (NVD, CISA KEV, Microsoft, GitHub Advisories, CERT, avis des éditeurs).
• Toutes les 12 heures : Wordfence Intelligence, la base de vulnérabilités des extensions et thèmes WordPress.
• À chaque collecte, chaque vulnérabilité concernée est réévaluée et le niveau actuel est recalculé sur les dernières 24 heures.
• À 04:00 UTC, tous les jours de l'année, le niveau du jour et le contenu du briefing sont fixés, avec les données collectées jusqu'à ce moment ; à 05:00 UTC, après vérification, le briefing est envoyé aux abonnés.

Chaque signalement collecté enregistre une source, un instant, une ou plusieurs vulnérabilités citées (identifiées par leur code CVE) et quelques indicateurs tirés du texte, comme la mention explicite d'une exploitation active. Les signalements ne sont jamais supprimés : le calcul utilise toujours l'historique complet. Un signalement attribué par erreur à une vulnérabilité, par exemple un avis sur d'autres vulnérabilités qui ne la cite qu'en contexte, est exclu du calcul pour cette vulnérabilité après vérification : la correction reste enregistrée et le niveau est recalculé avec les mêmes règles. Dans un bulletin sur plusieurs vulnérabilités, une vulnérabilité exploitée depuis au moins 7 jours (catalogue KEV ou première confirmation), citée à côté de vulnérabilités nouvelles (publiées depuis moins de 14 jours ou pas encore publiées) et absente du titre de l'avis, est un renvoi et non un signal : ce signalement ne compte pas pour elle. Un avis officiel ou de l'éditeur publié dans les 48 heures qui suivent la publication de la vulnérabilité est l'avis qui la concerne : il n'est exclu que s'il lui attribue à tort une exploitation. Le communiqué de la CISA sur l'ajout au catalogue KEV ne compte que pour les vulnérabilités que le catalogue répertorie à sa date (ou à la veille, à cause du fuseau horaire) : pour les autres qu'il cite, il ne compte pas.

5. L'analyse de chaque vulnérabilité

Chaque vulnérabilité est évaluée sur quatre axes, chacun de 0 à 10.

5.1 Gravité technique (S)

C'est le score CVSS officiel. Si la fiche CVE n'est pas encore publiée mais qu'un avis officiel, d'un CERT national ou de l'éditeur, confirme la vulnérabilité, c'est la gravité indiquée dans l'avis qui s'applique : son score CVSS ou, à défaut, le minimum de la classe indiquée (critique 9, élevée 7, moyenne 4, faible 0,1) ; le produit touché et la possibilité d'une attaque sans identifiants sont repris du même avis. Sinon, il est estimé à partir de la catégorie de la vulnérabilité (par exemple : exécution de code à distance 9 ; contournement de l'authentification 8,5 ; écriture de fichiers arbitraires 8,5 ; élévation de privilèges 7,5 ; divulgation d'informations 5,5 ; cross-site scripting 4,5), avec −1 si des prérequis difficiles sont nécessaires (identifiants administrateur, accès local ou physique) et +0,5 si elle est attaquable par le réseau sans identifiants. « Attaquable par le réseau sans identifiants » vient du vecteur CVSS, mais ne s'applique pas si l'éditeur écrit qu'il faut un accès local, des privilèges ou un compte déjà obtenus, ou un client authentifié : ce sont alors les prérequis difficiles qui comptent. Si la fiche CVE n'a ni éditeur ni produit, ce sont ceux que les catalogues de vulnérabilités exploitées et l'ENISA EUVD indiquent sous forme structurée qui s'appliquent ; ensuite, les produits touchés indiqués par la fiche elle-même ou par NVD, s'ils ne nomment qu'un seul éditeur (avec les seuls produits d'une distribution Linux, qui inclut le composant, l'évaluation la plus grave s'applique) ; à défaut, le produit nommé dans les titres des avis et des catalogues, avec son éditeur lorsqu'il s'agit d'un produit connu. Si elle n'a pas de description, la catégorie est tirée des titres des avis.

5.2 Exploitation réelle (E)

Elle dépend du statut documenté le plus avancé :

La valeur monte jusqu'à 10 × EPSS si la probabilité EPSS est plus élevée, et au moins à 6 si la vulnérabilité fait partie des 5 % les plus probables selon EPSS. Elle baisse de 1,5 si des prérequis difficiles sont nécessaires (sauf exploitation active) et de 1 si la complexité d'attaque CVSS est élevée.

L'« exploitation active » est reconnue dans les textes à des expressions explicites (« exploited in the wild », « actively exploited », « under active exploitation » et similaires). Elle ne compte que si la source est officielle, un éditeur ou la recherche ; si seuls la presse, ou au moins deux comptes différents sur les réseaux sociaux, l'affirment, la vulnérabilité reste en observation avec la mention « exploitation signalée, non confirmée » et ne va jamais dans le bruit. Elle est aussi reconnue en italien, français, espagnol, allemand et néerlandais, les langues des CERT lus, et ne compte pas lorsqu'elle est niée (« not aware of active exploitation », « n'a pas connaissance d'exploitation »). Dans les bulletins portant sur plusieurs vulnérabilités, elle ne compte que pour celles nommées dans la phrase sur l'exploitation ; si cette phrase n'en nomme aucune, elle compte pour toutes s'il y en a trois au plus et, s'il y en a davantage, seulement pour celle dont le paragraphe contient la phrase, lorsque le bulletin les décrit une par une. Un article de presse ou une publication sur les réseaux sociaux qui ne cite que d'autres CVE dans son titre ou ses premières lignes ne compte pas comme un signalement d'attaques pour les vulnérabilités mentionnées plus loin, sauf si la phrase sur l'exploitation les nomme. Dans les résumés en liste, elle ne compte que pour la vulnérabilité de la ligne qui la contient, et elle ne compte pas lorsqu'elle décrit seulement ce que la faille permettrait (« lets attackers… »). Un article de recherche dont le titre nomme d'autres CVE et pas celle-ci la cite comme contexte : ce n'est pas un signal pour elle. Un article de recherche ou de presse sur une vulnérabilité inscrite au catalogue CISA KEV depuis plus de 30 jours la cite comme contexte et ne compte pas pour elle, sauf si le titre ou l'adresse nomme la vulnérabilité, son produit ou son éditeur, ou parle d'attaques, ou si, dans un texte sur plusieurs vulnérabilités, la phrase sur l'exploitation la nomme. Il en va de même pour toute vulnérabilité lorsqu'un article de recherche ne cite qu'elle, sans nommer dans le titre ou l'adresse la vulnérabilité, son produit ou son éditeur et sans parler d'attaques : il la cite comme contexte et, comme un renvoi, ne compte pas pour elle.

5.3 Impact (I)

Il part de la catégorie (exécution de code 9,5 ; contournement de l'authentification 9 ; compromission de la chaîne d'approvisionnement 9 ; écriture de fichiers arbitraires 8,5 ; élévation de privilèges, corruption de mémoire, injection SQL 7 ; …) et se corrige selon la diffusion du produit (voir la section 6) : +1,5 composants présents presque partout, +1 équipements de bordure, 0 produits courants, −1,5 produits de niche, −4 générateurs de vulnérabilités à faible impact. +1 si elle est utilisée par des groupes de rançongiciels selon la CISA, +0,5 si elle est attaquable par le réseau sans identifiants. L'exécution de commandes arbitraires compte comme exécution de code, y compris lorsqu'elle découle d'une injection SQL.

5.4 Attention (Z)

Elle mesure à quel point les professionnels en parlent au cours des dernières 24 heures. Comptent les mentions de la recherche, du code, de la presse et des réseaux sociaux, chacune pondérée selon le rôle de sa source (tableau de la section 3), et chaque compte, média ou auteur ne compte qu'une fois, avec le poids le plus élevé de ses mentions, même quand il publie sur plusieurs réseaux sociaux sous le même nom d'utilisateur ; les avis officiels, des éditeurs et des archives d'exploits entrent déjà dans la gravité et l'exploitation, et ne comptent pas ici :

Le logarithme empêche que mille messages répétés comptent mille fois plus qu'un seul.

Ne comptent pas les comptes qui republient les fiches des vulnérabilités au lieu d'en discuter : ceux qui, au cours des 7 jours précédents, ont écrit sur au moins 20 vulnérabilités différentes, sauf les comptes de référence de la section 3. Le même texte publié par des comptes différents à quelques minutes d'intervalle, comme le fait une rédaction avec plusieurs profils, compte comme un seul compte.

5.5 Score combiné

Les poids privilégient la gravité et l'exploitation réelle ; l'attention ne compte que pour 10 %, afin de ne pas récompenser le bruit. Ce sont des choix de méthode, déclarés ici et vérifiés a posteriori (section 12). Le score sert à choisir quelles vulnérabilités entrent dans le briefing (7,0 pour les principales, 5,8 pour « à surveiller ») ; le niveau, en revanche, suit les règles explicites de la section 8.

6. Produits répandus et ciblés

Une vulnérabilité compte davantage si elle touche un produit utilisé par de nombreuses organisations et historiquement visé par les attaquants. La classification associe une liste publique par type de produit et une donnée objective d'historique des attaques :

L'historique des attaques provient du catalogue CISA Known Exploited Vulnerabilities : on compte les vulnérabilités dont l'exploitation est confirmée ajoutées au cours des 5 dernières années. Le décompte est refait automatiquement le premier jour de chaque mois (UTC) et reste fixe tout le mois ; l'état de chaque mois est conservé. Ainsi, un produit que les attaquants ciblent entre dans la classification même s'il ne figurait pas dans la liste, et un produit de la liste sans historique d'attaques n'est pas surévalué. L'éditeur est reconnu sans sa forme juridique, quelle que soit la façon dont la source l'écrit : « PHP Group » est PHP, « SAP SE » est SAP, « IBM Corporation » est IBM.

La classe issue de la liste vaut pour les produits de l'éditeur de la plateforme : Windows de Microsoft, Android de Google ou des fabricants qui l'installent sur leurs téléphones, les composants système (OpenSSL, glibc, sudo…) aussi des distributions Linux qui les incluent. Un produit tiers qui en cite le nom n'en hérite pas : une bibliothèque Python n'est pas Python, une application Android n'est pas Android. Pas davantage un projet dont le nom accole celui de la plateforme à un autre mot par un trait d'union (node-openssl n'est pas OpenSSL), qui ne prend pas non plus l'historique d'attaques de son éditeur, sauf si le produit porte seul le nom de la plateforme. Il en va de même pour les composants additionnels (plugins, extensions, thèmes, modules complémentaires) : un plugin pour WordPress n'est pas WordPress. Ces produits sont classés pour eux-mêmes, avec leur propre historique d'attaques. L'éditeur et le produit sont ceux de la fiche CVE, sauf dans deux cas où valent ceux du catalogue CISA KEV : la fiche cite plus de trois produits (Microsoft cite chaque version de Windows), ou elle indique un éditeur sans lien avec celui du catalogue, le plus souvent un produit qui intègre le composant touché (Apache Struts, et non l'équipement Huawei qui le contient). Les noms génériques du catalogue (« Multiple Products ») ne valent jamais.

Une vulnérabilité qui touche plusieurs produits du même éditeur est évaluée avec la classe de chacun, et le résultat le plus grave s'applique : une faille de Bamboo qui touche aussi Confluence et Jira compte comme une faille d'un équipement de périmètre. Les produits touchés sont ceux qu'indiquent les sources officielles (fiche CVE, NVD, catalogue CISA KEV, avis des éditeurs), sauf ceux que la fiche déclare non touchés ; les produits d'autres éditeurs, comme les systèmes qui intègrent une bibliothèque touchée, et les noms génériques du catalogue ne comptent pas.

Pour les éditeurs au catalogue étendu (Cisco, Fortinet, Ivanti, Citrix, Palo Alto Networks, F5, Juniper, VMware, ConnectWise), le nom de l'éditeur dans la liste des équipements de bordure ne vaut que pour ses produits ayant leur propre historique d'attaques, au moins 2 vulnérabilités exploitées en 5 ans : un pare-feu Cisco oui, un commutateur de centre de données ou un serveur de licences non. Ses autres produits comptent comme produits courants.

Les commutateurs et les points d'accès du réseau interne ne sont pas des équipements de bordure, même chez les éditeurs dont les produits comptent par ailleurs comme tels : ce sont des produits courants. On les reconnaît au nom du produit ou, pour Zyxel, à la référence du modèle.

Un éditeur qui est la marque d'un produit connu (par exemple NetScaler, de Citrix) compte comme ce produit de son propriétaire, avec son historique. Le noyau Linux compte comme tel même lorsque la fiche CVE l'appelle seulement « Linux ».

7. La maîtrise de l'alarmisme

Une vulnérabilité ne peut pas faire monter le niveau si elle relève de l'un de ces cas :

• Non confirmée : on en parle beaucoup, mais aucune source officielle ni aucun éditeur ne l'a confirmée. Si la presse signale toutefois une mise à jour de sécurité de l'éditeur, elle rejoint celles à surveiller.
• Rejetée ou contestée dans le registre CVE, sauf si elle figure dans le catalogue KEV de la CISA ou fait l'objet d'un avis de l'éditeur : elle est alors évaluée comme les autres.
• Sensationnaliste : langage de gros titre (« catastrophique », « des milliards d'appareils menacés »…), ni exploitation ni exploit crédible, gravité inférieure à 7 ou produit de niche, quand l'attention ne s'explique pas par un avis officiel ou de l'éditeur des 3 derniers jours.
• Exploit faux ou non vérifié largement partagé, avec une gravité inférieure à 9, quand l'attention ne s'explique pas par un avis officiel ou de l'éditeur des 3 derniers jours.

Ces cas vont dans la section « Très discutées, mais sans motif d'alarme aujourd'hui » du briefing, avec l'explication de la raison pour laquelle ils ne constituent pas une urgence. Fait exception une vulnérabilité pour laquelle la presse, ou au moins deux comptes différents sur les réseaux sociaux, signalent des attaques : même non confirmées, elle va parmi les vulnérabilités à surveiller, jamais dans cette section. La rédaction peut déplacer une entrée de cette section vers les vulnérabilités à surveiller, jamais l'inverse ; aucun niveau ne change.

En outre, une vulnérabilité ancienne (publiée il y a plus d'un an, ou avec un code CVE datant de deux ans plus tôt) n'est pas une nouvelle, sauf si la CISA vient de confirmer son exploitation : dans ce cas, elle peut atteindre au plus le niveau 3.

8. Le niveau de chaque vulnérabilité

Les conditions sont évaluées de haut en bas ; la première remplie s'applique. Seules les vulnérabilités confirmées et non classées comme bruit peuvent dépasser le niveau 5.

« Récente » signifie : ajoutée au catalogue KEV depuis 14 jours au plus, ou publiée depuis 30 jours au plus, ou faisant l'objet d'un nouveau signalement d'exploitation par une source officielle, un éditeur ou la recherche au cours des dernières 72 heures. Une exploitation connue de longue date est un problème connu, pas une nouvelle.

Sources indépendantes (attention large du niveau 2 et demi-point de l'attention) : chaque source compte une fois ; les réseaux sociaux ensemble valent une seule source, car l'attention mesure déjà combien on en parle ; le communiqué de la CISA sur l'ajout au catalogue KEV est le catalogue KEV ; le catalogue VulnCheck KEV ne compte pas si les preuves qu'il cite viennent d'une source déjà présente. Le même nom d'utilisateur sur plusieurs réseaux sociaux est un seul auteur.

Le niveau 2 distingue l'attaque contre un produit d'une menace à large impact. Un équipement de bordure attaqué (un pare-feu, un VPN, une passerelle d'un éditeur donné) est une urgence pour ceux qui l'utilisent : ceux qui le comptent parmi leurs produits dans My Defence, avec « Seulement mes produits », reçoivent tout de suite l'alerte, et tous la trouvent dans le briefing du jour ; mais à lui seul, il ne fait pas passer l'indice global en risque grave, réservé aux composants présents partout et aux campagnes documentées par plusieurs sources.

Il s'ensuit qu'une vulnérabilité grave sur un produit répandu ne descend jamais au niveau 5, et qu'une vulnérabilité critique avec un exploit public sur un produit répandu est au moins au niveau 3, avant même que des attaques soient observées.

9. Le niveau du jour

9.1 Le niveau à un instant donné

À chaque instant, le niveau est le plus grave parmi ceux des vulnérabilités du briefing : les nouveautés et celles toujours en cours, ces dernières un cran en dessous :

Les vulnérabilités principales sont les vulnérabilités confirmées avec un score combiné d'au moins 7,0 ou un niveau 3 ou plus grave. Le sont aussi, même sans attaque connue, les vulnérabilités critiques (gravité ≥ 9) d'un équipement de bordure, attaquables par le réseau sans identifiants et publiées depuis 30 jours au plus : elles gardent leur niveau et portent l'indication de mettre à jour dans la semaine. Celles « à surveiller » apparaissent dans le briefing mais ne déterminent pas le niveau. Un signal sans code CVE sur un produit qui a déjà dans le briefing une vulnérabilité avec son code CVE est la même nouvelle : il n'apparaît ni comme entrée à part ni parmi celles à surveiller. Les vulnérabilités de produits classés comme bruit ne sont jamais principales, sauf si elles figurent dans le catalogue CISA KEV. Les vulnérabilités du même produit citées avec une vulnérabilité principale dans le même avis officiel, de l'éditeur ou de recherche des 7 derniers jours, avec au plus 5 vulnérabilités, rejoignent son entrée même si elles ne seraient pas retenues seules : elles forment la même chaîne d'attaque. Le niveau du jour ne change pas.

Le moment de l'actualité est le plus récent parmi : la publication de la vulnérabilité, l'ajout au catalogue KEV (+12 heures), le dernier signal officiel, d'un éditeur, de la recherche ou d'un exploit, et « maintenant » s'il y a au moins 3 mentions au cours des dernières 24 heures. Une vulnérabilité dont on continue de parler reste donc dans l'actualité ; une dont on ne parle plus sort du calcul. Un avis republié par la même source avec le même titre dans les 30 jours n'est pas un signal nouveau ; une mise à jour avec un titre différent, si. La date de chaque signal est celle à laquelle la source l'a publié ; un élément sans date lisible ne compte comme nouveau que la première fois qu'il apparaît. Un signal sans date fiable (illisible, antérieure à 1999, de plus d'un jour dans le futur, ou identique à la milliseconde sur au moins trois avis différents de la même source portant sur des vulnérabilités différentes : c'est l'heure à laquelle la source a mis à jour son flux) vaut pour ce qu'il dit, pas pour le moment : il ne rend pas une vulnérabilité d'actualité et ne confirme pas son exploitation, qui reste signalée et non confirmée tant qu'une source datée ne la confirme pas.

Pour rester au niveau 1 ou 2, et au niveau 3 en raison d'une exploitation active, une vulnérabilité doit toutefois avoir un signal fort au cours des dernières 24 heures : publication, ajout au catalogue KEV (+12 heures), ou signal officiel, d'un éditeur, de la recherche ou d'un exploit. Si elle n'est dans l'actualité que parce qu'on en parle, elle compte un cran en dessous, dans le niveau du jour et dans le briefing.

Aux niveaux 4 ou 5, une vulnérabilité d'actualité seulement parce qu'on en parle, sans signal fort depuis plus de 7 jours, n'est pas principale : elle figure parmi celles à surveiller et ne détermine pas le niveau.

Nouveautés des dernières 24 heures. Parmi les vulnérabilités principales dans l'actualité au cours des dernières 24 heures, sont des nouveautés celles qui n'ont jamais figuré parmi les entrées des briefings des 30 jours précédents, celles qui ont un signal fort au cours des dernières 24 heures et celles dont le niveau est plus grave que la dernière fois, sauf si seules les discussions l'ont fait monter. Une vulnérabilité déjà signalée qui revient dans l'actualité seulement parce qu'on en parle, sur les réseaux sociaux ou dans la presse, n'est pas une nouveauté et ne revient pas dans le briefing ; si les discussions ont fait monter son niveau, elle figure sur une ligne, comme celles toujours en cours, qui l'indique. La même règle vaut pour les vulnérabilités à surveiller : une vulnérabilité déjà parue dans les briefings des 30 jours précédents ne revient qu'avec un signal fort au cours des dernières 24 heures. Une vulnérabilité jamais signalée dont on a seulement parlé au cours des dernières 24 heures va parmi celles à surveiller, sauf si elle est au niveau 1–3 (exploitée, ou critique avec un exploit public) : c'est alors une nouveauté, même si elle figurait déjà parmi celles à surveiller. Une vulnérabilité de plus d'un an, dans le catalogue CISA KEV depuis plus de 30 jours, ne revient parmi les vulnérabilités à surveiller qu'avec un signal fort au cours des 7 derniers jours ou si au moins deux comptes en ont parlé au cours des dernières 24 heures.

Toujours en cours. Une vulnérabilité activement exploitée de niveau 1–3, déjà signalée et sans signal fort au cours des dernières 24 heures, reste dans le briefing pendant 72 heures après son dernier signal fort, sur une ligne, même si personne n'en parle ; le dernier jour, la ligne l'indique. Dans le niveau, elle compte un cran en dessous : ceux qui n'ont pas encore corrigé restent exposés. Un nouveau signal fort la ramène parmi les nouveautés. Si son produit a une nouveauté, elle figure dans la même entrée. Les autres vulnérabilités déjà signalées, sans nouveauté, quittent le briefing.

Autres vulnérabilités exploitées. Le briefing compte au plus 8 nouveautés, les plus graves, et au plus 8 lignes « toujours en cours ». Les vulnérabilités activement exploitées (exploitation confirmée ou catalogue KEV) qui restent en dehors figurent dans une section à part, une ligne par vulnérabilité, de la plus grave à la moins grave, 60 au maximum ; les autres restent en dehors. Le niveau du jour les inclut déjà. Elles comptent comme signalées : comme les autres, elles ne reviennent parmi les nouveautés qu'avec un signal fort au cours des dernières 24 heures ou un niveau plus grave.

Sous le niveau, le briefing indique ce qu'il était dans le briefing précédent et quelles vulnérabilités le déterminent.

Quand le briefing signale un produit, il rappelle aussi les autres vulnérabilités du même produit exploitées au cours des 60 derniers jours (catalogue KEV ou première exploitation) qui ne figurent pas dans le briefing du jour : 6 au maximum, les plus récentes, avec la date depuis laquelle elles sont exploitées. Ce n'est qu'un rappel : il ne change ni le niveau du produit dans le briefing ni celui du jour.

9.2 Le niveau du jour dans l'indice

Le niveau d'un jour (jour calendaire en UTC) est celui fixé à 04:00 UTC et communiqué aux abonnés dans le briefing de 05:00 de ce jour. Il ne change plus ensuite. Si les collectes de la journée relèvent un niveau plus grave, l'indice l'affiche comme pic de la journée, avec l'heure en UTC, sans changer le niveau du jour.

Le niveau actuel affiché en direct est, lui, recalculé à chaque collecte : une urgence qui apparaît après le briefing figure immédiatement dans le niveau actuel, est transmise aux abonnés par une alerte immédiate et apparaît dans l'indice le jour suivant.

Les alertes partent en DEFCON 1, 2 et 3 : le DEFCON 1 à tous les abonnés ; le DEFCON 2 à ceux qui reçoivent toutes les alertes et, pour ceux qui ont choisi « Seulement mes produits » dans My Defence, seulement s'il concerne leurs produits ; le DEFCON 3 seulement à ceux qui ont choisi « Seulement mes produits », et seulement s'il concerne leurs produits. En DEFCON 4 et 5, aucune alerte ne part : les vulnérabilités sont dans le briefing du jour. Les alertes ne partent que sur un signal fort des dernières 24 heures. Si la vulnérabilité figurait déjà parmi les entrées du briefing et qu'aucun nouveau signal fort n'est arrivé depuis, un niveau plus grave atteint ensuite (par exemple parce qu'on en parle davantage) ne déclenche pas d'alerte en DEFCON 2 ou 3 : le briefing suivant le signale. Le DEFCON 1 part toujours. Si seul le catalogue VulnCheck KEV confirme l'exploitation et que les preuves qu'il cite ne sont que des publications sur les réseaux sociaux, des pages d'agrégateurs ou des bases de données de vulnérabilités (comme la fiche CVE), qui décrivent la faille sans prouver une attaque, la vulnérabilité reste dans le briefing à son niveau, mais l'alerte attend une deuxième source : le catalogue CISA KEV, un CERT, l'éditeur ou un rapport de recherche.

Dans les 24 heures qui suivent une alerte DEFCON 1 ou 2, la vulnérabilité ne descend pas sous le niveau qu'elle avait au moment de l'alerte du seul fait que le temps passe, par exemple parce que les mentions sortent des 24 heures : ce niveau est recalculé avec les données actuelles, et ne descend que si un fait a changé, comme un signalement exclu après vérification, une CVE rejetée ou un CVSS officiel plus bas. Dans le briefing de ces 24 heures, l'alerte vaut un signal fort : la vulnérabilité reste parmi les nouveautés, au niveau de l'alerte.

10. Le rôle de l'intelligence artificielle

Le niveau, la sélection et l'ordre des vulnérabilités sont calculés uniquement par la règle déterministe décrite sur cette page : à données égales, le résultat est toujours le même, et l'intelligence artificielle ne les décide jamais. Nous l'utilisons pour la rédaction : avant l'envoi, un système d'intelligence artificielle vérifie chaque briefing et chaque alerte sur nos données (produits, preuves d'exploitation, dates, prérequis) et en rédige les textes. S'il trouve un signalement attribué à la mauvaise vulnérabilité, il l'exclut, et le niveau est recalculé par la règle. Si les données ne confirment pas une alerte, elle n'est pas envoyée. Briefings et alertes ne partent qu'une fois la vérification terminée : si elle n'est pas prête, l'envoi attend.

11. L'historique de l'indice

Le niveau de chaque jour est calculé avec les règles décrites sur cette page, en utilisant uniquement les données que les sources avaient publiées jusqu'à ce jour : aucune information postérieure n'entre dans le niveau d'un jour passé.

12. La vérification des résultats

Nous vérifions la méthode en comparant ses niveaux au catalogue CISA KEV, la liste des vulnérabilités dont l'exploitation réelle est confirmée. Nous mesurons combien de vulnérabilités exploitées la méthode porte au moins au niveau 3, avec quelle avance ou quel retard par rapport à la confirmation officielle, et combien de celles portées au niveau 2 ou 1 sont réellement exploitées.

La vérification se fait de deux façons, avec le catalogue parmi les sources, comme fonctionne le service, et sans lui, comme contrôle indépendant, et elle est répétée à chaque version de la méthode.

13. Limites déclarées

• Couverture des sources. Le système ne voit que ce qui est public et écrit dans les sources qu'il lit. Les attaques pas encore divulguées, ou divulguées uniquement dans des canaux fermés, ne sont pas visibles.
• Dépendance au code CVE. Les vulnérabilités sans code CVE ne sont reconnues que si elles citent un produit connu ; elles peuvent être sous-estimées. Les noms de produit qui sont aussi des mots courants (Teams, Outlook, Zoom, Entra) ne comptent qu'avec l'éditeur ou un mot qui les qualifie, comme « Microsoft Teams ». Un exploit sans CVE ne fait pas monter le niveau à lui seul : il ne compte qu'avec d'autres signaux sur le même produit.
• Reconnaissance du langage. L'exploitation active est reconnue dans les textes à des expressions explicites dans six langues (anglais, italien, français, espagnol, allemand, néerlandais) ; des formulations inhabituelles ou d'autres langues peuvent lui échapper.
• Poids et seuils. Ce sont des choix de méthode, pas des grandeurs physiques : ils sont déclarés, stables dans le temps et vérifiés a posteriori, mais une autre méthode donnerait d'autres niveaux.
• Historique des attaques. Le catalogue CISA KEV reflète les priorités du gouvernement américain et sa capacité de confirmation ; des produits très utilisés hors des États-Unis peuvent y être sous-représentés.
• Produits aux noms différents. La mise en correspondance des noms d'éditeurs et de produits entre les sources est automatique et peut se tromper dans les cas ambigus.
• Niveaux antérieurs au 1er octobre 2026. Ils dépendent de ce que les sources conservent des jours passés : certaines sources n'ont pas d'historique consultable et, pour une comparaison équitable dans le temps, les réseaux sociaux ne comptent que pour les hashtags à l'historique complet (#vulnerability, #zeroday), avec au maximum 30 mentions par jour. Les niveaux de cette période peuvent donc sous-estimer le risque.

14. Versions et modifications

La méthodologie porte un numéro de version. Chaque modification susceptible de changer un niveau est consignée ici avec sa date ; les niveaux déjà publiés ne sont pas réécrits en silence : si une nouvelle version modifie des niveaux passés, elle le déclare.

15. Utilisation et citation des données

Les niveaux quotidiens sont publics et réutilisables sous licence Creative Commons Attribution 4.0 (CC BY 4.0), en citant la source. Le fichier CSV des 12 derniers mois se télécharge depuis la page du DefenceLevel Index et contient la date, le niveau, le nom du niveau et le nombre de vulnérabilités incluses dans le briefing.

Citation suggérée : DefenceLevel Index (defencelevel.com), méthodologie v1.30, avec la date de la donnée.

Le détail de chaque vulnérabilité (noms, produits, actions recommandées) est réservé aux abonnés du briefing.