Othniel Tra Bi

Vibe coder comme un dieu commence par le contexte

Un agent qui voit trop peu, trop ou du périmé se trompe. Comment garder son contexte riche et pertinent dans Claude Code, Codex et Cursor.

Ce qu’un agent voit décide de ce qu’il produit. Gérer son contexte à la hausse comme à la baisse, dans Claude Code, Codex et Cursor.
Date de publication

5 octobre 2026

Introduction

Une session de vibe coding commence souvent très bien. On décrit la fonctionnalité, l’agent lit deux fichiers, propose un plan propre et écrit un code qui marche. Quarante minutes plus tard, la même session oublie une contrainte posée au début, réintroduit un bug déjà corrigé ou s’acharne sur une piste abandonnée. Le modèle n’a pas changé entre les deux moments. Ce qu’il voit, si.

La notion précédente de la formation Techniques d’utilisation des agents IA, la fenêtre de contexte, posait un point de départ. Un agent est limité par ce qu’il voit avant de l’être par son intelligence. Elle montrait comment bien charger une session. Ce chargement ne suffit plus dès que le travail dure, que les outils ramènent du volume et que le projet accumule des règles.

Cet article explique pourquoi la qualité d’un agent baisse quand son contexte devient trop pauvre, trop chargé ou périmé. Il rassemble ensuite les gestes qui permettent de le garder riche et pertinent au bon moment, dans Claude Code, Codex et Cursor. Il s’appuie sur des études publiques et sur la documentation officielle des outils, consultée le 5 octobre 2026. Il ne contient aucune mesure faite sur mes propres sessions.

Que voit l’agent au fil d’une session ?

Prenons une session concrète, qui servira de fil rouge. Il s’agit de brancher Stripe Checkout sur la page de tarifs d’une application Next.js qui utilise déjà Supabase. Deux contraintes comptent. Pas de mode sombre, et l’authentification ne doit pas bouger.

Au premier message, la fenêtre contient peu de choses, et toutes sont utiles. Le but, les deux contraintes, la page de tarifs et le fichier de configuration de Stripe. Au quinzième échange, elle contient en plus les journaux des tests, plusieurs diffs, un fichier de deux mille lignes lu en entier et une idée de webhook finalement abandonnée. Les deux contraintes sont toujours là, mais elles sont désormais noyées au milieu du reste.

Ce glissement est mécanique. À chaque requête, Claude Code renvoie au modèle toute la conversation, avec les instructions du projet, l’historique, les fichiers lus et les sorties des outils (Claude Code, Manage costs). Rien n’en sort tant que la fenêtre n’est pas pleine ou que l’on ne fait pas le ménage. Le Table 1 résume les trois états qui dégradent alors une session.

Table 1: Trois façons pour un contexte de dégrader une session
État du contexte Ce qui se passe dans la fenêtre Ce que l’on observe
Trop pauvre L’information utile n’y est pas L’agent comble avec une valeur plausible, par exemple une méthode d’une ancienne version de Stripe
Trop chargé L’information utile y est, noyée parmi le reste Une contrainte ignorée, des réponses plus vagues, un coût qui grimpe
Périmé De vieilles sorties et des pistes abandonnées restent en place L’agent suit une consigne dépassée ou mélange deux approches

Trop peu de contexte, l’agent comble les trous

Quand une information manque, le modèle ne s’arrête pas. Il génère la suite la plus probable à partir de ce qu’il voit et de ce qu’il a appris pendant son entraînement. Sans la version de Stripe utilisée par le projet, il peut proposer une méthode qui existait il y a deux ans. Ce n’est pas une intention, c’est le mécanisme de génération. Beaucoup d’« hallucinations » en session sont d’abord des problèmes de chargement.

Trop de contexte, le signal se dilue

On pourrait alors être tenté de tout donner. Les mesures publiques disent le contraire. En 2023, Liu et ses coauteurs ont montré que les modèles retrouvent mieux une information placée au début ou à la fin du contexte qu’au milieu, y compris des modèles conçus pour les longs contextes (Lost in the Middle). En 2025, l’équipe de recherche de Chroma a testé 18 modèles récents. Leurs performances baissent quand l’entrée s’allonge, même sur des tâches simples, et des passages proches du sujet mais inutiles aggravent la baisse (Context Rot). Anthropic décrit le contexte comme un budget d’attention limité et recommande de viser le plus petit ensemble d’informations à fort signal (Effective context engineering for AI agents).

Ces résultats viennent de bancs d’essai, pas de la session Stripe. Ils décrivent pourtant bien ce que l’on y observe. La contrainte « pas de mode sombre » est toujours dans la fenêtre au quinzième échange, mais elle se trouve au milieu, entourée de journaux de tests qui pèsent beaucoup et n’ont rien à voir avec elle.

