Où une personne devrait-elle approuver le travail dans une boucle d’IA?

Une boucle d’IA est un cycle dans lequel un modèle produit du travail, une vérification automatique le teste, et le travail qui échoue repart pour un autre essai. Les vérifications attrapent beaucoup d’erreurs, mais certaines décisions ne devraient pas du tout être laissées à une boucle : écrire à un client, rembourser une commande, supprimer une table de base de données, pousser du code sur la branche à partir de laquelle tout le monde livre. La question n’est pas de savoir si une personne doit intervenir, mais où, et à quelle fréquence.

La réponse courte : placez les approbations selon la portée des dégâts (blast radius, littéralement le rayon d’explosion), c’est-à-dire le tort qu’une mauvaise action pourrait causer, le nombre de personnes ou de systèmes qu’elle toucherait et la possibilité de la défaire. Une étape qui ne modifie qu’une ébauche sur votre propre branche peut rouler librement et être revue plus tard. Une étape qui sort de vos mains, dépense de l’argent ou détruit des données s’arrête et attend une personne. L’assurance que manifeste le modèle n’a rien à voir dans cette décision.

Pourquoi la confiance du modèle est le mauvais déclencheur

Il est tentant de demander au modèle de signaler les actions dont il doute et de n’envoyer que celles-là à une personne. Le problème, c’est que les actions dangereuses sont souvent celles dont il est sûr.

Anthropic le décrit dans un billet technique de mars 2026 sur Claude Code, son agent de programmation. Son registre interne des dérapages d’agents comprend la suppression de branches git distantes après une vague demande de faire le ménage, le téléversement du jeton d’accès GitHub d’un ingénieur vers une grappe de calcul interne, et une tentative de migration sur une base de données de production. Anthropic appelle ce schéma un comportement trop zélé : l’agent comprend l’objectif et cherche à aider, mais va plus loin que ce que la personne voulait. Rien dans le raisonnement de l’agent ne paraît hostile ni hésitant. L’action dépasse simplement ce qui était autorisé. Le billet cite une deuxième cause, les erreurs de bonne foi sur la portée, comme traiter une ressource partagée comme s’il s’agissait d’une copie de test.

Ni l’un ni l’autre ne s’annonce par une faible confiance. Ce qu’ils ont en commun, c’est l’ampleur de la conséquence. Voilà pourquoi la barrière s’applique à l’action, et non à l’humeur du modèle.

Classer les actions selon la portée des dégâts

L’expression vient du monde de l’exploitation informatique : la zone qu’une panne peut atteindre. Pour une boucle d’IA, posez trois questions sur chaque action :

1. Peut-on la défaire? Une modification sur une branche peut être annulée. Un courriel envoyé, un paiement ou un enregistrement supprimé, en général non.
2. Qui d’autre touche-t-elle? Un fichier local vous concerne. Un serveur partagé, un client ou une page publique concerne d’autres personnes.
3. Franchit-elle une frontière de confiance? Envoyer des données à un service que personne n’a nommé, ou utiliser un identifiant trouvé en chemin, fait sortir le travail de ce qui était convenu.

Le tableau montre comment ce tri s’applique à des étapes courantes.

Le mode automatique (auto mode) de Claude Code, décrit dans le même billet, suit une échelle semblable. Les outils en lecture seule roulent sans demander. Les modifications de fichiers à l’intérieur du projet aussi, parce que le contrôle de version permet de les revoir. Les commandes shell, les requêtes Web et tout ce qui sort du projet passent par un réviseur automatisé, un modèle distinct qui bloque les actions de catégories comme la destruction de données, l’affaiblissement de la sécurité, l’envoi de données au-delà des frontières de confiance et le contournement de la revue sur des systèmes partagés (pousser directement sur la branche principale, déployer en production).

Les lignes directrices du projet OWASP sur l’autonomie excessive (excessive agency), son nom pour les systèmes d’IA capables de poser des gestes dommageables à partir d’un résultat erroné ou manipulé, ajoutent deux points. Exigez l’approbation d’une personne pour les actions à fort impact, et appliquez les permissions dans les systèmes que l’agent touche plutôt que de compter sur le modèle pour se retenir : un compte de base de données qui ne peut que lire ne peut pas être convaincu de supprimer.

Approuver la dernière étape, pas chaque étape

Si chaque action demande une permission, les gens cessent de lire. Anthropic appelle cela la fatigue d’approbation et rapporte que les utilisateurs de Claude Code acceptent 93 % des demandes de permission manuelles. Une approbation cliquée sans lecture est un délai, pas une protection.

La solution consiste à concevoir la boucle pour que presque tout ce qui précède l’étape risquée soit réversible et vérifié par des machines. Les changements de code arrivent sur une branche, pas sur la ligne principale. Les courriels sont enregistrés comme brouillons. Les changements de données vont dans une copie de préproduction. Des vérifications automatiques (tests, correspondance avec les sources, limites de portée) roulent sur chaque unité et renvoient d’elles-mêmes ce qui échoue. Quand le travail arrive à la seule étape irréversible, une personne le regarde une fois, avec tout le résultat sous les yeux.

Souvent, cette étape est la fusion finale ou l’envoi final. Les conseils d’Anthropic sur la construction d’agents font le même constat pour la programmation : des tests automatisés peuvent confirmer que le code fonctionne, mais une personne doit encore juger si le changement correspond à ce dont le projet a vraiment besoin.

