CRA & Open Source à OW2con’26 : retour d’atelier, guide v3 et cas LibreOffice

Le 2 juin 2026, l’équipe d’inno³ est intervenue aux côtés de Stéphane Fermigier (CNLL) à l’édition 2026 d’OW2con’26, autour de la thématique « Cyber Resilience Act (CRA) and impact on open source actors ». L’occasion de présenter les dernières évolutions du guide CRA & Open Source élaboré par inno³ et le CNLL, ainsi qu’un cas d’usage concret mené avec The Document Foundation autour de LibreOffice. Au-delà de la présentation, les discussions ont fait émerger des points d’attention qui dessinent les chantiers à venir pour tout l’écosystème.

Le CRA et son guide : où en est-on ?

La première partie de la session est revenue sur l’actualité du Cyber Resilience Act et du guide qui l’accompagne. Pour rappel, le CRA est un règlement européen destiné à renforcer la cybersécurité et la résilience des produits numériques commercialisés dans l’Union européenne. Les premières obligations entreront en application dès septembre 2026, avec la notification des vulnérabilités activement exploitées et des incidents graves. L’ensemble des exigences du règlement s’appliquera ensuite à partir du 11 décembre 2027 : déclaration de conformité, marquage CE et exigences de sécurité de l’Annexe I.

inno³ et le CNLL ont présenté à cette occasion une version améliorée de leur guide. Elle intègre les orientations publiées par la Commission européenne, qui viennent confirmer plusieurs interprétations importantes pour les actrices et acteurs de l’Open Source : une activité commerciale suppose une monétisation, les stewards (gestionnaires de logiciels libres) ne sont pas assimilés à des fabricants, et les contributrices et contributeurs restent hors du champ d’application. Ces orientations clarifient également le traitement à distance des données, les modifications substantielles, les périodes de support et la notion de vulnérabilités « connues ».

Des questions restent toutefois ouvertes — sur la non-rivalité du logiciel libre, les cas d’usage des PME ou encore le niveau de détail attendu pour les SBOM. C’est précisément pour faire valoir les spécificités de l’écosystème Open Source qu’inno³ et le CNLL ont contribué à la consultation européenne sur ce guide.

LibreOffice : un cas d’usage qui fera école

La conférence a aussi été l’occasion de présenter le travail mené pour The Document Foundation (TDF), qui donnera lieu à la matérialisation d’outils complémentaires qui seront intégrés à la prochaine version du guide. inno³ accompagne en effet la fondation dans la mise en place de sa déclaration de conformité et de son marquage CE.

La qualification de LibreOffice comme « produit comportant des éléments numériques mis sur le marché », et le souhait de The Document Foundation de se positionner comme fabricant (et/ou steward) imposent à la fondation de se conformer aux nouvelles obligations du CRA. L’accompagnement s’est structuré autour de plusieurs ateliers — qualification au regard de l’article 13, exigences de l’article 14 et de l’Annexe I, documentation de l’Annexe II — débouchant sur une analyse d’écart (gap analysis) puis un rapport d’évaluation.

Point important : la méthodologie et les livrables issus de cet accompagnement sont conçus pour être partagés publiquement et réutilisés par d’autres organisations Open Source. C’est tout l’intérêt de la démarche : faire d’un cas concret un commun méthodologique au bénéfice de l’ensemble de l’écosystème.

Ce que les échanges ont révélé

La présentation a été suivie d’une discussion ouverte avec les participantes et participants. Le tour de table a d’abord mis en évidence l’extrême hétérogénéité des profils concernés par le CRA — grands industriels, éditeurs, administrations, fondations — et un degré de compréhension du règlement très variable selon les communautés. Plusieurs points saillants méritent d’être relevés.

L’intention commerciale, pierre angulaire du périmètre. La notion d’intention commerciale a beaucoup occupé les échanges : c’est elle qui détermine qui est considéré comme « fabricant » au sens du règlement, en particulier lorsqu’un service est proposé. L’élément déterminant n’est pas le fait de demander une rémunération, mais sa finalité : la mise à disposition du logiciel vise-t-elle à générer des revenus, ou seulement à compenser les frais légitimes de développement et de maintenance ?

L’impact économique sur la conformité. La question du financement a tenu une place centrale. Les nouvelles exigences (suivi des vulnérabilités, maintenance, gestion des correctifs) représentent un investissement significatif en temps et en compétences, et risquent d’accentuer la pression sur des projets souvent portés par des ressources limitées. Deux lignes de force se sont dégagées : financer durablement la maintenance des logiciels utilisés dans des produits commerciaux devient la norme ; et les entreprises qui réutilisent ces composants ont une responsabilité dans cet équilibre. À ce titre, le CRA peut jouer un véritable rôle de levier pour inciter les organisations à contribuer aux projets Open Source dont elles dépendent.

Les SBOM : granularité, typologie et difficultés d’appariement. La nomenclature logicielle (Software Bill of Materials) prend une importance croissante, d’autant que le règlement impose sa fourniture sur demande des autorités. Les échanges ont fait apparaître plusieurs difficultés concrètes : un besoin de granularité accru et de meilleur appariement entre SBOM et description des vulnérabilités (CVE) ; l’existence de plusieurs types de SBOM selon la nature des objets décrits, les SBOM de bibliothèques appelant une approche spécifique ; et la couverture encore limitée des fichiers de configuration et des environnements de déploiement, angle mort persistant de l’analyse des risques.

Réduire la surface d’attaque : une logique déjà à l’œuvre. Une tendance de fond s’est confirmée : la réduction du nombre de fonctionnalités et de dépendances comme levier de sécurité, d’autant plus pertinente à l’heure où l’IA accélère la découverte de vulnérabilités. Une bonne pratique déjà en place pour de nombreux projets Open Source au travers de la modularisation et la conception de modules ou greffons autonomes (addons)

Une réglementation encore mouvante, une communauté à embarquer

Dernier enseignement, et non des moindres : le CRA n’est pas encore figé, et l’implication de la communauté reste possible. Plusieurs voix ont insisté sur le besoin de produire des documents traduisant un consensus communautaire, pour peser sur les modalités concrètes d’application.

C’est exactement la direction dans laquelle inno³ et le CNLL inscrivent leurs travaux : un guide vivant, nourri de cas réels comme celui de LibreOffice, et une méthodologie ouverte pour que la conformité reste accessible et renforce les petites structures comme les projets communautaires. La suite se jouera dans les prochains mois, à mesure que les premières obligations approchent — et nous comptons bien continuer à y contribuer.

Pour les personnes intéressées, l’effort de veille et d’analyse se poursuit au sein du groupe de travail du CNLL dédié au Cyber Resilience Act. Les organisations souhaitant contribuer activement à l’élaboration de ces modèles sont invitées à se rapprocher du CNLL ou d’inno³, ou directement sur mission-cra-cnll@framagroupes.org.

Le guide et les modalités de participation sont disponibles sur les sites inno3.fr et cnll.fr.