Aller au contenu principal
L'ingénierie de prompts contre celle des boucles et des graphes : ce qui change à chaque niveau
OutilsMarkTechPost · 3 min de lecture

L'ingénierie de prompts contre celle des boucles et des graphes : ce qui change à chaque niveau

Source originale ↗·

Trois termes se disputent aujourd'hui la même ligne dans les offres d'emploi en ingénierie IA : prompt engineering, loop engineering et graph engineering. Le premier est le terme historique. Le loop engineering est apparu dans le vocabulaire fin 2025 et a dominé les discussions de développeurs jusqu'en juin 2026. Le graph engineering a suivi environ six semaines plus tard. Ces trois approches ne sont pas des techniques concurrentes mais trois niveaux de contrôle empilés : un prompt régit une seule réponse de modèle, une loop régit le cycle de comportement d'un agent, un graph organise plusieurs agents entre eux. Anthropic recommande de structurer un system prompt en sections étiquetées (contexte, instructions, usage des outils, format de sortie), délimitées par des balises XML ou des titres Markdown, en fournissant l'ensemble minimal d'informations qui spécifie complètement le comportement attendu, minimal ne signifiant pas court. Vient ensuite le context engineering, décrit par Anthropic comme le prolongement naturel du prompt engineering : la question n'est plus de trouver les bons mots mais de décider quelle configuration de tokens doit occuper la fenêtre de contexte, une ressource finie. Le harness engineering couvre l'environnement dans lequel tourne un agent seul (fichiers, outils, mémoire, retours), tandis que le loop engineering se situe un niveau au-dessus. Un article publié sur arXiv en juin 2026 sur l'IA agentique appliquée à l'ingénierie du bâtiment, intitulé Buildrix, détaille cette progression en quatre étapes : prompt, contexte, harness, puis loop, ce dernier niveau définissant comment un système observe, agit, vérifie et se corrige de façon répétée.

Cette hiérarchisation compte parce qu'elle explique pourquoi le prompt engineering seul cesse de suffire dans certaines situations concrètes : volume élevé de requêtes, tâches multi-étapes, absence d'humain disponible pour juger chaque sortie, résultats qui alimentent automatiquement l'étape suivante. Rien ne se dégrade dans le prompt lui-même ; ce sont les conditions qui changent autour de lui. Pour les équipes qui construisent des agents de codage ou des systèmes multi-agents, la compétence à développer ne se limite plus à la formulation de l'instruction mais s'étend à la conception du cycle complet (objectif, outils, boucle de vérification) et, à l'échelle supérieure, à l'organisation de plusieurs agents travaillant en parallèle. Anthropic illustre ce point avec son propre système de recherche multi-agents : les premières versions faisaient partir 50 sous-agents pour des requêtes pourtant simples, et la correction est passée par le prompt engineering plutôt que par un changement de topologie du système, preuve que la couche la plus basse ne disparaît jamais, même quand des couches plus complexes sont ajoutées par-dessus.

Le terme loop engineering s'est imposé dans le débat public en juin 2026, après qu'un post largement partagé a appelé les ingénieurs à cesser de simplement prompter les agents de codage pour se mettre à concevoir les boucles qui les pilotent, présentant l'agent de codage comme un outil de recherche de solutions par force brute dont la vraie valeur ajoutée réside dans la conception de l'objectif, des outils et de la boucle. L'équipe Claude Code d'Anthropic a décrit publiquement le même virage la même semaine. La description la plus détaillée de cette approche identifie cinq briques de base reliées par un sixième élément, dont les automatisations, qui déclenchent découverte et tri sans supervision selon un calendrier ou un événement, et les worktrees, qui isolent les agents travaillant en parallèle pour qu'ils ne modifient jamais le même fichier en même temps. Le graph engineering, la dernière étiquette apparue, reste la moins stabilisée : son origine exacte est débattue et le terme entre en collision avec l'usage plus ancien de « graph » dans le contexte des bases de connaissances, même si la pratique sous-jacente d'orchestration par graphe s'appuie sur une lignée déjà documentée dans la recherche sur les systèmes multi-agents.

