Responsabilité de l’IA : qui répond, et comment le prouver

L’essentiel

• La responsabilité de l’IA n’est pas une qualité morale d’entreprise. Dans le règlement européen sur l’IA, c’est une position juridique attribuée à un rôle nommé, assortie de sa propre ligne dans l’article des sanctions.
• Le règlement ne rend jamais un système responsable. Il désigne cinq rôles humains : fournisseur, déployeur, importateur, distributeur et mandataire.
• L’article 25 peut vous transférer la responsabilité de l’IA sans aucun contrat nouveau. Apposez votre marque, modifiez substantiellement le système ou changez sa destination, et vous en devenez le fournisseur.
• Une responsabilité de l’IA que l’on ne peut pas prouver sur demande reste une intention. Chaque obligation a son artefact : documentation technique, journaux, désignation du superviseur, déclaration de conformité.
• L’article 99 tarife le manquement rôle par rôle, jusqu’à 15 millions d’euros ou 3 % du chiffre d’affaires mondial, et la réparation des dommages relève désormais de la directive révisée sur la responsabilité du fait des produits.

Ce que recouvre vraiment la responsabilité de l’IA

La plupart des définitions de la responsabilité de l’IA s’arrêtent à un sentiment : quelqu’un devrait répondre lorsqu’un système d’IA cause un préjudice. C’est exact et sans portée pratique. Aucun critère pour désigner ce quelqu’un, aucun critère pour dire ce qu’il doit, aucun critère pour vérifier qu’il l’a fait.

Le manuel de l’Alan Turing Institute consacré au sujet propose la décomposition la plus nette disponible. Il distingue deux composantes de la responsabilité de l’IA : la capacité à rendre des comptes, c’est-à-dire l’obligation de fournir aux personnes concernées des justifications claires et accessibles des décisions et de leurs effets, et l’auditabilité, c’est-à-dire la capacité démontrable, fondée sur des preuves, d’établir comment un système a été conçu, construit et exploité (Alan Turing Institute). La première relève de ce que vous dites. La seconde, de ce que vous pouvez montrer. Une organisation qui maîtrise la première sans la seconde fait de la communication.

Le même manuel ajoute un second axe, généralement absent des contenus d’éditeurs. La responsabilité de l’IA se déploie dans deux directions temporelles. La responsabilité anticipative regroupe la gouvernance, la justification et la documentation menées en amont et pendant le projet, afin d’éviter le dommage. La responsabilité réparatrice rassemble les mécanismes de recours, de contestation et de correction mobilisés une fois le dommage survenu. La quasi-totalité des articles consacrés à la question « qui est responsable quand l’IA se trompe » ne traite que la seconde, celle vers laquelle on se tourne quand il est déjà trop tard pour que ce soit économique.

Cette distinction transforme ce que la responsabilité de l’IA signifie un lundi matin. Elle cesse d’être une déclaration de valeurs dans une charte pour devenir deux questions concrètes. Qui répond de ce système précis, nommément ? Et quelles preuves remettrions-nous demain à une autorité de contrôle qui nous demanderait de le démontrer ? La gouvernance de l’IA est le modèle opérationnel qui rend ces deux questions solubles.

Une précision avant d’entrer dans le détail juridique, tant les résultats de recherche l’ignorent. La responsabilité de l’IA ne se confond ni avec la transparence, ni avec l’explicabilité. Ces dernières sont des moyens : l’explicabilité vous aide à répondre, la journalisation vous aide à prouver. La responsabilité de l’IA est la relation elle-même, celle par laquelle une partie nommée doit rendre compte d’une décision à qui est fondé à le lui demander.

Les cinq rôles que le règlement rend responsables

Lorsqu’on demande si une IA peut être tenue pour responsable, on pose une question que le droit a déjà écartée. Le règlement européen n’attribue pas d’obligations aux systèmes. Il en attribue aux opérateurs, et il en nomme cinq.

