Pourquoi le Prompt Engineering est mort (Vive le Loop Engineering)

La fin annoncée d'une compétence reine

Pendant deux ans, une obsession a structuré tout l'écosystème de l'IA générative : écrire de meilleurs prompts. Donner de meilleures instructions, fournir plus de contexte, choisir de meilleurs exemples, trouver la formulation exacte qui ferait sortir le meilleur de Claude, de Codex, de Cursor ou de n'importe quel agent. Le « prompt engineering » est devenu une discipline à part entière, avec ses recueils de techniques et, à son apogée en 2023, sa réputation de compétence rare et grassement payée.

Cette ère est en train de se refermer. Non pas parce que le prompt aurait cessé de fonctionner, mais parce qu'il a révélé une limite structurelle que les modèles, en devenant plus capables, ont rendue de plus en plus visible. La presse économique annonçait dès 2025 que le métier de prompt engineer devenait obsolète, à mesure que les modèles devenaient meilleurs pour deviner l'intention derrière une requête maladroite — un constat que Business Insider résumait en juin 2026 par une formule sans équivoque : « Forget prompt engineering ». Mais ce n'est pas la véritable cause de mort. La véritable cause est ailleurs, et elle est plus intéressante : le prompt engineering résout le mauvais problème.

Le prompt engineering n'a pas disparu parce qu'il échouait, mais parce qu'il optimise une exécution unique au lieu d'un système qui s'améliore. Cet article explique pourquoi, et pourquoi le Loop Engineering — la conception de systèmes autonomes qui prompteront les agents à votre place — vient prendre le relais. Il s'inscrit dans une généalogie que SFEIR documente depuis plusieurs paradigmes : du prompt au context engineering, puis au harnais, et enfin à la boucle. Nous verrons d'abord le défaut fondamental du prompt, puis le phénomène de dérive qui ruine les espaces de travail IA, et enfin comment la boucle transforme une tâche jetable en un actif qui s'améliore.

Le problème fondamental : le prompt ne s'accomplit qu'une fois

Le défaut du prompt engineering tient en une phrase : il ne vous permet d'accomplir une tâche qu'une seule fois. Au cœur de la discipline se trouve une hypothèse implicite : le but ultime serait d'écrire un prompt parfait à chaque fois que l'on a besoin de quelque chose. Or, comme le souligne Addy Osmani dans son article fondateur de juin 2026, ce n'est pas le bon objectif. Le but n'est pas de produire la formulation idéale ; c'est de concevoir un système qui s'améliore à chaque exécution.

Vous écrivez un prompt brillant, vous obtenez un résultat brillant, et puis ? Rien ne subsiste. La prochaine fois que vous aurez besoin de la même chose, vous repartirez de zéro, ou vous copierez-collerez un prompt légèrement périmé que vous ajusterez à la main. Le savoir accumulé dans la formulation ne se capitalise pas. Il s'évapore avec la fenêtre de contexte. C'est exactement la limite que SFEIR identifie au cœur de sa progression vers le Context Engineering : le prompt engineering est une interaction isolée, à mémoire éphémère et à ROI linéaire, là où l'enjeu est désormais un environnement à mémoire persistante et à ROI composé.

Le Loop Engineering inverse cette logique. Au lieu de se concentrer sur l'exécution ponctuelle, il se concentre sur l'amélioration continue des artefacts qui façonnent la manière dont la tâche est exécutée à chaque fois. Un prompt jetable, on peut se permettre de le rater. Mais une règle dont dix personnes dépendent, ou une grille d'évaluation utilisée par toute une équipe, ne peut pas se permettre de dériver silencieusement. C'est précisément la distinction que fait Shubham Saboo dans son travail sur le Loop Engineering appliqué au produit : un prompt one-shot, vous pouvez vous tromper ; un artefact réutilisé, non.

Cette distinction est plus profonde qu'elle n'en a l'air. Elle déplace l'objet du travail. Dans le prompt engineering, l'objet du travail est la sortie : le code, le texte, l'analyse produits ici et maintenant. Dans le Loop Engineering, l'objet du travail est l'artefact qui produit la sortie : le fichier CLAUDE.md, la skill de revue, la checklist, le rubric. On ne travaille plus le résultat, on travaille la machine à résultats. Et cette machine, contrairement à un prompt, peut s'améliorer dans le temps.

