Cyber Resilience Act : l’Europe entre dans le circuit des failles

Dans sa FAQ mise à jour le 3 octobre 2026, l’ENISA décrit une singularité de sa nouvelle plateforme : le compteur peut annoncer un retard avant l’expiration du délai légal. La cause est connue. Il ajoute actuellement quarante-huit heures à l’envoi de l’alerte précoce, alors que le règlement fait partir les soixante-douze heures de la prise de connaissance de l’événement. L’agence annonce une correction ultérieure. ^[2]

Le détail mérite davantage qu’une moquerie sur l’informatique administrative. Il ouvre une question centrale du Cyber Resilience Act, le règlement européen sur la cyberrésilience : comment faire circuler une information de sécurité alors que ceux qui la reçoivent disposent encore de moyens incomplets pour protéger les utilisateurs ? Un formulaire peut être transmis. Une exploitation peut être confirmée. Le correctif, lui, reste parfois à concevoir, à tester, puis à faire parvenir aux produits concernés.

Depuis le 11 septembre 2026, les fabricants entrant dans le champ du texte doivent notifier les vulnérabilités activement exploitées de leurs produits et les incidents graves affectant leur sécurité. L’ENISA, l’agence européenne pour la cybersécurité, a ouvert ce jour-là la plateforme commune de signalement. Les principales exigences de sécurité des produits s’appliqueront le 11 décembre 2027. Les obligations propres aux organismes que le texte appelle les « intendants de logiciels ouverts » commencent également à cette seconde date. ^{[1] [5] [10]}

Cette entrée en application progressive installe les autorités dans une phase sensible de la vie du logiciel : celle où une faiblesse est comprise par quelques personnes, peut déjà être utilisée par un attaquant, et circule sous confidentialité entre ceux qui préparent la réponse. L’enjeu est de transformer cette connaissance en protection, tout en maîtrisant sa diffusion. Le texte organise ce passage avec plus de nuances que ne le laisse entendre la formule des « vingt-quatre heures ».

Le déclencheur se trouve dans le produit

Pour comprendre le dispositif, suivons une bibliothèque logicielle. Il s’agit d’un composant réutilisable, intégré dans des applications ou des équipements. Son code peut être identique chez plusieurs fabricants, tandis que les fonctions activées, les versions livrées et les conditions d’utilisation diffèrent. L’exemple qui suit est pédagogique : aucune entreprise réelle n’y est mise en cause.

Un chercheur découvre une faiblesse dans cette bibliothèque. Chez un premier fabricant, la fonction vulnérable est inaccessible dans le produit livré. Chez un deuxième, elle est utilisable, mais aucune exploitation malveillante dans le produit n’est établie. Un troisième reçoit des éléments fiables montrant une exploitation non autorisée de son produit. Ces situations demandent toutes une analyse de sécurité. Elles aboutissent à des conclusions différentes sur l’obligation de notification d’une vulnérabilité activement exploitée.

Le règlement définit cette dernière par l’existence de preuves fiables qu’un acteur malveillant a exploité la faiblesse dans un système sans l’autorisation de son propriétaire. Les orientations publiées par la Commission le 27 juillet 2026 précisent, au paragraphe 218, que le fabricant apprécie cette condition dans son propre produit. Elles distinguent expressément le code qui ne peut pas y être exploité et la vulnérabilité qui n’y a pas été exploitée. L’existence d’un composant vulnérable commun ne déclenche donc pas mécaniquement une notification obligatoire chez chaque intégrateur. ^{[1] [3]}

Cette précision donne une fonction essentielle au travail de qualification. Une référence de vulnérabilité dans une base publique aide à identifier une faiblesse ; l’équipe doit encore établir son rapport avec le produit distribué. Quelle version contient le code ? La fonction est-elle accessible ? Les éléments reçus décrivent-ils une tentative, une démonstration autorisée ou une exploitation malveillante ? Le raisonnement doit pouvoir être expliqué, surtout lorsque les informations évoluent.