Rôle	Critère de qualification	Obligation centrale	Article
Fournisseur	Développe un système, ou le fait développer, et le met sur le marché ou en service sous son nom ou sa marque	L’ensemble du dispositif haut risque : gestion des risques, gouvernance des données, documentation technique, évaluation de la conformité, enregistrement	Article 16
Déployeur	Utilise un système sous sa propre autorité dans un cadre professionnel	Respecter la notice, désigner une supervision humaine, surveiller et suspendre, conserver les journaux, informer les travailleurs et les personnes concernées	Article 26
Importateur	Met sur le marché de l’Union un système provenant d’un fournisseur établi hors de l’Union	Vérifier l’évaluation de la conformité, la documentation et le marquage avant la mise sur le marché	Article 23
Distributeur	Met un système à disposition sur le marché, sans être fournisseur ni importateur	Vérifier le marquage et la documentation, agir en cas de suspicion de non-conformité	Article 24
Mandataire	Désigné par écrit par un fournisseur établi dans un pays tiers	Vérifier l’existence de la déclaration et de la documentation, les conserver 10 ans, donner accès aux journaux, résilier en cas de manquement	Article 22

Le terme générique retenu par le règlement pour les désigner tous est celui d’opérateur. La plupart des organisations qui lisent ces lignes sont des déployeurs, et la plupart ne l’ont jamais formalisé. Si votre entreprise utilise l’outil d’un éditeur dans un cadre professionnel, vous êtes le déployeur de ce système, et les obligations de l’article 26 vous incombent quoi qu’en dise la documentation commerciale de l’éditeur. Notre guide opérationnel du règlement européen sur l’IA détaille l’ensemble des obligations par rôle.

Le mandataire mérite un arrêt, car c’est le rôle doté de véritables prérogatives. Un fournisseur établi hors de l’Union doit en désigner un par mandat écrit avant toute mise sur le marché d’un système à haut risque. Ce mandataire vérifie que la déclaration UE de conformité et la documentation technique ont bien été établies et que l’évaluation de la conformité a été réalisée, tient la documentation à la disposition des autorités pendant dix ans, et fournit aux autorités compétentes les informations utiles, y compris l’accès aux journaux générés automatiquement. Et s’il vient à estimer que le fournisseur agit contrairement à ses obligations, il doit mettre fin au mandat et en informer l’autorité de surveillance du marché en indiquant les motifs (article 22). Le législateur a inscrit un lanceur d’alerte au cœur de la chaîne de conformité.

Article 25 : la responsabilité de l’IA change de mains sans prévenir

C’est le mécanisme de responsabilité de l’IA le plus susceptible de coûter cher à un déployeur, et il est presque absent des commentaires publiés.

Vous pouvez devenir le fournisseur d’un système à haut risque sans rien signer de nouveau. L’article 25, paragraphe 1, prévoit trois déclencheurs (article 25) :

1. Vous apposez votre nom ou votre marque sur un système à haut risque déjà mis sur le marché, sauf stipulation contractuelle répartissant autrement les obligations.
2. Vous apportez une modification substantielle à un système à haut risque, de telle sorte que sa conformité s’en trouve affectée ou que sa destination change, et qu’il demeure ou devient à haut risque.
3. Vous modifiez la destination d’un système, y compris un système d’IA à usage général non initialement classé à haut risque, de sorte qu’il le devienne au sens de l’article 6.

Le troisième déclencheur est celui de notre époque. Prenez un modèle à usage général, affinez-le sur vos propres données, et orientez-le vers le tri de candidatures ou l’octroi de crédit. Vous n’avez pas acheté un système à haut risque : vous en avez fabriqué un, et vous en êtes désormais le fournisseur, avec l’intégralité du dispositif de l’article 16, évaluation de la conformité comprise.

Le sort de l’éditeur d’origine est tout aussi peu commenté. En vertu de l’article 25, paragraphe 2, le fournisseur initial cesse d’être considéré comme le fournisseur de ce système. Il n’est pas libéré pour autant : il doit coopérer étroitement avec le nouveau fournisseur et lui transmettre la documentation technique, les limites et modes de défaillance connus, ainsi que l’accès technique ciblé nécessaire à la mise en conformité. Une réserve mérite néanmoins de figurer dans toute discussion d’achat. Ce devoir de coopération tombe si le fournisseur initial a expressément exclu que son système puisse être transformé en système à haut risque. Un éditeur peut contractuellement se dispenser de vous aider, et beaucoup le feront.

L’article 25, paragraphe 4, referme la boucle en imposant aux fournisseurs et à leurs partenaires tiers de préciser par accord écrit les informations, l’accès technique et l’assistance nécessaires à la conformité. Les composants libres et open source en sont exclus, et le Bureau de l’IA peut publier des clauses contractuelles types volontaires. Si vous assemblez des systèmes à partir de briques, cet accord écrit est votre instrument de responsabilité, et sa place est dans la diligence raisonnable fournisseurs, non dans la revue juridique trois jours avant la mise en production.

