CRA fournisseurs : diligence et clauses contractuelles

Le 11 septembre 2026, dans moins d’un mois, les obligations de signalement du Cyber Résilience Act deviennent applicables. Un fabricant devra alerter le CSIRT coordinateur et l’ENISA dans les 24 heures suivant la connaissance d’une vulnérabilité activement exploitée — y compris lorsque cette vulnérabilité se loge dans un composant qu’il n’a pas écrit. C’est là que la plupart des dossiers de conformité que j’examine s’effondrent : l’entreprise a documenté son propre code, mais elle est incapable de dire, en 24 heures, quelles versions de quelles bibliothèques tierces tournent dans quels produits livrés.

Le CRA n’est pas un texte sur le code que vous écrivez. C’est un texte sur le produit que vous mettez sur le marché — assemblé, dans les faits, à 80 % ou 90 % de composants que vous n’avez pas produits.

Deux positions dans la chaîne, deux régimes juridiques

Avant toute chose, il faut savoir où vous vous situez. Le règlement (UE) 2024/2847 ne traite pas de la même manière celui qui intègre des composants et celui qui achète des produits finis.

Votre position	Le CRA vous oblige-t-il ?	Ce qui vous concerne
Fabricant intégrant des composants tiers	Oui, directement	Art. 13(5), 13(6), 13(8), 14 ; annexe I
Importateur ou distributeur	Oui, obligations allégées	Art. 19 à 21
Personne réalisant une modification substantielle	Oui, comme fabricant	Art. 22
Acheteur / utilisateur professionnel	Non, sauf marchés publics	Art. 5(2) ; levier contractuel
Steward de logiciel open source	Régime allégé spécifique	Art. 24

Cette grille de lecture n’est pas cosmétique : elle détermine si vous devez insérer des clauses dans vos contrats fournisseurs pour vous conformer, ou simplement pour vous protéger. Si vous n’êtes pas certain de votre qualification, mon article sur qui est concerné par le CRA reprend la méthode d’analyse produit par produit.

La diligence requise de l’article 13(5) : ce que le texte exige vraiment

L’article 13(5) du CRA tient en une phrase, et c’est probablement la disposition la plus sous-estimée du règlement :

Les fabricants font preuve de la diligence requise lorsqu’ils intègrent des composants provenant de tiers, de sorte que ces composants ne compromettent pas la cybersécurité du produit comportant des éléments numériques, y compris lorsqu’ils intègrent des composants de logiciels libres et ouverts qui n’ont pas été mis à disposition sur le marché dans le cadre d’une activité commerciale.

Trois observations sur la portée de ce texte.

Première observation : la diligence est une obligation de moyens, mais documentée. Le CRA n’exige pas que vos composants soient exempts de vulnérabilités — ce serait une obligation impossible. Il exige que vous ayez mis en place un processus de sélection, de vérification et de surveillance, et que ce processus soit démontrable. L’article 13(7) impose d’ailleurs de documenter systématiquement « les aspects pertinents en matière de cybersécurité », y compris les informations fournies par des tiers. En cas de contrôle de l’autorité de surveillance du marché, ce qui sera examiné n’est pas la présence d’une CVE dans votre pile logicielle, mais votre capacité à prouver que vous l’avez identifiée, évaluée et traitée.

Deuxième observation : l’open source non commercial est explicitement visé. C’est le point qui surprend le plus les équipes techniques. Le mainteneur bénévole d’une bibliothèque publiée sur un dépôt public n’est, lui, soumis à aucune obligation au titre du CRA — le règlement l’exclut de son champ dès lors qu’il n’y a pas d’activité commerciale. Mais cette exclusion ne se propage pas : dès que vous intégrez cette bibliothèque dans un produit que vous commercialisez, la charge de la diligence bascule intégralement sur vous. J’ai détaillé cette mécanique dans mon analyse du CRA et des logiciels open source : le texte protège les communautés, il ne protège pas leurs utilisateurs industriels.

