La dernière bouteille de Mrs Donoghue

Le 26 août 1928, une femme de Glasgow nommée May Donoghue entra avec une amie dans un café de Paisley, une petite ville à environ sept miles du centre. L’amie commanda et paya pour elle un Scotsman ice cream float, une glace servie avec du soda au gingembre. La boisson fut servie par le propriétaire du Wellmeadow Café dans une bouteille opaque de verre sombre, du type alors répandu parce que le verre trouble empêchait de voir d’éventuels sédiments dans le contenu.

Quand la seconde moitié du liquide fut versée dans le verre avec la glace fondue, sortit de la bouteille, entraîné par le soda, un escargot en état de décomposition avancée. May Donoghue tomba malade d’une gastro-entérite sévère, fut visitée par un médecin le 29 août et hospitalisée en urgence à la Glasgow Royal Infirmary le 16 septembre. Quatre ans plus tard, en 1932, la House of Lords rendit un arrêt considéré comme la pierre angulaire du droit moderne de la responsabilité du fait des produits dans le monde de common law.

L’escargot dans la bouteille

La décision fut prise à la majorité de trois voix contre deux. Le rédacteur de l’opinion majoritaire fut Lord Atkin, qui dans le passage célèbre que tous les étudiants en droit continuent à mémoriser formula ce qu’on appelle le neighbour principle — l’obligation pour chacun de prendre soin de son voisin au sens juridique, où voisin signifiait quiconque était raisonnablement prévisible comme destinataire des effets de son comportement.

Dès lors, le producteur répond de son produit même envers ceux avec qui il n’a pas de relation contractuelle, même si la bouteille passe par un distributeur et un café avant d’arriver au consommateur, même si entre l’usine et la gastro-entérite de Mrs Donoghue s’interposent des semaines d’entrepôt et des kilomètres de route.

Ce que presque personne ne remarque en lisant l’arrêt, c’est que le juge, pour pouvoir écrire le neighbour principle, avait besoin d’un présupposé ontologique précis — d’une certaine idée de l’objet dont on parlait. L’objet était la bouteille. Un artefact borné, doté de contours nets, identifiable, examinable, conservable.

La bouteille était produite dans une usine spécifique, chez David Stevenson de Paisley, remplie à un moment daté, scellée par un bouchon qui en garantissait l’intégrité jusqu’au point de vente. Si nécessaire, les avocats auraient pu demander à examiner le lot de production, à analyser la composition du verre, à vérifier la chaîne d’approvisionnement des sucres et des arômes. La cause matérielle, au sens aristotélicien, était joignable. La cause efficiente — le processus productif — était documentée. La cause formelle — la forme typique d’une bouteille de soda — connue de tous.

Tout le droit moderne de la responsabilité du fait des produits qui s’est construit sur Donoghue v. Stevenson présuppose ceci de très simple et capital : on peut pointer du doigt un objet et dire « ceci », et le doigt qui pointe trouve toujours quelque chose au bout.

La nouvelle PLD et le problème d’une catégorie

En 1985, l’Europe, avec la Directive 85/374/CEE, a transposé en forme continentale le principe de Donoghue, en l’étendant et en le systématisant. La Product Liability Directive parle de « produits défectueux » et établit une responsabilité objective du producteur, indépendante de la faute, pour les dommages causés par le produit.

Quarante ans plus tard, le 23 octobre 2024, la Directive 2024/2853 a été adoptée, entrée en vigueur le 9 décembre 2024 et à transposer dans les ordres nationaux d’ici le 9 décembre 2026, date à partir de laquelle l’ancienne directive de 1985 est abrogée. La nouvelle PLD a été pensée expressément pour le logiciel et inclut dans la définition de produit les fichiers numériques, les composants logiciels, les applications, les systèmes d’IA. C’est l’une des plus ambitieuses réformes du droit de la responsabilité civile jamais tentées par l’UE.

Le fait qu’il ait fallu quarante ans pour la repenser, et que malgré l’effort énorme de ses rédacteurs elle risque d’être déjà inadaptée le jour de son entrée en vigueur, n’est la faute de personne en particulier. C’est la conséquence d’un problème que le droit n’a pas encore su nommer avec précision. Le problème est que le « produit » sur lequel Lord Atkin et ses successeurs ont bâti deux siècles de jurisprudence, dans le logiciel contemporain, n’existe plus.

Vaut la peine de prendre une minute pour comprendre où il est passé, parce que le diagnostic est le point de départ de tout ce qui suit.

Du disque au concert

Pendant longtemps, le logiciel a été un produit au sens plein et conventionnel. On est sorti du laboratoire des Bell Labs et on est entré dans la distribution de masse avec Unix puis avec les OS pour PC.

Une application des années 80 ou 90 était un ensemble de fichiers distribués sur disquette, puis sur CD, puis sur DVD, avec un numéro de version, un hash identificateur, une copie conservable au coffre. Si le logiciel présentait un défaut, on pouvait, du moins en théorie, isoler la version exacte du binaire, la comparer à la version supposée correcte, identifier le bug. Windows 95 était un produit. Word 97 aussi. Même un jeu comme Baldur’s Gate, avec ses patchs numérotés et conservables.

