Les boucles d’IA : le vrai virage et la dépendance qu’on vous vend avec

Depuis quelques semaines, le même mot revient dans tous les fils des comptes qui vivent de l’IA : la boucle. Le message est partout identique. Vous ne devriez plus prompter vos agents, vous devriez concevoir des boucles qui les pilotent. C’est répété avec l’assurance de l’évidence, illustré de deux ou trois citations d’ingénieurs respectés, et ça se termine, presque toujours, par le lien vers un produit miracle.

La partie agaçante, c’est que sur le fond, ils ont raison. Le concept est réel, il est même central. La partie qu’ils ne disent jamais, c’est ce que cette boucle coûte vraiment, et surtout à qui elle finit par appartenir. Cet article traite des deux.

Commençons par poser proprement l’objet, parce qu’on ne peut pas critiquer ce qu’on n’a pas défini.

Ce qu’est une boucle, vraiment

Un prompt est une instruction unique. Vous demandez, le modèle répond, et il s’arrête. Tant que vous ne relancez pas, rien ne bouge. Vous êtes le moteur, l’IA n’est que l’outil dans votre main, et un outil ne fait rien seul. C’est ainsi que la quasi-totalité des gens utilisent l’IA aujourd’hui : une requête à la fois, chaque étape passant par eux.

Une boucle, c’est autre chose. C’est un objectif que l’IA poursuit d’elle-même jusqu’à l’atteindre. Vous définissez un but une fois, et le système itère jusqu’à ce qu’il soit rempli. Pensez à un objectif récursif. Le cycle complet tient en cinq temps :

DÉCOUVRIR  →  déterminer ce qu'il y a à faire
PLANIFIER  →  décider comment le faire
EXÉCUTER   →  faire le travail
VÉRIFIER   →  confronter le résultat à l'objectif
ITÉRER     →  pas encore atteint ? réinjecter le résultat et recommencerLangage du code : Shell Session (shell)

Sur ces cinq étapes, trois font tout le travail, et ce sont précisément celles que les gens ratent.

La vérification est le cœur de la boucle. Sans contrôle réel sur le résultat, vous n’avez pas une boucle, vous avez un agent qui se donne raison à lui-même en boucle. Le contrôle est ce qui transforme la répétition en progrès : un test qui passe ou échoue, une condition mesurable, une grille de notation. Sans porte de sortie objective, le modèle corrige sa propre copie, et celui qui a produit le travail est toujours un correcteur beaucoup trop indulgent.

L’état est ce qui fait apprendre la boucle. À chaque passage, l’agent doit se souvenir de ce qu’il a déjà tenté, sinon il refait éternellement la même erreur. Une vraie boucle tient un petit registre à côté : ce qui est fait, ce qui a échoué, ce qui vient ensuite. Le passage suivant reprend au lieu de repartir de zéro.

La condition d’arrêt est ce qui la garde saine. Une boucle sans sortie tourne jusqu’à ce qu’elle réussisse, casse, ou vide votre compte. Toute boucle sérieuse a deux façons de s’arrêter : le succès, et une limite dure (au bout de huit tentatives, on s’arrête et on rapporte). Sautez cette étape et vous avez construit une machine qui peut tourner toute la nuit pour rien.

En une phrase : un prompt confie une instruction à l’IA, une boucle lui confie un travail, un moyen de savoir quand il est terminé, et une règle pour renoncer.

Voilà le cadrage. Maintenant, la partie que les fils promotionnels escamotent.

Le test à quatre cases : quand la boucle est un piège

On vous vend la boucle avant de vous dire quand elle est une erreur. Pourtant le test que les gens sérieux appliquent réellement est simple. Une boucle ne vaut le coup d’être construite que si les quatre conditions suivantes sont vraies en même temps.

La tâche se répète, au moins une fois par semaine. En dessous, le coût d’installation ne se rembourse jamais. Un travail ponctuel reste mieux servi par un seul bon prompt.

Quelque chose peut rejeter automatiquement une mauvaise sortie. Un test, une vérification de type, un build, un linter, une règle dure. Si rien ne peut faire échouer le travail à votre place, la boucle ne fait que tourner à vide.

L’agent peut réellement faire le travail de bout en bout, sans vous en rendre la moitié à traiter à la main.

Le « terminé » est objectif, pas une affaire de jugement. Si la qualité est une question de goût, un humain gagne encore.

Une case manquante, gardez le prompt manuel. La version honnête de tout ce sujet tient là : l’ingénierie de boucles est réelle, et la plupart des gens n’ont pas besoin de la version lourde pour l’instant. Ce n’est pas un manque, c’est une lucidité. Ce que tout le monde peut utiliser, c’est la version légère, et nous y reviendrons. Mais il faut savoir où passe la ligne.