Troisième observation : la diligence doit être proportionnée au risque. Vous n’avez pas à auditer avec la même intensité une bibliothèque de formatage de dates et une pile cryptographique. La proportionnalité est admise par le texte (art. 13(7)) et confirmée par les orientations que la Commission a publiées le 27 juillet 2026 (communication C(2026) 5252, adoptée au titre de l’article 26 du CRA), qui consacrent 67 exemples pratiques à l’application concrète du règlement, avec une attention particulière aux microentreprises et PME. Ces orientations ne sont pas contraignantes, mais elles constituent la position officielle de la Commission — et donc le premier référentiel qu’invoqueront les autorités nationales.

Ce que la diligence recouvre concrètement

Dans les dossiers que j’accompagne, un processus de diligence défendable comporte six composantes :

1. Un inventaire exhaustif des composants tiers, matérialisé par un SBOM au niveau des dépendances de premier rang au minimum — l’annexe I, partie II, point 1 en fait une exigence essentielle.
2. Un critère de sélection écrit appliqué avant l’intégration : existence d’une politique de divulgation coordonnée chez le fournisseur, fréquence des publications de correctifs, activité du projet, historique des CVE.
3. Une surveillance continue des sources de vulnérabilités pour chaque composant inventorié, avec un délai cible de détection.
4. Une évaluation du risque propre à votre produit : une CVE critique dans un composant que vous n’appelez pas dans votre configuration ne présente pas le même risque qu’une CVE moyenne sur un chemin d’exécution exposé.
5. Une décision tracée pour chaque vulnérabilité : correction, contournement, ou acceptation motivée.
6. La conservation de la preuve pendant au moins dix ans après la mise sur le marché, ou pendant la période de support si elle est plus longue (art. 13(13)).

Ce sont exactement les briques du programme décrit dans mon guide sur la gestion des vulnérabilités CRA — appliquées cette fois à ce que vous n’avez pas écrit.

L’obligation remontante de l’article 13(6) : signaler au fournisseur du composant

L’article 13(6) crée une obligation dont je constate qu’elle est presque systématiquement ignorée dans les analyses d’écart. Lorsqu’un fabricant identifie une vulnérabilité dans un composant intégré — y compris un composant open source —, il doit :

• signaler la vulnérabilité à la personne ou à l’entité qui fabrique ou maintient le composant ;
• traiter et corriger la vulnérabilité selon les exigences de l’annexe I, partie II ;
• et, s’il a développé une modification logicielle ou matérielle corrigeant la faille dans ce composant, partager le code ou la documentation correspondants avec le mainteneur, le cas échéant dans un format lisible par machine.

Autrement dit : le CRA impose une obligation de contribution en amont. Vous ne pouvez pas patcher silencieusement une bibliothèque tierce dans votre fork interne et laisser le reste de l’écosystème exposé. C’est une disposition inhabituelle en droit des produits, et elle a des conséquences opérationnelles réelles — notamment sur les politiques internes qui interdisent aux développeurs de publier du code vers l’extérieur. Il est recommandé de traiter ce point dès maintenant avec vos directions juridique et sécurité, parce qu’il suppose une procédure d’autorisation de publication qui n’existe pas dans la plupart des entreprises.

Le piège de l’article 22 : intégrer, c’est parfois devenir fabricant

L’article 22 dispose qu’une personne autre que le fabricant, l’importateur ou le distributeur qui réalise une modification substantielle d’un produit comportant des éléments numériques et le met à disposition sur le marché est considérée comme fabricant. Elle devient alors soumise aux articles 13 et 14 — pour la partie affectée par la modification, ou pour le produit entier si la modification affecte sa cybersécurité globale.

La notion de modification substantielle, définie à l’article 3 du CRA, couvre les changements qui affectent la conformité du produit aux exigences essentielles de l’annexe I, partie I, ou qui modifient la finalité prévue pour laquelle le produit a été évalué. Le règlement précise à l’inverse qu’une mise à jour de sécurité destinée à corriger une vulnérabilité ne constitue pas, en elle-même, une modification substantielle.

Trois situations françaises courantes basculent dans ce régime :

• Le revendeur à valeur ajoutée qui recompile un logiciel avec ses propres modules et le distribue sous sa marque.
• L’intégrateur qui livre une solution matérielle et logicielle assemblée dont il modifie le firmware ou les paramètres de sécurité par défaut.
• L’éditeur qui construit un produit sur une brique open source en modifiant son périmètre fonctionnel.

