Imaginez le collaborateur suivant. Il a tout lu, il connaît tous les langages, il travaille à une vitesse déraisonnable et il ne se vexe jamais quand on lui demande de refaire. Un seul détail : chaque matin, il prend son poste sans aucun souvenir de la veille. Sa seule mémoire est un carnet de notes, d'une taille fixe, qu'il remplit au fil de la journée et qui repart vierge le lendemain. Ce collaborateur, c'est Claude.
Tout ce chapitre tient dans cette image, et je vous préviens : une fois qu'on l'a en tête, on ne peut plus utiliser une IA comme avant. Chaque bonne pratique du guide, de la documentation aux tests en passant par le choix du modèle, est une réponse logique à cette seule contrainte.
Une machine à probabilités
Avant d'ouvrir le carnet, il faut dire ce qu'il y a dans la tête. Claude n'est pas une base de données qui stocke des vérités et les ressort à la demande : c'est un modèle de langage, autrement dit une machine à probabilités. À chaque instant, il calcule la suite la plus probable de ce qu'il a sous les yeux, compte tenu de tout ce qu'il a appris. Quand il écrit du code, il ne « sait » pas au sens où un livre sait : il produit la continuation la plus vraisemblable du contexte qu'on lui a donné.
Relisez le chapitre 1 avec cette clé, et le mystère se dissout. Le code plausible, celui qui compile, qui brille à la démo et qui se trompe dans les recoins, n'est pas un accident de parcours : c'est la nature même de la machine. Plausible est littéralement ce qu'elle optimise. Demandez « fais-moi un site de réservation » sans une précision de plus, et la réponse la plus probable est le site de réservation générique, la moyenne statistique de tout ce qui existe : ni votre métier, ni vos règles, ni vos cas limites.
D'où le renversement qui fonde toute la méthode de ce guide : puisque Claude produit le plus probable compte tenu du contexte, guider Claude, c'est déplacer des probabilités. Chaque information que vous ajoutez resserre l'espace des réponses possibles autour de votre projet.
Le brief du chapitre 3 rend vos conventions plus probables que celles de la moyenne d'internet. Le plan validé du chapitre 5 rend la bonne architecture plus probable qu'une architecture vraisemblable. Le test rouge du chapitre 6 rend la vraie correction plus probable qu'une rustine.
Vous ne donnez pas des ordres à une machine déterministe : vous orientez une machine probabiliste.
Toute la méthodologie qui suit n'est que cela, dit avec d'autres mots : l'art de rendre la bonne réponse plus probable que la réponse moyenne.
Lire, réfléchir, agir, observer
Passons au geste, car c'est lui qui distingue Claude Code d'un simple chat. Claude Code, créé chez Anthropic par Boris Cherny, est un agent qui vit dans votre terminal (il existe aussi en application de bureau, sur le web et le mobile, et en extension dans votre éditeur, mais le principe reste identique partout). Agent, le mot est précis : il ne se contente pas de répondre, il travaille en boucle.
- LireIl lit ce dont il a besoin.
- Réfléchir
- AgirÀ travers des outils : lire et écrire des fichiers, lancer des commandes dans le terminal, chercher dans le code.
- ObserverIl observe le résultat de son action, puis recommence jusqu'à ce que l'objectif soit atteint.
Concrètement, quand vous lui demandez de corriger un bug, il ne devine pas une réponse : il ouvre les fichiers concernés, forme une hypothèse, modifie le code, relance les tests, constate qu'un cas échoue encore, ajuste, relance. C'est ce droit de constater qui change tout. Un chat vous propose du code et vous laisse vérifier ; un agent vérifie lui-même, à condition qu'on lui donne un moyen de le faire (c'est précisément l'objet du chapitre 6).
La boucle s'arrête quand le travail est fait, ou quand vous décidez qu'elle part dans la mauvaise direction : la touche Échap interrompt Claude à tout moment, et c'est un réflexe à cultiver dès maintenant (le chapitre 7 en fait une discipline).
Mais voici le point capital, celui qui nous ramène au carnet : chaque tour de boucle écrit dedans. Chaque fichier lu, chaque sortie de commande, chaque échange avec vous s'ajoute aux notes. Le carnet ne se vide jamais tout seul en cours de journée. Il se remplit.
Un carnet de taille fixe
Ce carnet porte un nom technique : la fenêtre de contexte. C'est la mémoire de travail de Claude, et il faut résister à l'intuition qui la confond avec un disque dur. Un disque dur stocke tout, pour toujours, et on y pioche. La fenêtre de contexte, elle, contient uniquement la session en cours : votre conversation, les fichiers que Claude a lus, les sorties des outils qu'il a lancés. Elle est finie. Et elle ne s'étend pas quand on approche du bord.
Deux conséquences découlent de cette taille fixe, et elles expliquent à peu près tous les comportements qui déroutent les débutants. La première : ce qui n'est pas dans le carnet n'existe pas. La décision d'architecture prise hier dans une autre session, le fichier que Claude n'a pas ouvert, la convention de nommage évidente pour toute votre équipe : rien de tout cela n'existe pour lui tant que personne ne l'a écrit dans le contexte.
La seconde : quand le carnet approche de la saturation, la qualité se dégrade. Les premières notes se compressent, les décisions du début de session deviennent floues, et Claude se met à réinventer ce qui avait été tranché une heure plus tôt. Il ne devient pas moins intelligent : il perd ses notes.
Prenez une seconde pour relire le chapitre 1 avec ces lunettes. Les quatre symptômes du projet sans méthode, les bugs fantômes, le fichier unique, la structure illisible, la facture de tokens : quatre problèmes en apparence, quatre visages d'une seule cause en réalité. Un agent au carnet fini, à qui personne n'a écrit ce qu'il fallait retenir, et qui relit tout pour retoucher n'importe quoi. Ce guide n'est pas une liste de douze remèdes indépendants : c'est une seule contrainte, prise sous douze angles.
Le lendemain matin, c'est plus radical encore : nouvelle session, carnet vierge. Le collaborateur brillant revient à son poste sans le moindre souvenir de la veille. C'est pour cela qu'on lui prépare un dossier de brief qu'il relit chaque matin (le fichier CLAUDE.md, tout le chapitre 3 y est consacré), et c'est pour cela que les équipes qui documentent tirent dix fois plus de ces outils que celles qui improvisent.
Regarder le carnet se remplir
Bonne nouvelle : le carnet n'est pas une boîte noire. La commande /context vous montre à tout moment ce qu'il contient et ce qu'il reste de place.
❯ /context Contexte utilisé : 62 % ██████████░░░░░░ conversation 31 % █████░░░░░░░░░░░ fichiers lus 22 % ███░░░░░░░░░░░░░ sorties d'outils 9 % La photographie du carnet à l'instant T. Tout ce que Claude sait de votre session est là, et rien d'autre.
Prenez l'habitude de la lancer en cours de session, comme on jette un œil à la jauge d'essence. Et voici ce qui se passe quand on roule sans regarder : la session s'allonge, on colle des fichiers entiers, on enchaîne les corrections, et un beau moment la conversation ressemble à ceci.
❯ Reprends la validation du formulaire comme convenu. · Claude travaille... J'ajoute la validation côté client dans SignupForm... ❯ Non. On avait dit côté serveur, il y a une heure. · Claude relit la conversation... Vous avez raison, je ne retrouve plus cette décision. La décision a été poussée hors du carnet. Claude ne ment pas : elle a réellement disparu de sa mémoire.
Je vois cette scène chez presque toutes les équipes que je rencontre, et je l'ai vécue sur mes propres projets avant d'en faire une règle d'hygiène. Le symptôme est toujours le même : on croit que Claude « fatigue » ou « fait exprès ». Non. Son carnet déborde, voilà tout.
Et vous avez des outils pour agir : /clear vide entièrement le contexte pour repartir à neuf, /compact le résume pour garder l'essentiel en libérant de la place, /rewind vous ramène à un point de sauvegarde antérieur de la session. Le chapitre 7 détaille quand choisir lequel ; retenez pour l'instant qu'ils existent, et qu'un /clear au bon moment vaut mieux que dix corrections dans un contexte saturé.
Tout le guide découle de ce carnet
Reprenez n'importe quelle pratique professionnelle du développement assisté par IA : c'est une réponse au carnet.
- Documenter · ch. 3Puisque Claude oublie tout entre les sessions, on écrit une mémoire de projet qu'il recharge chaque matin.
- Découper · ch. 5Puisque le carnet est petit, on donne des tâches qui y tiennent confortablement, au lieu d'une épopée qui le fait déborder.
- Faire vérifier · ch. 6Puisque la boucle agentique sait observer, on lui fournit des tests à exécuter plutôt que notre confiance.
- Nettoyer · ch. 7Puisque le contexte se dégrade en vieillissant, on le vide ou on le résume avant qu'il ne pourrisse.
- Déléguer · ch. 9Puisque lire quarante fichiers remplirait le carnet principal, on envoie des subagents explorer avec leur propre carnet, et on ne récupère que la conclusion.
- Payer juste · ch. 10Puisque chaque note a un coût, on apprend à le mesurer et à le réduire.
Six chapitres, une seule cause. C'est ce que j'appelle un bon modèle mental : il ne vous donne pas des règles à mémoriser, il vous permet de les retrouver.
Les tokens, ou le prix de chaque note
Reste à parler du prix du carnet, parce qu'il éclaire la dernière pièce du puzzle. Le texte que Claude lit et écrit se mesure en tokens : des unités de texte, des morceaux de mots, la monnaie d'échange de tous les modèles de langage. Et le point que beaucoup découvrent sur leur première facture : les tokens sont comptés dans les deux sens. Ce que Claude produit, mais aussi tout ce qu'on lui fait lire. Un contexte, ça se paie.
D'où une conséquence arithmétique qui devrait vous faire voir vos sessions autrement : un contexte sale coûte double. En euros d'abord, puisque chaque tour de boucle relit la conversation accumulée ; plus elle traîne de fichiers collés inutiles et de faux départs, plus chaque nouvelle réponse embarque ce poids mort. En qualité ensuite, puisque ce même poids mort noie les informations utiles et dégrade les réponses. Vous payez plus cher des réponses moins bonnes : c'est la double peine du carnet mal tenu.
Une nuance pour finir, qui a son importance : rester dans le même fil de conversation n'est pas un gaspillage en soi. Le cache de prompt rend la relecture du même début de conversation nettement moins chère que sa première lecture. Un long fil sain et cohérent est donc économe ; c'est le fil sale, gonflé de scories, qui coûte. La facture détaillée, les modèles et les réflexes qui la divisent vous attendent au chapitre 10.
Questions fréquentes sur la fenêtre de contexte
Comment Claude produit-il ses réponses ?
Claude est un modèle de langage : une machine à probabilités qui calcule, à chaque instant, la suite la plus vraisemblable de ce qu'elle a sous les yeux, compte tenu de son entraînement. Il ne consulte pas une base de vérités : il produit la continuation la plus probable de son contexte. C'est pourquoi une demande vague obtient une réponse générique, la moyenne statistique de ce qui existe, et pourquoi tout l'art de la méthode consiste à enrichir le contexte (brief, plan, tests) pour rendre la bonne réponse plus probable que la réponse moyenne.
Qu'est-ce qu'un token ?
Un token est l'unité de texte que manipulent les modèles d'IA : un morceau de mot, un mot court ou un signe de ponctuation. Tout ce que Claude lit et tout ce qu'il écrit se compte en tokens, et les deux sens sont facturés : l'entrée (votre conversation, les fichiers lus) comme la sortie (le code et les réponses produits). C'est pourquoi un contexte encombré coûte de l'argent même quand Claude répond peu : il relit tout le fil à chaque tour.
Pourquoi Claude oublie-t-il ce que je lui ai dit ?
Parce que sa mémoire de travail, la fenêtre de contexte, est finie. Quand une session s'allonge, les informations du début se compressent puis sortent du contexte : la décision prise il y a une heure peut littéralement disparaître. Et d'une session à l'autre, tout est oublié par construction. Les remèdes existent : surveiller la jauge avec /context, repartir proprement avec /clear ou /compact, et surtout écrire les décisions durables dans un fichier CLAUDE.md rechargé à chaque session.
Qu'est-ce que la fenêtre de contexte ?
La fenêtre de contexte est la mémoire de travail d'un modèle d'IA : elle contient tout ce que le modèle « voit » à un instant donné, soit la conversation en cours, les fichiers lus et les sorties d'outils. Sa taille est fixe. Ce qui n'y figure pas n'existe pas pour le modèle, et quand elle approche de la saturation, la qualité des réponses se dégrade. Ce n'est pas un disque dur : rien n'y est stocké durablement entre deux sessions.
La suiteLe collaborateur brillant oublie tout chaque matin ? Alors le premier geste professionnel s'impose de lui-même : lui préparer le dossier de brief qu'il relira à chaque prise de poste. Au chapitre 3, on écrit ce dossier ensemble : CLAUDE.md, les fichiers de cadrage, et la technique de l'interview inversée où c'est Claude qui vous pose les questions.
David Silvera
Développeur mobile & web freelance · 15 ans · Android, iOS, React Native, Next.js
Ce guide est tiré de ma pratique quotidienne : ce site lui-même est développé avec Claude, selon la méthode qu'il enseigne. J'accompagne aussi les équipes qui veulent monter en compétence : audit de pratique, formation, mise en place d'outillage.
Discutons de votre équipe