CRA et open source : fabricant, contributeur, intendant

La licence open source ne suffit pas à déterminer les obligations CRA. Il faut distinguer le contributeur, le fabricant qui commercialise un produit et l’intendant qui soutient durablement un logiciel ouvert. Le financement du développement, la gratuité de la distribution et la monétisation par un autre acteur ne produisent pas les mêmes effets.

Commercialisation et développement : deux analyses distinctes

Les Art. 3(13), 3(22), 3(48) et considérants 15 à 20 du règlement (UE) 2024/2847 encadrent cette distinction. L’Art. 3(48) définit le logiciel libre et ouvert ; il ne constitue pas, à lui seul, une disposition générale d’exemption.

Le considérant 18 précise que les seules circonstances du développement ou son financement ne déterminent pas le caractère commercial de la fourniture. Un soutien financier par une entreprise ou des mises à jour régulières ne suffisent pas à transformer le projet en activité commerciale.

De même, un composant fourni pour intégration dans le produit d’un tiers n’est considéré comme mis à disposition sur le marché, dans cette analyse, que s’il est monétisé par son fabricant d’origine. La vente du produit final par l’intégrateur ne transforme pas rétroactivement chaque contributeur en fabricant.

À l’inverse, un logiciel gratuit peut accompagner une activité commerciale. Le considérant 15 cite notamment certains services d’assistance dépassant la récupération des coûts, une intention de monétisation ou certaines conditions de traitement des données. L’acceptation de dons sans intention lucrative ne constitue pas en elle-même une activité commerciale.

Qui est un intendant de logiciels ouverts ?

L’Art. 3(14) vise une personne morale autre qu’un fabricant, ayant pour objectif de soutenir systématiquement et durablement le développement de produits qualifiés de logiciels libres et ouverts destinés à des activités commerciales, et d’assurer leur viabilité.

Ne déduisez pas ce statut du seul mot « fondation » ou d’un hébergement de code. Examinez l’organisation, la continuité du soutien, le rôle joué et les produits concernés. Une même structure doit qualifier ses différentes activités plutôt que s’attribuer une exemption globale.

Les obligations spécifiques de l’article 24

L’intendant doit mettre en place une politique de cybersécurité documentée de manière vérifiable. Elle favorise le développement sécurisé, le traitement des vulnérabilités et le partage d’informations. Il coopère avec les autorités de surveillance et leur fournit, sur demande motivée, la documentation de cette politique.

L’Art. 24(3) prévoit des signalements dans des situations précises :

• les obligations de l’Art. 14(1) s’appliquent lorsque l’intendant participe au développement du produit ;
• celles des Art. 14(3) et 14(8) s’appliquent lorsque les incidents graves touchent les réseaux et systèmes fournis par l’intendant pour le développement des produits.

Ce renvoi ne permet pas de reprendre sans analyse toutes les obligations du fabricant. L’article 24 relève de l’application générale du 11 décembre 2027, distincte de l’article 14 applicable aux fabricants depuis septembre 2026. Le calendrier CRA sépare ces échéances.

Pas d’amende CRA de 2,5 millions pour les intendants

L’Art. 64(10)(b), lu avec le rectificatif du 2 juillet 2025, exclut les intendants des amendes administratives visées aux paragraphes 2 à 9 pour les violations du règlement. Il ne crée pas un palier spécial de 2,5 millions d’euros ou 1 %.

Cela ne supprime pas les obligations ni les mesures correctives prévues, notamment à l’Art. 52(3). Consultez les sanctions CRA en distinguant le statut réellement exercé et le manquement en cause.

L’intégrateur reste responsable de son produit

Le fabricant qui intègre un composant ouvert dans son produit commercial doit exercer la diligence prévue à l’Art. 13(5) et gérer les vulnérabilités qui affectent son produit. L’Art. 13(6) organise les échanges avec le fabricant ou mainteneur du composant, y compris le partage d’un correctif développé dans les conditions du texte.

Le SBOM aide à retrouver composants et versions ; il ne remplace pas l’analyse de leurs risques. Organisez le traitement des vulnérabilités CRA avec un responsable, un suivi des décisions et des moyens de correction.

Une voie particulière pour certains produits importants

L’Art. 32(5) permet aux fabricants de produits répondant aux critères de logiciels libres et ouverts et relevant de l’annexe III d’utiliser les procédures de l’Art. 32(1), dont le contrôle interne, à condition de rendre la documentation technique publique lors de la mise sur le marché.

C’est une modalité d’évaluation de conformité, pas une dispense des exigences essentielles. Elle ne doit pas être confondue avec le régime de l’intendant ni étendue sans texte aux produits critiques de l’annexe IV.

Constituer une fiche de qualification par produit

Commencez par nommer le logiciel, sa version et la personne qui le fournit. Un dépôt peut accueillir plusieurs projets et une structure peut intervenir à plusieurs titres. Une conclusion portant seulement sur le nom de l’association ou de la société laisse ces différences invisibles.

La fiche suivante est une méthode de travail proposée, à compléter avec les documents disponibles :