Bien sûr, déjà alors, le logiciel dépendait de choses qui n’étaient pas le produit au sens strict — drivers, firmware, protocoles réseau, services système. Mais ces dépendances étaient statiques, déclarées, en nombre limité et surtout médiées par un artefact autosuffisant qu’on pouvait conserver et reproduire bien des années plus tard. La copie du CD de Windows 95 qu’un archiviste numérique conserve aujourd’hui est encore identique à celle de 1995, bit pour bit. Le produit, comme objet doté de continuité dans le temps, existait.

Au début des années 2000, quelque chose commence à changer, et la vitesse du changement s’accélère dramatiquement la décennie suivante. La transition au software as a service déplace l’application du disque local du client au serveur du fournisseur. Au début c’est une simple question de distribution, mais bientôt cela devient une transformation ontologique.

Quand l’application tourne sur un serveur distant, la version qu’utilise l’utilisateur à un moment donné n’est plus une propriété stable — c’est une propriété momentanée, renégociable par le fournisseur à tout instant sans même prévenir. Le continuous deployment pousse cette fluidité à son aboutissement, avec des entreprises qui mettent en production des dizaines ou des centaines de changements par jour, sans que personne, même en interne, ne soit en mesure de reconstituer exactement la configuration du système à 14h23 d’un mardi d’il y a trois mois.

En parallèle, la composition interne du logiciel change de nature. Depuis le début des années 2010, grâce aux écosystèmes comme npm, Maven ou PyPI, écrire une application signifie importer des centaines ou milliers de paquets tiers, chacun composé à son tour de paquets tiers, dans un graphe de dépendances transitives qu’aucun humain ne lit entièrement et qui se met à jour de façon asynchrone par rapport au code écrit. L’affaire left-pad en 2016, quand un seul dev a effacé de npm un paquet de onze lignes et a cassé une grande partie des pipelines de build et processus d’installation du monde JavaScript, fut le moment où l’industrie s’est aperçue, un instant, à quel point fragile et distribué était devenu ce qu’elle continuait à appeler produit.

La dernière accélération, vécue ces mois-ci, est l’entrée des modèles de langage dans la chaîne productive du logiciel. Ici le saut n’est pas seulement quantitatif mais catégorial, parce que ce qui entre dans le produit n’est plus un ensemble d’instructions déterministes mais un composant probabiliste dont les outputs ne sont pas exactement reproductibles, et dont les poids, une fois écartés par le fournisseur pour passer au modèle suivant, pourraient ne plus être accessibles.

Une application qui tourne aujourd’hui via API sur un modèle frontier est une application dont le comportement observable dépend d’un composant qui pourrait demain se comporter différemment, dans deux ans n’exister plus sous une forme récupérable, et dont le fonctionnement interne n’est inspectable par personne, pas même son entraîneur. Qui développe sait : si un utilisateur d’il y a cinq ans nous demandait de reproduire exactement le bug qu’il avait vu, la réponse honnête serait que nous ne le pouvons pas, parce que le système qui a produit ce bug n’existe plus dans une configuration restorable. Les dépendances ont été mises à jour, les API externes ont changé de contrat, la base a été migrée, le modèle d’IA a été remplacé. Nous avons les logs. Nous avons le code de notre application. Mais l’événement qui a produit le bug était un concert, et des concerts, il reste les enregistrements, pas les concerts.

C’est la métaphore qui rend, je crois, le saut ontologique en cours. Le logiciel contemporain n’est plus un disque, c’est un concert.

Le disque est un artefact stable, conservable, comparable, doté d’une identité dans le temps. Le concert est un événement distribué dans l’espace et le temps, coproduit par de nombreuses agences en temps réel, irrépétible, dont on peut avoir des traces mais pas d’originaux. Quand on réécoute l’enregistrement d’un concert de Keith Jarrett de 1975, on écoute un artefact dérivé, pas le concert — qui a eu lieu une seule fois et est terminé. Idem pour une appli SaaS aujourd’hui.

Ce que l’utilisateur a vécu hier à 11h est un événement coproduit par l’application, le navigateur, la latence du réseau, la version courante du LLM sous-jacent, la configuration de douze API tierces, un rate limit qui à cet instant exact avait une valeur. Cet événement n’est pas reproductible, pas conservable, pas ontologiquement un objet. C’est, justement, un concert.

L’objection et la copie qui n’est plus

Quelqu’un objectera ici que la distinction est exagérée : en 1998 aussi, le logiciel tournait sur un OS dépendant de drivers et de matériel ; la contingence runtime existait alors aussi ; tout usage d’une application a toujours été en quelque mesure un événement et non un objet.

L’objection est partiellement correcte, et la prendre au sérieux est important pour éviter de transformer le diagnostic en nostalgie. La différence qui change tout, cependant, est unique, et c’est celle que le droit n’a pas encore métabolisée.

En 1998 il existait toujours une copie de l’artefact. Au sens le plus strict, dans le coffre du fournisseur ou sur les disques durs des utilisateurs ou dans l’archive d’un archiviste numérique, il y avait un objet matériel contenant le logiciel sous sa forme autonome. Cette copie était le point de contact entre le produit juridique et l’événement exécutif. Le point archimédien permettant de revenir en arrière, examiner, comparer, juger. Ce qui permettait au juriste de dire « ce produit était défectueux » parce qu’un produit existait.

