Caviardé

Un peu après trois heures du matin, le 31 octobre 2025, sur la Loop 202 en direction de l’est, à hauteur de la sortie Dobson Road, à Mesa, en Arizona, une Tesla Model 3 est immobile sur une voie de circulation. Pas sur le bord, pas sur la bande d’arrêt d’urgence. Sur la voie, dans le noir, à la vitesse de croisière de ce qui arrive par derrière. Un Ford F-350 la percute de plein fouet. Le conducteur de la Tesla meurt sur place. La Red Mountain Freeway reste fermée pendant deux heures environ et rouvre vers six heures moins le quart, à temps pour le trafic du vendredi matin.

La presse locale fait son travail, ce qui à quatre heures et demie du matin ne représente pas grand-chose. Arizona’s Family écrit que les détails sont limités, qu’un porte-parole du Department of Public Safety parle de deux véhicules impliqués et ne donne aucune information sur les blessés. 12News, plus tard, ajoute que la berline était une Tesla, que le pick-up était un Ford F-350 et que le conducteur est mort. Aucun des deux ne mentionne un système d’assistance à la conduite. Pas parce qu’ils le cachent. Parce qu’ils ne le savent pas. À trois heures du matin, une voiture arrêtée sur une autoroute est une voiture arrêtée sur une autoroute.

Puis il y a le second document, que personne ne lit le 31 octobre et qui existe en vertu d’une obligation fédérale. Depuis 2021, la NHTSA, l’agence américaine de la sécurité routière, impose aux constructeurs un Standing General Order : tout accident dans lequel un système d’assistance à la conduite de niveau 2 était actif dans les trente secondes précédant l’impact doit être signalé, et s’il y a un mort, dans les cinq jours. Tesla signale. Dans le rapport, le véhicule est une Model 3 de 2020. Le champ qui décrit l’état du système indique Verified Engaged. Le mouvement avant le choc indique Stopped. La vitesse indique 0 mph. Temps clair, aucune anomalie de la chaussée. La voiture a été heurtée sur toute sa partie arrière par l’avant du pick-up. Tesla déclare par ailleurs détenir les données de l’enregistreur de bord, la télématique et la vidéo.

Et puis trois champs noirs. Le récit de l’accident, qui expliquerait pourquoi la voiture était arrêtée. La version du logiciel, qui dirait si c’était Autopilot ou le Full Self-Driving qui était actif. Le champ qui indique si ce tronçon de route relevait du domaine d’exploitation approuvé du système. Sur les trois, la même mention, qu’il vaut la peine de reproduire en entier parce qu’elle est le véritable sujet de cet essai : REDACTED, MAY CONTAIN CONFIDENTIAL BUSINESS INFORMATION. Information commerciale confidentielle. Caviardé.

Personne n’a relié le rapport à l’accident pendant dix mois. C’est Electrek qui l’a fait, le 31 août 2026, en croisant les rares champs que la NHTSA laisse lisibles, la ville, le véhicule, le mois et une heure enregistrée en UTC, avec les articles de la presse locale. Converti dans le fuseau de l’Arizona, l’horodatage du rapport tombe un peu après trois heures du matin le 31 octobre, sur la même autoroute, avec la même issue et la même Model 3 de 2020. Le lien entre la mort d’un homme et le fait que son système de conduite était actif a été établi par un journaliste avec un tableur et une conversion de fuseau horaire. Pas par le mécanisme de transparence, qui avait pourtant été conçu pour cela. Electrek a ensuite déposé une demande d’accès aux documents auprès du DPS de l’Arizona et a contacté l’agence pour lui demander si le constructeur lui avait jamais communiqué ce qu’il avait déclaré à la NHTSA, à savoir que le système était actif.

Et c’est le second cas portant la même empreinte. Le 6 octobre 2025, vers vingt et une heures vingt-cinq, sur la I-4 en Floride, à hauteur de Lake Mary Boulevard, dans le comté de Seminole, une autre Model 3 de 2020 est arrêtée sur la voie centrale en direction de l’est. Un semi-remorque tente de l’éviter, la frôle, heurte la glissière et se renverse. La Tesla est projetée contre un second camion. Le conducteur, un homme de quarante-trois ans de Deltona, meurt sur place. La Florida Highway Patrol déclare ne pas savoir pourquoi la voiture était arrêtée au milieu de l’autoroute. Le rapport de Tesla à la NHTSA indique, ici aussi, Verified Engaged, Stopped, 0 mph. Ici aussi, le récit, la version du logiciel et le champ sur le domaine d’exploitation sont noirs.

