Question de dirigeant
« Qui est responsable quand l'agent se trompe ? »
La réponse courte est inconfortable : vous. La responsabilité ne disparaît pas parce qu'une décision a été prise par une machine ; elle se répartit entre celui qui fournit le système et celui qui le met au travail. La bonne question n'est donc pas « qui portera la faute », mais « que pourrai-je prouver le jour où on me la posera ».
00La situation
Le jour où ça arrive
Un remboursement accordé deux fois. Une réponse fausse partie chez un client. Une écriture erronée dans l'ERP. Le jour où un agent se trompe, deux questions tombent en même temps : une question d'exploitation, comment l'arrêter et réparer, et une question de responsabilité, qui répond de ce qui vient de se passer.
Un agent n'est pas un logiciel ordinaire. Un logiciel exécute une instruction écrite à l'avance ; un agent décide de ses étapes. C'est ce qui le rend utile, et c'est ce qui change la nature de l'erreur : elle ne vient plus d'une ligne de code fautive qu'on peut montrer du doigt, mais d'une décision prise dans un cadre. Si ce cadre n'existe pas, la responsabilité se dilue entre l'équipe technique, le métier et le prestataire, et chacun a de bonnes raisons de penser que c'était à l'autre de veiller.
Le marché a déjà payé pour le savoir. Gartner prévoit que plus de quarante pour cent des projets d'agents seront abandonnés d'ici fin 2027, et cite trois causes : des coûts qui dérapent, une valeur métier floue, et des contrôles de risque insuffisants. La troisième est le sujet de cette page. Elle est aussi la seule qui se règle avant l'incident, pas après.
01Le droit
Ce que le droit a déjà tranché
Le règlement européen sur l'intelligence artificielle, le règlement (UE) 2024/1689, n'a pas attendu que la question soit confortable. Il répartit les obligations entre le fournisseur d'un système et celui qui le déploie. Le déployeur, c'est l'entreprise qui met l'agent au travail : vous.
Pour les systèmes classés à haut risque, le texte impose une supervision humaine effective et la journalisation du fonctionnement, et il confie au déployeur la garde de ces journaux. Pour tout le reste, il installe le réflexe que les assureurs, les juges et les donneurs d'ordre adoptent déjà : en cas de litige, la première pièce demandée sera la trace de ce qui s'est passé.
Un point mérite d'être dit sans détour. Un contrôle humain de façade, une case cochée dans une présentation, ne protège personne. Ce qui compte, c'est qu'il existe dans le système lui-même un endroit où une action attend une autorisation, et un endroit où tout s'inscrit. La suite de cette page décrit ces endroits.
02La preuve
Trois artefacts répondent à votre place
En ingénierie, l'ensemble de ce qui entoure le modèle et encadre ses décisions porte un nom : le harnais. Trois de ses organes répondent précisément aux trois questions qu'on vous posera.
La politique de permission
Pour chaque action que l'agent veut entreprendre, une règle décide : autoriser, refuser, ou demander à quelqu'un. Elle vit hors de portée du modèle, qui ne peut ni la voir ni la négocier. C'est elle qui répond à « qui l'a autorisé à écrire dans le CRM ».
Le journal d'audit
Chaque tour de la boucle, chaque appel d'outil, chaque résultat, horodatés. C'est lui qui répond à « que s'est-il passé mardi entre onze heures et midi », et c'est la pièce que le droit désigne comme preuve.
Les bornes
Un nombre maximal de tours, un plafond de dépense, un périmètre d'outils réduit au nécessaire. Elles répondent à « jusqu'où pouvait-il aller », avant même que la question ne se pose.
03Les demandes
Trois demandes à faire avant de signer
Il n'est pas nécessaire de lire du code pour vérifier qu'un prestataire a construit cela. Trois demandes suffisent, et la qualité des réponses dit tout.
« Montrez-moi la politique de permission. »
Si la réponse est « l'agent est bien instruit », ce n'est pas une politique, c'est un vœu. Une politique se montre : une liste d'actions et, pour chacune, autoriser, refuser ou demander.
« Montrez-moi la trace d'une exécution d'hier. »
Pas une démonstration préparée : une exécution réelle, avec ses appels d'outils et ses horodatages. Un système qui ne peut pas la produire aujourd'hui ne la produira pas non plus le jour où vous en aurez besoin.
« Que se passe-t-il si l'action est rejouée ? »
Une coupure réseau, une reprise, et le remboursement part deux fois. La réponse a un nom, l'idempotence, et elle fait l'objet d'une autre page de cette série.
Ce que cela implique en pratique
La responsabilité ne se délègue pas ; la preuve, elle, se construit. Un engagement contractuel dit qui paiera ; une architecture dit ce qui s'est passé. Les deux sont nécessaires, mais seul le second se vérifie avant l'incident. C'est exactement la différence entre une promesse et un artefact : la promesse se lit dans le contrat, l'artefact s'ouvre devant vous.
La boucle, et l'endroit exact où l'humain garde la main
La note de référence montre, schéma à l'appui, où vit la politique de permission : hors du contexte du modèle, à un endroit que l'agent ne peut pas contourner.
Neuf couches, dont quatre qu'on oublie toujours
L'observabilité et la gouvernance sont deux des quatre couches qu'on découvre à la première panne. La note décrit ce qu'elles contiennent, et ce qui manque quand elles manquent.
04Sources
Sources primaires
Vérifiées le 25 août 2026. Cette page fixe un cadre de lecture ; elle ne constitue pas un avis juridique. Pour la qualification de votre système au regard du règlement, l'avis d'un conseil est nécessaire.
- Règlement (UE) 2024/1689 établissant des règles harmonisées concernant l'intelligence artificielle. Texte intégral sur EUR-Lex, articles 12, 13 et 26.
- Gartner, « Over 40% of Agentic AI Projects Will Be Canceled by End of 2027 », communiqué de presse, 25 juin 2025.
- NIST, AI Risk Management Framework, cadre de gestion des risques des systèmes d'IA.
- uniy, Six schémas de l'ingénierie d'agents, note de référence, sections 04 et 05.