Le Cyber Resilience Act (CRA) entre désormais dans une phase très concrète. Les premières obligations de signalement s’appliqueront à partir du 11 septembre 2026, et l’ensemble du règlement s’appliquera pleinement à partir du 11 décembre 2027.
Pour beaucoup de directions IT et innovation, ce texte reste encore perçu comme un sujet de conformité réglementaire, piloté par les équipes juridiques ou RSSI. Peut-être faut-il changer d’angle de vue.
Le CRA ne se gagne pas dans un audit de conformité mené dans l’urgence à l’approche de l’échéance. Il se construit dès aujourd’hui, dans les choix d’architecture, de développement, de déploiement et de maintenance. Et c’est là qu’une distinction souvent confondue mérite d’être clarifiée : celle entre security by design et security by default.
Ce que dit vraiment le règlement
Le Cyber Resilience Act fixe des exigences essentielles de cybersécurité pour les produits comportant des éléments numériques mis sur le marché européen. Ces exigences portent à la fois sur la manière dont le produit est conçu, développé et maintenu, et sur sa manière de se comporter par défaut une fois livré.
L’idée centrale du règlement est simple : un produit numérique ne doit pas seulement être sécurisé « sur le papier » ou dans son architecture théorique. Il doit l’être dans sa conception, dans sa configuration initiale, dans sa maintenance, et dans la gestion des vulnérabilités tout au long de son cycle de vie.
Le texte du CRA ne crée pas une révolution conceptuelle. Il formalise et rend obligatoires des pratiques que les organisations les plus matures cherchent déjà à appliquer. Mais il leur donne un cadre réglementaire explicite, avec des obligations et des échéances précises.
Security by design : une démarche de conception
Le security by design désigne l’intégration de la sécurité dès la phase de conception et de développement. Ce n’est pas une fonctionnalité ajoutée a posteriori au produit livré ; c’est une méthode de travail.
Concrètement, cela recouvre plusieurs pratiques :
- La réalisation d’une analyse de risques ou d’un « threat modeling » dès le cadrage du projet, avant le développement. C’est-à-dire, identifier les actifs critiques, les vecteurs d’attaque plausibles et les contre-mesures associées.
- Des choix d’architecture intégrant la sécurité dès l’origine, par exemple une authentification robuste (OAuth2, MFA), la séparation des privilèges et le chiffrement des données sensibles.
- Une gestion structurée des dépendances logicielles et des composants tiers.
- La documentation et la traçabilité des décisions de sécurité prises tout au long du projet.
🧭 Le security by design est donc d’abord une question de méthode d’ingénierie. Il se mesure à la qualité du cadrage, à la rigueur des arbitrages techniques et à la capacité à documenter et justifier ces choix.
Security by default : une question de configuration livrée
Le security by default ne concerne pas le processus de conception, mais l’état du produit au moment où il est livré. Il s’agit de s’assurer que la configuration initiale est sécurisée, sans action particulière de l’utilisateur.
Un produit conforme à cet esprit doit, dès sa mise à disposition :
- éviter les mots de passe génériques ou faibles par défaut ;
- limiter les permissions au strict nécessaire ;
- désactiver les services, ports ou fonctionnalités non indispensables ;
- activer des mécanismes de protection adaptés, comme le chiffrement des communications ;
- permettre une gestion claire et robuste des mises à jour de sécurité.
C’est ici que la différence devient très concrète. Une équipe peut avoir mené un travail sérieux de conception, documenté ses choix et produit une architecture saine, tout en livrant un produit dont la configuration par défaut reste trop permissive. Un compte administrateur laissé actif pour simplifier la recette, des droits trop larges accordés initialement, ou des services ouverts par défaut sont des exemples typiques de défaillances au regard du security by default.
Pourquoi cette distinction compte particulièrement pour le développement sur-mesure
Pour une organisation qui fait développer une application métier, une solution digitale ou une application mobile, cette distinction a une conséquence directe sur le cahier des charges et la réception du livrable.
Le security by design s’évalue dans la méthodologie du projet : a-t-on réalisé une analyse de risques avant le développement ? La chaîne de dépendances est-elle documentée et surveillée ? Les choix d’architecture sont-ils justifiés et traçables ?
Le security by default s’évalue dans le produit livré, en sortie de recette : quelle est la configuration réelle de l’environnement de production le jour de la mise en ligne ? Quels comptes, quels accès, quels services sont actifs sans intervention spécifique du client ou de l’utilisateur ?
🧭 Ce sont deux moments de contrôle différents, deux familles de preuves différentes, et deux types de défaillances différentes. Un projet peut être solide sur l’un et défaillant sur l’autre. D’où l’importance de les traiter comme deux exigences distinctes dans tout cahier des charges ou contrat de développement.
Un point souvent mal compris : qui est « fabricant » au sens du CRA ?
Une question revient souvent chez les directions IT : qui porte la responsabilité CRA lorsque le développement est confié à un prestataire externe ?
Le principe du règlement est clair : la responsabilité dépend de la position dans la chaîne de mise à disposition sur le marché, et non du simple fait d’avoir écrit le code. L’entité qui commercialise le produit sous sa propre marque, ou qui le met elle-même à disposition sur le marché, peut être considérée comme fabricant au sens du CRA.
Autrement dit, une entreprise ne peut pas se défausser automatiquement de sa responsabilité réglementaire sur son prestataire de développement. Cette responsabilité doit être pensée contractuellement, avec une répartition claire des obligations de documentation, de gestion des vulnérabilités, de maintenance et de suivi de conformité.
Pour un prestataire, cela signifie qu’il ne suffit plus de « faire de la sécurité si on le demande ». Il faut intégrer ces exigences nativement dans la manière de concevoir et de livrer les projets.
Ce que cela implique en pratique
Dans les projets de développement web et mobile, cette logique se traduit par des pratiques concrètes, intégrées dès le cadrage :
- un threat modeling systématique dès la phase de spécification ;
- une politique de gestion des dépendances avec suivi des vulnérabilités connues ;
- des configurations de déploiement sécurisées par défaut ;
- une documentation technique structurée dès la livraison ;
- une surveillance continue des composants tiers et des correctifs disponibles.
L’objectif n’est pas de transformer chaque projet en exercice de conformité lourd et anxiogène. Il s’agit plutôt d’ancrer ces réflexes dans la culture d’ingénierie, pour éviter de découvrir trop tard des failles de base qui auraient pu être anticipées dès le départ.
Une opportunité plus qu’une contrainte
Le CRA n’invente pas de nouvelles bonnes pratiques de cybersécurité. Il rend obligatoires des principes que les équipes les plus mûres appliquent déjà par discipline.
Pour une direction IT ou innovation, il s’agit bien sûr de se demander : « Comment se mettre en conformité d’ici 2027 ? » Mais aussi : « Nos partenaires de développement appliquent-ils déjà ces principes par défaut, ou faudra-t-il les imposer projet par projet ? »
Pour les organisations qui l’anticipent, c’est aussi un avantage concurrentiel réel. Un produit sécurisé dès sa conception et sécurisé par défaut inspire davantage confiance aux clients, aux partenaires et aux autorités de surveillance qu’un produit mis en conformité dans l’urgence à l’approche d’une échéance réglementaire.
En résumé
Que vous pilotiez une application déjà en production ou un projet en cours de cadrage, le bon moment pour intégrer ces principes, c’est maintenant. Plus la sécurité est pensée tôt, plus elle est efficace, plus elle est robuste, et moins elle coûte cher à maintenir.
Le CRA ne doit pas être vu comme une contrainte de dernière minute, mais comme un cadre qui pousse les organisations à professionnaliser encore davantage leurs pratiques de conception, de livraison et de maintenance.
Dans un contexte réglementaire en évolution, anticiper ces sujets permet non seulement de limiter les risques de sanctions, mais aussi de renforcer la confiance des clients, partenaires et donneurs d’ordre. La cybersécurité devient alors un véritable levier de résilience et de crédibilité pour l’entreprise. 💬Parlons-en !
Source : https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act
FAQ – Vos questions fréquentes sur le CRA et la sécurité applicative
Le CRA s’applique-t-il à une application développée pour un usage interne uniquement ?
En principe, le CRA vise les produits comportant des éléments numériques mis à disposition sur le marché. Une application strictement interne, non commercialisée et non distribuée à des tiers, peut donc se situer hors du périmètre du règlement. En revanche, dès qu’un produit est commercialisé, distribué à des clients ou intégré dans une offre, le sujet doit être réexaminé attentivement.
Qui est responsable si une ESN développe une application pour le compte d’un client ?
La responsabilité réglementaire dépend du montage réel de mise sur le marché. Le client peut être considéré comme fabricant s’il commercialise le produit sous sa marque ou le met à disposition sur le marché. Le contrat doit donc clarifier la répartition des responsabilités entre le donneur d’ordre et le prestataire.
Le CRA et NIS2 couvrent-ils la même chose ?
Non. Le CRA porte sur la cybersécurité des produits (logiciels ou matériels) comportant des éléments numériques. NIS2 concerne la cybersécurité des organisations et impose des obligations de gouvernance et de gestion des risques aux entités considérées comme essentielles ou importantes (santé, énergie, transport, etc.). Une même entreprise peut être concernée par les deux textes, mais pour des raisons différentes. Êtes-vous concernés ?
Quelles sont les sanctions en cas de non-conformité ?
Le CRA prévoit des sanctions importantes, pouvant inclure des amendes élevées (jusqu’à 15 millions d’euros ou 2,5% du CA annuel mondial de l’entreprise) et des mesures de retrait du marché pour les produits non conformes. Le détail dépend toutefois du type de manquement et de l’autorité compétente.
Vous souhaitez réagir ou en savoir plus ?
On vous offre un café et, en bonus, un entretien-conseil avec l’un de nos experts Cybersécurité, sans engagement. Vous êtes partant(e) ?