Produit IA : écrivez la date de fin de support dans le devis

Le 27 juillet 2026, la Commission européenne a publié sa guidance pratique sur le Cyber Resilience Act. Parmi ses 67 exemples, une précision mérite d’entrer directement dans les devis des PME : la durée de support d’un produit numérique ne se résume pas à « cinq ans ».

Le règlement fixe bien un plancher de cinq ans, sauf lorsque la durée d’usage attendue est réellement plus courte. Mais un produit conçu pour fonctionner huit, dix ou quinze ans ne peut pas transformer ce plancher en date de péremption automatique. Sa période de support doit suivre l’usage raisonnablement attendu.

Pour une machine connectée, une application métier ou un produit qui dépend d’un module IA distant, la bonne question commerciale devient donc très concrète : jusqu’à quel mois et quelle année les vulnérabilités seront-elles corrigées ?

Commission européenne, guidance CRA et calendrier des signalements, vérifiés le 28 juillet 2026.

Cinq ans est un garde-fou, pas un forfait

Le CRA demande au fabricant de déterminer une période pendant laquelle les vulnérabilités du produit et de ses composants seront traitées efficacement. Cette durée doit tenir compte de l’usage attendu, de la nature du produit, de sa finalité, des attentes raisonnables des utilisateurs et, lorsque c’est pertinent, de la durée de vie imposée par d’autres règles européennes.

La guidance insiste sur deux erreurs opposées.

La première serait d’annoncer moins de cinq ans sans pouvoir démontrer que le produit sera réellement utilisé moins longtemps. Une campagne numérique éphémère peut avoir une durée courte. Une application qui pilote un équipement installé chez un client ne devient pas éphémère parce que son contrat est renouvelé chaque année.

La seconde serait de traiter cinq ans comme une durée par défaut. Si le produit est raisonnablement destiné à servir plus longtemps, le support doit suivre cette attente. Un automate, une borne, un système de contrôle d’accès ou une machine de production ne change pas de durée de vie parce que sa couche logicielle est facturée par abonnement.

À partir de l’application des obligations principales, le fabricant devra aussi indiquer clairement, au moment de l’achat, la date de fin de la période de support, au minimum en mois et année. Lorsque la nature du produit le permet, une notification devra signaler l’expiration aux utilisateurs.

L’IA ne décide pas seule du périmètre

Ajouter une fonction IA ne place pas automatiquement toute solution dans le CRA. Il faut d’abord identifier un produit comportant des éléments numériques, sa mise à disposition sur le marché et le rôle exact de l’entreprise.

Une application vendue à des clients peut être un produit numérique. Un service distant conçu par le fabricant et indispensable à une fonction du produit peut entrer dans le périmètre comme solution de traitement de données à distance. À l’inverse, un service SaaS générique n’est pas automatiquement absorbé par le CRA parce qu’il utilise un modèle d’IA.

Le rôle de la PME compte tout autant. Acheter un assistant pour son usage interne ne fait pas d’elle le fabricant. Le commercialiser sous son nom, le modifier substantiellement puis le remettre sur le marché, ou livrer elle-même le produit change l’analyse.

Situation	Première question à trancher
Logiciel avec IA vendu sous le nom de la PME	La PME est-elle le fabricant du produit mis sur le marché ?
Machine connectée qui dépend d’une API IA	Le service distant est-il nécessaire à une fonction du produit ?
Assistant SaaS utilisé seulement en interne	La PME est-elle simplement utilisatrice d’un service ?
Module tiers intégré dans un produit client	Qui porte le produit final, ses composants et sa période de support ?

Commission européenne, guidance sur l'application du CRA, sections sur le périmètre et la période de support, vérifiée le 28 juillet 2026.

Cette qualification mérite une ligne dans le dossier produit. Elle évite deux dépenses inutiles : appliquer tout le CRA à un outil interne qui n’est pas mis sur le marché, ou découvrir trop tard qu’un service distant indispensable fait partie de la responsabilité du fabricant.

Le devis doit séparer quatre durées

Un seul mot, « support », mélange souvent des engagements différents. Pour acheter ou livrer un produit numérique avec IA, séparez au moins quatre horloges.

