Depuis dix-huit mois, presque tous les articles publiés sur le Cyber Resilience Act tournent autour de trois sujets : la classification des produits, la génération du SBOM, et l’obligation de notification des vulnérabilités à 24 heures. Ces sujets sont importants, certes, mais ils sont aussi sur-traités à un point tel qu’on a fini par perdre de vue un volet beaucoup moins discuté, et qui est pourtant central pour les fabricants : la manière dont la déclaration d’usage prévu — l’intended use du règlement — et les conditions générales d’utilisation s’articulent pour déterminer où s’arrête exactement votre responsabilité.

Ce volet n’est pas un détail. Pour un fabricant qui met un produit numérique sur le marché européen, c’est la frontière entre une obligation maîtrisée et une exposition illimitée. Or cette frontière est pratiquement ignorée des programmes de conformité CRA que je vois passer.

L’usage prévu n’est pas une formalité de dossier technique

Le règlement (UE) 2024/2847 impose au fabricant de documenter, dans son dossier technique (Annexe V et VI), l’usage prévu du produit ainsi que ses conditions raisonnablement prévisibles d’utilisation. La plupart des équipes produit traitent cela comme une obligation déclarative : on écrit quelques lignes, on coche la case, on passe à autre chose.

C’est une erreur. L’intended use est en réalité le pivot de toute votre architecture de conformité CRA. Il définit le périmètre dans lequel le produit doit satisfaire aux exigences essentielles de l’Annexe I. Il conditionne l’analyse de risque cyber. Il borne les attentes en matière de support et de mises à jour. Et surtout, il définit implicitement le périmètre dans lequel votre responsabilité peut être engagée.

Un exemple concret. Un fabricant de caméras IP industrielles déclare un usage prévu strictement professionnel, pour la vidéosurveillance de sites industriels avec administration confiée à du personnel formé. Si un revendeur installe ces mêmes caméras chez des particuliers en accès direct depuis Internet sans changement de mots de passe, et qu’un incident survient, le fabricant peut s’appuyer sur la déclaration d’usage pour démontrer qu’il y a eu sortie du périmètre prévu. À l’inverse, si l’intended use a été rédigé largement — « vidéosurveillance résidentielle ou professionnelle » — la même configuration relève intégralement de la responsabilité du fabricant.

D’où la première règle de discipline : un intended use trop large vous expose, un intended use trop restrictif vous coupe du marché. C’est un arbitrage commercial-juridique qui doit être pris par la direction produit, pas par le rédacteur du dossier technique au dernier moment.

La modification substantielle, ou comment l’obligation peut bouger

Le règlement introduit aussi la notion de modification substantielle. Si un produit subit après sa mise sur le marché une modification qui altère l’usage prévu ou augmente significativement le risque cyber, il bascule à nouveau dans le périmètre CRA, et la personne qui réalise la modification peut devenir elle-même « fabricant » au sens du règlement. C’est l’article 13 du CRA qui pose ce principe.

Cette mécanique a une conséquence stratégique majeure que peu de gens exploitent : elle permet, par une rédaction soignée des clauses contractuelles, d’organiser un transfert de responsabilité vers un intégrateur ou un utilisateur professionnel qui modifie le produit. Si vous fabriquez un module IoT industriel destiné à être intégré dans une chaîne d’automatisation par un système intégrateur, et que ce dernier modifie la configuration de sécurité par défaut, recompile le firmware, ou ajoute des fonctions non prévues, vous pouvez contractuellement faire reconnaître que l’intégrateur engage sa propre responsabilité de fabricant pour la version modifiée.

La rédaction qui permet cela suppose une cohérence parfaite entre trois documents : la déclaration d’usage prévu dans le dossier technique CRA, les conditions générales de licence ou de vente, et la documentation technique destinée à l’utilisateur. Une incohérence entre ces trois éléments — et je vois des incohérences quasiment chaque fois que j’ouvre un dossier — vous prive de la défense.

Les CGU restent vos amies, à condition de connaître leurs limites

Sur le plan contractuel B2B, le droit français autorise depuis longtemps les clauses limitatives de responsabilité. La jurisprudence Faurecia contre Oracle, qui s’est achevée par l’arrêt de l’assemblée plénière de la Cour de cassation du 29 juin 2010, a clarifié les conditions de validité. Trois principalement : le montant de la limitation ne doit pas être dérisoire au point de vider l’obligation essentielle de sa substance ; il ne doit pas y avoir manquement à une obligation essentielle au sens où le contrat perdrait son économie ; il ne doit pas y avoir faute lourde, appréciée subjectivement, qui exige un comportement gravement négligent et non pas un simple manquement contractuel.

Cette jurisprudence reste pleinement applicable. Un fabricant peut donc, en B2B, plafonner sa responsabilité financière à un montant raisonnable — souvent indexé sur le prix du produit, parfois sur la valeur des licences annuelles, parfois un plafond contractuel forfaitaire. Cela ne supprime pas l’obligation au sens CRA, mais cela borne l’exposition financière en cas de litige.

Mais attention au piège classique : les clauses limitatives ne protègent pas contre les obligations d’ordre public. Les obligations imposées par le CRA elles-mêmes, comme la notification de vulnérabilités dans les délais prévus à l’article 14, ne peuvent pas être contractuellement contournées. Les sanctions administratives en cas de non-respect — qui peuvent atteindre 15 millions d’euros ou 2,5 % du chiffre d’affaires mondial — ne sont pas plafonnables par contrat. Idem pour les amendes liées au RGPD si des données personnelles sont en jeu.

Le contrat permet de limiter le risque civil, pas le risque réglementaire. C’est une distinction que beaucoup d’équipes commerciales perdent de vue quand elles affichent une assurance excessive à propos des CGU « qui les couvrent ».

