Période d’assistance CRA : relier la date de fin à une décision documentée

Le règlement sur la cyberrésilience impose aux fabricants de déterminer une période d’assistance pour les produits comportant des éléments numériques. Il ne s’agit pas d’un champ « EOL » rempli après coup. Cette décision détermine notamment combien de temps le traitement efficace des vulnérabilités doit se poursuivre, et sa justification doit figurer dans la documentation technique.

En règle générale, la période d’assistance est d’au moins cinq ans. Lorsqu’un produit est censé être utilisé pendant moins de cinq ans, la période d’assistance correspond à cette durée d’utilisation attendue.

Critères définis dans le CRA

Le fabricant doit notamment tenir compte :

• des attentes raisonnables des utilisateurs ;
• de la nature du produit ;
• de sa destination ;
• du droit pertinent de l’UE déterminant la durée de vie du produit.

Le CRA permet aussi de prendre en considération :

• les périodes d’assistance de produits offrant des fonctions similaires ;
• la disponibilité de l’environnement d’exploitation ;
• les périodes d’assistance de composants tiers intégrés assurant des fonctions essentielles ;
• les orientations pertinentes de la Commission et de l’ADCO.

Les critères doivent être appliqués de manière proportionnée.

Ne commencez pas par la date

Un processus fragile commence ainsi :

« Indiquons cinq ans, puisque c’est ce que prévoit le CRA. »

Un processus plus solide commence par les hypothèses :

1. Pendant combien de temps les utilisateurs peuvent-ils raisonnablement s’attendre à utiliser le produit ?
2. Pendant combien de temps les dépendances essentielles peuvent-elles bénéficier d’une assistance ?
3. Quel est le cycle de vie du matériel ou de l’environnement d’exploitation ?
4. Le produit est-il utilisé dans un environnement industriel ou autre où sa durée de vie pratique est plus longue ?
5. Quels engagements découlent des contrats et des autres textes applicables ?
6. Le processus de mise à jour de sécurité peut-il réellement être maintenu pendant la période choisie ?

N’approuvez la date de fin qu’après avoir examiné ces questions.

Preuves étayant la décision

Une fiche minimale peut comprendre :

Champ	Exemple de contenu
Produit / version	Identification unique
Date de décision	Date d’approbation de la période d’assistance
Date de fin	Au moins le mois et l’année
Durée d’utilisation attendue	Hypothèse + source
Attentes des utilisateurs	Contrats, données produit, éléments issus du marché
Dépendances essentielles	Périodes d’assistance des tiers
Environnement d’exploitation	Systèmes et plateformes nécessaires
Fondement juridique / orientations	Sources utilisées pour la décision
Approbation	Personne ou rôle responsable
Date de revue	Date de nouvelle vérification des hypothèses

Les utilisateurs ont besoin d’une date de fin d’assistance claire

L’article 13 impose que la date de fin de la période d’assistance, au moins le mois et l’année, soit indiquée clairement et de manière compréhensible au moment de l’achat, dans un emplacement facilement accessible et, lorsque cela est pertinent, sur le produit, son emballage ou sous forme numérique.

Cette exigence relie une décision interne sur le cycle de vie à la communication produit. Si la date diffère entre documentation technique, tarification, interface et contrat, le problème apparaîtra dans les relations habituelles avec les clients bien avant un audit.

La période d’assistance est un engagement opérationnel, pas seulement une date

Pendant la période d’assistance, le fabricant doit traiter les vulnérabilités efficacement conformément aux exigences du CRA. La fiche de période d’assistance doit donc être reliée aux éléments suivants :

• politique de divulgation coordonnée des vulnérabilités ;
• triage et correction des vulnérabilités ;
• versions de sécurité ;
• composants tiers ;
• communication aux utilisateurs ;
• suivi de la fin d’assistance.

Le CRA prévoit également des exigences de maintien de la disponibilité des mises à jour de sécurité publiées et de conservation de la documentation pendant des durées définies. La gestion du cycle de vie ne peut pas se réduire à un champ dans un CRM ou un catalogue produit.

