Pendant deux ans, tirer davantage d’un agent IA signifiait écrire une meilleure invite.
Cette époque s’achève en silence. Les meilleurs ingénieurs du monde ont cessé d’écrire des invites il y a quelque temps et ont commencé à écrire des boucles : des systèmes qui invitent l’agent, vérifient le résultat et continuent de tourner jusqu’à ce que le travail soit terminé.
Le script nocturne de Karpathy a trouvé 20 optimisations qu’il avait manquées en deux décennies de réglage manuel. Boris Cherny, qui a construit Claude Code, n’a pas écrit une ligne de code cette année. Les ingénieurs d’Anthropic fusionnent désormais près de 8 fois plus de code par jour qu’en 2024.
Aucun d’eux n’a tapé quelque chose de plus intelligent. Ils ont cessé de taper tout court.
Voici ce qu’est réellement une boucle, quand vous en avez besoin, quand vous n’en avez pas besoin, et comment construire votre première.
700 expériences pendant que l’humain dormait
Mars 2026. Andrej Karpathy pousse trois fichiers sur GitHub. Environ 630 lignes de code.
Un fichier contenait le modèle. Un autre le notait. Le dernier disait à l’agent quoi explorer et quoi laisser tranquille. L’agent ne pouvait toucher que le fichier d’entraînement. Rien d’autre.
Le cycle était volontairement ennuyeux. Lire le code, proposer une modification, entraîner pendant cinq minutes, vérifier si le score s’améliorait, conserver la modification si c’était le cas, l’annuler sinon, puis recommencer.
Il a pointé la boucle sur un modèle qu’il avait déjà réglé manuellement pendant deux décennies. Il l’a laissée tourner deux jours.
Elle a réalisé 700 expériences. Elle a trouvé 20 améliorations. L’une d’elles était un multiplicateur scalaire manquant dans le mécanisme d’attention, subtil, pas le genre de bogue qu’un linter aurait jamais attrapé, mais exactement le genre de chose qu’un ingénieur attentif aurait pu trouver et n’a jamais trouvée.
Le PDG de Shopify a utilisé la même astuce une nuit sur un modèle interne. Il s’est réveillé avec un gain de qualité de 19 % sur un modèle deux fois plus petit que le précédent.
L’idée n’est pas « l’IA est plus intelligente ». Les humains se fatiguent après l’expérience numéro douze. Les boucles ne se fatiguent jamais.
Une boucle n’est pas une invite programmée
La plupart des gens entendent « boucle » et pensent cron. Cela rate complètement l’essentiel.
Une invite est une instruction unique. Une boucle est un objectif que l’IA continue de poursuivre jusqu’à ce qu’elle l’atteigne, sans personne à la place. Elle planifie, exécute, vérifie son propre résultat, renvoie le résultat, et répète.
Cinq étapes : découvrir, planifier, exécuter, vérifier, itérer. Trois d’entre elles font le travail réel.
Le vérificateur est le cœur de la boucle. Sans une véritable porte sur la sortie, vous n’avez pas une boucle, vous avez l’agent qui note lui-même ses devoirs indéfiniment. Une porte est un test qui réussit ou échoue, une compilation qui réussit ou échoue, un linter qui retourne zéro ou non-zéro. Pas un second agent avec une opinion.
L’état est ce qui fait apprendre la boucle. Un fichier à côté, un tableau Linear, un journal de projet, un endroit en dehors de la conversation qui enregistre ce qui a été essayé et ce qui a échoué. La course de demain reprend au lieu de repartir de zéro.
Une condition d’arrêt est ce qui la garde saine. Chaque vraie boucle a deux sorties : l’objectif est atteint, ou une limite dure se déclenche. Sautez cela et vous avez construit une machine qui tourne toute la nuit pour rien.
Si l’un des trois manque, vous n’avez pas construit une boucle. Vous avez construit un script coûteux.
Les quatre conditions avant d’en construire une
Les boucles ne rentabilisent leur coût que lorsque quatre choses sont vraies en même temps. Si l’une manque, la mise en place coûte plus qu’elle ne rapporte.
- La tâche se répète au moins toutes les semaines. Moins que cela, le coût d’installation ne s’amortit jamais.
- Quelque chose peut automatiquement faire échouer le travail. Un test, une vérification de type, un linter, une compilation.
- Votre budget de tokens peut absorber le gaspillage. Les boucles relisent le contexte, réessayent, explorent.
- L’agent dispose d’outils d’ingénieur senior. Journaux, environnement de reproduction, capacité à exécuter le code qu’il écrit et voir ce qui casse.
La version honnête, la partie que personne ne vous dira : la plupart des gens n’ont pas encore besoin de la version lourde. Si vous êtes sur un plan grand public et que vous essayez de faire des boucles de vérification nocturnes sur du travail sérieux, la facture de tokens arrive avant le gain de productivité.
Les bonnes premières boucles sont les ennuyeuses. Tri CI. Mises à jour de dépendances. Passages de lint et correction. Reproduction de tests instables. Projets de ticket vers PR sur une base de code avec des tests solides déjà en place.
Les mauvaises premières boucles sont les intéressantes. Réécritures d’architecture. Code d’authentification. Paiements. Tout ce où « terminé » est un jugement et où un humain doit encore intervenir.
Les cinq blocs qui rendent une boucle réelle
Chaque vraie boucle est assemblée à partir des cinq mêmes pièces. Claude Code et Codex les incluent tous maintenant.
Le premier est l’automatisation. Le battement de cœur. Quelque chose qui déclenche la boucle selon un calendrier ou un événement. /loop tourne sur un rythme. /goal continue jusqu’à ce qu’une condition que vous avez définie soit effectivement remplie. Sans battement de cœur, la boucle est un script que vous avez exécuté une fois et oublié.
Le second est une compétence. La connaissance du projet sauvegardée dans un fichier claude-md que l’agent lit à chaque exécution. Sans cela, la boucle redérive votre contexte à partir de zéro à chaque cycle. Avec, l’intention s’accumule. La boucle connaît vos conventions, vos étapes de construction, la chose que vous ne faites jamais à cause de cet incident il y a trois mois.
Le troisième est les sous-agents. Le fabricant et le vérificateur ne peuvent pas être le même modèle. Celui qui a écrit le code est bien trop généreux en notant son propre travail. Celui qui a écrit l’article manque ses propres sections faibles. Écrivez vite et pas cher. Révisez lentement et strictement. Cette séparation constitue l’essentiel de la qualité.
Le quatrième est les connecteurs. La boucle ouvre la pull request, ferme le ticket, envoie un message sur le canal quand le CI devient vert. C’est la différence entre un agent qui dit « voici une correction suggérée » et un rapport qui vous attend le matin disant que la PR est déjà fusionnée.
Le cinquième est le vérificateur. Le test, la vérification de type ou la compilation qui échoue automatiquement le mauvais travail. Tout le reste n’est que plomberie. C’est le bloc qui décide si la boucle vous aide ou dépense simplement votre argent.
Empilez ces éléments et vous obtenez ce que les équipes sérieuses exécutent désormais à grande échelle. Des dizaines de boucles, chacune responsable d’un seul travail étroit, tournant côte à côte pendant que tout le monde dort. Un ingénieur a utilisé une boucle de flotte comme celle-ci pour réécrire une base de code entière d’un langage à un autre en environ six jours, un travail qui aurait pris près d’un an à la main.
Là où les boucles échouent en silence
Les boucles ne plantent pas. Elles vous facturent en silence. Deux modes d’échec méritent d’être nommés, tous deux s’aggravant à mesure que la boucle s’améliore, et non l’inverse.
Le premier est la boucle Ralph Wiggum. L’ingénieur Geoffrey Huntley l’a documentée. L’agent décide qu’il a terminé trop tôt, émet le signal d’achèvement sur un travail à moitié fini, et la boucle se termine satisfaite. Sans une porte objective, la boucle continue de tourner la nuit suivante, continue de dépenser, continue de produire un travail que personne n’acceptera.
La solution n’est pas un agent plus intelligent. C’est une porte plus stupide. Un test qui réussit ou échoue. Une compilation qui réussit ou échoue. Quelque chose sans opinion.
Le second est plus subtil. La dette de compréhension. Plus vite la boucle livre du code que vous n’avez pas écrit, plus l’écart se creuse entre ce que votre dépôt contient et ce que vous comprenez réellement. Une boucle qui tourne bien facture des intérêts composés sur cet écart. Le jour où vous devez déboguer un système que personne dans l’équipe n’a lu coûte plus que les tokens ne l’ont jamais fait.
L’abandon cognitif l’accompagne. Quand la boucle tourne seule, il est tentant de cesser de se faire une opinion et d’accepter tout ce qui revient. Concevoir la boucle est le remède quand vous le faites avec jugement. C’est l’accélérateur quand vous le faites pour éviter de penser. Même action, résultat opposé.
Deux personnes peuvent construire la même boucle et finir à des endroits opposés. L’une l’utilise pour aller plus vite sur un travail qu’elle comprend profondément. L’autre l’utilise pour éviter de comprendre le travail du tout. La boucle ne connaît pas la différence. Vous, oui.
Commencez par une boucle, pas dix
L’erreur que tout le monde fait est d’essayer de construire tout le système dès le premier jour. Dix boucles, un tableau de bord, une flotte. Cela s’effondre avant le week-end parce que vous ne pouvez pas dire quelle boucle a fait quoi.
Commencez par une. Choisissez la tâche récurrente la plus ennuyeuse que vous avez, celle que vous vérifiez chaque matin par habitude, et transformez cette seule tâche en boucle. Laissez-la tourner quelques jours. Observez où elle dépasse ses limites. Observez où elle échoue. Resserrez. Puis ajoutez la seconde.
L’ordre compte plus que les outils. Rendez d’abord une exécution manuelle fiable, pas rapide, fiable. Transformez cette exécution en compétence claude-md. Enveloppez la compétence dans une boucle avec une porte objective et une condition d’arrêt dure. Et ensuite, seulement ensuite, mettez-la sur un calendrier. Aller plus vite, programmer quelque chose que vous n’avez pas rendu fiable à la main, est exactement comment les boucles explosent pendant que vous dormez.
La métrique qui décide si la boucle fonctionne n’est pas les tokens dépensés, les tâches tentées ou les PR ouvertes. C’est le coût par modification acceptée. Si votre taux de modifications acceptées est inférieur à 50 %, vous faites le travail de révision que la boucle était censée éliminer, et la boucle perd.
Karpathy a cessé d’écrire du code d’entraînement. Cherny a cessé d’inviter. Aucun d’eux n’a cessé de penser. Si vous retenez une chose de tout cela, retenez celle-ci. La boucle est un système qui fait les 95 % ennuyeux pendant que vous gardez toute votre attention sur les 5 % qui portent réellement le risque.
Vous payez pour une flotte d’agents et vous utilisez une seule fenêtre de discussion.
Suivez-moi et abonnez-vous à ma chaîne Telegram : https://t.me/+75nMf005jRpjMDU1
