Organiser sa journée Claude Code autour de la fenêtre 5 h

Mercredi, 9 h 02. Tu demandes à Claude Code un simple résumé des commits de la veille, juste pour te remettre dans le bain. Rien de grave, sauf que tu viens de lancer le chronomètre. À 11 h 30, en plein milieu d'un refactoring sérieux, la limite tombe, et le reset est annoncé pour 14 h 02. Ta matinée intense s'est faite sur une fenêtre déjà entamée, et l'après-midi commence avec une fenêtre neuve que tu n'utiliseras qu'à moitié.

Tu ne peux pas augmenter le quota, mais tu choisis quand l'horloge démarre et comment tu dépenses ce qu'elle contient. Cet article, le deuxième de la série sur l'optimisation des sessions Claude Code, propose une organisation par blocs : où placer la tâche lourde, quand figer le modèle et l'effort pour préserver le cache, quand compacter, et comment garder un œil sur le budget hebdomadaire sans y penser.

Pourquoi la fenêtre de 5 h change ton agenda ?

Rappel du premier article de la série : sur les abonnements Pro et Max, la fenêtre de session démarre au premier message envoyé et se réinitialise entièrement 5 heures après. Un premier message à 8 h ouvre une fenêtre qui court jusqu'à 13 h, que tu travailles dessus ou non.

Sur une journée de 8 h à 18 h, tu raisonnes donc en deux ou trois fenêtres, pas en une enveloppe continue. Par exemple 8 h à 13 h, puis un nouveau premier message vers 13 h 30, qui ouvre une fenêtre jusqu'à 18 h 30. Le temps restant de la fenêtre en cours est visible dans Settings > Usage, rubrique « Current session ».

Deux nuances. Un compte Ultra vérifié n'a pas de limite de 5 h, seulement l'hebdomadaire : seuls les conseils sur le cache et le budget hebdo le concernent. Et les limites sont partagées avec Claude sur le web, le desktop et le mobile, ainsi qu'avec les IDE : ta conversation de 7 h 50 sur le téléphone a peut-être déjà ouvert ta fenêtre.

Comment découper sa journée en blocs ?

L'idée est de traiter chaque fenêtre comme un sprint court avec un objectif livrable. Quelques règles qui marchent :

• Un bloc, un résultat vérifiable : une PR ouverte, une migration passée en CI, un refactoring terminé. Une tâche qui enjambe le reset est la plus coûteuse à reprendre.
• Le travail lourd en début de fenêtre : exploration d'un code inconnu, refactoring large, modifications multi-fichiers. C'est là que tu as le plus de marge pour te tromper et recommencer.
• Le travail léger en fin de fenêtre : relecture, renommages, documentation, tests ciblés, messages de commit. Si la limite arrive, tu perds peu.
• Une nouvelle conversation plutôt qu'une longue : Anthropic rappelle que la longueur et la complexité de la conversation, les fonctionnalités utilisées, le modèle et l'effort pèsent sur la consommation. Une conversation qui s'étire coûte de plus en plus cher par message.
• Un effort bas pour le routinier : c'est le conseil officiel pour les tâches répétitives.

Aucun chiffre absolu (messages ou tokens par fenêtre) n'est publié. Ne planifie donc pas en « N requêtes » : planifie en pourcentage consommé, que la statusline affichera plus bas.

Que faire en début de fenêtre pour préserver le cache ?

Les premières minutes déterminent le coût du reste de la fenêtre. La documentation sur le cache de prompt recommande de choisir le modèle et l'effort au début de la session, car changer de modèle invalide le cache : la requête suivante relit tout l'historique sans en profiter. Dans l'ordre :

• Choisis le modèle avec /model et l'effort avec /effort, avant le premier vrai prompt.
• Passe en plan mode pour cadrer la tâche. Changer de mode de permission conserve le cache.
• Valide le plan, puis exécute sans rebasculer de modèle.

Le piège est le réglage opusplan : il utilise Opus en plan mode et Sonnet en exécution, donc chaque bascule de plan est un changement de modèle et repart sur un cache neuf. C'est défendable pour un gros chantier cadré une fois, coûteux si tu alternes plan et exécution toutes les dix minutes.