Une fenêtre plus grande ne règle pas ce point. La documentation d’Anthropic rappelle que plus de contexte n’est pas automatiquement mieux, parce que la précision et le rappel baissent quand le nombre de tokens augmente (Context windows). La baisse mesurée par Chroma apparaît bien avant la limite des fenêtres.

Un contexte périmé, l’agent suit la mauvaise consigne

Le troisième état est plus discret. Une sortie de test d’il y a vingt minutes décrit un bug déjà corrigé. Une piste abandonnée reste visible avec tout son code. Deux consignes se contredisent parce que l’on a changé d’avis en route. Le modèle voit tout cela au même niveau que l’état actuel du projet, et rien ne lui indique ce qui est dépassé.

Gérer son contexte Décider à chaque étape ce qui entre dans la fenêtre, ce qui y reste et ce qui en sort, pour que le modèle travaille sur le plus petit ensemble d’informations utiles à la tâche du moment.

La gestion se fait donc dans les deux sens. À la hausse, pour apporter ce qui manque au moment où la tâche en a besoin. À la baisse, pour retirer ce qui ne sert plus.

Comment charger ce qui manque, au bon moment ?

Charger plus ne veut pas dire charger tout. Chaque geste de cette partie apporte une information précise à l’étape qui en a besoin, et pas avant.

Des consignes permanentes courtes

Les fichiers d’instructions sont lus au début de chaque session. CLAUDE.md pour Claude Code, AGENTS.md pour Codex, les règles de .cursor/rules pour Cursor, qui lit aussi AGENTS.md. Chaque ligne y occupe donc de la place à chaque tour. La documentation de Claude Code recommande de rester sous 200 lignes par fichier, parce qu’un fichier plus long consomme plus de contexte et que ses consignes sont moins bien suivies (Claude Code, memory). Codex assemble les AGENTS.md du dossier racine jusqu’au dossier courant et s’arrête par défaut à 32 Kio (Codex, AGENTS.md).

Ces fichiers sont la place des contraintes qui doivent rester actives pendant toute la session. Dans la session Stripe, trois lignes suffisent.

## Contraintes du projet
- Stack en place, Next.js et Supabase. Ne pas toucher à l'authentification.
- Pas de mode sombre.
- Paiement par Stripe Checkout, uniquement dans app/pricing et lib/stripe.ts.

Une règle qui ne concerne qu’une partie du code n’a pas sa place dans ce fichier. Claude Code permet de la ranger dans .claude/rules/ avec les chemins concernés, pour qu’elle ne se charge que lorsque l’agent travaille sur ces fichiers (Claude Code, memory). Cursor propose la même idée avec des règles attachées à des motifs de fichiers (Cursor, Rules).

Nommer les fichiers plutôt que demander de regarder le projet

Une demande vague comme « améliore ce projet » déclenche une exploration large, qui remplit la fenêtre de fichiers inutiles (Claude Code, Manage costs). Désigner les fichiers avec @, dans les trois outils, fait entrer exactement ce que la tâche demande. Quand on ne sait pas encore quels fichiers comptent, mieux vaut demander une lecture ciblée avant toute modification.

Des compétences et des outils chargés à la demande

Les skills de Claude Code et de Codex suivent le même principe. Seuls leur nom et leur description sont présents en permanence, leur contenu se charge quand la tâche en a besoin (Claude Code, best practices, Codex, skills). Une procédure utile une fois par semaine a donc plus sa place dans une skill que dans CLAUDE.md.

Les outils externes connectés par MCP coûtent aussi de la place, parce que leurs définitions entrent dans la fenêtre. Anthropic cite le cas de 58 outils qui consomment environ 55 000 tokens avant même le premier message, et une recherche d’outils à la demande qui réduit cette consommation de 85 % (Advanced tool use). Claude Code charge désormais ces définitions à la demande par défaut. Couper les serveurs inutiles avec /mcp reste le geste le plus simple (Claude Code, Manage costs).

Un plan écrit dans un fichier

Un plan qui n’existe que dans la conversation disparaît avec elle. Écrit dans un fichier du projet, il survit à un nettoyage ou à une nouvelle session, et il se recharge en une ligne. La documentation de Claude Code conseille, pour une fonctionnalité importante, d’écrire d’abord une spécification puis de l’exécuter dans une session neuve, dont le contexte ne contient que l’implémentation (Claude Code, best practices).

Comment retirer ce qui ne sert plus ?

Repartir à zéro entre deux tâches