Cet article vous a été utile ?

Vu une erreur factuelle dans cet article ? Signalez-la. Toutes les corrections valides sont publiées sur /corrections.

À lire aussi

« Prompt Engineering, Loop Engineering, Graph Engineering : ce qui change à chaque niveau »
1MarkTechPost 

« Prompt Engineering, Loop Engineering, Graph Engineering : ce qui change à chaque niveau »

Trois termes se disputent aujourd'hui la même ligne dans les descriptions de poste en ingénierie IA. Le « prompt engineering » est le plus ancien et le plus établi. Le « loop engineering » (ingénierie de boucle) a fait son apparition dans le vocabulaire de l'IA fin 2025 et a dominé les discussions entre développeurs jusqu'en juin 2026. Le « graph engineering » (ingénierie de graphe) a suivi environ six semaines plus tard. Anthropic recommande par exemple de structurer un prompt système en sections clairement identifiées, contexte, instructions, usage des outils, format de sortie, délimitées par des balises XML ou des titres Markdown, en fournissant l'ensemble minimal d'informations qui définit entièrement le comportement attendu. Un article publié sur arXiv en juin 2026, consacré à l'IA agentique dans l'ingénierie du bâtiment sous le nom de Buildrix, formalise une progression en quatre étapes : le prompt, puis le contexte, puis l'environnement d'exécution de l'agent (le « harness »), puis la boucle, cette dernière définissant comment un système observe, agit, vérifie et corrige de façon répétée. Anthropic a aussi rapporté que, dans ses recherches sur les systèmes multi-agents, un bug faisant naître jusqu'à 50 sous-agents pour de simples requêtes a été corrigé non pas en changeant l'architecture, mais en retravaillant les prompts. Ces trois approches ne sont pas des techniques concurrentes mais trois niveaux de contrôle empilés, chacun préservant celui qui se trouve en dessous. Un prompt gouverne une seule réponse d'un modèle. Une boucle gouverne le cycle de comportement d'un agent entier. Un graphe gouverne l'organisation de plusieurs agents entre eux. Cette distinction compte concrètement pour les équipes techniques : concevoir une boucle ne revient pas à écrire un meilleur prompt, mais à définir un objectif, des outils et un mécanisme de correction autonome, avec des éléments comme les automatisations, qui déclenchent une découverte et un tri sans supervision humaine, ou les copies de travail isolées, qui empêchent des agents parallèles de modifier les mêmes fichiers. L'enjeu pour les entreprises est de savoir à quel moment il devient rentable d'investir dans ces couches supérieures plutôt que de continuer à optimiser de simples instructions. Cette hiérarchie s'est imposée dans la pratique avant d'apparaître dans la documentation des fournisseurs, ce qui explique en partie la confusion actuelle sur les définitions. Le terme « graph engineering » reste le moins stabilisé : son origine exacte est débattue et il entre en collision avec l'usage plus ancien de « graphe de connaissances », même si l'orchestration multi-agents fondée sur des graphes possède une filiation bien documentée dans la recherche. Cette imprécision terminologique justifie une certaine prudence face à l'engouement du marché, d'autant que le prompt engineering, loin de disparaître, reste selon Anthropic le levier principal pour corriger les défaillances de coordination, même dans les systèmes les plus complexes.

💬 C'est le genre de débat de vocabulaire qui arrive toujours après coup, jamais avant. Le point utile là-dedans : trois niveaux de contrôle, pas trois écoles rivales, chacun bâti sur celui d'en dessous, et un prompt bien écrit règle encore plus de bugs qu'une archi repensée, même chez Anthropic sur du multi-agents. Retiens surtout ça : avant d'investir dans une boucle ou un graphe, vérifie que t'as pas juste un problème de prompt mal foutu, ça coûte cent fois moins cher à corriger.

