ENISA à ESET World : « plus aucune raison d'ignorer une vulnérabilité » — ce que le Cyber Resilience Act impose dès septembre 2026

Lors d'ESET World à Berlin, le 19 mai 2026, Hans de Vries, Chief Cybersecurity and Operational Officer de l'ENISA, a posé une équation sans détour : avec les outils de détection dopés à l'IA disponibles aujourd'hui, plus aucune entreprise ne peut prétendre avoir ignoré une faille dans son code. Et le Cyber Resilience Act (CRA), dont la première salve d'obligations entre en application le 11 septembre 2026, transforme cette capacité technique en obligation juridique.

Ce qui s'est passé

« Il n'y a aujourd'hui plus aucune raison pour qu'une entreprise dise : « je ne savais pas que mon application avait une faille » — parce qu'on peut maintenant la voir et la corriger en temps réel », a déclaré Hans de Vries devant l'auditoire d'ESET World. Le constat s'appuie sur l'arrivée massive en 2026 de modèles frontières capables d'analyser, identifier et patcher du code à une vitesse inédite, notamment Claude Mythos d'Anthropic et GPT-5.5-Cyber d'OpenAI.

Le dirigeant de l'ENISA a été plus loin : « Faire de la sécurité par conception et par défaut, c'est aujourd'hui la condition pour avoir le droit d'exercer une activité. Si vous ne le faites pas, votre adversaire l'utilisera contre vous, et vous serez poursuivi parce que vous auriez dû voir le problème en premier. »

À ses côtés, Paul Chichester, directeur des opérations du NCSC britannique, a nuancé : la découverte d'une vulnérabilité n'équivaut pas mécaniquement à une compromission. Mais il s'attend à voir les éditeurs eux-mêmes recourir à l'IA pour purger leurs produits — ce qui, à terme, uniformise le niveau d'assurance attendu sur le marché.

Pourquoi c'est important : le CRA convertit la capacité technique en obligation

Le Cyber Resilience Act, entré en vigueur en décembre 2024, impose deux principes directs aux fabricants et éditeurs de produits avec « éléments numériques » mis sur le marché européen : cybersecurity by default et cybersecurity by design. Le calendrier est désormais imminent :

• 11 septembre 2026 : entrée en application des obligations de reporting des vulnérabilités activement exploitées et des incidents graves auprès de l'ENISA et des CSIRT nationaux ;
• 11 décembre 2027 : application pleine et entière des autres obligations (gestion du cycle de vie, déclaration de conformité, traçabilité des composants logiciels).

Le CRA ne remplace pas le RGPD — il s'y ajoute. L'article 32 du RGPD oblige déjà le responsable de traitement à mettre en œuvre les mesures techniques appropriées « compte tenu de l'état de l'art ». Avec des outils d'IA qui repèrent en quelques minutes ce qui aurait pris des semaines d'audit, le « state of the art » se déplace. Ce que l'ENISA dit à Berlin, c'est qu'à partir de septembre 2026, un DPO ou un RSSI qui n'aura pas intégré ces capacités à sa gouvernance s'expose à une présomption de négligence — par la CNIL au titre du RGPD, et désormais aussi par la Commission au titre du CRA.

Cette doctrine prolonge l'alerte de l'ICO britannique de mai 2026, qui exigeait déjà cinq étapes minimales pour anticiper les cyberattaques boostées à l'IA. Et elle prend tout son sens à la lumière du scénario décrit par le Campus Cyber : une vague massive de correctifs à venir dans les 3 à 6 prochains mois, à mesure que les modèles comme Mythos déversent des découvertes de zero days dans l'écosystème.

Ce que ça change pour les organisations — actions concrètes

Pour les DPO et RSSI, l'intervention de l'ENISA n'est pas un signal théorique. Quatre chantiers méritent d'être enclenchés avant la fin de l'été 2026 :

1. Inventorier les produits avec « éléments numériques » que vous mettez sur le marché ou que vous intégrez. Le CRA vise les fabricants, mais aussi les importateurs et distributeurs. Un éditeur SaaS, une application interne distribuée à des clients, ou même un firmware embarqué dans un dispositif IoT vendu en Europe : tous entrent dans le périmètre. Cette cartographie conditionne la déclaration de conformité.

2. Outiller la détection. Adopter un pipeline de scan continu — SAST, DAST, SCA — augmenté par des outils IA. L'argument économique de l'ENISA fonctionne dans les deux sens : si vous pouvez détecter, vous devez détecter. Notre guide sur la sécurité des données rappelle les briques minimales à articuler avec ce nouvel outillage.

3. Préparer le canal de reporting. À partir du 11 septembre 2026, une vulnérabilité activement exploitée devra être notifiée dans des délais courts (24h pour le pré-avis, 72h pour la notification d'incident, un mois pour le rapport final). Ce circuit doit être documenté, testé, et articulé avec la notification RGPD article 33 si des données personnelles sont concernées.

4. Réviser les contrats sous-traitants. Les éditeurs qui vous fournissent du logiciel devront être en conformité CRA. Vos clauses doivent intégrer cette obligation, refléter le partage de responsabilité sur les notifications, et anticiper les audits de chaîne d'approvisionnement. Pour les sujets IA, notre webinaire sur l'AI Act rappelle l'articulation avec le CRA.

Ce que Leto pense de cette décision

La phrase de Hans de Vries — « la sécurité par défaut, c'est la licence pour exister » — marque une bascule doctrinale. Pendant dix ans, la sécurité applicative a été traitée comme une bonne pratique, voire un coût toléré. À partir de septembre 2026, c'est une condition d'accès au marché européen. Et la disponibilité d'IA capables de trouver les failles change la grammaire de la faute : ne pas avoir vu n'est plus une excuse. Pour les DPO, le réflexe à intégrer dès aujourd'hui : tout traitement reposant sur une application non patchée sera, demain, qualifiable de manquement à l'article 32 du RGPD aggravé par un manquement au CRA. La diligence n'est plus un curseur : elle a un calendrier.

Sources : Infosecurity Magazine — AI Raises the Bar on Vulnerability Awareness and Secure-by-Design Software ; Commission européenne — Cyber Resilience Act ; ENISA.