L'article 69(2) du Cyber Resilience Act, règlement (UE) 2024/2847, dispose que les produits comportant des éléments numériques mis sur le marché avant le 11 décembre 2027 « ne sont soumis aux exigences du présent règlement que si, à compter de cette date, ils font l'objet de modifications substantielles ». L'obligation de notification de l'article 14 leur est applicable quoi qu'il en soit, depuis le 11 septembre 2026. Tout le reste, les exigences essentielles de l'annexe I, l'évaluation de la conformité, la documentation technique, le marquage CE, attend la première modification substantielle. Pour un éditeur de logiciels dont le produit est déjà sur le marché, « qu'est-ce qu'une modification substantielle » est donc la question qui décide si, et quand, le règlement atteint ce produit. Et pour un produit mis sur le marché après cette date, elle décide si une version nécessite une nouvelle évaluation de la conformité.

Le règlement définit le terme à l'article 3(30) et l'explique au considérant 39, et les orientations de la Commission du 27 juillet 2026, C(2026) 5252, section 4.3, paragraphes 103 à 113, l'appliquent aux mises à jour logicielles, avec onze exemples traités. Les sections 4.4.2 et 5 disent ce qui s'ensuit. Cet article, ce sont ces paragraphes, lus pour une équipe qui livre chaque semaine.

Le critère est l'évaluation des risques, pas la taille du changement

Le paragraphe 104 reprend le considérant 39 : un produit est substantiellement modifié « lorsqu'un changement altère le niveau de risque en matière de cybersécurité, et lorsque ce risque altéré ou supplémentaire n'a pas été pris en compte par le fabricant dans son évaluation des risques et, par conséquent, dans sa mise en œuvre des exigences essentielles ». Le fabricant « devrait donc évaluer, au cas par cas, si une mise à jour logicielle introduit des risques de cybersécurité nouveaux ou accrus, et si ces risques étaient déjà traités dans son évaluation des risques ».

Deux conséquences en découlent, et les orientations tirent les deux. D'abord, un changement de la destination du produit en est probablement une : le paragraphe 105 indique que lorsque de nouvelles fonctionnalités « entraînent un changement de la destination du produit dans son ensemble, il est probable que le fabricant n'a pas pris ces changements en compte dans son évaluation des risques », et l'exemple 40 est un tableau de bord de supervision qui acquiert la capacité de commander les machines qu'il observe. Ensuite, la taille n'est pas le critère. Paragraphe 107 : « l'évaluation de la modification substantielle ne devrait donc pas reposer sur l'ampleur ou la complexité du changement, mais sur son impact négatif potentiel sur le profil de risque en matière de cybersécurité ». L'exemple 44 est celui que toute équipe produit devrait lire : une fonction « se souvenir de moi » qui stocke localement des jetons d'authentification « introduit de nouveaux risques liés au vol de jetons, à l'accès non autorisé et au détournement de session qui n'avaient pas été pris en compte dans l'évaluation des risques », et l'application « a été substantiellement modifiée ». L'exemple 45 est une fonction de diagnostic qui exporte des journaux détaillés, mineure en apparence, qui stocke des données opérationnelles sensibles en clair : substantiellement modifiée.

L'autre face est le paragraphe 106. Lorsque le fabricant « a anticipé le développement de ces fonctionnalités, a déjà décrit et évalué les risques associés, et a mis en œuvre des mesures d'atténuation appropriées », la mise à jour « ne devrait donc pas être considérée » comme une modification substantielle. L'exemple 42 est une application de messagerie dont l'évaluation des risques initiale couvrait l'introduction ultérieure de la messagerie de groupe, « y compris par exemple la complexité accrue du routage des messages » ; lorsque la discussion de groupe est livrée avec les contrôles d'administration et de modération prévus, rien n'a été substantiellement modifié. L'exemple 43 est un système de supervision livré avec des boucles de commande présentes mais désactivées et évaluées ; les activer n'est pas une modification substantielle.

C'est tout le mécanisme. Une évaluation des risques qui nomme la feuille de route absorbe la feuille de route. Une évaluation des risques écrite une fois, pour le produit tel qu'il était, transforme chaque fonctionnalité significative en modification substantielle.

Les mises à jour de sécurité : en général non, avec deux exceptions

