Notes sur Claude Code

J'ai testé Claude Code, et j'ai pris ces notes à cette occasion.

Disclaimer : ce sont mes notes sur un projet greenfield de 2000 lignes de code écrit en deux jours environ. Ces notes ne sont pas généralisables.

Note au passage : si ce genre de sujets vous intéresse et que vous souhaitez avoir une vision globale autours de ces questions, la conf "L'humanité a-t-elle les moyens de s’offrir l’IA ?" de Tristan Nitot à la School of Product 2025 est très bien.

• L'humanité a-t-elle les moyens de s’offrir l’IA ?

Mes notes

Flow

Good : aucune difficulté de prise en main pour un dev senior. On comprend la plupart des choses faites par l’outil, on peut lire les commandes shell utilisées. Impression : peu ou pas de courbe d’apprentissage quand on connait bien le métier de dev, le shell, les tests, les patterns.

Good : je dis à l’outil de faire, c’est l’outil qui tape. Super reposant. Les changements fatigants et rébarbatifs deviennent plaisants car c’est l’outil qui tape. On peut aller beaucoup plus loin en terme de qualité, la facilité d’usage enlève les freins à l’action. Déléguer le clavier et les implémentations bas niveau nous laisse aussi plus d’énergie pour le nommage et les améliorations. Mais : voir aussi risque d’addiction dans la section warnings ci-dessous.

Agents & Craft

Flow qui fonctionne : faire de petites étapes, tester et commiter à chaque fois. Good : l’outil lance automatiquement les tests qu’il trouve pour vérifier ce qui est tapé, et en génère sur le modèle de ce qui existe. C’est très compatible TDD, on peut appliquer tout ce qu’on sait faire : un changement complexe rendu super simple par une succession de petites étapes super safes. Je dirais même plus, dans mon essai, guider l’outil par une succession de petites étapes claires a donné des résultats remarquables. J’ai eu quasiment systématiquement ce que j’ai demandé, fait correctement et exécuté en 15 s. à 30 s. environ (note : mesures réelles à faire). Il est donc sans doute mieux de guider à la Craft que de faire une spec géante de haut niveau ? IMHO, Craft FTW!

Toujours garder un œil sur la taille des fonctions, sur la structure : l’outil peut les améliorer, il peut même auditer la base de code, trouver les défauts et les corriger, mais il ne le fera pas de lui même si on ne lui demande pas. Il est aussi intéressant de guider la correction des défauts en donnant des directives de haut niveau (niveau archi logicielle). Craft, Boyscout Rule, DRY, YAGNI, etc., à nous de guider.

De mon expérience, les réflexes des crafteux·ses restent très pertinents : le cycle "fait ce changement, vérifie le, simplifie ceci, fait cet autre changement, vérifie le, simplifie cela", etc. permet de garder le contrôle sur la qualité de ce qui est produit tout au long du dev. Ce qui veut dire qu'à tout moment on peut livrer. Plutôt que de lui donner une spec géante, puis de passer beaucoup de temps a simplifier un truc devenu trop énorme et ingérable, et puis on doit livrer donc tant pis et la simplification passe à la trappe.

Voir les warnings sur le prix ci-dessous, car tout ça incite à une utilisation de l’outil “open bar”.

Agents & vérifications automatiques

Intéressant : l’outil utilise beaucoup GNU CoreUtils, un peu ce que j’aurais fait. Par ex. fait un `grep -rl "'"` au début pour trouver les fichiers à modifier, et à la fin pour vérifier que tout est modifié. Peut utiliser `grep -rn "'"` pour trouver les lignes à éditer. Utilise aussi régulièrement `find` et `sed`. C’est des choses qu’on peut faire nous aussi, autant apprendre ça en passant. D’autant que si vous avez un historique de shell un peu long, vous pouvez réutiliser ce genre de commandes et ne pas les retaper à chaque fois.

