ENISA et l'IA de pointe : 5 conséquences pour le CRA

En janvier 2026, curl a fermé son programme de divulgation coordonnée des vulnérabilités. Des rapports générés par IA avaient submergé les mainteneurs, et le projet a jugé que le traitement des signalements coûtait plus qu'il ne rapportait. ENISA cite désormais cette fermeture dans une publication officielle. Voici ce qui vous concerne directement : un fabricant soumis au CRA ne peut pas faire le même choix. Le Règlement sur la cyberrésilience impose légalement un dispositif de réception des signalements de vulnérabilités à partir du 11 décembre 2027. curl a choisi la sortie. Vous n'en aurez pas.

C'est l'une des cinq collisions entre le nouveau document de position d'ENISA et vos obligations CRA. ENISA a publié en juillet 2026 sa position sur la cybersécurité à l'ère de l'IA de pointe. Les 16 pages s'adressent aux autorités nationales, aux décideurs européens, aux équipes de défense et aux prestataires de services. Aucune section n'est écrite pour les fabricants de produits. Les conséquences retombent quand même sur votre bureau.

Ce qu'ENISA a réellement publié

Le document est une note de position de 16 pages, élaborée avec le Réseau des CSIRT de l'UE et EU-CyCLONe entre mai et juin 2026. Sa mention légale précise qu'il ne crée aucune obligation réglementaire. Considérez-le comme un signal de l'orientation que prendra la doctrine opérationnelle d'ENISA, et lisez-le en parallèle des obligations CRA qui vous engagent déjà.

L'affirmation centrale est mesurable. La fenêtre entre la découverte d'une vulnérabilité et son exploitation est passée de plusieurs années à quelques mois, puis à quelques minutes. Les données citées par ENISA situent l'exploitation à 15 minutes après la divulgation et l'exfiltration médiane à 72 minutes après l'accès initial. Le NCSC-NL ajoute que les agents autonomes suppriment l'avantage de la découverte privée pour les défenseurs : une fois qu'un agent d'IA trouve une vulnérabilité, construire l'exploit relève du calcul, pas d'un projet d'ingénierie. Certains exploits existent désormais avant même le correctif, ce que le document appelle un temps d'exploitation négatif.

ENISA est franche sur l'autre versant du problème. Le document affirme que la capacité propre d'ENISA, tout comme celle des fabricants et des CSIRT nationaux, doit être renforcée ou repensée pour absorber la vague de vulnérabilités à venir. L'agence responsable de la Plateforme de signalement unique vous annonce noir sur blanc que les volumes mettront tout le monde sous tension.

Les cinq sections ci-dessous reprennent chacune un constat du document et le relient à une obligation CRA.

1. curl a fermé son guichet de vulnérabilités. Vous ne pouvez pas

Début 2026, les rapports de vulnérabilités générés par IA avaient commencé à submerger une partie du dispositif de divulgation open source. Le document nomme les dégâts : une plateforme mondiale de bug bounty a suspendu les nouvelles soumissions Internet Bug Bounty après une vague de rapports assistés par IA de qualité inégale, et curl a mis fin à son programme CVD en janvier 2026 parce que les mainteneurs ne pouvaient plus absorber le volume et le bruit. Le problème est la dilution du signal. Les relecteurs humains passent leur temps à séparer les découvertes réelles des soumissions répétitives, superficielles ou non validées.

Un projet open source peut fermer la porte. Sous le CRA, vous ne le pouvez pas. Le règlement vous impose de mettre en œuvre et de faire respecter une politique de divulgation coordonnée des vulnérabilités (CVD), et de publier une adresse de contact pour le signalement des vulnérabilités de votre produit. Les deux obligations s'appliquent à partir du 11 décembre 2027. Voici la vérité qui dérange : le CRA a été rédigé en partant du principe que les signalements sont rares et précieux. Le document décrit un monde où ils arrivent par centaines, rédigés par des machines et non vérifiés. L'obligation demeure. Le principe sur lequel elle reposait a disparu.

Votre politique CVD a donc besoin d'une clause pour l'ère de l'IA. Trois éléments doivent y figurer :

