Souverain

Le Cyber Resilience Act (CRA) est un règlement européen qui vise à relever le niveau de sécurité des produits numériques vendus dans l’Union européenne. En clair, l’idée est simple : un logiciel, une application, un objet connecté ou un composant informatique ne devrait plus arriver sur le marché sans exigences minimales de cybersécurité, sans suivi sérieux des failles et sans responsabilité clairement identifiée. Le texte officiel est le règlement (UE) 2024/2847, consultable sur EUR-Lex, et la Commission européenne en propose aussi une synthèse plus pédagogique.

Qu’est-ce que la nouvelle loi européenne sur la cybersécurité change pour les logiciels, les entreprises du numérique, l’open source et le lien avec la souveraineté numérique ?

Le CRA est entré en vigueur le 10 décembre 2024, mais son application se fait par étapes. Les principales obligations s’appliqueront à partir du 11 décembre 2027. Certaines obligations de signalement, elles, entreront en vigueur plus tôt, dès le 11 septembre 2026. La Commission précise aussi qu’une autre étape intermédiaire est prévue au 11 juin 2026 pour les dispositions relatives aux organismes d’évaluation de conformité.

Le texte s’applique aux « produits avec éléments numériques« . Cette formule peut sembler floue, mais elle désigne en réalité les produits matériels et logiciels qui ont une fonction numérique et une connexion directe ou indirecte à un appareil ou à un réseau. Cela inclut donc non seulement les objets connectés les plus visibles, mais aussi des logiciels, des applications, des systèmes d’exploitation, des puces, des composants ou encore des briques techniques vendues séparément. Autrement dit, le CRA ne vise pas seulement les produits finis, il peut aussi concerner des composants mis sur le marché à part.

L’un des points les plus importants du texte : l’open source non commercial est, en principe, hors du champ. Ce n’est pas le simple fait de publier du code libre sur Internet qui déclenche les obligations du règlement. Ce qui compte, c’est la mise à disposition sur le marché dans le cadre d’une activité commerciale, y compris lorsqu’un produit est distribué gratuitement mais dans un contexte économique organisé. La frontière juridique n’est donc pas « open source ou non », mais bien « activité commerciale ou non ».

Concrètement, cela signifie qu’un développeur qui publie un projet open source ne devient pas automatiquement responsable de tous les usages futurs de son code. En revanche, si une entreprise reprend ce code, l’intègre à un produit et le commercialise sous son nom, c’est elle qui porte la responsabilité de la conformité. Ce point est essentiel, parce qu’il évite de faire peser d’emblée sur les contributeurs bénévoles et les petits projets communautaires le même poids réglementaire que sur un acteur qui vend effectivement un produit sur le marché européen.

Qui est concerné dans la chaîne d’approvisionnement ?

Le CRA distingue plusieurs acteurs. Le fabricant est celui qui développe ou fait développer un produit et le commercialise sous son nom ou sa marque. L’importateur est l’acteur établi dans l’Union qui met sur le marché européen un produit provenant d’un fabricant situé hors de l’UE. Le distributeur, lui, met le produit à disposition sans en modifier les caractéristiques. Enfin, le texte introduit une catégorie particulière : l’open-source software steward.

Ce steward open source mérite d’être expliqué simplement. Il ne s’agit pas d’un développeur isolé, mais d’une personne morale, par exemple une fondation, une association structurée ou une entreprise, qui soutient de manière durable le développement d’un logiciel libre destiné à des usages commerciaux et qui en assure la viabilité. Le règlement lui reconnaît donc un rôle particulier dans l’écosystème open source, sans le traiter exactement comme un fabricant. À mes yeux, ce concept reste encore flou et sujet à interprétation.

Cette distinction est importante parce que le CRA essaie justement de ne pas appliquer la même logique à un bénévole et à une structure qui joue un rôle organisé dans l’économie du logiciel. Les stewards open source doivent bien mettre en place une politique de cybersécurité, coopérer avec les autorités et, dans certains cas, signaler des vulnérabilités ou des incidents. En revanche, la Commission précise qu’ils ne sont pas soumis aux mêmes sanctions administratives que les fabricants.

