Cyber Resilience Act : impact sur l'enseignement produit & secure-by-design
Un texte européen qui entre dans les salles de cours
Le Cyber Resilience Act (CRA), publié au Journal officiel de l'UE en novembre 2024 sous la référence Règlement (UE) 2024/2847, redéfinit les obligations de cybersécurité applicables aux fabricants et éditeurs qui commercialisent des produits numériques sur le marché européen. Sa logique est directe : tout produit comportant des éléments numériques — d'une caméra connectée à un système de gestion industriel, en passant par une application mobile ou un logiciel embarqué — doit être conçu, maintenu et documenté selon des exigences de sécurité précises et vérifiables.
Pour les enseignants en développement sécurisé, IoT, architecture logicielle et conformité, ce texte n'est pas un sujet d'actualité à mentionner en introduction de cours. C'est un cadre opérationnel à intégrer dans les syllabus, parce que les ingénieurs et développeurs qui entreront sur le marché du travail à partir de 2027 devront en maîtriser les exigences pour exercer leur métier en conformité.
Cet article propose une grille de lecture pédagogique du CRA, des ateliers concrets à lancer dès maintenant et des repères pour actualiser votre cours sans le surcharger.
Ce que le CRA impose : synthèse utile en cours
Le CRA distingue deux grandes catégories de produits soumis à des niveaux d'exigences différents :
- Produits par défaut : la majorité des produits numériques, soumis à auto-évaluation par le fabricant.
- Produits critiques (classes I et II) : liste définie en annexes du règlement (gestionnaires de mots de passe, hyperviseurs, systèmes de contrôle industriel, systèmes d'exploitation…). La classe II requiert une évaluation par un organisme tiers accrédité.
Pour tous les produits, les obligations essentielles couvrent sept domaines :
| Domaine | Exigence principale |
|---|---|
| Conception | Secure-by-design ; pas de vulnérabilités connues exploitables à la mise sur le marché |
| Configuration | Configuration sécurisée par défaut, surface d'attaque minimale |
| Authentification | Pas de mots de passe universels ou par défaut ; supports MFA si justifié |
| Mises à jour | Mécanisme de mise à jour sécurisé, signé ; disponibilité pendant la durée de vie du produit (min. 5 ans si durée indéterminée) |
| SBOM | Identifier et documenter tous les composants logiciels (Software Bill of Materials) |
| Vulnérabilités | Politique de divulgation coordonnée ; signalement à l'ENISA dans les 24 h en cas d'exploitation active |
| Documentation | Notice de sécurité accessible aux utilisateurs (installation, configuration, mise à jour) |
Calendrier à retenir pour vos cours :
- Obligations de signalement des vulnérabilités à l'ENISA : septembre 2026
- Obligations de conformité produit complètes : décembre 2027
Ce que l'étudiant doit retenir en 60 minutes
Une séquence d'introduction au CRA peut tenir en une heure si l'on se concentre sur cinq concepts fondamentaux que tout ingénieur produit doit comprendre.
1. Secure-by-design : la sécurité n'est pas une couche ajoutée
Le CRA exige que la sécurité soit intégrée dès la phase de conception, pas patchée après la mise sur le marché. En développement sécurisé, cela se traduit par : threat modeling en amont du code, réduction de la surface d'attaque dès l'architecture, principe de moindre privilège appliqué à chaque composant.
La formulation du CRA est sans équivoque : les produits ne doivent pas contenir de vulnérabilités connues exploitables au moment de leur mise sur le marché. C'est une rupture avec la culture « on corrige après » qui a prévalu dans le secteur pendant des décennies.
2. Le SBOM : l'inventaire de confiance de la supply chain
Un Software Bill of Materials est une liste structurée de tous les composants logiciels d'un produit — bibliothèques, frameworks, dépendances directes et transitives. Le CRA impose de le maintenir à jour et de le tenir à disposition des autorités de surveillance. La supply chain logicielle est l'une des surfaces d'attaque les plus actives : un SBOM bien tenu est la première ligne de réponse à une alerte de type Log4Shell.
En TP, demander aux étudiants de générer un SBOM d'un projet Python ou Node.js via syft, cdxgen ou pip-audit est un exercice de 30 minutes qui illustre immédiatement l'ampleur du problème.
3. La durée de vie du support : un enjeu d'architecture
Le fabricant doit assurer les mises à jour de sécurité pendant la durée de vie attendue du produit, ou pendant 5 ans au minimum si cette durée n'est pas explicitement définie. C'est un enjeu de coût et d'architecture que les étudiants doivent anticiper dès la conception : choisir une bibliothèque bien maintenue ou un composant avec un horizon de support clairement documenté, c'est aussi une décision de conformité.
4. La divulgation coordonnée : un processus à enseigner
Tout fabricant doit disposer d'une politique de divulgation coordonnée des vulnérabilités (CVD) et signaler à l'ENISA les vulnérabilités activement exploitées dans ses produits, dans les 24 heures suivant la prise de connaissance. Les étudiants spécialisés en sécurité IoT ou en développement logiciel doivent connaître ce processus et savoir le mettre en œuvre.
5. La documentation de sécurité : un livrable professionnel
Le CRA exige que l'utilisateur dispose d'instructions claires sur l'installation, la configuration et la mise à jour sécurisée du produit. Ce n'est pas une notice marketing : c'est un livrable réglementaire. Apprendre aux étudiants à rédiger une notice de sécurité est aussi utile que de leur apprendre à rédiger un rapport de pentest.
Raccorder le CRA aux contenus existants de votre syllabus
Le CRA ne réinvente pas les bonnes pratiques de sécurité : il les rend obligatoires pour les produits commerciaux. Voici comment raccrocher chaque obligation à un contenu pédagogique probablement déjà présent dans votre maquette :
| Obligation CRA | Contenu existant associé | Évolution à apporter |
|---|---|---|
| Secure-by-design | SDLC sécurisé, threat modeling | Préciser le contexte réglementaire CRA |
| SBOM | Gestion des dépendances, CI/CD | Ajouter génération automatisée et audit CVE |
| Configuration sécurisée | Hardening, moindre privilège | Créer une check-list conformité CRA |
| Divulgation vulnérabilités | CVD, bug bounty, pentest éthique | Ajouter processus de notification ENISA |
| Mises à jour sécurisées | OTA updates, PKI, certificats | Relier à l'obligation de durée minimale de support |
| Documentation | Livrables projet, rapports | Créer une notice de sécurité type comme livrable de TP |
Cette grille permet d'intégrer le CRA en ancrant ses exigences dans des séances existantes, par des rappels réglementaires explicites, plutôt que d'ajouter un cours entier qui surchargerait la maquette.
Le profil de spécialiste sécurité IoT est directement concerné, mais les ingénieurs logiciel généralistes, les développeurs embarqués et les architectes sont tout autant dans le périmètre du texte.
Cas pratique : une caméra IP connectée (45 min)
Pour ancrer le CRA dans un objet concret et familier, le scénario de la caméra de surveillance IP est particulièrement efficace : les étudiants en connaissent l'usage, les vulnérabilités classiques sont bien documentées et le produit entre dans le périmètre du CRA.
Contexte : une startup développe une caméra de surveillance IP destinée au marché B2C européen (particuliers et PME). Le groupe doit identifier les exigences CRA applicables et les intégrer dans la feuille de route produit.
Questions à traiter en binôme (45 min) :
- La caméra relève-t-elle de la catégorie "critique classe I" (selon l'annexe III, les produits de gestion d'identité et les éléments réseau sensibles peuvent l'être) ? Argumenter à partir du texte.
- Lister cinq vulnérabilités classiques des caméras IP (mot de passe admin par défaut, port Telnet ouvert, firmware non signé, certificat TLS auto-signé, UPnP exposé sur le WAN). Pour chacune, identifier l'exigence CRA violée.
- Rédiger une politique de divulgation coordonnée en dix lignes : canal de contact, délai de traitement, conditions de publication publique.
- Générer ou simuler un SBOM de trois composants fictifs (ex. : Linux 5.15, BusyBox 1.36, OpenSSL 3.x). Identifier les CVE potentiellement applicables via la base NVD.
- Rédiger la section « Sécurité » d'une notice utilisateur (200 mots maximum) : comment configurer le mot de passe à la première installation, comment activer les mises à jour automatiques, que faire en cas de suspicion de compromission.
Débrief : restitution en plénière sur les choix de priorisation. Quel item du backlog produit passe en priorité haute suite à l'analyse CRA ?
Ce scénario couvre l'essentiel des exigences du texte, ne requiert pas d'infrastructure spécifique et produit des livrables directement évaluables.
Atelier check-list conformité minimale (intégration dans un projet de fin de semestre)
La check-list suivante peut être distribuée aux étudiants comme critère d'évaluation complémentaire d'un projet de développement. Elle couvre les exigences essentielles du CRA applicables à un produit de classe par défaut.
SECURE-BY-DESIGN
□ Threat model documenté (actifs, surfaces d'attaque, contre-mesures)
□ Principe de moindre privilège appliqué à chaque composant
□ Surface d'attaque minimisée (ports fermés, services inutiles désactivés)
□ Aucun credential hardcodé dans le code source ou les images de déploiement
SBOM
□ Liste de toutes les dépendances directes et transitives avec leur version
□ Scan de CVE réalisé sur le SBOM (outil : Grype, Trivy ou Dependabot)
□ Politique de mise à jour des dépendances documentée
CONFIGURATION SÉCURISÉE PAR DÉFAUT
□ Pas de mot de passe par défaut ou universel
□ TLS activé ; algorithmes obsolètes désactivés (SSLv3, TLS 1.0, RC4)
□ Journalisation des événements de sécurité activée
MISES À JOUR
□ Mécanisme de mise à jour signé (vérification d'intégrité avant installation)
□ Durée de support documentée dans la fiche produit
DIVULGATION
□ Page de politique de divulgation publiée (security.txt ou équivalent)
□ Contact de sécurité identifié et joignable (adresse dédiée)
DOCUMENTATION UTILISATEUR
□ Instructions d'installation sécurisée incluses
□ Instructions de configuration du mot de passe lors du premier démarrage
□ Changelog de sécurité maintenu pour chaque version publiée
Cette check-list s'intègre facilement comme rubrique de soutenance : chaque case non cochée doit être justifiée ou planifiée avec un délai réaliste.
Pièges pédagogiques à éviter
Confondre CRA et RGPD
Le CRA porte sur la sécurité des produits numériques (confidentialité, intégrité, disponibilité, résilience). Le RGPD porte sur la protection des données personnelles. Les deux textes se croisent — un produit non sécurisé peut causer une violation de données personnelle — mais leurs périmètres, obligations et autorités de contrôle sont distincts. La certification CIPP/E couvre le RGPD et les réglementations connexes, pas le CRA. Évitez l'amalgame en cours.
Présenter le CRA comme applicable immédiatement
Les étudiants qui développent un produit aujourd'hui doivent anticiper le CRA mais ne sont pas encore formellement tenus de le respecter pour les produits déjà sur le marché. Les obligations de conformité produit s'appliquent aux nouveaux produits mis sur le marché à partir de décembre 2027. C'est une nuance importante pour les entreprises partenaires de l'école.
Négliger les actes délégués
Le texte principal du CRA définit le cadre général. Les actes délégués de la Commission européenne viendront préciser la liste des produits critiques, les méthodes d'évaluation et les schémas de certification. Ces actes sont en cours d'élaboration. Votre cours doit intégrer cette dynamique d'évolution du texte plutôt que de le présenter comme figé.
Ressources officielles et mise à jour annuelle
- Texte officiel : Règlement (UE) 2024/2847, Journal officiel de l'UE (novembre 2024), disponible sur EUR-Lex.
- ENISA : guide d'implémentation du CRA, schémas de certification européens (EUCS, EUCC).
- BSI (Allemagne) : publications techniques très opérationnelles sur les critères d'évaluation CRA.
- ANSSI : notes techniques adaptées au contexte français, en particulier pour les secteurs industriels et les administrations.
- ETSI / CEN-CENELEC : normalisation des méthodes d'évaluation liées au CRA.
Recommandation : réviser ce module une fois par an, au moment de la publication de nouveaux actes délégués. Le contenu sur le secure-by-design et le SBOM reste stable ; seule la liste des catégories critiques évoluera.
Ce qu'il faut retenir
- Le Cyber Resilience Act (Règlement UE 2024/2847) impose des exigences de sécurité vérifiables à tous les produits comportant des éléments numériques commercialisés en Europe.
- Deux jalons clés : septembre 2026 pour le signalement des vulnérabilités à l'ENISA ; décembre 2027 pour la conformité produit complète.
- En cours, l'intégration passe par l'ancrage dans les thèmes existants — SDLC sécurisé, SBOM, CVD, hardening — plutôt que par l'ajout d'un module dédié.
- Le scénario caméra IP est le meilleur support de TP : concret, couvre l'essentiel des exigences, ne requiert pas d'infrastructure.
- La check-list CRA peut servir de rubrique de soutenance pour tout projet de développement logiciel ou système embarqué.
Vous cherchez un intervenant capable d'enseigner le CRA et le secure-by-design avec des exemples terrain ? Retrouvez les professionnels de la sécurité produit sur Cyber Teachers et renforcez vos formations avec des praticiens qui connaissent les enjeux réglementaires actuels.