L'ère des boucles : pourquoi vos prompts AI sont en train de vous trahir

Imaginez la scène. Il est 23 heures. Vous devez livrer une feature avant demain matin. Depuis une heure, vous échangez avec un assistant de codage AI. Chaque prompt reçoit une réponse. Chaque réponse est collée dans votre projet. Une partie fonctionne. Le reste... moins. Et surtout, vous n'êtes pas vraiment sûr de quelle partie est laquelle.

Ça vous parle ?

Voici la vérité gênante : la plupart des développeurs utilisent les agents AI comme une calculatrice où vous devriez appuyer vous-même sur les touches. Oui, ça fait des calculs. Non, vous ne savez pas vraiment ce qui se passe à l'intérieur. Et quand ça vous sort quelque chose de plausible mais subtilement cassé, c'est vous qui débuggez à minuit.

Les équipes qui livrent vraiment du code production avec de l'AI ont compris autre chose. Elles ont arrêté de considérer l'assistance AI comme un jeu de prompt-et-réponse. À la place, elles construisent des systèmes — des boucles — qui permettent à l'AI de faire des petits changements vérifiables en continu. Les résultats parlent d'eux-mêmes : moins de régressions, moins de surcharge de contexte, et des diffs qu'on peut vraiment relire.

Le problème avec le tout-en-un

Le one-shot prompting a une simplicité séduisante. « Écris-moi un système d'authentification. » C'est fait. « Refactor tout ce module pour utiliser la nouvelle API. » Bam. Ça a l'air productive. Ça a l'air rapide.

Jusqu'au jour où ça ne l'est plus.

Pensez à ce qui se passe vraiment quand vous balancez une grosse tâche à une AI d'un coup. D'abord, vous butez contre le mur du contexte. La plupart des codebases worth working on sont trop volumineux pour tenir entièrement dans la mémoire d'une AI. Du coup, elle commence à deviner les parties qu'elle ne voit pas — en faisant des suppositions sur les dépendances, les conventions de nommage, les patterns architecturaux qui sont peut-être complètement faux.

Ensuite arrive le problème de la review. Si l'AI vous retourne un diff de 500 lignes, qu'est-ce que vous faites exactement ? Vous le parcourez en diagonale. Vous lui faites plus confiance que vous ne le devriez parce que l'AI a l'air confiante. Vous mergez et vous priez.

Le problème avec la prière : ce n'est pas un processus de contrôle qualité.

Le troisième problème est le plus vicieux. Les modèles AI sont entraînés pour être helpful, ce qui veut dire qu'ils sont entraînés pour sembler confiants. Quand une AI vous donne du code qui a l'air raisonnable, il a probablement l'air raisonnable parce qu'elle a été entraînée sur du code raisonnable. Ça ne veut pas dire que c'est correct pour votre contexte spécifique. Sans un gate qui vérifie le comportement réel, la confiance devient votre seul critère d'acceptation — et la confiance est un proxy terrible pour la justesse.

Entrez dans la boucle

L'alternative a l'air presque décevamment simple : au lieu d'un gros prompt, faites plein de petites étapes. Après chaque étape, vérifiez votre travail. Puis faites l'étape suivante.

Agis. Vérifie. Répète.

C'est une agentic loop dans sa forme la plus basique, et si ça a l'air trop évident pour mériter qu'on en parle, sachez que la plupart des équipes ne le font toujours pas. La magie n'est pas dans le concept — c'est dans la discipline de l'appliquer rigoureusement.

Voici à quoi ça ressemble dans la pratique. Au lieu de demander à l'AI de « corriger tous les tests qui échouent », vous feriez :

1. Lancez la suite de tests et identifiez le premier échec
2. Demandez à l'AI de corriger juste cet échec
3. Relancez les tests pour vérifier la correction
4. Si ça passe, passez à l'échec suivant ; si ça échoue, le changement est revert
5. Répétez jusqu'à zéro échec — ou jusqu'à ce que l'AI dise qu'elle ne peut plus progresser

Remarquez ce qui se passe ici. Chaque changement est indépendamment vérifié. Quand quelque chose casse, vous savez exactement quel edit l'a causé. Quand quelque chose fonctionne, ça reste. La boucle construit un cliquet de progrès vérifié plutôt qu'un tas de code « hopefully correct ».

Les trois règles qui font que ça marche

Toutes les boucles ne se valent pas. Une boucle mal conçue est pire que pas de boucle du tout — elle peut tourner indéfiniment en faisant des changements cosmétiques, ou elle peut casser des choses avec confiance tout en paraissant fonctionner. Les boucles qui livrent vraiment ont trois caractéristiques non négociables.

Première : un automated gate qui ne se laisse pas raisonner. Le gate est votre détecteur de vérité. Ça peut être une suite de tests qui passe, un linter qui retourne zéro erreur, un type checker qui confirme l'absence de mismatches, ou une comparaison automatisée de screenshots qui catch des régressions visuelles. Le point critique, c'est que le gate est déterministe et objectif. Vous ne pouvez pas l'expliquer, et l'AI non plus. Si le code ne passe pas le gate, ça n'a pas existé — revert, pas merge.