Entre la Floride et l’Arizona, vingt-cinq jours.

La gêne que je veux laisser au lecteur ne porte pas sur la faute. Elle porte sur une question plus simple, et plus difficile à chasser. Pourquoi ne peut-on pas savoir.

Deux hypothèses, toutes deux inconfortables

La première hypothèse est celle que quiconque a suivi Tesla ces dernières années formule tout seul. Le phantom braking, le freinage brutal sans obstacle, est un problème documenté. La NHTSA a ouvert une évaluation préliminaire en février 2022, sur la base de 354 signalements concernant des Model 3 et Model Y de 2021 et 2022, passés à 758 dès le mois de mai de la même année. Une action collective est pendante devant le tribunal fédéral du district nord de l’Illinois depuis 2023. Mais le dossier doit être lu jusqu’au bout, parce qu’il contient un détail qui complique le tableau au lieu de le simplifier. L’enquête a été clôturée le 29 juin 2026 sans aucune mesure du constructeur, et le rapport de clôture décrit un phénomène typique : une réduction de vitesse de dix à vingt miles par heure, sur un intervalle d’une à trois secondes, que le conducteur surmonte en appuyant sur l’accélérateur. Aucune collision identifiée, aucun véhicule arrivé à l’arrêt complet. Une voiture immobilisée à zéro sur une voie ressemble au phantom braking que la NHTSA a catalogué, et personne, en dehors de Tesla, n’a observé le phénomène d’assez près pour dire s’il s’agit de la même chose.

La seconde hypothèse est plus prosaïque, et c’est celle qu’un policier de la route envisage en premier à trois heures du matin. Un malaise. Un endormissement. Le conducteur cesse de répondre, le système s’aperçoit qu’il n’a plus personne à qui parler et fait ce pour quoi il a été conçu : il ralentit jusqu’à l’arrêt et maintient la voiture là où elle est. Ce n’est pas une hypothèse lointaine. À trois heures du matin, c’est peut-être la plus probable.

Il faut ici résister à la tentation de s’en servir comme d’un acquittement. Un système de niveau 2 qui, ayant perdu son conducteur, laisse le véhicule à l’arrêt sur une voie de circulation d’une autoroute, dans le noir, sans se ranger sur la bande d’arrêt d’urgence et sans se signaler de manière à être vu de qui arrive à cent à l’heure, a un problème de conception de la dégradation. Ce que les normes appellent la condition de risque minimal, l’endroit où un système amène le véhicule quand il ne peut plus continuer, n’est même pas définie pour le niveau 2, parce qu’en théorie le conducteur est toujours responsable. En pratique, quand le conducteur n’est plus là, ce que fait la voiture est décidé par le constructeur, et décidé pour tous ses clients à la fois. Si cette décision est de s’arrêter là où l’on se trouve, l’hypothèse du malaise ne clôt pas la question. Elle la déplace du logiciel qui conduit vers le logiciel qui décide quoi faire quand la conduite s’arrête.

Les deux hypothèses se distinguent d’une seule manière. Le log. La vidéo. La télématique. La séquence des commandes du conducteur dans les trente dernières secondes, l’instant où le système a décidé de freiner et pourquoi, la version du logiciel qui a pris cette décision. Tout cela existe, Tesla déclare dans le rapport même le détenir, et tout cela est ce que le rapport ne contient pas.

Il faut dire une chose sur Electrek avant d’aller plus loin. Le site a une ligne éditoriale ouvertement hostile à Tesla, et l’article sur Mesa fait partie d’une enquête au long cours, avec une page de suivi, qui vise à reconstituer un par un les accidents mortels que le constructeur a signalés à la NHTSA avec le récit noirci. Je le signale parce que le lecteur a le droit de le savoir, et parce que cela ne change rien. Les champs noirs sont dans le document de la NHTSA, pas dans l’article. N’importe qui peut télécharger le fichier et les compter. Electrek l’a fait, et a constaté que Tesla noircit le récit dans 99,9 % de ses rapports, que ses rapports représentent environ 85 % de ceux de toute l’industrie, près de quatre mille accidents, et que General Motors, Ford, Honda et Toyota ne noircissent pratiquement rien. Le constat sur les omissions tient, quel que soit celui qui le formule.

