Support CRA : durée, correctifs et fin d’assistance

Un produit vendu avec cinq ans de support n’est pas automatiquement conforme au CRA. La période d’assistance doit refléter sa durée d’utilisation prévue ; cinq ans constituent un plancher assorti d’une exception, pas un plafond. Le fabricant doit aussi distinguer la création de nouveaux correctifs, la disponibilité des correctifs déjà diffusés et la conservation du dossier technique.

Fixer et justifier la période d’assistance

L’Art. 13(8) du règlement (UE) 2024/2847 impose une période reflétant la durée pendant laquelle le produit est censé pouvoir être utilisé. Le fabricant tient compte des attentes raisonnables des utilisateurs, de la nature du produit, de son usage prévu et du droit de l’Union applicable.

Cette période est d’au moins cinq ans. Si la durée d’utilisation prévue est inférieure à cinq ans, la période correspond à cette durée. À l’autre extrémité, un usage prévisible plus long ne se règle pas par la simple mention « support cinq ans » dans les conditions commerciales.

Le fabricant documente les informations retenues. L’environnement opérationnel, les composants tiers essentiels, les produits comparables et les orientations pertinentes peuvent contribuer à l’analyse. Une dépendance arrivant en fin de maintenance constitue un problème à traiter, pas une justification automatique pour écourter le support.

Trois durées à suivre séparément

Ces obligations n’imposent pas indistinctement dix ans de nouveaux correctifs pour tous les produits. Associez les échéances à chaque référence et version dans votre documentation technique CRA.

Gratuité et séparation des mises à jour

L’annexe I, partie II, point 8 prévoit la diffusion sans retard des correctifs disponibles, gratuitement, sauf accord contraire entre fabricant et utilisateur professionnel concernant un produit sur mesure. Cette exception ne permet pas de rendre payants tous les correctifs d’une gamme simplement parce que les clients sont professionnels.

Le point 2 demande de séparer les nouvelles mises à jour de sécurité des mises à jour fonctionnelles lorsque cela est techniquement possible. Il ne pose pas une séparation absolue dans toutes les architectures. Le point 7 exige une distribution sécurisée et, le cas échéant, l’automatisation.

L’annexe I, partie I, point 2(c) prévoit, le cas échéant, des mises à jour automatiques activées par défaut, faciles à désactiver, ainsi qu’une information et une possibilité de report temporaire. Intégrez ces réglages à la conception et aux instructions, pas seulement au contrat.

Peut-on ne corriger que la dernière version ?

L’Art. 13(10) prévoit cette possibilité pour les versions ultérieures substantiellement modifiées d’un logiciel, sous conditions : les utilisateurs des versions antérieures doivent accéder gratuitement aux dernières versions et ne pas supporter de coûts supplémentaires d’adaptation de leur environnement matériel ou logiciel.

Une migration imposant l’achat d’un nouveau matériel ne remplit donc pas cette condition par le seul fait que le téléchargement est gratuit. Documentez les prérequis, la compatibilité et les coûts d’adaptation avant de fermer une branche maintenue. Le programme de gestion des vulnérabilités doit refléter ce choix.

Informer au moment de l’achat et à la fin du support

L’Art. 13(19) demande d’indiquer clairement la fin de l’assistance, avec au moins le mois et l’année, au moment de l’achat. Lorsque la nature du produit le permet techniquement, une notification informe l’utilisateur que cette fin est atteinte. Le texte ne fixe pas ici un préavis universel chiffré.

Évitez aussi de promettre un « état final sans aucune vulnérabilité » : cela ne remplace pas l’obligation de traiter les vulnérabilités pendant l’assistance et ne garantit pas l’absence de découvertes futures. L’analyse d’un signalement CRA doit rester distincte de la politique commerciale de support.

Préparer la décision de fin de support

Réunissez cinq preuves : justification de la durée, information fournie à l’achat, inventaire des versions et composants, organisation des corrections, maintien de l’accès aux correctifs et documents. Pour les composants tiers, liez ce dossier au SBOM.

Ces exigences relèvent de l’application générale du 11 décembre 2027, sous réserve des transitions. Le calendrier CRA permet de les distinguer du signalement déjà applicable en septembre 2026.

Construire la justification avant de rédiger la promesse

Réunissez le responsable produit, la maintenance et les personnes qui connaissent les conditions d’utilisation. Le point de départ est l’usage attendu du produit, pas la durée d’un abonnement commercial choisi par défaut. Un équipement durable, un logiciel dépendant d’un environnement précis et un produit destiné à un usage limité appellent des analyses différentes.

Une note de justification peut rapprocher les éléments suivants :

Cette note est une proposition de méthode, pas un formulaire réglementaire. Les hypothèses doivent être identifiables. Si une dépendance n’est couverte que pendant une partie de la période envisagée, décrivez la solution retenue et les inconnues qui restent à résoudre. Un engagement d’un fournisseur peut contribuer au dossier ; il ne suffit pas à expliquer comment votre propre produit restera pris en charge.

