L’agent fait la tâche. La boucle fait le travail.

On me demande souvent ce que j’entends par « boucle ».

La confusion est légitime. Le mot sert aujourd’hui aussi bien à désigner un prompt qui se répète qu’une entreprise entièrement autonome.

Voici donc la définition utile : une boucle est un système borné qui lit l’état actuel d’un travail, prend une action, observe le résultat, et utilise ce résultat pour décider de la suite.

Puis elle recommence.

Pas indéfiniment. Jusqu’à ce qu’elle atteigne un résultat défini, qu’elle heurte une limite, ou qu’elle tombe sur une décision réservée à une personne.

Cette dernière phrase, c’est presque toute l’architecture.

Un prompt n’est pas une boucle

Un prompt, ça ressemble à ceci : une question, puis une réponse. Vous demandez un résumé. Le modèle l’écrit. L’échange s’arrête là.

Un workflow planifié, ça ressemble à ceci : une horloge, puis des instructions, puis un résultat. Tous les lundis à huit heures, le système rédige un rapport. Utile, mais ce n’est pas forcément une boucle pour autant. Il peut très bien refaire exactement les mêmes étapes le lundi suivant, sans tenir compte de ce qui est arrivé au rapport précédent.

Une boucle, ça ressemble à ceci : un objectif, puis inspecter, agir, observer, évaluer, et continuer, attendre, s’arrêter, ou remonter à une personne. Le résultat d’une action change l’action suivante.

C’est ce retour qui referme la boucle.

Sans lui, on a de l’automatisation. Parfois excellente. Mais pas un système capable de poursuivre un résultat.

Un exemple filé

Imaginez une équipe opérations dont les commandes clients sont régulièrement bloquées par des informations manquantes. Les gens vérifient plusieurs systèmes, identifient ce qui manque, relancent la bonne personne, revérifient plus tard, et remontent les dossiers les plus anciens. Le travail est répétitif, mais chaque dossier diffère légèrement.

« Utiliser l’IA pour gérer les commandes bloquées » n’est pas une spécification. Une boucle, si.

La mission. Réduire le nombre de commandes clients bloquées depuis plus de 24 heures.

Le déclencheur. Se lancer dès qu’une nouvelle commande se bloque, et revérifier les dossiers non résolus toutes les 30 minutes.

L’état. Pour chaque commande bloquée, la boucle conserve ce qui la bloque, ce qui a déjà été vérifié, qui porte le dossier actuellement, quelles actions ont déjà été tentées, quand la prochaine action est due, et le niveau de confiance du système dans son diagnostic. Cet état compte plus que le modèle. C’est lui qui évite au système de redécouvrir le même problème, de recontacter deux fois la même personne, ou d’oublier ce qui s’est passé lors du passage précédent.

Les actions. La boucle peut inspecter la commande, qualifier le blocage, retrouver une information interne manquante, demander un document, router le dossier vers un responsable, ou préparer une remontée. Son autorité est explicite. Elle peut envoyer une demande interne pour une donnée manquante. Elle ne peut pas promettre une date de livraison à un client, émettre un remboursement, changer des conditions commerciales, ou inventer une information absente du dossier.

L’observation. Après chaque action, la boucle vérifie ce qui a changé. Le document est-il arrivé ? La commande a-t-elle avancé ? Le responsable a-t-il répondu ? Le blocage supposé était-il vraiment le problème ? Le dossier a-t-il dépassé son délai ? L’observation est réécrite dans l’état.

La décision. La boucle a maintenant quatre options.

Continuer. Le diagnostic tient toujours, mais il reste du travail.

Attendre. Une action a été prise et le système patiente sur un événement externe.

Arrêter. La commande est débloquée et le résultat a été consigné.

Remonter. La prochaine action exige un jugement, une autorité, ou une information que le système ne possède pas.