• Exigences de validation : précisez ce qu'un signalement doit contenir pour entrer en triage. Produit et version concernés, étapes de reproduction ou preuve de concept, et impact observé. Un signalement qui n'en contient pas reçoit une demande de complément, pas un créneau de triage.
• Déduplication avant le triage : les outils d'IA soumettent la même faiblesse sous des formulations multiples. Regroupez d'abord les signalements entrants avec vos constats déjà connus, et comptez des regroupements, pas des e-mails.
• Engagements de triage par gravité : publiez des délais de réponse que vous pourrez tenir à un volume dix fois supérieur à celui d'aujourd'hui. Un SLA d'accusé de réception que vous rompez chaque semaine constitue une preuve plus mauvaise qu'un engagement modeste que vous respectez.

Une nuance supplémentaire du document : ENISA note que les mois récents ont apporté une réelle amélioration de la qualité des rapports générés par IA, donc une règle générale de refus des rapports IA écarte du signal utile. Filtrez sur la complétude et la reproductibilité, pas sur l'auteur. Publier les modalités de réception via security.txt garde l'obligation de point de contact auditable.

2. L'IA gonfle ce que recouvrent « connue » et « exploitable »

Le document contient un chiffre qui change l'ingénierie de mise en production. Une organisation du secteur a indiqué à ENISA être passée d'environ 80 CVE au premier trimestre 2025 à près de 500 au premier trimestre 2026, puis à environ 500 par jour une fois passée aux outils d'IA de pointe. ENISA appelle cela la dévaluation économique de la découverte : trouver des failles s'industrialise, si bien que le volume de divulgations augmente plus vite que quiconque ne peut y remédier.

Le CRA impose qu'un produit soit mis à disposition sur le marché sans vulnérabilité exploitable connue. Deux mots portent cette règle : « exploitable » et « connue ». L'IA fait mécaniquement gonfler la seconde : chaque analyse de votre SBOM fait remonter davantage de résultats, à chaque trimestre. Ce que l'IA ne change pas, c'est la première, et c'est là que vit désormais votre preuve de conformité. Le travail de notation de gravité, qui sépare la gravité intrinsèque de la probabilité d'exploitation, cesse d'être une optimisation pour devenir le verrou de mise en production lui-même.

L'enchaînement joue dans les deux sens. ENISA avertit que les vulnérabilités à faible risque ne peuvent plus être écartées comme inoffensives, parce que les modèles les enchaînent en exploits fonctionnels. La règle de triage « CVSS faible, on ignore » est donc morte. Mais un verrou CI basé sur le simple comptage de CVE meurt aussi : à 500 résultats par jour, il bloque toute mise en production pour de bon. Ce qui survit, c'est l'exploitabilité documentée pour chaque résultat. Le document nomme les deux instruments : l'EPSS de FIRST pour la probabilité d'exploitation, et le VEX pour consigner si votre produit est concerné ou non.

3. Chaque correctif publié cartographie la faille dans vos anciennes versions

La section du document consacrée à l'exploitation des failles N-day indique que les diffs de correctifs et les changements binaires ont historiquement alimenté la rétro-ingénierie et le développement d'exploits, et que la fenêtre d'exploitation s'ouvre avant même le déploiement du correctif. L'IA de pointe réduit cette rétro-ingénierie de plusieurs jours de travail spécialisé à un simple calcul. Le document note également que l'analyse assistée par IA accélère la compréhension du code des systèmes existants.

Reportez maintenant cela sur votre propre gamme de produits. Vous publiez un correctif de sécurité pour la version N. Le diff décrit précisément la vulnérabilité. Si la version N-1 partage le code concerné et a dépassé sa fin de support, votre propre correctif devient le meilleur guide d'exploitation disponible contre votre propre parc installé. À vitesse humaine, ce risque était connu mais lent. À vitesse machine, il se matérialise le jour même.

Cela change le sens de deux décisions CRA :

• La période d'assistance, cinq ans minimum dans la plupart des cas, détermine quelles versions reçoivent encore des correctifs. Les versions en dehors de cette période ne disparaissent pas du terrain. Elles restent accessibles, et chaque correctif que vous publiez pour les versions prises en charge renseigne aussi les attaquants sur elles. La prolifération de versions est désormais une surface d'attaque, donc moins de versions prises en charge mais plus durables valent mieux que de nombreuses versions éphémères. Voir la période d'assistance pour savoir comment sa durée est fixée.
• La divulgation de fin de support que vous devez aux acheteurs avant l'achat devient une information opérationnelle, pas de la paperasse de rayonnage. Un acheteur qui dépasse la date que vous avez communiquée fait tourner un produit que votre propre flux de correctifs décrit aux attaquants. Dites-le clairement dans la divulgation. La page divulgation de fin de support précise où la date doit figurer.

