ElegArtechTechnologie · Organisations · Action publique
S’abonner
Numérique, IA & souveraineté—Cybersécurité · Logiciel libre et communs · Régulation et droit—Analyse

Cyber Resilience Act : le 11 septembre 2026, première échéance dure pour les « stewards » open source

Le 11 septembre 2026, le Cyber Resilience Act européen fait entrer en application ses premières obligations dures, dont celles d'une catégorie juridique inédite, l'« open source software steward » (littéralement l'intendant de logiciel libre, personne morale qui soutient durablement un logiciel ouvert destiné à des usages commerciaux). La tension est nette : le règlement reconnaît en droit un travail d'entretien longtemps demeuré invisible, celui des fondations et des administrations productrices de communs numériques, mais il le rend obligatoire et notifiable sans lui adjoindre de modèle de financement. Cette chronique propose de suivre ce basculement, de la coulisse silencieuse à la scène réglementaire, et d'en mesurer le coût pour ceux qui maintiennent.

AM
Par Alexandre Berge8 septembre 2026 · 17 min de lecture
Illustration éditoriale pour « Cyber Resilience Act : le 11 septembre 2026, première échéance dure pour les « stewards » open source »
Entre ambition et réalité : les transformations à l’épreuve du terrain.

Une catégorie née d'un compromis, pas d'une théorie

Le Cyber Resilience Act (CRA), formellement le règlement (UE) 2024/2847 du 23 octobre 2024, est entré en vigueur le 10 décembre 2024 et s'appliquera pleinement le 11 décembre 2027. Entre ces deux dates, le législateur a échelonné trois marches. Le 11 juin 2026 sont entrées en application les dispositions relatives à la notification des organismes d'évaluation de la conformité (les laboratoires qui certifieront les produits). Le 11 septembre 2026 s'appliquent les obligations de signalement des vulnérabilités activement exploitées et des incidents graves, prévues à l'article 14. Le reste de l'architecture (marquage CE, évaluation de conformité, exigences essentielles de cybersécurité) attend décembre 2027.

Au cœur du texte figure une invention. Le CRA crée, à l'article 3, point 14, la figure de l'« open source software steward », définie comme une personne morale, autre qu'un fabricant, dont l'objet est d'apporter un soutien systématique et durable au développement de logiciels libres destinés à des activités commerciales, et qui en assure la viabilité. Le considérant 19 précise que cette catégorie inclut certaines fondations ainsi que des entités qui développent et publient des logiciels libres dans un contexte commercial, y compris des entités à but non lucratif. C'est la première fois qu'un texte européen nomme et dote d'un régime juridique propre les organisations qui, sans vendre le logiciel, en garantissent l'existence. Le steward n'est ni le fabricant qui commercialise, ni le développeur individuel qui contribue. Il est l'infrastructure qui tient l'ensemble debout.

Ce régime est volontairement allégé. Un steward n'appose pas le marquage CE (le sigle attestant la conformité d'un produit aux exigences européennes), ne réalise pas d'évaluation de conformité, ne conserve pas de documentation technique formelle. L'article 64, paragraphe 10, l'exempte des amendes administratives auxquelles s'exposent les fabricants (jusqu'à 15 millions d'euros ou 2,5 % du chiffre d'affaires annuel mondial selon l'article 64). Cette asymétrie n'est pas fortuite : elle résulte d'une négociation longue avec la communauté du libre, qui avait alerté sur le risque d'écraser des projets bénévoles sous des obligations pensées pour l'industrie. La catégorie de steward est donc un compromis politique, non le produit d'une doctrine. Elle reconnaît une réalité (des communs numériques soutenus par des structures identifiables) sans en tirer toutes les conséquences.

Ce que le 11 septembre rend obligatoire

