Planification de la Période de Support CRA : 5 Ans de Mises à Jour de Sécurité (Et Ce Que Cela Signifie Vraiment)

Cinq ans. C'est le minimum pendant lequel vous devez fournir des mises à jour de sécurité pour vos produits en vertu du CRA. Pour de nombreux fabricants, cela représente un changement fondamental dans leur façon de penser le cycle de vie des produits et les coûts de support.

Ce guide couvre ce que signifie réellement l'exigence de période de support, comment s'y préparer et comment gérer l'inévitable transition de fin de support.

Ce Que le CRA Exige Réellement

L'Article 13 et l'Annexe I établissent les obligations de période de support :

Durée Minimale

5 ans à partir du moment où le produit est mis sur le marché de l'UE, OU la durée de vie attendue du produit , selon la plus courte.

"Durée de vie attendue du produit" est déterminée par :

• Les attentes raisonnables des clients basées sur la nature du produit
• Comment des produits similaires sont généralement utilisés
• Ce que vous communiquez sur le produit

Pour la plupart des logiciels et produits IoT, 5 ans est le minimum pratique.

Ce Que Vous Devez Fournir

Pendant la période de support, vous devez :

1. Corriger les vulnérabilités sans délai

   • Fournir des correctifs de sécurité pour les vulnérabilités connues
   • Prioriser selon la sévérité
   • Pas d'attente de la "prochaine version majeure"

2. Livrer les mises à jour de manière sécurisée

   • Mises à jour automatiques lorsque techniquement possible
   • Distribution sécurisée (signée, vérifiée)
   • Capacité de rollback si les mises à jour échouent

3. Notifier les clients

   • Informer des mises à jour de sécurité disponibles
   • Fournir des instructions d'installation claires
   • Communiquer les informations pertinentes pour la sécurité

4. Fournir les mises à jour gratuitement

   • Pas de paiement pour les correctifs de sécurité
   • Les mises à jour de fonctionnalités peuvent être facturées séparément

Quand L'Horloge Démarre-t-elle ?

La période de support commence quand le produit est "mis sur le marché" , c'est-à-dire quand vous le rendez disponible pour la première fois dans l'UE.

Pas quand :

• Le client l'achète
• Le client l'active
• Une unité spécifique est expédiée

Cela crée un risque d'inventaire : Si votre produit reste en distribution pendant 18 mois avant la vente, le support se termine toujours 5 ans après la mise sur le marché initiale.

Exemple de Chronologie

Jan 2028: Produit v1.0 mis sur le marché UE
          → La période de support commence
          → Doit fournir des mises à jour jusqu'en Jan 2033

Juin 2029: Client achète v1.0 chez un distributeur
           → Client a 3,5 ans de support restant

Jan 2033: Période de support terminée
          → Plus d'obligation de corriger v1.0
          → Client a 18 mois de produit non supporté

Bonne pratique : Suivez les dates de mise sur le marché par version de produit, pas par unité.

Exigences de Livraison des Mises à Jour

Mises à Jour Automatiques (Préférées)

Lorsque techniquement faisable et approprié, le CRA attend des mises à jour de sécurité automatiques :

EXIGENCES MISES À JOUR AUTOMATIQUES :

Technique :
- Canal de téléchargement sécurisé (TLS, paquets signés)
- Vérification d'intégrité avant installation
- Capacité de rollback si mise à jour échoue
- Gestion gracieuse des problèmes de connectivité

Contrôle Utilisateur :
- L'utilisateur doit pouvoir refuser (avec avertissement clair)
- L'utilisateur doit pouvoir reporter (avec limites raisonnables)
- Les mises à jour critiques peuvent outrepasser le report pour la sécurité
- Le statut des mises à jour doit être visible pour l'utilisateur

Notification :
- Informer l'utilisateur quand des mises à jour sont disponibles
- Expliquer ce que la mise à jour corrige
- Fournir des instructions d'installation si manuel

Mises à Jour Manuelles (Quand L'Automatique N'est Pas Possible)

Certains produits ne peuvent pas se mettre à jour automatiquement : systèmes isolés, équipements industriels, appareils embarqués sans connectivité.

Pour ceux-ci :

• Fournir des paquets de mise à jour téléchargeables
• Versionnement clair et changelog
• Documentation d'installation
• Méthode de vérification (checksums, signatures)
• Notification via canaux disponibles (email, portail web, avis physique)

