Depuis le 11 septembre 2026, une vulnérabilité activement exploitée dans votre agent vocal IA doit être signalée à l'ENISA et au CSIRT désigné sous 24 heures. Cette obligation, la première du Cyber Resilience Act à devenir effective, s'applique dès aujourd'hui, bien avant le marquage CE attendu fin 2027.

Le Cyber Resilience Act (CRA, règlement UE 2024/2847) est le premier texte européen qui impose des exigences de cybersécurité sur l'ensemble du cycle de vie des produits comportant des éléments numériques, qu'il s'agisse de matériel ou de logiciel. Contrairement au RGPD qui protège les données personnelles ou à l'AI Act qui encadre les systèmes d'IA selon leur niveau de risque, le CRA s'attaque directement à la sécurité technique des produits eux-mêmes : leurs vulnérabilités, leur processus de correction, et la transparence envers les autorités et les utilisateurs.

Un agent vocal IA, plateforme logicielle connectée qui orchestre reconnaissance vocale, modèle de langage, synthèse vocale et intégrations téléphoniques, correspond très directement à cette définition. Pour les CTOs, DSIs et RSSI qui déploient ou opèrent ce type de solution, deux questions se posent immédiatement : que faut-il signaler depuis cette semaine, et comment se préparer aux obligations plus lourdes qui arrivent en 2027 ? Cet article répond aux deux.

Le Cyber Resilience Act, en bref

Le CRA ne réglemente pas un secteur : il réglemente tout produit numérique connecté vendu dans l'Union européenne, quel que soit le pays où son éditeur a son siège.

Adopté fin 2024, le CRA impose un socle commun d'exigences de cybersécurité : conception sécurisée par défaut, gestion documentée des vulnérabilités pendant toute la durée de vie du produit, mises à jour de sécurité gratuites et automatisables, et transparence envers les utilisateurs sur les risques résiduels. Il concerne aussi bien les objets connectés que les logiciels vendus en mode licence ou SaaS, dès lors qu'ils intègrent une connexion à un réseau ou à un autre appareil.

Le règlement entre en application par étapes, ce qui explique pourquoi une obligation ponctuelle devient effective dès septembre 2026 alors que l'essentiel du texte n'entre en vigueur qu'en 2027.

Date Ce qui devient obligatoire
11 septembre 2026 Signalement des vulnérabilités activement exploitées et des incidents graves à l'ENISA et au CSIRT
11 décembre 2027 Exigences essentielles de cybersécurité, marquage CE, déclaration de conformité, documentation technique complète

C'est cette première échéance qui concerne directement, et dès maintenant, tout éditeur ou intégrateur d'agent vocal IA commercialisé en Europe.

Ce qui change concrètement depuis le 11 septembre 2026

Deux catégories d'événements doivent désormais être notifiées, dès qu'un fabricant en a connaissance.

Les vulnérabilités activement exploitées

Il ne s'agit pas de toute faille théorique découverte lors d'un audit de sécurité, mais spécifiquement d'une vulnérabilité dont l'exploitation réelle est constatée : une tentative d'intrusion documentée, un accès non autorisé confirmé, ou l'usage démontré d'une faille par un tiers malveillant. Pour un agent vocal IA, cela peut concerner une faille dans l'API d'appels sortants, une vulnérabilité dans un composant tiers du pipeline vocal, ou un contournement de l'authentification d'un webhook d'intégration CRM.

Les incidents graves

Un incident grave est un événement ayant un impact substantiel sur la sécurité du produit, indépendamment de l'existence d'une vulnérabilité identifiée au préalable. Une compromission de l'infrastructure hébergeant l'agent vocal, une fuite de données de conversation, ou un dysfonctionnement de sécurité affectant un grand nombre de clients entrent dans cette catégorie.

Le CRA ne demande pas d'attendre d'avoir corrigé le problème pour en parler : l'obligation démarre dès la prise de connaissance, pas après la résolution.

Le calendrier de notification en trois étapes

Le CRA structure la notification en trois temps, chacun avec un délai et un contenu précis.

Étape Délai Contenu attendu
Alerte précoce Sans délai injustifié, au plus tard 24 heures Signalement initial de l'existence de la vulnérabilité exploitée ou de l'incident, sans analyse complète
Notification détaillée 72 heures Première évaluation de la gravité, de l'impact et, si disponibles, des indicateurs de compromission
Rapport final 14 jours après correction (1 mois si la correction est plus longue) Description complète, cause racine, mesures correctives et préventives mises en œuvre

Pour un agent vocal IA en production, traitant potentiellement plusieurs milliers d'appels par jour, ce calendrier suppose une capacité de détection et de qualification d'incident disponible en continu, pas seulement pendant les heures ouvrées. Un éditeur qui découvre une exploitation active un vendredi soir ne peut pas attendre le lundi matin pour engager le compte à rebours des 24 heures.