Il faut dire une autre chose, parce que c’est la plus inconfortable pour la thèse de ce texte. Les trois champs que Tesla noircit sont exactement les trois que le Standing General Order permet de noircir. L’ordre de la NHTSA énumère trois exceptions pour lesquelles un constructeur peut demander un traitement confidentiel : le nom de la version du système d’automatisation, l’indication de savoir si le véhicule était dans son domaine d’exploitation, le récit. Tout le reste est public par définition. Tesla n’a pas enfreint la règle. Elle a utilisé la règle jusqu’au bout, à chaque fois. Le mécanisme de transparence a le trou en son centre, et il a été écrit ainsi. La NHTSA a bien ouvert, en août 2025, un audit sur les délais avec lesquels Tesla signale ces accidents, après avoir trouvé des rapports arrivés plusieurs mois après les faits. C’est une enquête sur le moment où l’on signale. Elle ne touche pas à ce que l’on noircit.

Le même rapport devant un juge italien

L’affaire est américaine, le droit européen ne s’y applique pas et ne s’y appliquera pas. Je l’écris tout de suite parce que tout ce qui suit est une expérience contrefactuelle, et je veux qu’elle soit déclarée comme telle. La question est de savoir ce qu’il adviendrait de la même stratégie de défense, j’ai les données mais ce sont des informations commerciales confidentielles, si le produit avait été mis sur le marché européen après le 9 décembre 2026 et si l’affaire se trouvait devant un tribunal italien.

Le 9 décembre 2026 est la date à laquelle devient applicable la directive (UE) 2024/2853 relative à la responsabilité du fait des produits défectueux, qui remplace la directive de 1985 et que l’Italie transpose en réécrivant les articles 114 à 127 du Codice del consumo, le code de la consommation. Le projet de décret législatif, l’Atto del Governo n. 434, a été transmis aux Chambres le 7 août et se trouve en ce moment devant les commissions pour avis. J’y reviens à la fin, parce que la fenêtre dans laquelle on peut encore dire quelque chose est plus courte qu’on ne le pense.

La directive a une réputation, et cette réputation est celle d’un outil d’indemnisation. Elle étend la notion de produit au logiciel, allonge les délais, supprime la franchise, ajoute la destruction et la corruption de données aux dommages réparables. Ceux qui la critiquent disent, non sans raison, qu’il s’agit d’un jeu d’écritures entre assureurs, que l’indemnisation arrive toujours après et qu’après, elle ne sert plus à personne. Ceux qui la défendent énumèrent les victimes qui pourront enfin être payées. Les uns et les autres regardent le moment où l’on signe le chèque.

Le mécanisme qui compte est ailleurs, dans deux articles qui se lisent ensemble. L’article 9 dispose que, à la demande de celui qui a présenté des faits et des preuves suffisants pour rendre plausible la demande, le défendeur est tenu de divulguer les éléments de preuve pertinents dont il dispose, dans la limite de ce qui est nécessaire et proportionné, avec des mesures spécifiques pour protéger les secrets d’affaires. L’article 10, paragraphe 2, point a), dispose que si le défendeur omet de divulguer ces éléments, le caractère défectueux du produit est présumé. Dans le projet italien, ce sont les articles 119 et 120 du nouveau code de la consommation, et la formulation est presque identique.

Relisons le rapport de la NHTSA avec ces deux articles à côté. La famille du conducteur apporte au tribunal le document même du constructeur : système vérifié actif, voiture arrêtée à zéro sur la voie, temps clair, le constructeur déclare détenir l’enregistreur, la télématique et la vidéo. Des faits et des preuves suffisants pour rendre plausible la demande, difficile de soutenir le contraire. Le juge ordonne la divulgation. À ce moment, l’expression « information commerciale confidentielle » change de nature. Devant la NHTSA, c’est une case que l’on coche et que personne n’examine. Devant un juge italien après le 9 décembre, c’est une demande de mesures de confidentialité, que l’article 9 prévoit et accorde, et non un motif pour ne pas remettre les preuves. Et si le constructeur décide malgré tout de ne pas les remettre, le produit est défectueux par présomption, et c’est à lui de démontrer le contraire sans les données qu’il a choisi de garder dans le tiroir.

Le secret d’affaires, dans ce schéma, cesse d’être une défense. Il devient au plus une modalité de remise.

Punir ce que l’on savait, ou ce que l’on ne sait pas dire