Et la nouvelle directive sur la responsabilité va corser l’affaire

Le 18 novembre 2024, le Journal officiel de l’Union européenne a publié la directive (UE) 2024/2853 relative à la responsabilité du fait des produits défectueux, abrogeant la directive de 1985. Les États membres ont jusqu’au 9 décembre 2026 pour la transposer. Elle s’appliquera aux produits mis sur le marché à partir de cette date.

Ce texte mérite une attention particulière de la part des fabricants concernés par le CRA, pour quatre raisons.

Premièrement, le logiciel devient explicitement un « produit » au sens de la directive, y compris quand il est distribué de manière autonome ou intégré à du hardware. Les logiciels open source à finalité commerciale sont inclus ; ceux à finalité non commerciale sont exclus.

Deuxièmement, la directive introduit une approche dynamique de la défectuosité, qui prend en compte l’évolution du produit après sa mise sur le marché — typiquement les mises à jour, les nouvelles fonctions, les modifications de comportement issues d’apprentissage continu pour les systèmes d’IA. Un produit qui était considéré comme sûr au moment de sa commercialisation peut devenir défectueux suite à un événement ultérieur.

Troisièmement, les exonérations classiques du fabricant sont durcies. Le risque de développement (le fait qu’un défaut n’était pas détectable à la date de mise sur le marché compte tenu de l’état des connaissances scientifiques et techniques) reste invocable, mais les présomptions au profit de la victime sont renforcées, et la charge de la preuve glisse partiellement vers le fabricant.

Quatrièmement, et c’est là que l’articulation avec le CRA devient critique, la conformité aux exigences essentielles de sécurité prévues par le CRA devient un élément central de la défense du fabricant dans le cadre du contentieux 2024/2853. Si vous démontrez que le produit était conforme aux exigences essentielles Annexe I, que vous avez tenu votre processus de gestion coordonnée des vulnérabilités, que vous avez notifié dans les délais prévus, et que l’usage était conforme à l’intended use déclaré, vous renforcez considérablement votre position défensive. À l’inverse, une faille dans votre processus CRA devient un élément à charge dans un contentieux 2024/2853.

D’où la conséquence très concrète : votre dossier technique CRA ne sera pas seulement l’instrument de votre conformité administrative. Il deviendra une pièce centrale de votre défense en cas de litige. Bâclez le premier, vous perdrez le second.

La cohérence des trois documents, plus que chaque document pris isolément

À ce stade, je voudrais faire passer le message principal de cet article. Le piège pour les fabricants n’est pas d’avoir un dossier technique CRA insuffisant, ou des CGU mal rédigées, ou une documentation utilisateur lacunaire. Le piège est d’avoir trois documents séparément acceptables mais incohérents entre eux. Et c’est ce que je vois neuf fois sur dix.

L’équipe produit rédige l’intended use du dossier technique CRA en optimisant la latitude commerciale. L’équipe juridique rédige les CGU en optimisant la limitation du risque. L’équipe documentation rédige le manuel utilisateur en optimisant la clarté pédagogique. Les trois documents sont produits par trois équipes qui ne se parlent pas, et ils contiennent des contradictions invisibles à l’œil non averti mais dévastatrices en contentieux.

Exemple typique : le dossier technique déclare que le produit est destiné à un usage avec administration par du personnel formé. Les CGU n’imposent pas de formation et autorisent toute utilisation respectant les lois en vigueur. Le manuel utilisateur explique comment changer la configuration de sécurité par défaut. Un avocat adverse exploitera la deuxième et la troisième assertion pour montrer que l’usage prévu était en réalité élargi. Le bénéfice défensif de la première assertion s’évapore.

D’où ma recommandation opérationnelle, qui suppose un investissement d’environ trois à six mois de travail pour un produit de taille moyenne : rédaction conjointe et coordonnée de la déclaration d’usage prévu, des conditions générales, et de la documentation utilisateur. Avec une révision croisée par chacune des trois équipes. Avec validation par un comité produit-juridique unique. Avec versionnement aligné, pour que toute évolution se reflète simultanément dans les trois documents.

C’est moins glamour que de débattre du format CycloneDX ou SPDX pour le SBOM, mais c’est probablement plus rentable en termes de réduction d’exposition juridique.

En guise de précautions

Une dernière chose avant de refermer ce papier. Je suis RSSI senior avec une expertise sur la conformité multi-référentielle, pas juriste. Tout ce que j’ai écrit ci-dessus est une lecture stratégique d’opérationnel, qui doit être validée par un avocat IT avant toute mise en application sur des contrats réels. Pour les fabricants qui souhaitent traiter ce sujet sérieusement, l’investissement dans une revue conjointe RSSI ou Product Security Officer et avocat IT spécialisé contrats numériques est probablement le meilleur retour qu’on puisse faire sur quelques journées de travail.

Et je passerai dans un prochain article sur le B2C, où la mécanique change radicalement : les clauses limitatives perdent l’essentiel de leur portée face à un consommateur, et la directive 2024/2853 prend toute sa puissance. Pour les fabricants qui visent les deux marchés, ce sera un autre type de gymnastique contractuelle, à anticiper en amont de la mise en œuvre du CRA en décembre 2027.

Sources : règlement (UE) 2024/2847 du 23 octobre 2024 (CRA) ; directive (UE) 2024/2853 du 23 octobre 2024 (responsabilité produits défectueux) ; Cass. ass. plén., 29 juin 2010, Faurecia c/ Oracle. Cet article n’est pas un avis juridique. Toute application à un cas concret doit être validée par un avocat compétent.