En environ 108 heures de temps machine, en août 2026, une seule campagne bénévole a fait passer un modèle à poids ouverts sur 501 projets open source de l’écosystème Bitcoin et a consigné 7 958 constats de sécurité potentiels, dont 1 280 classés élevés ou critiques. Nous avons raconté cette campagne — et le règlement avec lequel elle entre en collision — dans Les machines lisent le code. Cette note porte sur le chiffre lui-même.
Car un fournisseur de sécurité a publié un banc d’essai opposant trois systèmes de revue de code par IA à une application de test privée : l’un a trouvé 68 des 89 vulnérabilités implantées, un autre 60, un troisième 58. Les fournisseurs se font désormais concurrence sur ce ratio — plus de constats, à moindre coût. Trouver est devenu une marchandise dans une guerre des prix.
Il vaut donc la peine de dire clairement ce qu’est réellement un constat — car le décompte mesure la mauvaise chose.
Un constat est un témoin, pas un verdict
La philologie a réglé cela il y a cinq siècles, et son mot est exact.
Quand un texte ancien survit dans de nombreux manuscrits copiés à la main, aucune copie n’est le texte. Chacune est un témoin : un document dérivé portant l’original — plus les lapsus, les habitudes et la dérive héritée de son copiste. Que trois manuscrits s’accordent peut signifier que la leçon est authentique — ou que les trois descendent du même exemplaire fautif. La discipline qui démêle cela produit une édition critique : le texte tel qu’on peut au mieux l’établir, avec, dessous, un apparat consignant chaque témoin pesé, chaque variante, chaque jugement éditorial et ses raisons.
Un constat de vulnérabilité généré par IA est un témoin exactement en ce sens. Il n’est pas le défaut. Il est le rapport d’un modèle sur un défaut — les propriétés réelles du code, mêlées aux habitudes du modèle, à sa lignée d’entraînement et au prompt qui l’a produit. Que deux scanners s’accordent peut signifier que le bug est réel — ou que les deux partagent les mêmes angles morts et les mêmes gabarits. Entraînés sur un corpus public largement commun, c’est souvent le cas. L’accord de témoins corrélés est une preuve sur les témoins, pas sur le code.
Et la règle la plus durement acquise des philologues se transfère intacte : la leçon fluide est la leçon suspecte. Les copistes lissent un passage difficile en cliché commode, et la version lisse est plus souvent l’amélioration du copiste que les mots de l’auteur. Un rapport de vulnérabilité a un genre fixe : titre, classe de faiblesse, gravité, une citation, un paragraphe « un attaquant pourrait… ». Un modèle de langage produit cette forme de façon convaincante — que le défaut existe ou non. Le poli ne porte aucune information sur la vérité. Dans ce genre, la fluidité n’est pas un titre de créance. C’est la chose à vérifier.
Voilà pourquoi le décompte est la mauvaise unité. Il compte des témoins et les déclare verdicts.
La gravité est l’endroit où les rapports exagèrent
L’inflation n’est pas uniforme. Elle se concentre en un point, pour une raison structurelle qui mérite d’être nommée.
« Cette fonction compare un horodatage en millisecondes à une colonne en précision seconde » est une affirmation qui cite quelque chose — un fichier, une ligne, un commit. On peut l’ouvrir et la trancher en une minute. « Critique » ne cite rien. Aucune ligne de code ne porte la mention Critique. La gravité est un jugement sur l’atteignabilité, l’exploitabilité et le rayon d’impact — et parce qu’elle n’a aucun ancrage dans la source, c’est exactement là qu’un générateur fluide dérive vers le haut sans contrepoids. La lecture dramatique est la plus facile ; chaque incitation de la chaîne de signalement récompense le chiffre le plus gros ; et rien dans l’artefact ne résiste.
Quand une campagne annonce donc 1 280 constats « élevés ou critiques », la lecture honnête est : 1 280 constats qu’un générateur a étiquetés ainsi. L’étiquette est le champ le moins vérifiable du document — et c’est elle qui porte le gros titre.
Sont-ils exploitables ? Personne ne l’a encore dit
Entre un constat et un défaut se trouve une étape que le décompte saute : l’appréciation — décider quels constats sont réels, lesquels sont atteignables, lesquels comptent. Cette étape reste humaine, et elle ne suit pas l’échelle de la génération.
La mesure publique la plus claire de ce qui arrive quand on la saute vient de curl. Son équipe de sécurité bénévole de sept personnes a vu la part des signalements de vulnérabilité confirmés tomber de plus de 15 % à moins de 5 % à l’arrivée des soumissions assistées par IA — chaque signalement infondé coûtant toujours des heures à réfuter. L’un est arrivé complet, avec sessions GDB et vidages de registres, pour un exploit HTTP/3 dans une fonction qui n’existe pas dans curl. Son mainteneur a décrit la charge de triage comme équivalant à un DDoS (« tantamount to a DDoS »), et le projet a fini par fermer son programme de bug bounty — en déclarant n’avoir jamais vu un seul signalement de sécurité valide produit avec l’aide de l’IA.
Lisez ce chiffre dans le bon sens. Il ne prouve pas que les constats d’IA sont sans valeur — il prouve que la fluidité d’un constat et sa validité sont indépendantes, et que lorsqu’on retire l’étape d’appréciation, le rapport signal-bruit s’effondre. Les signalements sont devenus plus nombreux et plus assurés ; la fraction qui survivait à la vérification a baissé.
Le flot est un problème de sécurité, pas un désagrément
Il est tentant de classer « trop de constats » parmi les nuisances. Ce serait une erreur. Quand la génération distance l’appréciation, le vrai constat ne disparaît pas — il gît enseveli dans la file derrière deux cents constats plausibles, et une file que personne ne peut vider est une file qui cache des choses. Le mot de curl — DDoS — est le bon registre. Une équipe qui se noie dans des signalements assurés n’est pas plus sûre qu’une équipe sans signalements ; c’est une équipe dont l’attention a été épuisée sur des témoins jamais contre-interrogés.
Tenir les deux alarmes séparées
Deux affirmations se confondent ici, et les séparer est toute la discipline.
En agrégat, le danger est réel. Il existe véritablement d’énormes quantités de défauts non corrigés dans du vieux code, et un chercheur bon marché et infatigable en fera remonter une partie. Balayer toute la catégorie comme du battage est faux.
Par constat, la criticité déclarée est systématiquement surévaluée — vers le haut, parce que le seul champ que personne ne peut vérifier est celui que tout le monde gonfle. Traiter chaque alerte comme un verdict est faux aussi — dans l’autre sens.
L’erreur consiste à répondre à la question de l’une avec l’alarme de l’autre. « Beaucoup de vrais bugs existent quelque part dans cet écosystème » ne rend pas ce constat, sur votre ligne, exploitable. Et « la plupart de ces alertes-ci sont du bruit » ne signifie pas que votre base de code est propre.
Ce qui voit clair
L’éditeur médiéval ne pouvait pas décontaminer toute la tradition. Ce qu’il pouvait faire : attacher des conditions à chaque leçon et rendre ces conditions explicites. Le même geste fonctionne ici. Quand on vous tend un constat, demandez :
- Quel échelon de preuve atteint-il réellement ? Tracé dans la source, compilé, testé, ou reproduit en exécution — ce ne sont pas la même affirmation. Un constat ne devrait jamais porter une certitude supérieure au travail qui le fonde.
- Est-il atteignable dans votre build, ou atteignable en principe ? Une gravité sans argument d’atteignabilité est une humeur, pas une mesure.
- A-t-il été apprécié, ou moyenné ? Trois outils d’accord ne font pas trois confirmations si les outils partagent un angle mort. Un constat minoritaire vaut une vérification d’oracle bon marché — exécuter le test, lire la spécification, parcourir le chemin — pas un vote.
- Est-il déjà corrigé, ou déjà connu ? Un constat que les mainteneurs ont clos le mois dernier est un témoin de l’histoire, pas de votre risque.
Rien d’exotique là-dedans. C’est ce qu’une édition critique fait d’une pile de manuscrits : collationner les témoins, les apprécier contre une preuve plus forte qu’une opinion de plus, et garder l’apparat — les jugements, l’incertitude, les leçons considérées et rejetées.
Tous les constats morts ne sont pas morts de la même mort
La plupart des constats ne survivent pas. C’est normal, et c’est le but — mais comment un constat est mort est une information, et une revue qui les verse tous dans un même bac étiqueté « rejetés » a jeté cette information.
La philologie sépare les cas, et la distinction est assez ancienne pour porter un nom. Un manuscrit dont on démontre qu’il a été copié sur un autre manuscrit conservé est rayé du compte — eliminatio codicum descriptorum — non parce qu’il serait faux, mais parce qu’il n’apporte aucun témoignage indépendant. Son accord n’a jamais été une preuve.
Trois morts, et elles ne signifient pas la même chose :
- Redondant. Plusieurs outils ont produit le même constat. Là où ces outils ne sont pas indépendants — et, partageant données d’entraînement et gabarits, ils ne le sont souvent pas —, leur accord est une leçon en trois copies plutôt que trois confirmations ; la compter trois fois est la manière dont se fabrique la fausse confiance. Rayez les doublons, mais consignez l’hypothèse d’indépendance au lieu de la supposer acquise : l’accord de relecteurs véritablement indépendants n’est pas rien.
- Faux. Le constat affirme que le code fait quelque chose que le code ne fait pas. Tranché en ouvrant le fichier. C’est la seule catégorie que la plupart des gens ont en tête quand ils disent « faux positif ».
- Vrai, mais sur un texte qui n’existe plus. Le constat est exact — sur une révision corrigée depuis. Le témoin est honnête ; le code a bougé sous lui. Un défaut clos à une révision amont épinglée n’est pas un faux positif pour cette révision et ne devrait pas être enregistré comme tel. Cela ne tient que si le constat dit quelle révision il a lue : un rapport incapable de nommer sa révision n’est pas un témoin honnête d’un texte dépassé — c’est une affirmation périmée sur le texte actuel.
Seule la deuxième est une erreur de la leçon elle-même ; le cas non épinglé de la troisième est une erreur de la chaîne qui l’a rapportée. Un dossier qui dit de quelle mort chaque constat est mort peut être audité par quelqu’un qui n’était pas là. Un ratio — « nous avons trié deux cents constats jusqu’à six » — ne le peut pas, et ce n’est pas non plus un signal de qualité : une chaîne paresseuse atteint ce ratio en générant des rebuts et en les jetant. L’élimination n’est pas le produit. La preuve derrière les survivants l’est.
À quoi sert une édition
La raison de construire une édition plutôt qu’une liste : quelqu’un doit rendre un verdict, et ce ne sera pas le relecteur.
Un mainteneur décide s’il faut corriger. Un fabricant décide ce qui entre dans la documentation technique. L’équipe de sécurité d’un client entreprise décide si elle signe. Chacun d’eux rend un verdict, et chacun se verra demander plus tard — par quelqu’un de moins amical, avec plus de temps — de montrer comment il l’a rendu. Ce dont ils ont besoin de la part d’un relecteur, ce n’est pas d’une opinion de plus à peser. C’est de la preuve, ordonnée de sorte que leur propre décision survive à la question.
En Europe, cela passe de bonne pratique à exigence légale. Le Cyber Resilience Act exige des fabricants qu’ils « soumettent régulièrement les produits comportant des éléments numériques à des tests et examens de sécurité efficaces » (annexe I, partie II, point 3)), et la documentation technique doit contenir « les rapports des essais effectués pour vérifier la conformité … » (annexe VII, point 6)) — tenus à disposition pendant au moins dix ans après la mise sur le marché, ou pendant la période d’assistance si elle est plus longue (article 13, paragraphe 13). La notification, au titre de l’article 14, des vulnérabilités activement exploitées et des incidents graves commence le 11 septembre 2026 ; le règlement s’applique intégralement à partir du 11 décembre 2027.
Lisez ce qui est réellement demandé. Ni un scan propre, ni un chiffre bas. Un rapport d’essais effectués, conservé une décennie, lisible par quelqu’un qui n’était pas dans la pièce. Une liste de constats aux gravités assurées, sans apparat dessous ni trace de ce qui a été rejeté et pourquoi, ne survit pas à cette lecture. Une édition, si — parce que chaque affirmation nomme la preuve qui la fonde, chaque leçon éliminée est consignée avec sa raison, et chaque correction se fait par écrit.
Les obligations pèsent sur le fabricant, pas sur un relecteur externe. Une revue externe du type décrit ici vient à l’appui de la documentation technique que vous assemblez ; elle n’est pas le dossier complet, et elle ne remplace pas l’évaluation de la conformité par un organisme notifié là où le règlement en exige une. Mais elle est la partie de ce dossier la plus difficile à produire sur votre propre travail — car la seule propriété qu’elle doit porter est que quelqu’un d’autre que vous l’a écrite.
Pourquoi cela nous concerne
Chez CounterProof, nous pratiquons la revue adversariale de code écrit par des machines, et ces questions ne sont pas théoriques pour nous — ce sont nos règles de fonctionnement. Les constats sont appréciés plutôt que moyennés ; chaque affirmation nomme l’échelon de preuve qu’elle a atteint, et aucun de plus ; un constat déjà corrigé en amont est retiré plutôt que compté ; et quand l’une de nos propres affirmations ne survit pas, nous la rétractons par écrit, publiquement (en anglais). Nous ne vendons pas un nombre de constats, et nous vous conseillerions de ne pas acheter sur cette base. Les scanners sont des copistes, et le scriptorium tourne désormais jour et nuit pour trois fois rien. La denrée rare n’a jamais été la copie. C’est l’édition.
L’argument long — y compris la forme conditionnelle de chaque affirmation ci-dessus et les limites de notre propre méthode — figure dans notre document de travail sur la collation et la provenance du texte généré par des machines, lisible en intégralité ici (en anglais). C’est une prépublication à l’état de brouillon, non relue par des pairs, et elle le dit.
Les chiffres ci-dessus sont sourcés : la campagne sur 501 projets est documentée dans notre note antérieure ; les ratios du banc d’essai des trois systèmes proviennent du billet publié par le fournisseur ; le taux de confirmation de curl, le signalement de la fonction fantôme et la fermeture de son programme de bounty sont rapportés par The New Stack, BleepingComputer et The Register. Les citations du Cyber Resilience Act renvoient au règlement (UE) 2024/2847 dans sa version linguistique française officielle — les mêmes références que nous portons sur notre page d’accueil. Là où une affirmation est notre inférence plutôt qu’un constat cité — que la gravité s’inflationne vers le haut, que fluidité et validité sont indépendantes —, nous l’avons dit. Cette page est une traduction de l’original anglais ; en cas de divergence, l’original prévaut. Si quelque chose est faux ici, nous le corrigerons par écrit sur cette page.