Comment Pulsar gère la décision

Pulsar permet de conserver la décision, sa justification, les personnes responsables, les actions et les preuves, puis de les relier aux risques et à la documentation. Lors d’une revue ultérieure, l’équipe voit ce qui a changé depuis la décision précédente, au lieu de devoir reconstituer sa justification initiale.

Cela ne signifie pas que Pulsar décide de manière autonome de la période d’assistance appropriée. Les hypothèses et l’approbation restent de la responsabilité du fabricant.

Découvrez Pulsar GRC dans le cycle de vie d’une décision

Guides associés

• Documentation technique CRA
• SBOM et dépendances du produit
• Retour au guide CRA

Construire un calendrier à partir du produit

La décision de période d’assistance doit partir du produit, de son usage prévu et des critères applicables, plutôt que d’une date commerciale choisie isolément. Rassemblez les informations sur les fonctions, les utilisateurs et les conditions dans lesquelles le produit reste utilisé. Conservez les éléments qui expliquent la durée retenue. Une durée reprise d’un autre produit peut être simple à gérer mais ne démontre pas qu’elle convient à celui qui est examiné.

Le responsable doit distinguer la période d’assistance du produit, le maintien des versions et la disponibilité des mises à jour déjà publiées. Ces sujets sont liés sans être identiques. Une version peut demander une migration alors que le produit reste pris en charge. La méthode doit expliquer les conséquences pour les utilisateurs et les pièces qui démontrent la décision. Les obligations exactes restent à examiner dans le règlement et les conditions applicables.

Examiner les dépendances avant d’annoncer une durée

Une promesse d’assistance dépend de la capacité à maintenir les composants et les services nécessaires. Identifiez les fournisseurs importants, leurs conditions de maintenance et les informations disponibles sur la fin de support. Conservez la source et la date de ces informations. Une page commerciale actuelle peut changer ; le dossier doit montrer ce qui a été examiné au moment où l’organisation a pris son engagement.

Si une dépendance risque de cesser d’être maintenue avant la fin de la période prévue, préparez les questions à résoudre : remplacement, correction sous votre responsabilité, changement de conception ou autre mesure justifiée. Chaque option a un coût et des limites. Le fabricant doit apprécier ses responsabilités sur son produit ; l’annonce d’un fournisseur ne suffit pas à réduire automatiquement la période d’assistance promise aux utilisateurs.

Exemple de planification sans durée universelle

Dans un scénario hypothétique, une entreprise prévoit de maintenir un produit plusieurs années, tandis qu’un composant important a un calendrier plus court. L’équipe identifie le moment où une solution de remplacement doit être disponible et les essais nécessaires avant sa distribution. La date interne de préparation n’est pas un délai réglementaire inventé. Elle résulte du calendrier du produit et du temps dont l’équipe a besoin pour vérifier le changement.

Ce plan doit également examiner les clients qui ne mettent pas immédiatement leur installation à jour. Décrivez les versions prises en charge, les instructions et les limites pertinentes. Un correctif disponible ne montre pas qu’une migration a eu lieu chez chaque utilisateur. L’organisation doit savoir quelles informations elle communique et quelle preuve elle conserve de cette communication. Les choix contractuels et réglementaires demandent une appréciation dans leur contexte.

Rendre la date visible dans les documents cohérents

Le dossier technique, les informations aux utilisateurs et les documents commerciaux doivent exprimer des engagements compatibles. Si deux documents donnent des dates différentes, attribuez une revue au responsable concerné avant la publication. Une contradiction peut conduire un utilisateur à prendre une décision sur une durée qui n’est pas celle réellement prévue. Gardez la version examinée et la décision qui résout le désaccord.

