Au-delà de la nomenclature des systèmes : pourquoi la loi sur la cyber-résilience représente un défi en matière de traçabilité PLM

Si vous êtes développeur de produits, ingénieur système ou administrateur PLM, vous avez probablement entendu parler au cours de l'année écoulée de la loi européenne sur la cyber-résilience (CRA) . La plupart des discussions dans le secteur ont porté sur les fondamentaux de la cybersécurité : les principes de sécurité dès la conception, le chiffrement et la génération d'une nomenclature logicielle (SBOM) dans des formats standard tels que CycloneDX ou SPDX.

On comprend aisément pourquoi. Les équipes de sécurité maîtrisent ces concepts. Elles considèrent la génération de SBOM comme un problème inhérent au processus de compilation logicielle : analyser le code, générer un fichier lisible par machine et valider la conformité.

Mais une nomenclature de stock (SBOM) ne fait que décrire le contenu de votre produit. Elle ne garantit pas ce qui est réellement livré au client et ne vous sera d'aucune utilité si une vulnérabilité critique est découverte et que vous n'avez que quelques heures pour réagir. C'est pourquoi l'obligation de conformité aux normes de sécurité (CRA) ne se limite pas à une simple exigence de cybersécurité : elle représente un défi majeur en matière de gestion du cycle de vie des produits (PLM) et de traçabilité.

Bilan du 11 septembre 2026 : le compte à rebours est déjà lancé

Alors que de nombreux fabricants se concentrent sur l'échéance du 11 décembre 2027 pour la mise en conformité totale (y compris le marquage CE et les évaluations de conformité), une étape cruciale a déjà été franchie. Depuis le 11 septembre 2026, les obligations de déclaration obligatoires de l'ARC sont officiellement entrées en vigueur.

En vertu de ces règles en vigueur, si votre produit contient des « éléments numériques » et est vendu sur le marché de l’UE, vous devez signaler les vulnérabilités exploitées et les incidents de sécurité graves à l’Agence de l’Union européenne pour la cybersécurité (ENISA) et aux autorités nationales. Les délais sont stricts :

• 24 heures : Vous devez soumettre une notification d'alerte précoce dès que vous avez connaissance d'une vulnérabilité activement exploitée ou d'un incident grave.
• 72 heures : Vous devez soumettre une notification détaillée, comprenant une évaluation initiale de la gravité et de l'impact de la vulnérabilité.

D'après les analyses juridiques et sectorielles, comme celles de BlackBerry, ces délais s'appliquent aux produits déjà commercialisés, et non seulement aux versions futures. Autrement dit, si une vulnérabilité est découverte dans un composant que vous utilisiez il y a trois ans, le délai court immédiatement.

Pourquoi la génération d'une nomenclature de schémas (SBOM) est la partie facile

Une nomenclature de schéma (SBOM) est un instantané. Elle indique ce que vos systèmes d'ingénierie considèrent comme ayant été intégré au produit lors de sa conception. Cependant, les produits physiques restent rarement identiques à leurs jumeaux numériques tout au long de leur cycle de vie.

Prenons l'exemple d'un fabricant d'électronique de pointe. La conception débute dans un logiciel de CAO électronique, se poursuit dans un système PLM sous forme de nomenclature technique (EBOM), puis est transmise à la production sous forme de nomenclature de fabrication (MBOM). Tout au long de ce processus, les composants sont approvisionnés, remplacés et mis à jour.

Lorsqu'une vulnérabilité est annoncée, il ne suffit pas de savoir si une bibliothèque logicielle ou un firmware de microcontrôleur spécifique est vulnérable en théorie. Il est impératif de connaître précisément les unités physiques livrées avec cette version, les clients qui les possèdent et si un fournisseur a remplacé ce composant lors d'une production. Si vos données produit sont dispersées dans des bases de données, des feuilles de calcul et des courriels non connectés, répondre à ces questions en 72 heures relève du miracle.

Le décalage : conformité traditionnelle vs traçabilité numérique

Pour comprendre pourquoi les approches traditionnelles sont insuffisantes dans le cadre du CRA, examinons comment les données produits sont généralement gérées par rapport à la manière dont elles doivent l'être dans un monde post-CRA :

Le cauchemar de la dérive des données produits

La dérive des données produit est un fléau silencieux pour la conformité. Dans la fabrication de produits électroniques, une carte de circuit imprimé (PCBA) peut subir de multiples substitutions de composants en usine en raison de ruptures d'approvisionnement ou de mesures d'optimisation des coûts. Un fournisseur peut, par exemple, remplacer un microcontrôleur ou une puce de mémoire flash.

