Secure-by-design : pour l'ENISA, c'est devenu la « licence d'exploitation » des entreprises tech

Pour Hans de Vries, le directeur de la cybersécurité de l'ENISA, le débat est tranché : avec les outils de détection de vulnérabilités dopés à l'IA, plus aucune entreprise technologique ne peut prétendre ignorer les failles de ses produits. Et faire du « secure-by-design » n'est plus une bonne pratique optionnelle — c'est, selon ses mots, la « licence d'exploitation » de toute société qui veut rester sur le marché.

Ce qui s'est passé

Lors d'une intervention rapportée par Infosecurity Magazine, Hans de Vries, chief cybersecurity officer de l'Agence de l'Union européenne pour la cybersécurité (ENISA), a livré un message sans ambiguïté aux éditeurs de logiciels. La généralisation des scanners de vulnérabilités fondés sur l'intelligence artificielle supprime, d'après lui, le dernier argument de défense des entreprises : l'ignorance. Quand une IA peut passer au crible une base de code entière et remonter les bugs à grande échelle, ne pas voir une faille n'est plus une excuse recevable.

De Vries rattache directement cette exigence au Cyber Resilience Act (CRA), le règlement européen qui impose la cybersécurité « par défaut » et « par conception » à tous les produits comportant des éléments numériques. Entré en vigueur en décembre 2024, le CRA déploie ses obligations en deux temps : le signalement des vulnérabilités activement exploitées s'applique dès le 11 septembre 2026, puis l'ensemble des obligations de fond à partir du 11 décembre 2027. « Faire de la sécurité par conception et par défaut, c'est aujourd'hui la licence pour faire des affaires », a-t-il résumé, avertissant qu'une entreprise négligente verra « son adversaire faire un mauvais usage du logiciel vulnérable » et finira « probablement devant les tribunaux, parce qu'elle aurait dû voir le problème ».

Pourquoi c'est important

Cette sortie n'est pas isolée. Elle prolonge la position que l'ENISA et le NCSC britannique ont martelée la même semaine à ESET World, où les deux agences ont acté que l'IA force désormais la main du Cyber Resilience Act. Le glissement est lourd de conséquences juridiques : tant que la détection de failles relevait d'une expertise rare, l'inconnaissance pouvait constituer une circonstance atténuante. Désormais que « plus aucune raison n'existe d'ignorer une vulnérabilité », le standard de diligence attendu monte d'un cran — et il est daté.

Pour les DPO et les RSSI, le parallèle avec le RGPD est immédiat. L'article 32 du RGPD impose déjà des mesures de sécurité « adaptées à l'état de l'art ». Or l'état de l'art, c'est précisément ce que les outils d'IA viennent de redéfinir : si une vulnérabilité est détectable par une machine accessible à tous, ne pas l'avoir corrigée devient difficilement défendable au regard de l'obligation de sécurité du traitement. Les deux régimes — CRA et RGPD — convergent vers une même logique : la preuve de diligence ne se mesure plus à l'intention, mais à la capacité démontrée d'avoir cherché et traité les failles.

Ce que ça change pour les organisations

Concrètement, les organisations qui éditent ou intègrent du logiciel ont jusqu'à l'automne 2026 pour structurer leur dispositif. Quatre chantiers se dégagent. D'abord, cartographier les produits et composants couverts par le CRA, en distinguant ce qui est développé en interne de ce qui provient de tiers. Ensuite, industrialiser un pipeline de détection de vulnérabilités — y compris assisté par IA — pour que la veille technique ne repose plus sur des audits ponctuels. Troisièmement, préparer le canal de signalement réglementaire, qui devra s'articuler avec la notification de violation déjà prévue par le RGPD. Enfin, verrouiller les clauses contractuelles avec les sous-traitants et fournisseurs de briques logicielles, car la responsabilité de l'obligation de sécurité se répercute tout au long de la chaîne.

Les entreprises qui déploient des systèmes d'IA doivent en plus composer avec la superposition de l'AI Act dès lors que leurs usages sont qualifiés de « haut risque ». De Vries va d'ailleurs plus loin que la seule conformité défensive : « Si vous n'utilisez pas l'IA de manière cohérente, vous ne serez probablement pas performant d'ici un an ou deux. » Autrement dit, l'IA n'est pas seulement un risque à encadrer, c'est aussi l'outil qui permet de tenir le nouveau standard de sécurité.

Ce que Leto pense de cette décision

Le message de l'ENISA a le mérite de la clarté : la sécurité par conception cesse d'être un argument marketing pour devenir une condition d'accès au marché, adossée à un risque contentieux réel. Nous y voyons surtout un signal d'alignement entre cybersécurité et protection des données. Le DPO qui attend décembre 2027 pour s'y intéresser fait fausse route — c'est dès maintenant, à l'aune de l'article 32, que l'absence de détection des failles peut être reprochée. La bonne nouvelle, c'est que le travail demandé par le CRA et celui exigé par le RGPD se recouvrent largement : une organisation qui investit dans un pipeline de détection sérieux coche les deux cases à la fois.

Sources : Infosecurity Magazine — AI Raises the Bar on Vulnerability Awareness and Secure-by-Design Software