Voilà la boucle. L’IA n’en est qu’un composant. Le système réel, c’est l’opération autour de l’IA : l’état, les permissions, l’évaluateur, les conditions d’arrêt, les règles de remontée.

L’humain n’est pas vaguement « dans la boucle »

Cette formule est devenue un alibi. Une équipe affirme qu’un humain restera dans la boucle, mais ne sait pas dire lequel, à quel moment, sur quelle preuve, avec quelle autorité pour décider de quoi.

Ce n’est pas un contrôle. C’est un vœu pieux.

Un vrai point de contrôle humain porte un nom. Pour la boucle des commandes bloquées, ce pourrait être : remonter au responsable du compte dès que résoudre le dossier changerait le prix, les engagements de livraison, ou les conditions client.

Le système atteint cette limite, rassemble les preuves, pose une seule question, et attend. La personne ne refait pas l’enquête. Elle exerce le jugement que l’opération lui a réservé. Sa décision est ensuite réécrite dans l’état, et la boucle continue.

Le cahier des charges minimal

Avant de construire une boucle, je veux neuf choses écrites noir sur blanc.

Mission. Quel morceau précis de travail cette boucle possède-t-elle ?

Résultat. Quelle condition observable signale que le travail est terminé ?

Déclencheur. Qu’est-ce qui fait tourner la boucle ?

État. Qu’est-ce qui doit survivre d’un passage à l’autre ?

Actions. Qu’a le système le droit de faire ?

Observation. Comment sait-il ce qui s’est passé ?

Évaluateur. Comment distingue-t-il le progrès de la simple activité ?

Limites. À quel moment doit-il arrêter d’essayer ?

Porte. Quelles décisions appartiennent à une personne nommée ?

S’il en manque une, le pilote se rattrapera généralement par la supervision. Quelqu’un fournira le contexte encore et encore, remarquera le travail en double, vérifiera le résultat, corrigera le système, ou décidera quand il doit s’arrêter.

La démo continuera peut-être d’avoir l’air intelligente. L’opération, elle, restera manuelle.

L’évaluateur est la partie difficile

En recherche informatique, le succès se réduit parfois à un test ou à un chiffre. Le système change quelque chose, lance le test, garde le changement si le résultat s’améliore, et recommence.

Les opérations d’entreprise sont moins polies. Un e-mail rédigé n’est pas un progrès du seul fait d’exister. Une exception routée n’est pas résolue du seul fait d’avoir changé de file. Un lead n’est pas qualifié du seul fait qu’un modèle lui a attribué un score. Un pilote IA n’a pas de valeur du seul fait que des employés l’ont utilisé.

L’évaluateur doit mesurer le résultat qui compte réellement pour l’opération. Pour la boucle des commandes bloquées, cela pourrait être le pourcentage résolu sous 24 heures, le temps médian de résolution, les dossiers rouverts après une résolution apparente, les remontées humaines inutiles, et les minutes de supervision par dossier résolu.

Le modèle peut changer. Les outils peuvent être remplacés. C’est l’évaluateur qui garde le système pointé sur la mission.

Commencez par le travail presque automatisé

La meilleure première boucle est rarement le workflow le plus ambitieux de l’entreprise.

Cherchez le travail qu’on décrit ainsi : « On a déjà automatisé presque tout, mais il faut encore que quelqu’un surveille. »

Cette phrase révèle presque toujours le système manquant. L’automatisation exécute des étapes. Une personne fournit l’état, le retour, la gestion des exceptions, et le jugement d’arrêt.

Ne commencez pas par demander quelle plateforme d’agents acheter.

Écrivez les neuf lignes. Définissez ce que la boucle cherche à terminer, ce qu’elle peut observer, comment elle saura si elle a progressé, et l’endroit précis où elle doit s’arrêter pour une personne.

Construisez ensuite la version ennuyeuse.

Le but de la première semaine n’est pas de prouver que l’IA sait exécuter une tâche. C’est de découvrir ce que l’opération exige pour que la boucle puisse se refermer.