Ce que le CRA impose réellement aux fabricants

Pour les fabricants, le règlement change profondément la donne. Il ne suffit plus de mettre un produit sur le marché puis de passer à autre chose. Le fabricant doit procéder à une évaluation des risques, concevoir son produit selon des exigences minimales de cybersécurité, documenter ses choix techniques, fournir des informations claires à l’utilisateur, organiser le traitement des vulnérabilités et démontrer la conformité du produit avant sa mise sur le marché. À l’issue de cette procédure, il doit établir une déclaration UE de conformité et, lorsque les conditions sont réunies, apposer le marquage CE.

Le CRA introduit aussi une logique de cycle de vie. La sécurité n’est plus pensée uniquement au lancement du produit : le fabricant doit prévoir une période de support pendant laquelle les vulnérabilités seront traitées. La Commission précise même que la date de fin de support, au moins le mois et l’année, doit être indiquée de manière claire et compréhensible au moment de l’achat. Pour le grand public, c’est un changement important : cela revient à rendre visible une question trop souvent laissée dans le flou, à savoir combien de temps un produit restera réellement maintenu.

Autre point central : le signalement des vulnérabilités et des incidents. Les fabricants devront notifier les vulnérabilités activement exploitées ainsi que les incidents graves affectant la sécurité de leurs produits. La Commission indique un calendrier précis : une alerte précoce sous 24 heures, une notification principale sous 72 heures, puis un rapport final dans les délais prévus selon qu’il s’agit d’une vulnérabilité exploitée ou d’un incident sévère. Ces obligations commenceront à s’appliquer à partir du 11 septembre 2026.

Ce que le texte change pour l’open source

Pour le monde de l’open source, le CRA peut produire un premier effet positif : il clarifie enfin la question de la responsabilité. Publier du code libre n’équivaut pas, en soi, à mettre un produit sur le marché. En revanche, une entreprise qui s’appuie sur ce code pour construire une offre commerciale ne peut plus se retrancher derrière le simple caractère « ouvert » du logiciel pour esquiver ses obligations. Le texte pousse donc vers une responsabilisation plus nette des acteurs économiques qui tirent parti de l’open source.

C’est là qu’apparaît le problème du contournement : des acteurs peuvent récupérer des briques open source, les intégrer à une offre commerciale, en tirer de la valeur, sans contribuer sérieusement à la sécurité ni assumer clairement la maintenance. Avec le CRA, cette position devient plus difficile à tenir, car celui qui met le produit sur le marché doit démontrer sa conformité, gérer les vulnérabilités et répondre aux autorités. En pratique, profiter du libre sans prendre ses responsabilités devient donc moins soutenable.

Le texte peut aussi renforcer la crédibilité de certaines offres open source auprès des clients publics et privés. Lorsqu’un produit libre est porté par un acteur identifié, capable d’assumer le support, la documentation, la conformité et la gestion des incidents, il devient plus lisible pour des acheteurs qui ont besoin d’un interlocuteur responsable. Le CRA peut donc, dans certains cas, jouer en faveur d’un open source plus structuré.

Mais il existe aussi un risque réel : la charge de conformité. Le règlement suppose des compétences en sécurité, en documentation, en gouvernance produit et en suivi réglementaire. La Commission elle-même a publié des mesures de soutien pour les petites entreprises et un projet de guide destiné à faciliter l’application du CRA, en particulier pour les microentreprises (MIC) et les PME, ce qui montre bien que la mise en conformité peut être lourde pour les structures modestes.