Ce que chaque rôle doit produire

Une responsabilité de l’IA que vous ne pouvez pas étayer est une allégation, pas une position. Le règlement se montre inhabituellement précis sur les artefacts, et c’est là que la responsabilité de l’IA devient opérationnelle plutôt qu’incantatoire.

• La documentation technique établie avant la mise sur le marché et tenue à jour, conformément à l’annexe IV. C’est le dossier maître qui atteste des choix de conception, de la gouvernance des données et des tests. Voir notre analyse des exigences de documentation.
• Les journaux générés automatiquement, prévus dès la conception au titre de l’article 12 pour enregistrer les événements sur la durée de vie du système, et conservés par le déployeur au titre de l’article 26, paragraphe 6, pendant une durée appropriée à la destination et en tout état de cause d’au moins six mois, sauf disposition contraire du droit de l’Union ou national.
• Une désignation documentée de la supervision humaine, nommant les personnes physiques qui l’exercent, au titre de l’article 26, paragraphe 2.
• La déclaration UE de conformité prévue à l’article 47, signée par le fournisseur : le moment où la responsabilité de l’IA est formellement assumée par écrit.
• La surveillance après commercialisation prévue à l’article 72, et le signalement des incidents graves au fournisseur et à l’autorité de surveillance du marché au titre de l’article 73. Notre guide du signalement des incidents précise les délais et les seuils.

Pris comme un ensemble, ces artefacts constituent le versant auditabilité de la définition de l’Alan Turing Institute, traduit en obligations juridiques. Chacun répond à une question qu’une autorité peut poser : qu’avez-vous construit, qu’a fait le système, qui surveillait, qui a signé, et qu’avez-vous fait quand cela a dérapé.

La responsabilité de l’IA a un tarif

La meilleure preuve que la responsabilité de l’IA relève du rôle et non de la vertu, c’est que le règlement la tarife rôle par rôle.

L’article 99, paragraphe 4, fixe des amendes administratives pouvant atteindre 15 000 000 d’euros ou 3 % du chiffre d’affaires annuel mondial total, le montant le plus élevé étant retenu, puis énumère les destinataires : les fournisseurs au titre de l’article 16, les mandataires au titre de l’article 22, les importateurs au titre de l’article 23, les distributeurs au titre de l’article 24, les fournisseurs et opérateurs au titre de l’article 25, paragraphes 2 et 4, les déployeurs au titre de l’article 26, les organismes notifiés, ainsi que les fournisseurs et déployeurs soumis aux obligations de transparence de l’article 50 (article 99). Les pratiques interdites de l’article 5 se situent plus haut, jusqu’à 35 000 000 d’euros ou 7 %. La communication d’informations inexactes, incomplètes ou trompeuses à un organisme notifié ou à une autorité nationale compétente expose jusqu’à 7 500 000 euros ou 1 %.

Ce dernier palier mérite qu’on s’y arrête : le compte que vous rendez est lui-même réglementé. Se tromper volontairement dans la réponse constitue une infraction distincte.

L’action publique ne couvre que la moitié du terrain. La réparation des dommages suit une voie séparée, qui a récemment bougé. La proposition de directive sur la responsabilité en matière d’IA a été retirée par la Commission en février 2025 : les demandes des personnes lésées relèvent donc désormais de la directive révisée (UE) 2024/2853 sur la responsabilité du fait des produits défectueux, qui traite les logiciels et les systèmes d’IA comme des produits, applique un régime de responsabilité sans faute dispensant le demandeur de prouver une négligence, élargit le cercle des opérateurs économiques responsables et instaure des présomptions de preuve favorables à la victime. Les États membres doivent la transposer d’ici au 9 décembre 2026 (EUR-Lex). Deux régimes, deux demandeurs différents, un seul ensemble de faits.

Nommer les personnes : compétence, formation et autorité

L’article 26, paragraphe 2, contient trois mots qui mettent discrètement en échec la plupart des dispositifs de supervision. Les déployeurs doivent confier la supervision humaine à des personnes physiques disposant des compétences, de la formation et de l’autorité nécessaires, ainsi que du soutien requis (article 26).

