Cyber Resilience Act : ce que le 11 septembre 2026 change pour vos fournisseurs logiciels

Depuis le 11 septembre 2026, une nouvelle obligation européenne est entrée en application : tout fabricant d'un produit comportant des éléments numériques doit signaler sous 24 heures toute vulnérabilité activement exploitée. C'est la première échéance concrète du Cyber Resilience Act, un règlement qui vise les logiciels et objets connectés eux-mêmes plutôt que la gouvernance interne des entreprises. Pour les DSI, RSSI et équipes achats, ce texte change une chose précise : évaluer un fournisseur logiciel ne se limite plus à vérifier ses conditions générales, il faut désormais comprendre comment il gère ses vulnérabilités et s'il est capable de le prouver.

Qu'est-ce que le Cyber Resilience Act et pourquoi le 11 septembre 2026 compte

Le Cyber Resilience Act (CRA) est un règlement européen qui impose des exigences de cybersécurité aux produits comportant des éléments numériques commercialisés dans l'Union européenne : logiciels, objets connectés, équipements réseau, applications professionnelles. Contrairement à NIS2, qui organise la gouvernance de sécurité des entreprises (comités, gestion des risques, notification d'incidents), le CRA s'attaque directement au produit : sa conception, sa maintenance, et la façon dont son éditeur gère les failles découvertes après sa mise sur le marché.

Le texte prévoit une entrée en application progressive. La première échéance, fixée au 11 septembre 2026, porte sur deux obligations de signalement : une notification sous 24 heures à l'agence européenne de cybersécurité (ENISA) en cas de vulnérabilité activement exploitée, suivie d'un rapport plus détaillé sous 72 heures. Les obligations plus larges de conformité produit (marquage CE, documentation technique complète, cycle de gestion des vulnérabilités tout au long du cycle de vie) entrent en application sur un calendrier plus étalé, jusqu'en 2027.

Ce calendrier resserré change la donne pour deux catégories d'acteurs à la fois. Les éditeurs et fabricants doivent désormais être capables de détecter, qualifier et signaler une vulnérabilité en quelques heures, ce qui suppose une organisation interne déjà rodée. Les entreprises qui achètent ces produits, de leur côté, héritent d'un nouveau critère de sélection : un fournisseur incapable de démontrer cette capacité de réaction expose ses clients à un risque qu'ils ne maîtrisent pas eux-mêmes.

Ce que le CRA exige concrètement des fabricants et éditeurs

Au-delà du signalement sous 24 heures, le CRA impose une logique de sécurité par conception et par défaut. Un produit numérique doit être livré sans vulnérabilité connue exploitable, avec une configuration sécurisée par défaut, et surtout avec un mécanisme de mise à jour de sécurité pendant toute sa durée de vie annoncée. L'éditeur doit documenter ce cycle de gestion des vulnérabilités : comment une faille est détectée, qualifiée, corrigée, et communiquée aux utilisateurs concernés.

Cette exigence de documentation est ce qui distingue le CRA d'une simple bonne pratique. Un éditeur ne peut plus se contenter d'affirmer qu'il prend la sécurité au sérieux : il doit pouvoir produire une politique de gestion des vulnérabilités écrite, un point de contact dédié pour les signalements externes, et un historique démontrable de correctifs appliqués dans des délais raisonnables. Pour une entreprise cliente, ces éléments deviennent des pièces à demander avant la signature d'un contrat, au même titre qu'une politique de confidentialité ou des conditions de réversibilité des données.

Le règlement distingue également des catégories de produits selon leur criticité, avec des exigences renforcées pour les produits jugés « importants » ou « critiques » au sens du texte, qui devront passer par une évaluation de conformité plus poussée, parfois via un organisme tiers. Un logiciel SaaS grand public n'est pas nécessairement logé à la même enseigne qu'un composant réseau ou un système d'exploitation, mais l'esprit du texte reste le même pour tous : la sécurité ne se déclare plus, elle se documente et se prouve.

Le marquage CE devient à terme le signal visible de cette conformité pour les produits numériques concernés, un peu à la manière de ce que ce marquage représente déjà pour d'autres catégories de produits industriels. Mais entre l'entrée en application des premières obligations de signalement et l'échéance complète du marquage CE, plusieurs mois séparent la théorie du règlement de sa mise en œuvre effective chez la plupart des éditeurs. C'est précisément dans cet intervalle que se joue la différence entre un fournisseur qui anticipe et un fournisseur qui découvrira ses obligations au dernier moment, sous la pression d'un client ou d'un auditeur.