C’est aussi pour cette raison que des zones grises subsistent encore. La Commission a publié le 3 mars 2026 un projet de guide pour aider les entreprises à appliquer le CRA, ce document porte notamment sur le logiciel libre, les solutions de traitement de données à distance, la notion de période de support et l’articulation avec d’autres textes européens. Tant que ces lignes directrices ne sont pas stabilisées, une part d’incertitude demeure dans l’interprétation pratique du règlement.

Pourquoi il faut se préparer dès maintenant ?

Même si l’échéance principale est fixée à décembre 2027, le CRA n’est pas un sujet à repousser à la dernière minute. Pour les entreprises concernées, la bonne méthode consiste dès maintenant à cartographier les produits, identifier le rôle juridique occupé dans la chaîne de valeur, repérer les écarts de conformité, mettre à jour les processus internes, organiser la documentation technique et préparer les procédures de gestion des vulnérabilités et de réponse aux incidents. C’est exactement le sens des ressources publiées par la Commission sur les fabricants, l’implémentation du texte et le guide soumis à consultation.

Ce que cela veut dire pour le grand public

Vu de l’extérieur, le CRA peut sembler technique. En réalité, son objectif est très concret : faire en sorte que les produits numériques vendus en Europe soient plus sûrs, mieux suivis, mieux documentés, et qu’il soit plus facile de savoir qui est responsable lorsqu’un problème de sécurité apparaît. Ce n’est donc pas une loi réservée aux spécialistes, c’est aussi une loi qui vise à mieux protéger les particuliers, les entreprises clientes et les administrations qui dépendent chaque jour de logiciels, d’applications et d’équipements connectés.

Quel lien avec la souveraineté numérique ?

Le lien avec la souveraineté numérique est direct, même s’il n’est pas toujours formulé ainsi dans le texte juridique. Un écosystème numérique souverain ne repose pas seulement sur le fait de disposer de code ouvert ou de solutions européennes, il suppose aussi de maîtriser la maintenance, la sécurité, la gouvernance, la capacité de correction et la responsabilité tout au long de la chaîne. De ce point de vue, le CRA pousse vers une forme de maturité industrielle qui peut renforcer l’autonomie numérique européenne.

Le règlement peut ainsi avoir un effet positif : si l’Europe soutient des offres open source ou européennes capables d’assumer proprement ces nouvelles exigences, le CRA peut devenir un levier de souveraineté numérique. Cette lecture n’est pas théorique : la Commission affirme désormais explicitement que le secteur open source est important pour la souveraineté technologique européenne, et plusieurs initiatives récentes lient l’open source à la réduction des dépendances, à la flexibilité, à la sécurité et à la compétitivité.

Mais l’effet inverse est tout aussi possible. Si le CRA devient, dans les faits, une mécanique de conformité que seuls les très grands fournisseurs peuvent absorber facilement, alors les plus petits acteurs, y compris européens et open source, risquent d’être marginalisés.
Dans ce scénario, des organisations pourraient préférer des offres propriétaires déjà très structurées sur le plan administratif, non pas parce qu’elles seraient nécessairement meilleures, mais parce qu’elles paraîtraient plus simples à gérer du point de vue réglementaire. Le danger serait alors de remplacer une dépendance technique par une dépendance de conformité. Cette conclusion relève d’une lecture stratégique du texte, mais elle est cohérente avec le niveau d’exigence du CRA et avec le fait que la Commission a déjà dû prévoir des guides et des mécanismes de soutien pour les petites structures.

La vraie question stratégique

Au fond, la bonne question n’est pas de savoir s’il faut choisir entre le CRA et l’open source. La vraie question est de savoir si l’Europe saura financer, outiller et accompagner les acteurs open source et les entreprises européennes, pour qu’ils puissent satisfaire ces nouvelles obligations sans être écrasés par elles. Si cet accompagnement suit, le CRA peut devenir un outil de montée en gamme et un levier de souveraineté. S’il échoue, le texte risque surtout de consolider la position des acteurs déjà les plus puissants.

À ce stade, tout l’enjeu est donc moins dans l’existence du règlement que dans sa mise en œuvre concrète.