Vers une résilience numérique "conçue" et partagée
En Europe comme ailleurs, on assiste à un changement profond : la cybersécurité n'est plus uniquement une question d'opérations ou de réaction aux incidents.
Elle devient une propriété intrinsèque des produits, des chaînes d’approvisionnement et des écosystèmes numériques.
Dans ce contexte, le Cyber Resilience Act (CRA) s’inscrit clairement dans une logique de rééquilibrage des responsabilités. Historiquement, une grande partie du risque cyber reposait sur les opérateurs — les entreprises qui utilisent la technologie. Aujourd’hui, avec le CRA, une partie de cette responsabilité remonte vers les fabricants et les éditeurs, c’est-à-dire vers ceux qui conçoivent et distribuent les produits numériques.
Une architecture européenne en couches : CRA, NIS2, DORA
Ce qui est intéressant, c’est que le CRA ne fonctionne pas seul. Il s’articule avec d’autres cadres comme NIS2 et DORA, qui opèrent à des niveaux différents mais complémentaires.
Le CRA traite la sécurité au niveau du produit.
NIS2 adresse la sécurité des organisations et de leurs opérations.
DORA renforce la résilience du secteur financier, notamment sur les tiers ICT.
En réalité, ces textes forment une architecture cohérente : sécurisation des produits → sécurisation des opérations → résilience sectorielle.
Le CRA vient combler un angle mort important : jusqu’à présent, les entreprises devaient gérer le risque de leurs fournisseurs sans toujours avoir de visibilité suffisante sur la sécurité des composants eux-mêmes. En imposant davantage de transparence et de responsabilité du côté des fabricants, il renforce indirectement l’efficacité de NIS2 et de DORA.
Une convergence mondiale, malgré des approches différentes
Ce mouvement n’est pas propre à l’Europe. On observe une convergence globale sur les objectifs, même si les chemins diffèrent.
Aux États-Unis par exemple, l’accent est mis sur la transparence (SBOM), la divulgation des vulnérabilités et la sécurisation de la supply chain. À Singapour ou en Australie (APRA), les régulateurs se concentrent historiquement sur les opérateurs, mais avec une attention croissante portée aux dépendances technologiques.
Ce qui se dessine, c’est une double transformation :
- Un “shift-left” : la sécurité intégrée dès la conception
- Un "shift-up” : la responsabilité qui remonte dans la chaîne de valeur
On passe d’une cybersécurité gérée en aval à une résilience conçue en amont.
Le rôle central — et souvent sous-estimé — de l’open source
Dans ce paysage, il y a un élément absolument structurant : l’open source.
La grande majorité des logiciels modernes repose aujourd’hui sur des composants open source. Le CRA ne régule pas directement ces projets, mais il transforme profondément la manière dont ils sont utilisés.
En pratique la liberté d’usage reste intacte mais la responsabilité repose désormais davantage sur ceux qui intègrent et distribuent ces composants.
Cela révèle une réalité que l’industrie connaît depuis longtemps : une grande partie de l’infrastructure numérique mondiale repose sur des briques open source maintenues par des communautés parfois très limitées.
Le sujet central n’est donc pas le risque de l’open source en soi, mais plutôt le déséquilibre entre son importance critique et les ressources qui lui sont allouées**.
Vers une logique de " bien commun numérique "
C’est là qu’émerge une idée clé, de plus en plus partagée : celle de “protéger les communs numériques ensemble”.
L’open source peut être vu comme une forme de bien public mondial qui est accessible, mutualisé et fondamental pour l’innovation. Mais un bien commun ne peut rester résilient sans gouvernance, investissement et engagement collectif.
Le CRA, indirectement, accélère cette prise de conscience. Il ne peut pas, à lui seul, sécuriser l’open source. Mais il crée les conditions pour que l’écosystème évolue vers plus de responsabilité et de structuration.
Du modèle de consommation au modèle de responsabilité
Ce que l’on observe aujourd’hui, c’est un basculement. Avant les entreprises consommaient de l’open source mais aujourd’hui, elles doivent en devenir des acteurs responsables. Cela se traduit concrètement par une meilleure visibilité sur les dépendances (SBOM), une contribution plus active aux projets critiques, un soutien accru aux mainteneurs et une gestion plus rigoureuse du cycle de vie.
La résilience ne dépend plus seulement de ce que l’on utilise, mais de la manière dont on contribue à l’écosystème.
Transparence et limites : le cas des SBOM
Le CRA met également en avant des outils comme les SBOM (Software Bill of Materials). C’est une évolution importante en matière de transparence. Mais il faut être lucide, une SBOM est un point de départ, pas une solution. La vraie valeur réside dans la capacité à maintenir ces informations à jour et à les exploiter. Cela renforce l’idée que la cybersécurité devient une discipline continue et opérationnelle, et non plus statique ou déclarative.
Une approche en 3 étapes : Alignement, pragmatisme et approche systémique
Dans ce contexte, il est essentiel d’avoir une logique d’alignement avec ces évolutions de fond. Trois idées clés structurent cette approche :
1. S’inscrire dans le mouvement "secure-by-design"
Il ne s’agit pas d’une rupture totale, mais d’une accélération :
- Formalisation des pratiques
- Renforcement de la traçabilité
- Extension à l’ensemble du cycle de vie
2. Adopter une vision globale et intégrée
Les clients ne font pas face à une seule réglementation, mais à un paysage complexe (CRA, NIS2, DORA, exigences internationales). L’enjeu devient non pas de répondre à chaque texte individuellement, mais d’adopter des approches cohérentes à l’échelle globale.
3. Contribuer à l’écosystème open source
Dans une logique de “commons”, la sécurité ne peut pas être uniquement internalisée. Cela passe par la participation à des initiatives collectives, l’amélioration de la transparence et de la gouvernance et le soutien à la durabilité des projets critiques.
Des initiatives comme le Project Lightwell ou d’autres démarches autour de la sécurisation des écosystèmes illustrent cette orientation : faire évoluer l’open source vers davantage de robustesse, de visibilité et de maintenabilité à l’échelle industrielle.
Conclusion : une transformation structurelle, pas uniquement réglementaire
Au fond, le Cyber Resilience Act est la partie émergée d’un changement plus profond. On passe d’une cybersécurité réactive à une résilience conçue, d’une responsabilité locale à une responsabilité distribuée et d’une utilisation de l’open source à une gestion collective du bien commun numérique. La question n’est plus seulement " comment sécuriser ", mais " comment co-construire durablement un écosystème numérique résilient ".