Qui doit signaler : éditeur, intégrateur ou client final ?

L'obligation de notification à l'ENISA pèse formellement sur le fabricant au sens du CRA, c'est-à-dire l'entité qui conçoit, développe et met le produit numérique sur le marché européen sous son propre nom ou sa propre marque. Pour un agent vocal IA, cela recouvre généralement l'éditeur de la plateforme.

  • L'éditeur de la plateforme d'agent vocal IA porte l'obligation directe de signalement à l'ENISA et au CSIRT pour les vulnérabilités et incidents affectant son produit.
  • L'intégrateur qui personnalise et déploie la solution chez un client peut être considéré comme fabricant s'il modifie substantiellement le produit d'origine, par exemple en y intégrant des composants propriétaires significatifs.
  • L'entreprise cliente qui utilise l'agent vocal IA n'a pas d'obligation directe de notification à l'ENISA au titre du CRA, mais elle doit être informée sans délai par son fournisseur, notamment pour ses propres obligations si elle est par ailleurs régulée par NIS2 ou DORA.

En pratique, un contrat de fourniture d'agent vocal IA conforme au CRA doit désormais préciser explicitement qui notifie quoi, dans quel délai interne, et comment l'information circule du prestataire vers le client. C'est un point de vigilance nouveau à intégrer dans les due diligences fournisseurs.

CRA, NIS2, AI Act, DORA : quatre textes, quatre angles complémentaires

Un agent vocal IA déployé en France peut se retrouver simultanément concerné par quatre réglementations européennes, chacune couvrant un angle différent.

Réglementation Ce qu'elle encadre Qui est régulé
Cyber Resilience Act Sécurité technique du produit numérique lui-même, du concepteur jusqu'à la fin de vie Le fabricant : éditeur ou intégrateur du produit
NIS2 Cybersécurité organisationnelle des entités exploitant des systèmes d'information critiques Les entreprises clientes dans les secteurs essentiels ou importants
AI Act Classification et transparence des systèmes d'intelligence artificielle selon leur niveau de risque Fournisseurs et déployeurs de systèmes d'IA
DORA Résilience opérationnelle numérique et relation aux prestataires TIC, secteur financier uniquement Entités financières et leurs prestataires TIC critiques

La différence essentielle entre le CRA et NIS2 mérite d'être soulignée : NIS2 régule l'organisation qui exploite un système, indépendamment de qui l'a fabriqué. Le CRA régule le produit lui-même, indépendamment du secteur de son client. Un éditeur d'agent vocal IA vendant à la fois à une mairie, une clinique et une banque est soumis au CRA pour son produit dans tous les cas, alors que ses trois clients peuvent relever de régimes NIS2, HDS ou DORA différents selon leur secteur.

Comment se préparer techniquement, dès maintenant

Attendre le marquage CE de décembre 2027 pour s'organiser serait une erreur : l'obligation de signalement est déjà effective, et la structuration interne qu'elle demande prend du temps à mettre en place. Quatre chantiers sont prioritaires.

1. Constituer une nomenclature logicielle (SBOM)

Un agent vocal IA repose sur un empilement de composants : moteur STT, modèle de langage, moteur TTS, bibliothèques d'intégration téléphonique, dépendances open source. Sans inventaire précis de ces composants et de leurs versions, il est impossible de savoir rapidement si une vulnérabilité publiée ailleurs affecte votre propre plateforme.

2. Désigner un point de contact et une astreinte CSIRT

Le compte à rebours de 24 heures démarre dès la prise de connaissance, pas pendant les heures ouvrées uniquement. Une astreinte capable de qualifier un signal de sécurité à toute heure, et de déclencher la procédure de notification, devient une nécessité opérationnelle et non plus une option.

3. Documenter une procédure interne de gestion des vulnérabilités

Cette procédure doit fixer des délais internes plus courts que les délais réglementaires, pour laisser une marge d'analyse avant l'échéance légale : qualifier une remontée de sécurité en quelques heures, pas en 23 heures et 59 minutes.

4. Ouvrir un canal de divulgation coordonnée des vulnérabilités

Le CRA encourage la mise en place d'un point de contact clair pour les chercheurs en sécurité qui découvriraient une faille, avec un engagement de traitement et, si pertinent, une politique de non-poursuite pour les découvertes de bonne foi. C'est souvent la première fois qu'une faille activement exploitée est révélée à un éditeur : autant que le canal soit identifié avant qu'elle ne survienne.

TALKR structure sa réponse au Cyber Resilience Act

