Cyber Resilience Act et Open Source : transformer une obligation réglementaire en levier stratégique
En synthèse, le Cyber Resilience Act (CRA) combine trois facteurs de succès pour transformer cette obligation réglementaire en levier stratégique :
1️⃣ Standardisation : le CRA harmonise la cybersécurité en UE (2026-2027), clarifiant les responsabilités sur toute la chaîne logicielle.
2️⃣ Open Source protégé : les projets communautaires non commerciaux sont exclus de ces obligations, favorisant l’innovation et le rôle des Open Source Stewards.
3️⃣ Conformité = transformation : SBOM, gestion des vulnérabilités et intégration des processus deviennent des leviers de résilience et de confiance.
Depuis la publication du Cyber Resilience Act (CRA) fin 2024, les acteurs du numérique ont un horizon clair concernant les exigences de cybersécurité applicables aux produits numériques qu’ils commercialisent dans l’Union européenne (fin 2026 pour certain, fin 2027 pour tous les autres). Nous avions publié l’an dernier un guide dédié au CRA dans le cadre des pratiques de l’Open Source.
Au fil de trois interventions récentes — un webinaire interne à Numeum, un autre inno³ & SMILE, et une intervention avec Stéfane Fermigier (CNLL) lors du Red Hat Summit — un message néanmoins positif a été partagé quant à ces nouvelles directives. Le CRA vient harmoniser les pratiques et reformuler les responsabilités autour des chaînes logicielles, tout en ouvrant de nouvelles perspectives pour structurer l’innovation autour de modèles ouverts. Il ne faut donc pas voir cette réglementation comme une nouvelle contrainte, mais au contraire comme une standardisation accélérée et fluidifiée sous l’impulsion d’un législateur conscient de la nécessité d’accompagner la transition.
Ces bonnes pratiques conduisent à mettre en œuvre une démarche de conformité (ce qui n’est pas une culture encore unanimement partagée) au sein de chaque organisation, mais aussi de prévoir et d’outiller les processus humains et organisationnels afin d’être en capacité d’opérer une telle gestion aux travers de politiques dédiées. Pour celles et ceux qui réfléchissent à cette mise en conformité, c’est l’occasion idéale de s’appuyer sur la définition et mise en œuvre d’une politique Open Source en interne : les deux s’appuient sur une connaissance exhaustive des composants (Open Source ou non) utilisés, la définition de processus adaptés aux typologies de produits commercialisés et leurs modalités d’exploitations, ainsi que sur des processus animés et suivi par la constitution d’une commission dédiée (souvent dénommée OSPO pour Open Source Program Office)
Quelques uns de ces points sont développés ci-après.
Un pouvoir de régulation du marché intérieur affirmé et confirmé
Le CRA matérialise une approche de régulation du marché intérieur de l’Union européenne qui est dans la lignée du règlement 2019/1020 sur la surveillance du marché et la conformité des produits (qui complète le New Legislative framework de 2008).
Elle fait de la cyber sécurité un axe majeur, dans la continuité de réglementations générales telles que NIS (2016), le Cybersecurity Act (2019), NIS 2 (2022) ou encore de réglementations spéciales applicables au xservices financiers (tel le Digital Operational Resilience Act dit DORA applicable dès 2025) ou du paiement et aux équipements médicaux ou radio, etc.
À cela s’ajoutent des textes transversaux, mais aux effets sectoriels prononcés, tels que l’Artificial Intelligence Act (AI Act) de 2024 imposant des exigences pour les systèmes à haut risque, ou la directive CER (2022) renforçant la résilience des entités critiques dans des secteurs sensibles. Le tout impose un certain nombre de bonnes pratiques dont le non-respect pourra être autant de bases d’indemnisation sur le fondement de la directive relative aux produits défectueux (NPLD pour New Product Liability Directive) de 2025.
Cette complexité apparente, qui reflète la complexité factuelle de notre société numérique moderne, n’est néanmoins pas nécessairement synonyme d’une lourdeur inutile. D’une part une certaine homogénéisation s’observe entre ces différents textes complémentaires. Le train de mesures « omnibus » présenté par la Commission européenne le mercredi 19 novembre 2025 – qui n’englobe que très partiellement et accessoirement ces aspects – matérialise cette tendance à l’harmonisation et à la simplification. D’autre part, ces différents cadres viennent simplifier par l’harmonisation des pratiques hétérogènes. Enfin, le numérique est aussi un allié pour venir appréhender et réduire cette complexité, permettant de créer des outils qui partagent le traitement et l’automatise.
Le projet Hermine-FOSS, s’il est initialement prévu pour saisir la complexité de l’écosystème juridique de l’Open Source, est un bon exemple d’un outil permettant à la fois d’agréger une connaissance exhaustive de l’ensemble des composants tiers utilisés (par version par produits par catégorie de produits) d’automatiser le traitement de licences (contrats) et d’implémenter automatiquement un certain nombre de politiques au sein de l’organisation. Voir aussi le panel « Conformité Cybersécurité et Open Source : vers une approche outillée unifiée autour des SBOM » qui prolongera ces réflexions durant OSXP 2025
Une évolution réglementaire qui clarifie les responsabilités tout au long de la chaîne logicielle
Le CRA standardise un certain nombre de bonnes pratiques, qui deviennent obligatoires pour tout acteur économique opérant sur le marché européen :
- la mise en place d’une documentation technique complète, incluant une nomenclature logicielle complète (dite SBOM, dans un format tel que SPDX ou CycloneDX) ;
- la gestion continue des vulnérabilités durant au moins cinq ans ;
- une politique de cybersécurité alignée sur les pratiques DevSecOps ;
Ces obligations répondent à un constat partagé : les chaînes logicielles actuelles sont complexes, largement transversales et souvent insuffisamment documentées. Les incidents récents (Log4Shell, XZ, compromissions NPM) ont mis en lumière des dépendances critiques qui, faute de soutien, fragilisent l’ensemble de l’écosystème.
Le schéma qui suit permet d’identifier les produits de l’organisation qui sont potentiellement concernés par le CRA (avec des obligations plus ou moins importantes selon les catégories de produits concernés) :
Le CRA prévoit une liste de personnes spécifiquement concernées (étant entendu que le reste des responsabilités suivra le jeu contractuel habituel) :
Auteur/Autrice
Collectif inno³
Ressources associées
Article
Cyber Resilience Act et Open Source : transformer une obligation réglementaire en levier stratégique
Article
L’impact de la NPLD sur l’écosystème Open Source
Article
Pourquoi le Cyber Resilience Act devrait favoriser une valorisation par l’Open Source au sein des établissements de recherche ?
Article
Produire et maintenir une Software Bills of Materials (SBOM) : enjeux et pistes futures
À termes, une prise en compte collective de ces enjeux, appuyée par une connaissance précise des composants et des acteurs de la supply chain, pourra permettre de viser une véritable résilience des organisations. Cela pourra se faire au travers des informations partagées et collectivement contrôlées. C’est sur cet axe, en alliant une approche communautaire et industrielle, que nous travaillons actuellement conjointement, inno³ et Examin, afin de proposer des modalités de mesure et de pilotage automatisables de la résilience (en s’appuyant à la fois sur les premiers indicateurs publiés en France et en Europe).
Une exception Open Source conçue pour préserver la capacité d’innovation
Le CRA maintient un principe fort : les projets Open Source communautaires, lorsqu’ils ne font l’objet d’une activité commerciale directement liée restent en dehors de son périmètre. Ce régime dérogatoire vise à préserver la dynamique des communs numériques et l’innovation qui caractérise ces écosystèmes ouverts. C’est aussi, d’une certaine manière, la reconnaissance d’une limite à une régulation par le jeu du marché face à ces pratiques qui le dépassent et qui peuvent, sous certaines réserves, parfois palier aux faiblesses du marché (et ne nécessitent ainsi pas la même régulation).
Cette distinction ouvre la voie à des modèles hybrides :
- diffusion communautaire : au travers d’une structure dédiée ou au sein d’un collectif organisé,
- offres commerciales accompagnées, documentées et maintenues : ce qui permet de gommer certaines zones de floues entre les offres communautaires et les offres commerciales de certains éditeurs
- structuration d’écosystèmes ouverts de confiance. Le CRA reconnait un rôle nouveau et structurant d’Open Source Steward (intendant de logiciel ouvert) qui est présenté comme partenaire de confiance des régulateurs.
Ces approches s’alignent sur les travaux conduits par inno³ autour de la gouvernance, de la conformité Open Source et des stratégies de diffusion. Elles questionnent et permettent d’affiner de certaines typologies d’acteurs, certaines étant plus fortement chamboulées tels que les centres de recherche.
De la conformité à la transformation organisationnelle
La mise en conformité CRA dépasse largement la seule lecture juridique. Les organisations doivent se repenser à la fois dans leur organisation interne et dans leurs relations externes.
Ainsi, il s’agira en interne de :
- formaliser une politique Open Source articulée avec la politique de cybersécurité ;
- intégrer l’automatisation SBOM dans les chaînes CI/CD ;
- acculturer en interne et clarifier les rôles et responsabilités (correspondant Open Source, RSSI, juristes, équipes produit) ;
- étendre l’analyse aux dépendances transitives.
En externe, il s’agira surtout de réfléchir à la manière de
- contractualiser la fourniture des SBOM et la remédiation des vulnérabilités ;
- renforcer les relations avec les projets upstream (projet Open Source d’origine) ;
- garantir une coordination des correctifs et de l’information de sécurité.
Vers une chaîne de conformité ouverte, interopérable et outillée
Ces réflexions mettent en évidence un besoin commun : disposer d’une chaîne de conformité unifiée, ouverte et interopérable, reliant transparence, gestion des vulnérabilités, exigences réglementaires et contribution aux communs Open Source.
Une telle ambition est précisément celle du consortium ConCyOS (Conformité Open Source et Cyber) initié en 2025 et réunissant Thales, inno³, Examin et l’INRIA afin d’outiller la production et la circulation des SBOM, d’améliorer l’interopérabilité entre acteurs, de renforcer la confiance dans les composants Open Source (sur des enjeux de cyber, de conformité aux licences OS, mais aussi de maturité des mainteneurs) et d’intégrer les cadres de conformité dans les pratiques industrielles.
Conclusion
L’entrée en vigueur du CRA accélère la transformation des pratiques industrielles. Loin de constituer une simple contrainte, cette évolution ouvre une opportunité : définir et adopter des standards permettant de mettre au centre des projets numérique les enjeux de soutenabilité, de sécurité et de conformité).
L’enjeu collectif reste de développer des outils ouverts, de renforcer la coopération au sein et avec les communautés, et enfin de consolider des cadres de confiance permettant à l’Open Source de rester un moteur d’innovation, de résilience et de souveraineté. Ces différents axes font partie intégrante de notre stratégie de recherche au sein d’inno³ et seront ainsi développés durant les trois années à venir. Dans cet esprit d’ouverture et de contribution à l’écosystème, nous partagerons dans les prochains mois les réflexions menées avec notre partenaire Examin afin de les développer dans une approche ouverte et communautaire.