La dérive silencieuse des espaces de travail IA

La dérive (drift) est l'érosion lente et non mesurée des artefacts qui pilotent un agent : ni le modèle ni le prompt ne sont en cause, ce sont les artefacts qui se dégradent sans surveillance. Il existe un phénomène que tous ceux qui travaillent intensément avec des agents IA finissent par rencontrer, et que le prompt engineering est structurellement incapable de combattre.

Voici comment elle s'installe. Au début, votre espace de travail IA fonctionne bien. Votre fichier d'instructions est concis, votre skill de revue est précise, votre workflow de recherche est propre. Puis, semaine après semaine, les choses s'accumulent. Votre CLAUDE.md s'allonge, parce que vous y ajoutez une consigne chaque fois qu'un problème survient. Votre skill de revue devient plus stricte. Votre workflow de recherche hérite d'instructions venues d'un projet passé qui n'ont plus lieu d'être. Votre checklist de lancement gonfle jusqu'à ce que l'agent en ignore la moitié. Vos critères d'évaluation changent, mais vous oubliez quand et pourquoi.

Un mois plus tard, l'agent semble moins bon. Il écrit de moins bons documents, donne des résumés plus génériques, rate la nuance produit qu'il captait autrefois. Le réflexe est d'accuser le modèle. C'est une erreur. Comme l'observe Saboo, le modèle n'a probablement pas empiré. Ce sont vos artefacts qui ont dérivé, et rien ne les surveillait.

C'est le vrai problème que le Loop Engineering résout. Pas rendre un prompt meilleur, mais s'assurer que les artefacts qui façonnent votre travail s'améliorent au lieu de se dégrader lentement. Et parce que ces artefacts sont réutilisés des dizaines de fois, ils composent dans les deux directions, selon la formule d'Osmani : un bon artefact rend votre travail plus tranchant chaque semaine ; un mauvais artefact le ralentit chaque semaine, silencieusement, jusqu'à ce que vous remarquiez que la sortie sonne faux sans pouvoir dire pourquoi. C'est la même mécanique de pourriture du contexte que SFEIR traite par le maintien actif et l'évaluation continue du contexte d'agent.

La dérive est insidieuse précisément parce qu'elle est silencieuse. Il n'y a pas d'alerte, pas de message d'erreur, pas de test rouge. Juste une lente érosion de la qualité que personne ne mesure. Le prompt engineering, qui ne raisonne qu'à l'échelle de l'exécution unique, n'a aucun moyen de la détecter. La boucle, elle, a une mémoire et une preuve — deux de ses composants — et c'est exactement ce qu'il faut pour transformer une dérive invisible en un signal mesurable.

De l'exécution à l'amélioration : ce qu'est vraiment une boucle

Une boucle, au sens du Loop Engineering, est un cycle répété : modifier un artefact qui façonne l'agent, lancer l'agent, évaluer la sortie, garder ou révoquer le changement, puis committer l'apprentissage. Le passage du prompt à la boucle est le passage de l'exécution à l'amélioration. Shubham Saboo le décrit étape par étape : vous changez quelque chose qui façonne le comportement de l'agent ; vous lancez l'agent ; vous évaluez la sortie ; vous gardez le changement si la qualité s'améliore et vous le révoquez si elle baisse ; puis vous committez l'apprentissage pour que la version suivante démarre en avance sur la précédente.

Remarquez ce qui se passe ici. Chaque tour de boucle ne produit pas seulement un résultat ; il produit aussi un apprentissage qui est conservé. C'est la différence cardinale avec le prompt. Le prompt produit un résultat et oublie. La boucle produit un résultat, le mesure, en tire une conclusion, et inscrit cette conclusion quelque part de durable — un fichier, un dépôt Git, un board. La prochaine itération hérite de tout ce qui a été appris. Comme le dit Osmani d'une formule frappante : « The agent forgets, the repo doesn't » — l'agent oublie, le dépôt non.