L'obligation qui mord à partir du 11 septembre 2026 est procédurale et brutale dans sa temporalité. Un fabricant qui a connaissance d'une vulnérabilité activement exploitée dans son produit doit adresser une alerte précoce dans les 24 heures, une notification détaillée dans les 72 heures, et un rapport final dans les 14 jours suivant la mise à disposition d'un correctif. Pour un incident grave affectant la sécurité du produit, la cadence de 24 heures puis 72 heures est identique, mais le rapport final est dû dans un délai d'un mois. Les signalements transitent par la Single Reporting Platform (SRP, la plateforme unique de signalement) opérée par l'ENISA, l'agence européenne de cybersécurité, qui les redistribue au CSIRT national compétent (l'équipe nationale de réponse aux incidents de sécurité). En France, ce point d'entrée est le CERT-FR, rattaché à l'ANSSI, l'Agence nationale de la sécurité des systèmes d'information. La surveillance du marché revient à l'Agence nationale des fréquences (ANFR), l'ANSSI jouant le rôle d'autorité notifiante.

Le steward n'échappe pas à cette mécanique, mais il y entre par une porte étroite. L'article 24, paragraphe 3, rend applicables aux stewards les obligations des paragraphes 14(1), 14(3) et 14(8), et seulement « dans la mesure » où ils sont impliqués dans le développement du produit ou fournissent l'infrastructure qui le porte. Un steward qui n'apporte qu'un soutien non technique n'a aucune obligation de signalement. Celui qui héberge l'infrastructure de développement doit notifier les incidents graves. Celui qui fournit des ressources d'ingénierie doit signaler les vulnérabilités activement exploitées et informer les utilisateurs. Les délais eux-mêmes, la cadence de 24 heures puis 72 heures, ne figurent pas dans les paragraphes cités par l'article 24, mais dans les paragraphes 14(2) et 14(4) qui en constituent les modalités. Autrement dit, lorsqu'un steward relève de l'obligation, il applique la même horloge que le fabricant. Le régime est allégé sur les principes, pas sur la vitesse d'exécution.

La Commission a tenté de dissiper les zones grises. Elle a publié un projet de guide le 3 mars 2026, soumis à consultation publique jusqu'au 31 mars 2026, puis un guide final le 27 juillet 2026, formalisé comme annexe à la décision C(2026) 5252 et long d'environ 80 pages. Ce document, non contraignant (seule la Cour de justice de l'Union peut interpréter le texte de façon définitive), clarifie le périmètre du logiciel libre, la notion de modification substantielle, les périodes de support et l'articulation avec les autres textes. La vice-présidente exécutive de la Commission, Henna Virkkunen, l'a présenté sous le signe de la simplification, déclarant le 27 juillet 2026 : « Une Europe cybersécurisée et une Europe favorable aux entreprises vont de pair : le guide d'aujourd'hui contribuera à garantir que les produits sur notre marché sont protégés des cybermenaces, tout en évitant une charge inutile et l'insécurité juridique pour les entreprises. » Un document de questions-réponses avait déjà été publié le 3 décembre 2025. L'appareil interprétatif est donc abondant, ce qui en dit long sur l'incertitude qu'il cherche à réduire.

Nommer le mécanisme, la sociologie du travail invisible

Décrit ainsi, le geste du CRA prend un sens précis quand on lui applique un outil des sciences sociales. En 1999, dans la revue Computer Supported Cooperative Work, la sociologue Susan Leigh Star et le sociologue Anselm Strauss publient « Layers of Silence, Arenas of Voice », un article fondateur dont la thèse tient en une phrase : aucun travail n'est intrinsèquement visible ou invisible. La visibilité d'une activité, expliquent-ils, est le résultat d'une négociation permanente, d'un choix d'indicateurs par lesquels on décide de voir ou de ne pas voir un effort. Rendre visible un travail auparavant tacite n'est jamais neutre : cela déplace des responsabilités, crée des comptes à rendre, engendre de nouvelles charges pour ceux dont l'activité entre soudain dans l'arène des voix.

Le travail invisible (Star et Strauss, 1999)

Dans « Layers of Silence, Arenas of Voice », Susan Leigh Star et Anselm Strauss avancent qu'aucune activité n'est visible ou invisible par nature. La visibilité résulte d'un choix d'indicateurs et d'une négociation sociale. Rendre visible un travail tenu jusque-là dans l'ombre modifie l'équilibre des responsabilités et fait peser sur ses auteurs de nouvelles obligations de rendre compte. Le concept éclaire pourquoi une simple obligation de signalement peut transformer la condition de ceux qui maintiennent.

C'est exactement l'opération que réalise l'article 24. La maintenance de sécurité d'un logiciel libre, jusqu'ici accomplie dans le silence des dépôts de code, devient un travail nommé, daté, tracé, adossé à une horloge de 24 heures. Le CRA fait passer l'entretien du commun de la couche de silence à l'arène de la voix. Il ne crée pas le travail, il le rend légalement légible. Le concept de Star et Strauss n'est pas ici décoratif : sans lui, on ne verrait dans l'article 24 qu'une formalité de reporting, alors qu'il s'agit d'un basculement de régime de visibilité, avec ses effets de charge. Si l'on retire cette grille, l'analyse redevient un simple commentaire de calendrier.

Le cas s'éclaire encore par la sociologie de la maintenance. Jérôme Denis et David Pontille, dans Le soin des choses. Politiques de la maintenance (La Découverte, 2022), décrivent la maintenance comme l'art de faire durer les choses, un travail discret, contrepoint de l'obsession pour l'innovation, qui ne devient perceptible que lorsqu'il fait défaut. Les historiens Andrew Russell et Lee Vinsel, dans leur essai « Hail the Maintainers » (Aeon, 7 avril 2016), formulent la même critique de l'idéologie de l'innovation, résumée par leur sous-titre : le capitalisme excelle dans l'innovation mais échoue dans la maintenance, et pour la plupart des vies c'est la maintenance qui compte le plus. Enfin, l'enquête de Nadia Eghbal pour la Fondation Ford, Roads and Bridges: The Unseen Labor Behind Our Digital Infrastructure (2016), avait établi que l'infrastructure numérique repose sur un travail largement invisible et sous-financé, dont la fragilité n'apparaît qu'au grand jour lors d'un incident comme la faille Heartbleed d'OpenSSL. Ces trois références convergent : le commun numérique est un travail d'entretien que sa réussite même rend invisible.

Un précédent, le RGPD et l'invention du délégué

La régulation européenne a déjà fabriqué une figure d'acteur intermédiaire à partir d'une obligation. Le parallèle le plus proche par sa structure n'est ni le marquage CE, ni la directive NIS2 (sur la cybersécurité des réseaux), ni le règlement REACH (sur les substances chimiques), tous cités ici pour mémoire, mais le Règlement général sur la protection des données (RGPD) et sa création du délégué à la protection des données (DPO). Avant 2018, le correspondant informatique et libertés existait sur une base largement facultative. Le RGPD a rendu la désignation d'un DPO obligatoire pour les organismes publics et pour certains traitements à risque, et lui a assigné des missions précises : informer, conseiller, contrôler la conformité, coopérer avec la CNIL et servir de point de contact. En quelques années, une fonction a émergé, un marché de la formation s'est structuré, un métier s'est professionnalisé.

Le parallèle est instructif à deux titres. D'abord, il montre qu'une régulation peut faire exister un acteur en le nommant : le DPO n'est pas né d'une demande spontanée des organisations, mais d'une obligation légale qui a créé sa propre demande. Le steward suit la même logique de performativité juridique. Ensuite, et c'est la différence décisive, le RGPD a assorti la création du DPO d'un régime clair de responsabilités et d'une économie viable : le DPO est salarié ou prestataire, sa charge est identifiée, son coût est intégré au budget de conformité de l'organisation qui le désigne. Le steward, lui, est nommé sans être doté. Le CRA reconnaît son rôle, lui impose une horloge, mais ne dit rien de qui paie l'astreinte de 24 heures un dimanche d'août sur un dépôt maintenu par trois bénévoles. Là où le RGPD a inventé une fonction financée, le CRA a reconnu un travail sans lui attacher de ressource.

L'angle mort, reconnaître sans doter

Le non-dit du discours institutionnel n'est pas dissimulé, il est structurel. Le CRA opère une reconnaissance sans dotation. Les données rassemblées par l'OpenSSF (Open Source Security Foundation) et la Linux Foundation dans leur rapport 2026 sur la maturité face au CRA en donnent la mesure. Ce 2026 CRA Awareness and Readiness Report, produit avec LF Research, l'OpenSSF, Balena, Ericsson et Revanite et publié début juin 2026, établit qu'à moins d'un an de l'échéance, la part des répondants européens peu ou pas familiers du règlement s'établissait à 66 %, contre 62 % un an plus tôt, un recul statistiquement nul. Plus de la moitié des répondants (54 %) peinaient encore à distinguer les rôles de fabricant et de steward, catégories aux obligations pourtant très différentes ; 56 % ignoraient le régime de sanctions et 34 % seulement identifiaient correctement 2027 comme l'année cible de la conformité complète. L'échantillon de stewards interrogés était lui-même minuscule, les auteurs notant explicitement que « l'échantillon de stewards (n = 28) est petit », signe que la catégorie reste peu appropriée par ceux qu'elle vise.

Le décalage de préparation (OpenSSF, 2026)

Selon le 2026 CRA Awareness and Readiness Report de l'OpenSSF et de la Linux Foundation, 66 % des répondants européens restaient peu ou pas familiers du CRA à moins d'un an de l'échéance (62 % en 2025), 54 % ne distinguaient pas fabricant et steward, et 56 % ignoraient le régime de sanctions. L'échantillon de stewards interrogés se limitait à 28 répondants. L'organisation appelle explicitement à un soutien financier et juridique des stewards pour tenir la cadence de réponse aux vulnérabilités.

Dans le même temps, la pression de maintenance s'intensifie : le rapport relève une hausse de 394 % en glissement annuel des CVE (vulnérabilités publiées) au premier trimestre 2026, soit plus de 101 000 vulnérabilités supplémentaires, à travers 14 204 projets open source indexés sur la plateforme LFX, avec une progression de 811 % pour les failles de haute sévérité. La charge d'entretien augmente donc à mesure que la charge de conformité s'installe. L'OpenSSF en tire une conclusion sans détour : « Un soutien financier et juridique aux stewards est également indispensable pour gérer la réponse rapide aux vulnérabilités. »

L'ambiguïté est particulièrement vive pour les administrations productrices de communs. La France dispose d'un écosystème public actif : le pôle Open Source de la DINUM (Direction interministérielle du numérique) anime le Socle interministériel de logiciels libres (SILL), publie du code sous licence libre via code.gouv.fr, et pilote depuis 2022 un Conseil logiciels libres réunissant agents publics et acteurs de l'écosystème. Une administration dotée de la personnalité morale qui soutient durablement un logiciel libre pourrait-elle être qualifiée de steward ? La vérification des sources primaires est ici sans appel : ni le règlement, ni le considérant 19, ni le guide de la Commission du 27 juillet 2026, ni la FAQ de l'Eclipse Foundation ne traitent explicitement le cas des entités publiques comme stewards. Le secteur public n'apparaît dans le guide qu'en qualité de financeur de logiciels libres, jamais comme steward. Le critère juridique (personne morale, autre qu'un fabricant, soutenant un logiciel destiné à des activités commerciales) n'exclut pas une administration, mais aucun texte ne tranche la question. Cette zone grise n'est pas anecdotique : elle laisse des producteurs publics de communs sans savoir s'ils entrent dans une catégorie dont ils devraient assumer les obligations.

La reconnaissance sans dotation produit un effet prévisible. Les obligations, même allégées, supposent une capacité de détection, un processus d'astreinte, une chaîne de notification et une coopération avec les autorités de surveillance. Ces capacités ont un coût fixe que les grandes fondations et les entreprises peuvent absorber et transformer en avantage concurrentiel. Red Hat, par exemple, déclare avoir analysé plus de 800 projets et retenu quinze projets pour lesquels il s'identifie comme steward, répartis en un niveau « Champion » (Ansible, Fedora, CentOS Stream, Konflux, Quay, StackRox, OKD) et un niveau « Light » (crun, hermeto, IIB, Maistra, OSbuild, Pulp, RamaLama, sssd). Les producteurs modestes, associations, petites fondations, administrations, portent la même horloge sans les mêmes moyens. Le régime allégé protège du risque financier des amendes, mais pas du coût réel de la conformité.

Article 3, point 14, du règlement (UE) 2024/2847

'open-source software steward' means a legal person, other than a manufacturer, that has the purpose or objective of systematically providing support on a sustained basis for the development of specific products with digital elements, qualifying as free and open-source software and intended for commercial activities, and that ensures the viability of those products".

Rendre visible n'est pas rendre soutenable

Le CRA a fait ce que fait toute régulation ambitieuse : il a nommé une réalité pour la gouverner. En créant le steward, il a tiré le travail d'entretien du commun numérique de la couche de silence où il opérait, pour le porter dans l'arène de la voix, selon le mouvement décrit par Star et Strauss. Mais rendre visible n'est pas rendre soutenable. La tension posée au départ demeure entière : le règlement reconnaît l'intendant du commun sans lui donner les moyens de son intendance, et laisse dans l'ombre le statut des administrations qui produisent ces communs.

De là une hypothèse vérifiable. Si aucun mécanisme de financement ou de mutualisation n'émerge, le rôle de steward se concentrera sur les organisations les mieux dotées, tandis que les producteurs publics et les petites structures éviteront l'étiquette ou l'endosseront à moyens constants, au prix d'une sous-conformité silencieuse. Plusieurs indicateurs, observables sans information interne d'ici au 11 décembre 2027, date d'application complète, permettront de trancher : la publication par le Conseil logiciels libres de la DINUM d'un avis identifié sur le statut de steward des administrations françaises ; l'apparition d'une entité publique française parmi les stewards déclarés ou parmi les membres du groupe de travail Open Regulatory Compliance de l'Eclipse Foundation ; l'inscription d'une ligne budgétaire de conformité CRA dans le rapport annuel d'une fondation de communs ; ou encore le franchissement, dans le rapport OpenSSF 2027, d'un seuil d'échantillon de stewards nettement supérieur aux 28 répondants de 2026. Si ces signaux restent absents à l'échéance, l'hypothèse d'une reconnaissance sans dotation se trouvera confirmée.

Note méthodologique

Cette chronique s'appuie en priorité sur les sources primaires : le règlement (UE) 2024/2847 (articles 3, 14, 24, 64 et considérants 18 à 20), le guide de la Commission du 27 juillet 2026 (C(2026) 5252) et les pages officielles de l'ANSSI. Le concept central mobilisé est le travail invisible de Star et Strauss (1999), opérationnalisé sur le basculement de visibilité opéré par l'article 24. Deux arbitrages ont été tranchés seul. D'abord, le statut des administrations publiques comme stewards a été présenté au conditionnel, faute de source qui le confirme : c'est une déduction juridique, non un fait établi. Ensuite, sur la lettre de l'article 24(3), les délais de 24 heures et 72 heures ont été attribués aux paragraphes 14(2) et 14(4), et non au seul paragraphe cité par l'article 24, pour éviter une imprécision fréquente dans la presse. Le parallèle du DPO a été préféré à ceux du marquage CE et de NIS2 pour sa proximité structurelle (création d'une figure intermédiaire par obligation). La piste de l'économie des communs d'Elinor Ostrom a été écartée comme non centrale. Les chiffres de l'OpenSSF proviennent d'une enquête déclarative dont l'échantillon de stewards est faible, réserve signalée dans le corps du texte. La date et le titre du guide de la Commission ainsi que le verbatim de l'article 24(3) demeurent à revérifier sur EUR-Lex et sur le site officiel de la Commission avant publication.

Sources

Sources primaires institutionnelles

Rapports officiels et données chiffrées

Cadres théoriques

Parallèle historique

Presse spécialisée

Toutes les analyses