La durée commerciale dit combien de temps l’abonnement ou la maintenance est payé. La durée fonctionnelle indique combien de temps la version continue de fonctionner dans son environnement prévu. La période de support de sécurité fixe jusqu’à quand les vulnérabilités sont traitées. Enfin, la durée des composants tiers dépend des bibliothèques, appareils, systèmes d’exploitation, modèles et API intégrés.

Ces durées peuvent diverger. Un fournisseur peut continuer à facturer un accès alors qu’une ancienne version ne reçoit plus de correction. Une API IA peut changer avant la machine qu’elle accompagne. Un système d’exploitation peut cesser d’être maintenu alors que le produit physique reste opérationnel.

Le devis ou son annexe produit doit donc répondre sans jargon :

1. quel produit et quelle version sont couverts ;
2. quelle est la date de fin de support, en mois et année ;
3. quelles vulnérabilités et quels composants entrent dans ce support ;
4. comment les mises à jour sont livrées et qui les installe ;
5. si le passage à la dernière version est gratuit ;
6. quels coûts d’adaptation du matériel ou de l’environnement restent à charge du client ;
7. comment une fin anticipée d’un modèle ou d’une API est gérée ;
8. par quel canal le client est averti avant l’expiration.

Une nouvelle version ne remet pas toujours le compteur à zéro

Les produits logiciels évoluent par itérations. Une version substantiellement modifiée peut constituer une nouvelle mise sur le marché et nécessiter une nouvelle période de support conforme. Cela ne signifie pas que chaque modification prolonge automatiquement le support de cinq ans.

La Commission donne l’exemple d’un équipement dont le logiciel ou le service distant est profondément modifié sans changer la durée de vie raisonnablement attendue du matériel. Dans ce cas, la période restante peut rester alignée sur la durée initiale. Si la modification prolonge réellement la vie du produit, par exemple après le remplacement de sa plateforme informatique, la période doit être recalculée.

Pour un produit avec IA, le journal de versions doit donc distinguer :

• le remplacement d’un modèle sans changement de finalité ni de durée d’usage ;
• l’ajout d’une fonction qui modifie l’usage prévu ou le niveau de risque cyber ;
• la refonte d’une architecture distante ou des flux de données ;
• la modification qui prolonge réellement la durée de vie du produit.

La conclusion ne vient pas d’une règle automatique. Elle vient d’une trace : ce qui a changé, ce qui n’a pas changé, l’effet sur les risques et l’effet sur la durée d’usage attendue.

Le contrôle d’une heure avant signature

L’ENISA propose depuis le 13 juillet un modèle de maturité CRA destiné d’abord aux PME qui fabriquent des produits numériques, mais également utile aux intégrateurs et prestataires de la chaîne produit. Il confirme qu’une petite entreprise peut commencer par une évaluation structurée sans lancer immédiatement un programme lourd.

Pour le prochain achat ou renouvellement, prenez le produit le plus durable de votre liste : une application métier, une borne, un objet connecté ou un équipement qui dépend d’un service IA. Retrouvez le devis, les conditions de maintenance et la politique de versions.

• Le produit et le rôle de chaque partie sont nommés.
• La durée d'usage attendue est documentée.
• Une date de fin de support apparaît en mois et année.
• Les composants tiers et services distants critiques sont listés.
• Le coût du passage à la dernière version est explicite.
• Le canal de notification des vulnérabilités et fins de support est connu.
• Le registre de versions permet de relier chaque client à une version supportée.

ENISA, SME Cyber Resilience Maturity Assessment Model, vérifié le 28 juillet 2026.

La décision de lundi matin

Ajoutez trois colonnes à votre registre produit : « durée d’usage attendue », « fin du support sécurité » et « prochaine décision de version ». Si la première colonne dit dix ans et la deuxième cinq ans sans justification, le contrat contient déjà un trou.

Pour un nouvel achat, faites inscrire le mois et l’année dans le devis. Pour un produit que votre PME fabrique, documentez les critères qui ont fixé cette date et les dépendances capables de la raccourcir.

Le CRA n’oblige pas à promettre l’éternité. Il oblige à rendre la fin prévisible. Une date défendable coûte moins cher qu’un produit encore utilisé après la disparition de ses correctifs.