Cyber Resilience Act : apports, limites et portée réelle de la guidance de la Commission

La Commission européenne a approuvé le 27 juillet 2026 le contenu de sa guidance sur l’application du Cyber Resilience Act : un chapitre entier est consacré aux logiciels libres et Open Source. Le document ne sera formellement adopté, et ne s’appliquera, qu’une fois toutes les versions linguistiques disponibles. Fruit d’un processus ouvert auquel inno³ et le CNLL ont contribué, il apporte des réponses concrètes et bienvenues. Il suscite aussi quelques questions, d’autant plus importantes, compte tenu sa portée juridique relative. Analyse en quatre temps, à six semaines de l’entrée en application des obligations de notification (le 11 septembre 2026).

Ce que la guidance sur l’application du Cyber Resilience Act apporte

Le chapitre consacré au FOSS est le plus détaillé jamais publié par la Commission : une vingtaine d’exemples et un logigramme officiel (la première des dix figures du document) viennent outiller la grille que nous défendons depuis la première version du guide CNLL × inno³.

Le critère de la monétisation est détaillé : le financement d’un projet (subventions, sponsoring, contrats de développement), les contributions et la régularité des releases ne déclenchent pas les obligations. Aussi, il est possible de vendre du service (conseil, formation ou autre accompagnement au déploiement autour d’un logiciel libre public) sans qu’il y ait de mise sur le marché de ce logiciel. La bascule n’intervient que lorsque l’accès au produit lui-même, maintenance comprise, est conditionné à rémunération.

La guidance rappelle qu’un même acteur peut être fabricant de son édition commerciale et steward de sa version communautaire. Les fondations voient leurs obligations de notification graduées selon la nature de leur soutien : gouvernance seule, hébergement d’infrastructure, ou ressources d’ingénierie. Autant de points sur lesquels la guidance va parfois plus loin que la lecture prudente de la v2 de notre guide et qui seront intégrés dans la v3.

De plus, contribuer du code à un projet qu’on ne contrôle pas (via de simples pull request) reste hors champ. Il en va de même pour le partage de code sur un dépôt public, le code non finalisé (versions alpha, bêta, release candidates) ou encore les forges et registres de paquets pour les composants qu’ils hébergent.

La guidance clarifie également la notion de traitement de données à distance couvert par le règlement, via deux critères cumulatifs : 1) nécessité fonctionnelle pour le produit et 2) conception sous la responsabilité du fabricant. Ainsi, un service SaaS tiers reste hors périmètre, mais doit être traité comme composant à risque, alors qu’un backend développé sur mesure (IaaS/PaaS) en fait partie intégrante.

La mise sur le marché s’apprécie désormais par version. Le CRA n’était pas clair et les débats nombreux. Toutes les copies d’une même version non modifiée sont réputées placées sur le marché à la date de sa première offre, une modification substantielle valant nouveau placement. Chaque version substantiellement modifiée doit afficher sa période de support (cinq ans étant un plancher, pas un forfait). L’article 13(10) permet par ailleurs, lorsque les versions substantiellement modifiées se succèdent, de concentrer la correction des vulnérabilités sur la dernière version, dès lors que la mise à niveau est gratuite (cette dérogation est toutefois étroite et ne porte que sur l’obligation de correction sans délai, ainsi la SBOM, les autres exigences de traitement des vulnérabilités et les notifications de l’article 14 restent dus).

Enfin, la notification est décrite dans les deux sens : vers l’ENISA à partir du 11 septembre, mais aussi en upstream (projets en amont). Cela s’accompagne de l’obligation de signaler les vulnérabilités des composants intégrés sans doublonner ce qui est connu et de partager ses correctifs sous une forme compatible avec la licence de la dépendance. Ce cadre est important, car, correctement exécutées, ces obligations deviennent des flux qui reviennent vers les projets (c’est le levier que nous décrivons depuis 2024) alors que, mal exécutées, ces contributions peuvent venir saturer inutilement les projets.

Ce que la guidance ne règle pas (et ce qui interroge)

Plusieurs difficultés documentées dans le guide restent sans réponse :

• Les SBOM, pour commencer par le plus important : pas une ligne de l’annexe ne traite de leur granularité, de leurs formats ou de leur articulation avec les obligations des licences, alors que ce sont les questions concrètes que rencontrent tous les projets, comme l’avaient encore montré les échanges d’OW2con’26 ;
• Les programmes volontaires d’attestation de sécurité des logiciels libres (article 25), ne sont pas détaillés, alors qu’attendus par bon nombre de projets Open Source;
• La guidance renonce expressément à dresser la liste des licences éligibles et ne détaille pas le contenu attendu de la politique de cybersécurité des stewards. Cela laisse supposer un accord sur le principe du renvoi à l’Open Source définition, mais les règlements européens ne sont pas si clairs sur ce sujet ;
• Enfin, aucun signe des actes délégués attendus, n’est présent, alors qu’ils constituent le principal espace où l’écosystème peut encore façonner des règles à son avantage. Les premières normes harmonisées, enfin, restent attendues pour la fin août 2026. Enfin, aucun signe des actes délégués attendus n’est présent, alors qu’ils constituent le principal espace où l’écosystème peut encore façonner des règles à son avantage. Quant aux normes harmonisées, aucune n’est à ce jour citée au Journal officiel (la présomption de conformité de l’article 27 n’est donc ouverte pour aucune catégorie de produit) : l’échéance pour les deux premières normes horizontales initialement fixée au 30 août 2026 fait l’objet depuis le 7 juillet d’un projet de report au 30 octobre 2026.

