L'IA trouve des failles, puis laisse le tri aux humains

Une vulnerabilite trouvee par IA ne devient pas automatiquement une alerte utile. Elle devient d’abord une ligne de plus dans une file d’attente. C’est moins spectaculaire qu’un modele qui ecrit un exploit, mais c’est le point ou les organisations se cassent deja les dents.

Le rapport publie par ENISA le 7 juillet 2026 sur la cybersécurite a l’ere de l’IA de frontiere decrit un monde ou certaines attaques, certaines decouvertes et certaines adaptations peuvent se produire a vitesse machine. Le vocabulaire attire naturellement l’oeil vers l’offensive : des modeles capables d’aider a chercher des failles, a automatiser des chaines d’attaque, a produire des variantes. Pourtant, la partie la plus concrete pour une entreprise moyenne est plus grise. Si tout le monde peut produire plus de signalements, plus vite, le premier systeme critique devient le systeme de tri.

Une PME qui entend “l’IA trouve des failles” imagine souvent deux options. Soit elle s’en felicite : les bugs vont sortir plus tot. Soit elle s’inquiete : les attaquants vont aller plus vite. Les deux lectures sont vraies, mais incompletes. Le risque ordinaire n’est pas seulement qu’une faille soit trouvee. C’est qu’une equipe reduite ne sache plus distinguer, a temps raisonnable, un signal exploitable d’une simulation fragile, d’un doublon, d’un faux positif ou d’un rapport gonfle par un outil.

Le signal n’est pas la preuve

Le cas curl est devenu un raccourci utile parce qu’il est brutal. Le projet a mis fin a son programme de bug bounty au 31 janvier 2026. Dans son billet, Daniel Stenberg explique que le taux de rapports confirmes s’est effondre et que le bruit, notamment les rapports assistes par IA, consommait trop d’energie. Ce n’est pas un petit outil marginal. curl est partout : postes de developpeurs, serveurs, conteneurs, scripts internes, produits embarques.

Le point important n’est pas “curl refuse la securite”. C’est l’inverse : une equipe qui prend la securite au serieux peut decider qu’un canal mal calibre degrade sa capacite a traiter les vrais problemes. Si chaque rapport demande une lecture, une reproduction, une discussion et parfois une defense argumentee contre une conclusion hallucinee, alors le cout du tri devient une surface d’attaque organisationnelle.

HackerOne indique de son cote que l’Internet Bug Bounty est en pause pour les nouvelles soumissions depuis le 27 mars. La raison publique tient en peu de mots : le programme prend une pause. Le contexte, lui, est clair dans l’ecosysteme : les grands canaux ouverts doivent absorber plus de rapports, avec une qualite tres variable. Un programme public n’est pas une adresse email magique. C’est une promesse de lecture.

Pour une PME, cette nuance change tout. Recevoir un rapport de vulnerabilite n’est pas recevoir une correction. C’est recevoir une obligation de verifier.

La verification devient le travail

La plupart des entreprises n’ont pas une equipe dediee capable de reproduire dix signalements par jour. Elles ont un responsable IT, un prestataire, parfois un developpeur qui connait le vieux module de facturation, et un dirigeant qui veut savoir si l’entreprise doit interrompre une livraison. Dans ce contexte, l’IA ne supprime pas le goulet. Elle le deplace.

Avant, le probleme visible etait la rarete : peu de tests, peu de retours, peu de temps. Demain, le probleme visible peut etre l’abondance : trop de sorties d’outils, trop de captures d’ecran, trop de chaines d’exploitation plausibles mais non prouvees. Le mot “plausible” est le piege. Une faille plausible n’est pas une faille prioritaire. Une faille prioritaire a un actif touche, une condition d’exploitation, une preuve reproductible et un impact metier.

Les modeles d’IA excellent souvent a produire une forme convaincante. Ils savent ecrire un rapport structure, nommer une categorie OWASP, proposer un niveau de severite, ajouter une remediation generique. Cela ne veut pas dire que le rapport est faux. Cela veut dire que la forme ne suffit plus comme filtre de competence.

Le tri doit donc descendre d’un niveau. La question n’est pas : “ce rapport ressemble-t-il a un vrai rapport ?” La question est : “quelle preuve minimale nous permet de passer de la lecture a l’action ?”

Le bon canal est plus petit qu’on ne croit

La reponse paresseuse serait d’ajouter une boite security@, une page “responsible disclosure”, puis d’attendre. C’est souvent pire que rien si personne ne sait quoi faire derriere. Un canal de signalement sans regle de traitement fabrique une dette de securite visible : des personnes vous ont alerte, vous avez accuse reception, puis vous n’avez pas tranche.