L’autre porte d’entrée est l’incident grave ayant des répercussions sur la sécurité du produit. L’article 14 vise notamment un événement qui affecte, ou peut affecter, la capacité du produit à protéger la disponibilité, l’authenticité, l’intégrité ou la confidentialité de données ou fonctions sensibles ou importantes. Il vise aussi un événement qui conduit, ou peut conduire, à l’introduction ou à l’exécution de code malveillant. Cette qualification possède ses propres critères. Elle doit être examinée séparément, y compris lorsqu’une analyse ne conclut pas à une vulnérabilité activement exploitée dans le produit. ^[1]

Enfin, le destinataire de ces obligations est le fabricant au sens du règlement : celui qui développe ou fait développer le produit et le commercialise sous son nom ou sa marque. Le champ comporte des conditions et des exclusions, notamment pour certains logiciels libres fournis hors activité commerciale. Un logiciel gratuit peut relever d’un produit commercial ; contribuer à un dépôt libre ne suffit pas à faire de son auteur un fabricant. La qualification suit l’activité et le produit, plutôt que l’étiquette « open source ». ^[1]

Le temps commence avec la connaissance

Le point de départ légal est la prise de connaissance. Les orientations de la Commission décrivent une évaluation initiale immédiate du signal suspect, jusqu’à disposer d’un degré raisonnable de certitude sur l’exploitation ou l’incident. Elles insistent sur la rapidité de cette première analyse. Le temps nécessaire pour qualifier un indice se distingue ainsi du délai de notification qui s’ouvre lorsque les conditions sont réunies. Cette explication guide l’application du texte ; elle ne crée aucun droit à laisser une alerte en attente. ^[3]

L’alerte précoce doit être transmise sans retard injustifié et, au plus tard, dans les vingt-quatre heures suivant la prise de connaissance. Elle apporte des informations limitées. La notification enrichie suit, avec les éléments disponibles, sans retard injustifié et au plus tard dans les soixante-douze heures, à partir du même événement initial. Elle décrit notamment le produit, la nature générale de l’exploitation et les mesures prises ou utilisables par les clients. L’enquête technique peut continuer pendant que le dossier s’enrichit. ^[1]

Prenons un cas purement arithmétique : l’alerte précoce est envoyée six heures après la prise de connaissance. Avec le calcul de compteur décrit par l’ENISA, l’affichage arrive à échéance à la cinquante-quatrième heure : six plus quarante-huit. Le plafond légal reste fixé à la soixante-douzième heure, soit dix-huit heures plus tard. Cet écart ne constitue ni un délai supplémentaire accordé à l’entreprise, ni la preuve d’une sanction erronée. Il montre pourquoi un indicateur d’interface doit être confronté à sa règle de calcul. ^{[1] [2]}

Le rapport final révèle encore mieux la logique du dispositif. Pour une vulnérabilité activement exploitée, il doit arriver au plus tard quatorze jours après la disponibilité d’une mesure corrective ou d’atténuation. Le point de départ peut donc être un correctif ou une mesure qui réduit le risque. Pour un incident grave, le rapport final est dû dans le mois suivant la notification enrichie. Ces échéances documentent deux parcours différents. Aucun de ces nombres ne fournit, à lui seul, une date à laquelle toutes les machines seront protégées. ^[1]

La séparation est utile à la lecture d’une crise. L’alerte indique que le fabricant possède une connaissance qui mérite d’être partagée. La mesure d’atténuation décrit une action protectrice disponible. L’installation effective dans les produits des clients constitue une étape supplémentaire. Confondre leurs dates peut donner l’impression qu’une crise est achevée alors que son traitement vient seulement de devenir possible.

Le cercle de ceux qui savent s’élargit

La plateforme commune, ou Single Reporting Platform, a pour fonction de faire parvenir le signalement au CSIRT coordinateur compétent et à l’ENISA simultanément, selon le régime normal. Un CSIRT est une équipe de réponse aux incidents informatiques. Le coordinateur initial retransmet ensuite l’information aux coordinateurs des États membres dans lesquels le fabricant indique avoir mis le produit à disposition. La circulation est liée aux marchés concernés, avec des exceptions de sécurité ; le règlement ne prévoit pas un envoi indistinct de chaque dossier à tous les services publics européens. ^[1]

