Le 27 juillet 2026, la Commission européenne a publié de nouvelles orientations pratiques sur le Cyber Resilience Act. Pour les éditeurs, intégrateurs, distributeurs en marque blanche, fabricants d’objets connectés et entreprises qui adaptent un logiciel tiers, une question devient urgente : une modification du produit peut-elle les faire basculer dans la catégorie du « fabricant » ? La réponse dépend moins du volume de code modifié que de ses effets. Une évolution qui change la destination, les fonctions ou le niveau de risque cyber du produit peut constituer une modification substantielle. Celui qui la réalise puis remet le produit sur le marché peut alors supporter les obligations du fabricant.
Cette qualification n’est pas un simple débat de vocabulaire. Elle commande l’analyse des risques, la documentation technique, l’évaluation de conformité, le marquage CE, le traitement des vulnérabilités et, à compter du 11 septembre 2026, certaines notifications de sécurité. Elle modifie aussi la répartition des risques dans les contrats entre éditeur, intégrateur, importateur, distributeur et client. L’entreprise doit donc documenter chaque version, distinguer le correctif de sécurité de l’évolution fonctionnelle et vérifier qui décide réellement de la mise sur le marché. Voici la méthode juridique et opérationnelle pour qualifier la modification, sécuriser les preuves et réagir si le contrat ne répartit pas correctement les responsabilités.
I. Cyber Resilience Act : quand une modification de logiciel vous fait-elle devenir fabricant ?
A. Comment reconnaître une modification substantielle d’un logiciel ou d’un objet connecté ?
Le règlement (UE) 2024/2847 du 23 octobre 2024 vise les produits comportant des éléments numériques mis à disposition sur le marché de l’Union. La notion englobe de nombreux logiciels, applications et matériels connectés, sous réserve des exclusions et régimes sectoriels prévus par le texte. L’entreprise doit commencer par identifier le produit, son utilisation prévue, ses fonctions, son environnement matériel et logiciel, ainsi que les risques raisonnablement prévisibles.
Une modification est substantielle lorsqu’elle intervient après la mise sur le marché et affecte la conformité du produit aux exigences essentielles de cybersécurité, ou lorsqu’elle modifie l’utilisation prévue pour laquelle le produit a été évalué. Le raisonnement est concret. Une nouvelle ligne de code n’est pas automatiquement substantielle ; une évolution apparemment courte peut l’être si elle ouvre une interface, ajoute un moyen d’authentification, modifie le traitement des données, change une communication réseau ou étend les droits d’un utilisateur.
Les considérants du règlement donnent une première frontière utile. Un correctif qui réduit le risque cyber sans changer l’utilisation prévue n’est normalement pas une modification substantielle. Une correction ciblée d’une vulnérabilité, un ajustement mineur du code, une amélioration visuelle, une nouvelle langue ou l’ajout de pictogrammes restent en principe du côté de la mise à jour mineure. La qualification change si l’évolution transforme les fonctions, le type ou les performances du produit et accroît la surface d’attaque. L’ajout d’un nouveau champ de saisie, d’une API, d’un accès distant, d’une synchronisation cloud ou d’un module d’intelligence artificielle mérite ainsi une analyse formalisée.
Le test doit porter sur quatre questions successives :
- la fonction nouvelle change-t-elle ce que le produit est censé faire ou les personnes qui peuvent l’utiliser ;
- la modification crée-t-elle un nouveau flux de données, une nouvelle dépendance, une nouvelle interface ou un nouveau privilège ;
- l’analyse de risques, la documentation technique ou l’évaluation de conformité d’origine restent-elles valables sans nouvelle vérification ;
- le produit modifié est-il remis à disposition dans le cadre d’une activité commerciale, même gratuitement ou sous une autre marque ?
Une réponse positive ne suffit pas toujours à elle seule, mais plusieurs réponses positives forment un signal fort. Il faut alors comparer la version initiale et la version modifiée fonction par fonction. Une matrice simple peut associer à chaque évolution sa finalité, ses nouveaux actifs exposés, ses dépendances, ses vulnérabilités possibles, ses mesures de réduction et la personne qui autorise la diffusion.
Les exemples les plus sensibles sont fréquents dans les projets ordinaires. Une entreprise achète un logiciel étranger puis l’adapte sous sa marque. Un intégrateur ajoute un connecteur bancaire à un ERP. Un distributeur installe un accès distant permanent pour la maintenance. Un fabricant de machine connectée remplace le composant de communication par une bibliothèque open source. Une plateforme transforme un outil interne en application proposée à ses clients. Dans chacun de ces cas, le contrat commercial peut appeler l’opération « paramétrage » ou « personnalisation » sans que cette étiquette tranche la qualification réglementaire.
Le portail officiel de la Commission sur le Cyber Resilience Act, actualisé le 27 juillet 2026, renvoie désormais vers des orientations pratiques destinées aux fabricants, développeurs et entreprises de toute taille. En France, l’ANSSI rappelle le calendrier progressif du CRA : les notifications relatives aux vulnérabilités activement exploitées et aux incidents graves commencent le 11 septembre 2026, tandis que la conformité générale des produits mis sur le marché est attendue en décembre 2027. L’entreprise doit donc séparer le calendrier de notification du calendrier complet de conformité.
La date de la version est décisive. Il faut conserver le journal de versions, le dépôt de code, les demandes de changement, les résultats de tests, les décisions d’architecture et la preuve de la date de mise à disposition. Une capture d’écran isolée ou une facture générale ne permet pas de reconstruire la portée technique d’une évolution. Le dossier doit montrer l’état avant et après, la raison du changement et son incidence sur la cybersécurité.
Cette discipline rejoint le droit français des contrats. L’article 1112-1 du Code civil, vérifié dans sa version en vigueur, impose notamment que : « Celle des parties qui connaît une information dont l’importance est déterminante pour le consentement de l’autre doit l’en informer dès lors que, légitimement, cette dernière ignore cette information ou fait confiance à son cocontractant. » La qualification CRA, la durée de support, la dépendance à un composant et l’impossibilité de conserver l’évaluation d’origine peuvent devenir des informations déterminantes lors de la vente ou de l’intégration.
La Cour de cassation a précisé la portée de ce devoir dans un arrêt de la chambre commerciale du 14 mai 2025, pourvoi n° 23-17.948, publié au Bulletin : « Il résulte de l’article 1112-1 du code civil que le devoir d’information précontractuelle ne porte que sur les informations qui ont un lien direct et nécessaire avec le contenu du contrat ou la qualité des parties, et dont l’importance est déterminante pour le consentement de l’autre partie. » L’entreprise qui invoque un défaut d’information doit donc établir le caractère déterminant de l’information cyber. Le cahier des charges, les courriels de négociation et le procès-verbal de validation doivent rendre ce caractère visible.
B. Importateur, distributeur, intégrateur ou client : qui devient fabricant après la modification ?
Le règlement ne réserve pas le statut de fabricant au concepteur historique. L’importateur ou le distributeur est traité comme un fabricant lorsqu’il met le produit sur le marché sous son propre nom ou sa propre marque, ou lorsqu’il apporte une modification substantielle à un produit déjà mis sur le marché. Une autre personne physique ou morale qui réalise une modification substantielle puis remet le produit à disposition sur le marché peut également être considérée comme fabricant.
Trois éléments doivent être réunis et distingués. Premièrement, qui apporte ou fait apporter la modification ? Deuxièmement, la modification est-elle substantielle au regard de la destination, des fonctions et du risque ? Troisièmement, qui remet le produit modifié à disposition sur le marché dans une activité commerciale ? L’entreprise qui finance, spécifie et diffuse l’évolution peut être exposée même si le développement est matériellement sous-traité.
Un intégrateur n’est donc pas automatiquement fabricant. S’il installe le produit conformément aux instructions, sans modifier ses propriétés ni sa destination, son rôle peut rester celui d’un prestataire ou d’un distributeur. En revanche, s’il conçoit une fonction nouvelle puis livre la solution transformée à plusieurs clients, le risque de requalification augmente. Le distributeur en marque blanche se trouve dans une situation encore plus nette lorsque son nom ou sa marque apparaît sur le produit.
Le client final qui modifie un outil pour ses besoins purement internes n’est pas nécessairement dans la même situation que celui qui met la version modifiée à disposition d’autres entités, filiales, franchisés ou clients. La notion de marché doit être examinée avec soin : la fourniture peut être onéreuse ou gratuite dès lors qu’elle intervient dans une activité commerciale. Une licence offerte avec une machine, un logiciel inclus dans un abonnement ou une application mise à disposition comme accessoire d’un service peuvent donc entrer dans l’analyse.
Le cas de l’open source demande une vigilance particulière. Le logiciel libre non fourni dans une activité commerciale bénéficie d’un traitement spécifique. Mais l’entreprise qui intègre un composant open source dans son produit commercial ne transfère pas sa responsabilité à la communauté qui a publié le code. Elle doit exercer la diligence requise sur le composant, suivre les vulnérabilités, documenter la version et organiser les mises à jour. Le régime allégé des intendants de logiciels ouverts ne devient pas une exonération générale pour l’intégrateur commercial.
La chaîne de valeur doit être représentée dans un tableau de responsabilités : éditeur d’origine, mainteneur open source, intégrateur, hébergeur, fabricant du matériel, importateur, distributeur et détenteur de la marque. Pour chacun, le dossier identifie les tâches, les accès au code, le pouvoir de décision, la surveillance des vulnérabilités, la notification, le support, la conservation des preuves et le financement des correctifs.
Le contrat reste central, sans pouvoir neutraliser les obligations réglementaires. L’article 1103 du Code civil énonce mot pour mot : « Les contrats légalement formés tiennent lieu de loi à ceux qui les ont faits. » Les engagements de support, de conformité, d’audit et de coopération sont donc opposables entre les parties. L’article 1104 du Code civil ajoute : « Les contrats doivent être négociés, formés et exécutés de bonne foi. Cette disposition est d’ordre public. » Une partie ne peut dissimuler une modification qui change la charge de conformité puis opposer au cocontractant une clause vague.
Le contrat devrait identifier le responsable de chaque version, imposer une procédure d’autorisation des changements et prévoir une alerte lorsque l’évolution risque d’être substantielle. Il devrait encore déterminer qui maintient l’analyse de risques, qui prépare la documentation technique, qui réalise les tests, qui dialogue avec l’organisme d’évaluation et qui notifie les vulnérabilités ou incidents. Les délais de réponse doivent être compatibles avec les délais réglementaires, ce qui exclut une clause de coopération « dans les meilleurs délais » sans durée chiffrée.
Il faut aussi traiter les coûts. Une évolution demandée par le client peut nécessiter une nouvelle évaluation, un audit, une documentation complémentaire, une nomenclature logicielle, une surveillance accrue et une période de support différente. Le devis doit distinguer ces postes. À défaut, le différend portera sur la question de savoir si la conformité était comprise dans le prix initial ou constituait une prestation supplémentaire.
L’article 1602 du Code civil protège l’acheteur contre l’ambiguïté : « Le vendeur est tenu d’expliquer clairement ce à quoi il s’oblige. Tout pacte obscur ou ambigu s’interprète contre le vendeur. » Pour un produit numérique modifié, les expressions « standard », « conforme », « sécurisé », « maintenance incluse » ou « compatible CRA » doivent être définies par des livrables vérifiables, des tests, une période et un périmètre.
Une décision récente illustre l’enjeu de la preuve. Dans un arrêt de la cour d’appel de Rennes du 10 juillet 2026, n° 21/01039, relatif à la vente, l’installation et au paramétrage d’un logiciel, la cour retient notamment : « La société Sygespro est cependant responsable à l’égard de son client des défauts du système qu’elle a proposé et mis en place, peu important qu’il s’agisse de recommandations du tiers fournisseur. » Le fait d’avoir suivi la recommandation d’un éditeur tiers ne suffit donc pas toujours à écarter la responsabilité contractuelle de l’intégrateur envers son client.
Avant toute diffusion d’une version modifiée, le dirigeant doit pouvoir répondre par écrit à cinq questions : quel produit est mis à disposition, sous quel nom, avec quelle destination, par quelle personne et avec quelle preuve de conformité ? Si l’une des réponses manque, la mise sur le marché doit être suspendue le temps de compléter le dossier.
II. Cyber Resilience Act : quelles preuves préparer et quels recours en cas de logiciel non conforme ?
A. Quelle checklist appliquer avant de diffuser la version modifiée ?
La première pièce est une fiche de qualification du produit. Elle décrit le matériel ou le logiciel, les versions, l’utilisation prévue, les utilisateurs, les environnements compatibles, les interfaces, les composants tiers et les données traitées. Elle indique aussi les exclusions sectorielles éventuellement examinées. Cette fiche évite qu’un projet soit qualifié seulement à partir de son nom commercial.
La deuxième pièce est un registre des modifications. Chaque ligne précise la demande, l’auteur, la date, la version concernée, le code ou le composant affecté, la fonction ajoutée ou retirée, le risque cyber créé ou réduit, les tests réalisés et la décision finale. Une colonne doit répondre explicitement à la question « modification substantielle : oui, non ou analyse complémentaire ». La conclusion est motivée et validée par une personne identifiée.
La troisième pièce est l’analyse de risques mise à jour. Elle ne se limite pas à un test d’intrusion final. Elle couvre les actifs, les menaces, les dépendances, les scénarios d’abus, les accès, les secrets, les communications, les mises à jour, la journalisation, le traitement des vulnérabilités et la fin de support. Si la version ajoute une API ou un accès distant, l’analyse doit montrer comment les risques d’authentification, d’autorisation, d’injection, d’exposition de données et d’indisponibilité ont été traités.
La quatrième pièce est la preuve de recette. Le procès-verbal doit reprendre les exigences contractuelles et de sécurité, avec pour chacune un résultat, une anomalie, une réserve ou une validation. Une mise en production sans recette contradictoire affaiblit la preuve de la conformité comme celle de la non-conformité. La cour d’appel de Rennes l’a relevé dans l’affaire du 10 juillet 2026 : l’absence de recette ne permettait pas de s’assurer que l’installation fonctionnait complètement conformément aux besoins définis.
La cinquième pièce est le dossier de dépendances. L’entreprise inventorie les bibliothèques, composants open source, versions, licences, auteurs ou fournisseurs, vulnérabilités connues et modes de mise à jour. Elle prévoit un mécanisme d’alerte lorsqu’un composant devient vulnérable ou n’est plus maintenu. Une dépendance incluse sans version verrouillée ni responsable de suivi transforme rapidement un correctif ponctuel en risque durable.
La sixième pièce est le plan de support. Il indique la durée, les versions prises en charge, les canaux d’alerte, les délais de qualification, les conditions de fourniture des correctifs et les règles de migration. Il distingue la correction de sécurité mineure, l’évolution fonctionnelle et la modification substantielle. Le client doit savoir si une ancienne version reste supportée, si la migration est gratuite et si elle impose du matériel nouveau.
La septième pièce est la procédure de notification. À compter du 11 septembre 2026, le CRA impose aux fabricants concernés de déclarer les vulnérabilités activement exploitées et les incidents graves affectant la sécurité du produit via la plateforme prévue, avec transmission au CSIRT coordonnateur. Pour la France, l’ANSSI indique que le CERT-FR assume ce rôle. La procédure interne doit désigner le décideur, l’équipe technique, le juriste, les informations nécessaires et la continuité pendant les week-ends et congés.
La huitième pièce est le contrat de chaîne. Les obligations de l’éditeur, de l’intégrateur, du mainteneur, de l’importateur et du distributeur doivent être cohérentes. Une clause de notification imposée au distributeur ne sert à rien si l’éditeur refuse de transmettre les éléments techniques. Une clause de garantie sans accès au code, sans service de sécurité et sans engagement du fournisseur en amont devient difficile à exécuter.
La neuvième pièce est l’attestation de décision de mise sur le marché. Elle contient la version, la date, le nom ou la marque, le territoire, la destination, les réserves, les signataires et les documents examinés. Elle établit qui a assumé la décision de diffuser le produit modifié. Les preuves doivent être horodatées et conservées dans un espace dont les droits d’accès et les sauvegardes sont maîtrisés.
Cette checklist ne remplace pas l’analyse adaptée au produit. Elle crée un socle probatoire. Lorsqu’un litige survient, la chronologie compte autant que la qualité technique : date de découverte, date d’alerte, décision de correction, version livrée, utilisateurs informés et réponse du fournisseur.
La qualité de l’étude des besoins est également déterminante. Dans un arrêt de la cour d’appel de Rennes du 3 février 2026, n° 24/05422, relatif à l’intégration d’une solution Odoo, la cour relève : « Il ajoute qu’aucun audit réel, aucune analyse détaillée n’ont été réalisés avant la vente ou au début du projet. » Elle retient aussi : « La société Apik a gravement manqué à son obligation de fournir un produit complet, stable et adapté aux besoins de son client. » La qualification CRA ne dispense donc jamais de définir précisément le besoin fonctionnel et de démontrer l’adaptation du produit.
Pour les entreprises de Paris et d’Île-de-France, la préparation du dossier doit intégrer les intervenants locaux utiles : équipe informatique, direction juridique, assureur cyber, prestataire de réponse à incident, commissaire de justice pour les constats et conseil capable d’agir devant le tribunal compétent. Un constat rapide du comportement de la version, des messages d’erreur, des journaux et de la documentation peut préserver une preuve avant qu’une mise à jour ne l’efface.
B. Que faire si le fournisseur refuse de corriger, d’informer ou d’assumer la conformité ?
La première action est de préserver les preuves sans aggraver l’incident. Il faut isoler les données utiles, conserver les journaux, exporter les tickets, figer les versions, sauvegarder les échanges et identifier les utilisateurs affectés. L’entreprise évite de modifier le système de façon irréversible avant d’avoir documenté l’état litigieux, sauf mesure urgente nécessaire à la sécurité.
La deuxième action est la notification contractuelle. La mise en demeure décrit le produit, la version, la modification, la non-conformité ou le risque, les stipulations violées, les mesures demandées et le délai. Elle exige la transmission du dossier technique disponible, des résultats de tests, de la liste des composants, de la politique de support et des informations nécessaires à toute notification réglementaire. Le courrier doit rester précis : une accusation générale de « défaut de cybersécurité » est moins efficace qu’une liste d’écarts vérifiables.
La troisième action est de choisir le remède adapté. L’article 1217 du Code civil prévoit : « La partie envers laquelle l’engagement n’a pas été exécuté, ou l’a été imparfaitement, peut : – refuser d’exécuter ou suspendre l’exécution de sa propre obligation ; – poursuivre l’exécution forcée en nature de l’obligation ; – obtenir une réduction du prix ; – provoquer la résolution du contrat ; – demander réparation des conséquences de l’inexécution. » Le même article autorise le cumul des sanctions compatibles et l’ajout de dommages-intérêts.
La suspension du paiement ne doit pas être improvisée. Il faut vérifier la gravité du manquement, le lien avec la prestation facturée, les clauses de paiement et les conséquences opérationnelles. L’exécution forcée peut être pertinente si le correctif est réalisable et si le fournisseur dispose seul des accès. La réduction du prix répond à une prestation imparfaite mais utilisable. La résolution devient envisageable si le produit ne peut atteindre sa finalité ou si le manquement est suffisamment grave.
L’article 1231-1 du Code civil énonce : « Le débiteur est condamné, s’il y a lieu, au paiement de dommages et intérêts soit à raison de l’inexécution de l’obligation, soit à raison du retard dans l’exécution, s’il ne justifie pas que l’exécution a été empêchée par la force majeure. » L’entreprise doit néanmoins démontrer son préjudice et le lien de causalité : frais d’audit, solution de remplacement, mobilisation interne, interruption, perte de données, perte de marge ou atteinte commerciale doivent être chiffrés et justifiés.
Lorsque le contrat porte sur la vente d’un produit affecté d’un défaut caché, l’article 1641 du Code civil dispose : « Le vendeur est tenu de la garantie à raison des défauts cachés de la chose vendue qui la rendent impropre à l’usage auquel on la destine, ou qui diminuent tellement cet usage que l’acheteur ne l’aurait pas acquise, ou n’en aurait donné qu’un moindre prix, s’il les avait connus. » Le régime applicable dépend de la nature du contrat, du défaut, de son antériorité et des qualités des parties.
Si la garantie des vices cachés est mobilisable, l’article 1644 du Code civil prévoit mot pour mot : « Dans le cas des articles 1641 et 1643 , l’acheteur a le choix de rendre la chose et de se faire restituer le prix, ou de garder la chose et de se faire rendre une partie du prix. » Le choix de l’action doit être coordonné avec les demandes contractuelles pour éviter des fondements incompatibles ou un chiffrage incohérent.
La quatrième action peut être une expertise amiable contradictoire. Sa mission doit couvrir la version, la modification, les exigences contractuelles, les vulnérabilités, la portée des tests, la possibilité de correction, les coûts et les pertes. Chaque partie reçoit les pièces et peut répondre. Si l’urgence, le risque d’altération ou le refus du fournisseur l’exige, une mesure d’instruction avant procès peut être envisagée pour préserver ou établir la preuve.
La cinquième action est la continuité. Le contentieux ne doit pas empêcher la réduction du risque. L’entreprise prépare une solution de repli, limite les accès, corrige les secrets exposés, surveille les indicateurs, informe les personnes nécessaires et vérifie les obligations envers ses propres clients. Toute intervention est journalisée afin que la défense adverse ne puisse prétendre que le demandeur a lui-même créé le défaut.
La sixième action est l’examen des clauses de responsabilité et d’assurance. Les plafonds, exclusions, franchises et procédures de déclaration doivent être analysés immédiatement. Une déclaration tardive à l’assureur cyber ou responsabilité professionnelle peut compliquer la garantie. La demande indemnitaire doit distinguer les coûts de correction, la restitution du prix, la perte d’exploitation et les dommages causés à des tiers.
Le meilleur moment pour sécuriser la responsabilité reste avant la diffusion. Un avenant signé après la découverte d’une vulnérabilité peut régler la correction et la coopération, mais il ne reconstitue pas les preuves manquantes ni n’efface les obligations déjà nées. L’entreprise qui prend le contrôle d’une version modifiée doit donc obtenir le code, la documentation, les tests, les droits nécessaires et la coopération du fournisseur avant la mise sur le marché.
Conclusion
Une modification substantielle au sens du Cyber Resilience Act ne se mesure ni au nombre de lignes de code ni au nom donné par le contrat. L’analyse porte sur la destination du produit, ses fonctions, son niveau de risque, la validité de la conformité initiale et sa remise à disposition sur le marché. L’importateur, le distributeur, l’intégrateur ou une autre entreprise peut devenir fabricant lorsqu’il transforme substantiellement le produit puis le diffuse, en particulier sous sa marque.
Le réflexe sûr consiste à qualifier la version avant sa diffusion, documenter le changement, mettre à jour l’analyse de risques, organiser la recette et répartir par contrat la conformité, le support et les notifications. Si le fournisseur refuse d’agir, les preuves techniques et contractuelles déterminent le choix entre correction, réduction du prix, résolution et indemnisation. Le calendrier rend cette préparation urgente : les obligations de signalement commencent le 11 septembre 2026, avant l’application générale de la conformité des produits en décembre 2027.
Besoin d’un avis rapide sur votre dossier.
Obtenez une consultation téléphonique sous 48 heures avec un avocat du cabinet. Nous examinons la qualification du produit, les contrats, les preuves techniques et les recours envisageables.
Appelez le cabinet au 06 46 60 58 22 ou utilisez le formulaire de contact de Kohen Avocats. Pour un dossier à Paris ou en Île-de-France, préparez le contrat, les cahiers des charges, le journal des versions, les tickets, les rapports de test et les échanges avec l’éditeur ou l’intégrateur.
Pour replacer ce risque dans la stratégie globale de l’entreprise, consultez également notre page consacrée au droit des affaires. Sur la première échéance du CRA, notre analyse du signalement d’une faille exploitée sous 24 heures complète ce guide.
Transmettez les pièces de votre dossier au cabinet. Maître Reda KOHEN vous répond personnellement sous 24 heures avec une première analyse stratégique.