Suis-je fabricant ? La question du CRA que personne ne tranche.
Vous publiez une extension et vous voulez savoir si le règlement sur la cyberrésilience fait de vous un fabricant. Les sources donnent deux réponses.
La question tient en une phrase. Vous avez construit une extension WordPress, elle est dans le répertoire ouvert, tout le monde peut la télécharger, et vous vendez une version Pro à côté. Cela fait-il de vous un fabricant au sens du règlement sur la cyberrésilience, le règlement (UE) 2024/2847 ?
La réponse honnête est inconfortable. Cela dépend, les sources se contredisent précisément sur ce point, et une partie des voix les plus fortes du marché vend les outils censés régler la question. En août 2026, nous avons vérifié de façon systématique, face aux sources disponibles, l'affirmation selon laquelle les extensions gratuites assorties d'une version Pro relèvent automatiquement du CRA. Le résultat n'est ni un oui net ni un non net.
Vous ne lirez donc pas ici une réponse qui n'existe pas. Vous lirez ce que dit le règlement, ce que la Commission en dit, où les deux divergent, et avec quelles questions trier votre propre situation. Ceci est une mise en perspective et non un conseil juridique.
La phrase qui fait tressaillir la plupart des développeurs
Commencez par la définition. L'exception vient ensuite. L'article 3, point 1 du CRA décrit le produit comportant des éléments numériques comme "a software or hardware product and its remote data processing solutions, including software or hardware components being placed on the market separately". Traduit dans notre cas : un module logiciel distribué séparément est couvert. Une extension est un module logiciel distribué séparément.
L'article 3, point 13 définit ensuite le fabricant : celui qui développe ou fait développer des produits comportant des éléments numériques et les commercialise sous son propre nom ou sa propre marque, "whether for payment, monetisation or free of charge". Cette dernière formule est l'endroit où la discussion s'arrête d'habitude avant d'avoir commencé. Elle dit que le prix ne fait pas partie de la notion de fabricant : faire payer, monétiser autrement ou donner reviennent au même. Ce qui compte, c'est la commercialisation sous son propre nom.
Une réserve vaut pour tout l'article : pendant nos recherches, EUR-Lex n'a rien renvoyé, quelle que soit la forme d'URL testée. Les citations d'articles proviennent de reproductions du texte intégral qui concordaient entre elles. Nous les laissons donc en anglais et nous les expliquons à côté au lieu de les traduire : une traduction maison ferait croire à une exactitude que nous ne pouvons pas justifier. Si vous réutilisez une citation littérale, vérifiez-la d'abord dans EUR-Lex.
Le contrepoids se trouve dans les orientations de la Commission
Fin juillet 2026, la Commission européenne a publié des orientations d'application du CRA, référence C(2026) 5252, composées d'une communication et d'une annexe qui contient le mode d'emploi proprement dit. Environ 80 pages, 67 exemples pratiques, des logigrammes, avec les microentreprises et les PME comme public explicite. Petite note d'exactitude : la Commission date le document de Bruxelles, le 27 juillet 2026, tandis que heise online annonce une publication le 28 juillet 2026. Probablement une date d'établissement contre une date de publication. Nous écrivons donc fin juillet et nous citons la référence.
Sur le fond, les orientations disent de l'open source l'inverse de ce que beaucoup attendent après avoir lu l'article 3: les logiciels open source librement disponibles restent en principe hors du champ d'application du CRA tant qu'ils ne sont pas commercialisés. Relèvent de l'activité commerciale, selon les orientations, notamment la vente du logiciel, les éditions entreprise payantes, la monétisation de services au travers du programme, l'exigence de données à caractère personnel au-delà des finalités de sécurité et d'interopérabilité, ainsi que les dons qui conditionnent de fait l'accès.
Ne sont expressément pas commerciaux, selon les orientations, les contributions volontaires, le financement public et le parrainage pris isolément. Des prestations de support payantes ne soumettent pas automatiquement un projet au CRA tant que le logiciel lui-même reste librement disponible.
Notez ce qui manque dans le règlement : le CRA ne définit pas la notion d'activité commerciale de manière autonome dans le corps des articles. Les critères viennent des considérants et de ces orientations. C'est exactement de là que naît l'espace dans lequel les lectures divergent.
L'intendant est un régime allégé, pas un blanc-seing
Entre le fabricant et la personne non concernée, il existe un troisième rôle. L'article 3, point 14 du CRA définit l'intendant de logiciels libres et open source (open-source software steward) comme la personne morale qui n'est pas un fabricant et dont l'objet consiste à soutenir de façon durable et systématique le développement de certains produits comportant des éléments numériques qui sont des logiciels libres et open source et sont destinés à des activités commerciales.
Ce qui en découle figure à l'article 24. Le paragraphe 1 exige une politique de cybersécurité documentée qui favorise le développement sécurisé et le traitement des vulnérabilités, y compris le signalement volontaire prévu à l'article 15. Le paragraphe 2 exige une coopération avec les autorités de surveillance du marché et, sur demande motivée, la remise de la documentation dans une langue aisément compréhensible pour l'autorité. Le paragraphe 3 rend l'article 14, paragraphe 1 applicable aux intendants pour les produits au développement desquels ils participent, ainsi que l'article 14, paragraphes 3 et 8 dans la mesure où des incidents graves touchent leur propre infrastructure de développement.
Retenez la combinaison : les intendants sont soumis à une obligation de signalement à partir du 11 septembre 2026, mais sans amende administrative au titre de l'article 64, paragraphe 10. Qui entend "relève du CRA" et pense sanctions se trompe d'image pour ce rôle. Ce qui vaut pour les fabricants à partir du 11 septembre 2026 et quels délais courent alors est détaillé dans l'article sur les obligations de signalement du CRA.
C'est ici que les sources divergent
Le cas central, c'est l'extension gratuite dans le répertoire ouvert, avec à côté une version Pro payante du même éditeur. Il existe deux lectures et elles mènent à des résultats différents.
Lecture A : la version gratuite est appréciée pour elle-même
Selon cette lecture, la version libre s'examine séparément. Si elle n'est pas monétisée elle-même, autrement dit aucun achat nécessaire, aucun blocage d'accès ou de mises à jour contre paiement, aucun traitement de données au-delà des finalités de sécurité et d'interopérabilité, alors elle ne tombe pas automatiquement sous les obligations complètes du fabricant du seul fait que le même éditeur vend une version Pro à côté. L'Open Regulatory Compliance Working Group restitue les orientations en ce sens qu'une personne morale peut endosser plusieurs rôles à la fois, y compris pour des versions différentes du même logiciel, édition communautaire et édition monétisée comprises. Le considérant 18 du règlement va dans ce sens : la fourniture de produits qui sont des logiciels libres et open source 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 18 retient aussi que la seule existence de publications régulières et le seul soutien financier de fabricants ne suffisent pas, à eux seuls, à donner un caractère commercial à l'activité.
Lecture B : la version Pro déteint sur la version gratuite
Plusieurs prestataires spécialisés dans la conformité au CRA formulent les choses plus largement. Celui qui vend l'extension, propose une version Pro, fournit du support payant ou la monétise d'une manière ou d'une autre fournirait dans le cadre d'une activité commerciale et se trouverait dans le champ d'application, indépendamment de la licence GPL. Fait intéressant, l'un de ces mêmes prestataires nuance ailleurs et se demande si le produit gratuit sert d'instrument de vente pour une offre payante.
Et maintenant la divulgation qui accompagne cette position : ces prestataires vendent des outils et du conseil en conformité CRA aux personnes qui développent des extensions. Un intérêt économique à une lecture aussi large que possible du champ d'application ne peut pas être écarté, puisque plus de développeurs concernés signifie plus de clients. Ce n'est pas une accusation et cela ne rend pas leur propos faux. Cela signifie seulement que cette formulation ne vient pas des orientations. Elle en est l'interprétation par des acteurs du marché qui ont un intérêt propre. Qui pondère une source pondère aussi son intérêt.
Autre réserve que presque personne ne livre avec ses conseils : l'annexe de C(2026) 5252 n'a pas pu être exploitée par machine. Toutes les affirmations de fond sur l'open source dans cet article proviennent du communiqué de presse de la Commission, de la presse spécialisée et de blogs d'organisations. Nous n'avons relu ni les 67 exemples ni les critères précis de délimitation. Qui vous dit savoir exactement ce que contient la page 41 a plus d'accès que nous, ou en raconte plus qu'il n'en sait.
S'y ajoute qu'aucune prise de position d'une autorité ou de la Commission ne nomme expressément les extensions WordPress. Le classement des extensions comme produit comportant des éléments numériques se justifie bien par l'article 3, points 1 et 13. Les sources qui nomment les extensions sont, sans exception, des blogs d'éditeurs qui vendent des outils de conformité.
Sept questions pour situer votre propre cas
Les questions suivantes ne remplacent pas l'examen de votre cas par une personne habilitée. C'est une grille de tri, construite à partir des critères que les orientations et les considérants nomment selon les sources exploitées. Plus la colonne de droite penche vers le commercial, plus il est raisonnable de se comporter par précaution comme un fabricant.
| Question sur votre propre produit | Ce que la réponse signifie |
|---|---|
| L'accès à la version gratuite est-il lié à un paiement, y compris de façon indirecte via une inscription avec achat obligatoire ? | Demander un prix pour le logiciel ou pour des fichiers précompilés relève de l'activité commerciale selon les orientations. Un téléchargement libre sans contrepartie non. |
| La version gratuite reçoit-elle des mises à jour de sécurité seulement contre paiement ? | Bloquer les mises à jour derrière un paiement est, selon la lecture exploitée, l'un des arguments les plus forts pour considérer la version libre comme monétisée elle-même. |
| Exigez-vous des données à caractère personnel au-delà des finalités de sécurité et d'interopérabilité ? | Les orientations nomment exactement cela comme activité commerciale. Collecter une adresse e-mail pour le téléchargement est donc un facteur de risque, pas un détail. |
| La version gratuite est-elle autonome sur le plan fonctionnel, ou est-elle un péage devant la vraie fonction ? | Un produit utilisable seul plaide pour la lecture A. Une coquille gratuite qui ne fait rien sans achat plaide pour un couplage fonctionnel avec la vente. |
| Monétisez-vous d'autres services au travers du programme, par exemple de la publicité ou de la collecte de données ? | Le logiciel comme plateforme de monétisation d'autres produits relève de l'activité commerciale selon les orientations, même si le logiciel lui-même est gratuit. |
| Les dons conditionnent-ils de fait l'accès au logiciel ou aux mises à jour ? | Les dons volontaires sans but lucratif ne sont pas commerciaux. Les dons qui conditionnent de fait l'accès le sont. |
| Commercialisez-vous sous votre propre nom ou votre propre marque ? | C'est le critère de l'article 3, point 13 qui s'applique indépendamment du prix. Il ne répond pas à lui seul à la question du fabricant, mais c'est la porte par laquelle elle entre. |
Si vous voulez traduire le résultat en quelque chose d'utilisable : la partie qui a du sens quelle que soit la qualification, c'est un fichier security.txt avec les coordonnées publiques pour le signalement de vulnérabilités. Vous pouvez la préparer aujourd'hui, sans avoir tranché la question du fabricant.
Comment nous nous situons
hafenstudios est exactement le cas dont on débat. Nous avons plusieurs extensions avec version gratuite et version Pro payante, dont Wellenbrecher, présent dans le répertoire WordPress depuis le 21 août 2026. Avec le thème Hafen, nous avons aussi un logiciel sans aucune édition payante. Tout est sous GPLv2 ou ultérieure.
Notre position : nous nous comportons comme un fabricant. C'est l'hypothèse prudente, et elle nous coûte moins cher que de nous être trompés le jour où cela compte. En pratique, cela veut dire des voies de contact documentées pour les signalements de vulnérabilités, une procédure pour les délais de l'article 14 et la préparation au programme complet d'obligations à partir du 11 décembre 2027, quand s'appliqueront le marquage CE, la documentation technique, l'évaluation de la conformité et la nomenclature logicielle de l'annexe I, partie II.
Nous disons ouvertement que la question n'est pas tranchée. Un rendez-vous avec un avocat est prévu. C'est plus honnête que d'affirmer ici une certitude que l'état des sources ne permet pas. Encore une fois, à l'endroit où cela compte : cet article est une mise en perspective et non un conseil juridique. Pour une appréciation contraignante de votre cas, il vous faut une personne habilitée.
L'incertitude est le dommage réel
Voici maintenant l'opinion pour laquelle cet article a été écrit. Le problème de cette situation n'est pas la réglementation en soi. Des exigences de sécurité pour un logiciel qui tourne sur des centaines de milliers de sites se justifient sans peine. Le problème, c'est que personne ne peut dire de façon fiable qui est concerné.
Cette incertitude se répartit inégalement. Un grand groupe a une direction juridique qui rédige une appréciation et un budget qui survit à une appréciation fausse. Une structure de deux personnes a une soirée et une page de résultats dont les cinq premiers viennent de prestataires qui veulent lui vendre un abonnement. Le coût du flou est porté par le petit, alors même que les orientations ont été écrites explicitement pour les microentreprises et les PME.
Le cadre national n'apaise rien, et c'est là qu'il faut regarder votre propre pays. Le signalement va au CSIRT de l'État membre de l'établissement principal, et la mise en oeuvre nationale a été réglée différemment dans chaque État membre. En Allemagne, où nous sommes établis, le destinataire est le BSI avec le CERT-Bund, et la loi allemande d'application du CRA n'était toujours pas en vigueur au 21 août 2026 : elle figure comme document du Bundestag 21/6134 du 26 mai 2026, première lecture le 11 juin 2026. Elle ne crée pas d'obligations nouvelles, elle désigne les compétences. L'article 14 s'applique au 11 septembre 2026 indépendamment de cela. Si votre établissement principal se trouve dans un autre État membre, l'autorité compétente et le calendrier national sont à vérifier sur place.
Ce qui en découle n'a rien de spectaculaire. Comportez-vous par précaution comme un fabricant si plusieurs des sept questions penchent vers le commercial. Documentez comment vous êtes arrivé à votre qualification. Et méfiez-vous de toute source qui répond à cette question en deux phrases, surtout quand la troisième vend quelque chose.
Ce que nous publions sur la sécurité et les voies de signalement
Notre page sécurité explique comment signaler une vulnérabilité dans l'une de nos extensions, comment nous la traitons et dans quels délais. C'est la partie qu'un éditeur doit à ses utilisateurs, quelle que soit l'issue de la question du fabricant.
Questions fréquentes
Donner le logiciel gratuitement fait-il vraiment de moi un fabricant ?
Selon l'article 3, point 13 du CRA, le prix n'entre pas en compte. Est fabricant celui qui développe ou fait développer un produit comportant des éléments numériques et le commercialise sous son propre nom ou sa propre marque, dans la formule anglaise "whether for payment, monetisation or free of charge", donc contre paiement, par une autre monétisation ou gratuitement. Savoir si cette commercialisation a lieu dans le cadre d'une activité commerciale est la seconde question, celle qui est disputée. Le CRA ne définit pas cette notion dans le corps des articles.
Mon extension gratuite relève-t-elle automatiquement du CRA parce qu'il existe une version Pro ?
Selon les sources qui traitent des orientations elles-mêmes, pas automatiquement. Elles décrivent un examen au cas par cas : une version autonome et non monétisée reste dans le régime allégé ou hors champ, sauf si elle est monétisée elle-même ou couplée fonctionnellement à la vente. Les prestataires commerciaux de conformité défendent la lecture large. La question n'est pas tranchée.
Qu'est-ce qu'un intendant de logiciels libres et open source ?
L'article 3, point 14 du CRA décrit une personne morale qui n'est pas un fabricant et dont l'objet consiste à soutenir de façon durable et systématique le développement de certains produits open source destinés à des activités commerciales. L'article 24 exige une politique de cybersécurité documentée, une coopération avec les autorités et une obligation de signalement limitée. Au titre de l'article 64, paragraphe 10, les intendants sont exemptés des amendes administratives prévues par cette disposition.
Les orientations de la Commission sont-elles contraignantes ?
Non. La Commission précise elle-même que seule la Cour de justice de l'Union européenne peut interpréter le droit de l'Union de manière contraignante. C(2026) 5252 ne change aucune obligation ni aucune échéance. Pour les autorités de surveillance du marché, ce document restera tout de même un point de référence en pratique, raison pour laquelle il faut le connaître sans le prendre pour la loi.
Qu'est-ce qui s'applique à partir de quand ?
Le chapitre IV sur les organismes notifiés s'applique depuis le 11 juin 2026. L'article 14 avec les obligations de signalement des fabricants s'applique à partir du 11 septembre 2026. Le reste du règlement s'applique à partir du 11 décembre 2027, ce qui comprend le marquage CE, la documentation technique, l'évaluation de la conformité et la nomenclature logicielle de l'annexe I, partie II. La source des trois dates est l'article 71 du CRA.
