Loop Engineering vs Prompt Engineering : La Vérité

Loop Engineering vs Prompt Engineering : La Vérité

Un ami m'a envoyé un lien la semaine dernière avec une seule ligne en pièce jointe : "le prompt engineering est mort." L'article en dessous soutenait que le loop engineering l'avait remplacé — qu'écrire des prompts était désormais une compétence de débutant, et que le vrai jeu était de construire des boucles qui font tourner l'IA en pilote automatique.

J'ai lu l'ensemble deux fois. Puis j'ai ouvert mon terminal, regardé la boucle que j'avais construite deux semaines plus tôt pour optimiser un script Python lent, et j'ai réalisé que l'article avait tout à l'envers.

Voici ce que presque personne ne dit à voix haute dans le débat loop engineering vs prompt engineering : une boucle est des prompts. Ce sont des prompts exécutés encore et encore, enveloppés dans une structure et un moyen de vérifier s'ils ont fonctionné. Supprimez la conception du prompt et la boucle ne devient pas plus intelligente — elle devient confiante, coûteusement fausse à grande échelle. Donc si vous craignez d'avoir raté le mémo et de devoir jeter tout ce que vous avez appris sur le prompting, détendez-vous. Ce n'est pas le cas. Mais vous avez besoin d'une deuxième compétence empilée par-dessus, et c'est de cela qu'il s'agit.

