Il y a quelques mois, j'ai traduit un vieux visual novel d'horreur chinois en français avec Claude Code : les menus, les dialogues, quasiment tout. J'ai enfin pu y jouer en comprenant l'intrigue (j'ai arrêté au premier jumpscare, mais c'est un autre sujet). Ce jour-là, j'ai appris pas mal de choses, et je n'ai rien écrit. Si je devais le refaire, je ne saurais plus par où commencer.

Et c'est le sort de tous mes projets. J'utilise Claude Code tous les jours, pour des clients comme pour le plaisir ; certains aboutissent, d'autres meurent en route, et tout reste stocké en local sans que rien n'en sorte. À chaque session j'apprends quelque chose, et chaque session s'évapore.

D'où l'idée que je teste dans cet article : et si Claude Code tenait son propre journal ?

L'hypothèse

À l'heure actuelle, je ne sais pas si j'ai vraiment besoin de ce système. Je vais peut-être le bazarder après une session, ou peut-être que je ne pourrai plus m'en passer. Cet article servira à documenter l'expérience.

Les hooks

Les hooks sont des actions qui se déclenchent automatiquement à des moments précis d'une session Claude. Ça peut intervenir au moment où vous le décidez :

  • à la fin d'un échange
  • à la fermeture d'une session
  • à l'ouverture d'une session
  • lorsqu'un mot ou un terme est écrit
  • lorsqu'une action est accomplie
  • etc.

À chacun de ces moments, on peut accrocher un script.

Récemment, j'ai eu un souci avec Opus 5, qui m'envoyait des messages commençant par « Correction » : il corrigeait une affirmation qu'il m'avait donnée deux messages plus tôt… Ça m'a rendu FOU.

Naruto en train de secouer Claude

J'ai réussi (après de nombreux allers-retours avec Claude) à faire intervenir un second modèle en mode « gardien », qui vérifiait constamment si des affirmations étaient posées sans preuve. Ça consommait un peu plus de tokens par tour, mais j'étais plus serein. Depuis, j'ai changé de modèle et débranché le gardien : le souci venait surtout d'Opus 5, qui dit une chose puis son inverse. Le mécanisme, lui, m'a montré tout ce qu'un hook sait faire.

Et cet utilisateur de Reddit a, j'ai l'impression, le même souci que moi.

Capture d'un échange Reddit : un utilisateur excédé par les affirmations fausses répétées de son modèle

Le système de journalisation que j'ai mis en place repose sur ce mécanisme : à chaque message que j'envoie à Claude Code, une entrée s'ajoute dans un fichier. Un fichier par jour, par projet, avec toutes les actions effectuées.

Vu que je ne sais jamais quand je m'arrête de bosser, je ferme mon ordinateur quand j'ai fini mes tâches, quand je suis trop fatigué, ou tout simplement quand j'en ai marre. J'avais donc besoin d'un système automatique pour les comptes-rendus : chaque jour, le script vérifie si le récapitulatif de la semaine existe. S'il manque, il l'écrit.

Ça, c'était le plan. La réalité était tout autre.

Ce que j'ai construit

La mise en place elle-même a été rapide : deux heures entre le premier échange et le système validé. Précision qui a son importance : je ne suis pas développeur. Le seul code que je sais écrire, c'est du HTML et du CSS. Tout le reste s'est fait en français, en discutant. Claude Code a créé le dossier, le Git et le repo GitHub privé.

Deux heures, mais pas en ligne droite. Trois versions.