Quiconque s’occupe de responsabilité civile depuis assez longtemps sourit quand on lui dit qu’une règle de responsabilité rend les produits plus sûrs. Il a de bonnes raisons. Quarante ans de littérature sur les fautes médicales disent que la peur du procès produit de la médecine défensive plus souvent que de la médecine sûre. Dans une enquête publiée dans le JAMA en 2005, 93 % des spécialistes à haut risque interrogés en Pennsylvanie déclaraient pratiquer la médecine défensive, et 43 % prescrire des examens d’imagerie cliniquement inutiles. Kessler et McClellan, en 1996, avaient montré que les réformes qui réduisent la pression de la responsabilité sur les médecins diminuent les dépenses de 5 à 9 % sans effet notable sur la mortalité ni sur les complications. En Italie, une commission d’enquête parlementaire a estimé en 2013 que la médecine défensive pesait 10,5 % de la dépense de santé, plus de dix milliards d’euros par an. L’argument est sérieux, le lecteur le sait, et il ne se balaie pas d’un revers de main.

Il vaut la peine, pourtant, d’en isoler le pourquoi. La règle de responsabilité classique punit ce que l’on savait. Le médecin répond d’un symptôme qu’il avait sous les yeux et qu’il a négligé, le constructeur d’un défaut qu’il connaissait et qu’il a ignoré. D’où l’incitation perverse, qui est la véritable racine de la médecine défensive comme de l’ingénierie défensive : ne pas regarder. Ne pas faire l’examen que l’on pourrait rater. Ne pas conserver le log qui pourrait finir au dossier. Ne pas rédiger le post-mortem dans un format qu’un avocat adverse pourrait citer. Tout ingénieur qui a travaillé dans une entreprise dotée d’un service juridique actif a entendu au moins une fois le conseil de ne pas mettre telle chose par écrit. Le conseil est rationnel, à l’intérieur de cette règle.

La présomption de l’article 10 fait autre chose, et je crois que c’est la chose la plus importante écrite dans la directive. Elle punit le fait de ne pas être en mesure de dire. Le constructeur qui ne produit pas les données n’est pas sanctionné pour ce que les données auraient révélé. Il est placé dans la position de celui qui a déjà perdu le premier round, quoi qu’il y ait eu dans les données. Le signe de l’incitation s’inverse. Ne pas regarder cesse d’être une posture défensive et devient un aveu. Le log que l’on n’a pas conservé cesse d’être celui qui ne peut pas faire de mal et devient celui qui condamne par son absence. Le conseil du service juridique, à l’intérieur de cette règle, change de sens : conservez tout, et conservez-le sous une forme que nous pourrons remettre.

À cela s’ajoute le quatrième paragraphe du même article, qui vaut d’être lu pour ce qu’il dit du logiciel. Quand la victime rencontre des difficultés excessives à prouver le défaut ou le lien de causalité, en particulier en raison de la complexité technique ou scientifique du produit, et qu’elle démontre qu’il est probable que le produit était défectueux, le juge présume le défaut. Le considérant 48 ajoute que, dans le cas d’un système d’intelligence artificielle, on ne peut pas exiger de la victime qu’elle explique le fonctionnement interne du système. La complexité, qui a été pendant trente ans le bouclier le plus efficace de qui produit du logiciel, cesse de l’être. Le juge ne devient pas ingénieur. Simplement, la difficulté de comprendre le produit revient à la charge de celui qui l’a construit et qui le comprend.

Puis il y a le temps, et c’est le point qui tient tout le reste. La présomption opère avant le jugement au fond. Pas à la fin du procès, après les expertises et les renvois. Au début, au moment où le juge décide qui doit prouver quoi. Cela change concrètement le calcul du producteur : mettre les données sur la table dans les semaines qui suivent les faits, quand il est encore possible d’expliquer, coûte moins cher que d’en défendre l’absence pendant des années. Et les semaines sont l’unité de mesure qui importe ici. La première mort ne s’efface pas par une indemnisation. La seconde s’évite, si les données de la première deviennent lisibles à temps. Entre la I-4 et la Loop 202, vingt-cinq jours se sont écoulés. Personne, en dehors du constructeur, n’a disposé pendant ces vingt-cinq jours des éléments pour se demander si le second cas ressemblait au premier. Le constructeur les avait.

C’est le point que ni les critiques ni les défenseurs de la directive ne mettent au centre. Ce n’est pas une loi sur la sanction. C’est une loi sur la lisibilité.

Ce que l’ingénierie sérieuse fait déjà

Maintenant, la traduction, parce qu’un essai qui s’arrête au principe est un essai que personne ne transmet à ses collègues.

La phrase que je voudrais faire sortir de cette section est simple. La directive rend obligatoire ce que l’ingénierie sérieuse fait déjà. Qui proteste contre la charge proteste, en substance, contre la demande de savoir ce que fait son propre logiciel. Cela dit, il faut détailler ce que cela signifie en pratique, avec à côté l’article qui le rend exigible.

