# Un constat n'est pas un verdict

> L'IA peut désormais générer des milliers de constats de vulnérabilité en un après-midi. Un constat est un témoin, pas un verdict — et le seul champ que personne ne peut vérifier est celui que tout le monde gonfle. Voici comment lire le flot sans s'y noyer.

Source: https://counterproof.io/fr/notes/un-constat-nest-pas-un-verdict/ · Published 25 August 2026 · CounterProof est une pratique de Clavestra Capital Limited (Malte, C 113987).


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*](https://counterproof.io/fr/notes/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 :

1. **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.
2. **Est-il atteignable dans votre build, ou atteignable en principe ?** Une gravité sans argument
   d'atteignabilité est une humeur, pas une mesure.
3. **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.
4. **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](https://counterproof.io/notes/we-withdrew-our-own-number/) (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](https://research.counterproof.io/) (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.*