Un assistant IA interrompu perd le fil : onze points de réussite en moins

Il est 9 h. Votre développeur attaque la refonte de la facturation. À 9 h 20, un client signale une panne. À 10 h, le comptable relance sur un tableau de chiffres faux. À 11 h, il revient à la facturation. Il relit ses notes, rouvre quatre fichiers, et repart sur une mauvaise hypothèse.

Vous connaissez ce coût, et vous l'avez accepté comme une fatalité du métier. Une équipe de recherche vient de le chiffrer sur des assistants d'IA qui écrivent du code. Le résultat vaut aussi comme leçon d'organisation.

Ce qui se passe quand on change de tâche

L'étude s'appelle Switch-SWE, du nom du jeu d'essais qu'elle a construit. Elle vient de l'université Jiao Tong de Shanghai et de l'université Tongji. Elle a été déposée le 1er novembre 2026 sur arXiv, l'archive publique où les chercheurs déposent leurs travaux avant relecture.

Les auteurs ont pris 200 demandes de modification réelles. Elles portent sur 19 projets Python existants, dont le code et l'historique sont publics. Une demande typique : corriger un défaut, ajouter une option, changer un comportement.

Chaque demande est confiée deux fois au même assistant. La première fois, il travaille d'un bout à l'autre sans être dérangé. La seconde fois, on lui confie entre-temps des morceaux d'autres demandes, sur le même projet. La comparaison porte donc sur des paires identiques, avec la même exigence finale et le même test de vérification.

Un point de vocabulaire. Un assistant de code est un programme auquel on donne un objectif en français et qui décide lui-même des étapes. Il lit les fichiers, modifie le code, lance les tests. On l'appelle souvent un agent, parce qu'il enchaîne ces actions sans qu'on lui dicte chacune.

Sept configurations ont été testées, chacune associant un modèle et l'outil qui le pilote. Les noms importent peu. Ce qui compte est qu'elles viennent de six éditeurs concurrents, et que les résultats se ressemblent.

Onze points de réussite perdus en moyenne

Le chiffre principal est un écart. Interrompu, l'assistant résout en moyenne 11,5 points de pourcentage de demandes en moins. L'écart va de 6 à 15 points selon la configuration.

Un exemple concret. Claude Opus 5, piloté par Claude Code, réussit 53,5 % des demandes quand on le laisse finir. Il tombe à 41,5 % quand on le change de sujet entre-temps. Un autre modèle perd davantage encore : de 46,5 % à 31,5 %, soit un tiers de sa réussite en moins.

Le détail le plus utile est ailleurs. Les auteurs ont comparé deux sortes d'interruption. La première porte sur une partie voisine du projet. La seconde porte sur une partie éloignée. L'écart moyen est de 8,1 points dans le premier cas, de 14,9 points dans le second.

Autrement dit, ce n'est pas l'interruption seule qui coûte. C'est la distance entre le sujet qu'on quitte et celui qu'on impose.

Trois précautions avant d'en tirer une conclusion. L'étude ne porte que sur du code Python, dans des projets publics, avec des tests automatiques. Elle mesure des assistants dans un cadre de laboratoire, pas votre équipe. Enfin, elle constate un lien entre la distance et la perte, sans démontrer le mécanisme.

La facture cachée

Le second résultat se lit sur la consommation. Une session entrecoupée consomme de 4,5 à 11 fois plus de jetons qu'une session propre. Un jeton est la fraction de texte que le modèle lit et facture, environ trois quarts d'un mot.

Attention à l'interprétation. Ce rapport inclut le travail des tâches intercalées, pas seulement le retour sur la tâche initiale. Il ne dit donc pas que revenir coûte onze fois le prix.

La mesure devient plus précise quand on isole la reprise. Pour finir la tâche initiale, l'assistant consomme encore de 1,4 à 3 fois le volume d'une session complète et sans interruption. Il relit l'historique des tâches croisées avant de reprendre la sienne.

L'analogie est celle du dossier papier. Un dossier resté ouvert se reprend en deux minutes. Un dossier empilé sous trois autres se reprend en relisant tout ce qui est posé dessus. L'assistant fait exactement cela, sauf qu'il paie chaque relecture au prix du modèle.

Ce que le code gardé ne rattrape pas

Le code, lui, ne se perd pas. Chaque tâche dispose de son propre espace de travail, avec les modifications déjà écrites. L'assistant retrouve les fichiers exactement dans l'état où il les a laissés.

Ce qui se perd est ailleurs. Les exigences, les décisions prises, les pistes abandonnées et la raison de chaque choix vivent dans la conversation. Au retour, cette mémoire est noyée dans les échanges des autres tâches.

Les auteurs ont relu les traces d'exécution. Deux comportements reviennent. L'assistant mélange les exigences de deux tâches, et applique à l'une une règle demandée pour l'autre. Ou bien il soumet une modification qui ne correspond plus au périmètre de la tâche initiale.

Un second travail, déposé le 4 novembre 2026 sur la même archive, va dans le même sens à une autre échelle. Il enchaîne 5 à 15 demandes successives sur une même base de code. Chaque étape part du code produit à l'étape précédente. Sur 69 chaînes de ce type, le meilleur modèle n'en résout que 18,5 %. Trente-huit chaînes ne sont résolues par aucun modèle.

L'analogie tient au chantier. Un chef d'équipe peut poser une cloison en une journée. Il ne construit pas l'étage sans savoir ce qui a été coulé dessous. Le plan se transmet, le raisonnement se perd.

Quatre décisions pour votre équipe

Une session, un sujet. Ouvrez une conversation neuve par chantier, et fermez-la quand vous changez de sujet. Le coût d'un redémarrage propre est plus faible que celui d'un mélange. C'est vrai pour un assistant, et c'est vrai pour un développeur.

Écrivez l'état avant de quitter. Trois lignes suffisent : ce qui est fait, ce qui reste, ce qui a été décidé et pourquoi. Les auteurs ont testé un module qui tient ce résumé sur l'un de ces outils ; il relève la réussite de 5,5 à 15,5 points. Le même carnet sert à un humain qui reprend le dossier.

Relisez au retour, pas à la fin. Demandez à l'assistant de reformuler la tâche et l'état du code avant de le laisser continuer. Un désaccord détecté en trente secondes coûte moins qu'une modification hors périmètre découverte en revue.

Comptez les reprises. Sur deux semaines, notez les heures passées à reprendre un travail interrompu. Ce chiffre est votre vrai coût de l'interruption, et il ne figure dans aucun abonnement.

Ce qu'il faut retenir

• Sur 200 demandes réelles, un assistant de code perd en moyenne 11,5 points de réussite quand on le change de tâche entre-temps.
• L'écart va de 6 à 15 points selon l'outil : le même modèle peut passer de 53,5 % à 41,5 % de demandes résolues.
• Plus l'interruption est éloignée du sujet en cours, plus la perte est lourde : 8,1 points pour un sujet voisin, 14,9 pour un sujet distant.
• Reprendre une tâche coûte de 1,4 à 3 fois le volume d'une session sans interruption, parce que l'historique des autres tâches est relu.
• Une session par sujet, un état écrit en trois lignes, une relecture au retour : cela se met en place cette semaine, sans nouvel outil.