LLMsOpinion
1 source
Guide de l'ingénierie des boucles : comment 'autoresearch' et 'Bilevel Autoresearch' transforment les agents IA en boucles autonomes de recherche en machine learning
2MarkTechPost 

Guide de l'ingénierie des boucles : comment 'autoresearch' et 'Bilevel Autoresearch' transforment les agents IA en boucles autonomes de recherche en machine learning

Ancien mode d'usage de l'IA : on tape une instruction, on lit la réponse, on recommence manuellement. Un nouveau paradigme appelé "loop engineering" remplace cet aller-retour par une boucle autonome où le modèle planifie, agit, vérifie son propre résultat, puis recommence jusqu'à atteindre un objectif fixé une seule fois par l'humain. Le 7 mars 2026, Andrej Karpathy a publié en open source sous licence MIT le dépôt "autoresearch", à peine trois fichiers et environ 630 lignes de code, qui a atteint près de 90 000 étoiles sur GitHub en quelques jours et donné son nom au procédé baptisé "Karpathy Loop". Le système limite volontairement l'agent : il ne peut modifier que le fichier train.py, qui contient le modèle GPT, les optimiseurs Muon et AdamW et la boucle d'entraînement, mais n'a pas accès au fichier prepare.py qui gère l'évaluation, empêchant ainsi l'agent de tricher en simplifiant le test plutôt qu'en améliorant le modèle. Un humain rédige les consignes dans un fichier program.md, et chaque cycle consiste à proposer une modification, entraîner le modèle pendant cinq minutes, puis conserver ou annuler le changement selon la métrique valbpb, les bits par octet en validation, où une valeur plus basse est meilleure. Ce rythme permet environ 12 expériences par heure, soit une centaine pendant une nuit. Les résultats rapportés par Karpathy sont concrets : appliqué à son code d'entraînement déjà optimisé nanochat GPT-2, le système a tourné deux jours, réalisé environ 700 expériences et conservé 20 améliorations réelles, réduisant le temps d'entraînement de 11 %, de 2,02 à 1,80 heure. L'une des corrections concernait une implémentation de QK-Norm à laquelle manquait un multiplicateur scalaire, ce qui diluait excessivement l'attention entre les têtes du modèle. Karpathy souligne qu'un humain se lasse après une douzaine d'expériences, alors que la boucle continue sans relâche. Tobi Lütke, PDG de Shopify, a testé le système sur un modèle interne pendant une nuit et obtenu une amélioration de 19 % après 37 expériences, confirmant l'intérêt de la méthode dès lors qu'une métrique objective existe. Ce constat a fait émerger une variante plus ambitieuse, "Bilevel Autoresearch", qui ajoute un second agent superviseur au-dessus de l'agent exécutant, avec un journal d'expériences enrichi de code injecté, et revendique une baisse de valbpb cinq fois supérieure à la boucle simple. Pour fonctionner de façon fiable, toute boucle repose sur trois éléments : un vérificateur objectif qui note chaque tentative, un état persistant qui mémorise les essais passés, et une condition d'arrêt qui limite le coût. Les équipes d'ingénierie IA assemblent désormais ces boucles à partir de cinq briques réutilisables : l'automatisation qui déclenche le cycle, une base de connaissances au format markdown, des agents spécialisés qui séparent rédaction et relecture, des connecteurs vers des outils réels comme un gestionnaire de tickets, et un vérificateur qui reste la garantie finale contre les résultats médiocres.

💬 Faut pas se laisser distraire par les 90 000 étoiles, le truc important c'est que Karpathy a trouvé la formule qui manquait : un vérificateur objectif, un état persistant, une condition d'arrêt, et l'agent tourne toute la nuit sans se lasser. 700 expériences en deux jours pour gagner 11 % sur du code déjà optimisé, un humain n'aurait jamais tenu ce rythme. Reste que ça ne marche que si t'as une métrique claire à optimiser, dès que le critère de succès devient flou la boucle tourne dans le vide.