À la lecture de la guidance, certaines positions protectrices reposent sur des concepts flous qui interrogent sur leur efficacité. Ainsi, une personne physique peut facturer une assistance couvrant ses coûts réels, « y compris un niveau de vie raisonnable » (reasonable living expenses), sans basculer dans le champ commercial.

L’intention est excellente, mais elle pose la question de savoir qui interprétera, et sur quelle base, une notion dont le contenu varie fortement d’un État membre à l’autre, et au sein même de chaque pays. Mon niveau de vie reste-t-il « raisonnable » si je roule en berline électrique neuve plutôt qu’en citadine des années 90 ? Faute de méthode d’évaluation, cette souplesse (bienvenue) pourrait produire exactement ce que la guidance veut éviter : au mieux des applications hétérogènes, au pire des sanctions non souhaitables de développeurs.

Dans le même esprit, deux autres points appellent la vigilance :

• L’annexe exige un code source publiquement disponible pour la qualification FOSS, ce qui écarte des pratiques pourtant conformes aux licences copyleft, comme la fourniture du code aux seuls destinataires des binaires ;
• Par ailleurs, elle attribue quasi automatiquement le rôle de steward à toute personne morale publiant une version communautaire, là où le règlement pose des conditions de soutien systématique et durable (les éditeurs open-core auront intérêt à vérifier finement leur situation).

Quelle valeur juridique ?

Cette guidance n’est pas pour autant une communication spontanée : son principe et son contenu minimal sont prescrits par l’article 26 du règlement, qui impose à la Commission de publier des orientations, avec une attention particulière aux micro-entreprises et PME.

Néanmoins sa valeur juridique mérite d’être clarifiée : n’étant qu’une communication interprétative, elle ne lie personne et seul le règlement fait foi. La Commission le dit elle-même. Elle produira pourtant des effets bien réels : autorités de surveillance du marché et organismes notifiés s’y référeront, et l’on voit mal une autorité reprocher à un acteur d’avoir suivi de bonne foi l’interprétation publiée par la Commission. La Cour de justice a d’ailleurs jugé, à propos des recommandations, que les juridictions nationales doivent « prendre en considération » les instruments non contraignants lorsqu’ils éclairent l’interprétation du droit applicable (arrêt Grimaldi, C-322/88). Cette logique est transposable à une communication de ce type, dès lors que l’interprétation ne vient pas contredire la règle — or il nous semble précisément que le CRA et l’Open Source sont venus conjointement chambouler un ensemble de réglementations et de pratiques antérieures (ne serait ce que le fait d’acter que le logiciel est un « produit ».

Notre principale réserve est ainsi sur plusieurs positions de l’annexe, favorables ou défavorables, qui procèdent de lectures extensives du texte telles que la neutralisation des dons excédant les coûts (que le considérant 15 range pourtant parmi les indices de commercialité) ou l’intégration du niveau de vie dans les coûts récupérables. Rien ne garantit qu’un juge les suivrait. À l’inverse, une position plus stricte que le règlement lui serait tout autant inopposable. S’ajoute à cela que le Blue Guide, socle méthodologique sur lequel la guidance s’appuie, est lui-même une communication dépourvue de valeur normative.

La recommandation sera donc certainement de veiller à se constituer une documentation probatoire (comptabilité des coûts, statuts, traçabilité de la réaffectation des excédents) venant s’appuyer sur cette guidance tout en restant autoportante autant que possible.

Quelques éléments pour la suite (v3 guide Cyber Resilience Act)

Cette publication n’arrive pas en terrain vierge. Avec le CNLL, nous avions contribué à la consultation de mars pour faire valoir les spécificités de l’écosystème, dans le prolongement du guide « Être prêt pour intégrer le Cyber Resilience Act dans sa pratique Open Source », dont la version 2.0 est parue en décembre 2025 (CC BY-SA, français et anglais). La version 3 intégrera la guidance : alignement de notre logigramme sur le logigramme officiel, correspondance entre nos personas et les exemples de l’annexe, et mise à jour des points où la Commission s’est montrée plus ouverte que nous.

Elle s’appuiera aussi sur du concret : l’accompagnement de The Document Foundation vers la conformité de LibreOffice, présenté à OW2con’26 aux côtés du CNLL. Ateliers de qualification (article 13, article 14 et Annexe I, Annexe II), analyse d’écart, cap vers le marquage CE : la démarche et ses livrables sont conçus comme un commun méthodologique, réutilisable par d’autres organisations. La guidance conforte cette approche, des scénarios consacrés aux fondations jusqu’à la gradation des obligations des stewards, et sera intégrée au rapport d’évaluation en cours. Le groupe de travail CRA du CNLL reste ouvert aux organisations qui souhaitent rejoindre ce travail collectif : mission-cra-cnll@framagroupes.org (n’hésitez pas à nous écrire).