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

1 – Évolution sous le contrôle du fabricant

1. Une défectuosité postcommercialisation. 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 dynamique4. 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édicaux5 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’IA7, la nouvelle directive intègre l’idée que l’autonomie évolutive du système doit être considérée dans l’évaluation du risque8.

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ème9. 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.

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évisable10. 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 seul12. 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 connexes13 dès lors qu’il ne serait pas en mesure d’assurer une ou plusieurs de ses fonctions s’il en était dépourvu14. 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ération16.

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ôle17. Dans la lignée de la directive de 198518, le fabricant du produit intégrant et le fournisseur du produit composite soit du service connexe défectueux seront solidairement responsables19. 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.

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ériorité 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 notion 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 ;
• autonome23, dans le cas des systèmes d’IA capables d’autoapprentissage24 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 produit25 au sens de la directive26. 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.

1 – L’émergence d’un risque objectivement indécelable en l’état des connaissances scientifiques et techniques

1. La 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 Commission27.

2 – Une obligation de veille scientifique et technique

L’article 11 de la nouvelle directive reprend l’exonération28 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 IA29 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. Une 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 soustrait 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émentaire30.

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 risquesde 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.

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 CRA35. 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ée36. 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 CRA37. 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 CRA38.

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 CRA39.

2 – La modification substantielle résultant de l’apprentissage continu d’un système d’IA

L’autoapprentissage 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 chatbot40. 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 9641 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).