Les réponses et les explications de chaque question s’affichent ici une fois le parcours terminé. Elles renvoient alors vers la fiche du glossaire correspondante, où la notion est traitée en entier avec son exemple chiffré.
1. La directive révisée sur la responsabilité du fait des produits inclut explicitement les logiciels et les systèmes d'intelligence artificielle dans la notion de produit. Qu'est-ce que cela change pour la victime d'un dommage causé par un algorithme ?
Elle n'a plus à prouver une faute, le régime étant celui de la responsabilité objective
Le régime européen de responsabilité du fait des produits repose depuis les années 1980 sur une idée simple : celui qui met un produit défectueux en circulation répond du dommage qu'il cause, sans qu'il faille établir une faute de sa part. La victime doit prouver le dommage, le défaut et le lien entre les deux, ce qui est déjà exigeant, mais elle n'a pas à démontrer une négligence. Ce régime avait été écrit pour des objets matériels, et la question de savoir s'il couvrait un logiciel est restée ouverte pendant des décennies, avec cette conséquence pratique qu'une victime de dommage algorithmique se retrouvait souvent renvoyée à la responsabilité pour faute, c'est-à-dire à une preuve qu'elle n'avait aucun moyen de rapporter. La révision tranche en incluant les logiciels et les systèmes d'intelligence artificielle dans la notion de produit, et elle étend la notion de défaut aux défaillances de sécurité, aux mises à jour et à l'apprentissage continu, ce qui vise directement les systèmes qui évoluent après leur vente. Pour un assureur, la conséquence est que le sinistre change de garantie et souvent d'assuré : ce qui se plaidait comme une faute de service se traite désormais comme un défaut de produit.
Fiche du glossaire →2. La directive 2024/2853 institue une présomption réfragable de défectuosité lorsque la preuve du défaut est excessivement difficile en raison de la complexité technique du produit. Appliquée à un modèle opaque, quel effet cela produit-il ?
L'inexplicabilité se retourne contre le fabricant, à qui il revient de prouver l'absence de défaut
L'opacité d'un modèle a longtemps servi d'argument défensif : on ne peut pas montrer ce qui a mal fonctionné à l'intérieur, donc la victime échoue à prouver le défaut, donc l'action tombe. La présomption renverse exactement cette mécanique. Lorsque la complexité technique rend la preuve excessivement difficile, le défaut est présumé, et il revient au fabricant de démontrer que son produit n'était pas défectueux, ce qui suppose d'ouvrir sa documentation d'entraînement, ses jeux de données et ses journaux. L'inexplicabilité, argument technique d'hier, devient une charge juridique, et c'est le point qu'il faut retenir parce qu'il change la valeur de la documentation dans l'entreprise : ce qui n'était qu'une bonne pratique interne devient la pièce sans laquelle on perd. Il faut noter que la présomption est réfragable, ce qui n'est pas un détail : le fabricant garde une défense, mais il doit la construire avec des preuves qu'il est le seul à détenir. Pour la souscription, cela déplace l'examen du risque vers la traçabilité effective du modèle plutôt que vers sa performance annoncée.
Fiche du glossaire →3. La défense du risque de développement exonère le producteur lorsque l'état des connaissances, au moment de la mise en circulation, ne permettait pas de déceler le défaut. Pourquoi tient-elle mal face à une IA embarquée mise à jour à distance ?
L'instant de référence disparaît, le fabricant gardant la maîtrise du produit après la vente
Cette défense repose sur une image précise, celle d'un objet figé à la sortie d'usine : on juge ce que l'on pouvait savoir à cet instant, et ce qui a été découvert après ne peut pas être reproché. L'image tient pour un composant mécanique et cesse de tenir pour un système que son fabricant continue de modifier, puisqu'il conserve la maîtrise du produit par les mises à jour et l'accès à distance. L'instant de référence sur lequel reposait toute l'exonération se dissout alors : à quelle date apprécie-t-on l'état des connaissances, quand le logiciel de janvier n'est plus celui de septembre et que le modèle a continué d'apprendre entre les deux ? Un produit qui n'est jamais fini est un produit dont la responsabilité ne se referme jamais, et c'est une transformation profonde pour l'assurance, qui raisonne d'ordinaire par exercice de survenance ou de réclamation sur des objets stables. Ce qu'il faut retenir n'est pas que la défense disparaît, elle demeure dans le texte, mais qu'elle devient très difficile à invoquer pour celui-là même qui a gardé la main sur le produit après l'avoir vendu.
Fiche du glossaire →4. Un assureur santé utilise un modèle pour tarifer ses contrats individuels. Sous le règlement (UE) 2024/1689, il déploie un système à haut risque au titre de l'annexe III. Qu'est-ce que cette qualification déclenche ?
Gouvernance des données, documentation, journalisation, supervision humaine et évaluation de conformité
L'architecture du règlement est une pyramide de risques, des usages interdits au sommet jusqu'au risque minimal à la base, et c'est sur la catégorie intermédiaire du haut risque que se concentre l'essentiel de la contrainte. On y accède par deux voies qu'il faut savoir distinguer : l'annexe I, quand le système est intégré comme composant de sécurité dans un produit déjà réglementé, et l'annexe III, qui vise huit domaines d'usage autonome sensibles, parmi lesquels l'identification biométrique, l'emploi, les infrastructures critiques et l'accès aux services essentiels. La tarification de contrats d'assurance santé et vie relève de cette seconde voie, ce qui vaut d'être connu du secteur : l'assurance n'est pas spectatrice de ce texte, elle en est un destinataire nommé. La qualification déclenche alors un ensemble d'obligations de procédé plutôt que de résultat, gestion des risques, gouvernance des données, documentation technique, journalisation, transparence, supervision humaine, exactitude, robustesse et cybersécurité, validées par une évaluation de la conformité. Ce sont des obligations sur la manière de construire et d'exploiter le système, et elles se prouvent par des pièces.
Fiche du glossaire →5. Une entreprise trie des candidatures avec un modèle conçu par un tiers, sans mettre en place la supervision humaine prévue. Un candidat écarté conteste. Comment le règlement partage-t-il les rôles ?
Au fournisseur la conception conforme, au déployeur l'usage approprié et la supervision
Le règlement distingue deux rôles et leur assigne des obligations différentes, ce qui est le point d'entrée de toute analyse de sinistre en la matière. Au fournisseur, celui qui conçoit et met sur le marché, reviennent la conception conforme, la documentation et la surveillance après commercialisation. Au déployeur, le professionnel qui met le système en oeuvre dans un contexte concret, reviennent l'usage approprié, le respect des conditions d'utilisation, la supervision humaine et, pour certains, l'analyse d'impact sur les droits fondamentaux. Cette distinction structure le partage de la charge en cas de dommage : une défaillance peut tenir à un défaut de conception, et l'on remonte au fournisseur, ou à un usage inapproprié, et l'on s'arrête au déployeur. Le cas décrit ici relève clairement du second, puisque le manquement porte sur une obligation propre au déployeur. Ce qui rend l'exercice difficile en pratique est la longueur des chaînes de valeur, un système en intégrant souvent d'autres, si bien que la qualification de chacun se discute avant même la responsabilité. Le contrat entre les parties organise leurs recours ; il ne redistribue pas les obligations que le règlement attache à chaque rôle.
Fiche du glossaire →6. Un organisme public met en service un système d'aide à la décision sociale et doit conduire une analyse d'impact sur les droits fondamentaux. En quoi diffère-t-elle de l'évaluation de conformité qui pèse sur le fournisseur ?
Elle porte sur les effets du système dans son contexte d'usage, et non sur sa conception
Les deux exercices se ressemblent par la forme et diffèrent par l'objet, et les confondre conduit à croire une obligation satisfaite quand elle ne l'est pas. L'évaluation de conformité regarde le système lui-même : sa conception, sa documentation, sa robustesse, et elle pèse sur celui qui le met sur le marché. L'analyse d'impact sur les droits fondamentaux regarde ce que le système produira là où on va l'employer, sur les personnes qui y seront soumises, et elle pèse sur le déployeur : discrimination, atteinte à la vie privée, à la dignité, à l'accès à des services. Un même modèle, parfaitement conforme, peut ainsi être sans danger dans un contexte et problématique dans un autre, ce qui est précisément la raison d'être de cette seconde analyse. Elle est due avant le déploiement, ce qui en fait un travail de conception d'usage plutôt qu'un contrôle a posteriori, et elle s'inspire de l'analyse d'impact relative à la protection des données que le règlement général connaissait déjà. Elle vise en particulier les organismes publics et certains acteurs privés fournissant des services essentiels, ce qui la rend directement pertinente pour une partie du secteur financier.
Fiche du glossaire →7. Un assureur refuse automatiquement un contrat sur la seule base d'un score algorithmique. L'article 22 du RGPD, antérieur au règlement sur l'IA, s'applique déjà. Qu'impose-t-il ?
Le droit d'obtenir une intervention humaine, d'exprimer son point de vue et de contester
On parle beaucoup du règlement sur l'IA comme s'il inaugurait l'encadrement des décisions algorithmiques en Europe, et c'est inexact : l'article 22 du règlement général sur la protection des données le fait depuis 2018. Il vise les décisions produisant des effets juridiques ou affectant significativement une personne lorsqu'elles sont fondées exclusivement sur un traitement automatisé, sans intervention humaine réelle. Le principe est que la personne a le droit de ne pas faire l'objet d'une telle décision, avec des exceptions encadrées, et qu'elle bénéficie dans tous les cas de garanties : être informée, obtenir une intervention humaine, exprimer son point de vue et contester. Deux précisions font toute la portée du texte. Le mot exclusivement est le pivot : une validation humaine de pure forme, qui approuve sans pouvoir décider autrement, ne fait pas sortir du champ, et c'est là que se joue la conformité réelle de la plupart des dispositifs. Et le considérant 71 cite le refus automatique d'un crédit en ligne et le recrutement en ligne, l'assurance relevant de la même logique, ce qui signifie qu'un assureur qui automatise une souscription ou une résiliation relève des deux régimes à la fois, celui-ci et le règlement sur l'IA.
Fiche du glossaire →8. Un exploitant entraîne un robot déjà en service à une tâche nouvelle, créant un danger qui n'existait pas. Le règlement européen sur les machines en tire une conséquence. Laquelle ?
Il devient fabricant de la machine modifiée, avec les obligations qui vont avec
Celui qui modifie une machine d'une manière créant un danger nouveau devient fabricant de la machine modifiée, et hérite de l'ensemble des obligations correspondantes : évaluation de conformité, dossier technique, déclaration et marquage. La règle existait en substance sous le régime antérieur, elle est désormais définie, et surtout elle vise expressément les modifications numériques autant que physiques. La difficulté se loge dans son application à un système apprenant, et elle n'est pas théorique : entraîner un robot à une tâche nouvelle, charger une politique de commande fournie par un tiers ou autoriser l'apprentissage continu en exploitation constituent-ils une modification substantielle ? Le critère fourni, l'apparition d'un danger nouveau, suppose de savoir ce que la machine fera après, ce qui est précisément indéterminé. La conséquence assurantielle mérite d'être vue en entier, parce qu'elle surprend les exploitants : un sinistre qui aurait relevé de la responsabilité civile exploitation bascule vers la responsabilité du fait des produits, régime que beaucoup d'utilisateurs de machines ne connaissent pas puisqu'ils ne se pensent pas fabricants. La qualification de l'exploitant, avant celle du dommage, est donc la première question du dossier.
Fiche du glossaire →9. En 2025, la Commission européenne retire sa proposition de directive sur la responsabilité en matière d'IA, qui devait introduire des présomptions de causalité et un accès aux preuves. Que reste-t-il aux victimes ?
Le droit national et le régime révisé de responsabilité du fait des produits
La proposition retirée visait un point que les autres textes ne traitent pas : non pas ce qu'il faut faire pour être conforme, mais comment une victime établit le lien entre un système et son dommage quand elle ne peut pas regarder à l'intérieur. Elle prévoyait pour cela des présomptions de causalité et des mécanismes d'accès aux preuves. Son retrait, annoncé en 2025 faute de consensus et dans un contexte de simplification réglementaire, laisse la responsabilité civile liée à l'IA au droit national et au régime révisé de responsabilité du fait des produits. Il faut mesurer ce que cela veut dire, et ce que cela ne veut pas dire. Ce n'est pas un vide : le régime révisé couvre désormais les logiciels, il est objectif, et sa présomption de défectuosité répond en partie à la difficulté de preuve. Mais il couvre les dommages causés par un produit défectueux, et laisse hors de son champ des situations que la directive retirée visait, notamment les dommages purement immatériels ou ceux qui procèdent d'un usage plutôt que d'un défaut. Le règlement sur l'IA, lui, n'organise aucune indemnisation : c'est un texte de mise sur le marché, dont le manquement se sanctionne par des amendes et non par la réparation d'un dommage. La conséquence pratique est que le régime applicable dépendra du pays autant que des faits.
Fiche du glossaire →