Signature des Mises à Jour

Toutes les mises à jour de sécurité doivent être signées cryptographiquement :

EXIGENCES SIGNATURE MISES À JOUR :

Signature de Code :
- Signer tous les paquets de mise à jour
- Utiliser une clé de signature dédiée (protégée par HSM)
- Inclure la vérification de signature dans le processus de mise à jour
- Publier la clé publique pour vérification

Métadonnées :
- Numéro de version
- Date de publication
- Référence changelog/avis
- Version de base minimale compatible
- Horodatage de signature

Réponse aux Vulnérabilités Pendant la Période de Support

La période de support ne consiste pas seulement à avoir des mises à jour disponibles , c'est répondre aux vulnérabilités au fur et à mesure de leur découverte.

Attentes de Réponse

Ce ne sont pas des délais mandatés par le CRA, mais ils reflètent les attentes de l'industrie et ce que les régulateurs considéreront comme "sans délai".

Suivi des Vulnérabilités

Vous avez besoin d'un processus pour :

1. Réception des découvertes

   • Politique CVD et point de contact
   • Pipeline de découverte interne
   • Surveillance des dépendances

2. Évaluation

   • La vulnérabilité affecte-t-elle notre produit ?
   • Quelles versions sont affectées ?
   • Quelle est la sévérité dans notre contexte ?

3. Remédiation

   • Développer le correctif
   • Tester le correctif
   • Publier le correctif

4. Communication

   • Notifier les clients
   • Publier un avis (si approprié)
   • Signaler à ENISA (si activement exploitée)

Vulnérabilités des Dépendances

Votre produit inclut des composants tiers. Quand ils ont des vulnérabilités :

• Dépendances directes : Vous devez évaluer l'impact et mettre à jour si affecté
• Dépendances transitives : Même obligation, plus difficile à suivre
• Vulnérabilités OS/plateforme : Peuvent nécessiter une mise à jour ou communication d'atténuation

Le SBOM est essentiel : Vous ne pouvez pas suivre ce que vous ne connaissez pas.

Modélisation des Coûts pour la Période de Support

De nombreux fabricants sous-estiment les coûts de support. Voici un cadre :

Coûts Fixes (Par Ligne de Produit)

Coûts Variables (Par Année de Support)

Exemple de Modèle de Coût

MODÈLE DE COÛT PÉRIODE DE SUPPORT

Produit: Smart Home Hub v2.0
Période de Support: 5 ans (Jan 2028 - Jan 2033)
Unités Estimées: 50 000

COÛTS FIXES (une fois) :
- Configuration pipeline mise à jour : 15 000 €
- Infrastructure de signature :        5 000 €
- Système de notification :           10 000 €
- Modèles de documentation :           5 000 €
SOUS-TOTAL :                          35 000 €

COÛTS ANNUELS :
- Ingénieur sécurité (0,2 ETP) : 30 000 €/an
- Surveillance dépendances :      2 000 €/an
- Infrastructure de test :        5 000 €/an
- Delta support client :          3 000 €/an
SOUS-TOTAL :                     40 000 €/an × 5 = 200 000 €

RÉSERVE INCIDENTS (5 ans) :
- Vulnérabilités critiques (est. 2) : 20 000 €
- Correctifs réguliers (est. 15) :    30 000 €
SOUS-TOTAL :                          50 000 €

COÛT TOTAL SUPPORT 5 ANS :           285 000 €
COÛT SUPPORT PAR UNITÉ :                 5,70 €

Si vente à 99 €/unité :
Support = 5,8% du chiffre d'affaires

Point clé : Le coût de support par unité diminue avec le volume. Les produits à faible volume ont une charge de support proportionnellement plus élevée.

Planification de Fin de Support

La période de support se termine. Et ensuite ?

Avant la Fin de Support

12 mois avant :

• Annoncer la date de fin de support
• Communiquer à tous les utilisateurs enregistrés
• Publier sur les pages produit et documentation
• Proposer des chemins de mise à niveau/remplacement

6 mois avant :