Un nouvel enjeu pour les acheteurs de logiciels et d'IA en entreprise

Le CRA déplace une partie du risque vers la chaîne de fournisseurs

Une entreprise qui déploie un outil logiciel, qu'il s'agisse d'un ERP, d'une solution de gestion RH ou d'un assistant IA de réunion, hérite en partie du niveau de sécurité de ses fournisseurs. Le CRA formalise ce principe déjà présent dans NIS2 côté chaîne d'approvisionnement, mais l'applique cette fois directement au produit logiciel lui-même. Un contrôle de conformité, un audit de sécurité ou une due diligence avant acquisition va de plus en plus intégrer une question simple : vos fournisseurs logiciels sont-ils prêts pour le CRA, et pouvez-vous le démontrer ?

Cette question devient particulièrement sensible pour les outils qui traitent des échanges professionnels sensibles, comme les assistants de transcription et de compte rendu de réunion. Un comité de direction, un comité de risques bancaire ou une revue de projet confidentielle transitent par ce type d'outil : sa robustesse face aux vulnérabilités n'est plus un détail technique, c'est une condition de la confidentialité de ces échanges. Sur ce point, la logique rejoint directement celle développée dans notre article sur la traçabilité des comités de sécurité face à NIS2 : la documentation de la sécurité devient elle-même un livrable attendu, pas seulement un argument commercial.

Les questions à poser avant de choisir un outil IA de réunion

Face à un fournisseur d'assistant IA de réunion, quelques questions permettent de vérifier concrètement sa préparation, au-delà du discours marketing. L'éditeur dispose-t-il d'une politique écrite de gestion des vulnérabilités, avec un point de contact identifiable pour un signalement externe ? Peut-il documenter ses délais moyens de correction depuis la découverte d'une faille jusqu'à son correctif ? Où sont hébergées les données de réunion, sous quel régime juridique, et avec quel niveau de chiffrement ? Existe-t-il une instance cloisonnée par organisation plutôt qu'un socle mutualisé entre tous les clients ?

Ces questions ne sont pas propres au CRA, mais le règlement leur donne un cadre réglementaire et un calendrier. Une entreprise qui les pose aujourd'hui prend une longueur d'avance sur des exigences qui deviendront, à mesure que le CRA se déploie jusqu'en 2027, des standards de fait dans les appels d'offres et les audits fournisseurs.

Dans la pratique, intégrer ces questions ne demande pas de refondre entièrement un processus achats. Il suffit souvent d'ajouter une section dédiée à la sécurité produit dans le cahier des charges ou le questionnaire fournisseur déjà utilisé pour les appels d'offres logiciels, au même titre que les rubriques existantes sur la conformité RGPD ou la réversibilité des données. Les équipes achats qui commencent dès maintenant à documenter les réponses de leurs fournisseurs actuels sur ces points se donnent une base de comparaison utile pour les renouvellements de contrats à venir, plutôt que de découvrir ces lacunes au moment d'un incident.

CRA et NIS2 : deux textes complémentaires, pas redondants

Il est facile de confondre CRA et NIS2, puisque les deux textes visent la cybersécurité européenne et sont entrés en application à quelques mois d'écart. Leur logique reste pourtant distincte. NIS2 organise la gouvernance de sécurité des entreprises elles-mêmes : comités de pilotage, gestion des risques, notification d'incidents, responsabilité des dirigeants. Le CRA, lui, s'adresse aux fabricants et éditeurs de produits numériques, et porte sur la sécurité du produit tout au long de son cycle de vie, de sa conception à sa fin de support.

Une entreprise soumise à NIS2 devra donc, dans le cadre de sa propre gouvernance des risques, vérifier que ses fournisseurs logiciels critiques respectent des standards proches de ceux qu'impose le CRA. Les deux règlements se rejoignent sur un même terrain : la capacité à documenter, tracer et prouver une pratique de sécurité, plutôt que de simplement l'affirmer. C'est cette même logique de preuve qui structure notre analyse de la résidence et de la gouvernance des données issues des réunions, un sujet qui infuse aussi bien la conformité NIS2 que l'évaluation d'un fournisseur au regard du CRA.

