Le mythe de la session longue : 10 minutes suffisent

267 sessions de coding agent tracées depuis décembre 2025 sur un projet Symfony/TypeScript. La distribution des durées :

< 10 min     165 sessions (62%)
10 - 60 min   61 sessions (23%)
1 - 4 h       21 sessions  (8%)
> 4 h          20 sessions  (7%)

La majorité du travail agentique se fait en micro-sessions. Pas des marathons de 2 heures avec l’agent — des interactions courtes, focalisées, puis retour au code.

Ce qui se passe dans une session de 10 minutes

Une question précise, une réponse, éventuellement un ajustement. Exemples typiques :

“Pourquoi ce test PHPUnit échoue avec un 500 sur cet endpoint ?” — l’agent lit le test, le controller, identifie le mock manquant. 3 minutes.

“Génère les fixtures pour cette entité avec les relations.” — l’agent produit le fichier, on vérifie, on ajuste un champ. 5 minutes.

“Refactorise ce switch en strategy pattern en suivant les conventions du projet.” — l’agent lit le code existant, les conventions dans AGENTS.md, produit le refactoring. 8 minutes.

Ce sont des livraisons complètes. Pas des sessions inachevées.

Pourquoi les sessions longues sont un anti-pattern

Au-delà de 30-40 échanges, le context rot dégrade la qualité des réponses. Les premières instructions perdent leur influence. L’agent commence à contredire ses propres décisions prises plus tôt dans la session.

Les 20 sessions de plus de 4 heures dans les données sont presque toutes des sessions “fourre-tout” — enchaînement de tâches non liées, debugging qui dérive, exploration sans objectif clair. Le ratio outcome/temps sur ces sessions est significativement plus bas.

Le context rot n’est pas la seule cause. Sur les modèles ouverts, un second plafond s’ajoute : j’ai rejoué la même tâche triviale trois fois sur les modèles opencode Go, environ un tour sur trois sort faux. Et le verdict des praticiens qui les ont tous poussés, c’est qu’ils s’effondrent au-delà de 5-10 minutes de travail. Dégradation du contexte d’un côté, plafond de capacité de l’autre : deux mécanismes distincts qui atterrissent sur la même consigne.

Le réflexe à construire

La bonne question n’est pas “comment faire durer la session plus longtemps” mais “est-ce que je peux découper ça en une session de 10 minutes ?”

Si la réponse est non — si la tâche nécessite vraiment un contexte large et du raisonnement continu — alors une session longue est justifiée. C’est 15% des cas. Pour les 85% restants, la micro-session est plus efficace, plus prévisible, et moins sujette au context rot.

Le context window n’est pas un réservoir à remplir. C’est une ressource à utiliser avec parcimonie.

Ces chiffres, je les montre systématiquement à un dev qui découvre les agents — ça désamorce l’idée reçue qu’une bonne session doit être longue, avant même qu’elle s’installe.

→ Guide : Gérer le contexte dans un workflow multi-agents → Guide : Principes du workflow agentique