Le canal minimal tient en quatre decisions.

D’abord, nommer un proprietaire. Pas un comite. Une personne ou un prestataire qui decide si le rapport entre en triage, part en doublon, demande une reproduction ou se ferme. Ensuite, publier une exigence de preuve courte : version touchee, etapes de reproduction, compte de test si necessaire, impact observe, limites a ne pas franchir. Puis definir une echelle de severite interne, pas seulement CVSS : une fuite de donnees client n’a pas le meme poids qu’un bug d’affichage, meme si les deux sont presentes avec le meme ton alarmiste. Enfin, garder un journal des decisions. Le journal protege autant l’entreprise que le chercheur serieux.

Cette discipline parait administrative. Elle est technique. Sans elle, chaque signalement redemarre la discussion depuis zero.

Les agents compliquent encore le tri

Le NIST a lance en fevrier 2026 une initiative sur les standards pour agents IA, avec un accent sur l’identite, l’autorisation, l’interoperabilite et la securite. OWASP, de son cote, a publie un Top 10 pour applications agentiques. Ces documents ne parlent pas seulement d’un futur exotique. Ils decrivent le prochain etage du probleme : des systemes qui n’appellent plus seulement un modele, mais des outils, des API, des bases internes et parfois d’autres agents.

Dans une application classique, un rapport de faille vise souvent une route, un parametre, un role, une dependance. Dans une application agentique, le rapport peut viser un objectif detourne, un outil appele au mauvais moment, une identite trop large, une memoire polluee, une delegation confuse. Le tri devient moins mecanique, parce que l’erreur se situe parfois dans une sequence d’actions et non dans une ligne de code.

Cela ne veut pas dire qu’il faut attendre les standards parfaits. Cela veut dire qu’il faut refuser de brancher des agents sur des droits flous. Si un agent a le droit de lire des tickets, creer des devis, envoyer des emails et modifier un CRM, alors un rapport de faille ne peut plus etre juge seulement sur “le modele a repondu ceci”. Il faut savoir quels outils etaient disponibles, quelles permissions etaient actives, quel journal d’execution existe, quelle validation humaine etait requise.

Le tri commence donc avant le premier rapport. Il commence au moment ou l’on limite ce que le systeme peut faire.

Ce qu’une PME peut faire cette semaine

La bonne nouvelle est que la premiere reponse ne demande pas une plateforme de securite neuve. Elle demande une procedure courte et testable.

Prenez un service expose : site web, portail client, API partenaire, application interne accessible a distance. Ecrivez une page privee de tri en une demi-heure. Qui recoit ? Qui decide ? Quelle preuve exige-t-on ? Quel delai de premiere reponse est realiste ? Quels tests sont interdits parce qu’ils peuvent casser la production ? Ou note-t-on les doublons ? Qui peut couper un acces en urgence ?

Ensuite, faites un exercice avec un faux rapport. Pas un audit complet. Un seul rapport plausible, volontairement imparfait. Demandez a l’equipe de le classer. Si personne ne sait qui doit repondre, vous venez de trouver le vrai risque. Si tout le monde debat de la severite avant meme d’avoir reproduit l’observation, vous avez trouve le deuxieme. Si la seule personne capable de verifier est indisponible, vous avez trouve le troisieme.

Le but n’est pas de ralentir la securite. C’est de reserver l’attention humaine aux signaux qui meritent l’attention humaine. L’IA peut aider a regrouper les doublons, reformuler un rapport, chercher une dependance connue, suggerer une reproduction. Elle ne doit pas devenir le juge final de l’impact.

Le vieux metier du doute

La cybersécurite a toujours ete un metier de doute. L’IA n’en change pas la nature. Elle change le volume, la vitesse et le degre de polissage des messages entrants. C’est plus difficile parce que le bruit a appris a ressembler au signal.

Le reflexe mature n’est donc pas de fermer toutes les portes, ni d’ouvrir toutes les boites. C’est de construire un tamis. Peu de categories, peu de promesses, beaucoup de clarte. Une preuve reproductible passe. Une hypothese reste une hypothese. Un rapport sans impact documente attend. Un signalement critique avec donnees exposees reveille quelqu’un.

Les entreprises qui traiteront l’IA comme une machine a trouver des failles seront surprises par la fatigue. Celles qui la traiteront comme une machine a produire du tri a verifier auront une chance de garder leur calme.

La difference n’est pas philosophique. Elle tient dans une file d’attente qui ne deborde pas.