ENISA et NCSC à ESET World : l'IA force la main du Cyber Resilience Act
À ESET World 2026 (Berlin, 19 mai), deux régulateurs européens — l'ENISA et le NCSC britannique — ont esquissé la fin d'une ère : celle où un éditeur pouvait ignorer les vulnérabilités de son propre logiciel. Avec l'IA qui industrialise la détection de bugs et le Cyber Resilience Act qui entre en application dès septembre 2026, le « je ne savais pas » s'apprête à devenir indéfendable.
Ce qui s'est passé
Hans de Vries, Chief Cybersecurity and Operational Officer de l'ENISA, et Paul Chichester, directeur des opérations du National Cyber Security Centre britannique, sont intervenus sur la même tribune à Berlin. Tous deux ont décrit un basculement déjà engagé : les outils d'IA — Claude Mythos d'Anthropic, GPT-5.5-Cyber d'OpenAI, mais aussi des plateformes commerciales spécialisées — détectent désormais à grande échelle des failles que les pipelines classiques laissaient passer.
« Aucune entreprise ne peut plus dire « je ne connaissais pas la vulnérabilité de mon application », parce qu'il est désormais possible de la voir et de la corriger », a martelé Hans de Vries. Sa thèse : la security by design et la security by default, que le Cyber Resilience Act élève en obligation, sont devenues « la licence d'exercer ».
Paul Chichester (NCSC) a complété l'analyse côté défense : la masse de vulnérabilités révélées par l'IA va exposer en priorité les organisations sans défense en profondeur — shadow IT, dette technique, chaînes d'approvisionnement opaques. Mais il prédit aussi que les éditeurs vont se saisir de l'IA pour purger leurs propres produits, et que cela uniformisera enfin l'assurance sécurité du marché logiciel.
Pourquoi c'est important — le CRA fait converger l'IA et la sécurité par défaut
Le Cyber Resilience Act (règlement UE 2024/2847) est entré en vigueur en décembre 2024. Son calendrier d'application est désormais l'élément clé pour les DPO et RSSI européens : les obligations de reporting des vulnérabilités exploitées s'appliquent dès le 11 septembre 2026 ; les obligations pleines — security by design, gestion de la durée de vie, documentation technique, marquage CE — entrent en vigueur le 11 décembre 2027.
Cette intervention de l'ENISA n'est donc pas un message d'ambiance : c'est une mise en demeure adressée à l'industrie. Sur le plan RGPD, l'argument se superpose à l'article 32 du RGPD, qui exige des mesures techniques et organisationnelles appropriées « compte tenu de l'état de l'art ». Or l'état de l'art, en 2026, intègre les outils d'IA capables d'auditer un code base. La diligence devient datée : ce qu'on pouvait raisonnablement ignorer il y a six mois ne l'est plus aujourd'hui.
Cette convergence rejoint l'analyse que Leto publiait sur l'intervention de l'ENISA et les quatre chantiers du CRA, et fait écho à l'avertissement du Future of Privacy Forum sur la gouvernance cyber des intégrations tierces à l'ère de l'IA.
Ce que ça change pour les organisations
Pour un éditeur logiciel ou un fournisseur de produit avec composante numérique (qui sera couvert par le CRA), quatre chantiers deviennent prioritaires :
- Cartographier les produits soumis au CRA : tout produit avec « éléments numériques » mis sur le marché de l'UE est concerné, y compris les composants logiciels embarqués et les services cloud associés. La nomenclature « important » et « critique » (annexes III et IV du CRA) dicte le régime d'évaluation de conformité.
- Industrialiser le pipeline de détection : SBOM (Software Bill of Materials) à jour, scan IA continu, intégration des résultats dans le cycle de patchs. C'est exactement le sujet que les tribunaux examineront pour qualifier l'« état de l'art » au sens de l'article 32.
- Préparer le canal de reporting : à partir du 11 septembre 2026, toute vulnérabilité activement exploitée devra être notifiée à l'ENISA et à l'autorité compétente sous 24 heures pour l'alerte précoce, puis 72 heures pour la notification d'incident. Cette obligation cohabite avec la notification CNIL article 33 du RGPD si des données personnelles sont en jeu.
- Verrouiller les contrats sous-traitants : l'article 28 du RGPD impose la transparence sur les mesures de sécurité ; le CRA ajoute la traçabilité des composants. Les questionnaires fournisseurs doivent désormais exiger un SBOM et une politique de divulgation responsable.
Pour les déployeurs de systèmes IA — typiquement ceux qui intègrent une plateforme de détection de vulnérabilités achetée sur étagère — la logique AI Act se superpose : si le système est qualifié à haut risque (voir les nouvelles lignes directrices de la Commission sur l'annexe III), la cascade d'obligations s'ajoute à celle du CRA.
Ce que Leto pense de cette décision
Le message d'ESET World 2026 est limpide : la régulation européenne fait de la sécurité logicielle un sujet de responsabilité éditoriale, plus seulement de bonnes pratiques. Pour les DPO et RSSI, c'est l'occasion de demander aux directions générales une décision stratégique claire : continue-t-on à acheter des outils sécurité chez des fournisseurs qui n'ont ni SBOM, ni divulgation responsable, ni pipeline IA, alors que cela deviendra une non-conformité documentée dès septembre 2026 ? La réponse paraît évidente. Reste à l'écrire dans les contrats — avant que la jurisprudence ne le fasse à la place des organisations.
Sources :