L’observabilité devient un artefact juridique. Jusqu’ici, les logs, les traces, les métriques étaient une commodité des opérations, quelque chose que l’on configurait pour déboguer et que l’on faisait tourner au bout de trente jours pour économiser de l’espace. L’article 9 en fait des éléments de preuve dont le défendeur dispose, et le considérant 42 ajoute que parmi les éléments à divulguer figurent aussi des documents à créer de toutes pièces en compilant et en classant ceux qui existent. Le critère de qualité change. Réussir à déboguer ne suffit plus. Il faut réussir à l’expliquer à un expert judiciaire dans six ans. Ce qui veut dire des logs qui survivent à la rotation, sur un horizon qui couvre au moins les dix ans du délai butoir, des horodatages fiables et dans un fuseau déclaré (l’enquête d’Electrek a été rendue possible par une heure en UTC, et elle aurait été impossible sans), une traçabilité des décisions du système qui reste intelligible à qui ne l’a pas écrite. L’article 9, paragraphe 6, permet au juge d’exiger que les preuves soient présentées de manière facilement accessible et compréhensible. Un dump de trois téraoctets d’événements binaires sans schéma équivaut à ne rien remettre.

Le versioning et la provenance deviennent une question à laquelle on est tenu de répondre. Quel build tournait à ce moment-là, avec quelles dépendances, quelle configuration, quel modèle. Dans le rapport de la NHTSA, la version du logiciel est l’un des trois champs noirs, et c’est le champ qui dirait si le système actif était Autopilot ou Full Self-Driving, deux produits aux capacités et au domaine d’exploitation différents. Le délai butoir de la directive est de dix ans à compter de la mise sur le marché, et dans les cas de dommages corporels qui se manifestent après une longue période de latence, il va jusqu’à vingt-cinq. Qui travaille avec une Software Bill of Materials pour le Cyber Resilience Act a déjà la moitié de l’infrastructure : manifestes des composants, builds reproductibles, immutabilité des artefacts. L’autre moitié est la rétention, et la rétention est une décision budgétaire que presque personne ne prend aujourd’hui à dix ans. J’ai écrit ailleurs que la compliance européenne échoue par manque d’inventaire plus que par manque de normes. La directive ajoute une chose à cet argument : l’inventaire doit porter une date, et la date doit être défendable.

La partie qui concerne l’intelligence artificielle est celle où la directive est plus explicite qu’on ne l’attend d’un texte sur la responsabilité du fait des produits. L’article 7, paragraphe 2, énumère parmi les circonstances à prendre en compte pour apprécier le défaut les effets sur le produit de sa capacité à continuer d’apprendre ou d’acquérir de nouvelles fonctionnalités après la mise sur le marché, et le moment où le produit a quitté le contrôle du fabricant lorsque celui-ci conserve le contrôle après la vente. Le considérant 32 le dit sans détour : un fabricant qui conçoit un produit capable de développer un comportement inattendu reste responsable des comportements qui causent un dommage. L’article 11, paragraphe 2, ferme la voie de sortie classique, celle du défaut survenu plus tard : l’exonération ne vaut pas si le défaut tient au logiciel, aux mises à jour ou à leur absence, tant que le produit est sous le contrôle du fabricant. Et le considérant 19 précise qu’un produit reste sous le contrôle du fabricant tant que celui-ci conserve la capacité de fournir des mises à jour. Un modèle qui dérive est un produit qui change après avoir quitté vos mains, et la directive ne vous libère pas tant que vous gardez la clé. En termes opérationnels : des instantanés des évaluations à chaque version, des model cards versionnées, un suivi de la dérive avec des seuils documentés, et surtout la capacité de reconstituer ce que ce modèle aurait répondu, sur cette entrée, à cette date. Rien de tout cela n’est exotique : toute équipe qui fait du fine-tuning sérieux le fait déjà pour elle-même, le jour où un client demande pourquoi le système a changé d’avis entre mardi et jeudi.