Prenons un exemple concret pour ancrer la différence. La version « prompt » de la recherche client consiste à demander à un agent : « Résume-moi ces appels. » C'est utile une fois, mais cela ne s'améliore pas la fois suivante. La version « artefact » consiste à construire un résumeur d'appels clients qui sait ce qui compte pour votre équipe : points de douleur, contournements actuels, urgence, objections, manques produit, citations exactes, suivis. La version « boucle » tourne chaque semaine : elle utilise le résumeur, compare les nouveaux appels aux thèmes précédents, signale ce qui se répète, ce qui est nouveau, et là où les preuves sont minces. Vous relisez la sortie. Si le résumé a raté une nuance, vous améliorez l'artefact — pas le prompt. La fois suivante, c'est meilleur.

Cette gradation — prompt jetable, artefact réutilisable, boucle qui améliore l'artefact — est le cœur du paradigme. Et elle explique pourquoi le travail ne consiste plus à coder ni à prompter directement, mais à construire ces boucles automatisées.

« Mon travail est d'écrire des boucles » : ce que Cherny a vraiment dit

La formule de Boris Cherny, créateur de Claude Code chez Anthropic, est devenue le slogan du mouvement, mais il vaut la peine de la replacer dans son contexte complet, car elle raconte une trajectoire. Lors de l'événement WorkOS de juin 2026 (entretien Acquired Unplugged), Cherny a décrit trois stades de son évolution personnelle. Premier stade : « The way that I coded a year ago was I wrote code with some autocomplete in the IDE » — il y a un an, j'écrivais du code avec un peu d'autocomplétion dans l'IDE. Deuxième stade : il faisait tourner cinq à dix Claude en parallèle, et son travail consistait à prompter Claude pour qu'il écrive le code. Troisième stade — le présent : « I don't prompt Claude anymore. I have loops running that prompt Claude and figuring out what to do. My job is to write loops. »

Il ajoute un détail révélateur : il aurait désinstallé son IDE faute de l'utiliser encore. Voilà la mesure du déplacement : un des meilleurs ingénieurs de sa génération n'ouvre plus d'éditeur de code. Lors de son intervention à Sequoia AI Ascent, il a résumé sa conviction : « I just have a bunch of loops running at any time. I sort of feel like loops are the future at this point » — j'ai simplement un tas de boucles qui tournent en permanence ; j'ai le sentiment que les boucles sont l'avenir, à ce stade. (Ces formulations issues de Sequoia nous parviennent via des transcriptions secondaires ; on les cite donc comme rapportées.)

Il faut résister à une lecture triomphaliste. Osmani, lui-même prudent, insiste : le propos de Cherny n'est pas que le travail est devenu plus facile, c'est que le point de levier s'est déplacé. C'est ce qui rend la conception de boucles plus difficile que le prompt engineering, pas plus facile. On ne supprime pas le jugement ; on le réinvestit ailleurs, à un niveau plus élevé d'abstraction. C'est précisément la thèse que SFEIR développe sous le nom de Harness Engineering : à modèle égal, ce qui fait la différence n'est plus la requête, mais le système qui encadre l'agent.

Pourquoi « mort » est le bon mot — et pourquoi c'est exagéré

Le prompt engineering est « mort » comme discipline centrale et comme métier autonome, mais survit comme composant interne de la boucle. Affirmer sa mort est à la fois juste et trompeur, et il est honnête de tenir les deux bouts.

C'est juste au sens où la compétence rare n'est plus de formuler la requête parfaite. Les modèles intuitent mieux l'intention, et surtout, l'horizon a changé : on ne cherche plus à réussir une tâche, on cherche à construire un système qui réussit la tâche de façon répétée et croissante. Dans ce monde, savoir écrire un excellent prompt isolé est une compétence de plus en plus marginale, de la même manière que savoir écrire un excellent assembleur est devenu marginal à mesure que les langages de haut niveau s'imposaient.

Mais c'est trompeur si l'on en conclut que le prompt n'a plus d'importance. Le prompt ne disparaît pas ; il change de statut. Il devient le cas dégénéré de la boucle : une boucle à une seule itération, sans mémoire ni preuve ni condition d'arrêt. À l'intérieur d'une boucle, il y a toujours un prompt — l'action que l'agent exécute à chaque tour. Et la qualité de ce prompt continue de compter. Simplement, ce n'est plus le levier principal. On pourrait dire que le prompt engineering n'est pas mort ; il a été absorbé, ravalé au rang de composant d'un système plus large.