Opportunités : quand l’outil vérifie le résultat de ce qui est tapé, c’est automatiquement, on voit des appels shell. Donc on peut lui dire “sauve cette vérification dans un script de test”, ou dans un script d’analyse. Ça c’est cool car ensuite on peut lire le script de test, le comprendre, et l’utiliser soi-même ou l’intégrer dans les suites de tests autos.

Docs

Good : Ajouter une ADR? Super facile, enlève toute friction. L’outil la rédige au bon endroit, à partir d’une analyse ou d’un commit.

Question : dans les revues, l’outil semble répéter ce qu’il a rédigé dans les commits (?)

Good / Meh : génère des docs de 500 lignes tout seul. Les docs sont de bonne qualité en général, et l’outil peut les mettre à jour à la demande, voir met à jour à l’occasion d’un changement (non systématique). Tendance à dupliquer, des infos se retrouvent dans plusieurs docs voir dupliquées dans le même doc. Lors des mises à jour, ne met pas toutes les duplications à jour. Aussi, vérifier tous les numéros de section, qui sont souvent bons mais pas tout le temps. Et vérifier tous les chiffres, on voit des témoignages de données inventées. Fournir des outils pour générer les chiffres. Autre point : quand on lui demande de mettre à jour plusieurs fois une doc, au bout d’un moment la doc devient saturée d’infos. Et quand on demande à l’outil de refaire la doc from scratch, la doc résultat est toujours bonne, mais change sur plusieurs aspects (sections différentes, ou notation sur 10 qui devient sur 5 ou l’inverse).

Conséquence : d’un côté les docs générées incluent plein d’infos utiles qu’on n’aurait pas pensé à inclure, mais si on veut des docs avec les infos les plus importantes bien visibles, sans redondance et avec le bon niveau d’information, ça demande pas mal de travail de simplification et de restructuration.

Warnings

Meh : commit régulièrement tout seul au bout d’un moment alors que j’ai mis dans la conf de toujours demander avant de commiter.

Pb : très addictif, on n’arrive plus à s’arrêter d’autant qu’il y a un genre d’”émulation”, comme l’outil ne faiblit pas on est amené à continuer sans cesse par mimétisme (c.f. article récent sur le risque de burnout avec ce genre d’outil).

Warning : on n’a plus envie de se mettre à réfléchir sur le “how”, on est addict au “what”, surtout sur les petits nettoyages barbants ou les nouvelles évolutions. On s’entraine à ne plus faire les tâches barbantes, qui sont perçues comme encore plus barbantes.

Warning : on a tendance à dégainer l’outil dès qu’on doit réfléchir plus de 3 secondes. Risque fort de perte de compétence / syndrome d’imposteur auto réalisant. ⇒ continuer à faire régulièrement soi-même des tâches difficiles qui nécessitent de réfléchir longtemps et avec risque d’erreur et de tâtonnement si on veut ne pas perdre la main.

Quand on fait des changements en dehors de l’outil, l’outil les rate parfois (sans doute une histoire de cache). Au bout de plusieurs fois on a envie de tout faire depuis l’outil, donc d’utiliser l’outil encore plus.

Prix = ??? facile de dépenser $ 50 à $ 100 par jour avec l’API Amazone Bedrock (si la commande /cost fonctionne). C’est cette utilisation “open bar” qui est “efficace”. Si j’ai bien vu, un usage de l’outil un peu efficace est de l’utiliser tout le temps. S’il faut se restreindre, avec par exemple des temps de “refroidissement” pour attendre que notre crédit ou quota se recharge, on va avoir tendance à faire du stop and go qui pourrait être contre productif.

Warning : la longueur de réflexion semble augmenter avec la taille du projet, mais je ne l’ai utilisé que sur ~2000 lignes de code.

