Conformité
Le règlement demande ce que votre parc doit savoir dire
Le Cyber Resilience Act impose une nomenclature logicielle, des correctifs pendant toute la période de support, et une alerte précoce sous vingt-quatre heures après la prise de connaissance. Toutes ces obligations butent sur la même question : que tourne-t-il réellement sur le parc, aujourd'hui ?
Prise 5
Ce que le règlement demande
Le Cyber Resilience Act (règlement (UE) 2024/2847) s'applique aux « produits comportant des éléments numériques » mis sur le marché européen. Si vous vendez une passerelle, un boîtier connecté, un terminal ou un calculateur, vous en êtes le fabricant au sens du texte, et ses obligations vous visent.
- 10 décembre 2024Entrée en vigueur du règlement.
- 11 septembre 2026Les obligations de signalement s'appliquent - c'est en cours : vulnérabilités activement exploitées et incidents graves.
- 11 décembre 2027L'ensemble des obligations s'applique. Marquage CE à la clé.
Quatre obligations qui touchent directement le parc
Connaître ses composants, et le prouver
L'annexe I demande d'identifier et de documenter les composants d'un produit, au moyen d'une nomenclature logicielle - un SBOM - dans un format lisible par machine, couvrant au minimum les dépendances de premier niveau.
Corriger pendant toute la période de support
Les vulnérabilités doivent être traitées sans délai, et les correctifs diffusés gratuitement. La période de support couvre la durée de vie attendue du produit, avec un plancher de cinq ans.
Signaler vite
Une vulnérabilité activement exploitée, ou un incident grave, déclenche une alerte précoce sous vingt-quatre heures après que le fabricant en a pris connaissance, auprès de l'ENISA et du CSIRT compétent, puis un signalement circonstancié sous soixante-douze heures, puis un rapport final. Le délai court depuis la prise de connaissance, pas depuis l'événement - mais tout ce que la prise de connaissance déclenche suppose de savoir, vite, quelles machines sont concernées.
Tenir la documentation
La conformité se démontre par des documents : analyse de risque, nomenclature, traitement des vulnérabilités, preuve de diffusion des correctifs.
Le vrai problème n'est pas d'écrire un SBOM. C'est de savoir ce qui tourne.
Un SBOM produit au moment de la mise sur le marché décrit ce que vous avez expédié. Trois ans plus tard, le parc a reçu des mises à jour, des interventions locales, des cartes remplacées en atelier, des paquets installés par un technicien pressé. La question que pose le règlement le jour où un avis de sécurité paraît porte sur le parc tel qu'il est maintenant, pas sur le manifeste d'une version.
Sans réponse à cette question, l'alerte précoce se rédige à l'aveugle : on ne sait pas dire si l'on est concerné, ni sur combien d'appareils, ni lesquels.
Ce que PipeLinker Hub apporte
L'inventaire logiciel de chaque machine, en continu
Les agents Linux et Windows remontent la liste des paquets installés : nom, version, architecture, éditeur, licence, taille, description. Sous Linux, lue directement dans les bases de dpkg, d'apk et de rpm ; sous Windows, dans les trois emplacements de désinstallation de la base de registre - 64 bits, 32 bits, et par utilisateur.
Des identifiants qui permettent réellement le rapprochement
Chaque paquet porte un identifiant normalisé au format Package URL. Le nom seul ne suffit pas : « openssl » ne désigne pas le même contenu selon la distribution, et un correctif rétroporté conserve un numéro de version ancien tout en corrigeant la faille. L'identifiant porte donc aussi la distribution, sa version, et le paquet source dont le binaire est issu - Debian, Ubuntu et Red Hat publiant leurs avis par source, jamais par binaire.
Un export CycloneDX, vérifié plutôt qu'annoncé
La nomenclature de chaque machine s'exporte au format CycloneDX, à donner à votre outil de rapprochement. Le contrôle que nous avons fait : le document produit pour une machine Debian 13 mène Grype aux mêmes 730 vulnérabilités que son analyse directe de cette machine, sans écart ni excédent.
La recherche dans tout le parc, en une question
C'est la question du jour où l'avis paraît : qui porte ce paquet ? La recherche porte sur le nom comme sur l'identifiant normalisé, et trouve donc « libssl3 » quand on cherche « openssl », son paquet source.
Les changements à la seconde, pas au réveil du lendemain
Un paquet ajouté, retiré ou mis à jour émet un événement immédiat. Une application installée puis retirée dans la journée est invisible d'un instantané quotidien au suivant ; l'événement, lui, arrive dans la seconde.
Diffuser le correctif, et pouvoir le prouver
Les mises à jour sont signées, et l'agent en vérifie la signature avant d'installer plutôt que de faire confiance au serveur qui les lui envoie. Le déploiement est progressif - canari, groupe de test, 10 %, 50 %, 100 % - et s'interrompt sur agent hors ligne ou contrôle de santé en échec. Le journal d'audit conserve ce qui a été poussé, quand, par qui, et sur quoi.
Ce que PipeLinker Hub ne fait pas
Il ne produit pas le SBOM de votre propre logiciel. Il inventorie ce qui est installé sur la machine, pas les dépendances de la brique que vous compilez. Celle-là relève de votre chaîne de construction, où le SBOM se génère à la source.
Il ne fait pas le rapprochement avec les bases de vulnérabilités. Il produit du CycloneDX exploitable, et vous le donnez à Grype, à Dependency-Track ou à l'outil que vos équipes utilisent déjà. Nous préférons produire une donnée juste plutôt qu'un tableau de bord de plus.
Et ceci n'est pas un avis juridique. La conformité au règlement ne se résume pas à connaître son parc : elle engage votre analyse de risque, votre documentation technique et votre procédure de signalement. Nous couvrons la partie que le parc doit savoir dire.
Dites-nous quels équipements, derrière quels réseaux. On vous montre la console dessus.
Et du côté des accès, ce qui se démontre
Le règlement demande de savoir ce qui tourne ; il demande aussi de savoir qui y a touché. Le hub garde de quoi le dire :
- l'identité de l'intervenant, rattachée à chaque session ;
- les droits dont il disposait, par rôle, par parc et par cible ;
- le journal d'audit : qui, quoi, sur quelle machine, quand, combien de temps ;
- la révocation, immédiate et individuelle ;
- les sessions de terminal et d'écran, enregistrées et rejouables ;
- la conservation de tout cela chez vous, avec vos propres durées.
Pourquoi cela vaut d'être en place maintenant
Les obligations de signalement s'appliquent depuis le 11 septembre 2026, et ce sont les plus exigeantes en temps de réaction. Vingt-quatre heures pour une alerte précoce, ce n'est pas le délai pour corriger : c'est le délai pendant lequel il faut pouvoir dire ce qui est exposé. Un parc qu'on interroge en quelques secondes rend ce délai tenable ; un parc qu'on inventorie à la main ne le tient pas, quel que soit le sérieux de l'équipe.
Les sources
Le texte du règlement : règlement (UE) 2024/2847 sur EUR-Lex. La page de la Commission européenne : Cyber Resilience Act. Cette page présente des éléments techniques et ne constitue ni un avis juridique, ni une certification de conformité.
Page mise à jour le 22 septembre 2026. Page tenue par l'équipe PipeLinker de LOOTUS SECURITY, éditeur du produit. La date vient du dépôt, pas d'une saisie.