La compétence et la formation s’achètent. L’autorité, non. Elle signifie que la personne désignée peut effectivement arrêter le système. L’article 26, paragraphe 5, le rend tangible : lorsque le déployeur a des raisons de considérer que l’utilisation présente un risque, il doit suspendre l’utilisation du système et en informer le fournisseur. Une fonction de supervision confiée à quelqu’un qui ne peut pas interrompre un service en production sans trois validations ne satisfait pas cette exigence, quoi qu’en dise la matrice de responsabilités. La distinction entre supervision humaine dans la boucle et sur la boucle recouvre exactement celle entre détenir l’autorité et se contenter d’observer.

Deux autres référentiels convergent ici, ce qui rend la correspondance peu coûteuse si vous êtes déjà certifié. La clause 5.3 de la norme ISO/IEC 42001 impose à la direction d’attribuer, de communiquer et d’autoriser les rôles du système de management de l’IA, en produisant des lignes de responsabilité documentées et en habilitant les personnes désignées à vérifier la conformité et à rendre compte des performances à la direction. Les auditeurs lisent cette clause comme une exigence de titulaires nommés sur tout le cycle de vie, et non comme un comité. Notre analyse de l’articulation ISO 42001 et règlement européen montre où la clause et l’article se rejoignent. Côté américain, la fonction GOVERN du cadre de gestion des risques de l’IA du NIST appelle des structures de responsabilité garantissant que les équipes et les personnes concernées sont habilitées, responsabilisées et formées (NIST AI 100-1).

Là où la responsabilité de l’IA se rompt

Quatre modes de défaillance expliquent l’essentiel des ruptures de responsabilité de l’IA.

Pas de rôle, faute d’inventaire. On ne peut pas attribuer la responsabilité de l’IA pour un système dont on ignore l’existence. L’IA fantôme est une défaillance de responsabilité avant d’être une faille de sécurité : un outil non recensé n’a ni fournisseur identifié, ni déployeur identifié, ni superviseur nommé.

Le problème des mains multiples dans les chaînes agentiques. Un enchaînement qui traverse un modèle de fondation, une couche d’orchestration, une base vectorielle et trois prestataires dilue la contribution causale au point que personne ne se sent tenu de répondre. La réponse du règlement est l’accord écrit de l’article 25, paragraphe 4, qui impose de consigner la répartition avant qu’elle ne devienne nécessaire, plutôt que de la plaider ensuite.

Le mythe du contrat. Les stipulations commerciales entre un fournisseur et un déployeur répartissent le risque entre ces deux parties. Elles n’évincent pas les obligations légales que chacun doit aux autorités et aux personnes concernées. Un déployeur qui s’est fait garantir a changé le payeur, pas le responsable.

Le mythe du report. Le règlement omnibus numérique sur l’IA, règlement (UE) 2026/1744, est entré en vigueur le 27 juillet 2026 et a repoussé au 2 décembre 2027 les obligations relatives aux systèmes à haut risque de l’annexe III, et au 2 août 2028 celles de l’annexe I. Il n’a pas tout suspendu. Les pratiques interdites s’appliquent depuis le 2 février 2025, et les obligations de transparence de l’article 50 restent inchangées. Lisez ce décalage comme du temps pour bâtir correctement votre cartographie, non comme une dispense. Notre lecture du paysage réglementaire retrace ce qui a bougé et ce qui n’a pas bougé.

Construire votre cartographie de la responsabilité de l’IA ce trimestre

Sept étapes pour cartographier la responsabilité de l’IA, dans cet ordre.

1. Recensez tous les systèmes d’IA en usage, y compris ceux achetés sur carte bancaire et ceux embarqués dans des logiciels que vous possédez déjà.
2. Qualifiez chacun au regard de l’annexe III et de l’article 6 pour déterminer si les obligations haut risque s’appliquent.
3. Attribuez votre rôle système par système, et non à l’échelle de l’organisation. Vous serez déployeur de la plupart et fournisseur de quelques-uns.
4. Nommez la personne physique exerçant la supervision de chaque système à haut risque, et confirmez par écrit qu’elle détient le pouvoir de suspension prévu à l’article 26, paragraphe 5.
5. Recensez l’artefact qui acquitte chaque obligation et son lieu de conservation : documentation, journaux et durée de rétention, déclaration de conformité, procédure d’incident.
6. Confrontez votre feuille de route aux déclencheurs de l’article 25. Tout projet de marque blanche, d’affinage ou de réaffectation rejoint une liste de surveillance avant le début des développements.
7. Fixez une cadence de revue et un titulaire pour la cartographie elle-même, car les rôles changent dès qu’un système est modifié.

Les étapes 1 à 3 sont celles que les organisations sautent, et toutes les suivantes en dépendent. Un audit d’IA engagé sans elles passe sa première semaine à reconstituer l’inventaire.