La plateforme TALKR documente sa nomenclature logicielle, maintient une astreinte de sécurité et notifie ses clients sans délai en cas de vulnérabilité exploitée ou d'incident grave. Nos équipes accompagnent également nos clients entreprises pour articuler cette obligation avec leurs propres exigences NIS2, DORA ou AI Act.

Découvrir la plateforme TALKR Parler à un expert conformité

FAQ - Cyber Resilience Act et agents vocaux IA

Qu'est-ce que le Cyber Resilience Act (CRA) ?

Le Cyber Resilience Act (règlement UE 2024/2847) est le premier cadre européen imposant des exigences de cybersécurité tout au long du cycle de vie des produits comportant des éléments numériques, matériels comme logiciels. Il s'applique à toute entreprise qui met un tel produit sur le marché de l'Union européenne, qu'elle soit établie dans l'UE ou non. Un agent vocal IA, en tant que logiciel connecté traitant des flux vocaux et des données, entre dans son périmètre.

Quelles obligations entrent en vigueur le 11 septembre 2026 ?

Depuis le 11 septembre 2026, les fabricants doivent signaler à l'ENISA et au CSIRT désigné deux types d'événements : toute vulnérabilité activement exploitée dans leur produit, et tout incident grave ayant un impact sur la sécurité du produit. C'est la première brique du CRA à devenir obligatoire, bien avant le marquage CE et les exigences essentielles prévues pour décembre 2027.

Un agent vocal IA est-il un produit comportant des éléments numériques au sens du CRA ?

Oui dans l'immense majorité des cas. Le CRA définit largement le produit comportant des éléments numériques comme tout logiciel ou matériel connecté dont la fonction implique une connexion directe ou indirecte à un appareil ou un réseau. Une plateforme d'agent vocal IA, ses API d'intégration téléphonique et CRM, et les composants qu'elle orchestre (STT, LLM, TTS) répondent à cette définition dès lors qu'ils sont commercialisés en tant que produit ou service logiciel autonome.

Quels sont les délais de notification imposés par le CRA ?

Le CRA impose trois étapes : une alerte précoce sans délai injustifié et au plus tard 24 heures après avoir eu connaissance de la vulnérabilité exploitée ou de l'incident grave, une notification détaillée dans les 72 heures avec une première évaluation de la gravité et de l'impact, puis un rapport final dans un délai de 14 jours après la mise en œuvre d'une mesure corrective, ou dans le mois suivant si la correction prend plus de temps.

Qui doit signaler : l'éditeur de l'agent vocal IA ou l'entreprise cliente ?

L'obligation de signalement à l'ENISA pèse sur le fabricant du produit, c'est-à-dire l'éditeur ou l'intégrateur qui met la solution d'agent vocal IA sur le marché européen. L'entreprise cliente n'a pas d'obligation directe de notification à l'ENISA, mais elle doit être informée sans délai par son fournisseur, car une vulnérabilité non corrigée sur l'agent vocal qu'elle exploite reste un risque opérationnel et contractuel de son côté.

Quelle différence entre le CRA et la directive NIS2 ?

NIS2 impose des obligations de cybersécurité aux organisations qui exploitent des systèmes d'information dans des secteurs jugés critiques ou importants. Le CRA, lui, s'applique aux fabricants de produits numériques eux-mêmes, indépendamment du secteur de leurs clients. Un éditeur d'agent vocal IA peut donc être soumis au CRA sans être une entité régulée par NIS2, tandis qu'une entreprise cliente régulée par NIS2 doit vérifier que les produits qu'elle achète, dont son agent vocal IA, respectent bien le CRA.

Que risque une entreprise qui ne signale pas une vulnérabilité exploitée ?

Le CRA prévoit des sanctions administratives pouvant atteindre 15 millions d'euros ou 2,5 % du chiffre d'affaires annuel mondial pour les manquements aux exigences essentielles de cybersécurité, et des montants réduits mais significatifs pour les autres manquements comme le défaut de notification. Au-delà de la sanction, un défaut de signalement expose l'éditeur à une perte de confiance de ses clients entreprises, qui intègrent désormais ce critère dans leurs audits fournisseurs.

Comment se préparer techniquement au CRA avant le marquage CE de 2027 ?

La préparation passe par quatre chantiers prioritaires : constituer une nomenclature logicielle (SBOM) recensant les composants et dépendances de la plateforme, désigner un point de contact CSIRT et une astreinte capable de qualifier un incident à toute heure, documenter une procédure interne de gestion des vulnérabilités avec des délais internes plus courts que les délais réglementaires, et mettre en place un canal de divulgation coordonnée des vulnérabilités pour les chercheurs en sécurité.

Pour aller plus loin