OutilsOutil
1 source
MCP fait l'objet de sa plus grande mise à jour : voici ce qui change pour les agents IA
3VentureBeat AI 

MCP fait l'objet de sa plus grande mise à jour : voici ce qui change pour les agents IA

Le Model Context Protocol, le standard ouvert créé par Anthropic pour connecter les agents d'IA aux logiciels, vient de recevoir sa mise à jour la plus importante depuis son lancement il y a vingt mois. Publiée sous l'égide de l'Agentic AI Foundation (AAIF), une fondation dirigée hébergée par la Linux Foundation, cette révision achève la transition de MCP vers une architecture entièrement stateless (sans état), renforce le modèle d'authentification contre une classe connue d'attaques, instaure une politique formelle de dépréciation sur douze mois, et fait passer deux fonctionnalités phares au rang d'extensions officielles du protocole : les interfaces interactives rendues côté serveur et les tâches asynchrones de longue durée. David Soria Parra, co-créateur de MCP et mainteneur principal chez Anthropic, a confié à VentureBeat que certains qualifient déjà cette version de "v2 officieuse", ajoutant qu'il s'agit du plus grand changement jamais apporté au protocole. Den Delimarsky, également mainteneur, et Mazin Gilbert, directeur exécutif de l'AAIF et ancien de Google et AT&T, ont tous deux participé à l'annonce aux côtés de nombreuses entreprises partenaires. Ce changement technique répond à un problème très concret qui freinait le déploiement des agents IA en entreprise. Jusqu'ici, un client MCP devait maintenir une session persistante avec une instance de serveur précise, ce qui imposait un "routage collant" (sticky routing) ou un état partagé pour assurer la continuité entre les requêtes. Dans les environnements cloud modernes, où des flottes de machines interchangeables apparaissent et disparaissent derrière des répartiteurs de charge, cette contrainte posait un problème majeur : si le pod hébergeant la session tombait, tout le travail de l'agent était perdu. La nouvelle architecture stateless supprime ce verrou en permettant aux serveurs MCP de fonctionner derrière des load balancers standards, avec les outils Kubernetes et DevOps cloud-natifs déjà utilisés par les entreprises. Selon Gilbert, cette limitation était devenue le principal obstacle empêchant les entreprises de faire passer leurs agents IA du stade pilote à la production à grande échelle, certaines cherchant à déployer des dizaines de milliers d'agents simultanément. Le débat sur les limites du modèle stateful de MCP ne date pas d'hier : dès décembre 2024, quelques semaines seulement après le lancement du protocole, Justin Spahr-Summers, autre co-créateur de MCP, avait ouvert une discussion publique sur GitHub pointant déjà les contraintes des connexions persistantes pour les déploiements serverless. Cette nouvelle version répond directement à ces préoccupations en associant les grands acteurs du secteur au processus de conception, l'AAIF ayant été mise en place précisément pour donner une gouvernance neutre et pérenne à ce standard désormais central dans l'écosystème des agents IA. Avec une politique de dépréciation encadrée sur douze mois et des extensions officielles pour les interfaces interactives et les tâches longues, MCP se positionne comme l'infrastructure de référence pour connecter durablement les agents IA aux logiciels d'entreprise, ouvrant la voie à des déploiements massifs jusqu'ici techniquement impossibles.

UELes entreprises françaises et européennes qui déploient des agents IA via MCP bénéficieront d'une architecture stateless plus robuste et d'une authentification renforcée, facilitant le passage à l'échelle en production, mais aucun acteur ou texte réglementaire français ou européen n'est directement concerné ici.

💬 Cette mise à jour stateless, c'est le truc qu'on attendait depuis que MCP existe. Tant qu'un agent avait besoin d'une session collée à un pod précis, aucune boîte sérieuse n'allait déployer ça à l'échelle, un load balancer qui redémarre et tout ton travail part en fumée. Là, MCP devient enfin compatible avec la façon dont le cloud fonctionne vraiment, et c'est ça, plus que l'authentification ou les extensions, qui va faire basculer les agents du pilote à la prod.