Le geste le plus efficace est aussi le moins coûteux. Une tâche sans rapport avec la précédente mérite une fenêtre vide. /clear dans Claude Code, /new dans Codex, une nouvelle conversation dans Cursor. Claude Code nomme le piège inverse la session fourre-tout, où des demandes sans lien s’accumulent dans le même contexte (Claude Code, best practices). Codex recommande de son côté une conversation par unité de travail cohérente (Codex, best practices).

Résumer quand la tâche continue

Quand la tâche continue mais que la fenêtre s’alourdit, la compaction remplace l’historique par un résumé. /compact dans Claude Code et dans Codex, un résumé automatique dans Cursor quand la fenêtre est presque pleine (Cursor, prompting). Claude Code accepte des consignes pour orienter ce résumé, par exemple /compact garde les contraintes du paiement et l'état des tests.

Piège à éviter Donner une contrainte seulement dans la conversation. Après une compaction, Claude Code relit depuis le disque le CLAUDE.md de la racine et le plan, mais le reste de la conversation devient un résumé, qui peut perdre une consigne donnée une seule fois (Claude Code, context window). Une contrainte qui doit tenir toute la session va dans le fichier d’instructions.

Isoler les recherches larges

Trouver tous les endroits où un composant est utilisé peut demander de lire vingt fichiers. Un sous-agent fait cette recherche dans sa propre fenêtre et ne renvoie que sa conclusion dans la conversation principale (Claude Code, subagents). Codex propose aussi des sous-agents, qu’il faut le plus souvent demander explicitement (Codex, subagents).

Filtrer les sorties trop longues

Une suite de tests ou un journal peut produire des milliers de lignes, dont seules les erreurs comptent. La documentation de Claude Code montre un hook qui ne garde que les lignes d’erreur. Il fait passer la sortie de dizaines de milliers de tokens à quelques centaines (Claude Code, Manage costs).

S’arrêter après deux corrections ratées

Quand l’agent échoue deux fois sur le même problème, la fenêtre contient surtout ses tentatives ratées. Le corriger une troisième fois ajoute encore du bruit. La documentation de Claude Code conseille alors de repartir d’une session propre, avec une meilleure demande qui intègre ce que l’on a appris (Claude Code, best practices). C’est aussi la règle que j’applique dans mes sessions.

Regarder avant de couper

On ne coupe bien que ce que l’on voit. Dans Claude Code, /context affiche ce qui occupe la fenêtre, fichiers d’instructions et outils compris (Claude Code, best practices). Dans Codex, /status donne les tokens utilisés (Codex, commandes), et Cursor affiche le remplissage de la fenêtre (Cursor, prompting).

Astuce de pro Avant chaque message important, trois questions suffisent. Qu’est-ce qui manque à l’agent pour cette étape ? Qu’est-ce qui ne lui sert plus ? Quelle contrainte doit rester active jusqu’au bout ?

Les mêmes gestes dans trois outils

Le Table 2 rassemble les commandes équivalentes. Les noms changent d’un outil à l’autre, les gestes restent les mêmes.

Table 2: Gestes de gestion du contexte et leurs commandes, d’après la documentation de chaque outil au 5 octobre 2026
Geste Claude Code Codex Cursor
Consignes permanentes CLAUDE.md, .claude/rules/ AGENTS.md .cursor/rules, AGENTS.md
Désigner un fichier @fichier @fichier @fichier
Voir l’occupation /context /status indicateur de remplissage
Repartir à zéro /clear /new nouvelle conversation
Résumer /compact avec consignes /compact résumé automatique
Isoler une recherche sous-agents sous-agents, sur demande non couvert ici
Charger à la demande skills, recherche d’outils MCP skills règles appliquées selon le besoin

Ce que ces gestes ne garantissent pas

Ces gestes améliorent les conditions de travail de l’agent. Ils ne garantissent pas le résultat.

  • Je n’ai pas mesuré leur effet sur mes propres sessions. Les chiffres cités viennent des études et des documentations, avec leurs propres protocoles.
  • Un contexte propre ne corrige pas un objectif flou. Si la demande ne dit pas comment savoir que le travail est fini, l’agent s’arrêtera au mauvais endroit, même avec la fenêtre la plus nette.
  • Un résumé perd toujours de l’information. La compaction prolonge une session, elle ne remplace ni un fichier d’instructions ni un plan écrit.
  • Les commandes évoluent vite. Celles de cet article ont été vérifiées le 5 octobre 2026, et l’aide de chaque outil reste la référence.

Et ensuite ?

Garder un contexte riche et pertinent permet de tenir une longue session sans que l’agent perde le fil. Il reste à formuler précisément ce que l’on attend de lui, et à lui donner un moyen de vérifier que c’est fait. C’est la suite logique de cette formation.

Sources