Open Source et Cyber Resilience Act : décryptage du régime allégé

Les premières versions du Cyber Resilience Act (CRA) avaient suscité une vive inquiétude au sein de la communauté open source. Dans sa version finale (règlement UE 2024/2847), le législateur européen a clarifié les règles : les logiciels libres bénéficient désormais de garde-fous précis et, pour certaines structures, d'un régime allégé adapté à leur réalité technique et collaborative.

La frontière entre activité commerciale et non commerciale

Le critère central d'application du CRA repose sur la notion d'activité commerciale. Les logiciels open source développés ou distribués hors cadre marchand sont exclus du champ d'application. Un développeur indépendant publiant un projet sous licence libre sans contrepartie financière n'est donc pas soumis aux exigences de conformité du règlement.

À l'inverse, l'activité est qualifiée de commerciale dans les situations suivantes :

• Le logiciel est monétisé via des abonnements, des licences payantes ou du support technique commercial assuré par les mainteneurs.
• Le projet est financé ou contrôlé par une entité qui en retire un avantage concurrentiel direct sur le marché.
• Le code open source est intégré dans un produit logiciel, un service SaaS ou un équipement connecté commercialisé au sein de l'Union européenne.

Le statut d'intendant de logiciel libre (Open Source Steward)

Pour les fondations à but non lucratif qui soutiennent des projets critiques (ex: Fondation Linux, Apache, Eclipse), le CRA instaure le statut d'intendant de logiciels libres (Open Source Software Steward). Ce statut reconnaît leur rôle de tiers de confiance dans l'écosystème.

L'intendant n'est pas considéré comme un fabricant au sens strict, car il ne commercialise pas le produit final. Il est ainsi exempté des contraintes lourdes imposées aux éditeurs marchands, comme l'évaluation de conformité formelle ou l'apposition du marquage CE.

Les obligations du régime allégé pour les intendants

Ce régime allégé impose des mesures proportionnées pour garantir la sécurité de la chaîne d'approvisionnement logicielle :

1. Mettre en place une politique documentée de traitement et de divulgation coordonnée des vulnérabilités (CVD).
2. Coopérer avec les autorités de surveillance du marché et notifier sans délai les vulnérabilités activement exploitées.
3. Promouvoir le partage de correctifs et l'adoption de pratiques de développement sécurisé au sein de la communauté.

Responsabilité des éditeurs intégrant des composants open source

Si le mainteneur bénévole ou l'intendant bénéficie d'un statut protégé, la charge de la conformité repose entièrement sur l'éditeur qui intègre ces briques dans un produit commercial. Dès lors qu'une dépendance open source est incluse dans votre solution, vous en devenez juridiquement responsable vis-à-vis du régulateur européen.

Chaque entreprise doit donc documenter ses composants tiers, surveiller activement les vulnérabilités et garantir la capacité à déployer des correctifs de sécurité tout au long du cycle de vie du produit.

Anticiper les échéances et sécuriser votre supply chain

Le calendrier réglementaire est strict : l'obligation de signalement des vulnérabilités exploitées s'applique dès le 11 septembre 2026, et l'ensemble des obligations techniques le 11 décembre 2027. Les sanctions peuvent atteindre 15 millions d'euros ou 2,5 % du chiffre d'affaires mondial.

Pour accompagner les équipes techniques, CRAcheck permet de connecter vos dépôts GitHub afin de générer automatiquement un inventaire de dépendances (SBOM) sur 9 écosystèmes. L'outil identifie les failles connues et prépare la documentation de conformité requise, incluant le fichier SECURITY.md et le suivi technique.