Qui est responsable des erreurs de l’IA ? Ce que la science-fiction a laissé de côté

Qui est responsable des erreurs de l’IA ? Pas le modèle. La responsabilité reste aux personnes et aux organisations : le développeur qui a construit le système, l’organisation qui l’a déployé, l’opérateur qui le fait tourner et, dans certaines limites, l’utilisateur qui agit sur ses résultats. Nommer ces rôles est facile. Le plus difficile est de décider, avant le lancement, lequel d’entre eux porte quelle décision.

La science-fiction a passé quatre-vingts ans à décrire des machines qui construisent, calculent et parlent. L’essentiel est arrivé : l’ordinateur qui répond aux questions, l’assistant qui écrit du code, l’agent qui exécute un workflow pendant la nuit. Le genre avait raison sur la capacité et restait discret sur la responsabilité. En 2026, la capacité ne coûte pas cher ; la responsabilité est donc la part qu’un chef d’entreprise doit concevoir.

Les règles d’Asimov (1942)

En 1942, dans la nouvelle « Runaround », Isaac Asimov écrit trois règles pour les robots. Les récits classiques qui suivent reposent sur une règle confrontée à une situation qu’elle n’avait pas prévue. Le robot obéit à la lettre, manque l’intention, et personne n’a établi qui répond de ce qui se passe ensuite. Les règles existaient. Un responsable identifié, non.

HAL (1968)

HAL, l’ordinateur de 2001 : l’Odyssée de l’espace (1968), parle, planifie et pilote un vaisseau spatial. Aucun propriétaire ne signe pour lui. Quand son jugement et les intérêts de l’équipage divergent, il n’y a ni piste d’audit que quelqu’un lit, ni condition d’arrêt convenue, ni voie d’escalade. La seule supervision humaine qui reste, c’est un membre de l’équipage qui le débranche à la main. La capacité est arrivée la première ; la responsabilité n’est jamais venue.

Les personnes qui construisent, déploient et exploitent le système, chacune pour ce qu’elle maîtrisait. Le développeur répond de la façon dont le modèle et le logiciel ont été faits. L’organisation qui déploie répond devant ses clients d’avoir mis de l’IA dans son produit. L’opérateur répond de son exploitation. L’utilisateur final répond d’avoir agi sur un résultat qu’il aurait pu vérifier.

Ceci n’est pas un conseil juridique. La responsabilité liée à l’IA dépend de la juridiction, du contrat et des faits, et une réclamation peut relever du contrat, de la négligence ou de la responsabilité du fait des produits ; consultez un avocat avant de vous appuyer sur quoi que ce soit ici. Les cadres publics vont dans le même sens : les Principes de l’OCDE sur l’IA tiennent les acteurs de l’IA responsables selon leur rôle, le NIST AI Risk Management Framework demande aux organisations de rendre des équipes et des personnes nommées responsables du risque lié à l’IA, et l’AI Act européen répartit les obligations entre fournisseurs et déployeurs.

Les failles apparaissent là où les rôles se recouvrent. Une entreprise qui construit son propre outil d’IA et l’utilise avec ses clients est à la fois développeur, organisation qui déploie et opérateur, et chaque équipe suppose qu’une autre porte le risque. Alors, qui est responsable quand l’IA échoue dans ce cas ? Celui qui a été nommé à l’avance, ou personne.

La partie bon marché

Une plateforme d’IA peut produire un prototype fonctionnel en une soirée. Nous utilisons ces outils nous-mêmes, dans notre ingénierie et dans Vendo AI, notre propre produit de vente. Le résultat doit tout de même être vérifié : le 2026 GenAI Code Security Report de Veracode relève un taux de réussite de 56 % aux contrôles de sécurité sur plus de 100 modèles, et dans la Stack Overflow Developer Survey, la confiance des développeurs dans l’exactitude des résultats de l’IA est tombée de 40 % à 29 %. Rien de cela ne rend les outils mauvais. Cela en fait des outils.

La partie coûteuse

Ce dont une entreprise a besoin après le prototype, c’est d’un système qui continue de fonctionner : une architecture qui survit à la croissance, des données traitées correctement, une sécurité vérifiée plutôt que supposée, et une personne nommée qui répond quand quelque chose casse à deux heures du matin. Pour un responsable produit, la gouvernance de l’IA se résume à quatre décisions, écrites avant le lancement :

• →Un responsable nommé : une personne, pas un comité, qui peut arrêter le système et répond du résultat.
• →Une piste d’audit : ce que le système a reçu, ce qu’il a produit et qui l’a approuvé, conservée pour la traçabilité et l’explicabilité.
• →Des conditions d’arrêt : là où l’IA ne doit pas agir seule, comme les paiements, les décisions automatisées concernant des personnes ou tout ce qui sort de son périmètre documenté.
• →Une voie d’escalade : qui est appelé, en combien de temps, et ce que voit l’utilisateur pendant qu’une personne prend le relais.

Aucune de ces décisions n’est une clause qu’un avocat ajoute à la fin. Chacune change l’architecture, l’interface, la documentation et le coût d’exploitation ; chacune a donc sa place dans la logique produit dès le départ. L’humain dans la boucle n’a de sens que si cette personne a l’autorité, l’information et le temps de passer outre la machine.

Notre règle est courte : pas de développement sans logique produit. Un opérateur produit décide de ce qui mérite d’être construit, le construit pour être exploité et répond du résultat. Pour un nouveau produit, la responsabilité commence avant la première ligne de code.

Le Leadership Gate est le moment où la responsabilité devient une décision. Il a un seul responsable, le CEO, et se conclut par une décision motivée : poursuivre, remodeler ou refuser. Nous refusons quand la logique produit ne tient pas, quand le modèle commercial ne peut pas soutenir l’exploitation, ou quand nous ne pourrions pas assumer la responsabilité du résultat. La séquence complète est décrite dans comment fonctionne notre processus.

Nous appliquons les mêmes règles à notre propre IA. L’étude de cas Vendo AI montre un produit d’IA responsable en production : chaque source de signaux est un module distinct, à activation volontaire, avec sa propre analytique, et une conversation peut passer à un humain en temps réel. Sur ce site, Vendo AI recueille le contexte et aide à organiser un appel ; il ne prend pas de décisions commerciales et n’émet pas d’offres.

Posez-les à votre propre équipe, à tout prestataire et à tout constructeur d’applications par IA que vous comparez. Les réponses doivent être écrites.

• →Qui est le responsable nommé de ce système en production ?
• →Quelles décisions l’IA peut-elle prendre seule, et lesquelles exigent l’approbation d’une personne ?
• →Qu’est-ce qui est journalisé, pendant combien de temps, et qui le lit quand quelque chose tourne mal ?
• →Quelles conditions arrêtent le système, et qui est appelé quand elles se déclenchent ?
• →Si vous hésitez entre un constructeur d’applications par IA et une équipe : qui répond du système après le lancement ?

Si personne ne peut répondre à la première question, le projet s’arrête au prototype, quelle que soit la vitesse à laquelle il a été fait. Si un produit construit avec l’IA est déjà en ligne, a des utilisateurs et stagne, Existing Product Review est le parcours dans lequel nous examinons le code, la logique métier et le marché, et décidons d’investir ou non.

La science-fiction a prédit les machines. Les règles pour les humains qui les entourent ont toujours été la partie difficile.