Quick wins and what's possible

Avant d'aller plus loin sur comment Claude Code fonctionne sous le capot, voici huit choses que vous pouvez faire aujourd'hui et que la plupart des utilisateurs ne découvrent que des semaines ou des mois plus tard. Aucune ne nécessite de configuration, et chacune soulève vos résultats tout de suite.

Les quick wins

Détaillons chacun.

1. Laisser l'auto-routing choisir le modèle, escalader vers Opus max pour la charge cognitive

Claude Code vous donne accès à plusieurs modèles (Haiku, Sonnet, Opus) à plusieurs niveaux d'effort. L'ancien conseil, celui que je donnais, était « pin Opus à max effort et ne plus jamais y penser ». Ce conseil est maintenant obsolète.

Deux choses ont changé. Haiku 4.5 a comblé la plupart de l'écart de qualité avec Sonnet sur le travail de routine. Et Claude Code a livré l'auto-routing. Il lit la tâche devant lui et choisit le bon tier. Des modèles pas chers pour des tours pas chers, les lourds quand la tâche le justifie. Forcer Opus partout maintenant signifie brûler de l'argent et des rate-limits sur des tâches qui n'en avaient pas besoin.

Donc le défaut est simple : laissez l'auto-routing activé. Ne pinnez pas un modèle. Laissez le harness faire son travail.

L'escalade est la règle qui compte. Quand vous sentez la charge cognitive vous-même (vous écrivez une spec, vous prenez une décision architecturale, vous debuggez quelque chose qui a résisté à deux tentatives), c'est là que vous atteignez /effort max. Cette commande monte le modèle actif à la profondeur de raisonnement maximum pour le prochain tour. Utilisez-la comme un passage de vitesse, pas comme un réglage.

/effort max

Vous pouvez confirmer que le routing fait bien ce que vous attendez à tout moment avec /model pour voir le tier actuel. Si vous voulez la context window d'un million de tokens, optez-y une fois via le sélecteur de modèle (suffixe [1m] sur Opus) et restez opté-in pour la session.

Sur le plan Pro (20 $/mois), l'usage d'Opus a des rate-limits. Le plan Max (100-200 $/mois) donne significativement plus de marge. Sur l'API, Opus est le tier le plus cher. L'auto-routing vous protège de ces limites par défaut ; l'escalade max-effort vous coûte les crédits qu'elle utilise réellement.

2. Passer en Plan Mode pour les moments de ralentissement

Le Plan Mode (Shift+Tab deux fois) était la recommandation pour « tout ce qui est non trivial ». C'était le bon conseil quand l'autonomie était l'opt-in. C'est maintenant le mauvais conseil, parce que l'autonomie est le défaut.

Le cadrage du « curseur d'autonomie » de Cherny (qu'Anthropic traite maintenant comme canonique) inverse la question. Le curseur est sur « laisse Claude tourner » par défaut. Le Plan Mode est l'échappatoire opt-in : vous y entrez quand vous voulez ralentir avant que l'agent touche à votre code.

Donc la nouvelle question n'est pas « est-ce assez non-trivial pour planifier ? ». La nouvelle question est « est-ce que je veux que Claude bouge librement ici, ou est-ce que je veux lire un plan d'abord ? ».

Concrètement, passez en Plan Mode quand :

• Le changement est à enjeux et l'annuler serait douloureux (une migration, un refactor qui touche plein de fichiers, tout ce qui est dans du code adjacent à la production)
• Le scope est flou et vous soupçonnez que Claude pourrait résoudre le mauvais problème
• Vous debuggez et vous voulez voir l'hypothèse de Claude avant qu'il commence à éditer
• Vous travaillez dans du code inconnu et vous voulez une visite guidée avant que les changements commencent

Sinon, laissez l'autonomie activée. Petites éditions, relances dans un fil que vous avez déjà cadré, travail de feature simple dans du code que Claude comprend déjà. Ceux-là n'ont pas besoin du Plan Mode. Ils n'ont jamais été le bottleneck.

