ActuDroit (@actudroit.skyfleet.blue)

La nouvelle directive sur les produits défectueux : vers une appréciation dynamique de la défectuosité des systèmes d’IA et des produits numériques Zoran Milic/AdobeStock La nouvelle directive n° 2024/2853, publiée au JOUE le 18 novembre 2024, est sur le point de faire entrer le régime de la responsabilité des produits défectueux dans une nouvelle ère. La démultiplication des produits logiciels, suivie de l’irruption des systèmes d’intelligence artificielle, capables d’évoluer de manière autonome et d’interagir dans un environnement numérique en proie aux menaces de cybersécurité, bouleversent les fondements du droit de la responsabilité civile. Cette nouvelle directive intègre les spécificités de ces technologies dans le droit commun des produits défectueux. Leurs singularités conduisent à faire évoluer ce régime vers une appréciation dynamique du risque, en redessinant les causes classiques d’exonération et en adaptant la temporalité juridique et le régime probatoire à la complexité de ces produits numériques. L’enjeu consiste à concilier l’innovation avec la protection des victimes, tout en préservant la compétitivité des acteurs européens. La responsabilité des systèmes d’intelligence artificielle (IA) devait initialement faire l’objet d’un encadrement spécifique par un règlement propre, distinct du régime applicable aux produits défectueux. Toutefois, faute de consensus politique 1 et en raison d’un lobbying actif des géants de la tech, la Commission européenne a annoncé, en février 2025, le retrait de sa proposition de directive relative à la responsabilité en matière d’IA, laissant le soin à la directive n° 2024/2853 d’en assurer seule la régulation. Si le corps du texte de la directive ne mentionne pas expressément les « systèmes d’IA », ces derniers sont néanmoins visés par les considérants et inclus dans son champ d’application à travers la définition large de « produit » posée à l’article 4, paragraphe 1, laquelle englobe les logiciels ainsi que les composants intégrés dans un produit logiciel 2 . Enfin, la singularité de ces systèmes est reprise dans l’appréciation de la défectuosité 3 . Dès lors, la responsabilité civile des développeurs d’IA sera amenée à être exclusivement régie, à l’échelle de l’Union, par le droit commun de la responsabilité du fait des produits défectueux. La présente étude explore le nouveau régime de responsabilité des produits numériques défectueux issu de la nouvelle directive, en particulier ceux intégrant des systèmes d’IA. Elle s’ouvre sur une analyse de la défectuosité envisagée comme une notion dynamique, susceptible d’émerger ou de se reconfigurer au fil de l’évolution du produit de manière autonome ou contrôlée à distance par le fabricant (I). Cette approche conduit à reconsidérer les causes classiques d’exonération ; dès lors que le produit reste dans la sphère de contrôle technique du fabricant, ni la postériorité du défaut ni le risque de développement ne conservent leur efficacité lorsqu’un défaut apparaît ou devient scientifiquement décelable lorsqu’il est sous le contrôle du fabricant (II). L’étude se poursuit par un examen du délai de forclusion, à l’aune de son nouveau point de départ au travers de la notion de « modification substantielle » (III). Elle s’achève sur le déplacement opéré du risque probatoire, au moyen des nouveaux outils procéduraux et techniques consacrés par la directive Produits et le règlement IA (IV). I – L’appréciation dynamique de la défectuosité L’appréciation dynamique de la défectuosité requiert de saisir simultanément l’évolution intrinsèque du produit, génératrice de risques nouveaux (A), et l’incidence d’un environnement numérique en perpétuelle mutation, source exogène de défauts (B). A – L’évolution défectueuse du produit générant de nouveaux défauts L’appréciation du défaut oscille entre les risques engendrés par l’évolution pilotée par le fabricant (1) et ceux que fait naître l’autoapprentissage autonome du produit (2). 1 – Évolution sous le contrôle du fabricant 1. Une défectuosité pos tc ommercialisation . L’appréciation de la défectuosité d’un produit, longtemps cantonnée à l’instant figé de la mise sur le marché ou mise en service, s’inscrit désormais pour les produits numériques dans une logique résolument dynamique 4 . Conformément au point e) de l’article 7 de la nouvelle directive, le « moment pertinent » ne se limite plus à la date de commercialisation tant que le fabricant conserve le contrôle technique de son bien, la sécurité doit être réévaluée jusqu’à la sortie effective de cette sphère d’influence. Ce déplacement du curseur temporel rappelle la philosophie d’autres règlements européens, notamment celui sur les dispositifs médicaux 5 ou encore le Cyber-Résilience Act (CRA) sur les services numériques, lequel impose une surveillance continue tout au long du cycle de vie. 2. Notion de « contrôle du fabricant » . La directive emploie expressément l’expression « contrôle du fabricant » (art. 4, pt 5). Cette notion traduit un contrôle principalement technique pouvant être réalisé par le fabricant ou par un tiers autorisé. Il se matérialise par la faculté de réaliser des mises à jour, mises à niveau correctives ou patchs de sécurité, d’accéder aux données télémétriques, de fermer ou rouvrir des services connexes connectés. Aussi longtemps que cette faculté subsiste, le fabricant est responsable des défauts qui apparaissent. Ignorer une vulnérabilité ou différer un patch peut désormais constituer une cause de défectuosité. La conformité d’un produit devient un processus itératif plutôt qu’un certificat statique. La sécurité se mesure donc à la capacité du producteur à maintenir, réviser et documenter sans discontinuer les performances du produit, au rythme de l’évolution technique et des vulnérabilités nouvellement découvertes, jusqu’à ce qu’il en perde la maîtrise effective lorsque le produit quitte son contrôle. 2 – Évolution autonome du produit par auto-reprogrammation 1. Un défaut propre aux systèmes IA. Le système d’IA n’est mentionné qu’indirectement dans le corps du texte au travers de l’appréciation des défauts faisant référence à une singularité fonctionnelle de ces systèmes. L’article 7, paragraphe 2, c) 6 , de la nouvelle directive impose de tenir compte « de l’effet sur le produit de toute capacité à poursuivre son apprentissage ou à acquérir de nouvelles caractéristiques après sa mise sur le marché ou sa mise en service ». Cette disposition vise expressément les systèmes d’IA dits autoadaptatifs, soit des systèmes dont le comportement évolue dans le temps par un processus d’apprentissage continu. À l’instar du règlement européen sur l’IA 7 , la nouvelle directive intègre l’idée que l’autonomie évolutive du système doit être considérée dans l’évaluation du risque 8 . 2. Un comportement inattendu. Le considérant 32 complète cette logique en invoquant la « confiance légitime dans le fait que les logiciels et algorithmes sous-jacents d’un produit sont conçus de manière à prévenir tout comportement dangereux ». Cette exigence inclut les comportements inattendus, nouvelle catégorie juridique propre à l’IA, qui renvoie au problème d’alignement bien connu en sciences informatiques : le décalage entre les objectifs assignés et ceux réellement optimisés par le système 9 . Il en résulte qu’un système d’IA sera juridiquement qualifié de défectueux dès lors que son algorithme d’apprentissage autonome lui permet d’évoluer, sans intervention humaine, vers une configuration susceptible de générer un comportement techniquement cohérent, mais dangereux, révélant une absence de maîtrise suffisante de son évolution par le fabricant. B – L’environnement numérique dynamique comme source exogène de défectuosité L’appréciation du défaut doit aussi intégrer les vulnérabilités nées du cyber-environnement fluctuant (1) et celles issues de l’interconnexion croissante des technologies en réseau (2). 1 – La cyberinsécurité d’un écosystème numérique : les menaces sécuritaires pesant sur l’environnement cyber 1. Un risque émanant de l ’ environnement numérique. Dans l’écosystème numérique, le risque ne résulte pas uniquement de l’évolution interne du produit, mais principalement de la transformation constante de l’environnement de cybersécurité dans lequel il opère. La directive n° 2024/2853 en prend acte en liant la défectuosité non seulement à la structure du produit, mais également à l’absence de réponse du fabricant face à l’émergence de nouvelles menaces. 2. La gouvernance des vulnérabilités. L’article 7, f), exige ainsi de prendre en compte « les exigences pertinentes de cybersécurité », ce qui confère à la mise à jour logicielle, non plus un caractère facultatif, mais une portée normative en matière de diligence. Bien que le considérant 51 de la directive n ’ impose formellement aucune obligation générale de mise à jour , la directive consacre une logique analogue où la sécurité devient un processus actif, structuré, révisable 10 . La gouvernance des vulnérabilités devient ainsi une exigence implicite. L’inertie logicielle face aux attaques adaptatives n’est plus excusable. Chaque vulnérabilité non traitée, dès lors qu’elle aurait pu être corrigée, devient le signe d’une défectuosité 11 , née du défaut de surveillance du risque évolutif. 2 – L’interconnexion comme facteur de risque contextuel 1. Des risques interconnectés. Dans un environnement numérique interconnecté, un produit n’évolue jamais seul 12 . L’article 7, paragraphe 2, d), de la directive n° 2024/2853 élargit l’analyse de la défectuosité en imposant de prendre en compte « l’effet raisonnablement prévisible sur le produit d’autres produits (…) notamment au moyen d’interconnexion ». Cette disposition reconnaît que l’évaluation de la sécurité ne peut donc se limiter aux seules caractéristiques internes du produit, mais doit intégrer les effets prévisibles de son interaction avec d’autres technologies, au travers d’une interconnexion avec un autre produit ou avec et au travers d’un service connexe. 2. Intégration et interconnexion sous le contrôle du fabricant. Le produit connecté doit être considéré comme intégrant des services numériques connexes 13 dès lors qu’il ne serait pas en mesure d’assurer une ou plusieurs de ses fonctions s’il en était dépourvu 14 . Le fabricant du produit dans lequel des services connexes sont implémentés sous son contrôle est responsable de leur défectuosité 15 . Tel est le cas lorsqu’ils sont fournis ou interconnectés avec le produit initial. Mais également lorsque le fabricant aura fourni ou interconnecté le service connexe à son produit ou aura autorisé un tiers à réaliser cette opération 16 . 3. Un service connexe assimilé à un produit composite. En assimilant ce service connexe à une composante du produit, la directive étend la responsabilité du fabricant du produit final à l’ensemble des services connexes défectueux intégrés ou interconnectés sous son contrôle 17 . Dans la lignée de la directive de 1985 18 , le fabricant du produit intégrant et le fournisseur du produit composite soit du service connexe défectueux seront solidairement responsables 19 . Même lorsqu’il est prouvé que la défectuosité émane du composant, le fabricant du produit l’ayant intégré ne pourra pas s’exonérer par le fait du tiers. Cependant, le fabricant ne sera pas responsable si l’intégration et la connexion d’un service ou composant numérique ont été rendues techniquement possibles par le fabricant mais qu’il n’a pas consenti à ces intégrations et connexions réalisées en dehors de son contrôle. On ne pourra rendre responsable le fabricant d’un système d’exploitation à raison du fait que l’utilisateur a installé un logiciel défectueux fourni par un tiers. La défectuosité devient ainsi contextuelle, dépendant non seulement du produit lui-même, mais aussi de l’écosystème technique dans lequel il s’insère. II – Produits défectueux et IA : l’adaptation des causes classiques d’exonération La nouvelle directive sur les produits défectueux a intégré le caractère évolutif, révisable et interconnecté des systèmes numériques et a étendu la période pendant laquelle la défectuosité d’un produit peut être retenue. Ce changement structurel redéfinit la portée de la responsabilité du fabricant, en restreignant sensiblement le recours aux causes classiques d’exonération, telles que le défaut postérieur à la mise sur le marché (A) ou le risque de développement (B). A – L’impact de l’appréciation dynamique de l’exonération à raison de la postériorité du défaut L’approche dynamique de la défectuosité rend inopérante l’exonération tirée de la postériorité du défaut, que celui-ci apparaisse alors que le produit reste sous la maîtrise du fabricant (1) ou qu’il accompagne la mise en service d’un produit substantiellement modifié (2). 1 – L’impossible exonération à raison de la présence d’un défaut sur un produit sous le contrôle du fabricant 1 . La postériorité du défaut à la mise en circulation au sens de la directive de 1985 . Sous l’empire de la directive n° 85/374/CEE, la défectuosité d’un produit devait être appréciée exclusivement au moment de sa mise en circulation. Cette conception, adaptée aux produits statiques, reposait sur l’idée que, une fois le produit commercialisé, le fabricant perdait toute maîtrise dessus. L’article 7, point b), permettait ainsi au producteur de s’exonérer s’il démontrait que le défaut n’existait pas au moment de la mise en circulation, bien qu’il apparût ultérieurement. 2 . La postério rité du défaut au contrôle du fabricant au sens de la nouvelle directive. Cette cause d’exonération prévue à l’article 11, paragraphe 1, point c), devient inopérante pour les produits numériques sous le contrôle du fabricant, en particulier les systèmes d’IA ou logiciels. Pour ces derniers, la défectuosité ne peut plus être évaluée de manière purement statique, à la seule date de sa mise en service. La directive actuelle adopte une approche dynamique : l’article 11, paragraphe 2, point c), exclut toute exonération à raison d’un défaut apparu après la mise en service, « tant qu’elle résulte d’un élément sous le contrôle du fabricant ». Cette disposition élargit donc la période au cours de laquelle le fabricant doit répondre de la défectuosité. 3 . Un produit sous le contrôle du fabricant. L’article 4, point 5, de la directive interprété à l’aune du considérant 19 précise qu’un produit est considéré comme étant sous le contrôle du fabricant lorsque ce dernier conserve, directement ou par l’intermédiaire d’un tiers, la capacité d’en assurer les mises à jour. L’article 11, paragraphe 2, identifie plusieurs éléments susceptibles de provoquer une défectuosité dans ce cadre : un service connexe, des logiciels, y compris les mises à jour ou mises à niveau logicielles, l’absence de mises à jour nécessaires au maintien de la sécurité, une modification substantielle du produit. Dans les hypothèses évoquées aux points a) 20 , b) et c), l’apparition du défaut a lieu durant la période où le produit était sous le contrôle du fabricant et résulte d’une opération de contrôle défectueuse. Cette intervention peut être active, tel est le cas de l’intégration d’un service connexe défaillant (point a), de l’incorporation d’un logiciel ou système d’IA source de défaut (point b) 21 ou encore d’une mise à jour ou mise à niveau logicielle vectrice d’une défectuosité. Elle peut se caractériser négativement par le point c) à raison de « l’absence d’une mise à jour » nécessaire pour garantir « le niveau de sécurité du produit ». De sorte que la non-réalisation de cette opération a créé une faille de sécurité ayant rendu le produit défectueux car vulnérable au risque de cybersécurité 22 . 2 – L’impossible exonération à raison de la présence du défaut d’un produit concomitant à sa mise en service 1 . La noti on de « modification substantielle » . Le point d) de l’article 11, paragraphe 2, emploie une terminologie générale, visant les défectuosités résultant d’une modification substantielle affectant un produit encore sous le contrôle de son fabricant. Cette notion est définie à l’article 4, point 18, de la directive comme une transformation postérieure à la mise sur le marché, altérant la performance, la finalité, ou la catégorie du produit, au-delà de l’évaluation initiale des risques. Cette notion englobe également les interventions qui modifient la nature du danger, font apparaître un risque inédit ou les aggravent. Elle inclut les modifications reconnues comme substantielles par les normes de l’Union ou le droit national. 2 . Les modes de modification substantielle. La modification substantielle d’un produit peut être : volontaire , lorsqu’un fabricant ou un tiers autorisé procède à une mise à jour améliorant notablement les performances du logiciel ; involontaire , lorsqu’une mise à jour introduit de manière non anticipée un nouveau risque ; autonome 23 , dans le cas des systèmes d’IA capables d’autoapprentissage 24 pouvant muter le système vers une forme défectueuse non anticipée. 3 . Une modification substantielle assimilable à la mise en service d ’ un nouveau produit. La portée du point d) de l’article 11, paragraphe 2, se distingue des cas évoqués aux autres points. Dans ces hypothèses, la défectuosité est fondée sur le fait qu’elle est certes apparue postérieurement à la mise en service mais durant la phase où le produit était sous le contrôle du fabricant. 4 . Un défaut concomitant à la mise en service du nouveau produit. La portée du point d) de l’article 11, paragraphe 2, se distingue des cas évoqués aux autres points. Dans l’hypothèse où la défectuosité résulte d’une modification substantielle, c’est une tout autre logique qui conduit à écarter cette cause d’exonération puisque la modification substantielle d’un produit correspond à la mise en service d’un nouveau produit 25 au sens de la directive 26 . Ainsi, lorsqu’une telle modification intervient, le produit initial (produit A) devient un produit distinct (produit B), mis en service alors qu’il est affecté par une défectuosité. Seul le nouveau produit est défectueux. L’exonération fondée sur le caractère postérieur du défaut à la mise sur le marché ne peut plus être invoquée, non pas parce que le défaut est apparu durant la phase ou le produit B était sous le contrôle du fabricant mais parce que l’apparition du défaut sur le produit B coïncide désormais avec la date de sa mise en service. B – L’impact de l’appréciation dynamique sur la cause d’exonération liée au risque de développement L’allongement de la période d’appréciation de la sécurité recompose l’exonération pour risque de développement. Il redéfinit le périmètre du défaut objectivement indécelable (1), instaure une veille scientifique à la charge du fabricant (2) et répartit les risques selon la maîtrise effective du produit (3). 1 – L’émergence d’un risque objectivement indécelable en l’état des connaissances scientifiques et techniques 1 . L a nouvelle directive opère un basculement dynamique. L’article 7, paragraphe 2, point e), impose désormais d’évaluer la sécurité « tant que le fabricant conserve le contrôle du produit ». Couplée à l’article 11, paragraphe 2, cette extension fait quasiment disparaître l’exonération liée à la postériorité du défaut (art. 11, § 1, c)) pour les produits numériques. Dès lors, un éditeur de logiciel ou un concepteur de systèmes IA qui découvre un dysfonctionnement sur son produit après la mise sur le marché mais avant qu’il ne quitte son contrôle ne peut plus se retrancher derrière cette exonération. Il ne lui reste qu’une seule porte de sortie consistant à démontrer qu’il s’agit bien d’un risque de développement stricto sensu , c’est-à-dire d’un défaut objectivement indécelable, compte tenu de l’état des connaissances scientifiques et techniques durant la période où le produit était sous son contrôle. 2 . Une cause d ’ exonération supplétive. L’article 18 de la directive autorise les États à y déroger, dès lors que la dérogation est proportionnée, spécifique à certains produits et justifiée par des objectifs d’intérêt public. Les États peuvent ainsi maintenir des dispositions limitant cette exonération. Ceux souhaitant introduire de nouvelles exceptions devront consulter la Commission 27 . 2 – Une obligation de veille scientifique et technique L’article 11 de la nouvelle directive reprend l’exonération 28 pour risque de développement, mais l’article 7, paragraphe 2, rattache désormais l’appréciation de la défectuosité à toute la période où le produit demeure sous le contrôle du fabricant. 1 . État de l ’ art initial. Au jour de la mise en service, le producteur doit réaliser une évaluation des risques, soit documenter les connaissances scientifiques et techniques disponibles pour cartographier les risques décelables. 2 . Obligation continue de veille. Tant que le contrôle technique subsiste, le fabricant doit surveiller l’évolution des publications, normes et alertes de vulnérabilité susceptibles de révéler un défaut jusque-là inconnu. Cette obligation perdure jusqu’à la perte effective de contrôle. 3 . Nouvelle évaluation des risques. Pour chaque mise à jour/mise à niveau ou tout processus d’autoapprentissage pouvant constituer une modification substantielle (art. 4, 18 et 11, § 2, d, de la directive), le producteur doit alors répéter l’ état de l ’ art pour la nouvelle version. Pour les systèmes IA, cette exigence est prévue par l’article 40 du règlement IA 29 et toute modification substantielle impose une nouvelle évaluation des risques. En pratique, dès qu’une avancée scientifique rend un risque identifiable pendant la période de contrôle, le fabricant doit déployer les correctifs nécessaires. À défaut, l’exonération pour risque de développement lui sera refusée. 3 – La répartition des risques de développement 1 . U ne obligation de veille scientifique et technique à durée indéterminée. L’obligation de veille pesant sur le fabricant ne s’accompagne d’aucune durée prédéfinie. Sa portée dépend de la période pendant laquelle le produit demeure sous son contrôle. Cette indétermination découle à la fois de facteurs techniques et de facteurs externes, tels que les comportements de l’utilisateur ou les modalités de diffusion du logiciel. 2 . Un produit soustrait au contrôle du fabricant. Un produit cesse d’être sous le contrôle du fabricant lorsque ce dernier : ne dispose plus de la capacité d’en assurer les mises à jour ou à niveau ; publie son code en open source à des fins non commerciales ; transfère la licence d’exploitation à un autre opérateur. De même, l’utilisateur peut, dans certains cas, soustraire un produit au contrôle du fabricant lorsqu’il refuse les mises à jour nécessaires à la sécurité ou modifie substantiellement le logiciel sans autorisation. 3 . Les risques de développement d ’ un produit sous le contrôle du fabricant. Le fabricant demeure responsable des risques de développement que l’état des connaissances scientifiques et techniques aurait pu révéler lors de la mise sur le marché du produit et durant la période où il était sous son contrôle. Durant toute cette période, le fabricant est tenu de s’informer de l’évolution des connaissances susceptibles de relever l’existence d’un risque. Il ne pourra pas s’exonérer pour risque de développement. 4 . Les risques de développement d ’ un produit soustrait activement au contrôle du fabricant. Les risques de développement sont désormais répartis entre le fabricant et l’utilisateur lorsque ce dernier joue un rôle actif dans la modification substantielle de son produit. Si le produit a été modifié par l’utilisateur, le fabricant ne sera pas tenu responsable des risques de défectuosité que l’état des connaissances scientifiques et techniques pouvait identifier. Il est tenu d’assurer une veille scientifique des risques uniquement sur la version d’origine de son logiciel. 5 . Les risques de cybersécurité d ’ un produit s oustrait passivement au contrôle du fabricant . En cas de mise à jour ou mise à niveau logicielle proposée, l’ancienne version reste sur le marché aussi longtemps que l’ensemble des utilisateurs n’aura pas installé les mises à jour. La nouvelle version à jour coexiste avec l’ancienne version des utilisateurs n’ayant pas réalisé la mise à jour de sécurité. Or, l’article 13, paragraphe 10, CRA rappelle qu’un fabricant n’est tenu de réaliser les mises à jour de sécurité que sur la dernière version ou sous-version de son logiciel dès lors que la mise à jour est gratuite et installable sur le support produit initial sans coût supplémentaire 30 . 6 . Conséquences pratiques. Dans cette situation, seule la dernière version de son produit continuera à être sous son contrôle, de sorte qu’il ne sera pas responsable des risques de défectuosité qui apparaissent sur la version obsolète de son logiciel et qui causent un préjudice aux utilisateurs qui ont refusé la mise à jour de sécurité. Dans cette hypothèse, il pourra s’exonérer pour risque de développement, s’il prouve que l’état des connaissances scientifiques ne permettait pas de déceler l’existence d’un risque lors de la période durant laquelle la version obsolète et défectueuse de son logiciel était sous son contrôle, soit après sa mise en service et avant la publication de la mise jour de sécurité. Il pourra invoquer cette exonération alors même que les connaissances scientifiques et techniques permettaient de déceler l’existence du défaut plusieurs années avant qu’il cause un préjudice dès lors qu’il n’est devenu scientifiquement décelable que postérieurement à la dernière mise à jour proposée. 7 . Une répartition équilibrée des risques de développement . Le fabricant est responsable de la version qu’il contrôle, tandis que l’utilisateur qui modifie le produit ou encore qui refuse les mises à jour accepte, de fait, le risque lié à l’usage d’un produit qu’il a volontairement soustrait au contrôle du fabricant. III – L’impact de l’appréciation dynamique sur la forclusion de l’action Si le délai de prescription triennal à compter de la connaissance du dommage reste inchangé 31 par rapport au droit antérieur, la directive introduit en revanche une évolution notable concernant l’appréciation du délai de forclusion en introduisant une nouvelle cause d’interruption (A) se révélant parfois difficilement déterminable (B). A – La modification substantielle, cause d’un nouveau point du délai de forclusion 1. La durée du délai de forclusion maintenue. Dans la lignée de la directive de 1985, la nouvelle directive prévoit en son article 17 un délai de forclusion de 10 ans 32 , porté à 25 ans lorsque la défectuosité cause des lésions corporelles se consolidant tardivement. Ce délai constitue une limite extinctive à l’exercice des actions en responsabilité. Il commence à courir en principe à compter de la mise sur le marché ou de la mise en service du produit, sans égard au fait que le produit demeure ou non sous le contrôle du fabricant. Ce délai de forclusion interdit aux victimes d’engager la responsabilité du fabricant au-delà, sauf s’il a été interrompu par une action intentée avant son échéance 33 . Nous avons précédemment rappelé que la modification substantielle d’un produit est assimilée à la mise sur le marché ou à la mise en service d’un nouveau produit. Cette considération théorique a des implications pratiques significatives. L’article 17, point b), interprété à l’aune du considérant 58, prévoit qu’en cas de modification substantielle, un nouveau délai de forclusion de 10 ans commence à courir à partir de la date de mise sur le marché ou mise en service du produit modifié substantiellement. L’innovation majeure de la directive tient au fait que la modification substantielle défectueuse constitue le point de départ d’un nouveau délai de forclusion du produit issu de cette transformation. Dès lors, il est impératif de déterminer avec exactitude la date à laquelle la modification substantielle a eu lieu. 2. L a portée du nouveau délai de forclusion. Le fait que la modification substantielle constitue le point de départ d’un nouveau délai de forclusion ne doit pas être interprété comme une cause interruptive du délai de forclusion initial, lequel continue à courir pour les défauts émanant des parties qui n’ont pas été modifiées. À l’issue d’une opération de modification substantielle, le produit modifié coexiste avec le produit initial sur le marché, notamment parce que certains utilisateurs n’auront pas procédé aux mises à jour proposées par le fabricant. En effet, le produit A, n’ayant pas subi de transformation, reste entièrement soumis au délai de forclusion initial, tandis que le produit B, fruit d’une opération de modification substantielle, est soumis à un nouveau délai de forclusion pour les défauts affectant les parties qui ont été substantiellement modifiées. Le fabricant pourra échapper à ce nouveau délai de forclusion s’il prouve que la défectuosité résulte d’un élément qui n’a pas été substantiellement modifié alors même que le produit a fait l’objet d’une modification substantielle. Dès lors, la responsabilité du fabricant d’un produit substantiellement modifié sera encadrée par des délais de forclusion distincts. B – La datation de la nouvelle mise en service La modification substantielle comme nouveau point de départ du délai de forclusion. La modification substantielle conduit à la mise en service d’un nouveau produit qui constituera le point de départ du délai de forclusion encadrant la responsabilité du fabricant pour le produit modifié, selon l’article 17 de la directive 34 . Il devient primordial de dater la nouvelle mise en service. Le considérant 40 a pour objet de déterminer la datation de la nouvelle mise en service en considérant que cette dernière a eu lieu lors de la modification effective du produit sans égard au moyen par lequel la modification a été réalisée. Ce mode de détermination englobe l’ensemble des modifications substantielles qui ont été réalisées via une mise à jour ou une mise à niveau logicielle, ou en raison de l’apprentissage continu d’un système d’IA. En voulant conférer une portée générale à cette notion, la directive échoue à appréhender les différences entre les modifications substantielles autonomes (2) et celles réalisées par le fabricant (1). 1 – La modification substantielle réalisée par le fabricant 1 . Une définition proposée à la modification substantielle d ’ un logiciel. Le paragraphe 1 du point 18 de l’article 4 dispose que la transformation d’un produit doit être qualifiée de modification substantielle dès lors qu’elle est considérée comme substantielle au regard des règles de l’Union. À défaut d’une telle réglementation, c’est la définition générique du second paragraphe qui s’applique. La modification substantielle d’un logiciel est reprise au point 30 de l’article 3 du CRA 35 . La modification substantielle d’un produit intégrant des éléments numériques correspond à l’opération de postcommercialisation de transformation réalisée par une mise à jour ayant « une incidence sur la conformité du produit comportant des éléments numériques aux exigences essentielles de cybersécurité énoncées à l’annexe I, partie I », ou entraînant « une modification de l’utilisation prévue pour laquelle le produit comportant des éléments numériques a été évalué ». 2. Une méthode générique de datation incompatible avec le caractère facultatif des mises à jour. Le considérant 40 de la nouvelle directive fait courir le nouveau délai de forclusion du fabricant d’un produit substantiellement modifié, en caractérisant sa nouvelle mise en service à partir du moment où la modification a été effectivement réalisée 36 . Or, une telle approche ne doit pas être interprétée littéralement, dans la mesure où les mises à jour imposées sont prohibées par le règlement CRA 37 . Si l’ installation automatique des correctifs de sécurité doit être la configuration par défaut, le fabricant doit permettre à l’utilisateur de refuser ou encore de planifier la mise à jour. Une mise à jour ne peut se faire sans le consentement de l’utilisateur, même lorsqu’elle vise à protéger une faille de sécurité. Les modifications substantielles proposées seront effectuées à des dates distinctes par les utilisateurs qui pourront différer l’installation de la mise à jour, la planifier ou encore même la refuser, de sorte qu’ils continuent à utiliser la version précédente du produit logiciel. La date de la modification substantielle ne devra pas être la date de l’installation effectivement réalisée de la nouvelle version défectueuse, comme le suggère le considérant 40, mais devrait être la date à laquelle le fabricant a mis la version de mise à jour, modifiant substantiellement le produit, à la disposition de l’utilisateur en la rendant téléchargeable et installable. En matière de mise à jour logicielle, l’article 17 doit être interprété à l’aune de la définition de « modification substantielle » du point 30 de l’article 3 du CRA 38 . 3. Le produit non substantiellement modifié échappant à la responsabilité du fabricant. Étant donné qu’un utilisateur est en mesure de refuser l’installation de la mise à jour ou mise à niveau logicielle visant à corriger des failles de sécurité, le produit ne sera pas retiré du marché. En revanche, il sera considéré comme soustrait au contrôle du fabricant au sens du considérant 51, de sorte qu’il ne sera plus responsable des défauts apparaissant postérieurement à cette modification substantielle au sens du point c) de l’article 11 de la nouvelle directive et de l’article 13 du CRA 39 . 2 – La modification substantielle résultant de l’apprentissage continu d’un système d’IA L ’ a utoap prentissage d ’ une nouvelle fonctionnalité. Un exemple particulièrement éclairant est celui d’un modèle de langage de grande taille (LLM) déployé dans une interface conversationnelle publique, et doté de capacités d ’ apprentissage continu . Lorsqu’un tel système, en interagissant avec les utilisateurs, ajuste de manière autonome ses réponses, affine ses performances ou intègre de nouveaux schémas linguistiques sans supervision ni mise à jour logicielle formelle, il peut développer des fonctionnalités non prévues initialement. Notamment le fait pour un LLM de développer la capacité de simuler des émotions humaines, pouvant manipuler des utilisateurs dans un état de vulnérabilité psychologique en les isolant de leurs proches jusqu’à les inciter au suicide. Cette tragédie a quitté le champ de la science-fiction pour intégrer celui des faits divers, à l’image de la tragédie survenu le 23 octobre 2024 où un adolescent a été poussé au suicide par son chatbot 40 . La mère de la victime a introduit une action en responsabilité contre le développeur du système d’IA. La datation de la modification substantielle d ’ un système d ’ IA. La datation de la nouvelle mise en service à la date à laquelle la modification a été effectivement réalisée soulève en effet davantage de difficultés, lorsqu’elle est faite au moyen de l’apprentissage continu d’un système d’IA. Consciente des incertitudes liées à l’interprétation de cette notion, la commission s’est engagée, à l’article 96 41 du règlement sur l’IA, à adopter des lignes directrices pour en préciser les modalités de mise en œuvre pratique. Si la modification substantielle d’un système d’IA à haut risque fait l’objet d’une définition réglementaire spécifique (a), seule la définition générale de la nouvelle directive s’appliquera aux autres systèmes d’IA (b). a – La modification substantielle d’un système d’IA à haut risque 1 . La modification substantielle d ’ u n système d ’ IA à haut risque définie par le règlement IA . Pour appréhender la modification substantielle d’un système IA, nous pouvons nous référer à l’article 3 42 du règlement IA , à l’aune du considérant 128 dudit règlement 43 . Selon cet article, il s’agit d’une modification postcommercialisation ou post mise en service apportée sur un système d’IA qui n’a pas été initialement planifiée dans l’évaluation de sa conformité et qui conduit à l’inobservation des exigences de conformité réservées au système d’IA à haut risque. Cette définition existe mais n’est valable que pour les IA classées à haut risque 44 . Tel sera le cas des systèmes IA qualifiés de haut risque par le premier ou le second paragraphe de l’article 6 et mentionnés respectivement aux annexes 1 et 8 du règlement sur l’IA. Tel sera le cas de l’algorithme d’administration automatisée d’insuline, ou encore des logiciels de recrutement, de gestion de carrière ou de monitoring des salariés, ainsi que les systèmes pilotant la distribution d’eau ou d’électricité au titre de la gestion d’infrastructures critiques. 2. Les obligations renforcées des IA à haut risque facilitant la datation. 2.1 . É valuation initiale des risques. L’article 43 du règlement IA impose une évaluation complète des risques avant le déploiement du système d’IA à haut risque, qui devra être renouvelée à chaque modification substantielle. Cette évaluation des risques doit prendre en compte les risques engendrés par la version initiale de leur produit, mais également prédéterminer les risques qui émaneront des versions améliorées par le processus algorithmique d’autoapprentissage. Le considérant 128 du règlement IA rappelle que les modifications algorithmiques et l’amélioration automatique des performances d’un système IA résultant d’un processus d’autoapprentissage « ne devraient pas constituer une modification substantielle » dès lors que cette modification ne crée pas un risque nouveau à ceux qui ont été répertoriés lors de l’évaluation initiale des risques. 2.2 . Enregistrement automatique. Les systèmes d’IA classés à haut risque ont des obligations de traçabilité renforcées permettant de déterminer avec précision la date à laquelle a été réalisée la modification substantielle. L’article 12 45 du règlement IA impose à ces produits d’embarquer un système d’« enregistrement automatique des événements (journaux) tout au long de la durée de vie du système » dans l’optique « de garantir (…) l’enregistrement des événements pertinents pour (…) repérer les situations susceptibles (…) d’entraîner une modification substantielle ». 3 . Conclusion. Pour les systèmes d’IA classés « à haut risque », la combinaison de la directive n° 2024/2853 et du règlement IA offre une datation presque mécanique : la notion de « modification substantielle » (régl. IA, art. 3) déclenche une nouvelle évaluation des risques (art. 9) et la tenue de journaux d’événements obligatoires (art. 12), si bien que l’horodatage consigné dans ces logs permet de fixer avec précision la date de la modification et, corrélativement, le point de départ du nouveau délai de forclusion prévu par la directive produits défectueux . b – La modification substantielle d’un système d’IA à risque systémique ou modéré 1. La modification substantielle autonome d ’ un système IA conditionnée à la création d ’ un risque imprévu. La « modification substantielle » dont traite le règlement IA ne concerne que les systèmes déjà qualifiés de high – risk au sens de son article 6. Pour tous les autres modèles, il faut se référer à la définition générique fournie par l’article 4, paragraphe 18, de la nouvelle directive n° 2024/2853, dite directive produits défectueux . Celle-ci pose trois conditions cumulatives : i) la transformation intervient après la mise sur le marché ou la mise en service ; ii) elle change « la performance, la destination ou le type d’origine du produit » sans avoir été prévue dans l’évaluation des risques initiale ; iii) ce changement doit créer un nouveau danger, modifier la nature du risque ou en accroître le niveau. 2. Les modèles d ’ IA à usage général présentant un « risque systémique ». Cette catégorie, qui inclut les grands agents conversationnels en apprentissage continu, relève de l’article 55. Avant toute mise à disposition, le fournisseur doit « évaluer et atténuer les risques systémiques » (art. 55, § 1, b)) et consigner les résultats dans son dossier de conformité. Cette évaluation reste cependant plus souple que le « système de gestion des risques » exhaustif imposé aux IA high – risk par l’article 9 : aucune obligation n’exige de cartographier a priori l’ensemble des risques futurs de versions auto-apprenantes. Cependant, l’organisme de normalisation s’est engagé à publier à la fin de l’année 2025 les normes d’évaluation des risques qui auront une portée contraignante 46 . À l’inverse, les IA de risque limité ne font l’objet d’aucune analyse ex ante . Le chapitre IV se borne à des obligations de transparence (art. 50), sans démarche systématique d’évaluation. Cette absence crée une incertitude, puisque la qualification d’« absence de risque significatif » repose sur une évaluation initiale minimale, toute évolution algorithmique qui accroît le niveau de risque ou fait simplement naître un risque nouveau doit être regardée comme une « modification substantielle » dont la conséquence est de rouvrir le cycle de conformité. 3. L ’ épreuve de la traçabilité et la datation incertaine des modifications. Le problème se corse lorsqu’il s’agit de dater cette modification substantielle. L’obligation de logging automatique de l’article 12 est strictement réservée aux systèmes high – risk , afin de « permettre l’enregistrement des événements tout au long du cycle de vie ». Les modèles à risque systémique n’y sont pas soumis, ils doivent seulement « tenir un journal interne et notifier sans délai les incidents graves » (art. 55, § 1, c)). Aucune disposition n’impose l’horodatage exhaustif de chaque mise à jour. Quant aux IA de risque limité, le règlement demeure muet. Faute de trace automatisée et horodatée, il devient techniquement impossible de prouver avec certitude la date exacte à laquelle la modification substantielle est intervenue, ce qui complique la détermination du point de départ des délais de forclusion prévus par la directive produits défectueux . 4. Conclusion. Le moyen par lequel une modification substantielle est réalisée influe considérablement sur la date de la mise en service de la nouvelle version modifiée. On se doit de distinguer les modifications imposées, dont la mise en service a lieu dès son installation par le fabricant, des mises à jour proposées, qui ont lieu lorsque la mise à jour du produit est téléchargeable par les utilisateurs. Enfin, la modification substantielle d’un système IA par autoapprentissage aura lieu au moment où le changement conduira à la création d’un nouveau risque n’ayant pas été prédéterminé lors de l’évaluation initiale des risques. Alors que le cadre normatif européen offre des repères précis pour dater la modification substantielle des systèmes d’IA à haut risque, l’exercice demeure entouré d’incertitudes lorsqu’il s’agit des modèles d’IA à usage général présentant un risque systémique. IV – Un déplacement du risque probatoire vers les opérateurs numériques Avec la directive n° 2024/2853, l’Union bascule d’une conception statique du « défaut » pensée pour un produit industriel figé vers une approche dynamique, apte à saisir la plasticité des logiciels, des mises à jour à distance et, plus encore, des systèmes d’IA dont les performances se modifient après la mise sur le marché. Or, face à la complexité de ces produits, l’utilisateur victime ne peut pas décrire seul les arcanes d’un réseau neuronal, ni démontrer comment une version mineure du firmware a introduit une vulnérabilité. Le législateur européen répond en faisant peser sur le fabricant ou l’intégrateur une part croissante du risque informationnel (A), tout en introduisant des présomptions au profit de l’utilisateur (B) en tenant compte de l’appréciation dynamique de la défectuosité (C) que nous nous proposons d’illustrer (D). A – L’accès aux éléments de preuve : la discovery européenne 1 . Un droit à la divulgation proportionnée. L’article 9, paragraphe 1, instaure, pour la première fois en droit de l’Union, une procédure de divulgation forcée proche de la discovery nord-américaine 47 , dès lors que le demandeur apporte « des faits et des éléments de preuve suffisants pour étayer la plausibilité de sa demande », le juge peut enjoindre le défendeur de remettre les documents, journaux d’événements (logs), modèles d’IA et rapports d’essai pertinents. La mesure est symétrique : le défendeur peut obtenir, à son tour, les pièces techniques détenues par le demandeur (§ 2). Le texte limite toutefois la divulgation « à ce qui est nécessaire et proportionné » et exige la prise en compte des « intérêts légitimes » de toutes les parties, notamment la protection des secrets d’affaires (§ 3 et 4). Pour les logiciels critiques (antivirus, bloc chaîne d’un dispositif médical implantable, modèle d’IA générative…), le juge peut ordonner une communication expurgée, restreindre l’accès au dossier ou fermer l’audience (§ 5), afin de prévenir toute fuite qui ruinerait l’avantage concurrentiel du défendeur 48 . 2 . Présentation intelligible et standardisation des traces numériques. Le paragraphe 6 autorise le magistrat à exiger une présentation « facilement accessible et compréhensible » des preuves. Ce point est capital pour les algorithmes, il fonde la possibilité d’ordonner la remise d’un jeu de logs horodatés, d’un arbre de décision simplifié. Le log désigne un journal d’événements ou d’enregistrements automatiques produits par un système. Un log recense les données techniques enregistrant les événements survenus dans un système, telles que les horodatages, les identifiants de session, les actions effectuées et les messages d’erreur. Ce document s’inscrit dans les obligations de traçabilité prévues par l’article 12 49 du règlement IA , qui impose l’enregistrement automatique des événements sur la durée de vie d’un système IA à haut risque. 3 . Sanction probatoire. Le non-respect d’une injonction de divulgation déclenche une présomption simple de défectuosité (art. 10, § 2, a)). Pour un logiciel de pilotage autonome, le fabricant qui refuse de produire les logs d’apprentissage inverse la charge de la preuve et devra démontrer l’absence de défaut. B – Système de présomptions : un allègement ciblé de la charge de la preuve 1 . Triptyque des présomptions simples. Outre la sanction liée à la divulgation, deux autres cas déclenchent une présomption de défaut. Tout d’abord l’inobservation d’une exigence de sécurité obligatoire 50 (art. 10, § 2, b) : ce sera le cas lorsque le fabricant d’un système IA ne satisfait pas aux exigences de traçabilité de l’article 12 du règlement IA 51 . Il pourra renverser cette présomption en fournissant un dossier technique démontrant la conformité aux exigences de robustesse, de gouvernance des données et d’explicabilité (règl. AI, cons. 71). En cas de dysfonctionnement manifeste, constaté par expertise lors d’un usage normal (art. 10, § 2, c)), le défaut est également présumé. Dans le domaine logiciel, un crash reproductible, la corruption ou la perte des données utilisateur suffit. Ces présomptions demeurent réfragables. En effet, le défendeur peut prouver une mauvaise configuration ou une altération par l’utilisateur. Le fabricant pourra aussi démontrer que la défectuosité émane d’un service connexe que l’utilisateur a intégré ou connecté en dehors du contrôle du fabricant. 2 . Présomption de causalité. Dès que le défaut est prouvé, le lien causal avec un dommage « d’une nature généralement compatible » est présumé (art. 10, § 3). Cette disposition transpose la jurisprudence constante de la Cour de justice de l’Union européenne (CJUE) 52 . 3 . La présomption à raison d ’ une difficulté excessive . En raison de l’opacité fonctionnelle des réseaux neuronaux, la directive a introduit une véritable innovation (art. 10, § 4) pour les produits numériques dont la complexité technique ou scientifique rend la preuve excessivement difficile. Ce mécanisme probatoire est conditionné au fait que : 1. le demandeur démontre des difficultés excessives liées à la complexité technique ou scientifique pour établir le défaut ou la causalité, malgré les éléments reçus ; 2. il établit seulement la probabilité simple et non « élevée » du défaut ou du lien causal 53 . Dès lors, le juge présume soit la défectuosité, soit la causalité, soit les deux. Concrètement, confrontée à un réseau de neurones non interprétable ( blac k b ox ), la victime d’un diagnostic médical erroné pourra invoquer l’opacité de l’algorithme. Le fabricant pourra dans un premier temps contester l’existence des difficultés excessives de prouver le défaut ou le lien de causalité. En cas d’échec, le fabricant devra alors démontrer l’absence de défaut ou de lien de causalité. Cette bascule traduit l’idée qu’au-delà d’un certain degré d’opacité algorithmique, exiger une preuve classique revient à priver la victime de toute action. C – Temporalité et « défectuosité dynamique » Un logiciel n’est pas figé : mises à jour, patchs de sécurité ou réentraînement de l’IA peuvent faire apparaître un défaut après la commercialisation. Par coordination, le règlement IA impose un monitoring post mise sur le marché (art. 12, § 2, b)) et des obligations d’archivage des versions logicielles (art. 11). Ainsi, le demandeur peut invoquer une défectuosité liée à une version précise. Le défendeur doit conserver chaque version et prouver qu’elle a été testée, ou que l’anomalie provient d’une altération externe. Les tribunaux devront statuer sur la date pertinente pour apprécier le défaut : jour de la mise en service, de la mise à jour ou du dommage. D – Étude de cas : assistant IA d’aide au freinage Une start-up commercialise un logiciel d’aide au freinage d’urgence intégré à des véhicules particuliers. Après une mise à jour, plusieurs automobilistes alertent sur le fait que le dispositif ne s’est pas déclenché. Un conducteur intente une action en responsabilité. Divulgation. L’automobiliste produit les rapports d’expertise et une étude interne montrant que le système a été défaillant. Le juge ordonne la divulgation ; le fabricant doit remettre les logs d’évolution des poids du réseau et la documentation d’essai. Difficulté excessive. Les experts judiciaires attestent de l’impossibilité d’interpréter les 250 millions de paramètres. Le juge retient la complexité et active l’article 10, paragraphe 4. Probabilité simple. La délégation à la sécurité routière a recensé 50 défaillances similaires ; la probabilité du défaut est jugée suffisante. Présomption et renversement. Défectuosité et causalité sont présumées. Le fabricant peut encore démontrer (i) une mauvaise configuration des seuils ou (ii) une altération des données. À défaut, il sera condamné. Conclusion. Par un savant dosage entre divulgation, présomptions modulées et clause de complexité, la directive n° 2024/2853 fait basculer le centre de gravité probatoire vers l’opérateur économique qui se trouve le mieux placé pour documenter la sécurité. Soutenue par le règlement IA , cette architecture trace un continuum entre la documentation technique, la divulgation judiciaire et la présomption en cas de carence. Pour les systèmes d’IA, la mécanique est particulièrement puissante puisque le développeur qui choisit l’opacité court le risque d’un renversement complet de la charge de la preuve. La directive, tout en préservant le secret des affaires, incite donc l’industrie numérique à internaliser le coût informationnel de la complexité qu’elle crée. https://www.actu-juridique.fr/droits-europeen-ue/la-nouvelle-directive-sur-les-produits-defectueux-vers-une-appreciation-dynamique-de-la-defectuosite-des-systemes-dia-et-des-produits-numeriques/