Cyber Resilience Act : qu’est-ce que je dois changer dans mon développement ?

Beaucoup d’équipes produit et développement se posent aujourd’hui la même question : "Avec le Cyber Resilience Act, qu’est-ce que je dois changer concrètement dans mon développement ?"

La confusion est normale. Le CRA est souvent perçu comme un texte de conformité supplémentaire, alors qu’il touche en réalité à la manière de concevoir, développer, livrer, maintenir et corriger un produit logiciel. La Commission européenne résume bien l’enjeu : le CRA impose des exigences cybersécurité obligatoires pour les produits comportant des éléments numériques, couvrant leur planification, conception, développement et maintenance sur l’ensemble du cycle de vie. Il est entré en vigueur le 10 décembre 2024 ; les principales obligations s’appliqueront à partir du 11 décembre 2027, et les obligations de reporting à partir du 11 septembre 2026.

La bonne lecture est donc la suivante : le CRA ne vous demande pas seulement d’être “plus secure”. Il vous demande d’industrialiser la sécurité de votre produit et de pouvoir la démontrer.

Le vrai sujet : le CRA change la logique du développement produit

Le principal malentendu est de croire que le CRA ajoute simplement quelques contrôles techniques. En réalité, il change le point de départ.

Avant, beaucoup d’équipes raisonnaient ainsi :

1. on développe le produit ;
2. on ajoute un peu de sécurité ;
3. on corrige les vulnérabilités au fil de l’eau ;
4. on documente si un client le demande.

Avec le CRA, la logique devient différente :

1. la sécurité doit être intégrée dès la conception ;
2. le produit doit respecter des exigences essentielles de cybersécurité ;
3. le fabricant doit réaliser une cybersecurity risk assessment ;
4. cette analyse doit informer la planification, la conception, le développement, la production, la livraison et la maintenance du produit.

Autrement dit, on ne parle plus seulement de bonnes pratiques de sécurité applicative. On parle d’un cadre qui oblige à faire le lien entre :

1. architecture produit ;
2. cycle de développement ;
3. gestion des vulnérabilités ;
4. maintenance ;
5. support ;
6. documentation ;
7. preuves.

La question à se poser n’est pas “suis-je conforme ?”, mais “mon SDLC est-il prêt ?”

C’est là que beaucoup d’équipes confondent sécurité et conformité.

La sécurité cherche à réduire les risques réels sur le produit.

La conformité CRA cherche à s’assurer que cette sécurité est pensée, mise en œuvre, maintenue et démontrable dans un cadre réglementaire.

Donc la bonne question n’est pas :

“Quel document faut-il produire ?”

La bonne question est :

“Quelles pratiques de développement dois-je rendre systématiques, traçables et défendables ?”

Ce que le CRA change concrètement dans le développement

1. Vous devez intégrer la cybersécurité dès la conception

Le CRA impose que les produits avec éléments numériques respectent des exigences essentielles de cybersécurité pendant la conception, le développement et la production, mais aussi pendant la durée où ils sont censés être utilisés. La Commission rappelle également que les produits doivent être conçus, mis à jour et maintenus pour protéger les utilisateurs.

Concrètement, cela veut dire que le développement ne peut plus traiter la sécurité comme un contrôle final ou un audit de dernière minute.

Dans les faits, cela pousse à renforcer :

1. les revues d’architecture ;
2. l’identification des surfaces d’attaque ;
3. la sécurisation des configurations par défaut ;
4. la gestion des authentifications, privilèges et secrets ;
5. le durcissement du produit dès sa conception.

Ce que cela change pour une équipe dev

Tu ne peux plus te contenter de dire :

1. “on corrigera plus tard” ;
2. “la sécurité sera vue en pré-prod” ;
3. “c’est le rôle du RSSI ou du DevSecOps”.

Le CRA pousse à faire de la sécurité une exigence produit, pas seulement une exigence d’infrastructure.

2. Vous devez passer d’une sécurité “best effort” à une sécurité “secure by design and by default”

La Commission indique explicitement que le CRA introduit un duty of care pour les fabricants, afin que les produits soient secure by design and by default.

C’est probablement l’un des changements les plus importants.

En pratique, cela veut dire :