• Communications de rappel
• Dernières mises à jour de fonctionnalités (le cas échéant)
• Gel de documentation (capturer l'état actuel)
• Préparer la mise à jour de sécurité finale

À la fin de support :

• Émettre la mise à jour de sécurité finale avec tous les correctifs connus
• Publier l'avis de fin de support
• Mettre à jour la documentation produit pour refléter le statut
• Rediriger les canaux de support vers les alternatives

Modèle de Communication Client

AVIS DE FIN DE SUPPORT

Produit : [Nom du Produit v1.0]
Date de Fin de Support : [Date]

Ce que cela signifie :
- Les mises à jour de sécurité ne seront plus fournies après [Date]
- Le support technique pour cette version prendra fin
- Le produit continuera à fonctionner mais pourra devenir vulnérable

Ce que vous devez faire :
- Option 1 : Mise à niveau vers [Nom du Produit v2.0] - [lien]
- Option 2 : Remplacement par [Produit Alternatif] - [lien]
- Option 3 : Continuer l'utilisation à vos risques (non recommandé)

Chronologie :
- [Date - 6 mois] : Dernière mise à jour de fonctionnalités
- [Date - 1 mois] : Dernière mise à jour de sécurité
- [Date] : Fin de support

Questions ? Contactez [canal de support]

Après la Fin de Support

Vos obligations après la période de support :

• Conserver la documentation technique pendant 10 ans au total (depuis la dernière unité mise sur le marché)
• Répondre aux demandes de surveillance du marché
• Aucune obligation de corriger les nouvelles vulnérabilités

Bonnes pratiques (volontaires) :

• Maintenir un contact sécurité pour la divulgation responsable
• Considérer la publication des vulnérabilités connues mais non corrigées
• Garder l'infrastructure de mise à jour disponible pour les urgences critiques

Support Multi-Versions

La plupart des fabricants ont plusieurs versions de produits sur le marché simultanément.

Périodes de Support Échelonnées

CHRONOLOGIE SUPPORT VERSIONS

v1.0: Jan 2028 ─────────────────────────── Jan 2033
v1.1:      Juil 2028 ─────────────────────────── Juil 2033
v2.0:           Jan 2029 ─────────────────────────── Jan 2034

Support superposé: Jan 2029 - Jan 2033 = 4 ans de double support

Exemple de Matrice de Support

MATRICE DE SUPPORT PRODUIT (au Jan 2030)

Version   Publiée     Fin Support    Statut
────────────────────────────────────────────
v1.0      Jan 2028    Jan 2033       Maintenance
v1.1      Juil 2028   Juil 2033      Maintenance
v2.0      Jan 2029    Jan 2034       Actuelle
v2.1      Jan 2030    Jan 2035       Actuelle

Maintenance = Mises à jour sécurité uniquement
Actuelle = Mises à jour sécurité + fonctionnalités

Réduire la Charge Multi-Versions

Stratégies pour minimiser le support superposé :

1. Base de code unifiée : Partager le code entre versions si possible
2. Processus de backport : Backports de sécurité automatisés ou semi-automatisés
3. Cycles de publication plus courts : Publications plus fréquentes = fenêtres de support plus prévisibles
4. Dépréciation agressive : Encourager les clients à se mettre à niveau

Considérations Spécifiques à l'Industrie

Appareils IoT

• Beaucoup ont des durées de vie attendues de 7-10 ans
• Les mécanismes de mise à jour peuvent être limités
• L'accessibilité des clients est difficile
• Considérez : capacité de mise à jour à distance, surveillance heartbeat

Logiciel B2B

• Les clients entreprise attendent un support plus long
• Les contrats de support peuvent déjà dépasser 5 ans
• La complexité d'intégration affecte le déploiement des mises à jour
• Considérez : niveaux de support étendus, services professionnels

Électronique Grand Public

• Le canal retail complique la communication client
• Les utilisateurs finaux peuvent ne pas enregistrer les produits
• Concurrence avec la culture d'obsolescence programmée
• Considérez : notifications de mise à jour dans le produit, mises à jour via app

Équipement Industriel

• Durées de vie attendues de 15-20 ans courantes
• Le temps d'arrêt pour les mises à jour est coûteux
• Installations isolées
• Considérez : déploiements par étapes, tests de compatibilité, services de déploiement professionnel

Erreurs Courantes

Coupler Sécurité aux Mises à Jour de Fonctionnalités

Problème : Correctifs de sécurité disponibles uniquement dans les versions majeures.

Pourquoi c'est faux : Les clients ne devraient pas avoir à accepter de nouvelles fonctionnalités (et de potentiels nouveaux bugs) pour obtenir des correctifs de sécurité.

Solution : Maintenir une piste de mise à jour sécurité uniquement pour les versions supportées.

Ignorer les Mises à Jour de Dépendances

Problème : Le code produit est maintenu mais les dépendances se détériorent.

Pourquoi c'est faux : La plupart des vulnérabilités proviennent des dépendances.

Solution : Inclure les mises à jour de dépendances dans votre périmètre de maintenance sécurité.

Pas de Vérification de Mise à Jour

Problème : Les mises à jour sont disponibles mais les clients ne peuvent pas vérifier l'authenticité.

Pourquoi c'est faux : Les attaquants peuvent distribuer de fausses "mises à jour".

Solution : Signer toutes les mises à jour, publier les procédures de vérification.

Fin de Support Non Claire

Problème : Le support s'arrête... juste comme ça. Aucune communication.

Pourquoi c'est faux : Les clients restent avec des produits vulnérables qu'ils ne savent pas non supportés.

Solution : Processus de fin de support proactif et documenté.

Période de Support Non Intégrée au Prix

Problème : Produit tarifé sans considérer le coût de support sur 5 ans.

Pourquoi c'est faux : Le support devient un centre de coût qui grignote les marges.

Solution : Modéliser les coûts de support avant de fixer les prix. Considérer le support comme coût des marchandises vendues.

Liste de Contrôle Période de Support

LISTE DE CONTRÔLE PLANIFICATION PÉRIODE DE SUPPORT

AVANT MISE SUR LE MARCHÉ :

Infrastructure :
[ ] Pipeline de build de mise à jour établi
[ ] Mécanisme de livraison de mise à jour sécurisé
[ ] Infrastructure de signature de code
[ ] Système de notification client

Planification :
[ ] Période de support déterminée (min 5 ans)
[ ] Date de fin de support calculée
[ ] Modèle de coût complété
[ ] Personnel de support planifié
[ ] Suivi des dépendances établi

Documentation :
[ ] Période de support indiquée dans l'info produit
[ ] Processus de mise à jour documenté
[ ] Modèles de notification client prêts

PENDANT LA PÉRIODE DE SUPPORT :

Surveillance :
[ ] Surveillance des vulnérabilités active
[ ] Mises à jour des dépendances suivies
[ ] Canaux de feedback client surveillés

Réponse :
[ ] Processus de triage des vulnérabilités
[ ] Workflow de développement de correctifs
[ ] Processus de test et publication
[ ] Processus de notification client

Reporting :
[ ] Intégration reporting ENISA (si exploitation)
[ ] Processus de publication d'avis
[ ] Suivi des métriques de support

FIN DE SUPPORT :

Communication :
[ ] Préavis de 12 mois envoyé
[ ] Rappel de 6 mois envoyé
[ ] Avis final à la fin de support
[ ] Documentation mise à jour

Transition :
[ ] Chemin de mise à niveau documenté
[ ] Mise à jour de sécurité finale publiée
[ ] Canaux de support redirigés
[ ] Documentation technique archivée (rétention 10 ans)

Important : Le CRA exige une période de support minimale de 5 ans pour les mises à jour de sécurité. Une période plus courte nécessite une justification documentée basée sur la durée de vie attendue du produit.

Conseil : Intégrez les coûts continus de surveillance des vulnérabilités et de livraison des correctifs dans la tarification de votre produit dès le premier jour.

Guides Connexes

• Planification de Fin de Vie CRA : Transitions de Produits Responsables
• Estimation des Coûts de Conformité CRA
• Guide du Dossier Technique CRA (Annexe VII)

Comment CRA Evidence Aide

CRA Evidence fournit la gestion de la période de support :

• Suivi du cycle de vie des versions : Dates de mise sur le marché, dates de fin de support
• Surveillance des dépendances : Alertes de vulnérabilités basées sur le SBOM
• Notification client : Modèles et suivi de distribution
• Documentation : Enregistrements de fin de support pour la documentation technique
• Tableau de bord de conformité : Statut de période de support à travers les produits

Planifiez vos périodes de support avec app.craevidence.com.

Cet article est fourni à titre informatif uniquement et ne constitue pas un conseil juridique. Pour des conseils de conformité spécifiques, consultez un conseiller juridique qualifié.