Cyber Resilience Act : ce que la loi impose à vos objets connectés

Pendant quinze ans, le marché des objets connectés s'est construit sur une logique simple : sortir vite, sécuriser plus tard — ou jamais. Mots de passe par défaut « admin/admin », ports ouverts, absence totale de mises à jour. Le Cyber Resilience Act (règlement UE 2024/2847) met fin à cette ère.

Ce texte impose, pour tout « produit comportant des éléments numériques » mis sur le marché européen, des exigences essentielles de cybersécurité : conception sécurisée, configuration par défaut durcie, gestion documentée des vulnérabilités et fourniture de mises à jour de sécurité pendant toute la durée de support attendue du produit.

Le champ d'application est volontairement large. Sont concernés aussi bien les objets grand public (caméras, thermostats, serrures connectées) que les composants industriels (passerelles, automates, capteurs). Dès lors qu'un produit se connecte directement ou indirectement à un réseau, il entre potentiellement dans le périmètre. Très peu de projets IoT échappent à cette définition.

Pour un développeur IoT, ce n'est donc pas une abstraction réglementaire lointaine. Le firmware que vous écrivez est le cœur de la conformité du produit. Si l'objet est jugé non conforme, c'est votre travail qui est directement en cause — et c'est vers vous que le fabricant se tournera pour comprendre pourquoi son produit ne peut plus être vendu.

Le CRA ne se contente pas de principes : il décline des attentes techniques précises que tout firmware doit honorer. En pratique, votre code doit désormais intégrer :

• L'absence de secrets en dur : pas de mot de passe ni de clé codés en clair dans le firmware.
• Le chiffrement des communications et des données sensibles au repos comme en transit.
• Une surface d'attaque minimale : désactiver les services et ports non nécessaires par défaut.
• Un canal de mise à jour authentifié et signé, pour empêcher l'injection d'un firmware malveillant.
• Une journalisation permettant de détecter et tracer les incidents de sécurité.

Ces exigences ne sont plus des bonnes pratiques optionnelles : leur absence peut constituer une non-conformité réglementaire et, en cas d'incident, une faute caractérisée. C'est un changement de paradigme majeur pour les indépendants habitués à livrer « ce qui marche ».

Le scénario le plus redouté de l'IoT non sécurisé porte un nom : le botnet. Des milliers d'objets connectés vulnérables sont compromis à distance, puis pilotés pour lancer des attaques massives — typiquement des attaques par déni de service distribué (DDoS) contre des sites ou des infrastructures.

L'enjeu juridique est redoutable : dans ce scénario, votre client n'est pas la victime, il est involontairement l'instrument de l'attaque. Et la victime est un tiers — une entreprise dont le service a été paralysé. La chaîne de responsabilité remonte alors du tiers vers l'exploitant du parc, puis vers le fabricant, puis vers vous, le concepteur du firmware vulnérable.

Dans un sinistre botnet, le développeur ne répond pas d'une donnée perdue, mais d'un dommage causé à des victimes qu'il n'a jamais rencontrées.

L'histoire récente de l'IoT est jalonnée d'épisodes de ce type, où des centaines de milliers d'objets domestiques mal protégés ont été recrutés pour saturer des infrastructures entières. À chaque fois, la même cause : des identifiants par défaut et une absence de mise à jour — exactement ce que le CRA entend désormais interdire, et exactement ce que le firmware doit prévenir.

Cette responsabilité civile envers les tiers, déclenchée par une faille de sécurité, relève typiquement du périmètre d'une garantie cyber et non de la seule RC Pro classique. La distinction est capitale : une RC Pro indemnise le préjudice subi par votre client ; la garantie cyber couvre, elle, le dommage que votre client cause à des victimes extérieures du fait d'une faille de sécurité.

Le CRA introduit une obligation qui modifie profondément la gestion d'incident : la notification des vulnérabilités activement exploitées et des incidents graves, dans des délais courts, à l'agence européenne compétente (ENISA) et aux autorités nationales.

Concrètement, lorsqu'une faille touchant votre firmware est exploitée, le fabricant a l'obligation de déclarer rapidement. Cette transparence imposée a deux conséquences pour vous :

1. Un risque réputationnel : la vulnérabilité devient publique, votre nom peut être associé au défaut.
2. Un risque opérationnel : vous devez être en mesure de produire un correctif en urgence, sous pression contractuelle et réglementaire.

Une garantie cyber moderne ne se limite pas à indemniser : elle inclut souvent une cellule de gestion de crise (experts forensic, juristes, communication) qui vous accompagne dans ces délais de notification serrés. Pour un indépendant seul face à un incident, c'est une bouée de sauvetage opérationnelle.

Le CRA n'est pas une déclaration d'intention : il s'accompagne d'un mécanisme d'application contraignant et d'un calendrier précis. À terme, un produit comportant des éléments numériques ne pourra plus porter le marquage CE — et donc être commercialisé dans l'Union — sans démontrer sa conformité aux exigences de cybersécurité.

Le calendrier est progressif : les obligations de notification des vulnérabilités et incidents s'appliquent avant le gros des exigences produit, qui deviennent pleinement contraignantes ensuite. Autrement dit, le compte à rebours a déjà commencé, et les firmwares conçus aujourd'hui doivent anticiper un cadre qui sera pleinement en vigueur demain.

Pour un développeur, l'implication est directe : un firmware livré sans démarche de conformité documentée devient un produit invendable pour le fabricant le jour où la règle mord. Le retard de conformité n'est pas qu'un risque juridique, c'est un risque commercial immédiat. Concevoir « CRA-ready » dès maintenant est un argument de différenciation autant qu'une protection.

Le CRA désigne formellement des « opérateurs économiques » : fabricant, importateur, distributeur. Le développeur freelance n'est pas toujours nommé directement dans la chaîne réglementaire. Faut-il en conclure qu'il est hors de cause ? Non.

Deux mécanismes le ramènent dans la boucle. D'abord, le contrat de sous-traitance : le fabricant, tenu de la conformité, répercute contractuellement ses obligations sur le développeur via des clauses de conformité et de garantie. Ensuite, la responsabilité civile de droit commun : si votre faute technique est la cause directe du défaut, vous pouvez être recherché en réparation, indépendamment de votre qualification CRA.

Autrement dit, ne pas être « assujetti » au CRA ne signifie pas être à l'abri de ses conséquences. Le freelance qui livre un firmware non conforme hérite du risque par ricochet contractuel et délictuel.

Face à ce durcissement réglementaire, le développeur IoT doit faire évoluer sa protection sur deux fronts complémentaires.

Côté conformité, documentez votre démarche de sécurité : analyse de risque, choix techniques, procédure de gestion des vulnérabilités. Cette documentation est à la fois une exigence du CRA et votre meilleure preuve de diligence en cas de litige.

Côté assurance, combinez une RC Professionnelle pour vos erreurs de prestation et une garantie cyber pour le risque spécifique des failles exploitées : responsabilité envers les tiers, frais de gestion d'incident, défense réglementaire. C'est cette combinaison que nous proposons aux développeurs IoT indépendants, dès 14,90€/mois, pour couvrir un métier dont le cadre légal vient de changer d'échelle.