Pourquoi ce sujet compte maintenant
On entend de plus en plus de récits d’agents qui codent des heures d’affilée. Selon Nate B Jones, trois ingénieurs d’OpenAI auraient livré un produit interne représentant plus d’un million de lignes de code en environ un dixième du temps habituel, via environ 1 500 pull requests, sans taper une seule ligne à la main. Les runs Codex sous-jacents dépassaient six heures d’affilée, parfois bien plus.
Le vrai sujet n’est pas le chiffre spectaculaire. C’est le problème que ces équipes ont dû résoudre pour y arriver : comment garder un agent sur la bonne voie quand le prompt initial devient obsolète au bout de deux heures ?
Aujourd’hui, les agents codent assez longtemps pour que la gestion du contexte devienne plus importante que la taille de la fenêtre de contexte. C’est ce que Nate B Jones appelle le progressive context shaping : la capacité à faire évoluer ce que l’agent considère comme la version courante de sa mission. On en reparle constamment sur Vibecodage : si l’agent n’a pas de mémoire structurée, il reste un chatbot un peu plus rapide (notre article sur la mémoire des agents).
Ce qu’il faut comprendre en premier
La première idée à retenir est contre-intuitive : un long manuel d’instructions ne protège pas l’agent, il l’asphyxie. Dans le projet OpenAI cité, l’équipe a remplacé un document de consignes géant par une carte courte qui pointait vers des plans d’exécution actifs, des journaux de décisions, des documents de design et une carte d’architecture. Objectif : donner à l’agent un moyen fiable de trouver l’information courante, pas de tout emporter en mémoire.
Du côté d’Anthropic, la pratique est similaire. Claude Code utilise un fichier de progrès (progress file) comme mémoire portable entre les sessions. Ce fichier note l’état actuel, le travail terminé, les limitations connues et les approches qui ont échoué avec la raison. Une nouvelle session peut le lire, reprendre la tâche suivante et éviter de retomber dans les mêmes impasses.
Les deux approches reposent sur le même constat : l’IA passe de la production de réponses au portage de travail qui évolue sur des heures, voire des jours. Le contexte ne peut plus rester un paquet figé envoyé au démarrage. Il doit changer au fur et à mesure que le travail vous apprend ce qu’est vraiment le job.
Analyse détaillée
Le principe du context shaping progressif repose sur quatre contextes distincts :
-
Instructions stables. Ce sont les règles de travail : conventions de code, commandes de test, actions nécessitant une validation humaine. Pour Codex, cela vit dans le fichier AGENTS.md. Pour Claude Code, c’est le fichier CLAUDE.md. Ces fichiers sont lus au début de chaque session et restent relativement constants.
-
État courant du projet. C’est le cœur de la méthode. Quel est l’objectif actif ? Quelles décisions sont en vigueur ? Que reste-t-il à faire ? Quand l’agent doit-il s’arrêter ? Ce matériau change souvent et mérite son propre fichier, ticket ou enregistrement structuré. Il ne doit pas être noyé dans l’historique de conversation.
-
La carte. Où vivent les ressources ? Documentation, fichiers de recherche, transcripts, brouillons précédents. L’agent n’a pas besoin de tout avoir sous les yeux, mais il lui faut un moyen fiable de localiser ce qui compte pour la prochaine décision.
-
L’historique. Ce qui s’est passé, ce qui a changé, pourquoi une décision a été prise. C’est utile, mais il ne doit pas se faire passer pour des instructions actives. Le changelog ou le journal de décisions jouent ce rôle.
La documentation officielle de Codex confirme que les fichiers AGENTS.md sont découverts et concaténés à chaque run, avec une règle de précédence simple : les fichiers les plus proches du répertoire de travail l’emportent sur ceux plus haut dans l’arbre. Cela permet de garder des instructions globales stables tout en autorisant des overrides ciblés. Côté Anthropic, l’article sur les dynamic workflows explique que les workflows peuvent reprendre là où ils s’étaient arrêtés après une interruption, exactement parce que l’état est maintenu en dehors de la fenêtre de conversation.
La leçon pratique est claire : le prompt devient un mandat initial, pas un autoportrait complet du projet. Dès que le travail produit de nouvelles informations, on met à jour l’état courant. Cela transforme l’interaction d’une commande en une direction de travail.
Erreurs fréquentes et limites
La plus grande erreur consiste à croire qu’un context window plus grand résout le problème. Une fenêtre immense ne fait qu’empirer le bruit : l’agent a davantage de matériel obsolète à trier. Ce n’est pas la quantité de tokens qui compte, c’est la priorité accordée à l’état actuel.
Une autre erreur courante : vouloir tout conserver dans le prompt. Les équipes qui collent l’intégralité de l’historique, des logs et des brouillons finissent par noyer l’objectif. L’agent passe son temps à réorganiser des informations au lieu d’avancer sereinement.
Il faut aussi rester lucide sur les chiffres du projet OpenAI. Ils viennent d’une vidéo YouTube et ne sont pas vérifiables indépendamment. Ils illustrent une tendance réelle — les runs longs deviennent opérationnels — mais ne constituent pas une garantie que n’importe quelle équipe peut répliquer ce résultat. Enfin, cette méthode demande une discipline documentaire. Sans quelqu’un qui vérifie que l’état courant reste fidèle à la réalité, l’agent dérive tout aussi sûrement que sans contexte.
Ce que ça change pour les devs
Pour passer du spectacle à l’usage régulier, voici ce que vous pouvez mettre en place cette semaine :
- Créez un fichier
CURRENT.md(ou équivalent) dans vos repos agents. Il contient l’objectif actif, les décisions en vigueur, les tâches restantes et les conditions d’arrêt. L’agent le lit au démarrage et le réécrit après chaque étape significative. - Gardez
AGENTS.md/CLAUDE.mdpour les règles stables. Ne mélangez pas les consignes pérennes avec l’état du jour. Cela évite de transformer votre fichier d’instructions en cimetière de règles obsolètes. - Demandez à l’agent un checkpoint pédagogique avant le résultat final. Une carte de recherche, un premier MVP ou un diagnostic intermédiaire vous apprendront vite si votre brief tient la route. Pour structurer ce type de mandat, reprenez les templates de notre playbook de cadrage des agents.
- Séparez historique et instructions actives. Le changelog raconte comment on en est arrivé là ; l’état courant dit ce qu’il faut faire maintenant. Ne demandez pas à l’agent de faire les deux dans la même fenêtre.
- Fixez un budget et un critère d’arrêt. Un run long sans condition de sortie finit par générer du mouvement pour du mouvement. C’est exactement le risque décrit dans notre article sur les agents sans contrat de comportement.
- Faites une revue humaine de l’état courant avant chaque reprise. L’agent ne sait pas qu’une décision a changé si vous ne l’écrivez pas. La mise à jour manuelle reste un point de contrôle essentiel.
Verdict et prochaine étape
La compétence stratégique de 2026 ne se limite pas à choisir le bon modèle ou à écrire un prompt soigné. C’est la capacité à piloter le contexte sur la durée. Un agent bien informé sur l’état courant produit du travail cohérent ; un agent qui traîne un prompt figé produit des tonnes de code dans la mauvaise direction.
Commencez petit : prenez un projet d’agent de plus d’une heure, ajoutez un fichier d’état courant, et vérifiez après chaque run qu’il reflète bien ce que vous avez appris. Vous gagnerez moins en buzz, mais beaucoup plus en prédictibilité.
Envie de recevoir le template CURRENT.md que nous utilisons et les checklists de reprise de run ? Abonnez-vous à la newsletter : on enverra la version opérationnelle avec des exemples bons et mauvais.
Image d’illustration : “Programming code.jpg” par Martin Vorel, sous licence CC BY-SA 4.0, via Wikimedia Commons.
Sources: https://www.youtube.com/watch?v=HZLPhPbw3fM, https://learn.chatgpt.com/codex/agent-configuration/agents-md, https://docs.anthropic.com/en/docs/agents-and-tools/claude-code/overview, https://claude.com/blog/a-harness-for-every-task-dynamic-workflows-in-claude-code