La plateforme reste en phase de déploiement. Dans sa FAQ du 3 octobre 2026, l’ENISA précise que la fonction de notification volontaire prévue par l’article 15 n’est pas encore disponible. Il faut donc distinguer les possibilités ouvertes par le droit et les fonctions effectivement proposées par le service à cette date. ^{[1] [2]}

L’architecture apporte une capacité que la relation bilatérale entre un fabricant et son client ne garantit pas : rapprocher des signaux venant de produits et de territoires différents. Imaginons plusieurs fabricants touchés par un composant commun. Chacun possède une partie des indices. Leur réunion peut aider les équipes de réponse à reconnaître un risque plus large, à orienter les mesures d’atténuation et à contacter les acteurs concernés. C’est le mécanisme recherché par le dispositif, et l’un des bénéfices présentés par l’ENISA lors du lancement. Son efficacité réelle devra être appréciée sur les réponses obtenues. ^[10]

Cette connaissance commune a un revers à gérer : certains éléments utiles au défenseur peuvent aussi aider un attaquant à comprendre la faiblesse. Le choix des destinataires et du niveau de détail devient une composante de la réponse technique. L’article 16 exige des protocoles stricts et un partage selon le besoin d’en connaître lorsqu’aucune mesure corrective ou d’atténuation n’est disponible. Il impose également des mesures de sécurité à l’ENISA pour la plateforme et les informations qu’elle transporte. ^[1]

L’information des utilisateurs possède sa propre finalité. Après avoir pris connaissance de l’événement, le fabricant doit informer les utilisateurs touchés et, lorsqu’il y a lieu, l’ensemble des utilisateurs, avec les mesures nécessaires pour réduire le risque. Les orientations expliquent que les détails peuvent être réservés aux destinataires concernés, en particulier dans les environnements sensibles. Avertir un exploitant d’une action protectrice à effectuer et publier les détails techniques de la faiblesse répondent à des besoins différents. ^{[1] [3]}

Le règlement distingue aussi ce circuit de la base européenne publique des vulnérabilités. Son article 17 prévoit, après la mise à disposition d’une mise à jour ou d’une mesure d’atténuation, l’ajout de vulnérabilités publiquement connues, en accord avec le fabricant. Un signalement confidentiel dans la plateforme n’est donc pas une fiche publique automatiquement publiée dans cette base. Entre les deux, des décisions sur le contenu, les destinataires et le moment de diffusion restent nécessaires. ^[1]

Le texte prévoit des freins à la diffusion

La crainte d’élargir trop tôt le cercle des destinataires précède la loi définitive. Dans une lettre du 15 juin 2023, EDRi, l’EFF, la Fondation Eclipse et d’autres signataires redoutaient la constitution, auprès d’organismes publics, de stocks d’informations sur des vulnérabilités encore sans remède. Ils demandaient notamment de limiter les détails diffusés et d’encadrer leur utilisation. Cette prise de position portait sur le projet de règlement de l’époque. ^[7]

Pour apprécier la réponse européenne, il faut lire le texte adopté, puis le règlement délégué 2026/881, adopté le 11 décembre 2025 et publié au Journal officiel le 20 avril 2026. Ce dernier explicite les circonstances dans lesquelles le coordinateur initial peut retarder la diffusion vers d’autres CSIRT. Le fabricant peut soulever le problème ; la décision appartient au coordinateur et doit rester limitée au temps strictement nécessaire. ^[4]

Un cas éclaire l’arbitrage. Des détails transmis pourraient suffire à créer une technique d’exploitation, notamment pour des acteurs peu compétents. Le coordinateur peut alors retenir la diffusion si les risques excèdent les bénéfices de sécurité et si les règles de manipulation et de repartage ne suffisent pas à les réduire. Une autre possibilité consiste à transmettre immédiatement les éléments permettant aux autres équipes de protéger leurs utilisateurs, puis à envoyer le reste lorsque la mesure d’atténuation est disponible. ^[4]

