Mercredi 14 octobre, un mail de Packt : un partenariat, et un accès gratuit à ExpertEdge, sa plateforme d'abonnement aux livres techniques. Première recherche, par réflexe : « Claude Code ». Quatre livres, tous parus en 2026. J'ai haussé les épaules. Je me sers de Claude Code tous les jours depuis plus d'un an. J'ai écrit ici sur ses hooks, sur mon CLAUDE.md et sur ce que coûtent ses plugins. Qu'est-ce qu'un livre allait m'apprendre ?
J'avais tort à moitié. Trois d'entre eux se trompent sur des syntaxes, parfois au point que leurs exemples ne marchent pas. Sur l'essentiel, en revanche, ils se recoupent, et cette partie-là ne vieillira pas. Un des quatre se détache malgré ses défauts : The Claude Code Operating Model.
Comment j'ai lu 1,2 million de caractères en une soirée
Je n'ai pas lu ces livres seul, et je préfère le dire tout de suite. ExpertEdge ne vend pas des PDF : il affiche les livres découpés en leçons dans un lecteur en ligne. J'ai laissé Claude piloter mon navigateur pour extraire le texte leçon par leçon. J'ai sauté les quiz : ce sont des évaluations à mon nom, je n'allais pas les faire passer par une IA. Ensuite, des agents ont lu chaque livre, et j'ai vérifié chaque citation retenue contre le texte extrait, mot pour mot, avec un script. Un agent qui relit son propre travail se note trop bien : j'ai expliqué pourquoi dans Aucun agent ne corrige sa propre copie.
Le texte extrait pèse 1 170 431 caractères : 527 600 pour The Claude Code Operating Model (84 leçons extraites sur les 93 annoncées), 385 585 pour Agentic Coding with Claude Code, 130 430 et 126 816 pour les deux livres de Zenva, un éditeur de cours en ligne.
Le coût, lui, est réel. Un token est le petit morceau de texte que le modèle lit, et que ton abonnement ou ton API compte. Lire en entier Agentic Coding, avec deux agents, m'a coûté de l'ordre de 250 000 tokens, de quoi entamer sérieusement un quota. J'ai donc dépensé au moins 250 000 tokens pour apprendre à en gaspiller moins.
Quel livre sur Claude Code lire en premier
| Livre | Éditeur | Note | En une phrase |
|---|---|---|---|
| The Claude Code Operating Model (Jia Huang) | Packt | 6,6/10 | Le seul qui pense en ingénieur, malgré une relecture bâclée |
| 101 Claude Code Tips (Zenva, auteur non nommé) | Zenva | 6,2/10 | Le carnet de notes d'une équipe qui s'est brûlé les doigts |
| Agentic Coding with Claude Code (Eden Marco) | Packt | 5,4/10 | Un cours vidéo mis par écrit, plein de démos et d'erreurs |
| Best Practices for Claude Code (Zenva, auteur non nommé) | Zenva | 6,0/10 | Un bon cours de discipline sous un titre qui promet trop |
Le meilleur : The Claude Code Operating Model. C'est le seul qui explique comment les pièces s'emboîtent. Il couvre le CLAUDE.md, les skills (des instructions réutilisables que Claude charge à la demande), les sous-agents, les hooks, MCP (le protocole qui branche Claude à des outils externes) et le mode sans interface, pensé pour la CI (l'intégration continue, qui lance tes vérifications à chaque envoi de code). Il chiffre aussi ses propres affirmations. Il compte 93 leçons et près de 6 heures de cours. Il vaut surtout si tu utilises déjà Claude Code et que tu veux comprendre le système plutôt que collectionner des astuces.
Le moins bien noté : Agentic Coding (5,4/10), à cause de ses exemples de configuration faux, que je détaille plus bas. Le plus décevant reste pourtant Best Practices for Claude Code (6,0/10). Le critère est autre : l'écart entre ce que le titre promet et ce que le livre contient. Agentic Coding tient sa promesse, un cours qui construit une application, avec ses défauts. Best Practices promet toutes les bonnes pratiques. Je n'y ai trouvé ni sous-agents, ni MCP, ni skills au sens de Claude Code. Les permissions tiennent en une ligne de renvoi, les hooks en un encart. Reste un cours de discipline correct si ton problème est un Claude qui fait bien plus que ce que tu as demandé.
Selon ton profil :
- Tu as une heure et demie et déjà quelques semaines de pratique : 101 Claude Code Tips (53 leçons, 1 h 26). Une bonne partie des conseils tourne autour de la production de contenu (vidéo, tableaux Trello), d'après mon décompte approximatif : tu peux les sauter.
- Tu débutes et tu veux suivre un projet de bout en bout : Agentic Coding construit une application (HookHub) pas à pas. Attention, il contient plusieurs exemples de configuration faux. Vérifie chaque bloc dans la documentation avant de le copier, sinon tu passeras une soirée à chercher pourquoi rien ne marche.
- Tu subis un Claude qui réécrit la moitié de ton code pour une petite demande : Best Practices (44 leçons, 2 h 24).
Ce que les livres sur Claude Code ont en commun, et ce que tu peux en faire
Trois signatures (Jia Huang, Eden Marco, et Zenva pour deux livres sans auteur nommé), deux éditeurs. Que les mêmes idées reviennent prouve peu : ils s'appuient sans doute tous sur la même documentation. Ce qui compte, c'est où ils vont plus loin que la doc et se recoupent. Voici qui porte quoi :
| Idée | Operating Model | 101 Tips | Best Practices | Agentic Coding |
|---|---|---|---|---|
| CLAUDE.md court | oui | oui | oui | une phrase |
| Les hooks garantissent, les prompts non | oui | oui | un encart | montre la mécanique |
| Sous-agents pour le bruit | oui | oui | non | oui |
| Ne pas croire ce que dit le chat | via le hook Stop | oui | oui | non repéré |
Un CLAUDE.md court. Les quatre le disent, plus ou moins fort. Jia Huang donne le test le plus radical. Supprime une règle : si Claude se comporte aussi bien sans elle, elle n'a rien à faire dans le fichier. 101 Tips vise environ 50 lignes et écrit qu'un fichier gonflé fait ignorer les vraies consignes, perdues dans le bruit. Best Practices range le fichier trop long parmi ses pièges. Agentic Coding se contente d'une phrase : garder les fichiers de mémoire concis et précis. Mon fichier faisait 296 lignes avant mon audit, et j'étais donc le contre-exemple des quatre livres à la fois. Il en fait 142 maintenant : encore près de trois fois la cible de 101 Tips, mais sous les 200 lignes que cite Operating Model. À toi de jouer : pour chaque règle de ton CLAUDE.md, imagine-la supprimée. Si Claude se comporte pareil, coupe.
Ce qui doit toujours arriver va dans un hook. Une règle écrite dans le CLAUDE.md reste une consigne que Claude peut mal lire. Operating Model fait dire à Kage, son mentor fictif : « Les hooks, c'est différent : ce ne sont pas des suggestions, mais une obligation » (traduction libre). 101 Tips, plus court : « les hooks garantissent l'exécution, les prompts non ». Best Practices leur consacre un encart. Agentic Coding enseigne la mécanique avec un hook qui joue un son à la fin d'une réponse, sans en tirer ce principe. C'est ce que j'ai fini par comprendre en écrivant mon article sur les hooks : arrêter de répéter « relance les tests » à chaque session, et le confier à l'événement Stop (il se déclenche quand Claude a fini de répondre). Voici le script du tip 48 de 101 Tips, que j'ai raccourci. Remplace bun test par ta commande de tests :
#!/usr/bin/env bash
input=$(cat)
# La garde : sans elle, le hook relance Claude à l'infini
if [ "$(echo "$input" | jq -r '.stop_hook_active // false')" = "true" ]; then
exit 0
fi
if ! bun test --silent >/dev/null 2>&1; then
echo '{"decision":"block","reason":"Les tests échouent, corrige-les avant de conclure."}'
fi
exit 0
Claude Code passe au script un JSON sur l'entrée standard. Quand les tests échouent, le hook renvoie block et Claude doit continuer. La garde stop_hook_active évite la boucle infinie : elle vaut true quand Claude repart à cause du hook, et le script le laisse alors s'arrêter. Operating Model et 101 Tips ont tous deux cette garde.
Un sous-agent sert à lire, pas à économiser. Un sous-agent est une instance séparée de Claude, avec sa propre fenêtre de contexte : seul son message final remonte dans ta conversation. Operating Model, 101 Tips et Agentic Coding l'utilisent pour isoler le bruit. La règle de 101 Tips est la plus nette. Une tâche produit des résultats de recherche, des journaux ou des fichiers qu'on ne reverra pas ? On la lance dans un sous-agent. Le calcul de Jia Huang est le plus honnête de l'ensemble. Sur son exemple, déléguer économise 8 500 tokens sur 125 000, soit 6,8 %. Avec le cache de prompt (le texte déjà envoyé au modèle est refacturé moins cher), il ne reste que 1 à 2 %. Le vrai gain, c'est une conversation principale qui reste lisible. Envoie donc dans un sous-agent tout ce qui produit du bruit : journaux, sorties de tests, recherches.
Le chat n'est pas une preuve. 101 Tips décrit un Claude qui annonce « J'ai lancé bun test, tout est vert » sans avoir appelé l'outil Bash. La narration est fluide, plausible, et fausse. Le remède du livre : lire la vraie sortie de l'outil dans la transcription, pas le résumé. Operating Model arrive au même endroit par un autre chemin, un hook Stop qui lance la suite de tests quand Claude déclare avoir fini. Best Practices pose la meilleure question à poser avant de valider : « Liste tous les comportements qui doivent rester inchangés après cette modification. Explique comment l'implémentation actuelle les préserve. », et résume sa méthode d'une formule : « compiler n'est pas relire ». Je n'ai rien trouvé d'équivalent dans Agentic Coding. Pose cette question avant de valider, et regarde la vraie sortie des outils. Méfie-toi aussi des verbes « refactor », « improve », « clean up » ou « optimize » : Best Practices y voit une permission de redessiner bien plus que ce que tu voulais.
Les erreurs de config à ne pas copier
Un livre sur un outil qui change chaque mois vieillit avant l'impression, et ces quatre-là n'ont pas toujours été relus. Quelques erreurs que j'ai vérifiées.
Le format des hooks. Le tip 48 de 101 Tips montre un hook Stop qui lance les tests. settings.json (le fichier de configuration de Claude Code) attend, lui, autre chose d'après la documentation actuelle : un niveau hooks autour, un champ type, et pas de matchers pour Stop, qui ne les gère pas (un matcher est un filtre sur le nom de l'outil qui déclenche le hook). Je n'ai pas testé ce que Claude Code fait du texte du livre, je constate seulement qu'il diffère de la doc.
// ✗ Ce que montre le livre (tip 48)
{
"Stop": [
{
"command": ".claude/hooks/check-tests.sh",
"matchers": []
}
]
}
// ✓ Le format de la documentation
{
"hooks": {
"Stop": [
{ "hooks": [{ "type": "command", "command": ".claude/hooks/check-tests.sh" }] }
]
}
}
Un fichier sans effet. Operating Model recommande un .claudeignore en première couche pour cacher des fichiers, tout en précisant qu'il peut être contourné, et conseille permissions.deny en seconde couche. La documentation actuelle va plus loin : un .claudeignore n'a aucun effet, et ses entrées doivent devenir des règles Read dans permissions.deny.
Une clé mal écrite. Agentic Coding écrit statusline dans son exemple de settings.json, quarante lignes après avoir parlé de la clé statusLine. La doc ne connaît que statusLine. Je n'ai pas testé ce que Claude Code fait de la version fautive.
Des scripts de sécurité à trous, de deux sortes. Dans 101 Tips, le hook « anti-commandes dangereuses » cherche une chaîne de texte : grep -Eq '(rm -rf|git push --force|…)'. Je l'ai rejoué : rm -rf est bloqué, rm -fr, rm -r -f ou rm suivi de deux espaces passent. Operating Model a d'autres angles morts : son matcher Write|Edit ne couvre pas cat > .env, parce qu'il filtre sur le nom de l'outil et que cat passe par Bash. Il se contredit aussi : il annonce l'auto-compactage à 50 % par défaut dans un chapitre et à environ 95 % dans un autre.
Ma règle : dans un livre sur Claude Code, prends les principes, et va chercher chaque syntaxe dans la documentation officielle.
La parade à l'agent qui recopie tes secrets
Un chapitre d'Operating Model décrit un piège que je n'avais jamais envisagé. Un agent de revue de code tourne dans la CI avec claude -p "Review the configuration for problems" --allowedTools "Read,Grep". On lui demande de vérifier la configuration. Il lit le fichier .env, et il recopie dans le journal de la CI l'URL de la base de données avec son mot de passe et la clé Stripe. Aucune consigne malveillante : il a simplement fait ce qu'on lui demandait. Le masquage automatique des secrets de GitHub, lui, ne couvre pas le texte écrit par le modèle.
La parade tient en deux réflexes. Le premier : interdire la lecture des fichiers sensibles dans les permissions (.claude/settings.json), avec la syntaxe de la documentation actuelle :
{
"permissions": {
"deny": ["Read(./.env)", "Read(./secrets/**)"]
}
}
Ajoute les variantes que tu as (.env.local, par exemple). La doc précise que ces règles couvrent les outils de lecture de Claude et des commandes comme cat, mais pas un script Python qui ouvre le fichier lui-même : pour une barrière qui tient contre tout processus, il faut activer le bac à sable (sandbox). Le second réflexe est une règle de prompt, pas de configuration : ne jamais demander à un modèle de lire ou d'afficher une variable d'environnement. Le livre le dit en toutes lettres.
Dans le même chapitre, une idée simple pour faire échouer une CI sur l'avis de Claude : lui faire écrire une ligne sentinelle, et chercher cette ligne exacte. Le prompt demande de terminer la revue par <VERDICT>request_changes</VERDICT> ou <VERDICT>approved</VERDICT>, le workflow du livre écrit la réponse dans review.md, puis :
if grep -qF "<VERDICT>request_changes</VERDICT>" review.md; then
Chercher le mot « critical » dans la réponse serait pire : il apparaît aussi dans « no critical issues ». Dernier geste, tout de suite : ouvre ton settings.json et vérifie que ton .env est dans permissions.deny.
Conclusion
Les livres insistent sur beaucoup de choses. Celle que j'ai le plus vécue : ne pas croire ce que Claude annonce. Aucun résumé d'agent n'est passé sans que je repasse par le script.
Le livre que je conseille a une qualité rare : il chiffre ses propres affirmations, même quand le chiffre dessert son sujet. Jia Huang vante les sous-agents, calcule 6,8 % d'économie puis 1 à 2 % avec le cache, et l'écrit. Son livre n'est pas sans erreurs, loin de là, mais ce réflexe vaut plus que ses syntaxes. Si tu n'en lis qu'un, lis celui-là, avec la documentation ouverte à côté.