Itération 1, le copier-coller tronqué. J'ai commencé à lire ce qu'il écrivait, et les corrections ont commencé : la date en anglais, la structure inversée (un dossier par projet avec des fichiers datés dedans, alors que moi je voulais relire ma journée, pas la vie d'un projet), des « résumés » qui recopiaient seulement les débuts de mes messages. Verdict : illisible.

Et un truc que je n'ai compris que bien plus tard : une partie de cet illisible venait de moi. J'avais programmé un hook qui coupe les sorties trop longues, pour museler un modèle extrêmement bavard et bourré de jargon. Ce garde-fou tronquait aussi mon journal.

J'ai d'abord accusé le modèle, j'en ai même changé pour un plus gros en pensant régler le problème. Le coupable, c'était mon propre garde-fou. Depuis, le journal tourne sur le plus petit modèle du catalogue, et il suffit largement (c'est toute la thèse de : le modèle le plus récent n'est pas le meilleur).

Itération 2, la synthèse à la fermeture de session. Celle-là, je ne l'ai jamais construite. En me projetant, j'ai réalisé que je ne ferme presque jamais une session : je ne tape pas /exit, je rabats le capot de l'ordinateur et basta. Et puis c'est quoi, une « fin de session » ? Chacun a sa propre définition. La mienne, c'est le capot.

Itération 3, le condensé toutes les 15 minutes. L'architecture finale : à chaque fin d'échange, le script regarde l'horloge ; si 15 minutes se sont écoulées depuis le dernier passage, il relit ce qui s'est écrit entre-temps dans toutes mes sessions ouvertes, anonymise, et envoie ça à Haiku (le modèle le moins cher d'Anthropic), qui écrit un résumé de 1 à 3 puces par projet. Et côté budget : zéro dépense en plus, tout tourne dans mon abonnement Claude.

Schéma du fonctionnement du journal en quatre étapes : je travaille, un déclencheur relit toutes les 15 minutes, le petit modèle résume, une page par jour

Le premier condensé lisible disait : « 22 liens 3XX corrigés ». Une ligne. C'est exactement ce que je voulais relire.

Dernière leçon, dès la première vraie journée : le journal a exposé les prénoms de mes interlocutrices clientes et un projet perso. Table d'anonymisation, purge de l'historique Git. Un journal automatique, ça note tout, y compris ce qui ne doit pas sortir.

Voici à quoi ressemble une page du journal (les clients sont anonymisés par secteur d'activité) :

Une page du journal, le 07/08/2026

Ce qui peut faire échouer le test

Je vois deux morts possibles pour ce journal, et je préfère les écrire avant de connaître le résultat.

Le journal-cimetière : des fichiers qui s'accumulent et que je ne relis jamais. C'est le destin de la plupart des systèmes de notes, et je n'ai aucune raison de me croire immunisé.

Le journal-photocopie : vu que je fais souvent les mêmes tâches, les entrées vont probablement toutes se ressembler et il n'y aura aucune plus-value à capturer des journées identiques. Honnêtement : j'en sais rien.

Pour parer ces deux morts, le bilan hebdomadaire doit être synthétique : 5 minutes à lire maximum. Au bout d'un mois, je pourrai dire si mes journées sont vraiment des photocopies, ou si des motifs émergent qu'on ne voit pas jour par jour.

Un mois plus tard

Cet article devait se terminer par « rendez-vous dans trois mois ». Le journal a un mois, alors voici un premier point d'étape, à chaud.

Le critère de succès, c'était la survie. Verdict : le journal a écrit tous les jours pendant un mois, tout seul. Je suis même parti deux semaines en vacances : le journal s'est arrêté d'écrire quand j'ai rabattu le capot, et il a repris tout seul à mon retour. Zéro maintenance, zéro redémarrage. Le premier mois, en une image :

Graphique du premier mois du journal : le nombre de résumés écrits chaque jour, avec le creux des deux semaines de vacances et la reprise automatique le 1er septembre

La mort n°1, le journal-cimetière, n'a pas eu lieu. Le contrat, c'était une relecture par semaine : pour l'instant il tient. À mon retour de vacances, j'ai tout relu d'un coup.

La mort n°2, le journal-photocopie, n'a pas eu lieu non plus. Cette relecture était agréable parce que variée : des audits GEO, un agent Telegram, ce site que vous lisez. Et surtout des trucs que j'avais complètement oubliés, qui vont devenir des tweets : la traduction de Tree of Savior que j'ai installée, les builds que Claude m'a aidé à monter.

Et il y a une utilisation que je n'avais pas prévue : cet article lui-même. Pour l'écrire, Claude a relu le journal et m'a ressorti des détails que ma mémoire avait effacés, le premier condensé lisible, les prénoms exposés du premier jour. Le journal ne sert pas qu'à se souvenir : il sert à raconter.

Le rendez-vous dans trois mois tient toujours, pour le verdict final. Mais à un mois, je peux déjà dire une chose : je ne l'ai pas bazardé.