Analyse - Trop de rapports de failles, trop vite : quand l’IA sature la cybersécurité

L’intelligence artificielle est de plus en plus utilisée pour analyser du code et rechercher des failles de sécurité. Sur le papier, c’est une excellente nouvelle : une IA peut parcourir rapidement des milliers de lignes de code et attirer l’attention sur des erreurs qu’un humain aurait pu manquer.

Le problème, c’est qu’elle peut aussi se tromper. Et surtout, elle permet désormais de produire des rapports de vulnérabilités à une vitesse que les équipes chargées de les vérifier ont parfois beaucoup de mal à suivre.

Google commence à lever le pied

Google vient justement de mettre temporairement un coup de frein à son programme de récompenses consacré aux logiciels open source. Depuis le 1er octobre 2026, le groupe n’accepte plus les nouveaux signalements de certaines vulnérabilités concernant directement ses projets.

Google explique faire face à une forte augmentation des rapports automatisés, dont une grande partie ne correspond finalement pas à de véritables failles.

Un bug bounty, c’est quoi exactement ?

Le principe est assez simple. Une entreprise ou un projet propose une récompense aux chercheurs qui découvrent une vraie vulnérabilité. Mais avant d’envoyer son rapport, le chercheur est normalement censé vérifier que la faille existe réellement, qu’elle peut être reproduite et qu’elle représente un véritable risque.

Avec les outils d’IA actuels, cette étape peut parfois être contournée. Un modèle analyse le code, repère quelque chose qui lui semble dangereux, imagine un scénario d’attaque et rédige même le rapport. Le résultat peut être très convaincant à la lecture, tout en étant complètement faux.

Des rapports crédibles... mais parfois totalement faux

Une fonction considérée comme dangereuse peut par exemple être impossible à atteindre dans des conditions normales. L’IA peut également imaginer une méthode d’exploitation qui ne fonctionne pas ou inventer certains éléments manquants.

Si personne ne vérifie le résultat avant de l’envoyer, c’est alors au développeur du projet de perdre du temps à démontrer que la faille n’existe pas.

Google avait déjà commencé à durcir ses règles au printemps 2026. L’entreprise expliquait alors recevoir davantage de rapports contenant des informations incorrectes, voire des éléments entièrement inventés par les modèles utilisés. Dans certains cas, une erreur existait bien dans le code, mais elle n’avait tout simplement aucun impact réel sur la sécurité.

L’open source en première ligne

Le phénomène touche particulièrement les projets open source. Google dispose d’équipes capables de trier ces signalements, mais beaucoup de logiciels libres sont maintenus par quelques développeurs, parfois bénévolement et pendant leur temps libre.

Recevoir des dizaines de faux rapports peut rapidement devenir un problème beaucoup plus sérieux.

L’Open Source Security Foundation s’est d’ailleurs penchée sur le sujet. L’expression « AI slop » est désormais régulièrement utilisée pour désigner ces rapports produits ou fortement assistés par IA, envoyés en masse sans véritable vérification humaine.

Apache compare la situation à un déni de service

Apache a connu le problème sur ses projets de journalisation. Entre juillet 2024 et novembre 2025, 32 rapports de sécurité avaient été reçus et seulement trois avaient finalement conduit à la publication d’une véritable vulnérabilité.

Puis le rythme s’est brutalement accéléré, avec 17 rapports en décembre 2025, 20 en janvier 2026 et encore 13 en février.

Les développeurs expliquaient alors consacrer tellement de temps au traitement de ces signalements qu’ils comparaient la situation à une forme de déni de service. Non pas parce que leurs serveurs étaient attaqués, mais parce que leur temps disponible était progressivement englouti par l’analyse de rapports qui ne menaient souvent nulle part.

curl avait déjà tiré la sonnette d’alarme

Le célèbre projet curl avait lui aussi connu le problème. Son créateur Daniel Stenberg estimait en 2025 qu’environ 20 % des rapports de sécurité reçus cette année-là pouvaient être considérés comme du « AI slop ».

Début juillet, seulement environ 5 % des signalements reçus depuis le début de l’année avaient finalement débouché sur de véritables vulnérabilités.

La situation était devenue suffisamment pénible pour que curl ferme son programme de récompenses début 2026.

Mais l’histoire ne s’arrête pas là. Après avoir changé de plateforme et surtout amélioré la manière dont les rapports étaient filtrés, le projet constatait quelques semaines plus tard que les signalements de mauvaise qualité étaient devenus beaucoup moins problématiques.

L’IA n’est pas forcément le problème

C’est un point important : l’intelligence artificielle n’est pas forcément le problème en elle-même. Elle peut aussi réellement aider un chercheur à découvrir une vulnérabilité.

Si une IA repère une faille, que celle-ci est ensuite vérifiée par un humain et qu’un rapport sérieux est envoyé, personne ne va se plaindre de la méthode utilisée.

Le souci apparaît surtout lorsqu’on automatise toute la chaîne. Il devient aujourd’hui possible de scanner un grand nombre de projets, de demander à une IA de produire automatiquement un rapport pour chaque comportement suspect et d’envoyer le résultat sans réellement le tester.

Quand la récompense pousse à envoyer toujours plus

Et lorsqu’une récompense financière est à la clé, la tentation existe forcément. Envoyer cent rapports générés automatiquement en espérant que l’un d’entre eux soit valable demande beaucoup moins de travail que de passer plusieurs jours à étudier sérieusement une seule faille.

Le résultat est assez pervers : les vrais chercheurs risquent d’être noyés dans une masse de rapports générés automatiquement, tandis que les équipes de sécurité doivent consacrer davantage de temps au tri qu’à la correction des véritables problèmes.

Des IA pour filtrer les rapports générés par des IA ?

Les programmes de bug bounty vont donc probablement devoir évoluer. Demander une preuve de concept qui fonctionne réellement, effectuer davantage de vérifications automatiques ou filtrer les rapports identiques pourrait devenir indispensable.

On pourrait même arriver à une situation assez ironique : utiliser de l’intelligence artificielle pour trier les rapports de vulnérabilités générés... par d’autres intelligences artificielles.

Le vrai problème reste le temps humain

Au fond, le problème est assez simple. L’IA permet désormais de produire des signalements de sécurité presque sans limite. Mais le temps des humains chargés de déterminer lesquels correspondent à de véritables failles reste, lui, très limité.

Utilisée correctement, l’intelligence artificielle peut devenir un outil formidable pour améliorer la sécurité des logiciels. Utilisée comme une machine à envoyer des rapports à la chaîne, elle risque surtout de faire perdre du temps à ceux qui essaient réellement de les sécuriser.

Sources

Google Bug Hunters — OSS VRP : mise à jour des règles face aux rapports assistés par IA
OpenSSF — travaux sur les signalements de vulnérabilités générés avec l’aide de l’IA
OpenSSF — rapport du groupe consacré à la divulgation des vulnérabilités
Apache Log4j — retour des mainteneurs sur l’afflux de rapports de sécurité
Daniel Stenberg / curl — Death by a thousand slops
Daniel Stenberg / curl — High-Quality Chaos
BleepingComputer — Google suspend une partie de son programme open source face au spam généré par IA