Aujourd’hui, cette copie n’existe plus, et pas par négligence ou mauvais choix, mais par construction. L’application SaaS du fournisseur X, à 14h23 d’un mardi d’il y a trois mois, n’existe dans aucune sauvegarde, aucun coffre, aucune archive. N’existe que la possibilité de reconstituer, de manière approximative et partielle, ce qu’elle aurait dû être, en croisant logs, versions du code, configurations des dépendances, poids des modèles, état de la base.

C’est une reconstitution archéologique, pas un accès à l’objet. Et même portée à son terme, elle aboutirait à autre chose — un modèle de l’application de ce moment, pas l’application de ce moment. Le produit, au sens bicentenaire du terme juridique, a disparu. Ce qui existe à sa place n’a jamais été nommé.

Le corpus européen et son désalignement

Le législateur européen, il faut le reconnaître, s’est aperçu que quelque chose clochait. Ces dernières années, il a produit un paquet impressionnant de normes qui tentent d’attraper le nouvel objet avec les outils disponibles.

Le Cyber Resilience Act, en vigueur depuis décembre 2024, applicable pleinement en décembre 2027, introduit le security by design/default pour les produits avec éléments numériques, impose des obligations de support sur tout le cycle de vie, exige la fourniture d’un Software Bill of Materials. La nouvelle PLD étend explicitement la responsabilité aux défauts de cybersécurité et aux dysfonctionnements des mises à jour. L’AI Act, en vigueur depuis le 1er août 2024 avec application générale au 2 août 2026 et certaines provisions au 2 août 2027, classifie les systèmes d’IA par risque et impose obligations de documentation, transparence, évaluation de conformité. À cela s’ajoutent NIS2, DORA, Data Act, EAA.

Mis bout à bout, ils forment le corpus normatif le plus ambitieux jamais bâti pour discipliner la production de logiciel, un effort sérieux, techniquement informé, culturellement important. L’erreur serait de les banaliser comme bureaucratie ou frein à l’innovation, à la mode d’une certaine vulgate libertarienne californienne. La thèse de cet essai est plutôt que, tout en étant sérieux et importants, ces instruments tentent de capturer le concert avec les catégories du disque, et le désalignement catégorial est destiné à produire des conséquences qu’on commence seulement à entrevoir.

Le cas du Software Bill of Materials est paradigmatique de cette difficulté. Le SBOM est un document énumérant tous les composants entrant dans un logiciel, leurs versions, leurs dépendances, leurs licences. Sur le papier, un outil parfaitement raisonnable, l’équivalent logiciel de la liste d’ingrédients sur les emballages alimentaires.

En pratique, le SBOM est la photographie d’un concert, avec toutes les limites épistémiques que cette condition implique. Une photo du concert n’est pas le concert, c’est déjà un autre objet, dérivé, partiel, daté. À l’instant exact où la photo est prise, le concert change déjà, et au dixième de seconde suivant les dépendances transitives ont pu se mettre à jour, la version de l’API externe peut avoir changé, le poids du modèle peut avoir été remplacé.

Le SBOM capture un état, mais le logiciel contemporain n’a pas d’états stables — seulement des flux. La norme demande donc aux développeurs de maintenir la photographie à jour, ce qui génère des processus de continuous SBOM generation, avec des outils qui produisent un SBOM à chaque build, à chaque deploy, idéalement en temps réel. Résultat paradoxal : le document censé capturer l’identité du produit se multiplie en milliers de snapshots quotidiens, dont chacun est déjà obsolète au moment de sa génération. Le SBOM ne capture pas le produit, parce que le produit n’existe pas. Il capture le flux, sous forme de fragments discrets, et chaque fragment est un document juridiquement pertinent. La charge documentaire qui en découle est énorme, et sa valeur probante, quand il s’agit de reconstituer qui était responsable de quoi à un moment précis, est bien moins nette que ce que les législateurs ont supposé.

Le même problème, aggravé par la nature stochastique des modèles, se pose pour l’AI Act. L’article 10 demande que les datasets d’entraînement soient documentés, traçables, gouvernés par des critères de qualité. L’article 15 demande que les systèmes à haut risque soient exacts, robustes, cybersécurisés. L’article 72 impose le monitoring post-market. Chaque obligation a du sens prise isolément, et renvoie à des pratiques que la meilleure ingénierie du machine learning devrait déjà adopter.

Ce que les législateurs n’ont pas pleinement absorbé, c’est que le modèle qu’un fournisseur offre aujourd’hui via API est un objet dont l’identité dans le temps est, au mieux, conventionnelle. Les poids sont mis à jour, le RLHF est affiné, les guardrails modifiés, et ce qui continue à s’appeler GPT-4 ou Claude Opus ou Gemini Ultra est, du point de vue du comportement observable, un objet différent de ce qui portait le même nom il y a six mois.

Demander la documentation du training, c’est demander la documentation de quelque chose qui, au moment où la documentation est produite, peut déjà avoir été dépassé par un autre training. Le monitoring post-market est une excellente pratique, mais il présuppose un marché où le produit est le même au moment de la vente et de l’usage, ce qui n’est presque jamais vrai pour les modèles de langage.