1. éviter les configurations dangereuses par défaut ;
2. limiter les fonctionnalités exposées inutilement ;
3. réduire les privilèges par défaut ;
4. forcer ou encourager les paramétrages sécurisés ;
5. documenter clairement les options de sécurité.

Exemple concret

Une fonctionnalité d’administration activée par défaut, une API trop permissive, des credentials faibles ou un mode debug trop facile à laisser actif deviennent beaucoup plus difficiles à défendre.

Le CRA pousse donc à se demander :

si un client installe ou utilise le produit normalement, est-ce que le niveau de sécurité de départ est déjà raisonnable ?

3. Vous devez structurer la gestion des vulnérabilités sur tout le cycle de vie

Le CRA ne s’arrête pas à la sortie du produit. La Commission rappelle que les fabricants doivent aussi gérer les vulnérabilités pendant le cycle de vie de leurs produits.

C’est un point majeur pour les équipes dev et produit.

Concrètement, cela implique de mieux organiser :

1. la remontée de vulnérabilités ;
2. leur triage ;
3. leur correction ;
4. leur priorisation ;
5. leur suivi ;
6. la publication éventuelle d’avis de sécurité ;
7. la maintenance du produit après mise sur le marché.

Et ce n’est pas théorique. À partir du 11 septembre 2026, les fabricants devront notifier les vulnérabilités activement exploitées et les incidents sévères affectant la sécurité du produit, avec :

1. une alerte précoce sous 24 heures après prise de connaissance ;
2. une notification complète sous 72 heures ;
3. puis un rapport final selon les délais prévus.

Ce que cela change pour le développement

Il faut pouvoir répondre à des questions très concrètes :

1. comment une vulnérabilité remonte-t-elle jusqu’à l’équipe produit ?
2. qui décide de la priorité ?
3. sous quel délai corrige-t-on ?
4. comment suit-on le correctif ?
5. comment sait-on quelles versions sont touchées ?
6. comment documente-t-on la remédiation ?

Si ces réponses ne sont pas claires aujourd’hui, le CRA va vous obliger à les formaliser.

4. Vous devez mieux maîtriser vos dépendances et packages tiers

C’est un autre changement très concret.

En mars 2026, ENISA a publié un advisory technique sur l’usage sécurisé des package managers. Le document explique les risques liés aux packages tiers, présente des pratiques pour les sélectionner, les intégrer, les surveiller et traiter les vulnérabilités dans les dépendances.

Cela recoupe très directement les attentes CRA. Car pour démontrer la sécurité d’un produit, il faut aussi comprendre ce qui le compose.

En pratique, cela pousse à renforcer :

1. l’inventaire des dépendances ;
2. le suivi des versions ;
3. la maîtrise des librairies critiques ;
4. la gestion des dépendances obsolètes ;
5. la capacité à identifier rapidement une exposition liée à un composant tiers.

Ce que cela change pour une équipe logicielle

Tu dois être capable de répondre à des questions comme :

1. quelles dépendances sont utilisées dans le produit ?
2. quelles sont les plus sensibles ?
3. comment surveille-t-on leurs vulnérabilités ?
4. comment arbitre-t-on les mises à jour ?
5. quelle est la procédure si une librairie critique est compromise ?

5. Vous devez mieux documenter ce que vous faites

Le CRA n’est pas qu’un texte de sécurité technique. C’est aussi un texte de démonstration.

La Commission précise que les produits concernés devront satisfaire à des exigences essentielles et, selon les cas, passer par une évaluation de conformité avant leur mise sur le marché européen. ENISA et le JRC ont aussi travaillé sur une cartographie entre les exigences CRA et les standards existants, précisément pour aider à traduire les obligations en pratiques et preuves plus opérationnelles.

Concrètement, cela veut dire qu’une équipe de développement ne doit pas seulement faire les choses. Elle doit aussi pouvoir montrer :

1. quelles exigences sécurité ont été prises en compte ;
2. quelle analyse de risque a été faite ;
3. quelles décisions d’architecture ont été prises ;
4. quelles mesures de sécurité sont en place ;
5. comment les vulnérabilités sont traitées ;
6. quelle maintenance est assurée.

Le vrai changement culturel

Avant, beaucoup d’équipes documentaient surtout pour les clients, les audits ou la certification.

