La boucle pilote-critiques-référence : 4 principes pour faire travailler une IA longtemps et bien

10 octobre 2026 · Aliocha Iordanoff

Une intelligence artificielle, lorsqu’elle travaille seule, juge presque toujours son propre travail satisfaisant et terminé. Elle relit sa production avec les mêmes intentions que celles qui l’ont guidée pour le produire, elle connaît les difficultés qu’elle a rencontrées et elle se trouve des circonstances atténuantes pour tout ce qui manque. Face à ce comportement, la plupart des utilisateurs compensent de la seule manière disponible : ils relisent eux-mêmes chaque version, signalent ce qui ne va pas, attendent la suivante et recommencent, parfois des dizaines de fois. Dans ce schéma, l’humain fait le contrôle qualité, et l’IA ne peut finalement jamais travailler plus vite que le rythme du relecteur.

Ceci repose sur une conviction encore ancrée chez la plupart des humains, qui est que nous ferions un meilleur travail qu’un robot. Et cela a par ailleurs la conséquence de consommer un temps phénoménal. Probablement que vous avez déjà fait l’expérience, après avoir travaillé quelques heures avec une IA, de vous dire que vous auriez eu plus vite fait de le faire directement vous-même à la main.

Je partage ici la méthode que j’ai construite au cours des 4 derniers mois, en travaillant avec mon IA pour divers projets de réalisation d’ERP ou de routines d’automatisation de certaines tâches fastidieuses avec mon équipe de travail. Elle repose sur 4 principes de fonctionnement et permet d’avoir un pilote qui orchestre de manière très autonome et pendant longtemps un travail, jusqu’à livrer un produit beaucoup mieux fini et beaucoup plus avancé que ce que j’étais capable de faire il y a quelques mois avec l’IA.

1er principe : séparer celui qui produit de celui qui juge

Ce principe consiste à faire évaluer et critiquer un travail par un agent qui ne l’a pas réalisé. Beaucoup d’utilisateurs de l’IA font cela intuitivement, sans que la méthode soit nommée particulièrement, et le plus souvent, c’est fait manuellement. On peut demander à une session de travail d’évaluer le travail réalisé par une autre session. Cette méthode pilote dont je vous parle aujourd’hui consiste simplement à automatiser ce travail.

2ème principe : un agent pilote découpe l’objectif en tâches confiées à des sous-agents

Un agent principal reçoit l’objectif à réaliser et le décompose en plus petites pièces. Chaque pièce est confiée à un sous-agent qui ne s’occupe que d’elle, avec sa propre mémoire de travail. Mon agent pilote est responsable de choisir lui-même ce découpage. Les sous-agents travaillent en parallèle.

L’agent pilote est également responsable de choisir l’ordre dans lequel il lance les sous-agents et ce qu’il assume de paralléliser, notamment lorsque le travail de l’un dépend d’un autre. C’est à lui de gérer cette séquence.

Un modèle de langage traite bien mieux une tâche courte et bien bornée qu’une demande vaste qui l’oblige à tout garder en tête. Le même constat est valable pour une équipe humaine. Cela explique aussi pourquoi une description précise de rôles granulaires produit de meilleurs résultats qu’une fiche de poste floue.

3ème principe : des agents critiques séparés qui ne voient que le résultat fini

Chaque production produite par un agent rencontre un critique distinct du constructeur, qui juge le résultat fini. Par exemple une capture d’écran, un texte rendu, ou une page web affichée. Parce qu’il travaille dans son propre contexte, il ne reçoit ni les explications du constructeur ni l’historique des difficultés qu’il a rencontrées.

Cette séparation est le cœur du dispositif. Un relecteur qui a suivi la fabrication comprend les choix, excuse les compromis et tend à épouser le point de vue de celui qui a produit. Un agent qui partage le contexte du constructeur hérite de la même façon de ses justifications. Un critique qui ne voit que le résultat le juge comme le ferait un client, sur pièce.

4ème principe : le critique compare chaque production à un exemple ou à une grille de critères

Ces boucles de feedback par des agents critiques séparés ne fonctionnent bien que s’ils peuvent comparer côte à côte, en aveugle, 2 choses comparables. La boucle ne doit pas s’arrêter tant que chaque sous-agent n’est pas pleinement convaincu par la qualité obtenue.

Sans référence comparable, la boucle se dégrade en silence. « Améliore la qualité de ce compte rendu de mission » ne donne au critique aucun point de comparaison. Au fil des tours, il tend à s’aligner sur ce qu’il voit et à approuver ce qu’il reçoit. Une référence nommée (un exemple jugé excellent, un cahier des charges, une grille de critères vérifiables) rend visible l’écart entre ce qui est produit et ce qui est attendu.

L’ensemble logique

Mis bout à bout, le circuit est simple. L’objectif est donné en entrée, l’agent pilote le découpe, les sous-agents construisent, les critiques comparent chaque pièce à la référence, et les pièces refusées repartent pour un nouveau tour jusqu’à ce que l’ensemble ait franchi tous les critiques.

Résultats et limites de mes expériences et de celles des autres (arrêt, coût, vérifiabilité)

J’ai mis beaucoup de temps pour arriver à ce système, que je n’ai pas imaginé initialement de cette manière. Il s’est construit petit à petit en rencontrant les limites d’une méthode que j’ai petit à petit améliorée. J’imagine qu’aujourd’hui, en partageant cet état de l’art, je ne suis qu’à une étape intermédiaire d’un processus de construction et d’amélioration qui est loin d’être terminé. Le système est encore loin d’être parfait et contient plusieurs défauts. Je vous en parle ci-dessous, d’abord par souci de transparence et aussi pour que d’autres poursuivent aussi le travail à leur manière et puissent contribuer à trouver les bonnes solutions.