Bonne nouvelle pour l'effort : sur Opus, Sonnet et Haiku 5.5 (abonnement ou clé API), le changer en cours de session conserve le cache. Ce qui l'invalide, en revanche : le fast mode, la connexion ou le retrait d'un serveur MCP chargé d'emblée, la compaction, une accumulation d'images, et la mise à jour de Claude Code, qui s'applique au lancement suivant. Pas de redémarrage pour « tester la nouvelle version » en pleine fenêtre.

Dernier réglage de début de journée : garde ton CLAUDE.md sous 200 lignes environ. Il est chargé à chaque session et pèse sur chaque requête. Le reste peut vivre dans des skills chargés à la demande, comme expliqué dans les leviers natifs pour économiser des tokens.

Pourquoi tes pauses coûtent-elles du quota ?

Sur un abonnement, dans l'usage inclus, la conversation principale bénéficie d'un cache de prompt d'une heure. Les autres requêtes (sous-agents, compaction, workflows) restent sur un cache de 5 minutes.

Conséquence concrète : une pause café de 20 minutes ne coûte rien de particulier. Un déjeuner de 90 minutes provoque un cache miss : le premier message au retour retraite l'intégralité du contexte. Plus la session est longue, plus ce premier message est cher. Trois habitudes en découlent :

• /compact aux pauses naturelles, entre deux tâches, plutôt que l'auto-compaction qui se déclenche en pleine tâche. /compact lit toute la conversation : autant choisir le moment où tu la paies, de préférence quand le cache est encore chaud.
• /rewind quand tu abandonnes une piste : il revient à un préfixe déjà en cache, alors que /compact en construit un nouveau.
• /clear à la fin d'une tâche indépendante : il ne coûte rien. Fais un /rename avant pour retrouver la session plus tard avec /resume.

La combinaison la plus chère : reprendre une vieille session le lendemain et lancer /compact dessus, cache froid sur tout l'historique. Avant de partir déjeuner avec une session volumineuse, décide si tu la reprendras ou si tu la clôtures proprement. Pour le diagnostic, /usage affiche une ligne Prompt cache (main) avec la part de l'input servie du cache, le nombre de misses et leur cause probable. La gestion fine du contexte est détaillée dans l'article sur le context rot.

Quels consommateurs de fond couper ?

Une session qui paraît au repos peut continuer à consommer, en renvoyant à chaque fois tout son contexte. Les suspects principaux :

• /loop : une tâche planifiée de session tourne même quand tu ne tapes rien. Les plus lourdes apparaissent dans les lignes « Loops » de /usage.
• Les check-ins de /goal : jusqu'à trois au repos quand un objectif attend un travail de fond. La variable CLAUDE_CODE_GOAL_CHECKIN_MINUTES=0 les coupe.
• L'idle compaction : sur une longue conversation laissée inactive, Claude Code peut la compacter. Le réglage idleCompaction à false la désactive.

Avant une réunion, arrête ce qui n'a plus de raison de tourner. Pour l'idle compaction, dans ~/.claude/settings.json :

{
  "idleCompaction": false
}

Et pour une session sans check-ins de goal :

CLAUDE_CODE_GOAL_CHECKIN_MINUTES=0 claude

Comment afficher l'heure de reset dans la statusline ?

La statusline reçoit les champs rate_limits.five_hour et rate_limits.seven_day, chacun avec used_percentage (de 0 à 100) et resets_at (un timestamp Unix en secondes). Ils n'existent que pour les abonnés Pro, Max et Ultra, et seulement après la première réponse de la session : le script doit tolérer leur absence. Voici une version du script officiel enrichie de l'heure de reset, validée avec bash -n et testée sur un JSON d'exemple :

#!/usr/bin/env bash
# ~/.claude/statusline.sh -> [Opus 5.5] | 5h: 42% (reset 13:32) | 7d: 19% (reset Thu 11:32)
input=$(cat)

MODEL=$(jq -r '.model.display_name' <<<"$input")
FIVE_PCT=$(jq -r '.rate_limits.five_hour.used_percentage // empty' <<<"$input")
FIVE_RST=$(jq -r '.rate_limits.five_hour.resets_at // empty' <<<"$input")
WEEK_PCT=$(jq -r '.rate_limits.seven_day.used_percentage // empty' <<<"$input")
WEEK_RST=$(jq -r '.rate_limits.seven_day.resets_at // empty' <<<"$input")

