Votre prochaine mise à jour logicielle pourrait refaire de vous un fabricant

La modification substantielle au sens du Cyber Resilience Act, du règlement Machines, de la directive sur la responsabilité du fait des produits et du règlement sur l’IA — et pourquoi la décision se prend dans vos revues d’architecture, pas au service juridique.

La plupart des équipes d’ingénierie ne voient pas une mise à jour logicielle comme un événement réglementaire. Les exigences sont recueillies, les fonctions développées, les tests passent, les revues de cybersécurité sont validées, et la mise à jour est livrée. Rien que de très habituel.

Pourtant, au titre de quatre textes européens qui entrent aujourd’hui en application, une seule mise à jour de firmware peut légalement transformer un produit livré il y a des années en un produit neuf — et faire de celui qui a réalisé la modification son fabricant, avec tout ce que ce titre implique : une nouvelle évaluation de la conformité, les responsabilités liées au marquage CE, et un délai de responsabilité qui repart de zéro.

Le terme qui produit cet effet est la modification substantielle. Il figure dans le Cyber Resilience Act (CRA), le nouveau règlement Machines (UE) 2023/1230, la directive révisée sur la responsabilité du fait des produits (PLD) et le règlement sur l’IA (AI Act) — et chaque texte applique son propre critère.

Pourquoi c’est important maintenant

Ce ne sont pas des échéances lointaines. Deux des quatre textes s’appliquent d’ici quelques mois :

La plupart des entreprises traitent ces dates comme un projet de mise en conformité ponctuel. Le plus difficile vient ensuite : les produits sont mis à jour pendant des années, et chaque mise à jour peut rouvrir la question de savoir si le produit sur le marché est encore le produit qui a été évalué.

Ce que coûte une modification substantielle passée inaperçue

Lorsqu’un changement franchit la ligne sans que personne ne le remarque, quatre conséquences s’ensuivent :

• Une nouvelle évaluation de la conformité — analyse de risque actualisée, dossier technique, essais, et frais d’organisme notifié le cas échéant. La livraison attend que ce soit terminé.
• La perte du statut d’antériorité — un produit mis sur le marché avant l’application du CRA ou du règlement sur l’IA n’échappe à ces exigences que jusqu’à sa modification substantielle. Une seule mise à jour peut faire basculer toute une gamme de produits existants dans la conformité complète : processus de développement sécurisé, gestion des vulnérabilités, SBOM.
• Un délai de responsabilité qui redémarre — au titre de la nouvelle PLD, la période de responsabilité de dix ans redémarre lorsque le produit modifié est mis à disposition. Un produit vieux de neuf ans devient un risque neuf de dix ans, porté par celui qui a réalisé la modification.
• Amendes et mesures de marché — jusqu’à 15 millions d’euros ou 2,5 % du chiffre d’affaires mondial au titre du CRA, 15 millions d’euros ou 3 % au titre du règlement sur l’IA, auxquels s’ajoutent d’éventuels ordres de retrait ou de rappel.

Et cela vaut pour bien plus que le fabricant d’origine : au titre des quatre textes, un intégrateur, un distributeur ou un importateur qui modifie substantiellement un produit est traité comme son fabricant.

L’illusion de continuité

Pourquoi est-ce si facile à manquer ? Parce que le logiciel crée une illusion de continuité. Le client voit le même boîtier, le même nom de produit, le même matériel — seul un numéro de version change.

Du point de vue système, la situation peut être radicalement différente. Une machine jusque-là isolée dialogue désormais avec un service cloud. Un contrôleur qui traitait tout localement dépend maintenant d’une infrastructure externe. Un algorithme déterministe intègre désormais une aide à la décision assistée par IA. Le produit visible est identique ; le système qui a été évalué ne l’est plus.

La décision se prend en ingénierie, pas au juridique

Quand on évoque la « modification substantielle », on imagine des spécialistes de la réglementation. En pratique, les choix décisifs se font des mois plus tôt, dans les revues d’architecture, lorsque les ingénieurs décident de :

• ajouter une connectivité ou une maintenance à distance,
• exposer une nouvelle API ou ouvrir un port réseau,
• déporter des traitements vers un service cloud,
• toucher à une fonction de sécurité ou à ses paramètres,
• introduire une fonction assistée par IA.

Aucune de ces décisions n’est juridique. Chacune peut invalider les hypothèses qui sous-tendaient l’évaluation initiale de sécurité, de cybersécurité ou de conformité. La même fonction, conçue différemment, peut réussir tous les critères — ou en échouer trois sur quatre. Un diagnostic en lecture seule sur une voie isolée n’est pas la même évolution de produit qu’un accès en écriture aux paramètres de sécurité.

La bonne nouvelle : « non prévu » est le fil conducteur des quatre critères. Un changement qui a été planifié, évalué et documenté dans l’évaluation de conformité initiale n’est généralement pas substantiel. Une feuille de route produit inscrite dès la première analyse de risque est un véritable levier de coût.

Le contrôle de livraison que vous pouvez mettre en place dès la semaine prochaine

Une revue structurée de l’impact des changements prend quelques heures d’ingénierie par livraison — à comparer au coût d’une recertification, d’un rappel ou d’une période de responsabilité qui redémarre. Elle commence par des questions comme celles-ci :

• Le changement ajoute-t-il ou modifie-t-il une fonction, une interface ou l’usage prévu ?
• Était-il prévu et documenté dans l’analyse de risque ou l’évaluation de conformité initiale ?
• Modifie-t-il le risque de cybersécurité : nouvelle connectivité, nouvelles données, nouvelle surface d’attaque ?

Ce sont trois des huit questions de contrôle de livraison que nous détaillons dans notre livre blanc, avec les quatre critères juridiques comparés article par article, les schémas d’architecture qui les déclenchent le plus souvent (connectivité, migration vers le cloud, intégration d’IA), un exemple traité de variateur et une checklist pour l’architecte.

Foire aux questions

Un correctif de sécurité est-il une modification substantielle au sens du CRA ? En règle générale, non. Les orientations de la Commission européenne confirment que les mises à jour dont l’objet est de réduire le risque, sans changer la destination ni ajouter de nouveaux risques, ne sont pas des modifications substantielles.

Une modification substantielle affecte-t-elle un produit vendu avant l’application du CRA ? Oui. Un produit mis sur le marché avant le 11 décembre 2027 n’échappe aux exigences du CRA que jusqu’à sa modification substantielle. Ensuite, le produit modifié doit s’y conformer.

Qui est responsable lorsqu’un intégrateur modifie un produit ? Au titre de la PLD, la partie qui modifie substantiellement un produit en dehors du contrôle du fabricant d’origine est responsable en tant que fabricant du produit modifié, et la période de responsabilité de dix ans redémarre à compter de cette modification.

Un changement purement logiciel peut-il être une modification substantielle au sens du règlement Machines ? Oui. Le règlement précise explicitement que la modification peut être physique ou numérique, y compris une modification d’un logiciel relatif à la sécurité.

À propos d’ISIT-Neperis. ISIT-Neperis intervient à la rencontre de la sécurité fonctionnelle, de la cybersécurité et de la réglementation : évaluations d’impact des changements, formations CRA et sécurité fonctionnelle, et piles de communication de sécurité certifiées livrées avec leurs preuves de certification. Si une livraison de votre feuille de route soulève l’une de ces questions, parlez-nous-en avant que l’architecture ne soit figée.

Cet article fournit des informations générales et ne constitue pas un conseil juridique. Vérifiez les textes officiels et votre propre analyse de risque avant toute décision.