Lorsqu’une information est corrigée après publication, préservez l’historique et le motif de la modification. Évaluez les conséquences sur les utilisateurs déjà concernés. Une nouvelle date dans un document ne réécrit pas automatiquement les engagements antérieurs. La personne compétente doit examiner la situation, les textes et les contrats. Le registre sert à conserver cette analyse et les actions décidées, pas à produire une date rétroactive sans justification.

Préparer les tâches récurrentes de maintien

La période d’assistance se traduit en responsabilités concrètes : recevoir les informations de sécurité, évaluer les vulnérabilités, produire les corrections et maintenir les documents pertinents. Définissez les responsables et leur continuité. Une date longue sans ressources ni processus disponible reste une déclaration. Examinez la capacité de l’équipe à réaliser le travail prévu et les dépendances qui peuvent affecter cette capacité.

Les revues doivent partir de faits : évolution des composants, changements de fournisseur, risques nouveaux et retours des utilisateurs. Gardez les décisions et les travaux qui en résultent. Il n’est pas nécessaire de recopier toute la documentation à chaque revue si les éléments inchangés restent identifiables. En revanche, une modification pertinente doit être reliée à la version du produit et à la mesure qui conserve sa prise en charge.

Contrôler la fin de période avant son arrivée

Préparez la fin de période avec suffisamment d’anticipation pour examiner les informations à fournir et les obligations qui subsistent. Identifiez les utilisateurs ou distributeurs concernés, les documents à maintenir et les versions de mises à jour pertinentes. La disponibilité des mises à jour et la conservation de la documentation ne doivent pas être supposées terminées simplement parce qu’une date de support est atteinte. Vérifiez les règles qui couvrent chacun de ces sujets.

Conservez un plan de clôture avec les propriétaires des actions et les preuves attendues. Une liste de tâches peut inclure la revue des messages, la vérification des liens de téléchargement et la sélection des documents à archiver selon les exigences applicables. Les canaux exacts et les durées de conservation doivent être déterminés par l’organisation. Cet article propose une méthode de préparation, pas un engagement contractuel commun à tous les fabricants.

Accepter le dossier sur des preuves

Une personne autorisée doit retrouver la durée annoncée, son fondement, les dépendances évaluées et la décision d’approbation. Elle doit également comprendre ce qui change d’une version à l’autre et les questions encore ouvertes. Si le dossier contient seulement une date dans un tableau, il ne permet pas d’expliquer comment l’organisation compte respecter son engagement. Complétez les éléments manquants avant de présenter une conclusion favorable.

La revue peut inclure un exercice sur une dépendance fictive qui arrive en fin de maintenance. Demandez à l’équipe de retrouver la décision de période, le responsable du changement et la preuve nécessaire pour accepter une solution. Les difficultés observées deviennent des actions concrètes. Aucune baisse de coût ni durée de résolution n’est promise par cet exercice ; il mesure la capacité de votre propre organisation à reprendre le dossier.

Le rôle limité mais utile de Pulsar GRC

Pulsar peut relier les documents de période d’assistance aux risques, fournisseurs, tâches et décisions. Il ne détermine pas seul la durée juridiquement appropriée et ne prolonge pas la maintenance d’un composant externe. Les fonctions d’IA préparent des propositions à vérifier. La décision, les ressources nécessaires et les engagements envers les utilisateurs restent sous la responsabilité des personnes autorisées.

Pour tester ce parcours, utilisez un produit fictif et quelques pièces non confidentielles. Vérifiez la possibilité de relier une dépendance, une échéance et une décision sans perdre l’historique. L’essai de quatorze jours, avec un moyen de paiement requis, doit être apprécié selon les conditions actuelles de l’offre. Le résultat recherché est une décision de période expliquée et un plan de maintien que l’équipe peut réellement suivre.

Sources

• Règlement (UE) 2024/2847 — article 13 et annexe VII
• Commission européenne — orientations CRA du 27 juillet 2026

État documentaire du guide : 2 octobre 2026. Vérifiez les instructions opérationnelles actuelles avant toute notification.

• Pulsar GRC — accès, isolation des données et export (polonais)