La distinction est importante pour qui veut adopter le Loop Engineering sans jeter le bébé avec l'eau du bain. Les bonnes pratiques de formulation — clarté, contexte, exemples positifs et négatifs, raisonnement par étapes, balises structurées — restent utiles. Elles s'appliquent désormais à l'action interne de la boucle, et aux artefacts durables (les SKILL.md, les CLAUDE.md) qui guident l'agent. Le prompt engineering devient une compétence de second rang au service du Loop Engineering, exactement comme la calligraphie est devenue un raffinement au service de l'écriture, et non sa condition.

Une objection honnête : et si tout cela n'était qu'un effet de mode ?

Il serait malhonnête de présenter le Loop Engineering sans entendre l'objection qui revient à chaque nouveau paradigme : n'est-ce pas simplement le buzzword de la saison, qui sera remplacé dans six mois par le suivant ? La question est légitime, et la généalogie même du concept — quatre paradigmes en trois ans — pourrait nourrir le scepticisme. Le doute est d'ailleurs renforcé par l'ambiguïté du terme lui-même : « loop » évoque d'abord la boucle d'événements, la boucle de jeu ou le redouté crash-loop-backoff de Kubernetes avant d'évoquer une discipline d'ingénierie IA.

Deux éléments de réponse, sans triomphalisme. D'abord, le Loop Engineering n'invente pas une technique nouvelle ; il nomme une pratique que des praticiens de tout premier plan ont adoptée indépendamment et avant que le mot n'existe. Boris Cherny avait abandonné son IDE bien avant l'article d'Osmani de juin 2026. Geoffrey Huntley faisait déjà tourner sa boucle « Ralph Wiggum » courant 2025. Le terme est récent, mais la chose qu'il décrit est observée et reproductible. C'est l'inverse d'un buzzword creux : c'est un mot tardif posé sur une pratique déjà installée.

Ensuite, et c'est le plus important, le Loop Engineering est honnête sur ses propres limites. Les sources les plus sérieuses — Osmani au premier chef — passent autant de temps à décrire les dettes (vérification, compréhension, reddition cognitive) qu'à vanter les bénéfices. Un effet de mode promet la facilité ; le Loop Engineering promet l'inverse : plus de difficulté, plus de jugement, à un niveau d'abstraction plus élevé. Cette franchise sur le coût cognitif est précisément ce qui le distingue d'une promesse marketing. Reste que la prudence s'impose sur le vocabulaire : il est probable qu'un terme encore plus englobant émerge dans l'année. Mais la dynamique de fond — le développeur qui recule d'un cran pour concevoir le système plutôt que d'exécuter la tâche — paraît, elle, durable.

Trois changements de posture pour passer à la boucle

Si vous travaillez quotidiennement avec des agents, le passage au Loop Engineering implique trois changements de posture concrets.

D'abord, arrêtez de soigner vos prompts comme des œuvres uniques et commencez à soigner vos artefacts comme du code de production. Un fichier CLAUDE.md, une skill, un rubric : ce sont des actifs versionnés, qui méritent un historique, des revues et des tests. Quand quelque chose ne va pas, ne réécrivez pas le prompt dans le chat — corrigez l'artefact, et committez la correction. C'est aussi un changement de regard sur le coût : le contexte d'un agent n'est pas une dépense à minimiser mais un actif à budgéter, d'autant que les boucles fréquentes et les sous-agents font grimper la consommation de tokens — de l'ordre de 15× en configuration multi-agents selon les mesures rapportées par Anthropic.

Ensuite, instrumentez la qualité. La dérive est silencieuse ; rendez-la bruyante. Cela passe par des évaluations (evals) : prenez quelques exemples dont vous connaissez la bonne réponse, faites tourner votre artefact dessus, et mesurez s'il s'améliore vraiment. Comme le résume Simon Willison, les evals sont aux artefacts IA ce que les tests unitaires sont au code. Sans cette boucle de preuve, vous naviguez à l'aveugle — et « done » reste une affirmation de l'agent, jamais une preuve.