Si ces modifications ne sont pas répercutées dans le système PLM central, votre dossier d'ingénierie officiel diverge de la réalité. Votre analyseur de sécurité automatisé peut vous indiquer que votre produit est sûr car la nomenclature technique officielle mentionne un composant sécurisé. Or, des milliers d'unités en service contiennent une puce de substitution vulnérable.

Les logiciels présentent un problème de dérive similaire. Les mises à jour de firmware, les correctifs et les dépendances open source évoluent constamment. Si votre cycle de vie de développement logiciel (SDLC) n'est pas étroitement intégré à votre système PLM physique et à la gestion de la configuration matérielle, vous perdez la possibilité de suivre quelle version logicielle est exécutée sur quelle variante matérielle.

Création d'un fil numérique pour un traçage rapide des vulnérabilités

Pour survivre aux délais de déclaration stricts des CRA, les fabricants doivent construire un fil numérique robuste reliant les outils PLM, d'ingénierie des systèmes basée sur des modèles (MBSE), ERP et de surveillance de la sécurité.

Cela ne signifie pas qu'il faille migrer toutes les données de l'entreprise vers un système monolithique. Il s'agit plutôt d'établir des relations actives et traçables entre ces systèmes. Lorsqu'un développeur logiciel met à jour une dépendance de firmware, cette modification doit être automatiquement répercutée sur la configuration matérielle concernée dans le système PLM. Lorsqu'un fournisseur demande le remplacement d'un composant, le processus d'approbation doit automatiquement mettre à jour la nomenclature SBOM active.

Comme le soulignent les récentes analyses de développement produit de Dassault Systèmes, la connexion des données d'ingénierie multidomaines (mécaniques, électriques et logicielles) est indispensable pour garantir la traçabilité continue exigée par les réglementations modernes. Lorsque la documentation de conformité s'intègre naturellement à votre flux de travail quotidien, un délai de reporting de 72 heures cesse d'être une situation critique et devient une procédure opérationnelle standard.

Comment réaliser son propre test de résistance de 72 heures

N’attendez pas un incident de sécurité réel pour vérifier si vos données produit sont prêtes. Vous pouvez effectuer un test de simulation dès aujourd’hui afin d’identifier les failles de votre chaîne de traçabilité

1. Sélectionnez un produit expédié : Choisissez un produit complexe et connecté qui est sur le marché depuis au moins un an.
2. Introduire une vulnérabilité simulée : choisissez une bibliothèque logicielle open source spécifique ou un composant électronique tiers utilisé dans ce produit.
3. Démarrez le chronomètre : donnez à votre équipe 72 heures pour identifier chaque unité expédiée, client, configuration et variante concernée par ce composant.
4. Vérifiez les résultats : la recherche s’est-elle appuyée sur des recherches dans des courriels individuels, des feuilles de calcul de fournisseurs ou sur la mémoire personnelle ? Si tel est le cas, vos processus actuels de gestion du cycle de vie des produits (PLM) et de la configuration ne sont pas conformes aux exigences de la loi sur la responsabilité du comté de Man (CRA).

Cet exercice vous permettra de repérer rapidement les silos de données qui perturbent votre chaîne de traçabilité. Corriger ces incohérences dès maintenant est bien moins coûteux que de s'exposer ultérieurement à des sanctions réglementaires ou à des interdictions de marché.

Perspectives d'avenir : La conformité comme sous-produit de l'ingénierie

La loi sur la cyber-résilience change la donne pour les fabricants de matériel et de logiciels. La sécurité n'est plus une simple correction après le lancement ; c'est une dimension fondamentale de la qualité et de la conformité des produits, qui doit être gérée dès la conception et jusqu'à la fin de leur cycle de vie.

En intégrant pleinement les données de conformité à l'historique produit unifié, vous faites bien plus qu'éviter les amendes réglementaires. Vous renforcez votre chaîne d'approvisionnement, réduisez les reprises d'ingénierie et proposez à vos clients des produits plus sûrs et plus fiables.

Vos données d'ingénierie sont-elles structurées pour résister à un délai de réponse aux incidents de 72 heures, ou vous appuyez-vous encore sur des feuilles de calcul déconnectées pour gérer les configurations de vos produits ?

• Auteur
• Articles récents

Équipe ChampionXperience

Responsable du contenu chez ChampionXperience

Partage d'informations, de tutoriels et d'actualités du secteur sur les technologies de CAO, de simulation, d'ingénierie et de transformation numérique.

Derniers articles de ChampionXperience l'équipe (voir tous)

• Loi sur la cyber-résilience PLM : Pourquoi la traçabilité est préférable aux nomenclatures de systèmes (SBOM) - 13 septembre 2026
• NVIDIA + Hugging Face - 11 septembre 2026
• CATIA V5 vers DELMIA Machining : Pourquoi la migration est gagnante ? – 4 septembre 2026