L’AI Act n’est pas faux — c’est une des réponses régulatoires les plus articulées jamais tentées à cette échelle. Il hérite simplement du droit de la responsabilité du fait des produits une série de présupposés ontologiques que l’objet qu’il cherche à régler ne satisfait pas, et la tension entre les présupposés et l’objet se déchargera dans les années à venir sur les épaules des praticiens, sous forme d’obligations à valeur ambiguë, de documents dont le rapport au réel sera difficile à établir, de contentieux où le différend se réduira à un débat sur la représentativité d’un snapshot.

CrowdStrike, 19 juillet 2024

Un exemple récent, d’une portée telle qu’il est entré dans les cours de risk management du monde entier, aide à voir concrètement ce que cela signifie.

Le 19 juillet 2024, une mise à jour défectueuse du capteur Falcon de CrowdStrike a provoqué le crash simultané d’environ 8,5 millions de machines Windows à travers la planète, avec un boot loop nécessitant une intervention manuelle sur chaque appareil. Aéroports paralysés, hôpitaux repassés au papier, banques inopérantes, télévisions bloquées, appels d’urgence non routés. Delta Airlines à elle seule a déclaré plus de 500 millions de dollars de dommage direct, les seules Fortune 500 ont déclaré des pertes non assurées de l’ordre de 5,5 milliards, avec des estimations globales que diverses sources placent dans les dizaines de milliards.

Dans le contentieux qui a suivi — toujours ouvert dans plusieurs juridictions —, toute la question s’est concentrée sur : qui était responsable.

• CrowdStrike, qui avait diffusé une mise à jour avec un défaut détectable par n’importe quel test sérieux.
• Microsoft, qui avait permis à un logiciel tiers d’opérer avec des privilèges kernel suffisants pour mettre l’OS en boot loop.
• Les organisations déployeuses, qui acceptaient les mises à jour en push automatique sans phases canary.
• Les régulateurs européens, selon la défense de Microsoft, qui des années plus tôt avaient imposé l’ouverture du kernel pour des raisons de concurrence.

Chacune de ces quatre attributions, prise isolément, capte un aspect réel. Aucune, prise isolément, ne raconte ce qui s’est passé. Ce qui s’est passé, c’est un échec d’orchestration — un événement où de nombreux acteurs avaient, chacun à son degré, une influence effective sur le comportement runtime, et où aucun n’avait exercé cette influence proportionnellement aux conséquences possibles.

Le droit actuel n’a pas d’outils adéquats pour distribuer la responsabilité ainsi, et le contentieux glisse en conséquence vers des scénarios où gagne qui a les meilleurs avocats ou la position contractuelle la plus défendable — autre manière de dire que le droit a renoncé à dire quelque chose de substantiel sur l’incident. Un cas comme CrowdStrike, lu à la lumière de la catégorie d’assemblage responsable que je tente d’esquisser, aurait dû produire un arrêt distribuant la responsabilité en quotités identifiables entre les acteurs en fonction de leur blast radius et de leur contrôle effectif, et créer un précédent utilisable pour les incidents futurs, qui seront certainement nombreux. Rien de tout cela n’arrive, parce que la catégorie pour le faire n’existe pas.

Latour, Ricœur et la pluralité de l’action

L’assemblage responsable n’est pas une invention ex nihilo, mais l’adaptation au domaine juridique de réflexions que la philosophie du XXᵉ a développées ailleurs.

Bruno Latour, avec l’actor-network theory, a montré dès les années 80 que les actions complexes n’ont jamais un seul agent, mais émergent de réseaux d’acteurs humains et non humains dont l’analyse exige de suspendre l’obsession du sujet individuel et de suivre les connexions effectives. Son exemple canonique du dos d’âne, le sleeping policeman, est éclairant : le dos d’âne enforce la limitation indépendamment du policier, agissant comme acteur non humain doté d’agency.

Le ralentissement de l’auto est coproduit par le conducteur, le dos d’âne, le code de la route, la peur d’abîmer la suspension, la culture partagée qui reconnaît le dos d’âne comme signal de prudence. Aucun de ces acteurs, seul, n’explique le ralentissement. Le droit positif tend à découper la responsabilité sur le conducteur pour des raisons pratiques, mais la compréhension philosophique de l’événement exige de voir les cinq ensemble. Le pas que le droit n’a pas fait, et que la philosophie a fait il y a quarante ans, c’est d’accepter que cette distribution de l’agence soit la norme, pas l’exception, et d’en tirer les conséquences.

Paul Ricœur, dans Soi-même comme un autre (1990), a ajouté un volet : l’imputation est un acte narratif qui exige de reconstruire une histoire plausible de causation, et quand l’histoire plausible implique de nombreux agents, la narration imputative ne peut se réduire à un seul sujet sans trahir la vérité de l’événement. L’imputation, pour Ricœur, est une herméneutique de la responsabilité, et comme toute herméneutique elle exige de la patience, de l’écoute des différents niveaux, le refus des simplifications.

Le droit contemporain de la responsabilité du fait des produits simplifie trop, parce qu’il a hérité d’une grammaire narrative dix-neuviémiste où le producteur était un, identifiable, imputable. Reconstruire l’imputabilité pour le logiciel contemporain, c’est accepter la nature plurielle de l’action et la restituer dans le texte de l’arrêt.

L’assemblage responsable