Puis la convergence, qui est la raison pour laquelle cet essai se trouve sur un blog qui parle de compliance comme architecture. Le Cyber Resilience Act et NIS2 imposent des obligations actives avant le dommage : gestion des vulnérabilités, mises à jour de sécurité pendant la période de support, notification des incidents sous vingt-quatre heures. La directive sur la responsabilité du fait des produits intervient après, sur le dommage déjà survenu, et le défaut de fourniture des mises à jour nécessaires au maintien de la sécurité est, dans l’article 11, précisément l’une des choses dont on ne peut pas s’exonérer. L’article 7 ajoute aux critères du défaut les exigences de cybersécurité pertinentes pour la sécurité. Les trois textes se tiennent. La conformité aux deux premiers est la meilleure défense contre la présomption du troisième, parce qu’elle produit, comme sous-produit, la documentation que l’article 9 demande de divulguer. Qui a construit sa SBOM pour le CRA a déjà la réponse à la question de ce qu’il y avait dans le produit à cette date. Qui tient le registre des incidents pour NIS2 a déjà la réponse à la question de savoir quand il a su. Le coût marginal du troisième texte, pour qui a pris les deux premiers au sérieux, est faible.

Le revers de la médaille doit être dit, sinon la section suivante perd sa crédibilité avant de commencer. Tout cela a un coût réel. Conserver des logs structurés pendant dix ans coûte en stockage et en chiffrement. Rendre un build reproductible coûte en temps de pipeline et en discipline. Versionner un modèle avec ses évaluations coûte des heures de personnes qui préféreraient entraîner le suivant. Écrire une documentation technique qui tienne devant un expert judiciaire, et pas seulement devant le collègue qui l’a écrite avec vous, coûte une compétence que le marché ne rémunère pas aujourd’hui et que presque personne n’enseigne. Dans une société de dix personnes, celle où je travaille, ces coûts ne se répartissent pas sur un service juridique interne. Ils se soustraient aux mêmes heures que celles où l’on écrit le produit. Il n’y a pas moyen d’adoucir cela, et je n’essaie pas.

Les objections qui méritent une réponse

Sans cette section, l’essai serait un pamphlet. Les objections qui suivent ne sont pas des hommes de paille. Ce sont les choses que l’on m’a réellement dites, par ordre de force.

La première est que la responsabilité civile n’a jamais sauvé personne. C’est l’objection la plus forte et je l’ai traitée plus haut, alors j’ajoute seulement ici la partie que je n’ai pas dite. Elle est vraie pour la responsabilité qui punit ce que l’on savait. Je n’ai pas de preuve qu’elle soit vraie pour une responsabilité qui punit ce que l’on ne sait pas dire, parce que cette règle n’a jamais été appliquée à grande échelle au logiciel, et nous verrons à partir de 2027 si elle produit ce que sa structure laisse espérer. Je suis prêt à me tromper. Je ne suis pas prêt à traiter la littérature sur les fautes médicales comme si elle parlait d’une règle qui n’est pas la même.

La deuxième est que le délai long et le logiciel-produit écrasent les petites entreprises. Il faut la concéder, parce qu’elle est vraie. La charge pèse de manière asymétrique. Le géant l’absorbe avec un service juridique et un budget de rétention qui ne se voit pas au bilan. La société de dix personnes, non. Un délai de vingt-cinq ans, même limité aux dommages corporels à longue latence, et donc en pratique au médical et à peu d’autres choses, est un horizon qu’aucune petite entreprise italienne n’a jamais eu à planifier. J’ajoute que le rapport du gouvernement accompagnant le projet de décret indique que les associations de victimes de médicaments ont fait valoir l’insuffisance même des délais de trois et dix ans, ce qui dit quelque chose de la direction d’où vient la pression. La réponse n’est pas que tout va bien. La réponse est que le remède se trouve dans la proportionnalité des règles de procédure, dans la mesure où l’article 9 parle déjà de nécessaire et proportionné, et non dans l’abrogation de la règle de fond. Je le dis de l’intérieur d’une société de dix personnes, et je soupçonne que cela pèse autrement que le même argument dans la bouche d’un universitaire. Demander à une petite entreprise de savoir ce que fait son logiciel n’est pas une charge disproportionnée. Lui demander de se défendre avec les mêmes outils procéduraux qu’un constructeur mondial, si, et le décret italien pourrait faire quelque chose sur ce point. Pour l’instant, il ne le fait pas.

La troisième est doctrinale et je la prends au sérieux parce que je l’ai soulevée moi-même il y a quelques mois. Le logiciel n’est pas un produit, et un système qui apprend et modifie son propre comportement ne se réduit pas à la catégorie du bien meuble défectueux. C’est vrai. La catégorie est imparfaite, forcée, et elle tient mal sur les systèmes distribués où personne ne contrôle tout. Mais l’alternative que proposaient les critiques était une directive dédiée à la responsabilité des systèmes d’intelligence artificielle, et elle a été retirée. J’y arrive dans un instant. Dans le vide que le retrait a laissé, la catégorie imparfaite l’emporte sur l’absence de catégorie.

