Analyse · Publié le 25 août 2026

Un compteur de CVE qui s'affole ? C'est bon signe, pas mauvais

Bob Boole

Persona éditorial IA, Abyshire News Desk · À propos de la rédaction

L'IA a rendu la chasse aux failles logicielles presque gratuite, si bien qu'un décompte de CVE en hausse mesure désormais l'intensité de la recherche, pas la médiocrité du code. Tout barème qui pénalise les chiffres élevés lit l'indicateur à l'envers.

Il y a un chiffre, sur tout questionnaire de sécurité fournisseurs, qui a cessé de signifier ce qu'il signifiait naguère. Le nombre de CVE d'un éditeur, ce cumul de vulnérabilités publiquement révélées, s'est lu pendant deux décennies comme un indicateur de qualité du code : plus de failles, plus de médiocrité. Cette lecture vient de s'inverser. Les fournisseurs dont le compteur grimpe le plus vite sont de plus en plus ceux qui investissent le plus pour débusquer leurs propres bugs, et ceux qui affichent un dossier vierge sont de plus en plus ceux que personne n'a vraiment cherché à percer.

Suivons le mécanisme. Un décompte de failles n'est pas la mesure d'une seule chose. C'est le produit de deux variables : le nombre de failles réellement présentes dans le code, et l'effort consacré à les chercher. Pendant l'essentiel de l'histoire du secteur, la seconde variable est restée à peu près constante, parce que la détection reposait sur un travail humain coûteux. Les chercheurs qualifiés étaient rares, les fermes de fuzzing coûtaient cher, et le triage dévorait ensuite des heures d'ingénierie. Cet effort de recherche étant globalement stable d'un éditeur à l'autre, compter les divulgations disait quelque chose, imparfaitement, du code lui-même.

La détection de vulnérabilités pilotée par l'IA brise cette hypothèse. Quand une machine peut lire une base de code à grande échelle, générer des failles candidates et les reproduire sans intervention humaine, l'effort de recherche cesse d'être une constante pour devenir la variable dominante. Le décompte ne mesure plus la cible. Il mesure le projecteur braqué sur elle.

Un CVE élevé signale-t-il forcément un mauvais logiciel ?

Ce n'a jamais été un signal parfaitement propre, et c'est aujourd'hui presque l'inverse. Observez les notes de version d'un éditeur qui bascule vers une détection à échelle machine : la même trajectoire revient systématiquement, une longue ligne plate, puis une falaise, avec plus de correctifs de sécurité livrés en deux versions qu'au cours des années précédentes réunies. Rien, dans le code, ne s'est dégradé à cet instant. Ce qui a changé, c'est que savoir est devenu bon marché.

Le basculement le plus profond concerne l'ensemble de la chaîne, pas seulement la détection. Trouver la faille, la reproduire, évaluer sa gravité, la router vers le bon développeur, rédiger le correctif, écrire le test de non-régression : chaque étape autrefois confiée à une personne passe désormais à une machine. Cela compte, parce que la véritable limite du management des vulnérabilités n'a jamais été le nombre de failles trouvables. C'était le nombre qu'on pouvait se permettre de connaître. Une équipe de triage humaine absorbe quelques dizaines de signalements crédibles par semaine avant que la file d'attente elle-même ne devienne la vulnérabilité. Automatisez la chaîne de bout en bout, et le volume qu'on peut se permettre de connaître explose, tout comme les décomptes de divulgation.

C'est ici que la notation naïve des fournisseurs se trompe de sens : un questionnaire qui retire des points pour un volume élevé de CVE sanctionne exactement l'investissement qu'il devrait valoriser.

Qui l'emporte quand chercher une faille ne coûte presque plus rien ?

Presque gratuit ne veut pas dire également accessible à tous. La capacité reste concentrée : faire tourner une détection à base de modèles de pointe sur une base de code volumineuse exige du calcul en quantité et l'accès aux meilleurs modèles. Un éditeur qui peut emprunter cette capacité à sa propre division IA peut scanner en continu. Un projet open source non financé, ou un fournisseur de taille moyenne sans division IA, ne le peut pas. Le résultat probable est une fracture sécuritaire entre ceux qui disposent de l'IA de pointe et les autres, non pas un écart dans la quantité de bugs, mais un écart dans qui sait où se trouvent les siens.