Paragraphe 108, à nouveau d'après le considérant 39 : « les mises à jour de sécurité ne doivent en général pas être considérées comme des modifications substantielles, car leur objet principal est de réduire le niveau de risque en matière de cybersécurité ». Cela vaut « même lorsque cette mise à jour peut introduire des changements techniques importants », et couvre les fonctionnalités « modifiées ou restreintes uniquement en vue d'atténuer des vulnérabilités identifiées ». L'exemple 46 est la correction d'une erreur de validation d'entrée ou d'une vérification de jeton de session. L'exemple 47 est le durcissement : resserrer les règles de pare-feu, désactiver des ports, changer les politiques de mot de passe par défaut, rendre obligatoire l'authentification multifacteur là où elle existait déjà. L'exemple 48 est le remplacement d'un algorithme déprécié par un plus fort déjà pris en charge par la conception.

Le paragraphe 109 donne les exceptions : une mise à jour de sécurité qui modifie la destination au-delà de ce qui était prévu, ou « modifie sensiblement les limites ou la structure de dépendances du produit d'une manière non prévue dans l'évaluation des risques, par exemple en modifiant sensiblement les flux de données ou en ajoutant de nouvelles interfaces accessibles de l'extérieur ». L'exemple 49 remplace le chiffrement local des fichiers par un service de chiffrement à distance exploité par le fabricant : le produit fait désormais autre chose, il est donc substantiellement modifié malgré le motif de sécurité. L'exemple 50 remplace un cycle de vie des clés géré en interne par un service de gestion des clés tiers, ajoutant « de nouvelles interfaces externes et une dépendance à des services tiers non prise en compte dans l'évaluation des risques » : substantiellement modifié.

Les quatre questions à poser à chaque version

Le paragraphe 110 énumère ce qu'un fabricant « peut considérer », et c'est assez court pour figurer dans un modèle de pull request. La mise à jour :

a. introduit-elle de nouveaux vecteurs de menace, tels que des interfaces, des canaux de communication, des environnements d'exécution ou des dépendances externes supplémentaires par lesquels des menaces pourraient se matérialiser ; b. permet-elle de nouveaux scénarios d'attaque, y compris par exemple de nouvelles façons dont un accès non autorisé, une manipulation, une interférence ou un usage abusif du produit comportant des éléments numériques, ou des données qu'il traite, pourraient plausiblement se produire ; c. modifie-t-elle la probabilité de scénarios d'attaque précédemment identifiés, par exemple en réduisant l'effort ou l'expertise nécessaires pour les exploiter, en augmentant l'exposition à des acteurs non fiables ou en affaiblissant les protections existantes ; d. modifie-t-elle l'impact potentiel de scénarios d'attaque précédemment identifiés, y compris par exemple l'étendue des données ou fonctions affectées, la gravité des conséquences opérationnelles, de sécurité ou économiques, ou la capacité à détecter, contenir ou se remettre d'un incident.

Paragraphe 111 : quatre fois non, « à condition que les hypothèses et les mesures d'atténuation sur lesquelles repose l'évaluation des risques restent valables et efficaces », signifie qu'« il est donc probable que la mise à jour ne constitue pas » une modification substantielle. Paragraphe 112 : tout oui signifie que « le fabricant devrait réévaluer les risques de cybersécurité » et « déterminer si les exigences essentielles continuent d'être satisfaites ». Le paragraphe 113 ajoute l'obligation qui ne dépend pas de la réponse : « que les mises à jour logicielles constituent ou non des modifications substantielles, les fabricants sont tenus de maintenir l'évaluation des risques et la documentation technique exactes, complètes et continuellement à jour, conformément aux articles 13(7) et 31(2) ».

Ce que déclenche la première modification substantielle

La section 4.4.2 concerne le fabricant d'origine, ce qui est le cas courant en logiciel. Paragraphe 122 : le fabricant « reste le fabricant », mais « le produit comportant des éléments numériques substantiellement modifié doit être considéré comme nouvellement mis sur le marché ». Le paragraphe 123 limite le travail : suivant la section 2.1 du Guide bleu, le fabricant « peut réutiliser la documentation et les essais existants pour les aspects du produit comportant des éléments numériques qui ne sont pas touchés par la modification substantielle », l'évaluation de la conformité « devrait se concentrer sur les parties substantiellement modifiées », et un organisme notifié, lorsqu'il intervient, « devrait concentrer son évaluation sur les parties substantiellement modifiées ».

