Gestion du contexte : ne le laissez pas devenir « amnésique » ni épuiser vos tokens
📚 Navigation dans la série : L'article précédent 18 · Guide d'utilisation de CLAUDE.md vous a appris à inscrire les normes du projet dans ce « manuel d'intégration ». Cet article s'élève d'un niveau — ce manuel, avec vos conversations et les fichiers lus, est entassé sur un plan de travail appelé « fenêtre de contexte ». Comment bien gérer ce plan de travail et éviter de le surcharger, c'est le sujet d'aujourd'hui.
Lorsqu'on débute avec Claude Code, il est très facile de faire une chose plutôt stupide.
En reprenant un projet de taille moyenne qu'on ne connaît pas bien, on se dit « je vais lui faire lire tout le dépôt avant de commencer, comme ça il comprendra bien l'ensemble », alors on lui lance : « Lis tous les fichiers de ce projet, puis explique-moi l'architecture. »
Résultat ? Il lit effectivement les fichiers un par un, le terminal défile à toute vitesse, et après avoir lu une vingtaine de fichiers, il ralentit considérablement et devient apathique. Quand vous commencez à lui demander de corriger un bug de connexion, il vous demande « dans quel fichier se trouve le module auth dont tu parles ? » — un fichier qu'il a lu dix minutes plus tôt. Le travail n'est pas fini, il est déjà devenu « amnésique » et a brûlé un tas de tokens.
Une fois qu'on a compris, on réalise : la fenêtre de contexte n'est pas "plus c'est plein, mieux c'est". Lorsqu'elle est pleine, il devient paradoxalement plus bête. Aujourd'hui, nous allons expliquer en détail ce « plan de travail » — ce que c'est, ce qui se passe quand il est plein, comment le nettoyer avec /compact et /clear, comment surveiller l'utilisation en temps réel, et comment économiser des tokens à la source.
Après avoir lu cet article, vous saurez :
- Une analogie qui vous permettra de comprendre parfaitement la « fenêtre de contexte », et ce qui se passe vraiment quand elle est pleine.
- Quand utiliser respectivement
/compact(compresser),/clear(effacer) et démarrer directement une nouvelle session, expliqué dans un tableau clair. - Utiliser
/contextet/usagepour surveiller en temps réel des actions spécifiques + les sorties attendues. - Cinq habitudes pour économiser des tokens au quotidien, toutes tirées de pièges réels.
- Comprendre ce que fait vraiment la « compression automatique » (auto-compact) en coulisses, pour ne plus être surpris par ses interruptions soudaines.
01 Fenêtre de contexte : quelle est la taille du « plan de travail » de Claude
Posons d'abord ce concept fondamental.
La fenêtre de contexte (context window) — c'est la capacité totale de tout ce que Claude peut « voir » simultanément au cours d'une session, mesurée en tokens (la plus petite unité de facturation pour le traitement de texte par le modèle).
Elle ne contient pas seulement ce que vous tapez, mais tout un tas de choses. Le document officiel context-window.md détaille très clairement cela, je vous le traduis en langage courant :
| Ce qui est mis sur le plan de travail | Quand cela arrive | Combien cela occupe |
|---|---|---|
| Prompt système (règles de comportement de Claude) | À chaque démarrage, vous ne le voyez pas | Une portion fixe |
| Votre CLAUDE.md (Global + Projet) | Chargé entièrement au démarrage | Dépend de la taille du fichier |
| Mémoire automatique (auto memory) | Chargée au démarrage (avec une limite) | Moyen |
| Chaque phrase que vous tapez | S'ajoute à chaque phrase envoyée | Généralement très petit |
| Chaque fichier qu'il a lu | S'ajoute à chaque lecture | La plus grosse part, brûle le plus vite |
| Sorties de commandes, résultats d'outils | S'ajoute après chaque appel d'outil | Très rapide pour les logs / gros fichiers |
Vous voyez ? Vous pensiez que la conversation consistait principalement en « ce que vous dites », mais la plus grande part vient des fichiers qu'il lit et des sorties de commandes. L'exemple précédent de lui faire lire plus de vingt fichiers équivalait à empiler tout un tas d'autres plans d'ingénierie sur le plan de travail d'un coup, laissant très peu d'espace libre pour le « travail réel ».
Analogie : la taille du plan de travail. Imaginez Claude comme un menuisier travaillant sur un établi. La table a une certaine taille, et les plans, les outils, les pièces semi-finies, les post-its que vous lui tendez, tout doit être étalé sur cette table. Si la table est grande, il peut gérer beaucoup de choses à la fois ; si la table est pleine, il doit pousser les anciens plans sur le côté — et les informations sur ce plan, il les « oublie ».
Quelle est la taille de cette table ? Cela dépend du modèle que vous utilisez. La plupart des modèles ont une capacité de l'ordre de 200 000 tokens, certains modèles (comme ceux avec le tag [1m]) peuvent aller jusqu'à 1 million. Mais mémoriser une phrase est plus utile que de mémoriser un chiffre :
Aussi grande que soit la table, elle a des limites. Plus elle est pleine, plus il devient bête.
💡 En résumé : La fenêtre de contexte est le plan de travail de Claude, la plus grande partie de ce qu'elle contient ce sont les fichiers qu'il lit et non vos paroles ; la table a des limites, et quand elle est pleine, il commence à « faire tomber » les anciennes informations.
02 Que se passe-t-il quand le plan de travail est plein : il devient lent, bête, voire « amnésique »
C'est le diagnostic le plus important à retenir de cet article : le contexte n'est pas "plus il est plein, mieux c'est". Passé un certain niveau de remplissage, les performances de Claude se dégradent à vue d'œil.
Pourquoi ? Plus il y a de choses sur la table, plus l'« attention » du modèle est diluée, et les éléments anciens et non pertinents commencent à interférer avec la tâche en cours. Dans l'industrie, on appelle ce phénomène la « pourriture du contexte » (context rot).
Comment savez-vous qu'il « pourrit » ? J'ai résumé quelques symptômes de première ligne, et si vous en rencontrez un seul, vous devriez être en alerte :
- Il commence à se contredire, en oubliant la solution que vous aviez clairement validée ensemble auparavant.
- Ses réponses deviennent floues et générales, avec de moins en moins de détails, et il commence à dire des banalités correctes.
- Il vous redemande des choses auxquelles vous avez déjà répondu (comme le fameux « dans quel fichier est auth ? » du début).
- Pour le même problème, vous le corrigez plus de deux fois et il tourne toujours en rond.
Par exemple, en écrivant un script de migration de données, après plus d'une heure de discussion et de débogage répété, vers la fin, il a ressorti la solution erronée que nous avions conjointement rejetée dans la première partie de la session. Ses capacités ne s'étaient pas dégradées, c'est que le contexte avait été pollué par une heure de déchets de débogage.
Que fera Claude si la table est vraiment pleine ? Il compressera automatiquement (auto-compact) — nous détaillerons cela dans la section 05. Sachez pour l'instant : c'est une manœuvre de survie passive, dont le timing n'est pas décidé par vous, et qui peut vous interrompre soudainement au milieu d'une tâche cruciale.
Donc la bonne approche est : n'attendez pas qu'il compresse automatiquement, gérez-le activement. Comment gérer ? Lisez la suite.
💡 En résumé : Un contexte saturé déclenche une « pourriture du contexte » — contradictions, réponses générales, questions répétitives ; plutôt que de corriger sans cesse sur une table polluée, mieux vaut nettoyer activement.
03 Deux balais : /compact pour compresser vs /clear pour effacer
Pour ranger le plan de travail, Claude Code vous donne deux balais, dont les utilités sont totalement différentes, ne les confondez surtout pas.
/compact : « emballer et aplatir » ce qui est sur la table, mais le garder
Ce que fait /compact (compresser) c'est : résumer la longue série d'historique de conversation actuelle en un résumé concis, puis remplacer l'enregistrement mot à mot original par ce résumé, afin de continuer à travailler sur la même tâche.
Analogie : résumer une table remplie de brouillons en une page de points clés. Vous discutez avec un collègue pendant deux heures, et la table est recouverte de croquis jetés. /compact, c'est synthétiser ces croquis en une page de points clés : « nous avons finalement choisi A, rejeté B, la prochaine étape est C », pour libérer de la place sur la table, tout en gardant les conclusions.
Un point crucial, il permet de donner des instructions sur ce qu'il faut conserver en priorité :
/compact Conserve les décisions d'architecture du flux d'authentification et le format d'API validé, jette les tentatives infructueuses de débogageL'exemple anglais donné par le document officiel costs.md est /compact Focus on code samples and API usage (Concentre-toi sur les exemples de code et l'utilisation de l'API), ce qui revient au même.
Quand utiliser /compact : La tâche n'est pas encore terminée, mais le contexte est presque plein, et les éléments discutés précédemment seront encore utiles plus tard. Par exemple, au milieu de la création d'une fonctionnalité, les décisions d'architecture prises au début ne peuvent pas être perdues, mais une pile de sorties de commandes pour essais et erreurs intermédiaires peut être jetée.
/clear : Effacer complètement, repartir de zéro
/clear (effacer) est plus radical : il vide tout l'historique de la conversation, ce qui équivaut à ouvrir une toute nouvelle session.
Mais n'ayez crainte — /clear ne touche pas à votre CLAUDE.md ni à la mémoire automatique, ils se rechargent automatiquement dans la nouvelle session. Ce que vous perdez, c'est uniquement « le contenu discuté lors de cette conversation », les normes du projet et la mémoire à long terme sont toujours là.
Analogie : passer à une toute nouvelle tâche, nettoyer complètement la table avant de commencer. Si la tâche précédente est terminée, et que la suivante n'a rien à voir, alors vider entièrement la table est plus propre que de garder les interférences du travail précédent.
La documentation officielle costs.md le conseille littéralement : lorsque vous passez à un travail non lié, utilisez /clear pour recommencer, car « le contexte périmé gaspillera des tokens à chaque message suivant ».
Voici une règle de fer qui mérite d'être fixée : si vous corrigez le même problème deux fois et qu'il se trompe encore, ne perdez plus de temps dans cette session, faites un /clear direct, et avec les leçons apprises de ces deux tentatives, réécrivez un prompt plus précis pour demander depuis le début. Une table propre + un meilleur prompt gagnent presque toujours contre le fait de continuer à se débattre dans un contexte pollué — c'est l'une des expériences les plus précieuses testées dans la pratique.
💡 En résumé :
/compactc'est « emballer et aplatir, pour s'en servir ensuite »,/clearc'est « vider complètement, recommencer sur une nouvelle tâche » ; si vous le corrigez deux fois en vain, n'hésitez pas,/clear.
04 Surveiller l'utilisation : utiliser /context et /usage pour voir ce qu'il reste sur la table
Se fier à son intuition pour deviner « si c'est presque plein » est trop aléatoire. Claude Code fournit deux commandes pour vous permettre de voir les vrais chiffres. Ne confondez pas leurs noms.
/context : Voir ce qui remplit la table
/context/context va visualiser l'occupation en temps réel du contexte actuel à l'aide d'un graphique en blocs colorés, réparti par catégories — combien prend le prompt système, combien prend CLAUDE.md, combien prennent les différents services MCP, combien prend l'historique de la conversation, et il donnera également des suggestions d'optimisation. Le document officiel context-window.md est clair : si vous voulez connaître l'utilisation réelle de votre contexte à tout moment, lancez /context.
Une bonne habitude à prendre : avant de commencer une grosse tâche, lancez /context pour vérifier la base. Si vous vous apercevez qu'un service MCP occupe inutilement une grande partie, ou que CLAUDE.md est démesurément gonflé, nettoyez cela avant de commencer à travailler.
Il existe également une commande associée
/memory, utilisée pour vérifier quels fichiers CLAUDE.md et mémoires automatiques ont été effectivement chargés au démarrage — utilisez-la lorsque vous soupçonnez qu'il a « mal retenu » quelque chose.
/usage : Voir combien de tokens / d'argent ont été brûlés pendant cette session
/usageLe bloc Session en haut de /usage donne les statistiques d'utilisation des tokens pour la session en cours, et effectue également une conversion estimée en dollars (calculée localement). Voici à quoi ressemble l'exemple du document officiel costs.md :
Total cost: $0.55
Total duration (API): 6m 19.7s
Total duration (wall): 6h 33m 10.2s
Total code changes: 0 lines added, 0 lines removedExplication de la sortie attendue : Total cost est le coût estimé pour cette session (calculé localement, il peut différer de la facture réelle, les chiffres officiels se trouvent dans la console Claude) ; Total duration (API) est le temps réel passé à appeler le modèle ; Total duration (wall) est le temps total pendant lequel vous avez gardé cette session ouverte.
⚠️ Rappel : pour les utilisateurs abonnés Pro / Max, le coût des sessions est inclus dans l'abonnement, ce chiffre en dollars n'a pas de lien direct avec votre facture, regardez-le seulement comme un ordre de grandeur. Les forfaits et la facturation spécifiques ont été abordés dans le chapitre 06, cet article ne traite des tokens que sous l'angle du « contexte ».
Ça vous ennuie de le taper manuellement à chaque fois ? La version officielle permet aussi de garder l'utilisation du contexte affichée en permanence dans la barre d'état (statusline), afin qu'elle reste toujours visible à l'écran. Pour la méthode de configuration spécifique, consultez la documentation officielle de statusline, que nous ne développerons pas ici.
💡 En résumé :
/contextpour voir « ce qui occupe la table »,/usagepour voir « combien de tokens / d'argent ont été brûlés cette fois-ci » ; avant une grosse tâche, lancez/contextpour jeter un œil à la base.
05 Compression automatique (auto-compact) : il se protégera tout seul, mais ne comptez pas trop dessus
Nous avons mentionné à plusieurs reprises la « compression automatique », voyons dans cette section de quoi il s'agit exactement.
auto-compact (compression automatique) — c'est le mécanisme de survie intégré à Claude Code : lorsque le contexte est sur le point d'atteindre la limite de la fenêtre, il résumera automatiquement l'historique de la conversation, pour libérer de l'espace et continuer à travailler, vous évitant ainsi de vous heurter à un mur d'erreur. Le document officiel costs.md le place au même niveau que le prompt caching, comme l'un des deux moyens de Claude Code pour « optimiser automatiquement les coûts ».
Analogie : déchargement automatique sur une chaîne de montage. Le tapis roulant est presque plein, le système rassemble et compacte lui-même l'ancien matériel, pour éviter que toute la chaîne ne se bloque. Vous n'avez rien à faire, cela se déclenche automatiquement.
Ça a l'air sympa, mais je vous déconseille de vous y fier, pour deux raisons :
Premièrement, vous ne contrôlez pas le moment du déclenchement. Il est très possible qu'alors que vous lui faites faire une étape critique, la table se remplisse juste à ce moment-là, et il s'arrête brusquement pour aller compresser — votre rythme est complètement cassé.
Deuxièmement, la compression automatique est une compression « sans instruction ». Le moment où elle se déclenche est précisément celui où le contexte est le plus plein et le modèle le plus lent. À ce moment-là, c'est lui qui décide quoi jeter et quoi garder, et il est très possible qu'il efface ce que vous considérez comme important.
Donc, la bonne approche est d'être proactif : quand vous sentez que la conversation s'allonge et que /context indique une occupation élevée, faites un /compact vous-même en premier, en y ajoutant des instructions pour lui dire quoi garder en priorité. La compression proactive a deux avantages : vous décidez du moment, et vous décidez de ce qui est conservé.
Il y a encore une astuce pour être plus tranquille : écrire directement vos préférences de compression dans CLAUDE.md. L'exemple donné dans costs.md est d'ajouter ce bloc dans CLAUDE.md :
# Compact instructions
When you are using compact, please focus on test output and code changesAinsi, à chaque compression (qu'elle soit manuelle ou automatique), il conservera en priorité ce que vous avez spécifié, ce qui agit comme une assurance pour la compression automatique. Par exemple, si dans le CLAUDE.md d'un projet habituel vous écrivez « Lors de la compression, conserve les décisions de conception validées et les conventions d'interface », vous n'aurez plus à le lui répéter manuellement à chaque fois.
💡 En résumé : La compression automatique sert de sécurité, mais elle vous interrompt et peut effacer l'essentiel ; plutôt que de l'attendre, il vaut mieux déclencher proactivement
/compactavec des instructions, ou figer vos préférences dans CLAUDE.md.
06 Cinq astuces pour économiser des tokens : à la source, évitez que la table ne se remplisse trop vite
Nettoyer la table, c'est un rattrapage ; empêcher qu'elle ne se remplisse si vite est la meilleure stratégie. Voici cinq astuces utiles au quotidien, toutes conçues du point de vue du « contexte » et indépendantes du prix de votre forfait.
Astuce 1 : Ne vous entraînez pas sur un gros projet. Comme indiqué dans le chapitre 07 — pour la phase d'apprentissage et d'expérimentation, créez un projet de test avec trois à cinq fichiers. Moins il y a de fichiers, moins il en lit, la table reste propre, et vous voyez clairement ce qu'il a fait. Le piège du début (« lire plus d'une vingtaine de fichiers et devenir amnésique ») a pour origine le fait de prendre d'emblée un dépôt moyen qu'on ne connaît pas.
Astuce 2 : Utilisez @ pour cibler précisément un fichier, ne le laissez pas fouiller tout le dépôt. Au lieu de dire « corrige le bug de connexion » et de le laisser fouiller les fichiers un par un, dites directement @src/api/auth.ts répare le problème de 401. Le document officiel costs.md le dit très franchement : les requêtes vagues déclenchent des analyses vastes, les requêtes spécifiques lui permettent de travailler efficacement avec un minimum de lectures de fichiers. @ sert à clouer son regard directement sur le fichier concerné.
Astuce 3 : Ne lui donnez pas trop d'exigences à la fois. Si vous lui lancez cinq tâches non liées d'un coup, les fichiers qu'il lira et les sorties qu'il générera feront exploser la table. Divisez en cinq petites requêtes, et traitez-les une par une, la table restera toujours dégagée.
Astuce 4 : Divisez les tâches longues, nettoyez après chaque étape. N'espérez pas qu'une seule session porte une grosse fonctionnalité de bout en bout. Une fois une étape relativement indépendante terminée, faites un coup de /compact ; pour passer à une partie complètement différente, recommencez avec /clear.
Astuce 5 : Déléguez les opérations interminables à un sous-agent (subagent). Lancer des tests, fouiller des montagnes de logs, lire de la documentation... ces tâches qui produisent une quantité phénoménale de sorties, confiez-les à un sous-agent — il se débrouille sur son propre plan de travail indépendant, et ne ramène qu'un résumé des conclusions dans votre conversation principale. Dans l'exemple de context-window.md, un sous-agent a lu un fichier de 6100 tokens, mais le retour dans le contexte principal n'a pris que 420 tokens. Les sous-agents font l'objet d'un chapitre dédié plus tard, retenez pour l'instant que c'est l'arme absolue pour économiser du contexte. (Le lien sera ajouté en temps voulu).
Comparez « remède » et « prévention », et vous saurez où concentrer vos efforts :
| Action | Nature | Quand |
|---|---|---|
/compact | Remède · Compresser et conserver | Tâche non terminée, contexte élevé, le précédent est encore utile |
/clear | Remède · Effacer et recommencer | Passage à une tâche non liée, ou pollution trop forte |
Nouvelle session directe (quitter et relancer claude) | Prévention · Propreté absolue | On veut une table absolument propre, sans aucune trace de mémoire de la fois d'avant |
Cible précise avec @ | Prévention · Lire moins de fichiers | À faire à chaque demande |
| Projet de test pour pratiquer | Prévention · Réduire à la source | Phase d'apprentissage, essais |
| Sous-agent pour les tâches lourdes | Prévention · Isoler les sorties | Lancer des tests / fouiller les logs / consulter la doc |
💡 En résumé : Ranger la table est un rattrapage, lire moins de fichiers, diviser les petites tâches et déléguer aux sous-agents est la prévention ; le réflexe musculaire à adopter absolument est — lors d'une demande, cibler le fichier avec
@.
07 En pratique : trois étapes pour expérimenter la gestion du contexte
Regarder sans pratiquer ne sert à rien. Voici un petit exercice pour vous permettre de voir de vos propres yeux comment le contexte augmente, et comment /compact le réduit. Lancez claude dans n'importe quel répertoire de projet et suivez le guide.
Étape 1 : Regardez la base de départ
Après avoir lancé Claude, la première chose à taper est :
/contextRésultat attendu : Le terminal liste l'occupation actuelle du contexte par catégorie — vous verrez que le prompt système, CLAUDE.md, etc., occupent déjà une certaine place (c'est tout à fait normal d'avoir de l'occupation avant même d'avoir discuté), avec le total et des suggestions d'optimisation en bas. Notez ce chiffre de départ.
Étape 2 : « Nourrissez-le » volontairement avec du contenu, puis observez le changement
Faites-lui lire quelques fichiers et discutez un peu, par exemple :
Lis les principaux fichiers sources de ce projet, et explique-moi la structure globaleUne fois qu'il a fini de lire et de répondre, tapez à nouveau :
/contextRésultat attendu : L'occupation a clairement augmenté, les chiffres dans les catégories historique de conversation et fichiers ont grossi. Vous venez de voir de vos propres yeux le processus de « remplissage du plan de travail ».
Étape 3 : Utilisez /compact pour le réduire
/compact Conserve la conclusion sur la structure globale du projet, et jette le contenu brut de chaque fichier individuelRésultat attendu : Un message du type « Conversation compacted » (Conversation compressée) apparaît dans le terminal, la compression se fait silencieusement en arrière-plan, elle ne va pas vous inonder d'un écran de résumé. Après la compression, lancez à nouveau /context pour vérifier : l'occupation de la colonne historique de conversation devrait avoir diminué — il se souvient des conclusions sur la structure, mais les octets bruts des fichiers individuels ont été compressés en un résumé.
Vérification : Lancez /context avant et après la compression. Si le nombre de tokens de l'historique de conversation est élevé avant et bas après, cela signifie que /compact a fonctionné. Pour vérifier qu'il n'est pas « amnésique », demandez-lui ensuite « quelle est la structure du projet que tu viens de résumer ? », il devrait encore pouvoir vous répondre.
⚠️ Un détail : la compression est une opération avec perte. Elle conserve les points clés et les grandes lignes que vous avez spécifiés, mais le contenu mot à mot des anciennes sorties d'outils sera jeté. Donc, pour les conclusions vraiment importantes, prenez l'habitude (comme expliqué au chapitre 18) de les consigner dans CLAUDE.md — demander directement à Claude de « l'ajouter à CLAUDE.md » ou l'éditer avec
/memoryest plus sûr que de le laisser compressé dans la conversation.
💡 En résumé : Faites le cycle
/context→ nourrir le contenu →/compact→ à nouveau/context, et vous verrez de vos propres yeux comment le contexte monte et comment la compression le réduit ; comparer le nombre de tokens de l'historique avant et après vous montre si cela a marché.
08 Résumé
Dans cet article, nous avons exploré de fond en comble la « fenêtre de contexte » de ce plan de travail :
| Ce que vous avez appris | En une phrase |
|---|---|
| Ce qu'est la fenêtre de contexte | Le plan de travail de Claude, dont la plus grande part est prise par les fichiers lus et non par vos paroles |
| Ce qui arrive si c'est plein | Déclenche la pourriture du contexte — ralentissement, généralités, contradictions, amnésie |
/compact | Emballer, aplatir et conserver ; peut prendre des instructions pour cibler les points clés |
/clear | Vider complètement pour recommencer une nouvelle tâche, sans toucher à CLAUDE.md ni à la mémoire |
/context · /usage | L'un montre « ce qui est occupé », l'autre montre « combien a été brûlé » |
| Compression automatique | Mécanisme de survie, mais peut vous interrompre et effacer l'essentiel, l'action proactive est préférable |
| Économiser les tokens | Projets de test, pointer les fichiers avec @, ne pas tout regrouper, diviser les tâches, sous-agents |
Maintenant, vous devriez être capable de : comprendre ce que contient la fenêtre de contexte et pourquoi Claude devient stupide lorsqu'elle est pleine ; utiliser /compact pour compresser quand c'est nécessaire, et /clear pour recommencer à zéro le cas échéant ; utiliser /context et /usage pour surveiller l'occupation en temps réel ; et dès la formulation de la demande, utiliser une série d'habitudes d'économie de tokens, pour que la table garde toujours de la place pour le travail réel.
En fin de compte, l'essence de la gestion du contexte se résume à une phrase : utiliser avec parcimonie l'attention limitée de Claude pour les choses vraiment importantes.
Cette image compare la fenêtre de contexte à un plan de travail : une fois rempli de fichiers et de discussions (ici environ 92 %), on compte sur /compact pour compresser la pile de discussions en une page de points clés (à conserver pour la suite), ou sur /clear pour vider complètement la table (repartir de zéro) — le premier préserve l'information, le second cherche la propreté.
Article suivant 20 · Configuration des autorisations — Dans cet article, nous avons géré « combien Claude peut retenir », le prochain gérera « combien il peut faire ». Doit-il vous demander l'autorisation pour lire des fichiers, modifier du code ou exécuter des commandes, ou pouvez-vous le laisser faire ? Comment configurer des règles d'autorisation à la fois sûres et pratiques ? Une petite question pour vous faire réfléchir : Êtes-vous prêt à le laisser lancer un git push sans votre accord préalable ?