Questions fréquentes

Une IA peut-elle être juridiquement tenue pour responsable ?

Non. Aucun ordre juridique ne reconnaît la personnalité juridique aux systèmes d’IA, et le règlement européen n’y prétend pas. Il attribue les obligations à des opérateurs, personnes physiques ou morales : fournisseurs, déployeurs, importateurs, distributeurs et mandataires. Lorsque le débat public demande si l’IA peut répondre de ses actes, la traduction opérationnelle consiste à identifier le rôle que vous occupez pour un système donné et ce que ce rôle doit au titre de son article. Le système est l’objet de l’obligation, jamais son débiteur.

Pourquoi la responsabilité de l’IA pose-t-elle problème ?

Parce que la contribution causale est distribuée et les traces fugaces. Un résultat unique peut refléter des données d’entraînement choisies par une partie, un affinage par une deuxième, une consigne d’orchestration par une troisième et une décision de déploiement par une quatrième. Ajoutez des systèmes probabilistes qui évoluent à chaque réentraînement, et la chaîne probatoire ordinaire se rompt. La réponse réglementaire consiste à rattacher la responsabilité de l’IA à des rôles et à imposer des artefacts durables, journaux et documentation, pour que le compte rendu survive à cette dilution.

Quelle différence entre responsabilité de l’IA et IA responsable ?

L’IA responsable désigne une démarche : concevoir et exploiter des systèmes avec soin, équité et prudence. La responsabilité de l’IA est relationnelle et rétrospective : une partie nommée doit rendre compte d’une décision à qui est fondé à l’exiger, et en supporte les conséquences si le compte rendu fait défaut. On peut mener une démarche responsable sans être redevable envers personne en particulier. Dans le règlement européen, c’est la seconde notion qui prime, parce qu’elle vient avec un interlocuteur défini, un artefact défini et une sanction définie.

Un contrat avec notre éditeur transfère-t-il la responsabilité de l’IA ?

Pas à l’égard des autorités. Un contrat répartit le risque commercial entre les parties, et il peut jouer au titre de l’article 25, paragraphe 1, point a), où la qualification par la marque s’applique sauf stipulation contractuelle contraire. Mais les obligations légales dues aux autorités de surveillance du marché et aux personnes concernées ne sont pas cessibles par convention privée. Si vous êtes le déployeur, l’article 26 s’applique à vous quoi que dise le contrat de services sur la conformité relevant de l’éditeur.

Que doit contenir un dispositif de responsabilité de l’IA ?

Au minimum : un inventaire des systèmes, une qualification de rôle par système, une classification des risques, un superviseur nommé détenant le pouvoir de suspension, une cartographie des preuves reliant chaque obligation à son artefact et à sa durée de conservation, une voie d’incident et de recours, et un déclencheur de révision qui requalifie les rôles dès qu’un système est modifié. Les dispositifs de responsabilité de l’IA qui s’arrêtent aux principes échouent sur le versant auditabilité, car un principe ne se produit pas sur demande.

Qui répond lorsqu’un modèle à usage général cause un dommage en aval ?

La responsabilité de l’IA dépend ici de ce que vous en avez fait. Le fournisseur du modèle assume les obligations propres aux modèles à usage général. Si vous l’avez affiné ou réaffecté au point que le système obtenu devienne à haut risque au sens de l’article 6, l’article 25, paragraphe 1, point c), fait de vous le fournisseur de ce système, avec l’intégralité du dispositif de l’article 16. Si vous l’avez déployé tel quel pour sa destination initiale, vous portez les obligations de déployeur de l’article 26. La question porte toujours sur l’acte que vous avez accompli, jamais sur le logo apposé sur le modèle.

Conclusion

La littérature disponible sur la responsabilité de l’IA abonde en principes, et les principes ne sont pas la difficulté. La difficulté tient à ce que, en droit européen, la responsabilité est une position que l’on occupe, parfois sans l’avoir voulu, et que chaque position s’accompagne d’un numéro d’article, d’un artefact et d’une amende. Commencez par l’inventaire, attribuez le rôle système par système, nommez la personne qui peut tout arrêter, et rangez les preuves là où vous pourrez les produire en une journée. C’est en cela que consiste la responsabilité de l’IA en pratique. Le reste est commentaire. Pour le modèle opérationnel qui englobe tout ceci, commencez par la gouvernance de l’IA.