Dans ces trois cas, on ne parle plus de clauses de protection : on parle d’obligations propres, avec marquage CE, documentation technique et procédure d’évaluation de la conformité à votre charge. Le régime des importateurs et distributeurs ne vous couvre plus.

La période de support : le point de rupture contractuel

C’est le sujet sur lequel je vois les négociations achever de dérailler. L’article 13(8) impose une période de support d’au moins cinq ans, sauf si la durée d’utilisation attendue du produit est inférieure. Et il précise expressément que le fabricant peut prendre en compte, pour la déterminer, « les périodes de support des composants intégrés qui assurent des fonctions essentielles et qui proviennent de tiers ».

Le problème est arithmétique. Si vous vous engagez sur une période de support de sept ans auprès de vos clients et que la bibliothèque cryptographique sur laquelle repose votre authentification annonce une fin de vie à trois ans, vous portez seul le delta. L’article 13(9) aggrave la situation : chaque mise à jour de sécurité publiée pendant la période de support doit rester disponible au moins dix ans après sa publication, ou pendant le reste de la période de support si celle-ci est plus longue.

La conséquence pratique est simple, et elle relève de la gestion de portefeuille avant de relever du droit : la période de support de votre produit ne peut pas excéder durablement celle de ses composants critiques sans provision de maintenance interne. Il est recommandé de faire de la date de fin de support annoncée par le fournisseur un critère de sélection formel, au même titre que le prix. J’ai détaillé les mécanismes de calcul dans mon article sur le support sécurité des produits CRA.

Recevez nos analyses conformité chaque semaine. CRA, NIS2, RGPD, AI Act, Data Act : une lecture par semaine pour comprendre ce qui change et ce qu’il faut faire. S’inscrire à la newsletter.

Côté acheteur : le CRA comme levier de négociation

Si vous achetez des produits sans les intégrer ni les modifier, le CRA ne vous impose rien directement. Il vous donne en revanche deux leviers.

Le levier réglementaire des marchés publics

L’article 5(2) du CRA prévoit que, sans préjudice des directives 2014/24/UE et 2014/25/UE, lorsque des produits comportant des éléments numériques relevant du règlement sont achetés, les États membres veillent à ce que la conformité aux exigences essentielles de l’annexe I — y compris la capacité des fabricants à traiter efficacement les vulnérabilités — soit prise en considération dans la procédure de passation.

Pour un acheteur public français, cela signifie que la capacité de gestion des vulnérabilités devient un critère opposable, et non plus une préférence technique à justifier. Concrètement, cela se traduit par des exigences de mémoire technique portant sur le SBOM, les délais de correction et la période de support — et par la possibilité d’écarter une offre qui n’y répond pas.

Le levier contractuel du secteur privé

Pour un acheteur privé, le CRA fournit un référentiel commun qui remplace avantageusement les questionnaires sécurité maison. Vous n’avez plus à inventer vos propres exigences : vous exigez la conformité à un règlement européen, avec des obligations précises et des sanctions administratives pouvant atteindre 15 millions d’euros ou 2,5 % du chiffre d’affaires annuel mondial pour les manquements aux exigences essentielles de l’annexe I et aux obligations des articles 13 et 14 (art. 64(2)). Le détail du régime figure dans mon analyse des sanctions du CRA.

Un point de vigilance, cependant : le CRA ne s’applique pleinement qu’au 11 décembre 2027. Exiger aujourd’hui une déclaration UE de conformité CRA d’un fournisseur est prématuré et vous exposera à des réponses évasives. En 2026, l’exigence réaliste porte sur la trajectoire : plan de conformité daté, SBOM disponible, politique de divulgation coordonnée publiée, période de support annoncée. Le calendrier d’application du CRA donne les échéances précises à intégrer dans vos plannings d’achat.

Les sept clauses à insérer dans vos contrats fournisseurs

Voici la structure que je recommande pour un avenant CRA à un contrat de fourniture logicielle ou matérielle. Elle est volontairement modulaire : les clauses 1 à 4 sont indispensables, les suivantes se négocient selon la criticité du composant.