Il y a aussi d’autres expérimentateurs qui ont imaginé des solutions très ressemblantes. En même temps que je prototypais mes pilotes, je pense, par exemple, au gauntlet loop. Le terme vient de l’expression anglaise running the gauntlet, passer entre deux rangées d’assaillants et aller jusqu’au bout. L’entrepreneur Matt Shumer l’a imaginé en juillet 2026 en publiant le prompt, c’est-à-dire l’instruction écrite donnée au modèle, avec lequel Claude a construit seul un jeu vidéo en 3D (récit de l’expérience par Decrypt).

Limite n°1 : la patience infinie

Une boucle réglée sur « jusqu’à ce que le critique soit convaincu » ne s’arrête pas d’elle-même si la référence est hors d’atteinte. Le risque est donc qu’à chaque comparaison le critique soit insatisfait, que le produit reparte en production et que l’agent réitère son travail avec les mêmes défauts ou de nouveaux défauts. Cela peut avoir de multiples causes, telles qu’une instruction de départ insuffisamment précise, une incapacité de l’IA elle-même, des contradictions dans les consignes ou un point de référence insuffisamment précis ou lui-même contenant des paradoxes.

L’atout extraordinaire des IA devient ici leur propre limite. Comme les agents sont indéfiniment patients et infatigables, ils peuvent s’enfermer dans une boucle infinie et ne jamais s’arrêter. Il faut prévoir des mécanismes d’arrêt et des limites.

Limite n°2 : le coût

Des dizaines d’agents qui relisent, comparent et reconstruisent consomment une quantité de calcul sans commune mesure avec une conversation ordinaire dans votre IA.

Le travail d’agents en boucle donne ses résultats les plus solides quand l’arrivée est vérifiable sans ambiguïté. Ça a été notamment le cas quand j’avais un modèle de livrable à reproduire ou un design de page web à atteindre. Anthropic a aussi publié un exemple. Elle a fait travailler 16 agents en parallèle pendant près de 2 000 sessions pour écrire un compilateur C. La ligne d’arrivée est une suite de tests qui passe ou ne passe pas.

Plus la référence du point d’arrivée est vérifiable, plus le coût (en jetons) d’une boucle pilotée est un investissement rentable. Mais le risque est donc d’avoir une explosion de votre consommation de tokens si le support utilisé comme point de comparaison par les agents critiques est insuffisamment précis.

Mon usage : relecture en éventail des propositions commerciales

J’utilise ce mécanisme pour relire une proposition commerciale ou une réponse à un appel d’offres, ou encore pour la refonte graphique de mon site web. Plusieurs critiques travaillent en parallèle et chacun ne connaît qu’un seul référentiel : l’un juge le style, un autre la tarification, un troisième la fiscalité, un quatrième la structure attendue du document ou la conformité au cahier des charges. Un dernier agent joue le rôle de juge exigeant (le juge des critiques) : il confronte chaque remarque au texte produit, écarte celles qui ne sont pas fondées et classe le reste par niveau de gravité. La décision d’envoyer reste humaine.

Un exemple mesuré ce mois-ci sur une réponse à un appel d’offres a mobilisé 5 agents et environ 700 000 tokens (l’unité dans laquelle se mesure et se facture le calcul d’un modèle), en 5 minutes. 2 critiques ont rendu des remarques sur un document de travail interne au lieu du livrable ; le juge les a toutes écartées, ce qui montre bien l’intérêt de sa présence. Le critique de conformité a découvert que la consultation visée était close depuis 3 jours, une information qui figurait déjà dans le dossier. Depuis cette mésaventure, le contexte du dossier se vérifie avant le lancement des critiques.

Autre exemple, la relecture par des agents critiques avant qu’un livrable parte chez le client. Après de multiples expériences et après avoir eu plusieurs fois la sensation que nous avons finalement perdu plus de temps que gagné, j’ai mis une limite pour que la boucle s’arrête à 2 passes. Un document qui ne converge pas en 2 tours a un problème de fond qu’une troisième relecture ne réglera probablement pas.

Appliquer la boucle à un livrable : choisir l’objet, écrire la référence, fixer un budget

Pour utiliser un tel système de façon performante, le travail humain porte sur la définition de ce qui est un bon livrable, et non plus sur la relecture de chaque brouillon.

Choisissez d’abord un objet que votre organisation produit souvent et dont la qualité se reconnaît : une proposition commerciale, une page d’offre, un compte rendu de mission, une fiche produit. Un objet produit une seule fois ne justifie pas un tel effort de mise en place.

Rassemblez ensuite la référence. Cette étape est déterminante pour le succès de votre pilote des boucles critiques. Le meilleur exemple que vous ayez produit ou rencontré, et une liste de critères qu’on peut cocher sont une bonne base de départ. Une Définition du Fait bien écrite est exactement ce dont un critique a besoin. Sans elle, vous obtiendrez une boucle qui tourne longtemps pour approuver ce qu’elle voit.

Fixez enfin une limite de tours et un budget, et gardez le jugement final. La boucle transforme un premier jet en résultat solide beaucoup plus vite qu’une relecture humaine. La dernière marche, celle qui décide qu’un document peut partir sous votre nom, vous appartient.

Vous reconnaîtrez peut-être, dans cette description, ce que devrait appliquer une organisation performante dans une démarche qualité d’amélioration continue, lorsqu’elle sépare la production de la validation, documente ses standards et refuse de confondre « j’ai travaillé dessus » avec « c’est terminé ». Ce pilote de boucles critiques applique cette discipline à des agents qui relisent la 100e version avec la même exigence et la même patience que la première. Il suppose juste que cette exigence soit décrite quelque part dans votre organisation.