Je vais définir le loop engineering correctement, parcourir les cinq composants qui font réellement fonctionner une boucle (la plupart des explications s'arrêtent à quatre et ratent celui qui sauve votre portefeuille), vous montrer les cinq niveaux de critères de succès qui déterminent si une boucle vaut même la peine d'être construite, et vous donner le chemin exact en quatre étapes que j'utilise pour transformer un prompt unique en un système auto-améliorant. Il y a un exemple travaillé d'article LinkedIn avec un problème genuinement agaçant intégré, parce que les exemples faciles vous mentent.

Laissez-moi commencer par déconstruire le titre qui a lancé tout cela.

Le loop engineering remplace-t-il le prompt engineering ?

Non. Le loop engineering ne remplace pas le prompt engineering — il s'empile par-dessus, car une boucle est simplement des prompts exécutés de manière répétée avec un échafaudage, des critères de succès et une condition d'arrêt. De meilleurs prompts font de meilleures boucles ; de moins bons prompts font une boucle qui échoue plus vite et coûte plus cher.

C'est la version featured snippet. Maintenant la partie qui compte.

Quand vous écrivez un seul prompt, vous optimisez une requête à un modèle. Vous avez un essai, vous lisez la sortie, vous ajustez. Quand vous construisez une boucle, vous optimisez le système qui exécute ce prompt — ce qui se passe entre les appels, comment il vérifie son propre travail, et quand il décide de s'arrêter. Ce sont des compétences véritablement différentes. Mais ce ne sont pas des substituts. Ce sont des couches.

Pensez-y mécaniquement. La phase d'exécution de chaque boucle est un prompt. Si ce prompt est vague, chaque itération hérite du flou — et maintenant vous payez pour dix itérations vagues au lieu d'une. Il y a une phrase du discours sur le loop engineering de 2026 qui m'est restée : le prompt engineering échoue silencieusement — vous obtenez une mauvaise réponse et passez à autre chose — tandis que le loop engineering échoue bruyamment et coûteusement si vous n'avez pas conçu les modes de défaillance aussi soigneusement que le chemin de succès. Une boucle amplifie tout ce que vous y mettez. Prompt poubelle, poubelle amplifiée.

Donc les gens qui déclarent le prompt engineering mort sont comme quelqu'un qui déclare l'arithmétique obsolète parce qu'il a découvert les tableurs. Le tableur exécute l'arithmétique mille fois automatiquement. Il ne vous libère pas de comprendre ce que fait l'arithmétique. Si quoi que ce soit, le levier rend les fondamentaux plus importants, parce que les erreurs se composent maintenant.

Gardez cette pensée — "les boucles amplifient" — car c'est le fil conducteur de chaque section ci-dessous.

Ce que signifie réellement le loop engineering

Le loop engineering, c'est construire des boucles qui itèrent des prompts de manière répétée, avec un échafaudage ajouté et des critères de succès explicites, pour qu'une tâche se complète automatiquement et efficacement sans que vous surveilliez chaque étape.

C'est tout. Le mot "boucle" fait un vrai travail ici. Vous ne demandez pas à l'IA de faire quelque chose une fois. Vous construisez un cycle : elle agit, vous vérifiez si elle a réussi, et si non, elle repart — armée de ce qu'elle a appris de la dernière tentative. L'art réside dans l'échafaudage autour de l'action, pas dans l'action elle-même.

Je veux être précis sur la différence avec quelques choses avec lesquelles les gens confondent, car le contraste affine ce qu'est le loop engineering.

Les systèmes de "recherche automatique" — ceux qui partent collecter des informations vers un objectif — nécessitent des critères de succès stricts et bien définis pour fonctionner. Orientez-les vers un objectif flou et ils errent ou s'arrêtent arbitrairement. Le loop engineering partage cette exigence de critères clairs mais va plus loin : il opère sur un horizon long avec une amélioration continue, pas un unique sprint de recherche.

La fonctionnalité type /goal dans des outils comme Claude Code exécute une optimisation en session unique. Vous lui donnez un objectif vérifiable, elle travaille vers cet objectif dans une session, et s'arrête quand l'objectif est atteint. C'est une boucle belle et bien délimitée — et je l'utilise constamment — mais c'est un sprint. Le vrai loop engineering est la version marathon : il persiste à travers les sessions, enregistre ce qui s'est passé, et utilise cette histoire pour faire mieux la fois suivante. La session unique optimise ; la boucle conçue apprend.

Cette distinction — session versus horizon long, optimiser versus apprendre — est là où la gestion d'état prouve sa valeur. Nous y reviendrons.

Pour l'instant, le modèle mental : le prompt engineering écrit le coup. Le loop engineering construit la machine qui exécute le coup, juge le résultat, et décide s'il faut l'exécuter à nouveau. Si vous voulez la leçon d'anatomie plus approfondie sur la façon dont ces machines sont câblées, j'ai décomposé la structure trigger/action/condition d'arrêt dans mon guide complet pour concevoir des boucles d'agents — cette pièce est la couche stratégique au-dessus.

Les cinq composants d'une boucle (pas quatre)

La plupart des explications du loop engineering vous donnent quatre phases. Quatre phases vous donneront une boucle qui fonctionne jusqu'à ce qu'elle ne s'arrête pas. Alors je vous en donne cinq, et la cinquième est celle que je tatouerais sur le dos de la main de quiconque avant de laisser une boucle tourner sans surveillance.

Voici l'anatomie complète.

Laissez-moi donner à chacun l'attention qu'il mérite, car l'écart entre une boucle jouet et une boucle de production réside entièrement dans le sérieux avec lequel vous les traitez.

Trigger : comment la boucle démarre sans vous

La phase de trigger est ce qui fait d'une boucle une boucle plutôt qu'une commande sophistiquée que vous continuez à relancer. Un planning cron qui se déclenche à 9h00. Un webhook qui se déclenche quand un pull request est ouvert. Un observateur de fichiers qui se déclenche quand un CSV atterrit dans un dossier. Le point est que vous n'êtes pas le trigger. Au moment où un humain doit lancer manuellement chaque exécution, vous avez construit un outil, pas une boucle autonome — et c'est très bien, mais sachez lequel vous construisez.

La phase de trigger est aussi là où la plupart des gens introduisent accidentellement une dépendance envers eux-mêmes. "Ça tourne automatiquement — je dois juste coller les nouvelles données d'abord." Ce n'est pas automatique. Soyez honnête à ce sujet dès le départ, car une boucle semi-automatisée a toute la surface de défaillance de l'automatisation et rien de la liberté.

Exécution : là où vit le prompt engineering

C'est le moteur, et c'est un prompt. Ou plus précisément, en 2026, c'est généralement une compétence — une fonction réutilisable et nommée qui enveloppe un prompt bien testé et un format de sortie défini. La phase d'exécution est exactement là où le groupe "le prompt engineering est mort" a le plus tort, car cette phase est là où tout votre savoir-faire en prompts est dépensé. Une compétence qui "recherche les actualités IA et écrit un article" est un prompt avec un intitulé de poste.

Mieux ce prompt est conçu, moins chaque autre composant a de travail à faire. Un prompt d'exécution affûté produit une sortie cohérente et structurée, ce qui rend la vérification triviale. Un bâclé produit une sortie qui varie considérablement d'une exécution à l'autre, ce qui rend la vérification un cauchemar et la gestion d'état presque inutile. Les boucles récompensent le bon prompting et punissent le mauvais prompting — en volume.

Vérification : le véritable goulot d'étranglement

Voici une vérité que j'ai mis trop longtemps à intérioriser : le vérificateur, pas le modèle, est le goulot d'étranglement dans toute boucle. La compétence centrale du loop engineering est d'écrire la chose qui décide si la sortie est assez bonne pour s'arrêter.

Si votre critère de succès est "le temps d'exécution du script Python est-il descendu en dessous de 200ms ?" — félicitations, votre vérificateur est un chronomètre et une instruction if. Objectif. Peu coûteux. Fiable. Si votre critère de succès est "cet article LinkedIn est-il meilleur ?" — maintenant votre vérificateur doit répondre à une question subjective, et les vérificateurs subjectifs sont là où les boucles vont mourir. Nous consacrerons une section entière à cela car c'est le prédicteur le plus important de la réussite de votre boucle.

Gestion d'état : la différence entre répéter et apprendre

La gestion d'état est ce qui sépare une boucle qui fait la même chose 100 fois d'une boucle qui le fait mieux la 100ème fois que la première. Vous enregistrez la sortie et le résultat de chaque itération — dans une base de données, un fichier de log, un fichier JSON, n'importe où de durable — et vous réinjectez cette histoire dans l'exécution suivante.

Sans état, une boucle est un poisson rouge. Elle se réveille chaque cycle sans mémoire, fait le même appel, obtient le même résultat. Avec état, le prompt d'exécution peut dire : "Voici les dix derniers articles que tu as écrits et comment chacun a performé. Fais plus de ce qui a marché." Ça c'est de l'IA auto-améliorante — pas de la magie, juste de la mémoire plus un signal de feedback. La gestion d'état est le composant sans glamour qui fait de "l'auto-amélioration" un mécanisme réel plutôt qu'un mot à la mode.

Critères d'arrêt : le composant qui sauve votre argent

Et voici le cinquième, celui que les explications en quatre phases sautent. Les critères d'arrêt décident quand la boucle se termine. Deux façons propres de terminer : le critère de succès est rempli, ou un plafond strict d'itérations est atteint — "essaie au plus 8 fois, puis abandonne et dis-le-moi."

Pourquoi est-ce non négociable ? Parce qu'une boucle sans condition d'arrêt et une vérification de succès un peu trop optimiste est une machine à convertir votre budget API en rien. J'ai vu une boucle avec un critère de succès flou décider qu'elle n'était "jamais tout à fait prête" et moudre itération après itération, chacune appelant le modèle, chacune coûtant de l'argent, aucune ne satisfaisant jamais un objectif qui n'était jamais vérifiable en premier lieu. La boucle emballée n'est pas hypothétique. C'est le mode de défaillance par défaut contre lequel vous devez concevoir.

Construisez les critères d'arrêt en premier, honnêtement, avant de confier vos identifiants à une boucle. Votre futur vous, regardant la facture, sera reconnaissant.

Ce sont les cinq. Maintenant la question qui décide si vous devriez même construire la boucle.

Le loop engineering n'est pas une solution universelle

Ce qui est séduisant avec les boucles, c'est qu'elles semblent universellement applicables. Tout ce que vous faites de manière répétée, vous pouvez sûrement le boucler. Mais les boucles ont une exigence stricte que toutes les tâches ne peuvent pas remplir, et la forcer mène aux pires boucles — celles qui ont l'air automatisées mais produisent silencieusement de la dérive.

L'exigence est celle-ci : vous avez besoin d'un critère de succès que la boucle peut réellement vérifier.

Les boucles brillent quand le succès est objectif et mesurable. "Réduis le temps d'exécution de ce script Python" est l'objectif de boucle parfait. Pourquoi ? Parce que le vérificateur est un benchmark. La boucle exécute le script, le chronomètre, compare avec la dernière exécution, et sait — sans aucune ambiguïté — si ça s'est amélioré. Chaque itération produit un nombre, le nombre entre dans l'état, et la boucle peut monter le gradient vers "plus rapide" sans jamais rien demander à un humain. Feedback immédiat, objectif, fiable. C'est le paradis des boucles.

Maintenant contrastez avec : "écris un article LinkedIn de meilleure qualité." Quel est le vérificateur ? "Meilleur" selon qui ? La même IA qui l'a écrit ? C'est un modèle qui corrige ses propres devoirs — et une instance de modèle unique souffre de biais de confirmation ; elle sera ravie de noter sa propre sortie 9 et de rater ce qui la rend médiocre. Il y a des travaux publiés en 2026 sur exactement ce biais d'auto-attribution : les moniteurs IA sont indulgents avec eux-mêmes. Donc votre boucle "améliore" l'article chaque cycle selon son propre jugement tandis qu'un lecteur humain ne voit aucune différence, ou pire, le voit devenir plus fade alors qu'il optimise un proxy de qualité qu'il ne peut pas vraiment mesurer.

C'est la décision centrale de jugement du loop engineering, et je le dirai clairement : avant de construire une boucle, demandez-vous si vous pouvez écrire un vérificateur auquel vous feriez réellement confiance. Si non, la boucle n'est pas la réponse — du moins pas une entièrement autonome. Pour les objectifs flous, vous avez deux options honnêtes, et elles sont le pont pour rendre les tâches subjectives bouclables.

La première est la vérification avec humain dans la boucle : la boucle s'exécute, produit une sortie, et se met en pause pour qu'un humain approuve ou rejette avant de compter l'itération comme succès. Plus lent, mais le vérificateur est un vrai humain qui peut juger la qualité. La seconde est un juge IA séparé — un modèle fait le travail, un modèle différent l'évalue. La séparation compte énormément, car elle casse le problème de corriger ses propres devoirs. Le travailleur n'a pas le droit de se noter lui-même.

Même avec un juge séparé, restez méfiant. Une IA évaluant la qualité subjective reste une IA, avec ses propres biais sur ce à quoi "bon" ressemble. Utilisez-la pour le triage et pour révéler ce qui est clairement mauvais, mais pour tout ce qui a des enjeux élevés, gardez un point de contrôle humain. L'objectif n'est pas de supprimer les humains — c'est de les retirer des décisions ennuyeuses et vérifiables et de les garder pour les décisions de jugement.

Si vous préférez que quelqu'un configure ce type de flux de travail avec humain dans la boucle ou basé sur un juge avec vous plutôt que de le construire de zéro, j'accepte exactement ce type de projets — vous pouvez voir ce que j'ai construit sur fiverr.com/s/EgxYmWD. Pour tous ceux qui le construisent eux-mêmes, la section suivante est le framework que j'utilise pour y arriver.

Le Voyage du Héros : quatre étapes vers une solution avec loop engineering

Vous ne commencez pas par construire une boucle. C'est l'erreur. Vous commencez par prouver que la tâche est même possible à la main, et vous gagnez votre chemin vers l'automatisation en quatre étapes. Je l'appelle le Voyage du Héros parce que chaque étape est un level-up, et sauter un niveau est comment vous finissez avec une façon automatisée de faire la mauvaise chose très vite.

Étape 1 — Exécution manuelle : prouvez que ça marche à la main

Avant toute boucle, faites la tâche vous-même, dans le chat, en promptant l'IA manuellement. Vous voulez une boucle qui transforme la recherche IA en articles LinkedIn ? D'abord, promptez l'IA pour le faire une fois. Lisez la sortie. Est-elle vraiment bonne ? Un humain peut-il obtenir de manière fiable un bon résultat d'un bon prompt ?

Si vous ne pouvez pas obtenir un bon résultat manuellement, vous n'avez aucune raison de l'automatiser cent fois. Cette étape est la vérification de réalité. C'est aussi là où votre prompt engineering est forgé — chaque raffinement que vous faites ici devient la fondation sur laquelle repose l'ensemble de la boucle. Ne vous précipitez pas.

Étape 2 — Codifier en compétence

Une fois que le prompt manuel fonctionne de manière fiable, encapsulez-le. Transformez le prompt-plus-format-de-sortie en une compétence nommée et réutilisable — une fonction que vous pouvez appeler au lieu de retaper le prompt. C'est la codification de compétences, et c'est le moment où votre action unique devient un bloc de construction.

Codifier impose la discipline. Pour créer une compétence, vous devez définir exactement ce qui entre et exactement ce qui sort. Cette structure est précisément ce sur quoi les composants de vérification et d'état s'appuieront plus tard. Un prompt vague résiste à la codification ; un prompt affûté s'intègre proprement dans une compétence. (Si vous voulez la version approfondie de cette étape, j'ai écrit un détail complet de la construction de compétences d'agent dans Claude Code qui reprend exactement ici.)

Étape 3 — Automatiser la compétence

Ajoutez maintenant le trigger. Planifiez la compétence, ou connectez-la à un webhook, pour qu'elle s'exécute sans vous. À ce stade, vous avez l'automatisation : la compétence se déclenche toute seule et produit une sortie. Notez ce que vous n'avez pas encore — l'amélioration. Une compétence automatisée répète. Elle n'apprend pas. C'est un poisson rouge avec un calendrier.

Beaucoup d'automatisations précieuses s'arrêtent exactement ici, et c'est légitime. Si la tâche ne bénéficie pas de l'apprentissage — elle doit juste être faite de manière fiable selon un planning — l'Étape 3 est votre ligne d'arrivée. N'ajoutez pas une boucle juste pour vous sentir sophistiqué. Quand j'ai construit ma première vraie boucle de bout en bout, la discipline la plus difficile était de résister à l'envie de sauter directement à l'Étape 4 avant que l'automatisation de l'Étape 3 ne soit même stable.

Étape 4 — Ajouter l'auto-amélioration avec le loop engineering

C'est ici que ça devient une vraie boucle. Vous définissez les critères de succès, implémentez le suivi d'état — enregistrez chaque sortie et son résultat — et construisez le mécanisme de feedback qui utilise cette histoire pour rendre la prochaine exécution meilleure. Pour le cas LinkedIn, cela signifie scraper l'engagement, l'enregistrer, et réinjecter "voici ce qui a bien marché avant" dans le prompt d'exécution.

C'est l'étape qui transforme l'automatisation en IA auto-améliorante. Et c'est aussi l'étape où tout ce dont nous avons discuté sur la vérification mord : si votre critère de succès est flou, l'Étape 4 est là où la boucle déraille silencieusement. Vous arrivez donc ici ayant déjà décidé — honnêtement — si la tâche peut supporter un vérificateur fiable. Le Voyage place cette décision au début intentionnellement.

Quatre étapes. Manuel, codifier, automatiser, améliorer. Chacune un point de contrôle. Maintenant, laissez-moi faire passer un vrai exemple à travers, y compris la partie que le tutoriel propre de tout le monde laisse de côté.

Un exemple travaillé : la boucle d'articles LinkedIn (et son problème laid)

Construisons la boucle que tout le monde veut — une IA qui écrit et publie un article LinkedIn chaque jour et s'améliore avec le temps — et soyons honnêtes sur pourquoi c'est plus difficile que les démos ne le suggèrent.

Voici le design, mappé sur les cinq composants :

• Trigger : une exécution planifiée quotidienne à 9h00.
• Exécution : une compétence qui recherche les actualités IA du jour et écrit un article avec ma voix.
• Vérification : succès = nombre de likes que l'article obtient, scrapés du post et enregistrés.
• État : une base de données de chaque article passé et de sa performance, réinjectée pour guider le suivant.

Sur le papier, magnifique. Le critère de succès est même numérique — les likes sont un nombre, pas un ressenti. Mais exécutez-le et vous tombez sur le problème que l'exemple Python n'a jamais : le décalage temporel.

Quand j'optimise le temps d'exécution d'un script Python, le feedback est instantané. Exécutez le script, obtenez les millisecondes, sachez immédiatement si l'itération N a battu l'itération N-1. La boucle peut monter vite parce que le vérificateur répond maintenant.

La boucle LinkedIn n'a pas ce luxe. L'article est publié à 9h00. Les likes qui vous disent si ça a marché n'existent pas encore. Ils arrivent au compte-gouttes pendant des heures, parfois des jours. Le signal de vérification de l'article d'aujourd'hui n'est donc pas disponible quand l'exécution de demain se déclenche. Votre boucle veut apprendre de résultats qui ne se sont pas encore produits.

Cela casse la boucle unique naïve, et la solution est de diviser la chronologie. Vous faites tourner une boucle de scraping retardée ou parallèle — un cycle séparé dont le seul travail est de revisiter les articles publiés 24 ou 48 heures plus tard, de scraper l'engagement, et de l'écrire dans l'état. La boucle d'écriture se déclenche quotidiennement ; la boucle de mesure suit derrière, remplissant les résultats rétroactivement. Ce n'est que quand un article a "mûri" que sa performance devient un signal d'entraînement pour les articles futurs.

C'est la vraie forme d'une boucle de contenu auto-améliorante, et elle est significativement plus complexe que le cas Python. Les mêmes cinq composants, mais la machinerie de vérification et d'état doit tenir compte de l'écart entre faire et savoir. Le feedback de la boucle Python est immédiat et objectif, donc c'est considérablement plus facile à automatiser de bout en bout. Le feedback de la boucle LinkedIn est retardé et bruité — les likes dépendent du timing, de l'audience et de la chance autant que de la qualité — donc même avec un critère numérique, vous luttez contre le retard de signal et les variables de confusion.

La leçon se généralise : quand vous concevez une boucle, cartographiez non seulement si le signal de succès est objectif, mais s'il est disponible à temps pour piloter l'itération suivante. Un critère numérique que vous ne pouvez pas lire avant la semaine prochaine est toujours un problème de vérification. C'est le genre de détail qui sépare une boucle qui fonctionne en démo d'une qui fonctionne en production — et c'est exactement le compromis que la plupart des guides "construisez une IA qui publie pour vous" sautent entièrement.

Alors comment raisonnez-vous sur tout cela avant de construire ? Vous classez votre critère de succès.

Les cinq niveaux de vérification, classés

Le destin de chaque boucle est décidé par une chose : à quel point son critère de succès est vérifiable. Après en avoir construit suffisamment, je pense aux critères de succès sur une échelle à cinq niveaux, de "bouclez ça immédiatement" à "n'automatisez pas ça complètement." Voici l'échelle, du meilleur au pire.

1. Déterministe / basé sur des règles. La sortie passe une règle stricte ou non. Les tests passent ou échouent. Le fichier compile ou non. Le JSON correspond au schéma ou est rejeté. C'est le gold standard — le vérificateur est du code, il est objectif, il est instantané, et on ne peut pas discuter avec. Si votre tâche atterrit ici, bouclez-la sans hésiter.

2. Numérique / basé sur des métriques. Le succès est un nombre mesurable que vous voulez pousser dans une direction. Temps d'exécution en millisecondes. Likes. Taux de conversion. Coût en tokens. Presque aussi bon que le niveau un, si le nombre est fiable et disponible rapidement. La boucle LinkedIn vit ici — numérique, mais tirée vers le bas par le décalage temporel et le bruit dont nous venons de parler.

3. Juge IA séparé. Pas de règle propre ni de nombre, donc un modèle différent évalue la sortie par rapport à une grille d'évaluation. Utilisable pour les tâches semi-subjectives, mais vous faites maintenant confiance au jugement d'une IA sur le travail d'une autre, et vous devez rester vigilant aux biais propres du juge. Bon pour filtrer et trier, instable pour les décisions finales à enjeux élevés.

4. Humain dans la boucle. Le succès est assez subjectif pour qu'une personne doive décider. La boucle s'exécute, puis se met en pause pour une approbation humaine avant de compter l'itération comme succès. Fiable, car le vérificateur est un vrai humain — mais lent, et ça plafonne l'autonomie de la boucle. Utilisez-le quand la qualité requiert véritablement un jugement humain.

5. Flou / subjectif auto-évalué. "Améliore-le," jugé par la même IA qui l'a fait. C'est le niveau le plus bas et, honnêtement, la zone de danger. Le modèle corrige ses propres devoirs, le biais de confirmation s'infiltre, et la boucle optimise un proxy qu'elle ne peut pas vraiment mesurer. Évitez de construire des boucles entièrement autonomes ici. Si vous devez opérer dans cet espace, remontez l'échelle — ajoutez un point de contrôle humain (niveau 4) ou au moins un juge séparé (niveau 3).

La recommandation qui en découle est simple. Visez aussi haut que possible sur l'échelle. Concevez votre tâche pour que le succès soit basé sur des règles ou numérique, même si cela signifie redéfinir l'objectif. Vous n'y arrivez pas ? Alors ne prétendez pas qu'un critère de niveau cinq est suffisant — ajoutez explicitement une validation humaine ou un évaluateur séparé, et ne vous fiez jamais uniquement à la même IA pour générer et juger la qualité subjective. Le niveau que vous pouvez honnêtement atteindre vous dit non seulement comment construire la boucle, mais si vous devriez la construire de manière autonome.

Cette seule question — "à quel niveau est mon critère de succès ?" — vous épargnera plus de boucles gaspillées que tout autre conseil dans cet article.

Ce que cela signifie pour votre façon de travailler

Prenez du recul et l'image est claire : le cadrage loop engineering vs prompt engineering est un faux choix. Ce n'a jamais été l'un remplaçant l'autre. C'est une pile.

Le prompt engineering est la fondation — la compétence d'obtenir une bonne sortie d'une bonne requête. Le loop engineering est l'étage construit par-dessus — la compétence d'exécuter cette sortie de manière répétée, de la juger, de s'en souvenir et de l'améliorer, le tout sans vous aux commandes. Vous avez besoin des deux. La personne qui ne peut que prompter est coincée à faire les choses à la main. La personne qui essaie de boucler sans prompting solide automatise le chaos. La personne qui peut faire les deux construit des systèmes qui tournent vraiment tout seuls et s'améliorent pendant qu'elle dort.

Et ce que je veux le plus que vous reteniez n'est pas une technique. C'est une habitude d'honnêteté. Avant de construire une boucle, posez les questions inconfortables : Puis-je écrire un vérificateur auquel je ferais réellement confiance ? Mon signal de succès est-il objectif, et est-il disponible à temps pour piloter l'itération suivante ? Ai-je construit une vraie condition d'arrêt, ou suis-je à une vérification floue d'une facture emballée ? La plupart des boucles échouées échouent sur ces questions, pas sur le code.

Si vous voulez apprendre les fondamentaux sous tout cela — prompting, compétences et loop engineering ensemble, de la façon dont ils s'emboîtent réellement — j'ai préparé une masterclass Claude Code qui parcourt exactement cette progression. C'est le même Voyage du Héros, enseigné de bout en bout.

Alors, le prompt engineering est-il mort ? Allez regarder la phase d'exécution de la meilleure boucle que vous puissiez imaginer. Assis juste là, faisant le vrai travail, il y a un prompt. Il n'est jamais allé nulle part. On lui a juste appris à tourner tout seul — et à se souvenir de ce qui s'est passé la dernière fois.

La vraie question n'a jamais été "boucles ou prompts." C'est celle-ci : de toutes les choses que vous faites encore et encore, lesquelles ont un critère de succès auquel vous feriez véritablement confiance à une machine pour le vérifier ? Répondez honnêtement, et vous saurez exactement quelles tâches boucler — et lesquelles ont encore besoin de vous.

Questions Fréquemment Posées

Le prompt engineering est-il obsolète à cause du loop engineering ?

Non. Le loop engineering ne remplace pas le prompt engineering — il en dépend. La phase d'exécution d'une boucle est un prompt exécuté de manière répétée, donc des prompts faibles produisent des boucles faibles à grande échelle. Les deux sont des compétences requises qui s'empilent plutôt que de se concurrencer. Voir les sections d'ouverture ci-dessus pour l'explication mécanique complète.

Quelle est la différence entre le loop engineering et le prompt engineering ?

Le prompt engineering optimise une requête unique à un modèle ; le loop engineering optimise le système qui exécute ce prompt de manière répétée — gérant les triggers, la vérification, l'état et les critères d'arrêt. Le prompting écrit le coup ; le loop engineering construit la machine qui exécute le coup et juge le résultat.

Quand ne devrais-je pas utiliser le loop engineering ?

Évitez les boucles entièrement autonomes quand le succès est subjectif et ne peut être jugé que par la même IA qui a produit la sortie, car cela invite le biais de confirmation et des itérations emballées. Pour les objectifs flous, ajoutez un point de contrôle avec humain dans la boucle ou un juge IA séparé. Voir l'échelle de vérification à cinq niveaux ci-dessus.

Quels sont les composants d'une boucle d'agent IA ?

Une boucle complète a cinq composants : un trigger qui la démarre automatiquement, une phase d'exécution qui fait le travail (généralement via une compétence), une phase de vérification qui vérifie les critères de succès, une gestion d'état qui enregistre et apprend des résultats, et des critères d'arrêt qui terminent la boucle en cas de succès ou après un plafond strict d'itérations.

Comment empêcher une boucle IA de tourner indéfiniment ?

Définissez des critères d'arrêt explicites avant de l'exécuter : terminez quand le critère de succès est rempli, et ajoutez un plafond strict d'itérations comme filet de sécurité. Une boucle avec une vérification de succès floue et sans plafond d'itérations est la cause par défaut des coûts API emballés. Pour l'anatomie complète, voir mon guide pour concevoir des boucles d'agents.

Travaillons Ensemble

Vous cherchez à construire des systèmes IA, automatiser des flux de travail ou faire évoluer votre infrastructure technique ? J'adorerais vous aider.

• Fiverr (builds personnalisés et intégrations) : fiverr.com/s/EgxYmWD
• Portfolio : mejba.me
• Ramlit Limited (solutions entreprise) : ramlit.com
• ColorPark (design et branding) : colorpark.io
• xCyberSecurity (services de sécurité) : xcybersecurity.io