Une caméra de surveillance compromise n’est plus seulement un appareil à redémarrer. Elle peut devenir le point d’entrée d’une attaque, rejoindre un réseau de machines piratées ou exposer des images privées. À compter du 11 septembre 2026, les fabricants concernés devront aussi savoir alerter les autorités, vite et de manière structurée. C’est le premier grand rendez-vous opérationnel du Cyber Resilience Act européen. Pour les vendeurs de capteurs, de passerelles et d’objets connectés, le changement dépasse la conformité : il oblige à organiser la vie du produit après sa vente.
Une première échéance, pas encore tout le règlement
Entré en vigueur en décembre 2024, le Cyber Resilience Act, ou CRA, établit des exigences de cybersécurité pour les produits comportant des éléments numériques mis à disposition sur le marché européen. Son application générale est prévue le 11 décembre 2027. Mais les obligations de notification démarrent plus tôt, le 11 septembre 2026. Cette distinction compte : l’échéance de septembre ne signifie pas que toutes les nouvelles exigences de conception et de conformité deviennent immédiatement applicables.
Le périmètre dépasse largement la maison connectée. Caméras professionnelles, équipements réseau, passerelles industrielles et nombreux capteurs communicants peuvent être concernés. Certains secteurs disposent toutefois d’exclusions ou de règles spécifiques. Un service cloud n’entre pas automatiquement dans le champ du CRA : certaines fonctions de traitement à distance peuvent en revanche être couvertes lorsqu’elles font partie intégrante du fonctionnement du produit.
Autre point sensible : les obligations de signalement peuvent aussi concerner des produits mis sur le marché avant l’application générale du règlement. Les fabricants ne peuvent donc pas se contenter de préparer leur prochaine gamme. Ils doivent examiner leur parc existant et déterminer les responsabilités qui leur incombent, y compris lorsqu’ils commercialisent sous leur marque un équipement conçu ailleurs.
Ce qu’il faut signaler, et à quelle vitesse
Le CRA distingue deux déclencheurs : une vulnérabilité activement exploitée contenue dans le produit et un incident grave ayant une incidence sur sa sécurité. Toute faille découverte en laboratoire n’entraîne donc pas automatiquement cette notification. Pour le premier cas, il faut disposer d’éléments fiables montrant qu’un acteur malveillant a effectivement exploité la vulnérabilité sans autorisation.
La gravité d’un incident répond elle aussi à des critères. Il ne s’agit pas de déclarer chaque panne Wi-Fi, mais notamment des événements affectant, ou susceptibles d’affecter, la protection de données ou de fonctions importantes, ou permettant l’introduction et l’exécution de code malveillant. Une qualification technique documentée devient indispensable.
- Sous 24 heures après en avoir pris connaissance : une alerte précoce doit être transmise, sans retard injustifié.
- Sous 72 heures : une notification plus complète apporte les informations disponibles sur la vulnérabilité ou l’incident, ainsi que sur les mesures prises ou envisageables.
- Pour une vulnérabilité exploitée : le rapport final est attendu au plus tard quatorze jours après la disponibilité d’une mesure corrective ou d’atténuation.
- Pour un incident grave : le rapport final doit intervenir dans le mois suivant la notification de l’incident, avec des modalités adaptées lorsqu’il reste en cours.
Le dispositif prévoit une transmission au CSIRT désigné comme coordinateur dans l’État membre concerné et à l’ENISA, l’agence européenne pour la cybersécurité, au moyen d’une plateforme unique de signalement. Notifier n’est pas publier immédiatement tous les détails d’une attaque. L’enjeu est de permettre une coordination sécurisée sans offrir un mode d’emploi aux attaquants.
Le vrai test commence un vendredi soir
Prenons un scénario hypothétique : un chercheur avertit un fabricant qu’une passerelle permet d’exécuter des commandes à distance. Quelques heures plus tard, des traces montrent que la faille est déjà utilisée contre des clients. L’entreprise doit identifier les versions touchées, vérifier les éléments reçus, qualifier l’obligation et préparer son alerte. Le délai ne commence pas lorsque le comité de direction revient le lundi.
Cela suppose une adresse de contact surveillée, une équipe capable de traiter les signalements et un circuit de décision court. Le service juridique ne peut pas travailler seul ; les ingénieurs non plus. Support, sécurité, responsables produit et communication doivent partager une chronologie et distinguer les faits établis des hypothèses. Une première alerte peut être incomplète : elle ne doit pas attendre une expertise exhaustive.
Le fabricant doit également informer les utilisateurs concernés des vulnérabilités exploitées ou incidents graves et, lorsque c’est nécessaire, des mesures qu’ils peuvent appliquer. Pour une caméra, cela peut signifier désactiver temporairement une fonction exposée ou installer un correctif. Encore faut-il pouvoir joindre le propriétaire : un produit vendu par un distributeur, sans compte client, rend cette tâche particulièrement difficile.
L’IoT rattrapé par ses dépendances
Cette exigence heurte une réalité ancienne : beaucoup d’objets connectés assemblent des composants venus de plusieurs fournisseurs. Le boîtier porte une marque européenne, mais son micrologiciel utilise une bibliothèque libre, un module radio et un logiciel de référence fournis par d’autres acteurs. Lorsqu’une faille apparaît, la première question est souvent élémentaire : quels modèles embarquent réellement le composant vulnérable ?
Les attaques de type Mirai, connues depuis 2016, ont montré comment des équipements mal sécurisés pouvaient être enrôlés à grande échelle. La crise Log4Shell, en 2021, a illustré une autre faiblesse : la difficulté à retrouver une dépendance logicielle dans une chaîne de produits. Le CRA ne fait pas disparaître ces problèmes. Il rend beaucoup moins tenable une organisation incapable de les retracer.
Inventaires des composants, versions de micrologiciels, procédures de mise à jour et contacts de sécurité chez les fournisseurs deviennent donc des outils opérationnels. Une nomenclature logicielle peut aider, sans remplacer l’analyse : connaître la présence d’une bibliothèque ne suffit pas à savoir si sa faille est exploitable dans un appareil donné.
Un coût immédiat, un possible avantage commercial
Pour une petite entreprise, la difficulté sera moins de remplir un formulaire que d’assurer une capacité de réaction continue. L’externalisation peut apporter une permanence ou une expertise, mais elle n’efface pas la responsabilité du fabricant. Les contrats avec les sous-traitants devront préciser qui enquête, qui fournit le correctif et à quelle vitesse les informations remontent.
Le signalement ne doit pas non plus être confondu avec la remédiation. Une notification exemplaire ne sécurise aucun capteur si la mise à jour est impossible à déployer. À l’inverse, corriger discrètement sans remplir les obligations applicables ne suffit plus. Pour les acheteurs professionnels, la qualité du suivi pourrait ainsi devenir un critère aussi important que le prix ou l’autonomie.
Et maintenant ? L’échéance du 11 septembre 2026 ouvre une phase dont les résultats devront être évalués, sans présumer du volume de notifications ni de leur efficacité. Le scénario souhaitable est celui d’alertes mieux coordonnées, de correctifs plus rapides et d’utilisateurs mieux informés. Le risque est une conformité de façade, centrée sur les déclarations. D’ici à l’application générale de décembre 2027, le véritable indicateur sera donc simple : les fabricants savent-ils transformer une alerte reçue en protection concrète pour les appareils déjà installés ?