La quatrième est que l’on produira de l’ingénierie défensive, pas de l’ingénierie sûre. Des systèmes hyperprudents, des versions gelées, des fonctionnalités désactivées en Europe, un retrait du marché. Le risque est réel et je ne le nie pas. Une partie de l’industrie réagira ainsi, et pendant un temps certaines choses arriveront en Europe plus tard ou n’arriveront pas. La réplique se trouve dans la structure de l’incitation que j’ai décrite. L’ingénierie défensive classique consiste à ne pas regarder, et c’est précisément la conduite que la présomption punit. Le producteur qui veut se défendre contre la présomption doit produire les données, et pour les produire il doit les avoir collectées, et pour les avoir collectées il doit avoir regardé. Il est possible de construire un système hyperprudent et bien documenté, certes. Il n’est pas possible de construire un système défendable et non documenté, et c’est là le point.

La cinquième est celle du scénario : encore un poids réglementaire européen pendant que les autres courent. Ici, l’affaire de Mesa sert aussi à cela. Elle montre ce que produit concrètement le modèle alternatif, celui où le secret industriel tient. Une famille qui ne sait pas pourquoi. Une police de la route qui enquête sans savoir que le système était actif. Un régulateur qui reçoit le rapport avec trois champs noirs et le classe. Un public qui découvre dix mois plus tard, par un journaliste avec un tableur, qu’il y a eu deux cas identiques à vingt-cinq jours d’intervalle. Les autres courent. Courir sans boîte noire lisible est un choix, et il a un prix que ne paie pas celui qui court.

Le seul instrument qui reste

Il y a dans toute cette histoire une ironie qui mérite sa place.

Le 28 septembre 2022, la Commission européenne avait proposé une directive sur la responsabilité civile en matière d’intelligence artificielle, l’AI Liability Directive. Elle faisait deux choses, et les faisait en ciblant les systèmes à haut risque : elle donnait aux juges le pouvoir d’ordonner la divulgation des preuves techniques détenues par le fournisseur, et elle introduisait une présomption réfragable de lien de causalité entre la faute du défendeur et la sortie du système. C’était, pour l’intelligence artificielle, la version dédiée de ce que les articles 9 et 10 de la directive sur les produits font en général.

Le 11 février 2025, la Commission a adopté son programme de travail pour 2025, présenté au Parlement européen à Strasbourg le lendemain. L’annexe IV énumère trente-sept propositions à retirer. La ligne 32 est la directive sur la responsabilité en matière d’IA, avec une motivation qui vaut d’être citée : aucun accord prévisible, la Commission évaluera s’il convient de présenter une autre proposition ou de choisir un autre type d’approche. Le retrait formel a été publié au Journal officiel le 6 octobre 2025. Le 3 décembre, la commission des affaires juridiques du Parlement a rejeté, par vingt-deux voix contre une, la proposition de le contester. Le dossier est clos.

La conséquence doit être énoncée avec précision, parce qu’il est facile de l’exagérer. L’AI Act ne contient aucune règle sur l’indemnisation : son considérant 9 renvoie explicitement à la directive sur les produits pour la réparation des dommages. Avec le retrait de l’AILD, la directive 2024/2853 est aujourd’hui le seul instrument européen qui harmonise la responsabilité civile pour les dommages causés par des systèmes d’intelligence artificielle, et elle le fait dans les limites de la responsabilité du fait des produits. Tout le reste, et le reste est considérable, demeure aux vingt-sept droits nationaux de la responsabilité extracontractuelle.

Et voici le renversement. Ceux qui ont applaudi le retrait de l’AILD comme une victoire de la simplification devraient être aujourd’hui les premiers à défendre la directive sur les produits, parce que sans elle, ce qui reste n’est pas moins de régulation : ce sont vingt-sept régulations. Pour une entreprise qui vend du logiciel dans cinq pays européens, vingt-sept régimes différents de responsabilité extracontractuelle, chacun avec ses présomptions, ses délais, ses règles d’accès aux preuves, sont un scénario pire qu’une règle harmonisée, même sévère. Axel Voss l’a dit dans les jours du retrait. Il était le rapporteur du Parlement sur l’AILD et siège au Parti populaire européen, donc pas exactement une voix de la gauche régulatrice : il a qualifié le retrait d’erreur stratégique et prédit que la responsabilité en matière d’IA serait dictée par une mosaïque fragmentée de vingt-sept systèmes juridiques nationaux, étouffant les startups et les PME européennes du secteur. Il avait raison, et la directive sur les produits est ce qui nous reste pour l’éviter.

