Provetry
ENDEDemander l’accès anticipé
Test gratuit
Demander l’accès anticipé

Provetry ouvre en novembre 2026. Le test CRA gratuit, les outils et les guides sont disponibles dès maintenant.

Le CRA et l’open source : mainteneurs, intendants et fabricants

8 min de lecture

Sur cette page
  1. 1. L’open source hors activité commerciale : hors champ
  2. 2. Les intendants de logiciels ouverts : un régime allégé
  3. 3. Les fabricants qui utilisent de l’open source : pleinement responsables
  4. Un auto-diagnostic rapide
  5. Ce que les mainteneurs peuvent faire quand même
  6. Ce que fait Provetry
  7. Sources

L’open source a été la partie la plus débattue du Cyber Resilience Act. Les premières versions inquiétaient les mainteneurs : publier du code sur GitHub allait-il faire d’eux des fabricants responsables ? Le texte final trace une ligne claire : le CRA suit l’activité commerciale, pas le code. Il donne trois positions aux personnes et organisations autour de l’open source, chacune avec ses obligations.

1. L’open source hors activité commerciale : hors champ

Les logiciels libres et ouverts développés ou fournis en dehors d’une activité commerciale ne sont pas couverts. Les considérants précisent ce que cela veut dire en pratique :

  • Une personne ou un groupe qui publie du code, accepte des contributions et corrige des bogues gratuitement n’est pas un fabricant.
  • Contribuer à un projet dont vous n’êtes pas responsable ne fait jamais de vous son fabricant.
  • Les dons qui ne visent pas à faire un profit ne transforment pas un projet en activité commerciale.
  • Les organisations à but non lucratif qui développent de l’open source ne sont pas considérées comme commerciales, si leurs revenus sont réinvestis dans des objectifs non lucratifs.

Ce qui peut rendre commercial un produit open source : le vendre, facturer une assistance technique au-delà du recouvrement des coûts réels, le monétiser par une plateforme logicielle ou d’autres services, ou faire du traitement de données personnelles une condition de son utilisation pour d’autres raisons que la sécurité, la compatibilité ou l’interopérabilité.

2. Les intendants de logiciels ouverts : un régime allégé

Le CRA crée un nouveau rôle, l’intendant de logiciels ouverts (open-source software steward) : une personne morale, autre qu’un fabricant, qui a pour objectif de fournir un soutien systématique et continu au développement de produits open source précis destinés à des activités commerciales, et qui assure leur viabilité. Les fondations qui hébergent et soutiennent des projets très utilisés en sont l’exemple type.

Les intendants ont leur propre régime allégé (article 24). Ils doivent :

  • mettre en place et documenter une politique de cybersécurité qui favorise le développement sûr et le traitement efficace des vulnérabilités, et encourage le signalement volontaire des vulnérabilités par les développeurs ;
  • coopérer avec les autorités de surveillance du marché quand elles le demandent ;
  • signaler les vulnérabilités activement exploitées des produits au développement desquels ils participent, et les incidents graves seulement quand ils touchent les réseaux et systèmes d’information qu’ils fournissent pour ce développement. Ces obligations de signalement des intendants s’appliquent à partir du 11 décembre 2027.

Ils ne font ni évaluation de la conformité, ni marquage CE, ni documentation technique. Et ils ne peuvent recevoir aucune amende au titre des sanctions du CRA (article 64, paragraphe 10).

Le règlement prévoit aussi des programmes volontaires d’attestation de sécurité des logiciels open source, pour aider les fabricants à s’y fier (article 25).

3. Les fabricants qui utilisent de l’open source : pleinement responsables

Quand une entreprise met un produit sur le marché, elle est le fabricant du produit entier, composants open source compris. Trois conséquences :

  • Diligence sur les composants. Quand ils intègrent des composants tiers, open source compris, les fabricants doivent s’assurer qu’ils ne compromettent pas la cybersécurité du produit (article 13, paragraphe 5).
  • Signaler en amont. Un fabricant qui trouve une vulnérabilité dans un composant open source doit la signaler à la personne ou à l’organisation qui maintient ce composant, et la traiter ; s’il développe un correctif, il doit en partager le code ou la documentation avec le mainteneur, dans un format lisible par machine le cas échéant (article 13, paragraphe 6).
  • Gestion des vulnérabilités du produit. Le SBOM, la veille quotidienne des vulnérabilités nouvelles et exploitées, les correctifs et les avis sont le travail du fabricant pour chaque composant qu’il livre, y compris les bibliothèques qu’il n’a pas écrites.

Une entreprise qui publie son propre projet open source et le vend, ou en tire de l’argent comme décrit plus haut, est le fabricant de ce produit, avec toutes les obligations. Les produits libres et ouverts des catégories importantes ont un avantage : ils peuvent passer par l’auto-évaluation si leur documentation technique est publique (article 32, paragraphe 5).

Un auto-diagnostic rapide

Vous êtes Votre position
Mainteneur ou contributeur bénévole Hors champ
Une fondation qui héberge des projets utilisés commercialement Probablement intendant
Une entreprise qui vend un produit contenant de l’open source Fabricant du produit entier
Une entreprise qui vend l’assistance d’un projet open source qu’elle maintient, quand cela monétise le produit Peut-être fabricant : consultez les orientations de la Commission
Une entreprise qui publie de l’open source qu’elle utilise en interne, sans le vendre En général hors champ pour ce code

Les cas limites existent. Les orientations de la Commission sur l’application du CRA (juillet 2026) et sa FAQ donnent des exemples ; lisez-les, et demandez à un avocat si votre modèle est à la frontière.

Ce que les mainteneurs peuvent faire quand même

Même hors champ, les mainteneurs de projets populaires sentiront le CRA à travers les entreprises qui utilisent leur code. Quelques gestes utiles et peu coûteux :

  • publier une politique de sécurité et un point de contact (SECURITY.md, security.txt) ;
  • produire un SBOM pour les versions ;
  • publier des avis dans un format standard quand vous corrigez quelque chose ;
  • dire quelles versions sont maintenues.

Ce que fait Provetry

Pour les fabricants, Provetry liste chaque composant open source de chaque version, les surveille face aux vulnérabilités nouvelles et exploitées, et garde vos décisions. Chaque produit enregistre votre rôle (fabricant, importateur, distributeur ou intendant de logiciels ouverts), pour que votre documentation dise quelles obligations vous portent.

Ce guide est une information générale, pas un conseil juridique.

Sources