Avec le CRA, la documentation devient une composante normale de la conformité produit.

6. Vous devez clarifier votre période de support et vos mises à jour de sécurité

Le CRA vise explicitement le manque de mises à jour de sécurité en temps utile et impose une logique de sécurité sur la durée d’usage attendue du produit. La Commission résume le texte en expliquant qu’il établit des exigences non seulement pendant la conception et la production, mais aussi pendant le temps où le produit est censé être utilisé.

Pour beaucoup d’éditeurs, cela pose une question simple mais souvent mal cadrée :

combien de temps notre produit est-il maintenu, et que couvre réellement ce support en matière de sécurité ?

Concrètement, cela pousse à clarifier :

1. la durée de support ;
2. la politique de sécurité des versions ;
3. les délais de correction attendus ;
4. la stratégie de patch ;
5. la gestion des versions en fin de vie.

Les erreurs les plus fréquentes quand on traduit le CRA côté développement

1. Le traiter comme un sujet purement juridique

Le CRA a une dimension réglementaire, bien sûr. Mais l’impact réel est surtout produit, engineering, DevSecOps et maintenance.

2. Le réduire à un scan de vulnérabilités

Le scan est utile, mais insuffisant. Le CRA touche aussi la conception, les configurations par défaut, la gestion de cycle de vie, la documentation et la maintenance.

3. Penser que la conformité remplace la sécurité

Ce n’est pas parce qu’une checklist est remplie que le produit est réellement bien sécurisé. Le CRA pousse justement à relier exigences formelles et sécurité effective.

4. Oublier les dépendances

Les packages et composants tiers deviennent un angle mort dangereux si l’inventaire et la surveillance ne sont pas tenus.

5. Attendre 2027 pour réagir

C’est une erreur classique. Les principales obligations s’appliqueront en décembre 2027, mais les obligations de reporting arrivent dès septembre 2026, et les transformations SDLC prennent du temps.

Ce que vous devriez changer dès maintenant

Pour une équipe produit ou développement, les priorités les plus concrètes sont généralement celles-ci.

1. Formaliser une analyse de risque produit

Le CRA prévoit explicitement une cybersecurity risk assessment pour informer la conception et le cycle de vie.

2. Revoir les paramètres et comportements par défaut

L’objectif est d’être défendable sur le secure by default.

3. Structurer le processus de gestion des vulnérabilités

Avec rôles, délais, priorisation, traçabilité et boucle de correction.

4. Mettre sous contrôle les dépendances

Inventaire, surveillance, politique de mise à jour, traitement des vulnérabilités tierces.

5. Documenter le SDLC sécurité

Pas pour “faire joli”, mais pour démontrer ce qui est réellement fait.

6. Clarifier la maintenance sécurité du produit

Support, versions, correctifs, fin de vie.

En bref

Le Cyber Resilience Act ne demande pas seulement d’ajouter quelques mesures de sécurité. Il vous oblige à mieux structurer votre développement.

Ce qu’il faut retenir :

1. la sécurité doit être intégrée dès la conception ;
2. le produit doit être plus défendable par défaut ;
3. la gestion des vulnérabilités doit être organisée sur tout le cycle de vie ;
4. les dépendances doivent être mieux maîtrisées ;
5. la documentation et la preuve deviennent indispensables ;
6. le sujet concerne autant le produit que la conformité.

FAQ

Le CRA concerne-t-il vraiment le développement logiciel ?

Oui. La Commission indique clairement que le CRA impose des exigences cybersécurité pendant la planification, la conception, le développement, la production et la maintenance des produits avec éléments numériques.

Qu’est-ce que je dois changer en priorité dans mon développement ?

En général : l’analyse de risque produit, les paramètres sécurisés par défaut, la gestion des vulnérabilités, le suivi des dépendances, la documentation et la politique de maintenance sécurité.

Le CRA est-il un sujet de conformité ou de sécurité ?

Les deux. C’est un texte de conformité, mais il a un impact direct sur la façon dont vous faites de la sécurité produit au quotidien.

Pourquoi faut-il s’y préparer avant 2027 ?

Parce que les changements de cycle de développement, de documentation et de gouvernance produit prennent du temps, et que certaines obligations de reporting s’appliquent dès le 11 septembre 2026.