Enfin, choisissez vos batailles. Toutes les tâches ne méritent pas une boucle. Une boucle a un coût de conception et un coût en tokens. Réservez-la aux tâches répétées, où la cohérence compte et où les preuves existent. Pour le reste, un bon prompt ponctuel fait encore parfaitement l'affaire. Le meilleur ingénieur — comme le meilleur PM — ne sera pas celui qui a la plus longue bibliothèque de prompts, mais celui qui sait quelles tâches doivent devenir des boucles durables et lesquelles peuvent rester jetables.

Le prompt engineering nous a appris à parler aux machines. Le Loop Engineering nous apprend à construire les machines qui se parlent à elles-mêmes. C'est un saut d'abstraction, pas une simplification. Et c'est précisément parce qu'il est plus exigeant qu'il est plus puissant.

Ce qui survit du prompt engineering

Annoncer la mort du prompt engineering ne doit pas faire jeter ses acquis, car plusieurs d'entre eux survivent intacts — simplement déplacés à l'intérieur de la boucle, où ils constituent la matière première de l'action que l'agent exécute à chaque tour.

La clarté reste reine, et l'exigence est même plus forte : un prompt ambigu produisait un résultat médiocre ; une action de boucle ambiguë en produit des centaines. L'art de fournir des exemples positifs et négatifs, de demander un raisonnement par étapes, de structurer la sortie : ces techniques continuent de s'appliquer, désormais inscrites dans des artefacts durables comme les fichiers de skills plutôt que tapées au fil de l'eau. Ce qui change, c'est leur statut. Hier, elles étaient le levier principal ; aujourd'hui, elles sont un levier secondaire au service de la conception du système — exactement comme les langages de haut niveau n'ont pas aboli la compréhension fine de la machine, mais l'ont reléguée à un rôle de spécialiste.

La leçon pratique est donc nuancée : ne désapprenez pas à bien prompter, mais cessez d'en faire votre objectif principal. Réinvestissez cette compétence dans la qualité de vos artefacts et faites du véritable travail de conception, celui des boucles, votre nouveau centre de gravité. Le prompt engineering n'est pas mort ; il a été promu composant d'un système plus vaste, et c'est une forme de survie plutôt enviable.

Points clés

• Le prompt engineering optimise une exécution unique ; le Loop Engineering optimise un système qui s'améliore à chaque itération. C'est un changement d'objet de travail, pas une simple amélioration d'outil (Addy Osmani, 2026).
• « The agent forgets, the repo doesn't » : la boucle conserve l'apprentissage de chaque tour dans un artefact durable (fichier, dépôt Git), là où le prompt oublie tout avec la fenêtre de contexte.
• La dérive (drift) est l'ennemi que seule la boucle combat : les artefacts IA réutilisés se dégradent silencieusement sans mémoire ni évaluation pour les surveiller.
• « My job is to write loops » : Boris Cherny (Anthropic) décrit un troisième stade où il ne prompte plus l'agent mais conçoit les boucles qui le pilotent.
• Le prompt n'est pas supprimé, il est absorbé : il devient le cas dégénéré de la boucle (une itération, sans mémoire ni preuve ni arrêt) ; clarté, exemples et structure restent utiles à l'intérieur des artefacts.
• Le Loop Engineering est plus difficile, pas plus facile : le levier se déplace vers un niveau d'abstraction supérieur, avec un coût en tokens accru (de l'ordre de 15× en multi-agents, selon Anthropic) et une vérification humaine indispensable.

Sources

1. Addy Osmani — Loop Engineering — addyosmani.com, 7 juin 2026.
2. Business Insider — Forget prompt engineering: 'Loop engineering' is all the rage now — businessinsider.com, juin 2026.
3. Boris Cherny — Claude Code & the Future of Engineering (Acquired Unplugged, WorkOS) — youtube.com, juin 2026.
4. Shubham Saboo — Loop Engineering for PM.
5. Geoffrey Huntley — Ralph Wiggum (boucle d'agent autonome), 2025.
6. Simon Willison — Evals as unit tests.
7. SFEIR — matières first-party : Context Engineering, Harness Engineering.