1. Nomenclature logicielle (SBOM). Le fournisseur remet, à chaque livraison de version, une nomenclature au format SPDX ou CycloneDX couvrant les dépendances directes et transitives, incluant nom, version, éditeur et licence de chaque composant. Cette clause est celle qui conditionne toutes les autres : sans SBOM, aucune diligence n’est démontrable.

2. Notification des vulnérabilités. Le fournisseur notifie l’acquéreur de toute vulnérabilité affectant le produit livré, dans un délai contractuel aligné sur vos propres contraintes. Le point d’attention est le décalage : le CRA impose au fabricant une alerte précoce à l’ENISA sous 24 heures, mais aucune obligation de délai vis-à-vis de ses clients professionnels — l’article 14(8) prévoit seulement une information des utilisateurs concernés, sans échéance chiffrée. Ce délai doit donc être créé par le contrat. Un délai de 48 heures pour les vulnérabilités critiques, aligné sur les seuils CVSS, constitue un point d’équilibre praticable.

3. Engagement de correction. Des délais de mise à disposition des correctifs différenciés par niveau de criticité, avec pénalités ou droit de résiliation en cas de dépassement répété. Il est utile d’aligner ces délais sur votre propre politique de gestion des correctifs.

4. Période de support garantie. Date de fin de support explicite, obligation de préavis en cas d’anticipation, et clause de sortie ou de séquestre de code si la fin de support intervient avant l’échéance que vous avez vous-même annoncée à vos clients.

5. Coopération en cas de signalement. Le fournisseur s’engage à fournir, sous 24 heures, les éléments techniques nécessaires à l’établissement de votre notification au titre de l’article 14 : description de la vulnérabilité, sévérité, mesures d’atténuation disponibles. Sans cette clause, vous serez contractuellement seul face à un délai réglementaire de 24 heures.

6. Audit et preuve. Droit d’audit documentaire annuel, ou à défaut engagement de production des attestations et rapports de tests d’intrusion. Pour les composants critiques, une exigence de certification ISO 27001 ou de qualification SecNumCloud selon la nature de la prestation.

7. Répartition des responsabilités. Clause de garantie contre les conséquences d’une non-conformité du composant au CRA, plafond de responsabilité négocié en cohérence avec l’exposition réelle — les 15 millions d’euros ou 2,5 % du chiffre d’affaires de l’article 64(2) ne se logent pas dans un plafond fixé à douze mois de redevances.

Cette architecture reprend, en la transposant à la cybersécurité produit, la logique du contrat de sous-traitance de l’article 28 du RGPD : obligations documentaires, délais de notification, droit d’audit, répartition des responsabilités. Si vous avez déjà structuré votre chaîne de sous-traitance RGPD, l’ossature est réutilisable — et c’est le meilleur argument pour ne pas repartir d’une page blanche.

Le questionnaire de diligence : douze questions qui discriminent

Un questionnaire fournisseur utile fait une page, pas quarante. Voici les douze questions qui, dans mon expérience, séparent réellement les fournisseurs sérieux des autres.

#	Question	Ce qu’une bonne réponse contient
1	Fournissez-vous un SBOM ?	Format SPDX/CycloneDX, à chaque version, dépendances transitives incluses
2	Quelle est votre politique de divulgation coordonnée ?	URL publique, point de contact unique, délai de réponse annoncé
3	Quelle est la période de support de ce produit ?	Date de fin explicite, pas « tant que le produit est commercialisé »
4	Quel est votre délai de correction par niveau de criticité ?	Engagement chiffré différencié, pas « dans les meilleurs délais »
5	Comment notifiez-vous vos clients d’une vulnérabilité ?	Canal identifié, format structuré, délai contractuel
6	Où est établi votre principal établissement dans l’Union ?	Détermine le CSIRT coordinateur compétent (art. 14(7))
7	Le produit relève-t-il de l’annexe III ou IV du CRA ?	Conditionne la procédure d’évaluation applicable
8	Quel est votre plan de conformité CRA et son échéancier ?	Jalons datés jusqu’au 11 décembre 2027
9	Comment surveillez-vous les vulnérabilités de vos propres composants ?	Outillage nommé, fréquence, périmètre
10	Avez-vous déjà réalisé une évaluation par un organisme notifié ?	Nom de l’organisme, périmètre, date
11	Quelles données personnelles le produit traite-t-il ?	Croisement nécessaire avec l’article 28 du RGPD
12	Quelles sont vos dépendances open source critiques ?	Liste nominative, avec activité et gouvernance du projet