Faites valider la promesse publiée après cette analyse. Comparez les mentions du devis, de la boutique, de la documentation et du produit. Une durée exprimée dans un contrat et une date affichée à l’achat peuvent se contredire. La personne qui corrige les supports doit disposer de la décision et de son périmètre exact.

Exemple fictif : calculer trois échéances différentes

Dans cet exemple entièrement fictif, un fabricant met un produit sur le marché le 1er mars 2028 et retient, après analyse supposée justifiée, une assistance jusqu’au 1er mars 2036. Une mise à jour de sécurité est diffusée le 1er février 2035. Aucun de ces choix ne constitue une durée recommandée pour une autre gamme.

L’organisation doit distinguer trois échéances. La gestion des vulnérabilités se poursuit pendant la période d’assistance retenue. La mise à jour du 1er février 2035 doit rester disponible au moins jusqu’au 1er février 2045, puisque les dix ans après son émission dépassent ici le reste de l’assistance. La documentation technique et la déclaration restent disponibles au moins jusqu’au 1er mars 2038, les dix ans après la mise sur le marché étant, dans cette hypothèse, plus longs que l’assistance.

Ces calculs montrent pourquoi un bouton unique « fermer le produit » est insuffisant. Arrêter la prise en charge de nouvelles vulnérabilités à l’échéance applicable, retirer un fichier de téléchargement et supprimer des preuves sont des décisions distinctes. Pour chaque correctif, conservez sa date d’émission et son périmètre ; une date unique au niveau de la gamme peut masquer des obligations encore en cours.

Vérifier une migration avant de fermer une branche

La possibilité offerte par l’Art. 13(10) demande une analyse concrète. Identifiez les versions antérieures concernées, les environnements dans lesquels elles sont utilisées et les conditions d’accès à la nouvelle version. La mention « mise à niveau gratuite » ne renseigne pas sur les adaptations nécessaires.

Préparez un dossier de compatibilité indiquant les prérequis matériels, logiciels et les fonctions dont dépend l’utilisateur. Si la migration impose un achat ou une modification coûteuse de cet environnement, examinez la condition légale avant de considérer que la correction de la seule dernière version suffit. Ne confondez pas l’accès au fichier avec la possibilité de l’utiliser dans les conditions prévues par le texte.

Une vérification proposée peut demander à l’équipe de décrire le parcours de migration et les difficultés connues. Les conclusions doivent distinguer ce qui a été établi, ce qui reste à examiner et les utilisateurs éventuellement concernés par un obstacle. Aucun essai de migration n’est présenté ici comme ayant été réalisé.

Préparer la fin d’assistance sans perdre la traçabilité

Avant l’échéance, vérifiez que la date annoncée peut être retrouvée pour les références effectivement vendues. Répertoriez les correctifs encore à rendre disponibles, les documents à conserver et les personnes responsables de ces accès. La fermeture d’une équipe ou d’un espace commercial ne doit pas rendre ces obligations orphelines.

Pour les vulnérabilités connues pendant l’assistance, conservez le suivi de leur traitement. Une échéance proche ne transforme pas une vulnérabilité identifiée en sujet extérieur au périmètre. Le dossier doit montrer les décisions, les corrections diffusées et les informations remises aux utilisateurs dans les conditions applicables.

Enfin, contrôlez l’accessibilité réelle des ressources maintenues. Un fichier conservé dans une archive interne n’est pas nécessairement disponible pour l’utilisateur qui en a besoin. Vérifiez le chemin de téléchargement, l’identification des versions et les instructions associées, tout en maintenant une distribution sécurisée. Cette vérification est une action à organiser ; elle ne permet pas d’affirmer sans preuve que tous les utilisateurs ont installé le correctif.

Ce qu’il faut retenir

• Cinq ans ne sont ni un plafond général ni un minimum sans exception.
• La disponibilité d’un ancien correctif suit une durée propre.
• La gratuité comporte une exception précise pour certains produits professionnels sur mesure.
• La séparation des mises à jour dépend de sa possibilité technique.

FAQ

Peut-on choisir trois ans de support ?

Il faut justifier que la durée d’utilisation prévue du produit est inférieure à cinq ans. Une décision commerciale non étayée ne suffit pas à satisfaire l’Art. 13(8).

Tous les contrats B2B peuvent-ils prévoir des correctifs payants ?

Non. L’exception du point 8 vise un accord avec un utilisateur professionnel concernant un produit sur mesure. Elle ne s’étend pas automatiquement aux produits standard vendus aux entreprises.

La fin d’assistance autorise-t-elle à supprimer les téléchargements ?

Pas automatiquement. L’Art. 13(9) impose une disponibilité propre des mises à jour déjà diffusées, qui peut se poursuivre après la fin de l’assistance.

Recevez nos analyses conformité dans la newsletter.

Thiébaut Devergranne, docteur en droit et fondateur de donneespersonnelles.fr, travaille depuis plus de vingt ans sur le droit des technologies et la conformité numérique.