3. Lancer /init pour votre CLAUDE.md

CLAUDE.md est un fichier que Claude lit au début de chaque session. Il contient les commandes de build de votre projet, les règles de style de code, les instructions de test, et les décisions architecturales. C'est le fichier de configuration le plus important de Claude Code.

Vous n'avez pas à l'écrire de zéro. Lancez /init et Claude analyse votre projet (build system, framework de test, patterns de code) et génère un CLAUDE.md pour vous. Il est juste à 80% au premier passage. Ajustez les 20% restants en fonction de ce que vous connaissez de votre projet.

4. Parcourir le marketplace des skills, en installer deux ou trois

Les skills sont sorties de la beta. Elles sont GA maintenant, et l'écosystème a rattrapé vite. Il y a un marketplace de skills communautaires et publiées par Anthropic qui couvre la plupart de ce que vous auriez bâti en premier de toute façon : code review, scaffolding de tests, passes de refactor, design-to-code, checklists de deploy, helpers de libs doc-aware.

Une skill est un fichier markdown avec un trigger en frontmatter. Le trigger dit à Claude quand la charger : « quand l'utilisateur demande X ». Tant que le trigger ne se déclenche pas, la skill coûte zéro contexte. C'est le design qui rend « en installer plusieurs » réellement viable. Trois bonnes skills que vous n'avez jamais utilisées aujourd'hui ne vous coûtent toujours rien dans cette session.

Le quick win est le même que celui que vous avez utilisé avec /init : ne commencez pas par écrire les vôtres. Ouvrez le marketplace des skills, installez-en deux ou trois qui matchent du travail que vous faites chaque semaine, et utilisez-les quelques jours. Vous apprendrez plus vite à quoi une skill sert en en faisant tourner une de quelqu'un d'autre qu'en essayant de concevoir la vôtre à l'aveugle.

Le Chapitre 4 couvre comment les skills fonctionnent en détail : le format SKILL.md, quand choisir une skill plutôt que CLAUDE.md ou MCP, comment designer de bons triggers. Aujourd'hui vous avez juste besoin de savoir que le marketplace existe et qu'installer depuis là est le chemin le plus rapide pour entrer.

5. Donner à Claude des critères de vérification

C'est l'habitude au plus fort levier que vous puissiez construire.

Quand vous finissez un prompt avec « lance les tests après » ou « vérifie que le build passe », Claude vérifie son propre travail. Quand un test échoue, il lit l'erreur, corrige le problème, et relance les tests. Sans critères, Claude peut sauter la vérification entièrement et passer à autre chose.

6. Utiliser /compact, /cost, et /context

/cost montre où vont vos tokens : tokens d'input consommés, tokens d'output générés, répartition par catégorie d'outil. Lancez-le périodiquement pour rester conscient de votre budget.

/context visualise votre usage de contexte comme une grille colorée et affiche des suggestions d'optimisation, en flaggant les outils lourds en contexte, le memory bloat, et les avertissements de capacité. Voyez-le comme un dashboard pour la santé de votre session.

/compact résume l'historique de conversation plus ancien, libérant de l'espace pour le nouveau travail. Utilisez-le entre des tâches sans rapport. La clé : vous pouvez lui donner des instructions de focus. /compact Focus on the API changes dit à Claude quoi préserver et quoi résumer agressivement. Sans instructions, Claude devine ce qui compte. Avec instructions, vous dirigez la compression.

/compact Focus on the auth implementation and test results
/compact Preserve the file list and migration steps, summarize everything else
/compact Keep the architecture decisions, drop the debugging context

Voyez /cost comme vérifier votre pourcentage de batterie, /context comme le dashboard de santé de la batterie, et /compact comme une sauvegarde stratégique qui préserve ce que vous choisissez.

7. Interrompre et revenir en arrière