Le seul chiffre qui compte

Les boucles tournent aux tokens, et les tokens sont de l’argent. Le problème n’est pas que chaque étape coûte quelque chose, c’est la manière dont le coût se compose.

À chaque tour, l’agent relit son contexte : l’objectif, le code, le dernier résultat, ce qui a échoué. Tout ce paquet repasse dans le modèle à chaque itération, et il grossit à chaque passage. Une boucle qui tourne dix fois ne coûte pas dix prompts, elle coûte dix prompts dont chacun gonfle. La séparation entre le faiseur et le contrôleur, celle qui élève la qualité, double aussi la facture, puisque deux modèles lisent désormais le travail au lieu d’un.

COUT INDICATIF D'UNE BOUCLE
agent unique, tâche moyenne :        ~50 000 à 200 000 tokens
contexte renvoyé à chaque tour :     grossit à chaque passage
une flotte d'agents en parallèle :   multipliez tout ce qui précèdeLangage du code : Shell Session (shell)

La métrique qui compte réellement, et que presque personne ne suit, c’est le coût par changement accepté. Pas les tokens dépensés ni les boucles lancées. Si la boucle vous rend dix résultats et que vous en jetez six, vous refaites le travail de relecture qu’elle était censée vous épargner. En dessous de 50 % d’acceptation, elle coûte plus qu’elle ne rapporte.

Les boucles échouent aussi en silence. L’ingénieur Geoffrey Huntley appelle ça la « boucle Ralph Wiggum » : l’agent se déclare terminé trop tôt, sort sur un travail à moitié fait, et la boucle continue de tourner et de dépenser sans rien produire. Sans porte dure capable de faire échouer le travail, les boucles ne plantent pas, elles vous facturent dans le silence.

C’est pour ça que la version lourde appartient aux équipes qui ont le budget et les garde-fous pour la faire tourner : plafonds d’itérations, budgets de tokens, modèles bon marché sur les étapes ennuyeuses, supervision. Si ce n’est pas vous, vous ne ratez rien : l’idée centrale fonctionne à une fraction du coût et sans rien de l’installation.

Jusqu’ici, je n’ai fait que rendre sobre un discours qui ne l’est jamais. Mais il manque encore le coût le plus lourd, celui qu’aucun de ces fils ne facture.

Le coût que personne ne facture : la souveraineté

Regardez où tous ces fils atterrissent. Invariablement, sur le même geste : un produit propriétaire. Un bot dans Telegram, un connecteur tiers qui se branche sur « 500 applications et plus », une mémoire à long terme hébergée ailleurs, un modèle choisi pour vous selon la tâche. L’argument de vente est toujours le même triptyque rassurant : pas de code, pas d’hébergement, pas de clés.

Arrêtons-nous une seconde sur cette promesse, parce qu’elle est exactement l’inverse de ce que devrait vouloir quiconque réfléchit à deux fois. « Pas de clés » veut dire que vous remettez les vôtres. Pour qu’une de ces boucles vous prépare un brief matinal de votre boîte mail et de votre agenda, il faut lui donner accès à votre boîte mail et à votre agenda. Pour qu’elle « se souvienne de vous entre chaque conversation », il faut qu’elle stocke ce qu’elle apprend de vous, sur des serveurs que vous ne maîtrisez pas, dans une juridiction que vous n’avez pas choisie, sous des conditions d’utilisation qui changeront sans vous demander votre avis.

On vous vend la commodité, et la commodité est réelle. Mais elle se paie en dépendance, et la dépendance ne figure jamais sur la facture annoncée. Vous ne payez pas seulement des tokens. Vous payez en données, en surface d’attaque, en point de défaillance unique qui n’est pas chez vous, en capacité de partir le jour où le service ferme, augmente ses prix, ou décide que votre usage ne lui convient plus. Un agent qui « agit au lieu de répondre », qui envoie le mail au lieu d’en rédiger le brouillon, qui crée le ticket au lieu de le suggérer, est exactement un agent à qui vous avez délégué le pouvoir d’agir en votre nom dans vos propres systèmes. La question n’est plus « est-ce pratique », elle est « à qui ai-je confié cette clé ».

C’est précisément le point aveugle de tout le contenu qui sature les fils en ce moment. Il traite la boucle comme une fonctionnalité, jamais comme une délégation. Or une boucle est d’abord une délégation : vous sortez du circuit, et quelque chose continue le travail à votre place. Toute la question est de savoir si ce quelque chose vous appartient.

La version souveraine de la boucle