C'est plus dur que ça en a l'air parce que ça veut dire s'engager à construire l'infrastructure pour vos gates. Vous avez besoin de vrais tests avec une vraie couverture. Vous avez besoin que votre type checker tourne vraiment. Vous avez besoin que la pipeline CI/CD soit une citizen de première classe, pas un afterthought.

Deuxième : un changement par itération. Ça a l'air douloureusement lent quand vous êtes habitué au one-shot prompting. Pourquoi ne pas corriger toutes les erreurs de type d'un coup ? Pourquoi ne pas adresser tous les warnings de linting en un passage ?

Parce que quand vous batchez des changements ensemble et que quelque chose casse, vous n'avez aucune idée de ce qui l'a causé. L'AI pourrait corriger trois choses, en casser une, et le résultat net a l'air positif — donc le changement est mergé. Maintenant vous avez une régression sans coupable clair.

Un changement, une vérification, un verdict. C'est plus lent par étape, mais c'est monumentally plus rapide dans l'ensemble parce que chaque étape est indépendamment reviewable et révertible. Quand quelque chose casse en production, vous utilisez git bisect jusqu'au changement exact qui l'a causé au lieu de débugger un merdier à moitié fini de modifications interdépendantes.

Troisième : une stop condition honnête. Une boucle sans condition d'arrêt, c'est soit l'infini, soit une arrêt arbitraire. Les deux sont mauvais. La stop condition devrait être un signal mesurable : nombre de tests qui atteint zéro, un rapport « nothing to improve » sur des rounds consécutifs, un score d'évaluation qui se stabilise.

La discipline ici, c'est d'accepter les skips honnêtes. Quand le code est vraiment bon, le résultat correct est « n'a rien changé — rien n'avait besoin d'être changé. » Une boucle qui sait quand elle a fini vaut dix qui continuent à produire des changements marginaux pour paraître productive.

Ce que les boucles détectent que les prompts manquent

Laissez-moi vous donner un exemple concret de pourquoi ça compte.

Imaginez une boucle de self-improvement qui tourne sur un admin panel de production. La boucle prend des screenshots de chaque page, demande à l'AI d'identifier et corriger un problème d'UX par round, lance les type checks et le linting, et continue jusqu'à ce qu'elle ne trouve plus rien à améliorer.

Sur plusieurs rounds, cette boucle produit des dizaines d'améliorations réelles. Du polish UI propre. De meilleurs messages d'erreur. Des empty states plus malins.

Mais le fix le plus précieux n'était pas du polish — c'était un bug. Un round, le harness de screenshots a flagué qu'une page de settings rendait l'écran de crash full-page du framework. Voici le truc : ce crash était entièrement client-side. Les health checks de l'API étaient restés verts tout le temps parce que l'API allait bien. Un humain qui reviewait les screenshots aurait peut-être scrollé past cette page particulière ou aurait supposé que c'était un glitch de rendering transient.

La boucle automatisée l'a catché, a extrait l'erreur réelle (« Cannot read properties of undefined (reading 'memes') »), l'a tracée jusqu'à un bug de state-merge dans le cycle de vie du composant, et l'a corrigé à la racine. Et parce que le harness sait maintenant vérifier ce pattern d'écran de crash, il détectera cette classe entière de bugs pour toujours.

C'est le payoff. Une boucle ne fait pas juste du travail — elle construit un cliquet qui accumule des améliorations vérifiées et empêche les régressions vérifiées de revenir.

Pourquoi ça compte pour votre équipe

Si vous construisez une startup, vous n'avez pas le temps pour des outils AI qui demandent du babysitting constant. Si vous êtes développeur, vous n'avez pas de patience pour des outils qui introduisent plus de bugs qu'ils n'en corrigent.

Les agentic loops adressent ces deux préoccupations. Elles rendent l'assistance AI véritablement fiable en remplaçant la confiance par la vérification. Elles rendent le progrès mesurable en rendant chaque changement accountable. Elles rendent le debugging tractable en s'assurant que quand quelque chose casse, vous savez exactement quand et pourquoi.

Le meilleur partie ? Cette approche n'est pas restreinte à la génération de code. Le même pattern marche pour les tests automatisés, la chasse aux bugs, le security scanning, les mises à jour de documentation, la gestion des dépendances — partout où vous utilisez des one-shot prompts et où vous bénéficieriez d'une vérification continue.

Que vous voliez solo ou gériez une équipe, la question n'est pas si vous devez utiliser l'AI pour coder. La question est si vous l'utilisez d'une manière qui vous rend réellement plus rapide — ou qui vous fait juste paraître busy tout en accumulant de la dette technique.

Les boucles ne sont pas le seul moyen de travailler avec l'AI. Mais c'est le seul moyen que j'ai vu qui scale vers du vrai travail production sans accumuler un cimetière de code plausible-mais-faux.

Votre tour.