La question se pose sous trois formes, et le règlement sur la cyberrésilience, règlement (UE) 2024/2847, répond différemment à chacune. Un mainteneur qui publie une bibliothèque sur GitHub. Une entreprise dont le produit est construit sur cette bibliothèque. Une fondation qui maintient la bibliothèque en vie. Un seul des trois est fabricant, et l'un des deux autres a un régime propre.

Cas un : un logiciel libre qui n'est pas monétisé

Considérant 18 : « seuls les logiciels libres et ouverts mis à disposition sur le marché, et donc fournis en vue d'une distribution ou d'une utilisation dans le cadre d'une activité commerciale, devraient relever du champ d'application du présent règlement ». Et plus précisément : « la fourniture de produits comportant des éléments numériques qui sont des logiciels libres et ouverts et qui ne sont pas monétisés par leurs fabricants ne devrait pas être considérée comme une activité commerciale ».

Le considérant 20 ajoute que l'hébergement sur un dépôt, un gestionnaire de paquets ou une plateforme collaborative « ne constitue pas en soi la mise à disposition sur le marché », et le considérant 18 que le mode de financement du développement ne tranche pas non plus la question.

Une bibliothèque publiée sous licence libre, sans version payante, sans support payant qui lui soit lié ni arrangement commercial autour de sa fourniture, est donc hors des obligations du fabricant. Son auteur n'a pas de marquage CE à apposer, pas de dossier technique, pas d'obligation au titre de l'article 14. L'article 15 lui permet de signaler des vulnérabilités volontairement ; rien ne l'y oblige.

Cas deux : un produit commercial construit sur des composants libres

L'entreprise qui intègre cette bibliothèque dans un produit qu'elle met sur le marché est fabricant de ce produit. La licence du composant n'y change rien. L'annexe I s'applique à tout le produit, la SBOM liste le composant, et l'article 13, paragraphe 5, impose au fabricant de faire preuve de diligence lorsqu'il intègre des composants de tiers, y compris libres, afin qu'ils ne compromettent pas la sécurité du produit.

L'article 32, paragraphe 5, accorde un allègement : un produit libre et ouvert relevant d'une catégorie de l'annexe III peut encore utiliser la procédure d'auto-évaluation, à condition que sa documentation technique soit rendue publique lors de la mise sur le marché. Cela vise les produits libres eux-mêmes mis sur le marché commercialement, pas les composants à l'intérieur d'un produit propriétaire.

Le considérant 21 prévoit des programmes volontaires d'attestation de sécurité pour les composants libres, pour que la diligence d'un fabricant ait quelque chose sur quoi s'appuyer. Aucun n'a encore été établi.

Cas trois : le gestionnaire de logiciels libres

L'article 3, point 14, définit le gestionnaire comme « une personne morale, autre qu'un fabricant, qui a pour but ou objectif d'apporter systématiquement un soutien durable au développement de produits spécifiques comportant des éléments numériques qui sont des logiciels libres et ouverts et sont destinés à des activités commerciales, et qui assure la viabilité de ces produits ». Le considérant 19 en nomme le type : certaines fondations, et des entités qui développent et publient des logiciels libres dans un contexte professionnel, y compris des entités à but non lucratif.

« Destinés à des activités commerciales » est le pivot. Le considérant 19 dit que cela inclut l'intégration dans des services commerciaux ou des produits monétisés, et que l'intention existe lorsque des fabricants qui intègrent le composant contribuent régulièrement à son développement ou le financent régulièrement. Une fondation dont le projet est embarqué dans des produits commerciaux à travers l'industrie est un gestionnaire. Un projet de loisir sans relation de ce type ne l'est pas.

L'article 24 donne aux gestionnaires un régime que le règlement lui-même qualifie d'allégé :

Une politique de cybersécurité, documentée de manière vérifiable (article 24, paragraphe 1), favorisant un développement sûr et une gestion efficace des vulnérabilités par les développeurs du projet, y compris la documentation, le traitement et la correction des vulnérabilités, le partage d'informations sur les vulnérabilités découvertes au sein de la communauté, et l'encouragement au signalement volontaire de l'article 15.

La coopération avec les autorités de surveillance du marché à leur demande (article 24, paragraphe 2), et la fourniture de cette politique à une autorité sur demande motivée.

Un article 14 restreint. Article 24, paragraphe 3 : l'obligation de notifier les vulnérabilités activement exploitées s'applique aux gestionnaires « dans la mesure où ils participent au développement » du produit ; l'obligation de notifier les incidents graves, et d'informer les utilisateurs, s'applique « dans la mesure où des incidents graves ... touchent les réseaux et systèmes d'information fournis par les gestionnaires de logiciels libres pour le développement de ces produits ». Les horloges sont les mêmes 24 et 72 heures, vers le même CSIRT et l'ENISA.

Ce qu'un gestionnaire n'a pas : les obligations de l'annexe I pour le produit, un dossier technique, une évaluation de la conformité, un marquage CE, une déclaration de conformité, une période d'assistance. L'article 24 est tout. Et l'article 64, paragraphe 10, point b), dit que les amendes administratives de l'article 64 « ne s'appliquent pas » aux infractions au règlement commises par des gestionnaires de logiciels libres ; les autres mesures correctives d'une autorité de surveillance du marché demeurent.

Quoi décider, et écrire

Quel cas est le vôtre. Si vous publiez du libre et ne monétisez rien autour, écrivez-le, avec la date, parce que « non monétisé » est un fait sur votre activité qui peut changer. Si vous livrez un produit construit sur des composants libres, vous êtes dans le cas deux et les douze étapes s'appliquent en entier. Si vous soutenez un projet dont dépendent des produits commerciaux, vous êtes gestionnaire : rédigez la politique de l'article 24, paragraphe 1, nommez la personne qui répond à une autorité, et décidez comment vous apprendriez, et notifieriez, une vulnérabilité activement exploitée dans le projet.

Les orientations de la Commission du 27 juillet 2026 font des deux considérants sept tests avec 22 exemples traités : où atterrissent un lien de don, un palier de support payant, une édition open core et une fondation est l'article compagnon de celui-ci.

Sources

  • Règlement (UE) 2024/2847, article 3, point 14 (cité), article 13, paragraphe 5, article 15, article 24, paragraphes 1 à 3 (cités), article 32, paragraphe 5, article 64, paragraphe 10, point b) ; considérants 17 à 21 (cités). Lu dans le texte du Journal officiel sur EUR-Lex le 11 septembre 2026.

Ceci n'est pas un avis juridique. Les considérants sont là où la ligne du libre est tracée, et ils sont cités ci-dessus pour que vous les lisiez plutôt que d'adopter notre lecture.