Là où une personne garde la main

Deux raisons de rendre la main

Une personne reste sur le chemin. Ce transfert, c’est la pratique de l’humain dans la boucle (human in the loop) appliquée à l’IA, et elle repose sur deux déclencheurs que vous écrivez avant que le système ne tourne. L’agent a épuisé les tentatives que vous lui avez accordées. Ou il s’apprête à faire quelque chose qui ne peut pas être défait.

Le guide d’OpenAI du 15 janvier 2026, A practical guide to building agents (en anglais), nomme les deux, dans sa section sur l’intervention humaine. Il décrit le transfert comme l’agent qui rend la main proprement quand il ne peut pas terminer : à un conseiller humain dans un service client, ou à l’utilisateur dans un outil de développement.

Il existe une troisième voie, à ne pas confondre avec les deux premières. Un bon agent s’arrête parfois de lui-même pour poser une question. La note d’Anthropic d’avril 2026, Trustworthy agents in practice (en anglais), en fait l’un des problèmes les plus difficiles de la conception d’agents. Un agent qui s’arrête à chaque question abandonne l’autonomie qui le rendait utile. Un agent qui force toujours le passage comprend mal ce que veulent les gens. Anthropic rapporte que sur les tâches complexes, Claude vient demander confirmation environ deux fois plus souvent que sur les tâches simples. C’est bienvenu, mais c’est le jugement du modèle. Les deux déclencheurs écrits sont les vôtres, et ils tiennent quoi que décide le modèle.

La méthode autour de la construction se trouve dans Construire un agent IA qui tient.

Quand les tentatives sont épuisées

Le premier déclencheur d’OpenAI est une limite sur les tentatives ou sur les actions. Leur exemple : une demande client que l’agent n’a toujours pas comprise après plusieurs essais.

Vous écrivez le chiffre avant que le système ne tourne, et c’est la personne responsable du processus qui le choisit. Comptez à deux endroits : les tentatives sur une même étape, et le total des actions dans l’exécution. Le second attrape la boucle où l’agent tourne en rond en progressant lentement, sans jamais répéter exactement la même étape. Un modèle qui continue d’essayer n’est pas cette limite.

Ce que reçoit la personne compte autant que le moment où elle le reçoit. Un transfert qui dit « l’agent a échoué » oblige la personne à repartir de zéro, et elle cessera vite de faire confiance au système. Le transfert doit transmettre l’entrée d’origine, ce qui a été tenté, ce que chaque tentative a donné, et la raison de l’arrêt. Dans le processus de factures qui sert d’exemple à ces guides, cela veut dire la facture, les bons de commande que l’agent a examinés, l’écart qu’il a trouvé, et la règle qui l’a arrêté. La personne règle le dossier en quelques minutes au lieu de tout refaire.

Quand l’action ne peut pas être défaite

Le second déclencheur d’OpenAI est une action à fort enjeu : sensible, irréversible ou coûteuse. Les exemples sont les leurs : annuler une commande, autoriser un remboursement important, effectuer un paiement. Ces actions attendent une personne tant que la confiance dans le système n’a pas grandi.

La même séparation vaut pour toute étape que le processus ne peut pas défaire. Une lecture peut continuer. Une écriture qui déplace de l’argent attend. En pratique, donnez à chaque action l’un de trois réglages : toujours autorisée, soumise à approbation, ou bloquée. Anthropic décrit ce modèle pour les outils de ses propres applications. Un utilisateur peut laisser Claude lire son agenda librement mais exiger une approbation avant qu’il n’envoie une invitation. Vos garde-fous décident des actions bloquées d’office. Cette étape décide de celles qui attendent.

Une approbation ne fonctionne que si la personne qui approuve regarde vraiment. Deux modes d’échec sont bien documentés.

La lassitude d’approbation. Anthropic constate que lorsqu’une tâche demande des dizaines d’actions, les demandes d’approbation répétées deviennent une friction et les gens finissent par ne plus les lire. Leur réponse dans Claude Code est de montrer tout le plan d’emblée, pour relecture et modification, en laissant la personne intervenir à tout moment pendant l’exécution. Appliquez la même idée à un lot. Approuvez quarante factures rapprochées comme un seul plan, avec en tête les trois qui sortent de l’ordinaire, plutôt que par quarante demandes séparées.

Le biais d’automatisation. On a tendance à accepter ce que propose une machine. Le règlement européen sur l’IA le nomme explicitement. Son article 14, consacré au contrôle humain des systèmes qu’il classe à haut risque, exige que les personnes chargées de ce contrôle puissent comprendre ce que le système sait faire et ne sait pas faire, rester conscientes de la tendance à se fier excessivement à ses résultats, interpréter correctement ces résultats, les écarter ou les annuler, et arrêter le système. Que votre système relève ou non de cet article, cette liste fait un bon cahier des charges pour un écran d’approbation.

Concrètement, la personne voit quatre choses avant de décider : l’action proposée, les éléments qui la justifient, ce qui distingue ce dossier d’un dossier normal, et une option de refus aussi simple à utiliser que l’approbation. Ensuite, mesurez. Si l’étape d’approbation ne refuse jamais rien, soit l’agent est excellent, soit l’étape est devenue un tampon, et seules les données peuvent dire laquelle des deux. Une façon de le savoir est de glisser de temps en temps dans la file d’approbation quelques dossiers dont on sait qu’ils sont faux, et de voir s’ils sont repérés. C’est notre pratique, pas une exigence de l’une ou l’autre source.

La façon dont nous menons un processus mesuré jusqu’en production se trouve sur la page agents IA.

Les premières exécutions fixent les limites

OpenAI souligne que le transfert compte surtout au début, parce que c’est là qu’apparaissent les échecs et les cas inattendus, et que se construit un cycle d’évaluation. Les limites que vous avez écrites sont révisées à partir de ces exécutions. Ce n’est pas un slogan ajouté après le lancement.

Chaque transfert est une donnée. Chaque dossier qu’une personne a dû reprendre est un candidat pour l’ensemble d’évaluation. Il montre où l’agent a échoué, et il donne à la version suivante un cas à réussir.

Assouplissez les limites une action à la fois, et seulement sur preuves : l’ensemble de cas passe de façon fiable sur des exécutions répétées, et le journal des transferts montre que la personne approuve cette action sans modification sur une période prolongée. Resserrez immédiatement après un seul mauvais résultat sur une action irréversible. La confiance dans un système qui déplace de l’argent se gagne lentement et se retire vite.

Les deux questions restent sous les yeux de la personne responsable du processus. Combien de tentatives sont permises ? Quelles actions attendent une personne ? Ajoutez-en une troisième une fois le système en service : quand la personne approuve, vérifie-t-elle vraiment ?