Si l’on s’arrête là, le diagnostic risque d’apparaître pessimiste ou purement critique. Le point que je veux essayer de développer est l’opposé : si le concept de produit ne tient plus sa fonction d’attribution de responsabilité, il devient nécessaire d’imaginer la catégorie de remplacement.

Cette tâche ne peut être déléguée ni aux juristes purs, qui n’ont pas de contact avec le runtime des systèmes réels, ni aux ingénieurs purs, qui tendent à considérer le droit comme une nuisance externe plutôt qu’une tentative d’attribuer un sens moral à ce qu’ils font. La catégorie doit être pensée à quatre mains, par qui a la pratique du code et la lecture du droit, et partir du fait que le logiciel contemporain est une orchestration, un assemblage, un événement distribué — pas un objet.

Je propose de l’appeler, provisoirement, assemblage responsable.

Qu’est-ce qu’un assemblage responsable, en première approximation. Une configuration de composants, humains et non humains, organisés autour d’une fonction spécifique offerte à un utilisateur, dont aucun participant ne détient le contrôle intégral mais dont chacun exerce un degré identifiable d’influence effective sur le comportement observable en runtime.

La responsabilité, dans cette grille, ne suit plus la titularité formelle (« qui a contracté répond de tout »), ni l’origine historique des composants (« si le bug est dans la lib importée, c’est la faute du mainteneur »). Elle suit le gradient de l’influence effective.

Qui a pu, au moment du dommage, modifier le comportement du système par une action technique ciblée, répond proportionnellement au degré de cette possibilité. Le fournisseur du modèle d’IA qui aurait pu mettre à jour les guardrails et ne l’a pas fait répond d’une quotité. L’intégrateur qui a choisi ce modèle pour une fonction sensible sans évaluer adéquatement les risques répond d’une autre. L’utilisateur qui a configuré le système anormalement, contournant les avertissements, répond d’une troisième. Aucun ne répond de tout, aucun ne répond de rien — chacun répond de sa portion d’orchestration.

Formule simple à énoncer, infernalement complexe à implémenter, comme c’est naturel pour toute catégorie juridique nouvelle dans ses premières décennies.

Les objections viennent vite. Première : l’influence effective est difficile à mesurer, et un système juridique fondé sur un concept aussi fuyant serait source d’incertitude. Vraie, mais moins grave qu’il n’y paraît : le droit civil opère déjà avec des concepts fuyants — faute, prévisibilité, causation adéquate — et a développé des outils opérationnels pour les manier.

L’influence effective sur un système distribué est mesurable via ce que les ingénieurs appellent blast radius — l’estimation de l’ampleur des conséquences d’une action technique. Un fournisseur d’API LLM a un blast radius qui couvre potentiellement tous ses intégrateurs, parce qu’une modification se propage instantanément. Un intégrateur a un blast radius limité à ses utilisateurs, qui peut s’amplifier si son application est elle-même infrastructure d’autres applications.

Il existe des métriques techniques, grossières mais traitables, pour estimer le blast radius de chaque acteur, et la doctrine pourrait construire dessus une taxonomie graduée de la responsabilité. Pas plus fuyant que ne l’étaient les doctrines de la faute aquilienne au XIXᵉ avant que des décennies de jurisprudence ne les rendent opérationnelles.

Deux déformations à résister

La seconde objection est plus politique et vient de deux directions opposées, toutes deux intéressées.

La première : les milieux californiens de la grande tech, qui ont construit ces vingt dernières années une narration selon laquelle la nature open source et componentisée du logiciel rendrait impossible toute attribution de responsabilité particulière, et que la responsabilité devrait donc se limiter aux termes contractuels acceptés explicitement. Selon cette lecture, si un utilisateur subit un dommage d’une application qui utilise une lib open source d’auteur anonyme, hébergée sur un cloud qui décline toute responsabilité dans ses CGU, alors personne ne répond de rien — ou seulement qui a délibérément assumé la responsabilité par contrat.

C’est la doctrine de l’irresponsabilité distribuée, confortable rente de position pour qui occupe les nœuds les plus centraux de l’orchestration : on encaisse la valeur, on externalise les risques. L’assemblage responsable s’y oppose frontalement, parce qu’il refuse l’idée que l’absence de titulaire formel équivale à l’absence de responsabilité substantielle. Si ton modèle est le composant critique de milliers d’applications en aval, ta responsabilité ne dépend pas du fait que tu as ou non signé un contrat avec les utilisateurs finaux. Elle dépend de ton rôle dans l’orchestration, et ce rôle est objectivement mesurable.

L’autre direction : le formalisme européen continental, dans la doctrine du titulaire absolu.

Selon cette tradition, le titulaire du traitement, ou le fournisseur du service, ou le déployeur du système d’IA, répond de tout ce qui se produit dans la chaîne, indépendamment d’où la non-conformité est née. Doctrine intuitivement égalitaire — elle protège l’utilisateur en lui assurant que quelqu’un répondra toujours. Mais en pratique, elle produit deux distorsions sérieuses.

La première : elle décharge sur le titulaire une responsabilité dont il n’a pas le contrôle technique, le contraignant à se défendre contre des contentieux pour des dysfonctionnements issus de composants qu’il n’a pas écrits, pas choisis, ne peut inspecter. La seconde : elle déresponsabilise les nœuds en amont — ceux qui ont l’influence la plus systémique — parce qu’ils savent que leur quote-part sera formellement déchargée sur le déployeur final, et que les tribunaux continueront à pointer du doigt celui qui occupe la position la plus visible.

