Statut au 11 août 2026. Le Règlement européen sur la cybersécurité des produits (Règlement (UE) 2024/2847) définit les exigences en matière de cybersécurité pour les produits avec des éléments numériques mis sur le marché de l'Union. Les orientations pratiques de la Commission ont été publiées le 27 juillet 2026. Les obligations liées à la déclaration s'appliquent à partir du 11 septembre 2026 ; l'ensemble principal des obligations pour les produits s'applique à partir du 11 décembre 2027. Ce guide s'adresse aux ingénieurs logiciels dont les produits pourraient être concernés, et non aux juristes chargés de l'évaluation de conformité.
Clarté sur le périmètre : le CRA ne remplace pas SOC 2, ISO 27001 ou le RGPD. Ce n'est pas "une autre case à cocher pour un bot de conformité". De nombreuses obligations du CRA concernent le fabricant, la documentation et les processus post-commercialisation. Seule une partie peut être identifiée dans une pull request classique : l'inventaire des dépendances et la fraîcheur du SBOM, les canaux de divulgation des vulnérabilités, et les contrôles de sécurité supprimés sous forme de code mort. Si votre équipe juridique ou produit n'a pas confirmé que le CRA s'applique à ce que vous livrez, arrêtez-vous ici et demandez-leur.
Calendrier des entrées en vigueur (pour les développeurs)
À partir du 11 septembre 2026, les obligations de déclaration liées au régime de déclaration des vulnérabilités et des incidents du CRA commencent à s'appliquer selon le calendrier défini par le Règlement et les orientations de la Commission pour les fabricants. À partir du 11 décembre 2027, les principales exigences de cybersécurité des produits (y compris les attentes en matière de sécurité par conception, les processus de gestion des vulnérabilités et la transparence liée au SBOM pour les produits avec des éléments numériques) s'appliquent plus largement. La classification exacte de votre produit (par défaut, important, critique) est une question juridique et produit, pas quelque chose qu'une revue de code peut décider.
Considérez ces dates comme des repères de planification. Si des corrections du Journal officiel ou des orientations ultérieures les modifient, réévaluez cette page (voir le registre de fraîcheur des dates).
Ce qui peut effectivement apparaître dans une pull request
Actualisation des dépendances et du SBOM : une modification fixe une composante obsolète, supprime la génération du SBOM dans le CI, ou arrête la publication de l'inventaire des composantes dont votre processus de gestion des vulnérabilités dépend. Voie de gestion des vulnérabilités : une modification supprime ou désactive de manière codée en dur un contact de sécurité, un flux d'avis ou un webhook de triage interne des vulnérabilités que votre processus aligné sur le CRA suppose exister. Érosion de la sécurité par conception : une PR de "nettoyage" supprime l'authentification sur un port admin, désactive les vérifications de mise à jour ou désactive la vérification d'intégrité des paquets de mise à jour car ils étaient bruyants.
Ce sont des formes techniques. Elles ne constituent pas un dossier complet de conformité CRA, une histoire de marquage CE ou une évaluation par un organisme notifié.
Exemple concret : le CI arrête de générer l'inventaire des composantes
Une équipe plateforme réduit le CI de deux minutes en supprimant une tâche qui exécutait syft (ou équivalent) et téléchargeait un artefact SBOM à chaque tag de version. Le Dockerfile et l'application continuent de s'assembler. Les tests restent verts. Les commentaires de revue portent sur le coût du pipeline. Des semaines plus tard, l'équipe de sécurité ne peut pas répondre à la question "quelles versions ont été livrées dans la 1.8.3" sans reconstituer à partir des couches.
Si votre produit est dans le périmètre du CRA et que votre processus dépend de cet inventaire pour la gestion des vulnérabilités et la transparence, la suppression de cette tâche n'est pas une simple hygiène neutre. Une revue consciente des exigences de conformité signale la perte de l'étape d'inventaire dans la PR, afin que les équipes produit et sécurité puissent accepter formellement le risque ou restaurer la tâche. heygrc citant un contrôle de cadre ici est un signal, pas une détermination que le produit est non conforme.
Objectifs explicitement exclus
Ce guide ne couvre pas les modules d'évaluation de conformité, le marquage CE, l'enregistrement du fabricant, la rédaction de la déclaration de conformité UE, ni la détermination de savoir si votre produit est "important" ou "critique" au regard du CRA. Il n'affirme pas que heygrc rend un produit conforme au CRA. Il ne remplace pas votre PSIRT, votre revue juridique ou votre plan de réponse à la surveillance du marché.
Si vous n'aviez besoin que de SOC 2 ou d'ISO 27001 pour vos clients, le CRA peut rester sans pertinence. Ne le forcez pas.
Rôle de heygrc et limite de transparence
heygrc est conçu pour mettre en évidence les modifications de pull request pertinentes pour les contrôles, en fonction des cadres que vous activez. Pour l'hygiène technique liée au CRA, la superposition utile est la même classe de constats que le développement sécurisé et la gestion des vulnérabilités dans d'autres cadres (par exemple, les exigences logicielles de NIS 2 Art. 21, les contrôles de développement sécurisé de ISO 27001) : suppression des vérifications d'intégrité des mises à jour, affaiblissement de l'authentification, suppression des tâches d'inventaire. Cartographiez avec soin ; n'inventez pas de numéros d'articles du CRA pour les constats à moins que votre base de connaissances activée ne les inclue.
Conservez SAST, les scanners de dépendances et votre relecteur de code. Le CRA, en tant que loi sur les produits, se situe principalement en dehors du diff. Le diff ne capture que la partie qui supprime discrètement ce que ces programmes supposent encore en cours d'exécution.