Plusieurs analyses juridiques publiées autour de l'échéance du 11 septembre 2026 notent que la majorité des entreprises concernées n'ont pas jusqu'en 2027 pour se préparer : les premières obligations de signalement s'appliquent dès maintenant, avant même le volet complet de conformité produit.

Ce que la posture de sécurité de Seedext illustre pour ce nouveau standard

Sans se présenter comme certifié CRA, un règlement qui concerne avant tout les fabricants de produits au sens large, Seedext construit sa posture de sécurité sur les mêmes principes que ceux que le texte pousse désormais le marché à exiger. Les données de réunion sont hébergées en France, chiffrées en AES-256 et TLS 1.3, dans une infrastructure conforme au RGPD. Chaque organisation cliente dispose d'une instance cloisonnée via le panel organisation, avec la possibilité d'un déploiement On-Premise pour les secteurs les plus exigeants : banques, assurances, énergéticiens, opérateurs d'infrastructures critiques.

Cette architecture s'accompagne de démarches de certification ISO et SOC2 actuellement en cours, une trajectoire cohérente avec l'esprit du CRA : documenter une pratique de sécurité plutôt que se contenter de la déclarer. Pour un DSI ou un RSSI qui doit désormais interroger chacun de ses fournisseurs logiciels sur sa préparation à ces nouvelles obligations européennes, la question à poser est la même quel que soit l'outil évalué : où sont vos données, qui peut y accéder, et comment prouvez-vous que votre sécurité tient dans la durée, pas seulement le jour de la signature du contrat.

L'assistant s'intègre par ailleurs nativement aux environnements de réunion déjà utilisés (Teams, Zoom, Google Meet, Webex), sans imposer de rupture dans les habitudes de travail des équipes, tout en apportant cette couche de documentation et de traçabilité que les nouvelles obligations européennes rendent désormais indispensable pour un fournisseur d'assistant de réunion en entreprise.

Pour une direction des achats IT, ce type de trajectoire se lit aussi dans la durée plutôt que dans un unique label affiché sur un site web. Un fournisseur qui communique régulièrement sur l'avancement de ses démarches de certification, qui documente ses choix d'hébergement et qui accepte de répondre en détail à un questionnaire de sécurité donne davantage de garanties qu'un simple logo de conformité sans contexte. C'est cette transparence progressive, plus que la seule obtention d'un certificat à un instant donné, que le CRA pousse désormais l'ensemble du marché logiciel à adopter comme standard.

FAQ

Qu'est-ce que le Cyber Resilience Act et qui est concerné ?

Le Cyber Resilience Act est un règlement européen qui impose des exigences de cybersécurité aux produits comportant des éléments numériques (logiciels, objets connectés, équipements réseau) commercialisés dans l'Union européenne. Il concerne directement les fabricants et éditeurs de ces produits, avec des répercussions pour les entreprises qui les achètent et les déploient.

Que change l'obligation de signalement du 11 septembre 2026 ?

Depuis cette date, tout fabricant doit signaler sous 24 heures une vulnérabilité activement exploitée sur l'un de ses produits à l'agence européenne de cybersécurité, suivi d'un rapport plus détaillé sous 72 heures. C'est la première échéance concrète du CRA, avant des obligations de conformité produit plus larges qui s'étalent jusqu'en 2027.

Quelle est la différence entre le Cyber Resilience Act et la directive NIS2 ?

NIS2 organise la gouvernance de sécurité des entreprises elles-mêmes (comités, gestion des risques, notification d'incidents), tandis que le Cyber Resilience Act cible directement les produits numériques et leurs fabricants, avec des exigences de sécurité par conception et de gestion des vulnérabilités tout au long du cycle de vie du produit. Les deux textes sont complémentaires plutôt que redondants.

Comment évaluer si un fournisseur logiciel est prêt pour le CRA ?

Il faut vérifier l'existence d'une politique écrite de gestion des vulnérabilités, d'un point de contact identifiable pour un signalement externe, de délais de correction démontrables, ainsi que la localisation et le niveau de chiffrement des données hébergées. Ces éléments deviennent des critères d'achat au même titre qu'une politique de confidentialité classique.

Le Cyber Resilience Act concerne-t-il les outils d'intelligence artificielle ?

Oui, dès lors qu'un outil d'intelligence artificielle constitue un produit logiciel comportant des éléments numériques commercialisé dans l'Union européenne, il entre dans le champ d'application du texte selon les mêmes principes de sécurité par conception et de gestion des vulnérabilités que les autres catégories de produits numériques.