L’assemblage responsable s’oppose aussi à cette doctrine. La position formelle du titulaire n’épuise pas la question, et une distribution seulement apparente du fardeau, qui se concentre dans les faits sur le nœud le plus accessible, maintient les choses telles qu’elles sont dans les rapports de force réels de l’industrie.

La proposition se trouve donc dans un territoire inconfortable pour les deux sensibilités dominantes, et c’est précisément pour cela qu’elle mérite d’être articulée. Qui travaille dans le software sait que l’idée d’une responsabilité purement contractuelle est une fiction utile à qui est dans la Silicon Valley et une expérience quotidienne d’impuissance pour qui est à Pescara, Milan ou Francfort et doit livrer un système qui fonctionne réellement sous des contraintes réelles. En même temps, qui travaille avec la compliance européenne sait que la doctrine du titulaire absolu transforme le déployeur en fusible juridique — fonction économique : sauter quand le système se rompt, permettant aux composants amont de continuer à produire des externalités.

Le logiciel contemporain a besoin d’une catégorie qui ne soit ni l’une ni l’autre, qui distribue la responsabilité de façon à refléter la distribution effective du pouvoir technique. Pas une distribution symétrique — le pouvoir technique n’est pas symétrique. Pas une concentration sur le titulaire — le pouvoir n’est pas concentré là. Une distribution qui suit le gradient de l’influence effective, avec des métriques transparentes, une doctrine pratique que les tribunaux puissent manier, une ratio que les praticiens reconnaissent comme adhérente à leur expérience de travail.

Certains domaines bougent déjà dans cette direction, sans que personne ne nomme la chose. Le RGPD, à l’article 28 et dans les lignes directrices de l’EDPB sur la chaîne des sous-traitants, a timidement commencé à reconnaître la gradation de responsabilité le long de la chaîne du traitement — formellement et sans l’appareil conceptuel nécessaire. Les AIPD, sérieusement faites, contiennent en germe un blast-radius appliqué à la donnée personnelle.

NIS2 introduit pour les fournisseurs de services managés des obligations qui reconnaissent leur rôle systémique. L’AI Act, avec sa distinction provider/deployer/importer/distributor, tente une taxonomie des rôles qui, encore trop rigide, va dans le sens d’une distribution non centrée sur le titulaire.

Aucun de ces instruments n’a encore formulé explicitement le principe de l’influence effective comme gradient de responsabilité, mais tous contiennent les traces d’un repensement qui n’attend qu’une systématisation doctrinale. L’impression : il manque quelque chose de comparable à ce que fut le neighbour principle pour Lord Atkin — une formulation synthétique, mémorable, opérationnelle, qui oriente cinquante ans de jurisprudence à venir. Qui l’écrira aura fait pour le XXIᵉ ce que la House of Lords fit pour le XXᵉ.

Pour que cette formulation puisse être écrite, il faudra une figure d’intellectuel qui n’existe pratiquement pas aujourd’hui. Pas des juristes purs (la grammaire des systèmes distribués ne s’apprend pas en faculté de droit). Pas des ingénieurs purs (la grammaire du droit et son histoire bicentenaire de catégories ne s’apprend pas en computer science).

Il faut des hybrides, des figures de frontière qui aient pratiqué les deux métiers assez longtemps pour en avoir compris les logiques internes et les limites, et qui soient prêts à imaginer ce qu’aucun des deux corpus, seul, ne saurait imaginer. En Italie, cette figure n’a pas encore de nom consolidé. Dans les pays anglo-saxons s’est affirmé ces dernières années le compliance engineer ou technical counsel, mais ce sont encore des définitions qui se limitent à mettre en communication les deux cultures sans en construire vraiment une troisième.

Il faut quelque chose de plus ambitieux : une figure qui ne traduise pas seulement le jargon technique en jargon juridique et inversement, mais qui élabore des catégories nouvelles capables de dire ce qu’aucun des deux jargons d’origine ne saurait dire. Métier en partie théorique (formation philosophique pour manier des catégories abstraites) et en partie pratique (expérience quotidienne du deployment, des dépendances transitives, des rétrocompatibilités cassées par un minor release du fournisseur, des stack traces ambiguës qui ne disent pas qui est en faute). Sans expérience pratique, les catégories abstraites restent suspendues. Sans formation abstraite, l’expérience pratique s’épuise en fatigue et tickets fermés.

La troisième voie est difficile non parce qu’elle exige des dons rares, mais parce que le marché du travail ne la valorise pas, les universités ne la forment pas, les entreprises ne l’organisent pas. Elle existe par seule volonté individuelle, et c’est précisément pour cela que qui la pratique a une responsabilité intellectuelle disproportionnée à sa position formelle.

Du Bill of Materials au Bill of Accountability

Revenons au problème concret du départ : comment attribuer la responsabilité pour un dommage causé par un logiciel contemporain.

Si l’on accepte que le logiciel n’est plus un produit mais un assemblage, et que l’assemblage s’analyse selon le gradient de l’influence effective, alors le premier pas opérationnel est de bâtir une pratique de documentation de l’assemblage qui ne soit pas la photo statique du SBOM, mais une carte dynamique des relations d’influence.