Warning : il y a un côté Reine rouge. Le système induit par l’outil nous invite à courir de plus en plus vite pour rester au même endroit, alors que certains processus de pensée nécessiteraient de faire une pause pour corriger la direction. Par exemple, est-ce que je suis en train de faire la bonne chose ? Est-ce que je suis en train de la faire de la bonne façon ? Quel est le but que faire cette chose me permet d’atteindre ? Est-ce que ce but est raisonnable ? Si on n’a jamais le temps d’avoir ce genre de réflexions, on risque d’être très efficace pour apporter la bonne solution au mauvais problème. Avec ces outils qui accélèrent, charge à l’individu de s’astreindre à faire des pauses, et à laisser à sa pensée le temps de mûrir s’il veut résister à l’injonction d’emballement. Charge à l’individu de cadrer son propre usage de l’outil. Or, en règle général, le système mange l’individu au petit déjeuner. Remember, fix the system, not the people.

Note : Mon premier réflexe à été de me dire que j’avais “gagné du temps”. Or IMHO on ne “gagne” pas de temps, i.e. on n’économise pas de temps de travail. Le temps “libéré” n’est pas libéré, il est utilisé à faire plus, par peur de la compétition, à tort ou à raison. Donc au mieux on fait beaucoup plus en le même temps, voire on travaille plus de temps qu’avant par effet d’entrainement. Un genre d’effet rebond ?

Voir aussi :

• https://hbr.org/2026/02/ai-doesnt-reduce-work-it-intensifies-it
• https://techcrunch.com/2026/02/09/the-first-signs-of-burnout-are-coming-from-the-people-who-embrace-ai-the-most/

---

Bonus : Explorer les commandes utilisées par Claude

Comme l'outil garde les conversations dans des fichiers jsonl, je les ai explorés avec jq vite fait. On peut donc apprendre à faire comme Claude.

Outils les plus utilisés

Par exemple, je peux voir quels outils il utilise le plus, sur une journée environ, sans surprise le top 10 (make because j'ai fait du C ce jour là), GNU CoreUtils est très utilisé :

$ find ~/.claude/projects/-some-path/ -type f \
    | xargs jq -f jclaude.jq | cut -d' ' -f1 | sort | uniq -c | sort -n
      1 "awk
      1 "./build/convert"
      1 "ctags
      1 "perl
      1 "pwd"
      1 "rmdir
      1 "scripts/analyze-function-lengths.sh
      2 "~/bin/gemtext_to_html
      2 "./scripts/analyze-function-lengths.sh"
      2 "touch
      2 "tree
      3 "chmod
      3 "rm
      3 "./scripts/test_dependency_tracking.sh"
      4 "./build/gemtext_to_html_example
      4 "./scripts/test_convert.sh"
      5 "cloc
      7 "mkdir
      8 "./scripts/analyze-function-lengths.sh
     14 "cat
     14 "find
     14 "ls
     18 "wc
     26 "./build/convert
     27 "echo
     31 "grep
     32 "sed
    227 "make
    473 "git

Script jclaude.jq pour filtrer le jsonl :

.message?.content?[]?
| select(.type? == "tool_use")
| .input?.command?
| select( . != null)

Lister les usages de sed

Commande :

Ensuite, toujours avec jq, j'ai exploré les commandes sed et find pour piquer des astuces, mais de ce que j'ai vu c'est du classique, `sed -i` ou `find ... | exec ...`. Le pattern simple mais sympa que j'ai trouvé et qui ressemble à ce que je fais, c'est :

• faire un `grep -rn toto` pour visualiser l'étendue du changement
• faire un `grep -rl toto | sed -i 's/toto/tata'` pour faire le changement
• faire un `grep -rn toto` à nouveau pour vérifier le changement
• of course, lancer les tests pour vérifier qu'on n'a rien cassé.

Commande bash:

$ find ~/.claude/projects/-some-path/ -type f \
    | xargs jq -r -f jclaude.jq

Script jclaude.jq :

.message?.content?[]?
| select(.type? == "tool_use")
| .input?.command?
| select( . != null)
| select( . | startswith("sed"))
| "\(.)\n"