Les questions 6, 7 et 10 sont particulièrement discriminantes : un fournisseur qui ne sait pas y répondre en 2026 n’a pas commencé son travail de conformité. Pour la partie données personnelles, mon modèle de questionnaire sous-traitants RGPD fournit la trame complémentaire.

Articulation avec le RGPD, NIS2 et DORA

Aucune de ces obligations ne remplace les autres. Un même fournisseur peut relever simultanément de quatre régimes de chaîne d’approvisionnement, avec des logiques distinctes.

Texte	Ce qui est encadré	Base juridique
CRA	Sécurité du produit livré, sur tout son cycle de vie	Art. 13(5), 13(6), 22
RGPD	Traitement de données personnelles pour votre compte	Art. 28, art. 32
NIS2	Sécurité de la chaîne d’approvisionnement de l’entité régulée	Art. 21(2)(d) de la directive NIS2
DORA	Prestations TIC pour les entités financières	Art. 28 à 30 du règlement

L’erreur la plus fréquente consiste à traiter ces obligations dans quatre contrats distincts, négociés par quatre équipes différentes, avec quatre délais de notification incompatibles. Le fournisseur, lui, appliquera le plus favorable. Il est bien plus efficace de construire une annexe fournisseur unique, avec des sections par régime et un délai de notification unifié — le plus court des quatre. L’articulation détaillée figure dans mes analyses du CRA et de NIS2, de la sous-traitance sécurité sous NIS2 et de la sous-traitance TIC sous DORA.

Les cinq erreurs que je rencontre le plus souvent

1. Confondre inventaire d’achats et SBOM. La liste des licences payées par la direction des achats ne dit rien des bibliothèques embarquées par vos développeurs. Ce sont deux périmètres sans intersection significative.
2. S’arrêter aux dépendances de premier rang. L’essentiel du risque se loge dans les dépendances transitives, que personne n’a choisies explicitement.
3. Croire que l’open source est un angle mort réglementaire. L’article 13(5) le vise expressément, et l’absence d’obligation du mainteneur ne fait qu’accroître la vôtre.
4. Négocier un plafond de responsabilité déconnecté du risque CRA. Un plafond à douze mois de redevances face à une amende potentielle de 2,5 % du chiffre d’affaires mondial n’est pas une négociation, c’est un transfert de risque à sens unique.
5. Attendre décembre 2027 pour agir. Les contrats de fourniture signés en 2026 courront jusqu’en 2029 ou 2030. Chaque contrat signé sans clause CRA aujourd’hui est un contrat qu’il faudra renégocier en position de faiblesse.

Sur ce dernier point, l’expérience du RGPD est instructive : les entreprises qui ont attendu mai 2018 pour réviser leurs contrats de sous-traitance ont mis trois ans à rattraper leur retard, et l’ont fait au prix d’avenants systématiquement défavorables. C’est ce type de travail de cartographie et de suivi contractuel que Legiscope automatise pour la chaîne de sous-traitance RGPD ; la logique est directement transposable à la chaîne CRA.

Ce qu’il faut retenir