OutilsActu
1 source
« Le grand débat sur les loops et l'état de l'ingénierie IA » (AIEWF Daily Dispatch)
4Latent Space 

« Le grand débat sur les loops et l'état de l'ingénierie IA » (AIEWF Daily Dispatch)

Lors de la dernière journée de l'AI Engineer World's Fair (AIEWF), un débat animé a opposé partisans et sceptiques des "loops", ces boucles d'agents IA autonomes capables de coder de façon quasi indépendante. Modéré par Allie Howe de Keycard, l'échange réunissait Geoffrey Huntley, créateur du Ralph Loop, et Ian Livingstone, PDG de Keycard, dans le camp favorable, face à Dex Horthy de HumanLayer et Greg Pstrucha de Subroutine côté sceptique. Huntley a affirmé que les loops sont déjà une réalité incontournable, déclarant ne plus vouloir revenir à l'écriture de code manuelle. Livingstone a insisté sur la vérifiabilité comme critère central, peu importe la méthode de production du code. Horthy a nuancé en soulignant que des systèmes comme Kubernetes reposent depuis longtemps sur des boucles de contrôle, mais déterministes, contrairement aux loops d'agents actuels. Il estime que l'enthousiasme dépasse largement la maturité technique du domaine. Pstrucha, de son côté, a pointé un problème de viabilité économique, rappelant qu'on ne peut pas résoudre ses problèmes en achetant simplement plus de tokens. En fin de débat, un vote du public n'a pu être dépouillé faute de visibilité, les projecteurs de scène empêchant de compter les mains levées. Cette controverse illustre un enjeu majeur pour l'industrie du développement logiciel: la promesse des "usines logicielles" entièrement automatisées se heurte à des limites bien réelles de fiabilité, de coût et de contrôle humain. Horthy a averti que l'automatisation totale risque de faire perdre aux développeurs tout contact direct avec les problèmes qu'ils sont censés résoudre, recommandant plutôt une approche progressive permettant de construire une intuition avant d'étendre l'automatisation. Même Huntley, malgré son enthousiasme, a reconnu que ce modèle relève encore d'une réflexion de pointe et n'est pas résolu à l'échelle du marché. Pour les ingénieurs et les entreprises qui investissent dans ces outils, ce débat conditionne directement les choix d'architecture et de budget à venir. En parallèle, Anthropic a illustré une possible transition vers ce modèle d'usine logicielle avec Claude Tag, son nouveau modèle interne annoncé la semaine précédente. Mike Krieger, cofondateur d'Instagram et aujourd'hui responsable du laboratoire d'Anthropic, a présenté cet outil lors d'un entretien avec swyx comme plus délégué, asynchrone et proactif que Claude. Selon lui, l'essentiel de l'usage interne consiste désormais à confier des responsabilités entières à l'agent plutôt qu'à corriger des tâches ponctuelles, illustrant une évolution vers des équipes qui délèguent des pans entiers de codebase à des systèmes autonomes plutôt que de remplacer les développeurs eux-mêmes.

💬 Le vote du public qu'on n'a pas pu compter à cause des projecteurs, tu trouves pas que ça résume bien le débat ? Ce qu'il révèle, c'est que la vraie question n'est plus de savoir si l'IA code toute seule, mais si quelqu'un reste capable de vérifier ce qu'elle produit avant que ça parte en prod. Et le move d'Anthropic avec Claude Tag, déléguer des pans entiers de codebase plutôt que des tâches ponctuelles, montre que le boulot de dev est déjà en train de changer, loops ou pas.

OutilsOutil
1 source

Recevez l'essentiel de l'IA chaque jour

Une sélection éditoriale quotidienne, sans bruit. Directement dans votre boîte mail.

Recevez l'essentiel de l'IA chaque jour

Gratuit · 1 email le matin, l'essentiel de l'IA · désinscription en un clic