Pour un logiciel déjà sur le marché avant le 11 décembre 2027, le paragraphe 124 est la phrase à retenir. Une modification substantielle par le fabricant d'origine « n'oblige pas, en soi, le fabricant à mettre l'ensemble du produit comportant des éléments numériques mis sur le marché avant cette date en pleine conformité avec le CRA, sauf si la modification affecte négativement la cybersécurité du produit comportant des éléments numériques dans son ensemble. Lorsque la modification n'affecte pas la cybersécurité du produit comportant des éléments numériques dans son ensemble, les obligations du fabricant d'origine relatives à la modification devraient se limiter aux parties substantiellement modifiées. » Ainsi, la première fonction « se souvenir de moi » après décembre 2027 place le parcours de connexion, et non tout le produit existant, sous l'annexe I ; une réécriture qui change les limites du produit l'y place en entier.

La section 5 ajoute la période d'assistance. Paragraphe 128 : « chaque version substantiellement modifiée d'un produit logiciel comportant des éléments numériques mise sur le marché doit avoir une période d'assistance déclarée conforme à l'article 13(8) », d'au moins cinq ans sauf si la durée d'utilisation prévue est manifestement plus courte, et lorsque la modification ne change pas les facteurs qui ont déterminé la durée d'utilisation prévue d'origine, « la période d'assistance d'origine n'est pas affectée ». Le paragraphe 131, pour les produits livrés à intervalles rapprochés : le fabricant doit déclarer une période d'assistance pour chaque version substantiellement modifiée, et peut s'appuyer sur l'article 13(10) pour cesser de remédier aux vulnérabilités des versions antérieures « dès que les utilisateurs peuvent passer à une version ultérieure gratuitement et sans encourir de coûts supplémentaires », ce que le paragraphe 130 lit comme excluant « les achats obligatoires de nouveau matériel, le remplacement d'infrastructure ou des changements fondamentaux de l'environnement d'exploitation » mais incluant l'effort normal de mise à niveau. L'article sur la période d'assistance couvre le reste de l'article 13(8).

Ce que cela signifie pour une équipe qui livre chaque semaine

Trois pratiques découlent de ces paragraphes, aucune n'étant de l'ingénierie nouvelle.

Écrivez la feuille de route dans l'évaluation des risques. Le paragraphe 106 et les exemples 42 et 43 récompensent une évaluation des risques qui nomme les fonctionnalités que vous comptez livrer et les évalue avant qu'elles existent. C'est moins coûteux qu'une nouvelle évaluation de la conformité par fonctionnalité, et c'est la différence entre l'exemple 42 et l'exemple 44. L'évaluation des risques de l'article 13 est l'endroit où la mettre.

Répondez au paragraphe 110 dans chaque version. Quatre questions, quatre réponses, une phrase chacune, dans le dossier de version. Lorsque les quatre sont non, le dossier dit pourquoi l'évaluation existante tient toujours. Lorsqu'une est oui, la version attend la réévaluation qu'exige le paragraphe 112, et l'évaluation des risques et la documentation technique sont mises à jour au titre du paragraphe 113, ce qui est dû de toute façon.

Tranchez la question des produits existants une fois pour toutes. Pour chaque produit sur le marché avant le 11 décembre 2027, consignez la version à cette date, pour que la première modification substantielle qui suit soit identifiable, et consignez pour chaque version ultérieure si elle en était une et, au titre du paragraphe 124, si elle a touché la sécurité du produit dans son ensemble ou seulement une partie.

StandardOS tient la documentation technique CRA et l'évaluation des risques comme des enregistrements vivants plutôt que comme des documents, de sorte qu'une version peut être rattachée aux quatre réponses et à l'évaluation sur laquelle elle repose. Que le produit soit dans le champ d'application vient d'abord.

Sources

  • Règlement (UE) 2024/2847, article 3(30), article 13(7), (8) et (10), article 31(2), articles 21 et 22, article 69(2), considérants 39 à 42 et 60.
  • Commission européenne, orientations de la Commission sur l'application du règlement (UE) 2024/2847, C(2026) 5252 final du 27 juillet 2026, annexe, section 4.3 (paragraphes 103 à 113, exemples 40 à 50), section 4.4 (paragraphes 114 à 124), section 5 (paragraphes 125 à 131).
  • Commission européenne, le Guide bleu relatif à la mise en œuvre de la réglementation de l'UE sur les produits, section 2.1, tel que les orientations le citent.

Ceci n'est pas un avis juridique. Les onze exemples tiennent en deux pages et sont plus proches de la réalité d'une équipe produit que tout le reste des orientations ; lisez-les avec vos dix dernières versions à côté.