Esc stoppe Claude en pleine action. Le contexte est préservé. Vous pouvez rediriger sans rien perdre.

Esc+Esc ouvre le menu rewind. Vous pouvez restaurer la conversation, le code, ou les deux à n'importe quel état précédent. Chaque action que Claude prend crée un checkpoint. Si quelque chose tourne mal, vous revenez en arrière.

Les best practices d'Anthropic ajoutent une règle de plus : « Si vous avez corrigé Claude plus de deux fois sur le même problème, /clear et recommencez avec un prompt plus spécifique. Une session propre avec un meilleur prompt surpasse presque toujours une longue session avec des corrections accumulées. »

8. Utiliser /clear entre des tâches sans rapport

Les longues sessions avec du contexte non pertinent réduisent les performances. Quand vous finissez de debugger un bug et voulez commencer une nouvelle feature, lancez /clear. La nouvelle tâche démarre avec une context window propre au lieu de patauger dans une conversation sur l'ancien bug.

Ça donne l'impression de gaspiller. Vous jetez tout ce que Claude a appris. Mais une session focusée de 10 minutes bat une session encombrée de 40 minutes à chaque fois.

Ce qui devient possible

Ces huit quick wins vous font passer du défaut à solide. Mais Claude Code est plus qu'un outil de code. C'est un système extensible. Laissez-moi vous montrer ce qui devient possible quand vous le configurez.

Le paysage des plugins

Il existe des systèmes bâtis par la communauté qui étendent Claude Code avec des workflows spécialisés. Chacun prend une approche différente :

Aucun ne couvre tout. Le bon mouvement est d'en choisir un, vivre avec pendant un moment, voir ce qui fit votre workflow, puis bâtir le vôtre. Une fois que vous comprenez comment votre système fonctionne, vous savez comment l'utiliser correctement. Les 57 commandes de quelqu'un d'autre incluront 40 que vous ne toucherez jamais.

Au-delà du code

Un Claude Code configuré va bien au-delà d'écrire du code. C'est la partie que la plupart des gens n'atteignent jamais.

Marketing. Je tape /copywriting et Claude réécrit la copy de ma landing page en utilisant des principes de psychologie marketing : rareté, preuve sociale, aversion à la perte. Je tape /seo-audit et il crawl mon site, checke les meta tags, analyse la structure des headings, et trouve quinze problèmes que j'aurais manqués à la main.

Recherche. Je pointe Claude sur de la documentation et il produit des briefings de recherche structurés que je peux référencer plus tard. Pas des résumés. Des analyses structurées avec des insights clés, des comparaisons, et des recommandations sur lesquelles je peux agir.

Design-to-code. Je colle une URL Figma et Claude implémente le design en utilisant les composants existants de mon projet, en matchant l'espacement, la typographie, et les color tokens. Pas du HTML générique. Du code production-ready qui suit mon design system.

Déploiement. Claude fait tourner ma checklist de pré-déploiement : migrations de base de données appliquées, variables d'environnement set, DNS configuré, smoke tests au vert. Il me dit ce qui manque avant que je ship.

Ce n'est pas hypothétique. Ce sont des commandes que je lance sur mes propres projets. L'écart entre « Claude écrit du code pour moi » et « Claude gère la moitié de mon travail » est ce que ce cours comble.

L'écart

Les quick wins vous font passer du défaut à 3x. Un système configuré vous amène à 10x. La différence n'est pas d'installer plus de plugins ou de mémoriser plus de commandes. C'est la méthodologie : vous apprenez comment Claude Code dépense réellement ses ressources, vous bâtissez sur cette réalité, et vous finissez avec un système qui s'améliore un peu à chaque utilisation.

Cette méthodologie est ce que les Chapitres 2 à 7 enseignent. Le reste de ce chapitre met en place l'unique ressource que tout ça protège, en commençant par la question que vous vous posez probablement déjà : est-ce que la context window de 1M n'a pas fait tout ça disparaître ?