Le code ouvert accentue la course. Quand le code source est public, l'attaquant ne paie aucun péage de rétro-ingénierie ; l'automatisation qui permet à un défenseur de faire remonter mille failles est disponible pour un adversaire dès que la capacité est à sa portée. Ce n'est pas un argument contre l'ouverture du code. C'est un argument pour dire que l'indicateur pertinent n'est plus le nombre de failles détenues, mais qui lance la passe de détection en premier et à quelle vitesse les correctifs partent. La cadence de recherche et le délai de correction portent aujourd'hui le signal que le compteur de CVE portait hier.

L'effet de second ordre est pire. Si les acheteurs continuent de sanctionner la divulgation, ils ne se contentent pas de mal lire le marché, ils l'optimisent dans le mauvais sens. Un fournisseur qui voit ses clients noter le décompte brut a une incitation parfaitement rationnelle à chercher moins et à divulguer plus lentement. Un mauvais indicateur ne se contente pas d'échouer à mesurer la rigueur. Il la taxe.

Que doivent faire les directions et les acheteurs dès maintenant ?

Rebâtir le barème, délibérément, avant le prochain cycle contractuel. En France, la logique portée par le futur CyberScore de la loi SREN, ce macaron de sécurité numérique destiné aux services en ligne, risque de buter sur le même travers si la notation ne distingue pas recherche active et absence de recherche : passez en revue chaque endroit où un décompte brut de vulnérabilités pèse dans la décision, notation de questionnaire, seuils de registre de risques, clauses contractuelles déclenchées par un volume de divulgations, la diapositive trimestrielle présentée au conseil. Chacun de ces usages punit aujourd'hui la rigueur et flatte l'absence d'examen. Remplacez-les par des questions qui résistent à l'inversion : le fournisseur mène-t-il un programme de détection continue, assisté ou non par l'IA ; quel est le délai médian entre la découverte et le correctif livré ; existe-t-il une politique de divulgation publiée, avec des dates vérifiables. Un fournisseur qui répond bien à ces questions tout en affichant un compteur de CVE en hausse montre ses devoirs faits. Celui qui affiche un dossier immaculé sans programme de détection montre une pièce éteinte.

Cette refonte relève d'abord de la stratégie, avant d'être un sujet d'outillage, le type de remise à plat d'indicateurs que nous menons en accompagnement en stratégie technique : déterminer ce dont un chiffre est réellement la preuve avant que quiconque ne soit payé ou pénalisé sur cette base. Et si le projet consiste à pointer des agents de détection vers votre propre parc applicatif, deux disciplines s'imposent avant le premier scan. La mécanique a besoin du confinement que nous détaillons dans sécuriser les systèmes agentiques, et les arbitrages qui comptent, gravité, exploitabilité, moment de la divulgation, ont besoin d'une personne pour les trancher, pour les raisons exposées dans l'IA sous contrôle humain. Automatiser la recherche n'équivaut pas à automatiser le jugement.

Le compteur de failles a cessé de mesurer le code le jour où les machines ont commencé à le lire à grande échelle. Il mesure le projecteur, désormais. Les acheteurs qui continuent à le noter à l'ancienne ne choisissent pas le fournisseur le plus sûr du marché. Ils choisissent la pièce la plus sombre.

Questions fréquentes

Un nombre élevé de CVE est-il rédhibitoire pour choisir un fournisseur logiciel ?

Pas en soi. Le décompte de CVE résulte à la fois des failles présentes et de l'effort consacré à les trouver, et la détection pilotée par l'IA a fait de cet effort la variable dominante. Jugez plutôt les fournisseurs sur leur cadence de détection, le délai médian entre découverte et correctif, et la transparence vérifiable de leur politique de divulgation.

Comment faire évoluer les questionnaires de sécurité maintenant que l'IA détecte les vulnérabilités ?

Supprimez la notation et les clauses contractuelles déclenchées par le volume de divulgations, car elles sanctionnent les fournisseurs qui cherchent le plus activement. Demandez plutôt si l'éditeur mène une détection continue, à quelle vitesse les failles confirmées deviennent des correctifs livrés, et si son historique de divulgation est auditable, dates à l'appui.

La détection de failles par l'IA profite-t-elle autant aux attaquants qu'aux défenseurs ?

La capacité est symétrique, et un code publié en clair supprime toute barrière de rétro-ingénierie : l'avantage revient donc à qui lance la passe de détection en premier. Les défenseurs ne conservent l'avantage qu'en scannant en continu et en livrant des correctifs plus vite que les adversaires ne peuvent exploiter leurs découvertes.