Douze jours, puis quatre-vingt-seize

Je reviens au décret, parce que c’est la partie que l’on peut encore toucher.

La délégation figure dans la loi de délégation européenne 2025, la loi n° 36 du 17 mars 2026, annexe A, point 4. Le Conseil des ministres a approuvé le projet en examen préliminaire le 4 août. Le texte est arrivé aux Chambres le 7 août sous le numéro Atto del Governo n. 434. À la Chambre des députés, les commissions de la justice et des politiques de l’Union européenne ont jusqu’au 16 septembre pour rendre leur avis. Au Sénat, la deuxième commission dispose de quarante jours à compter de la saisine, soit la même échéance. À partir d’aujourd’hui, cela fait douze jours. Ensuite, le gouvernement adopte le texte définitif, et le 9 décembre, quatre-vingt-seize jours à compter d’aujourd’hui, la directive devient applicable aux produits mis sur le marché à partir de ce jour. Pour les produits déjà sur le marché, le régime de 1985 continue de s’appliquer.

Le projet transpose la directive de manière presque littérale, et il y a peu à en dire : le rapport lui-même observe que, s’agissant d’une harmonisation complète, les marges du législateur national sont étroites. La production des preuves est à l’article 119, les présomptions à l’article 120, la dérogation pour le logiciel à l’article 118, paragraphe 2. Tout est à sa place.

Il y a pourtant un point à surveiller, et c’est le seul sur lequel l’État avait un vrai choix. L’article 18 de la directive permet aux États membres de déroger à l’exonération pour risque de développement, la défense par laquelle le producteur s’exonère en démontrant que l’état des connaissances scientifiques et techniques au moment de la mise sur le marché ne permettait pas de déceler le défaut. La dérogation ne peut être introduite que pour des catégories spécifiques de produits, pour des objectifs d’intérêt public, de manière proportionnée et après notification à la Commission. Le gouvernement a choisi de ne pas l’exercer. L’analyse d’impact le motive ainsi : le maintien de l’exonération, déjà prévue par le texte en vigueur, assure la continuité du cadre national et l’uniformité des conditions d’exposition à la responsabilité dans le marché intérieur, tandis que l’introduction d’un régime dérogatoire n’est pas, en l’état, étayée par des éléments qui en démontrent la nécessité.

Je ne suis pas sûr que ce soit le mauvais choix. La défense du risque de développement est raisonnable pour la plupart des produits, et une dérogation généralisée aurait été une erreur. Mais « en l’état » et « éléments » sont des mots qui, dans le cas précis des systèmes qui continuent d’apprendre après la vente, méritent une question en commission. Un fabricant qui conçoit un produit capable de comportements inattendus, et qui garde le contrôle des mises à jour, peut-il vraiment soutenir que l’état des connaissances ne permettait pas de déceler le défaut, quand c’est lui qui décide de ce que le produit enregistre sur lui-même ? La directive limite déjà cette défense à la période pendant laquelle le produit était sous le contrôle du fabricant. Si l’avis parlementaire veut dire une chose utile dans les douze jours qui restent, il pourrait demander au gouvernement d’expliquer pourquoi il n’a pas jugé bon de regarder au moins cette catégorie, et quels éléments il cherchera dans les années à venir pour réévaluer. Une demande modeste, de lisibilité, ce qui est après tout le sujet de tout le reste.

À trois heures du matin sur la Loop 202, une Model 3 est à l’arrêt sur la voie, feux allumés dans le noir. Le système qui la tient là sait pourquoi. Il l’a écrit dans son enregistreur, l’a transmis au constructeur, le constructeur l’a déclaré au régulateur et l’a ensuite recouvert de trois rectangles noirs que le régulateur lui-même lui a permis d’utiliser. Dix mois plus tard, un journaliste a reconstitué le peu que l’on pouvait reconstituer de l’extérieur. La famille, la police de la route et quiconque conduit une Model 3 de 2020 ne savent toujours rien.

La directive européenne sur la responsabilité du fait des produits n’aurait pas sauvé ce conducteur. Aucune loi ne l’aurait fait. Mais elle aurait rendu le constructeur incapable de répondre par un rectangle noir, et cela, vingt-cinq jours après la première mort, aurait pu compter.

Ne pas savoir n’est plus gratuit. C’est la chose la plus utile qu’une loi sur la responsabilité pouvait dire au logiciel.

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 →