Ce qui remplit la fenêtre
Tes instructions permanentes, l’historique de la conversation, chaque fichier lu, chaque sortie de commande, et les outils branchés (chaque serveur MCP charge la description de ses outils, même inutilisés).
1 · La ressource rare
Le contexte, et pourquoi tout tourne autour
Un agent ne « connaît » pas ton projet. À chaque tour, il lit une fenêtre de texte limitée : tes messages, les fichiers ouverts, les résultats de commandes, les instructions permanentes. Cette fenêtre est la ressource rare de tout le métier.
La dégradation silencieuse
Quand la fenêtre sature, la qualité chute avant tout message d’alerte : l’agent oublie une consigne du début, refait ce qu’il a déjà fait, invente un nom de fonction. Ce n’est pas « le modèle devient bête », c’est le contexte qui déborde.
Une tâche = un contexte
Repartir propre entre deux tâches sans rapport coûte moins cher que traîner 200 messages. Le contexte long n’est utile que si la suite dépend vraiment du début.
L’erreur classique du débutant : garder une seule conversation
géante pour tout le projet, en pensant que « l’IA se souviendra mieux ». C’est
l’inverse : plus la session est longue, plus les consignes du début se diluent. La
mémoire durable, ce n’est pas la conversation — c’est le fichier d’instructions du
projet (section suivante).
2 · Mémoire durable
Le fichier d’instructions du projet
Tous les agents sérieux ont le même mécanisme sous des noms différents : un fichier markdown à la racine, injecté au début de chaque session. C’est le seul endroit où une consigne survit vraiment.
| Outil | Fichier | Portée |
|---|---|---|
| Codex | AGENTS.md | Racine du projet, plus des versions par sous-dossier |
| Claude Code | CLAUDE.md | Racine du projet, global dans ~/.claude/, et par sous-dossier |
| Cursor | .cursor/rules | Règles projet, scopables par type de fichier |
✓
Ce qui mérite d’y être
Les commandes du projet (build, test, lint, dev). Les conventions qui diffèrent des défauts : gestionnaire de paquets, style de commit, structure imposée. Les pièges non évidents (« la migration X casse si on lance Y avant »). Les décisions d’archi et où les lire. Et surtout les interdits explicites.
✕
Ce qui le pollue
L’arborescence du repo, la liste des dépendances, la description d’une archi standard, un tutoriel du framework. L’agent retrouve tout ça en lisant le code — l’écrire consomme du contexte à chaque session pour rien.
!
La contrainte de taille
Au-delà d’environ 200 lignes, deux choses arrivent : ça mange du contexte à chaque tour, et les consignes sont statistiquement moins bien respectées (elles se noient). Si ça grossit, on découpe en règles modulaires chargées seulement quand c’est pertinent.
Anatomie d’une bonne règle
# ✗ Règle molle (ignorée tôt ou tard)
- Essaie d'écrire du code propre et de faire attention aux perfs
# ✓ Règle vérifiable (l'agent sait s'il l'a respectée)
- `pnpm -r typecheck` doit passer avant tout commit
- Aucune optimisation perf sans profil de mesure préalable
- `packages/core` n'importe JAMAIS une techno de queue
La différence : une règle vérifiable a un critère binaire.
"Propre" ne se vérifie pas. "typecheck passe" se vérifie.
# Formuler les interdits en absolu
- Jamais de `git push --force` sur une branche partagée
- Ne jamais modifier les migrations déjà appliquées
Les mots "jamais", "zéro", "aucun" sont mieux suivis que
"éviter de" ou "de préférence".
La règle des deux fois : une consigne que tu répètes deux fois va
dans le fichier d’instructions. Une routine que tu tapes deux fois devient une
commande réutilisable. Un interdit absolu devient une règle bloquante (permission ou
hook), pas une phrase polie dans un markdown.
3 · Le cadre
Permissions : ce que l’agent fait sans demander
Tous les agents modernes ont le même curseur : de « demande-moi tout » à « fais ce que tu veux ». Bien le régler, c’est le compromis entre la vitesse et le risque.
| Niveau | Ce que ça change | Quand l’utiliser |
|---|---|---|
| Lecture seule / plan | L’agent explore et propose, sans rien modifier. | Découverte d’un repo, refacto, toute tâche non triviale. Le mode le plus rentable. |
| Édition auto | Les modifications de fichiers passent sans confirmation, les commandes sensibles demandent encore. | Le régime de croisière une fois le plan validé. |
| Auto / agentique | L’agent enchaîne seul, avec garde-fous sur les actions destructrices. | Tâches longues et bien cadrées, sur un repo versionné. |
| Sans filet risqué | Zéro confirmation, aucune protection contre les injections de prompt. | Uniquement en environnement isolé : container, VM, CI jetable. |
Lire ne coûte rien
Quel que soit le mode, lire le code ne déclenche jamais de confirmation. Les garde-fous portent sur ce qui modifie : fichiers, commandes, réseau. Autrement dit, laisser un agent explorer librement est sans risque.
Les interdits passent au-dessus
Une règle d’interdiction (ne jamais lire .env, ne jamais forcer un
push) s’applique dans tous les modes, y compris le plus permissif. Le mode
décide de ce qui est auto-approuvé ; l’interdiction reste prioritaire.
Le vrai filet, c’est git
Les points de restauration d’un agent ne couvrent que ses propres éditions de
fichiers. Un rm, une migration de base, un push : rien de tout ça ne
s’annule. Commits fréquents et branche dédiée restent la seule vraie protection.
Injection de prompt, en une phrase : si l’agent lit un contenu
extérieur (issue GitHub, page web, dépendance, fichier reçu), ce contenu peut essayer
de lui donner des ordres. C’est exactement pour ça que le mode sans filet ne se
justifie qu’en environnement isolé, et que les interdits absolus valent mieux que la
confiance.
4 · La méthode
Explorer → Planifier → Coder → Vérifier
C’est le pattern qui sépare les gens qui obtiennent du code utilisable de ceux qui passent leur temps à corriger l’agent. Chaque étape a une raison d’être précise.
Explorer sans écrire
Demande à l’agent de lire le code concerné et de te dire ce qu’il comprend, ce qui manque, ce qui l’étonne. Interdis-lui d’écrire à ce stade. Deux bénéfices : tu vois s’il a compris le bon problème, et tu découvres les zones du code que tu avais oubliées.
Signal d’alarme : s’il décrit ton code d’une façon qui ne
correspond pas à la réalité, ne le laisse surtout pas coder. Corrige sa
compréhension d’abord.
Planifier, et corriger le plan
Fais-lui écrire un plan : les fichiers touchés, l’ordre des étapes, les cas limites, ce qui pourrait casser. Lis-le vraiment. Corriger un plan de vingt lignes prend deux minutes ; corriger un diff de quatre cents lignes prend une heure et laisse des traces.
C’est aussi le moment de dire « non, pas comme ça » : le coût d’un désaccord est minimal à cette étape.
Coder, en surveillant
Plan validé, laisse tourner en édition automatique. Reste devant : dès que ça dévie, interromps immédiatement. Plus tôt tu coupes, moins tu as de code à jeter. Laisser courir « pour voir » est le meilleur moyen de récupérer un diff illisible.
Vérifier, et exiger la preuve
« C’est fait » n’est pas une preuve. Un agent peut sincèrement croire que ça marche. La vérification doit être observable : la sortie des tests, une capture d’écran de la page, le retour d’une commande.
C’est tout l’intérêt de brancher un navigateur (voir la page MCP) : l’agent ne
dit plus « la page s’affiche correctement », il te la montre.
5 · Découpage
La taille de tâche qui marche
La cause numéro un des mauvais résultats n’est pas le modèle : c’est une tâche trop grosse ou trop floue.
✗ Trop gros, trop flou
« Refais le système d’authentification. » L’agent doit deviner le périmètre, les contraintes et le critère de réussite. Il produira quelque chose de plausible et de partiellement faux, et tu ne sauras pas par où le vérifier.
✓ Cadré, vérifiable
« Le login échoue quand l’email contient un +. Regarde
src/auth/. Écris d’abord un test qui reproduit le bug, montre-moi
qu’il échoue, puis corrige jusqu’à ce qu’il passe. »
Donne un critère de succès
Termine chaque demande par la façon dont on saura que c’est réussi : un test qui passe, une commande qui sort sans erreur, une capture. Sans critère, l’agent s’arrête quand lui pense avoir fini.
Le TDD marche très bien
Demander le test d’abord, vérifier qu’il échoue, puis demander l’implémentation : c’est le format le plus fiable avec un agent, parce que la réussite devient mécaniquement observable.
Un sujet à la fois
Mélanger un refacto, un bugfix et un changement de style dans la même tâche produit un diff impossible à relire — et impossible à annuler proprement si un seul des trois est raté.
6 · Économie
Répartir les modèles selon la tâche
Utiliser le modèle le plus cher pour tout est un gaspillage ; utiliser le moins cher pour tout donne des plans médiocres exécutés fidèlement. La bonne pratique est de séparer les deux rôles.
| Rôle | Type de modèle | Pourquoi |
|---|---|---|
| Réflexion & plan | Le plus capable disponible | Architecture, découpage, cas limites : c’est là que se joue la qualité du résultat. Une erreur de plan coûte tout le reste. |
| Exécution | Rapide et moins cher | Appliquer un plan précis est mécanique. Un modèle intermédiaire suffit et divise le coût. |
| Tâches répétitives | Le plus léger | Renommages, reformatages, extractions simples : inutile de sortir l’artillerie. |
Le corollaire : si un plan est écrit avec assez de précision pour être
exécuté par un modèle plus faible, c’est le signe que le plan est bon. Un plan qui
« nécessite un gros modèle pour être compris » est en fait un plan flou.
7 · Pièges
Les erreurs qui reviennent tout le temps
Croire le rapport final
Un agent conclut volontiers « tout fonctionne » sans avoir lancé quoi que ce soit. Ce n’est pas du mensonge, c’est une complétion probable. Le remède : exiger la sortie de commande ou la capture, systématiquement.
Le refacto non demandé
Tu demandes un fix, tu reçois un fix plus quinze fichiers reformatés. Le remède tient en une phrase dans le fichier d’instructions : ne modifier que ce qui est nécessaire à la tâche, et signaler le reste au lieu de le changer.
L’API qui n’existe pas
Une fonction plausible mais inventée, une option de librairie qui n’existe pas. Ça arrive surtout quand l’agent n’a pas lu la source. Le remède : lui faire ouvrir la doc ou le code réel plutôt que de répondre de mémoire.
Le « oui » systématique
Si tu proposes une mauvaise idée, beaucoup d’agents l’implémentent poliment. Demande explicitement le désaccord : « si tu penses que c’est une mauvaise approche, dis-le avant de coder ». Ça change réellement les réponses.
L’hypothèse non dite
Face à une consigne ambiguë, l’agent choisit une interprétation et continue sans le signaler. Exige l’inverse : expliciter les hypothèses, ou poser la question quand deux lectures sont possibles.
La session qui traîne
Enchaîner cinq sujets différents dans la même conversation dégrade tout. Repartir d’un contexte propre entre deux tâches sans rapport n’est pas une perte de temps, c’est ce qui maintient la qualité.
8 · Progression
Trois niveaux de maîtrise
Pour situer où tu en es et ce qui vaut le coup d’apprendre ensuite.
Utiliser
Tu poses des questions et tu acceptes des modifications une par une. Tu relis tout. C’est normal et sain au début — la seule chose à ajouter tout de suite, c’est travailler sur une branche git dédiée.
Cadrer
Tu écris un fichier d’instructions, tu utilises le plan mode avant les grosses tâches, tu découpes en tâches vérifiables et tu exiges des preuves. C’est là que le gain de temps devient réel.
Industrialiser
Tu automatises tes routines en commandes, tu branches les bons outils (navigateur, dépôt, logs), tu mets des garde-fous bloquants, et tu répartis les modèles entre planification et exécution.
Déléguer
Tâches longues en parallèle, sous-agents spécialisés, mémoire persistante entre sessions et indexation du code. Utile seulement une fois les niveaux 2 et 3 solides — sinon ça amplifie surtout le désordre.
L’essentiel
Ce qui distingue vraiment les bons résultats
Ce n’est ni le modèle ni l’outil : c’est la discipline. Un contexte propre, des instructions courtes et vérifiables, un plan relu avant d’exécuter, des tâches découpées avec un critère de succès, et une preuve observable à la fin. Le reste — skills, MCP, sous-agents — n’est qu’un accélérateur de cette base.