Le même texte prévoit le cas d’un remède attendu dans les soixante-douze heures. Sous les conditions précédentes, cette perspective peut justifier un report de diffusion. Si la mesure attendue n’arrive pas dans cette fenêtre, le coordinateur doit transmettre la notification aux CSIRT concernés. Ces soixante-douze heures appartiennent au mécanisme de partage entre autorités. Elles ne repoussent pas la notification que le fabricant doit effectuer après sa prise de connaissance. ^[4]

La réglementation va jusqu’à envisager une défaillance du destinataire. Le coordinateur peut différer l’envoi vers un CSIRT particulier dont la capacité à préserver la confidentialité est mise en doute dans les conditions prévues. Un incident affectant la plateforme peut également justifier un report de la diffusion par son intermédiaire. Ces dispositions reconnaissent qu’une infrastructure de signalement constitue elle-même un élément à protéger. Elles décrivent des situations prévues par le droit, pas des incidents dont notre enquête établirait la survenue. ^[4]

L’accès de l’ENISA suit une exception plus étroite. Dans les circonstances particulièrement exceptionnelles de l’article 16(2), certains détails de la notification de vulnérabilité à soixante-douze heures peuvent être retenus temporairement. L’agence reçoit tout de même l’existence du signalement et des informations générales. Les conditions visent notamment une exploitation connue limitée à l’État concerné, les intérêts essentiels de cet État, ou un risque cyber imminent élevé lié à la diffusion. Ce mécanisme ne permet pas de masquer librement toute alerte initiale à l’agence. ^{[1] [4]}

Ces garde-fous répondent à une partie de la critique de 2023. Ils laissent un arbitrage concret aux équipes : quelles informations améliorent immédiatement la défense, et lesquelles créeraient une exposition supplémentaire avant le remède ? On pourra apprécier la qualité du système à la manière dont ces décisions sont motivées et réexaminées. L’existence de la règle fournit un cadre ; elle ne renseigne pas encore sur toutes les décisions prises à l’intérieur de ce cadre.

Onze jours dans la vie d’un correctif

Le projet curl offre un exemple documenté du calendrier que le CRA vient rencontrer. Pour la vulnérabilité CVE-2023-38545, son avis de sécurité indique un signalement au projet le 30 septembre 2023, un contact avec la liste de coordination des distributions le 3 octobre, puis la sortie de libcurl 8.4.0 le 11 octobre, avec publication de l’avis. Onze jours calendaires séparent les deux extrémités. ^[8]

L’intérêt de cette chronologie tient à ce qui se passe entre les dates. La procédure publique actuelle de curl prévoit une réception confidentielle, une qualification, le travail sur une correction et une annonce coordonnée. Elle permet de comprendre la fonction de la discrétion : donner aux personnes qui préparent la réponse un espace de travail avant la diffusion publique. Cette procédure actuelle ne permet pas de reconstituer chaque échange de 2023. ^[9]

On ne peut donc pas appliquer rétroactivement le délai européen à ces onze jours. Il faudrait, dans un cas relevant du CRA, établir une exploitation active au sens du texte, identifier le fabricant concerné et déterminer quand il en a pris connaissance. La découverte d’une faille par un chercheur autorisé ne suffit pas à elle seule. Cette distinction évite de traiter toute préparation confidentielle d’un correctif comme une période de silence fautif. Les orientations précisent aussi qu’une exploitation active déjà connue avant le 11 septembre 2026 ne doit pas être signalée rétroactivement ; une exploitation dont le fabricant prend connaissance après cette date relève du nouveau régime. ^{[1] [3]}

La comparaison montre néanmoins le déplacement introduit par le règlement. Dès que son déclencheur est satisfait, une notification confidentielle aux autorités doit s’insérer dans le travail en cours. Le calendrier de publication du projet et celui du signalement réglementaire peuvent ainsi coexister. Pour les faire fonctionner ensemble, il faut savoir qui qualifie le produit, qui prépare sa correction et qui est habilité à partager quels éléments. La coordination possède un contenu technique : elle organise la séquence qui rend l’information utile plutôt que dangereuse.

Le logiciel libre entre par plusieurs portes