Un tel outil devrait permettre de répondre, pour chaque application, à des questions comme :

• Quels composants, modifiés, changeraient le comportement observable du système.
• Quels acteurs ont la capacité technique de modifier ces composants.
• Quelles sont les obligations contractuelles et normatives qui pèsent sur chacun.
• Quelles sont les évidences (logs, audit) permettant de reconstituer ex post l’état du système à un moment précis.
• Quels canaux de communication permettent à un acteur en aval de faire arriver un signal d’alarme à un acteur en amont.
• Quels sont les délais de réponse typiques le long de la chaîne.

Le document résultant ne serait plus un bill of materials, mais quelque chose de plus proche d’un bill of accountability — une carte des pouvoirs et devoirs le long de toute l’orchestration. Le produire exigerait du travail, exigerait coopération entre acteurs qui n’ont pas toujours intérêt à coopérer, exigerait des normes pour l’imposer. Mais ce serait un outil qui nommerait le problème pour ce qu’il est, plutôt que de le réduire à un problème d’inventaire.

Trois conséquences pour qui développe

Du point de vue de la pratique quotidienne, cette ré-articulation aurait des conséquences importantes.

Première : le contrat-type, qui aujourd’hui tend à décharger toute la responsabilité sur le fournisseur final ou, au mieux, à la limiter au montant annuel payé, deviendrait un document de structure très différente. Il serait construit en aval d’une analyse de l’orchestration, avec une articulation claire des composants que le fournisseur contrôle vs. qu’il intègre seulement, des risques qu’il assume pleinement vs. dont il fait canal de transfert, des obligations informationnelles qu’il accepte vs. qu’il n’est pas techniquement à même d’honorer. Plus long, plus complexe, plus honnête — et à long terme plus défendable, parce qu’il raconte la chose telle qu’elle est.

Deuxième : le processus de développement devrait inclure, dès le début, une réflexion sur l’orchestration dans laquelle le système s’insérera, pas seulement sur les exigences fonctionnelles.

• Qui sont les acteurs amont dont nous dépendrons.
• Quelles garanties nous donnent-ils.
• Quel blast radius ont-ils à notre égard.
• Comment vérifierons-nous leurs changements.
• Comment réagirons-nous si l’un de leurs changements casse notre comportement attendu.

Aujourd’hui reléguées à quelques slides d’architecture puis oubliées, ces questions devraient devenir partie intégrante de la spec. Leur absence dans une doc projet serait un indicateur d’immaturité, comme l’est aujourd’hui l’absence d’un threat model.

Troisième — la plus intéressante culturellement, qui touche la formation. Aujourd’hui, on apprend à écrire du code qui marche, puis, si on a de la chance, à écrire du code qui marche en production. Presque personne n’apprend à écrire du code qui marche au sein d’une orchestration dont il a conscience.

La conscience de l’orchestration arrive tard, souvent par un incident, rarement comme compétence enseignée. Une formation qui prendrait au sérieux la nature distribuée du logiciel contemporain devrait partir de là — montrer dès le premier jour qu’écrire une API, c’est entrer dans une orchestration ; choisir une lib, c’est accepter un fournisseur amont ; déployer en cloud, c’est s’héberger dans une infra dont les choix d’archi sont ailleurs.

Pas pour terroriser les jeunes, mais pour les habituer à voir ce que voient les développeurs expérimentés après vingt ans de cicatrices. L’orchestration est l’objet de leur travail, pas un décor. Le code qu’ils écrivent est une participation à un concert, pas un objet autosuffisant. S’ils grandissent avec cette conscience, la question de la responsabilité n’arrivera pas comme nuisance externe, mais comme dimension intrinsèque du métier.

Quand l’écriture aussi est orchestration

À qui soupçonne que tout ceci est exagéré par la lentille du SaaS et que dans des contextes plus simples la catégorie de produit pourrait encore tenir, on peut répondre que la direction du développement AI-natif rend le problème plus aigu, pas moins.

Quand on travaille avec des outils comme Claude Code ou des pratiques comme la specification-driven development style SpecKit, le code cesse d’être l’objet que le développeur écrit directement et devient le produit d’une chaîne de génération qui part de la spec, passe par un modèle, produit un artefact et l’intègre dans une orchestration déjà distribuée. La spec écrite hier et le code généré hier, régénérés aujourd’hui par le même modèle, produiraient un code plausible mais non identique, parce que le modèle a changé.

La notion de version, déjà affaiblie par le continuous deployment, devient encore plus instable, parce qu’elle ne l’est plus seulement au temps d’exécution mais aussi au temps d’écriture. Qui développe ainsi sait que la reproductibilité exacte est un horizon régulateur, pas une propriété effective.

L’assemblage responsable, dans un monde où l’écriture du code aussi est une orchestration entre développeur, spec, modèle, toolchain et pipeline, devient la catégorie naturelle pour penser la responsabilité — la seule où l’absence d’auteur monolithique ne se traduit pas automatiquement par l’absence d’imputabilité.

La mort d’une catégorie

Reste une question à laquelle l’essai doit répondre. Est-ce qu’il a vraiment du sens de parler de la mort d’une catégorie juridique, ou ne décrit-on qu’une évolution, une transformation, une mise à jour ?