La bonne nouvelle, c’est qu’on n’a besoin de personne. Le mécanisme entier est reproductible chez soi, et il existe deux étages.

L’étage léger d’abord, parce qu’il ne demande rien. Vous pouvez exécuter une boucle à la main dans n’importe quel LLM, avec un seul prompt. Le truc consiste à donner au modèle les trois parties d’un coup : un objectif, des critères de réussite stricts, et un protocole qui le force à se contrôler avant d’avoir le droit de s’arrêter.

BOUCLE AUTO-VÉRIFIANTE  (à coller dans Claude)
Tu vas travailler en boucle jusqu'à ce que la tâche atteigne le niveau requis.

TACHE :
(décrire exactement le résultat attendu)

CRITÈRES DE RÉUSSITE (stricts, aucun passage complaisant) :
- (critère 1)
- (critère 2)
- (critère 3)

PROTOCOLE DE BOUCLE, à répéter à chaque tour :
1. PLANIFIER - énoncer la seule prochaine étape.
2. FAIRE     - produire ou améliorer le travail.
3. VÉRIFIER  - noter le résultat de 1 à 10 sur chaque critère.
               Être brutalement honnête. Lister ce qui reste faible.
4. DÉCIDER   - si chaque critère est à 8 ou plus, écrire "FINAL" et s'arrêter.
               Sinon écrire "J'ITÈRE" et recommencer, en corrigeant
               d'abord le point le plus faible.

RÈGLES :
- Ne jamais déclarer terminé tant qu'un critère est sous 8.
- Chaque passage doit corriger la note la plus basse du VÉRIFIER précédent.
- Ne pas me poser de questions. Faire une hypothèse raisonnable, la noter,
  et continuer.

Commence. Tourne la boucle jusqu'à FINAL.Langage du code : Shell Session (shell)

Le modèle rédige, note son propre travail contre vos critères, trouve le point faible, recommence, jusqu’à passer la barre au lieu de vous tendre la première version à peu près correcte. C’est une boucle, et vous venez de la construire avec un paragraphe. Elle ne sort de nulle part, ne stocke rien, ne se branche sur rien. Elle vit le temps que vous la regardez, et disparaît quand vous fermez l’onglet. Pour 99 % des besoins quotidiens, c’est suffisant, et c’est gratuit.

L’étage lourd ensuite, pour ceux qui en ont vraiment l’usage, mais chez soi. Tout ce que les produits propriétaires assemblent pour vous, vous pouvez l’assembler vous-même, sur votre propre infrastructure. Un agent comme Claude Code fournit déjà les briques : un déclencheur, des instructions réutilisables, la séparation faiseur et contrôleur, des actions réelles via des connecteurs, et la porte de vérification. Le déclencheur, ce n’est pas un service tiers, c’est un cron ou un timer systemd sur votre serveur. La planification, ce sont vos hooks. Les actions, ce sont des serveurs MCP que vous écrivez vous-même, contre vos propres systèmes. Et la porte, le seul élément qui décide si la boucle vous aide ou vous ruine, ce sont vos propres tests, dans votre dépôt, sous votre contrôle.

Dans ce modèle, l’état et la vérification ne quittent jamais votre infrastructure. La mémoire de la boucle est une base que vous hébergez. Les clés restent vos clés. C’est plus de travail au départ, personne ne prétendra le contraire. Mais c’est exactement le sens de l’autonomie : elle a un coût d’entrée, pas un coût de loyer. On paie une fois pour maîtriser sa propre brique, au lieu de payer chaque mois pour dépendre.

Mon avis

Les boucles ne sont pas une mode. Elles marquent un déplacement réel de qui fait le travail : l’IA cesse d’attendre qu’on la pousse à chaque étape et se met à mener le travail seule. Le concept est solide, il est même important, et il ne sert à rien de jouer les sceptiques de principe.

Cela dit, ce n’est pas une chose à courir ni à forcer là où elle n’a rien à faire. La plupart du temps, vous brûlerez de l’argent pour rien. Commencez par ce qui est déjà là et gratuit, la boucle légère dans un LLM, et ne pensez à la version lourde qu’une fois que vous aurez réellement senti que ça ne suffit plus.

Et quand vous y penserez, posez la seule question qui vaille. Pas « quel produit me fait gagner le plus de temps », mais « à qui appartient cette boucle ». Parce que le vrai luxe, dans cette histoire, ce n’est pas l’agent qui fait tout à votre place. C’est l’agent que vous possédez. L’outil est réel, le virage est réel. Reste à ne pas confondre l’autonomie qu’il promet avec la dépendance qu’on vend avec.