# epoch -> heure lisible : GNU date (Linux) puis repli BSD date (macOS)
fmt_epoch() {
  date -d "@$1" "+$2" 2>/dev/null || date -r "$1" "+$2"
}

OUT="[$MODEL]"
if [ -n "$FIVE_PCT" ]; then
  OUT="$OUT | 5h: $(printf '%.0f' "$FIVE_PCT")%"
  [ -n "$FIVE_RST" ] && OUT="$OUT (reset $(fmt_epoch "$FIVE_RST" '%H:%M'))"
fi
if [ -n "$WEEK_PCT" ]; then
  OUT="$OUT | 7d: $(printf '%.0f' "$WEEK_PCT")%"
  [ -n "$WEEK_RST" ] && OUT="$OUT (reset $(fmt_epoch "$WEEK_RST" '%a %H:%M'))"
fi
echo "$OUT"

Rends-le exécutable avec chmod +x ~/.claude/statusline.sh, puis déclare-le dans ~/.claude/settings.json :

{
  "statusLine": {
    "type": "command",
    "command": "~/.claude/statusline.sh",
    "padding": 2
  }
}

Sous Linux, date -d @epoch convertit le timestamp. Sous macOS, cette option n'a pas le même sens et échoue : la syntaxe BSD est date -r epoch. La fonction fmt_epoch tente la première puis se replie sur la seconde. Les jours abrégés (%a) suivent la locale de ton shell.

Comment répartir son budget hebdomadaire ?

Le plafond hebdomadaire se réinitialise à une heure fixe chaque semaine, assignée à ton compte, indépendante de ta date d'abonnement et du moment où tu commences à travailler. La statusline ci-dessus te donne ce jour et cette heure : note-les une fois. Ensuite, répartis au lieu de tout consommer en début de semaine :

• Regarde le pourcentage 7d au bout du premier jour : s'il dépasse déjà largement un cinquième, la semaine sera serrée.
• Garde les tâches lourdes et exploratoires pour les jours où tu as de la marge, et les relectures et corrections pour la fin de cycle.
• Si ton reset tombe en milieu de semaine, tu as un « deuxième lundi » : c'est le bon moment pour les gros chantiers.
• N'oublie pas que Claude sur le web et le mobile alimentent le même compteur.

Pour savoir quelles tâches coûtent vraiment cher, mesure-les plutôt que de les estimer : la méthode est dans l'article sur le coût par tâche réussie.

Reste la question du message d'amorçage. Certains envoient un message jetable vers 7 h pour caler la fenêtre sur leur journée. C'est une pratique communautaire, pas une recommandation d'Anthropic : elle consomme peu, mais elle déplace la fenêtre sans ajouter de capacité, et elle n'est pas neutre pour l'hebdomadaire. Je ne la recommande pas par défaut : choisir consciemment l'heure de ton premier vrai message suffit dans la plupart des cas.

La checklist de la journée

• Installe la statusline avec l'heure de reset et note ton jour et ton heure de reset hebdomadaire.
• En début de fenêtre : /model et /effort d'abord, plan mode ensuite, aucun changement de modèle en cours de route.
• Un bloc, un résultat livrable. Le lourd au début, le léger à la fin.
• Avant une pause de plus d'une heure : /compact ou clôture, pas après.
• Une fois par jour, /usage : cache, loops, attribution.
• Coupe /loop, les check-ins de /goal et l'idle compaction quand tu n'en as pas besoin.
• En fin de fenêtre : note de passation, /rename, puis /clear.

Ces réglages valent surtout pour un abonnement individuel. Or le mode de facturation change les règles du jeu, parfois sans que tu l'aies décidé : le prochain article fait le tour des formules (Pro, Max, Ultra, Team, Enterprise, API, usage credits) et d'un piège de variable d'environnement qui peut te faire payer au token sans que tu le saches. Et si la limite tombe malgré tout, le dernier volet explique comment reprendre sans perdre le fil.

Ce rythme marche bien en solo, mais il repose sur des réglages personnels que personne d'autre ne partage. Dans une équipe, le gain vient surtout des conventions communes, un CLAUDE.md partagé et des habitudes de session alignées, et c'est exactement ce qu'on met en place en atelier, sur tes propres dépôts.

Écrit par

Flavien Métivier

Expert PHP/Symfony indépendant depuis 2014, ancien CTO de Kartable et d'Extrabat. Plus de 80 projets menés, de l'audit à la migration.

Mon parcours