Pour un projet libre, les personnes qui écrivent le code, l’organisation qui soutient son développement et l’entreprise qui le livre dans un produit peuvent être différentes. Le CRA donne un statut à certaines de ces organisations de soutien : les intendants de logiciels ouverts, ou open-source software stewards. La définition vise une personne morale, distincte du fabricant, qui apporte un soutien systématique et continu au développement de produits libres spécifiques destinés à des activités commerciales et en assure la viabilité. ^[1]

Leur régime commence le 11 décembre 2027. L’article 24 prévoit notamment une politique de cybersécurité documentée et une coopération avec les autorités de surveillance. Il leur applique le signalement des vulnérabilités activement exploitées dans la mesure où ils participent au développement. Pour les incidents graves, le rattachement concerne les réseaux et systèmes qu’ils fournissent pour ce développement. Cette dernière condition est importante : elle rattache l’obligation à leur rôle propre dans la chaîne logicielle. ^{[1] [5]}

La clarification du calendrier a eu un effet organisationnel visible. Dans un message public du 11 septembre 2026, la Fondation Eclipse, qui se présente comme intendant de ses projets, explique qu’elle était prête à signaler mais utilisera le temps restant pour affiner ses processus après la clarification de la Commission du 4 septembre. Elle maintient les procédures de sécurité existantes pour ses contributeurs. C’est la position déclarée de la fondation, sans audit de sa préparation dans notre dossier. ^[6]

Le texte de la Commission confirme la date. Sa FAQ, version 1.4 du 4 septembre 2026, ajoute précisément une réponse sur les intendants : l’article 24(3) s’applique en décembre 2027. Cette précision explique le calendrier ; elle ne constitue pas un report de la loi par une foire aux questions. ^[5]

Pour autant, le projet peut recevoir dès maintenant des demandes d’un fabricant déjà soumis à l’article 14. Dans notre exemple, l’équipe produit a besoin de comprendre la bibliothèque avant de qualifier l’événement. Le mainteneur connaît le code ; l’intégrateur connaît sa configuration livrée et, parfois, les indices d’exploitation chez ses clients. Leurs informations se complètent. Attendre que toutes les catégories d’acteurs arrivent à leur échéance réglementaire laisserait cette coordination sans réponse pendant la période intermédiaire.

C’est aussi une limite à toute lecture fondée sur la seule licence. Un même composant libre peut se trouver dans un projet non commercial, être soutenu par une fondation et entrer dans un produit commercial. La relation au CRA varie à chaque étage. Cette distinction protège la compréhension du rôle des contributeurs, tout en maintenant les obligations du fabricant sur le produit qu’il met à disposition. Elle n’efface ni les besoins de sécurité ni les échanges nécessaires entre ces étages. ^[1]

Le correctif doit pouvoir remonter

Une disposition moins visible que les délais mérite l’attention du libre. L’article 13(6), applicable avec les obligations générales à partir du 11 décembre 2027, demande au fabricant qui identifie une vulnérabilité dans un composant intégré d’en informer celui qui le fabrique ou le maintient. Si le fabricant développe une modification pour corriger ce composant, il doit partager le code ou la documentation pertinente avec cet interlocuteur. ^[1]

L’obligation ajoute une circulation en sens inverse de celle des téléchargements. Un intégrateur peut connaître une condition de défaillance révélée par son produit et développer une solution. Faire remonter cette connaissance peut permettre au projet d’origine d’examiner le problème, d’améliorer sa propre version et d’en faire bénéficier d’autres intégrateurs. Le mécanisme réduit une asymétrie : le code commun arrive chez le fabricant, tandis que certaines informations sur son comportement restent dans les produits qui l’utilisent.

Les orientations de juillet donnent à ce retour une forme praticable. Elles invitent à respecter les canaux de sécurité du projet, à éviter les doublons lorsque le mainteneur connaît déjà la vulnérabilité et à transmettre une correction dans un format vérifiable et adapté à la licence. Elles précisent aussi que le CRA n’impose pas au mainteneur d’accepter le correctif proposé. La revue technique garde sa fonction : une solution adaptée à un produit particulier peut demander un autre traitement dans le composant commun. ^[3]