Le langage de la mort est fort, et peut sembler exagéré. La justification : une catégorie meurt au sens où Foucault le disait à propos de catégories plus générales — quand elle cesse d’organiser le champ discursif de manière productive et commence à l’entraver.

Le concept de produit, appliqué au logiciel contemporain, n’organise plus le champ, il l’entrave. Il produit des obligations qui ne correspondent pas à des pratiques, des documents qui ne représentent pas d’objets, des contentieux qui s’enlisent sur la définition de l’objet avant même de pouvoir traiter le fond.

Un concept qui entrave le champ n’est pas un concept utile, même s’il reste formellement en vigueur. Le concept d’éther luminifère, en physique de fin XIXᵉ, n’était pas faux au sens d’affirmations singulières, c’était un concept qui avait cessé d’organiser productivement le champ, jusqu’à ce qu’Einstein le retire simplement.

Le concept de produit, en droit contemporain du logiciel, est dans une phase comparable. Encore là, encore dans les textes, encore dans les prétoires. Mais il ne travaille plus. Et faire comme s’il travaillait est plus dangereux qu’admettre qu’il ne travaille pas.

Je ne dis pas que le législateur européen aurait dû attendre d’avoir la bonne catégorie avant d’intervenir. Position intellectuellement pure et politiquement impossible — et le dommage de l’absence de régulation aurait dépassé celui d’une régulation catégorialement imparfaite.

Je dis, plus modestement, que la régulation actuelle est un work in progress, que son imperfection catégoriale doit être reconnue ouvertement, et que la construction de la catégorie de remplacement n’est pas un chantier réservé aux législateurs — il appartient aussi à qui travaille quotidiennement dans le software et à qui possède en philosophie du droit les outils pour penser. Qui a les deux pieds dedans peut contribuer plus que qui n’en a qu’un. Et la contribution n’est pas un exercice académique : chaque année passée sans que la catégorie émerge est une année où le contentieux se résout par des voies formelles ne reflétant pas les responsabilités substantielles, où les fournisseurs amont continuent à transférer du risque sans en payer le prix, où les déployeurs finaux continuent à servir de fusibles sans que l’ensemble du système s’améliore.

La salle de Lord Atkin

Je me suis étendu, et qui m’a suivi mérite au moins une synthèse honnête.

Nous sommes arrivés à dire que le concept juridique de produit, bâti au XXᵉ sur une ontologie d’objets bornés, préservables, identifiables, est insuffisant pour le logiciel contemporain — qui est plutôt une orchestration de composants humains et non humains, un événement distribué plus qu’un objet, un concert plus qu’un disque.

Nous avons dit que la régulation européenne, bien que l’effort le plus sérieux jamais tenté, tente de capturer le concert avec les catégories du disque, et que cette tension produit des obligations dont la valeur juridique substantielle est ambiguë.

Nous avons dit qu’à la place de la catégorie de produit, il faut en construire une nouvelle, provisoirement appelable assemblage responsable, qui distribue la responsabilité selon le gradient de l’influence effective en runtime — pas selon la titularité formelle ni selon l’irresponsabilité distribuée.

Nous avons dit que cette construction exige une figure intellectuelle hybride, avec pratique du code et lecture du droit, que le marché ne valorise pas et qui n’existe que par volonté individuelle.

Et nous avons dit que tant que la catégorie de remplacement n’émerge pas, les contentieux continueront à se décharger par des voies formelles ne reflétant pas les responsabilités substantielles, avec des coûts réels pour qui exerce le métier honnêtement.

Le point qui mérite peut-être d’être fixé, à la fin : Lord Atkin en 1932 n’était pas un juriste pur, c’était un juge qui avait vu beaucoup de bouteilles se briser et beaucoup de gens tomber malades, et qui avait compris quelque chose de pratique sur le monde industriel que l’instrumentaire conceptuel précédent ne savait pas dire.

L’arrêt Donoghue v. Stevenson a été possible parce que quelqu’un avait tenu ensemble, dans une seule tête, l’expérience matérielle du monde industriel et la tradition conceptuelle du droit civil. Aujourd’hui, il faut tenir ensemble, dans une seule tête, l’expérience matérielle des systèmes distribués et la tradition conceptuelle du droit de la responsabilité. Tâche qu’on ne peut déléguer, et qu’on ne peut pas finir en un seul essai. Ce qu’on peut faire avec un essai, c’est tenter de nommer le problème, offrir une direction, inviter qui a des outils similaires aux miens à continuer le travail.

La bouteille de Mrs Donoghue était opaque, et dedans il y avait un escargot que personne n’avait vu. Le logiciel contemporain est encore plus opaque, et dedans il y a beaucoup plus d’escargots, et la jurisprudence qui nous protège a été écrite pour un monde où les bouteilles étaient en verre. Il est temps d’écrire la jurisprudence d’un monde où les bouteilles ne sont plus.

L'auteur

Andrea MargiovanniCompliance UE

Je travaille aux côtés d'équipes qui conçoivent des systèmes sous AI Act, CRA, NIS2, RGPD. La règle n'est pas une liste à cocher : c'est une contrainte architecturale, à intégrer dès la conception, pas après.

Voir le parcours →