Pour chaque réponse, conservez la pièce, sa date et les incertitudes restantes. Une page indiquant « gratuit » ne règle pas la question des services associés. Un financement récurrent ne prouve pas davantage, à lui seul, la commercialisation du composant. La fiche doit expliquer le raisonnement au lieu d’accumuler des captures contradictoires.

Réexaminez la qualification lorsqu’une offre d’assistance change, qu’une édition commerciale apparaît ou que l’organisation reprend un autre rôle dans le projet. Ce sont des occasions de vérifier les faits ; elles ne déclenchent pas toutes automatiquement un changement de statut.

Exemple fictif : séparer le projet et son intégration

Dans cet exemple entièrement fictif, l’association Myrte entretient une bibliothèque ouverte grâce à des dons. La société Galet l’intègre dans un équipement vendu sous sa marque et contribue régulièrement au code. Une autre offre, présentée comme un accompagnement payant de la bibliothèque, figure sur le site de Myrte, mais ses conditions ne sont pas encore disponibles.

La vente de l’équipement par Galet ne suffit pas à qualifier la fourniture de la bibliothèque par Myrte. Il faut notamment examiner les conditions de l’accompagnement et sa relation avec la fourniture du logiciel. Les statuts et l’organisation du soutien aideront également à vérifier si Myrte répond, pour l’activité concernée, à la définition d’intendant. La conclusion reste ouverte tant que ces éléments manquent.

Galet ne peut pas attendre cette conclusion pour analyser les risques du composant dans son équipement. La société doit identifier la version incorporée, les modifications apportées et les fonctions exposées. Si une vulnérabilité est annoncée, elle doit déterminer si son produit est affecté et quelle correction lui convient. L’existence d’un correctif dans le dépôt ne démontre ni son intégration ni son bon fonctionnement dans l’équipement.

La note de décision peut donc comporter deux résultats différents : qualification de Myrte encore à documenter et actions de sécurité à engager par Galet. Cette séparation évite de transformer une incertitude sur le projet en justification d’inaction sur le produit final.

Rendre la politique de l’intendant utilisable

Pour préparer l’Art. 24, décrivez le chemin d’une alerte : réception, qualification, personne à contacter, décision sur le traitement et information des participants concernés. La politique doit tenir compte de l’organisation réelle du projet, notamment lorsque les mainteneurs sont bénévoles ou répartis entre plusieurs structures.

Préparez aussi une distinction entre une vulnérabilité du produit et un incident touchant les systèmes fournis pour son développement. Relevez la participation de l’intendant au développement et le périmètre de ses infrastructures. Ces faits servent à examiner les renvois précis de l’Art. 24(3) ; ils ne doivent pas être remplacés par une règle générale disant que tout problème impose tous les signalements du fabricant.

Un exercice de préparation peut partir d’une alerte inventée, sans données d’exploitation réelles. Demandez aux participants d’identifier le produit, la version, les informations manquantes et le responsable de la suite. Le résultat attendu est une procédure compréhensible et les corrections à lui apporter, pas une déclaration de conformité obtenue par la seule tenue de l’exercice.

Préparer les échanges entre mainteneur et intégrateur

Convenez d’un canal pour transmettre les informations techniques nécessaires. Un signalement utile précise la version concernée, les conditions connues du problème et les éléments permettant de le reproduire dans un environnement adapté. Limitez sa diffusion tant que la coordination de la correction l’exige, sans en déduire une autorisation de différer les obligations légales applicables.

Du côté de l’intégrateur, suivez séparément la réception du correctif, son examen, son adaptation éventuelle et sa diffusion pour le produit final. Une ligne « bibliothèque mise à jour » ne permet pas de retrouver quels produits et versions sont couverts. Conservez les décisions prises lorsque le correctif ne peut pas être intégré immédiatement et les mesures retenues dans l’intervalle.

Ce qu’il faut retenir

• Analysez la fourniture commerciale séparément du financement du développement.
• Un contributeur ne devient pas fabricant parce qu’un tiers vend un produit intégrant son code.
• L’intendant répond à une définition et à des obligations propres.
• L’intégrateur commercial conserve ses obligations sur le produit et ses composants.

FAQ

Recevoir un don rend-il automatiquement le projet commercial ?

Non. Le considérant 15 distingue notamment les dons sans intention lucrative. L’analyse doit porter sur les conditions concrètes de fourniture et de monétisation.

Une fondation doit-elle apposer le CE en qualité d’intendant ?

Le régime de l’intendant ne lui attribue pas les obligations de fabricant de ce seul fait. Il faut vérifier si la structure exerce aussi une activité distincte de fabricant.

Un fabricant peut-il invoquer la gratuité d’une bibliothèque ?

Pas pour écarter ses obligations sur le produit final. La diligence, l’analyse des risques et la gestion des vulnérabilités portent aussi sur les composants intégrés.

Recevez nos analyses conformité dans la newsletter.

Thiébaut Devergranne, docteur en droit et fondateur de donneespersonnelles.fr, travaille depuis plus de vingt ans sur le droit des technologies et la conformité numérique.