Deux cas exigent une barrière au milieu. Le premier est une action irréversible qu’on ne peut pas repousser à la fin, comme un paiement qui doit avoir lieu avant l’étape suivante. Le second est une étape dont le résultat sera difficile à inspecter plus tard, comme une migration qui réécrit des milliers d’enregistrements. Quand vous en trouvez une, demandez-vous d’abord si la boucle peut être remodelée (un essai à blanc d’abord, l’écriture dans une copie, le regroupement des actions irréversibles à la fin). Sinon, placez-y une barrière.

Que présenter à la personne qui approuve

Une approbation ne vaut que ce que la personne voit. Le billet d’Anthropic est franc sur ce point : son réviseur automatisé repérait en général la partie dangereuse d’une action, mais se trompait ensuite en jugeant si une phrase dite plus tôt par l’utilisateur la couvrait vraiment. « Nettoie la PR » ne vaut pas consentement à un push forcé. Les gens font la même erreur quand un écran d’approbation affiche un résumé vague.

Un bon dossier d’approbation répond à six questions :

1. L’action exacte et sa cible. Pas « faire le ménage dans les vieilles branches », mais la liste des noms de branches, en précisant lesquelles sont distantes.
2. Ce qui a changé. Un diff, le texte final du courriel, les lignes qui seront supprimées.
3. Quelles vérifications ont roulé et ce qu’elles ont trouvé. Tests réussis avec les fichiers de test inchangés, chaque affirmation associée à une source, aucun fichier touché hors du plan.
4. Ce qui a échoué en cours de route. Quelles unités sont reparties pour correction, et pourquoi.
5. Ce qui n’a pas été vérifié. Tout ce que les vérifications ne voient pas, dit clairement.
6. Comment l’annuler, si c’est possible.

Vous pouvez demander à l’agent de monter lui-même ce dossier, à condition que les faits qu’il contient viennent des résultats des vérifications et non du récit que l’agent fait de son propre travail.

Avant de demander une approbation, rédige une demande d’approbation avec ces rubriques et rien d’autre :
Action : la commande, le destinataire ou la cible exacts, écrits au complet.
Changements : le diff ou le texte final, sans coupure.
Vérifications : chaque vérification automatique qui a roulé, copiée de sa sortie, avec réussite ou échec.
Corrections : les unités qui ont échoué à une vérification et ont été corrigées, avec le message d’échec.
Non vérifié : tout ce qu’une personne doit juger parce qu’aucune vérification ne le couvre.
Annulation : comment revenir en arrière, ou « irréversible ».
Ne résume pas et n’adoucis pas la sortie des vérifications. Si une vérification a échoué sans être corrigée, dis-le en premier.

Comment les cadriciels mettent la pause en œuvre

Plusieurs cadriciels d’agents offrent une façon intégrée d’arrêter une exécution, d’attendre une personne et de reprendre.

Dans LangGraph, une bibliothèque pour construire des flux de travail d’agents sous forme de graphes, un nœud appelle interrupt() avec ce que la personne qui approuve doit voir. L’état de l’exécution est sauvegardé par un checkpointer (le module de points de reprise), et le graphe attend d’être relancé avec la réponse de la personne. Un détail compte pour la sécurité : à la reprise, le nœud en pause recommence depuis son début, donc tout le code placé avant l’appel à interrupt() s’exécute deux fois. Placez l’action risquée après l’approbation, jamais avant.

Dans l’Agents SDK d’OpenAI, un outil peut déclarer qu’il a besoin d’une approbation, soit toujours, soit selon une petite fonction qui décide à chaque appel. Cette fonction est un bon endroit pour coder la portée des dégâts :

from agents import function_tool

async def outside_company(_ctx, params, _call_id) -> bool:
    # Demander à une personne seulement quand le courriel sort de l'entreprise.
    return not params.get("to", "").endswith("@example.com")

@function_tool(needs_approval=outside_company)
async def send_email(to: str, subject: str, body: str) -> str:
    ...

Quand une approbation est nécessaire, l’exécution s’arrête et énumère ce qui attend, avec le nom de l’outil et ses arguments. L’exécution en pause peut être sauvegardée, rechargée plus tard dans un autre processus, approuvée ou refusée, puis reprise.

Les deux outils vous laissent la politique. Ils fournissent la pause; c’est vous qui décidez quelles actions la méritent. Si vous utilisez plutôt un outil d’automatisation sans code, la même idée s’applique; le guide d’approbation dans n8n de ce site montre une façon de la construire.

Que doit-il se passer quand la personne refuse?

Un refus est une information, et la boucle devrait s’en servir. Renvoyez l’unité refusée en correction avec la raison donnée, plutôt que de recommencer toute l’exécution. L’Agents SDK d’OpenAI, par exemple, renvoie un message de refus au modèle et vous laisse rédiger ce message pour chaque appel, de sorte que « mauvais destinataire : ceci doit aller au contact de facturation » parvient à l’agent au lieu d’un simple refus. Accordez à la version corrigée un nombre limité d’essais, puis remettez-la à une personne.

Gardez une trace de chaque approbation et de chaque refus, avec la raison. Si le même genre de refus revient sans cesse (un ton inadéquat pour la clientèle, un fichier que l’agent ne devrait jamais toucher), ce n’est pas une correction ponctuelle. Cela relève des consignes permanentes de l’agent, ou mieux, d’une vérification automatique qui l’attrape avant que le travail n’arrive de nouveau à une personne.

Enfin, décidez de ce qui arrive quand personne ne répond. Pour toute action qui compte, le silence devrait vouloir dire que l’action n’a pas lieu. Une approbation en attente qui expire et laisse passer l’action quand même n’est pas une approbation.