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

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.

💬 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.

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.

« 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.

Les agents IA ne se trompent pas avec assurance à cause d'un mauvais contexte, mais d'une mauvaise ingénierie des données

Un scénario revient de plus en plus souvent dans les équipes qui déploient des chatbots d'entreprise basés sur l'IA : after weeks de réglages, les réponses sont validées par les parties prenantes, le système est mis en production, puis trois mois plus tard il se trompe avec assurance sur environ un tiers des questions posées, sans que personne n'ait touché au modèle ni aux prompts. La cause n'est pas technique au sens classique : les prix ont changé, une politique a été mise à jour, une fiche produit est sortie dans une nouvelle version, et la base de connaissances sous-jacente n'a pas suivi. Un exemple similaire s'est produit dans une chaîne de traitement de données fintech : un système amont a modifié un champ sans prévenir les systèmes en aval, et le pipeline n'a jamais échoué au sens strict puisqu'il continuait de faire remonter des valeurs, simplement fausses, dans les tableaux de bord, jusqu'à ce qu'un client signale une incohérence. Un document de tarification obsolète est récupéré avec la même confiance qu'un document à jour, car le système évalue la pertinence ou la disponibilité de l'information, jamais son exactitude. Ce type de panne est particulièrement dangereux car il reste invisible : tous les indicateurs de supervision restent au vert, le pipeline tourne, le job se termine sans erreur, et pourtant la donnée servie est fausse. Face à ce problème, les équipes commettent généralement la même erreur de diagnostic à deux reprises : elles soupçonnent d'abord le modèle de langage et changent de LLM ou ajustent les prompts, puis, une fois cette piste écartée, elles blâment la couche de récupération de contexte et cherchent à acheter un meilleur outil de retrieval. Or le vrai problème se situe plus en amont, au niveau de l'ingénierie des données elle-même : la supervision existante vérifie si un traitement s'est exécuté, pas si la donnée qu'il a transportée est toujours vraie, un biais qui précède largement l'arrivée de l'IA générative en entreprise. Ce diagnostic explique la ruée actuelle des grands fournisseurs cloud vers ce qu'on appelle la couche de contexte. Amazon Web Services vient d'entrer dans cette course avec un graphe de connaissances qui apprend de l'usage des agents IA, tandis que Snowflake a lancé Horizon Context et Cortex Sense pour cibler précisément ce symptôme de réponses erronées mais confiantes. Ces réponses restent toutefois une couche au-dessus du vrai enjeu, puisqu'un graphe de connaissances dépend toujours de ce qui l'alimente en amont. La solution, selon l'auteur, passe par une véritable observabilité des données, un concept déjà ancien mais encore mal appliqué, où la métrique clé n'est pas un pourcentage de disponibilité mais la couverture réelle de la traçabilité des jeux de données critiques, un chantier qu'Uber a par exemple structuré via une équipe dédiée à la qualité et à l'observabilité des données.