Qui est responsable quand une IA se trompe dans un comité ?

L’état du droit

Les textes européens et les doctrines nationales convergent sur un point que les équipes projet sous-estiment encore : un système d’IA n’est pas un sujet de droit. Il n’a pas la capacité d’être responsable. L’AI Act organise des obligations de documentation, de traçabilité et de supervision humaine pour certaines catégories de systèmes. Il ne crée pas une personnalité juridique de l’algorithme. Le RGPD attribue des obligations au responsable de traitement. Le droit des sociétés attribue la décision aux organes compétents. Le droit de la responsabilité civile s’adresse à des personnes, physiques ou morales.

Lorsqu’un comité arrête une décision sur la base d’un livrable produit avec un modèle, la chaîne juridique reste donc classique. L’organisation est responsable vis-à-vis des tiers. En interne, la responsabilité opérationnelle suit les délégations : qui avait le pouvoir d’approuver, qui a effectivement approuvé, qui a omis de contrôler. Le modèle n’apparaît pas dans cette chaîne comme un co-décideur. Il apparaît comme un instrument. Un instrument défaillant n’exonère pas celui qui s’en est servi sans vérification adaptée.

Cette lecture déçoit parfois les équipes qui espéraient un « partage de responsabilité » avec le fournisseur du modèle. Le contrat peut organiser des garanties, des SLA, des clauses d’indemnisation. Il ne déplace pas, à l’égard d’un régulateur ou d’un auditeur, le fait que la décision métier a été prise par l’organisation. Invoquer le fournisseur pour expliquer une erreur de comité est une stratégie de communication. Ce n’est pas une stratégie de gouvernance.

Le droit pose donc une contrainte simple, presque brutale : quelqu’un a signé, ou quelqu’un aurait dû signer. S’il n’y a pas de signataire identifiable, le trou n’est pas comblé par le système. Il est comblé par la responsabilité de l’organe qui a laissé un livrable non validé produire des effets. L’absence de formalisation n’est pas une protection. C’est un risque de reconstitution a posteriori, souvent plus sévère que la formalisation elle-même.

Le problème de la validation à l’aveugle

Le vrai sujet n’est donc pas « qui blâmer ». C’est « comment une personne raisonnable peut-elle valider ». Or, dans une majorité de déploiements, le validateur reçoit un texte achevé, parfois élégant, rarement sourcé. On lui demande d’approuver un résultat dont il ne peut pas juger les fondements. Il a le titre. Il n’a pas les moyens.

Cette validation à l’aveugle prend plusieurs formes, toutes courantes. Le comité reçoit une synthèse sans extraits. Le manager coche une case dans un outil de workflow qui n’affiche pas les sources. L’expert « jette un œil » sur un document trop long pour être relu dans le créneau imparti. Dans tous les cas, la signature existe. La connaissance de cause n’existe pas.

Les conséquences sont doubles. Juridiquement, la signature reste opposable : on a validé. Opérationnellement, elle ne protège personne, parce qu’on ne peut pas démontrer que le contrôle a eu lieu. En cas d’erreur, le validateur est exposé sans avoir eu la possibilité de détecter l’erreur. C’est la configuration la moins défendable : responsabilité pleine, moyens nuls.

Il faut aussi nommer un biais organisationnel. Plus le livrable est fluide, plus il invite à la confiance. Un paragraphe bien écrit, un tableau cohérent, un score affiché avec deux décimales produisent un effet d’achèvement. Le cerveau du comité traite l’objet comme déjà décidé. La revue devient un rituel de politesse. Ce n’est pas un défaut de caractère des dirigeants. C’est un défaut de design : on présente un résultat isolé au lieu de présenter un dossier à juger.

La validation à l’aveugle n’est donc pas un problème de formation « à l’IA ». C’est un problème d’interface de décision. Tant que le signataire ne voit pas ce qu’il faudrait voir pour refuser, il ne peut pas valider. Il peut seulement endosser.

La chaîne de responsabilité formalisée

Une chaîne utile distingue des rôles, et refuse de les fusionner. Trois positions suffisent dans la plupart des rituels.

L’opérateur produit le brouillon. Il déclenche le run, rattache les sources, corrige ce qui relève de son périmètre. Il n’a pas le pouvoir d’approuver pour le comité.

Le réviseur confronte le livrable à la preuve. Il peut renvoyer, demander un complément, signaler une source manquante. Son acte est un avis motivé, pas une signature finale. S’il n’a pas accès au lineage, son avis n’a pas plus de valeur qu’une relecture de forme.

L’approbateur signe. Il engage l’organisation pour ce run. Son identité, son rôle et l’horodatage ferment la chaîne. Il doit pouvoir refuser. Un workflow qui ne permet que d’accepter n’est pas une supervision humaine. C’est une collecte de consentements.

La formalisation n’a d’effet que si les rôles sont non fongibles. Lorsque la même personne produit, revoit et approuve, la chaîne est un décor. Lorsque l’approbateur peut déléguer d’un clic sans que le dossier suive, la délégation n’est pas tracée. Lorsque le refus n’est pas un état du système, il redevient un commentaire.

Cette chaîne n’ajoute pas de bureaucratie si elle est inscrite dans le rituel déjà pratiqué. Un comité de pricing, un comité des risques, une revue d’assortiment ont déjà des rôles. Ce qui manque, ce n’est pas un organigramme. C’est l’attachement du dossier à l’acte. Le Run Receipt et le statut HITL (brouillon, relu, approuvé) ne créent pas le comité. Ils rendent le comité lisible après coup.

Ce que le validateur doit voir avant de signer

Donner les moyens, concrètement, c’est afficher un ensemble minimal avant que le bouton d’approbation soit actif.

Le validateur doit voir les sources citées, pas un résumé de sources. Chaque affirmation critique ouvre l’extrait. S’il ne peut pas ouvrir, il ne peut pas juger.

Il doit voir le niveau de confiance et ce qu’il signifie. Un score sans seuil métier est un ornement. Un score lié à une règle (« en dessous de ce seuil, la revue est obligatoire ») est une information de décision.

Il doit voir les alternatives écartées lorsque le rituel en comporte. Classer un produit, scorer une dépendance, retenir une formulation : le choix n’est défendable que si l’on sait ce qui n’a pas été retenu, et pourquoi.

Il doit voir qui a déjà revu, et ce qui a été modifié. Une approbation sur un livrable qui a changé après la revue n’est pas une approbation. C’est une signature sur un autre objet.

Il doit pouvoir bloquer. Si la preuve est insuffisante, le système n’offre pas un avertissement cosmétique. Il refuse l’état « approuvé ». C’est la seule manière d’éviter la validation à l’aveugle sans recourir à un discours d’incitation.

Lorsque ces éléments sont présents, une erreur du modèle reste possible. Elle devient une erreur détectable. Le validateur qui a vu les sources et a néanmoins signé assume. C’est le régime normal de toute décision d’entreprise. Le validateur qui n’a rien pu voir n’assume pas : il est exposé. La gouvernance consiste à ne pas produire cette seconde situation.

La question « qui est responsable quand l’IA se trompe » a donc une réponse juridique courte, et une réponse opérationnelle plus utile. Juridiquement, le signataire. Opérationnellement, l’organisation qui a conçu, ou non, les conditions d’une signature informée. C’est cette seconde réponse que l’on peut gouverner. La première, on la subit.