Le conseil du NCSC irlandais cité dans le document est sans détour : revoir les inventaires d'actifs, prioriser la discipline de correctifs, et évaluer l'exposition aux composants non pris en charge. Pour un fabricant, l'obligation miroir consiste à empêcher que l'écart entre « branche corrigée » et « branche abandonnée » ne s'élargisse silencieusement.

4. Les correctifs écrits par IA restent livrés sous votre marquage CE

ENISA s'attend à ce que la remédiation adopte les mêmes outils que la découverte. Le goulot d'étranglement de la vérification décrit dans le document en résulte : les équipes techniques font face à un défi d'échelle pour auditer et valider les correctifs générés par IA sans qu'ils n'introduisent de nouvelles vulnérabilités dans le code. Le document décrit aussi la pression du côté opposé, un écart d'autorité où les comités de changement humains ne peuvent pas autoriser une intervention dans les quelques minutes disponibles pour contrer un exploit autonome.

Le CRA n'a pas d'avis sur qui, ou quoi, écrit votre code. Il a un avis ferme sur qui en répond. Le règlement exige des tests de sécurité efficaces et réguliers de votre produit, et la déclaration de conformité que vous signez au titre de l'évaluation de la conformité couvre chaque correctif que vous distribuez pendant la période d'assistance. Un correctif généré par IA qui ouvre une nouvelle faille est votre non-conformité, à la vitesse machine.

Conséquence pratique : votre chaîne de correctifs a besoin de preuves de test qui suivent le volume de correctifs. La relecture humaine de chaque ligne écrite par IA ne tiendra pas à 500 résultats par jour. Des tests de sécurité automatisés et documentés sur le chemin de correction, si, et ils produisent les preuves dont votre dossier technique a besoin. Si vous adoptez la remédiation assistée par IA, consignez quels correctifs sont générés par machine et quelle validation chacun a subie. Quand un régulateur demande comment vous avez tenu votre obligation de test à cette vitesse, la réponse est un journal, pas une déclaration de principe.

5. Vos signalements de vulnérabilités deviennent un historique public

La dernière conséquence est la plus discrète du document. ENISA écrit que les données corrélées de l'EUVD permettent d'identifier les points chauds de la chaîne d'approvisionnement, les faiblesses systémiques et les tendances de vulnérabilités accélérées par la découverte assistée par IA. Une phrase plus loin : les signalements liés au CRA peuvent aider à valider les allégations de durcissement des fournisseurs face à l'exploitabilité réelle et aux schémas d'incidents.

Lisez cela en tant que fabricant. À partir du 11 septembre 2026, vous signalez les vulnérabilités activement exploitées et les incidents graves dans les 24 heures via la Plateforme de signalement unique, puis un suivi sous 72 heures, puis un rapport final dans les 14 jours suivant le correctif. Chaque dépôt atterrit dans une infrastructure qu'ENISA prévoit de corréler. Avec le temps, cette corrélation devient un historique de sécurité par fournisseur : la fréquence de vos expositions, la vitesse de vos correctifs, et la façon dont votre bilan se compare à vos allégations.

Deux comportements en découlent :

• Rédigez des allégations de sécurité produit que vous pouvez défendre avec votre propre historique de signalement. « Durci » et « sécurisé dès la conception » sur une fiche produit finiront par côtoyer votre ligne EUVD. Un discours marketing qui devance les données devient un sujet de conversation avec la surveillance du marché.
• Traitez la qualité de vos signalements comme une question de réputation, pas de paperasse. Une notification précise à 72 heures avec de véritables mesures correctives se lit différemment d'une notification minimale, et l'objectif affiché d'ENISA est de réduire l'écart entre divulgation et réponse coordonnée grâce à ces données. La chaîne de signalement elle-même est entrée en service par étapes cette année, avec l'intégration par ENISA de ses premières autorités d'attribution de numéros CVE en mai 2026.

Le résumé exécutif du document indique que la SRP doit être utilisée, une fois fonctionnelle, pour répondre aux défis des nouveaux développements. ENISA s'y est engagée par écrit. Vos signalements en sont la matière première.

Cet article est fourni à titre informatif uniquement et ne constitue pas un conseil juridique. Pour des orientations spécifiques en matière de conformité, consultez un conseil juridique qualifié.