Vous l'avez déjà vécu. Vous demandez une chose au modèle, il livre, puis vous dites « en fait, fais plutôt X », et la qualité baisse d'un cran. Ce n'est pas votre imagination, et ce n'est pas seulement votre modèle. En juillet 2026, Microsoft Research a chiffré le phénomène sur neuf modèles, propriétaires comme ouverts, et la chute est apparue dans chacun d'entre eux.
Des scores solides en un seul tour ne survivent pas à la discussion.
La méthode est la partie astucieuse, et elle mérite une phrase, parce que c'est elle qui rend les chiffres fiables dans leur forme. On prend une question de banc d'essai à réponse connue, on l'épingle comme la toute dernière chose que dit l'utilisateur, puis on synthétise une conversation plausible qui y mène : une première demande, une correction, un changement de plan. Le correcteur original note toujours la réponse finale, donc aucun « juge IA » flou n'entre dans la boucle. L'article fait ensuite tourner les mêmes tâches de deux façons : énoncées une fois, en entier (les auteurs appellent ça single), et livrées comme cette conversation évolutive (evolve).
Voici les mathématiques de niveau primaire, le domaine le plus facile de l'étude, où chaque modèle répond presque parfaitement quand vous énoncez le problème une seule fois.
Mêmes problèmes, mêmes réponses, mêmes modèles. La seule chose qui a changé, c'est que l'objectif est arrivé par morceaux, avec une correction et un changement de direction en cours de route, et chaque modèle a perdu entre 16 et 22 points. Microsoft Research rapporte le chiffre phare : GPT 5.5 glisse de 99,0 % à 80,5 % après six changements d'intention. Les domaines plus difficiles (requêtes de base de données, recherche agentique, corrections de code) chutent davantage, et le classement ne survit pas au déplacement : certains modèles qui se valent sur le test statique se séparent dès que l'intention se met à bouger.
Ajouter coûte peu. Changer de tâche coûte cher.
L'article découpe les façons dont l'intention bouge en exactement trois types, et ils ne coûtent pas le même prix.
Révéler (reveal), c'est un nouveau détail, le même objectif. « Trouve-moi un restaurant à New York », puis « je suis végane ». Le portrait ne fait que s'enrichir. Réviser (revise), c'est une valeur modifiée. New York devient Brooklyn, et le modèle doit écraser une croyance. Changer (switch), c'est une tâche modifiée. « Trouve un restaurant » devient « réserve-le », et le modèle doit mettre de côté la majeure partie de ce qu'il faisait. Appliqués un à la fois sur les mêmes maths, les deux premiers bougent à peine l'aiguille. Le troisième tombe d'une falaise, et il entraîne avec lui tout ce qui se compose avec lui.
L'explication des auteurs est la partie utile, et je l'attribue clairement : un changement de tâche « demands a larger belief state update » (en anglais dans l'original ; littéralement : « exige une mise à jour plus large de l'état de croyance »), parce que le modèle doit écarter le contexte qu'il avait déjà bâti plutôt que d'en absorber davantage. Ajouter est facile. Invalider est difficile. Une analyse complémentaire précise le tableau : les modèles gèrent surtout bien le changement au moment où il survient, puis perdent du terrain sur tout ce qui vient après, parce qu'ils « struggle to jointly integrate the context before the switch with the updates introduced afterwards » (en anglais dans l'original ; littéralement : « peinent à intégrer conjointement le contexte d'avant le changement avec les mises à jour introduites après »). Le pivot en lui-même n'est pas le problème. Ce qui l'est, c'est de garder le travail d'avant le pivot et la correction d'après le pivot dans un seul portrait cohérent, tour après tour.
Ce n'est pas que le modèle a oublié.
Le correctif évident, c'est de rappeler au modèle ce que vous voulez maintenant. L'article a testé exactement ça, et le résultat explique pourquoi le rappel ne fonctionne qu'à moitié.
Deux expériences séparent deux échecs distincts. La première demande au modèle, à la fin de chaque tour, d'énoncer votre intention actuelle : arrive-t-il seulement à suivre ce que vous voulez ? Presque. Le suivi tient à 96 à 99 % pour les révélations et les révisions, et descend à 82 % pour les changements de tâche (GPT 5.1 en maths). Le modèle ne perd donc pas le fil. La seconde expérience fournit au modèle une reformulation parfaite de votre objectif actuel à chaque tour, puis mesure s'il peut agir en conséquence. Ça aide, et ça reste insuffisant.
Lisez les deux expériences ensemble. Même quand le modèle sait exactement ce que vous voulez actuellement, parce que vous lui avez donné la réponse, l'ancienne conversation encore présente dans son contexte le rend moins bon dans l'exécution du travail. C'est de la pollution de contexte, pas de l'amnésie. « Il suffit de lui rappeler ce que vous voulez » est un correctif partiel par construction, parce que la conversation périmée est elle-même le frein, et qu'un rappel s'ajoute au contexte plutôt que de le nettoyer. Les auteurs énoncent l'autre moitié du problème sans détour : un système doit réduire l'attention portée au contexte périmé, pas seulement réénoncer l'objectif actuel.
Le même phénomène refait surface dans les traces de correction de code, sous une forme plus grossière. Sous intention évolutive, l'agent déverse son budget d'outils dans l'exploration plutôt que dans le travail : moins de 4 appels d'outils sur 100 par tour sont de l'exécution réelle (exécuter le code, modifier le fichier), et le reste, c'est de l'exploration (grep, find, ls). Un budget plus généreux n'a pas aidé, parce que le contexte accumulé et l'historique d'outils étaient eux-mêmes devenus des distractions.
Ce que ça change dans votre façon de travailler.
C'est un article étonnamment applicable, parce que c'est vous, l'utilisateur, dans l'expérience. Chaque longue session avec un agent de code ou un assistant conversationnel est une conversation à intention évolutive : vous révélez l'objectif par morceaux, vous corrigez des valeurs, et parfois vous changez de direction. Quatre choses en découlent, formulées comme ce que les preuves appuient.
- Un vrai pivot mérite une nouvelle session, pas une nouvelle instruction.
Quand la tâche change véritablement (« en fait, faisons plutôt X »), c'est un changement de tâche, la transition la plus coûteuse mesurée, et les dégâts s'accumulent à chaque tour qui suit. Réénoncer l'objectif et continuer aide, sans tout défaire. Repartir à neuf semble du gaspillage, et c'est pourtant le correctif le moins cher de toute l'étude.
cible · pivot de tâche → ouvrir une nouvelle session - Corriger une valeur en cours de session, ça va.
Les révélations et les révisions ne coûtent presque rien. Ajouter une contrainte ou corriger un détail erroné, ce n'est pas ce qui fait mal. Le geste coûteux est le changement en forme de tâche, pas le changement en forme de détail, donc vous n'avez pas à redémarrer chaque fois que vous précisez quelque chose.
cible · précisez librement · redémarrez seulement pour un vrai changement de tâche - Un agent qui dérive a besoin d'un redémarrage, pas d'un budget plus gros.
Quand une longue session agentique se met à relire et à chercher au lieu de modifier et de tester, c'est le symptôme documenté, pas de la malchance. Un budget d'outils plus généreux a empiré la situation dans l'étude. Videz le contexte et réénoncez l'objectif actuel proprement.
cible · dérive = redémarrage propre, pas plus de jetons - Pondérez à la baisse les scores en un seul tour quand vous choisissez un modèle pour du travail collaboratif.
Presque tous les chiffres de banc d'essai que vous lisez sont en un seul tour, et cet article montre que le classement ne survit pas à la dérive. Un modèle qui gagne le test statique peut perdre face à un autre qui tient mieux sous un objectif changeant. Pesez le comportement sous intention évolutive, pas le classement.
cible · jugez vos collaborateurs sur la dérive, pas sur des scores statiques
Ce que nous n'affirmons pas.
C'est un seul préprint, et il mérite ses réserves. Il n'y a ni barres d'erreur ni essais répétés, et les échantillons sont petits (50 tâches de code, 100 chacune pour la base de données et la recherche, 200 pour les maths), donc c'est la direction qui fait preuve, pas les pourcentages exacts. Trois des scores de correction de code sont littéralement à 0,0, et il s'agit d'un artéfact d'échafaudage, pas d'un résultat de capacité : ces modèles ont épuisé leur budget d'outils et ont expiré au lieu de répondre faux, et le budget a été relevé pour deux autres modèles, mais pas pour eux. Nous avons exclu chacune de ces cellules des figures ci-dessus. L'outil qui a rédigé les conversations simulées, GPT 5.1, était lui-même l'un des neuf modèles notés, un point que l'article n'aborde pas. Et les utilisateurs simulés sont scriptés et stylistiquement uniformes, pas de vrais opérateurs dans un vrai dépôt de code. La direction est bien appuyée parce qu'elle apparaît dans chaque modèle et chaque domaine testé. Traitez l'ampleur de l'effet dans votre propre travail comme inconnue, et sa forme comme réelle.
Si vous choisissez un modèle pour du travail collaboratif, ou si vos longues sessions n'arrêtent pas de dériver, le formulaire de contact est le chemin le plus rapide. Envoyez-nous le workflow, on vous renvoie une lecture écrite, sans appel requis.