• L’article 13(5) du CRA fait de vous le garant de composants que vous n’avez pas écrits, y compris des logiciels libres publiés hors activité commerciale. L’exclusion dont bénéficient les mainteneurs ne se propage pas à leurs utilisateurs industriels.
• La diligence est une obligation de moyens documentée, pas une obligation de résultat : inventaire, critères de sélection, surveillance, évaluation, décision tracée, conservation de la preuve pendant dix ans minimum (art. 13(13)).
• L’article 13(6) impose de remonter la vulnérabilité au mainteneur du composant et de partager le correctif développé — une obligation de contribution en amont que la plupart des politiques internes de publication de code interdisent aujourd’hui.
• Une modification substantielle vous transforme en fabricant au sens de l’article 22, avec les obligations complètes des articles 13 et 14. Revendeurs à valeur ajoutée et intégrateurs sont les premiers concernés.
• La période de support de votre produit ne peut pas excéder durablement celle de ses composants critiques. Le minimum de cinq ans de l’article 13(8) se heurte à des cycles de vie de bibliothèques souvent plus courts.
• Sept clauses suffisent : SBOM, notification, correction, période de support, coopération au signalement, audit, responsabilité. Le CRA n’impose aucun délai de notification du fabricant vers ses clients professionnels — ce délai n’existe que si vous l’écrivez.
• Les échéances sont le 11 septembre 2026 pour le signalement et le 11 décembre 2027 pour le reste. Les contrats signés aujourd’hui courent au-delà.

FAQ

Le CRA s’applique-t-il à mon fournisseur SaaS ?

En principe non pour le service lui-même, mais oui pour les solutions de traitement de données à distance nécessaires au fonctionnement d’un produit comportant des éléments numériques : le CRA les inclut dans son champ. Les orientations de la Commission du 27 juillet 2026 traitent précisément cette frontière, qui a fait l’objet de nombreuses demandes de clarification. En pratique, un logiciel purement en ligne sans composant installé chez le client échappe le plus souvent au CRA et relève plutôt de NIS2 ou de DORA selon le secteur. J’ai développé les critères dans mon article sur le CRA pour les éditeurs SaaS.

Puis-je exiger dès maintenant une déclaration UE de conformité CRA ?

Ce serait prématuré. Les obligations de marquage CE et de déclaration UE de conformité ne s’appliquent qu’à partir du 11 décembre 2027, et les organismes notifiés ne sont notifiables que depuis le 11 juin 2026. Exiger aujourd’hui un document qui ne peut pas légalement exister vous exposera à des engagements de complaisance sans valeur probante. L’exigence utile en 2026 porte sur la trajectoire : plan daté, SBOM disponible, politique de divulgation publiée.

Que faire si un composant open source critique n’a pas de mainteneur actif ?

C’est le scénario le plus délicat, et il n’a pas de réponse contractuelle — il n’y a personne avec qui contracter. Trois options, par ordre de préférence : remplacer le composant, internaliser sa maintenance en assumant explicitement le rôle de mainteneur pour votre fork, ou contribuer au financement du projet via l’une des fondations qui structurent ces communautés. La pire option est l’inaction documentée nulle part : l’article 13(5) sera lu comme un manquement caractérisé si vous avez identifié le risque sans le traiter.

Un acheteur privé peut-il refuser un fournisseur non conforme au CRA ?

Oui, la liberté contractuelle le permet sans réserve, et un critère de sécurité produit est parfaitement licite dans une consultation privée. La question réelle n’est pas juridique mais économique : sur certains segments techniques, l’alternative conforme n’existe pas encore. Dans ce cas, la démarche recommandée consiste à documenter l’analyse d’écart, à obtenir un engagement de trajectoire daté, et à conserver cette documentation — elle constituera la preuve de votre diligence au sens de l’article 13(5) si vous êtes vous-même fabricant.

Le CRA remplace-t-il mon annexe sécurité RGPD ?

Non, les objets sont distincts. Le CRA porte sur la sécurité du produit indépendamment de la nature des données traitées ; l’article 32 du RGPD porte sur la sécurité du traitement de données personnelles. Un produit parfaitement conforme au CRA peut violer le RGPD par une base légale défaillante, et inversement. L’articulation des deux textes, y compris sur le terrain de la protection dès la conception, est détaillée dans mon analyse de l’intersection CRA et RGPD. En pratique, il est recommandé de maintenir une annexe unique à deux sections plutôt que deux contrats parallèles.

---

Thiébaut Devergranne est docteur en droit (Paris II) et consultant en protection des données depuis plus de vingt ans, dont six passées au sein des services du Premier ministre (SGDN/DCSSI). Il est le fondateur de donneespersonnelles.fr et de Legiscope.