L’analyse doit également localiser le défaut. Une erreur introduite par la façon dont le fabricant assemble sa propre application n’est pas nécessairement une vulnérabilité du composant intégré. Les orientations distinguent ces situations. Elles encouragent néanmoins le partage des comportements utiles à comprendre lorsque l’intégration révèle une propriété de sécurité jusque-là peu visible. Cette nuance évite de transformer le projet amont en destinataire automatique de tous les problèmes du produit aval. ^[3]

Le bénéfice possible est concret : un fabricant qui corrige sa copie locale peut donner au mainteneur les moyens d’évaluer la même amélioration pour les autres utilisateurs. Mais une obligation de partage ne garantit ni la qualité de la modification, ni son intégration, ni sa diffusion finale. Ces étapes continuent de demander des échanges techniques et des choix explicites. Le droit crée une relation ; la coopération doit encore produire un résultat exploitable.

La machine protégée reste au bout du parcours

Le calendrier d’application introduit enfin une asymétrie entre voir le risque et pouvoir le corriger. L’article 14 s’applique également à des produits mis sur le marché avant décembre 2027. Les orientations de la Commission précisent que le signalement peut rester dû après la fin du support, lorsque le fabricant prend connaissance d’un événement répondant aux critères. Cette obligation d’information ne réactive pas, à elle seule, l’ensemble des exigences générales de traitement des vulnérabilités pour ces produits. ^{[1] [3]}

Une alerte sur un ancien produit peut ainsi permettre aux utilisateurs de réduire leur exposition, de désactiver une fonction ou de préparer un remplacement, selon les mesures réellement disponibles. Sa valeur dépend de la possibilité d’agir avec l’information reçue. Dans une évaluation du CRA, le nombre de signalements devrait donc être rapproché d’autres observations : le temps jusqu’à une mesure protectrice, sa diffusion vers les versions concernées et la capacité des utilisateurs à vérifier leur situation. Ce sont des critères d’analyse proposés ici, sans série de résultats reconstituée.

L’article 17 prévoit une analyse technique périodique des tendances par l’ENISA, avec un premier rapport dans les vingt-quatre mois suivant le début des obligations de septembre 2026. L’article 70 fixe également au 11 septembre 2028 une évaluation de l’efficacité de la plateforme par la Commission. Dans les documents publics examinés pour cette enquête, nous n’avons pas trouvé de bilan permettant déjà de mesurer les délais de correction ou le nombre d’utilisateurs protégés grâce au nouveau circuit. Cette absence de confirmation publique ne permet de conclure ni à son succès ni à son échec. ^[1]

Le dossier fait en revanche apparaître un choix institutionnel précis. L’Europe demande à recevoir l’alerte pendant que le traitement technique se construit. Elle prévoit des restrictions de diffusion pour préserver cette phase et prépare, pour 2027, une circulation plus explicite des défauts et des corrections dans la chaîne logicielle. Pour évaluer ce choix, il faudra suivre les mesures proposées jusqu’aux versions effectivement livrées et aux utilisateurs capables de les appliquer. Les règles décrivent aujourd’hui ce parcours ; ses résultats restent à documenter.

Pour prolonger l’analyse, notre enquête sur les accès cyber dans l’éolien et le solaire suit la répartition des responsabilités autour des équipements. Le dossier sur les fournisseurs invisibles du risque bancaire examine une autre réglementation, DORA, appliquée aux dépendances informatiques du secteur financier. Ces lectures permettent de situer la sécurité des produits dans une chaîne plus large d’exploitation et de sous-traitance.

Sources et méthode

Enquête documentaire arrêtée au 10 octobre 2026. Le règlement et l’acte délégué sont les références normatives ; les orientations et FAQ en expliquent l’application. Les déclarations de l’ENISA et de la Fondation Eclipse sont attribuées à leurs auteurs. Le cas curl est historique, antérieur au CRA. Les produits fictifs et le calcul du compteur servent à expliquer les mécanismes. Aucun entretien propre, accès authentifié à la plateforme, audit de sécurité, dépôt de notification ou examen de dossier confidentiel n’a été réalisé. Les orientations de juillet ont été vérifiées directement dans l’annexe PDF officielle de la Commission. La FAQ de la Commission a été lue dans sa version Markdown officielle. Aucun bilan d’efficacité absent des pièces consultées n’est reconstitué.