Introduction
La responsabilité du fait des produits défectueux appliquée aux logiciels change de dimension. Avec la directive (UE) 2024/2853, le législateur européen met fin à une incertitude devenue difficilement compatible avec la place du numérique dans les produits contemporains. Le logiciel est expressément un « produit », qu’il soit embarqué dans un objet connecté, fourni séparément, accessible dans le cloud ou proposé selon un modèle SaaS. Les systèmes d’intelligence artificielle entrent eux aussi dans ce périmètre.
La directive doit être transposée par les États membres au plus tard le 9 décembre 2026 et s’appliquera aux produits mis sur le marché ou mis en service à compter du 9 décembre 2026, , à la suite du rectificatif publié le 7 mai 2026.
Pourquoi le logiciel devient-il un produit au sens de la responsabilité du fait des produits défectueux ?
En droit français actuel, l’article 1245-2 du Code civil définit le produit comme « tout bien meuble », en y incluant notamment l’électricité, sans viser expressément le logiciel. L’article 1245-3 retient quant à lui comme critère central la sécurité à laquelle on peut légitimement s’attendre.
La directive (UE) 2024/2853 modernise cette architecture. Son article 4 intègre explicitement les logiciels à la définition du produit. Son considérant 13 précise que sont concernés notamment les systèmes d’exploitation, applications, firmwares et systèmes d’intelligence artificielle, quel que soit leur mode de fourniture. Le développeur ou producteur du logiciel, y compris le fournisseur d’un système d’IA lorsqu’il répond à cette qualification, peut ainsi être considéré comme un fabricant.
Une responsabilité sans faute pensée à l’origine pour les biens industriels corporels s’adapte désormais à un produit dont le comportement peut évoluer après sa commercialisation.
Tout bug logiciel constitue-t-il un produit défectueux ?
La directive ne transforme pas toute erreur de programmation, anomalie fonctionnelle ou baisse de performance en défaut engageant automatiquement la responsabilité du fabricant. La défectuosité reste appréciée au regard de la sécurité que le public peut légitimement attendre du produit.
Pour un logiciel, cette appréciation pourra notamment tenir compte de sa fonction, de son utilisation raisonnablement prévisible, de son interaction avec d’autres produits, de sa capacité à continuer à apprendre, mais également des exigences de cybersécurité applicables. L’article 7 de la directive énumère ces circonstances et vise expressément l’effet sur le produit de toute capacité à poursuivre son apprentissage après sa mise sur le marché. Un bug purement esthétique n’est donc pas placé sur le même plan qu’une erreur de calcul dans le logiciel de commande d’un dispositif médical, qu’une vulnérabilité permettant de prendre le contrôle d’un appareil connecté ou qu’un défaut d’un système automatisé conduisant à une action dangereuse.
Mises à jour logicielles et IA : la responsabilité peut se prolonger après la commercialisation
L’une des innovations majeures de la directive réside dans la notion de contrôle du fabricant après la mise sur le marché.
Dans l’économie numérique, un produit n’est plus nécessairement figé au jour de sa livraison. Il reçoit des correctifs, de nouvelles fonctionnalités, des mises à niveau de sécurité et, pour certains systèmes d’IA, son comportement peut évoluer en raison de mécanismes d’apprentissage.
L’article 11 de la directive écarte donc l’exonération tirée de ce que le défaut est apparu postérieurement à la commercialisation lorsque ce défaut résulte d’un élément restant sous le contrôle du fabricant. Sont notamment visés :
- une mise à jour ou une mise à niveau logicielle défectueuse ;
- l’absence d’une mise à jour nécessaire au maintien de la sécurité ;
- un service connexe placé sous le contrôle du fabricant ;
- une modification substantielle du produit ;
- l’évolution d’un algorithme d’apprentissage automatique restant sous le contrôle du fabricant.
La directive ne crée cependant pas, à elle seule, une obligation générale et autonome de fournir toutes les mises à jour imaginables. Elle précise également que le fabricant peut ne pas être responsable lorsque l’installation échappe réellement à son contrôle, par exemple lorsque l’utilisateur refuse d’installer une mise à jour de sécurité qui lui a été correctement fournie.
Composants logiciels tiers : externaliser le développement ne signifie pas externaliser le risque
Les architectures modernes reposent rarement sur du code entièrement développé en interne. Bibliothèques open source, API, SDK, modules propriétaires, modèles pré-entraînés et composants fournis par des prestataires forment une véritable chaîne d’approvisionnement logicielle.
Or, la qualité de tiers du fournisseur ne suffit pas à protéger le fabricant final.
Lorsque le composant a été intégré ou interconnecté sous le contrôle du fabricant, le fabricant du produit final et, selon les circonstances, le fabricant du composant peuvent tous deux voir leur responsabilité engagée. La directive précise également que la responsabilité d’un opérateur ne disparaît pas simplement parce qu’un acte ou une omission d’un tiers a concouru au dommage.
En revanche, il serait excessif d’affirmer qu’un composant totalement extérieur au contrôle du fabricant engage nécessairement celui-ci. Le contentieux se déplacera précisément vers la notion de contrôle : qui a choisi le composant ? Qui a autorisé son intégration ? Qui pouvait le mettre à jour ? Qui avait la capacité d’en suspendre l’usage ? Qui a validé son déploiement ?
Pourquoi la traçabilité du code devient-elle une preuve juridique ?
C’est probablement l’un des effets les plus importants de la nouvelle directive pour les directions juridiques et les équipes techniques.
L’article 9, intitulé « Divulgation des éléments de preuve », permet d’obtenir, sous certaines conditions, la communication des éléments pertinents détenus par l’autre partie. L’article 10, relatif à la charge de la preuve, aménage en parallèle plusieurs présomptions en faveur du demandeur, portant tant sur la défectuosité que sur le lien de causalité. La défectuosité peut notamment être présumée lorsque le défendeur ne communique pas les preuves pertinentes ordonnées. Des présomptions peuvent également intervenir lorsque la complexité technique ou scientifique rend excessivement difficile la preuve du défaut ou du lien de causalité. Le considérant 48 cite expressément la difficulté à expliquer le fonctionnement interne d’un système d’IA.
Un dossier technique mal documenté peut donc devenir un handicap contentieux.
À l’inverse, une organisation capable de produire l’historique des versions, les tests réalisés, les décisions de sécurité, les validations humaines et l’origine des composants dispose de meilleurs éléments pour identifier l’origine d’un incident et combattre une présomption.
Code généré par IA : il faut pouvoir distinguer génération, revue et validation
Le sujet devient particulièrement sensible avec les assistants de programmation tels que ChatGPT, GitHub Copilot ou d’autres modèles de génération de code.
La directive n’impose pas de déterminer « l’auteur » d’une ligne de code au sens du droit d’auteur. Le simple code source, pris isolément comme information, n’est d’ailleurs pas assimilé par le considérant 13 au produit logiciel lui-même. Mais son historique peut devenir déterminant pour démontrer qui contrôlait la conception, l’intégration, le test et la mise en production du logiciel.
Prenons un exemple fictif. Un développeur utilise une IA générative pour proposer une modification d’une fonction qui pilote un équipement connecté. Six mois plus tard, cette fonction provoque un comportement dangereux. Dire que « le code venait de l’IA » ne constitue pas une défense. Il faudra pouvoir déterminer :
- quel outil et, lorsque cela est pertinent, quelle version ont été utilisés ;
- quel code a effectivement été intégré ;
- qui a revu le résultat ;
- quels tests fonctionnels et de sécurité ont été exécutés ;
- qui a autorisé la fusion du code et sa mise en production ;
- quelles modifications ont été apportées ensuite.
Le sujet rejoint ainsi directement celui de la propriété intellectuelle du code généré par IA : notre analyse sur la protection des logiciels générés par l’IA.
Conclusion
La responsabilité du fait des produits défectueux et logiciel ne peut plus être traitée uniquement après l’incident. La directive (UE) 2024/2853 rapproche responsabilité produit, cybersécurité, gouvernance de l’IA, gestion des prestataires et propriété intellectuelle.
Pour les entreprises, la priorité consiste désormais à construire une chaîne de preuve parallèle à la chaîne de développement. La provenance du code, les décisions humaines, les revues, les tests, les composants tiers et les mises à jour doivent pouvoir être reconstitués. Cette organisation ne garantit pas l’absence de responsabilité, mais permet en revanche de démontrer, en cas de litige, les conditions réelles dans lesquelles le produit a été développé, contrôlé et maintenu.
Le cabinet Dreyfus accompagne ses clients dans la gestion de dossiers de propriété intellectuelle complexes, en proposant des conseils personnalisés et un soutien opérationnel complet pour la protection intégrale de la propriété intellectuelle.
Nathalie Dreyfus avec l’aide de toute l’équipe du cabinet Dreyfus
FAQ
Une panne logicielle causant uniquement une perte d’exploitation est-elle indemnisée par la nouvelle directive ?
Pas nécessairement. L’article 5 de la directive réserve le droit à indemnisation aux personnes physiques et le régime vise certaines catégories définies de dommages ; il ne constitue pas un mécanisme général d’indemnisation de toutes les pertes économiques B2B. Des pertes d’exploitation ou préjudices purement économiques peuvent en revanche relever, selon les circonstances, de la responsabilité contractuelle ou d’autres régimes nationaux.
Un juge pourra-t-il demander la communication du code source d’un logiciel ?
Potentiellement, si celui-ci constitue un élément de preuve pertinent. L’article 9 permet d’ordonner la divulgation de preuves nécessaires et proportionnées. La directive impose toutefois de prendre en considération la protection des informations confidentielles et des secrets d’affaires ; une demande de preuve ne signifie donc pas une publication libre du code source.
Une clause contractuelle peut-elle exclure la responsabilité envers une personne lésée ?
Le régime institué par la directive ne peut pas être neutralisé à l’égard de la personne lésée par une clause excluant ou limitant la responsabilité de l’opérateur économique lorsque les conditions légales sont réunies. Les contrats conclus entre fabricants, fournisseurs et intégrateurs restent néanmoins essentiels pour organiser les garanties, responsabilités et recours entre professionnels.
Qu’advient-il d’un logiciel commercialisé avant le 9 décembre 2026 ?
La directive 85/374/CEE continue en principe de régir les produits mis sur le marché ou mis en service avant cette date. Une modification substantielle ultérieure peut toutefois soulever une nouvelle question de mise sur le marché et conduire la personne qui effectue cette modification à être traitée comme un fabricant dans les conditions prévues par la nouvelle directive.
La destruction de données professionnelles est-elle couverte par la directive ?
Le nouveau régime inclut la destruction ou la corruption de données qui ne sont pas utilisées à des fins professionnelles. Les pertes portant sur des données professionnelles devront donc être examinées au regard d’autres fondements éventuellement applicables, notamment contractuels.
L’utilisation d’un composant open source protège-t-elle automatiquement l’entreprise contre la responsabilité ?
Non. La directive prévoit une exclusion pour certains logiciels libres et ouverts développés ou fournis en dehors d’une activité commerciale. Cela ne signifie pas qu’un fabricant commercial intégrant ce composant dans son propre produit soit automatiquement exonéré des conséquences d’un produit final défectueux.
Cette publication a pour objet de fournir des orientations générales au public et de mettre en lumière certaines problématiques. Elle n’a pas vocation à s’appliquer à des situations particulières ni à constituer un conseil juridique.