Claude Code, mon geôlier très compétent

Bonjour, je m'appelle Thomas. Je suis développeur depuis une bonne quinzaine d'années. Et ça fait plusieurs mois que je n'ai plus envie de coder le soir.

Je sais que certains d'entre vous vont reconnaître ce que je décris. On parle beaucoup de ce que l'IA va changer dans notre métier. On parle moins de ce qu'elle a déjà changé en nous.

Ce que j'ai du mal à dire

Je n'ai plus envie (ou beaucoup moins) de lancer un side project. Je ne m'arrête plus sur un problème intéressant. Le week-end, sur mes heures creuses j'ouvrais mon IDE (Neovim FTW!), maintenant je cours et je lis. Alors j'aime ça courir et lire, ce n'est pas le problème. Le problème, c'est que je ne me suis même pas rendu compte que j'avais arrêté de coder (en loisir, je parle).

Ce n'est pas un burnout, ce n'est pas non plus un changement de carrière. C'est comme un musicien qui aurait toujours son instrument mais qui ne jouerait plus chez lui. Le geste professionnel est intact mais l'envie personnelle s'est éteinte.

Pendant longtemps je n'ai pas su nommer ça. Je me disais que je vieillissais, que c'était normal, que la passion s'use. Et puis j'en ai parlé avec d'autres développeurs - dix ans, quinze ans, vingt ans de métier - et j'ai vu le même regard. On se reconnaît sans avoir besoin de beaucoup s'expliquer. Ça m'a soulagé et ça m'a inquiété en même temps.

Le même outil, deux effets opposés

L'ironie est saisissante. Les LLM ont rendu la programmation accessible à des gens qui n'auraient jamais écrit une ligne de code. Un designer lance un prototype fonctionnel en quelques prompts. Un entrepreneur teste une idée sans embaucher. Un chercheur automatise son pipeline de données en une après-midi. Pour eux, c'est une libération. Je vois des non-développeurs dans mon entourage faire des choses qu'ils n'auraient jamais osé tenter il y a deux ans, et c'est sincèrement réjouissant.

Mais pour moi - et je pense pour beaucoup d'entre nous ici - l'expérience est radicalement différente. Ce que je faisais en trois heures avec concentration et satisfaction, je le fais désormais en vingt minutes en supervisant une sortie de LLM. C'est plus rapide, plus efficace, et étrangement... vide.

Le problème n'est pas l'outil. Je les utilise tous les jours et je n'ai aucune intention d'arrêter. Le problème, c'est ce que l'outil a changé dans la nature de mon activité.

De bâtisseur à contrôleur qualité

Avant les LLM, coder un composant, c'était construire. Je partais d'une page blanche, je posais une structure, je résolvais des problèmes un par un, je voyais la chose prendre forme sous mes mains. L'effort faisait partie du plaisir - c'était même, rétrospectivement, l'essentiel du plaisir.

Avec un LLM, coder ce même composant, c'est réviser. Je décris ce que je veux, je reçois une proposition, je relis, je corrige, j'ajuste le prompt, je re-relis. L'activité a basculé de la création vers le contrôle. Je ne suis plus l'artisan - je suis le chef de projet d'un stagiaire extrêmement rapide et parfois brillant, mais dont il faut toujours relire le travail.

Je peux le dire ici, devant vous, parce que je pense que vous comprenez : je n'ai pas choisi ce métier pour relire le travail de quelqu'un d'autre.

Le voyage, pas la destination

Richard Feynman avait cette expression : the pleasure of finding things out. La joie de la découverte. Pas la joie d'avoir découvert - la joie de découvrir, au présent, dans l'acte même de chercher.

Quand je regarde en arrière, mes meilleurs souvenirs de développeur ne sont pas des mises en production réussies. Ce sont des moments de compréhension. Ce bug que j'ai mis une journée à traquer et qui m'a appris quelque chose de fondamental sur le système. Cette architecture que j'ai refaite trois fois avant de trouver la bonne. Ce moment à 23h où un test passe enfin et où je comprends non seulement le comment, mais le pourquoi. La destination, je l'ai oubliée. Le voyage, je m'en souviens encore.

Est-ce que c'est pareil pour vous ?

Les LLM compriment le chemin entre l'intention et le résultat. Pour beaucoup de tâches, c'est exactement ce qu'on veut - et je suis le premier à apprécier quand Claude Code me génère du boilerplate ou me débloque sur une API que je ne connais pas.

Mais la joie de coder n'a jamais résidé dans le résultat. Elle résidait dans le chemin. Dans cette heure passée à comprendre pourquoi ça ne marchait pas. Dans le moment où la solution apparaît - non pas parce qu'on l'a demandée, mais parce qu'on l'a construite, neurone après neurone, en suivant un fil logique jusqu'au bout.

Les LLM donnent la destination. Ils escamotent le voyage. Et avec le voyage, ils escamotent la raison pour laquelle la plupart d'entre nous ont commencé.

Le flow, ou ce qu'on a perdu sans le nommer

Le psychologue Mihaly Csikszentmihalyi a passé sa carrière à étudier ce qu'il appelle le flow - cet état de concentration absolue où le temps disparaît, où l'on est entièrement absorbé par ce qu'on fait. Ses recherches montrent que le flow est la source la plus fiable de satisfaction profonde. Pas le succès, pas la reconnaissance, pas le résultat - l'état lui-même.

Il identifie plusieurs conditions nécessaires : un objectif clair, un niveau de difficulté calibré - assez dur pour engager, pas assez pour paralyser, un feedback immédiat. Et un trait moins cité mais central : l'activité doit être autotélique (oui j'ai découvert ce terme en allant sur sa fiche wikipédia) - pratiquée pour elle-même, pas pour son résultat. L'alpiniste ne grimpe pas pour être en haut. Le musicien ne joue pas pour la dernière note. Le développeur - du moins, celui qui a connu cette joie - ne code pas pour le commit final.

En y repensant, je réalise que ce que j'appelais vaguement "passion pour le code" avait en fait des conditions très précises. Et les LLM sont venus perturber chacune d'entre elles.

L'objectif clair ? Remplacé par un prompt qu'on reformule jusqu'à obtenir quelque chose d'acceptable. Le calibrage de la difficulté ? Effondré - la plupart des problèmes deviennent triviaux à résoudre, même s'ils restent difficiles à spécifier. Le feedback immédiat ? Transformé en attente d'une génération, puis en relecture. Et le caractère autotélique ? Détruit. Quand l'outil promet d'aller plus vite vers le résultat, tout l'implicite pousse à optimiser pour la destination, pas pour le voyage.

Je n'ai pas perdu ma passion. J'ai perdu les conditions du flow. Et le flow, c'était le moteur silencieux de cette passion.

Ce que sait la main

Richard Sennett, dans son essai sur l'artisanat, décrit un phénomène qu'il observe chez les souffleurs de verre, les luthiers, les menuisiers : la satisfaction naît de la résistance du matériau. Le bois a ses nœuds, le verre casse si on force. C'est cette résistance qui oblige l'artisan à s'adapter, à progresser et c'est là qu'il trouve du sens. Retirez la résistance et vous retirez le sens.

Le code a toujours été mon matériau. Ses contraintes - la logique stricte, les cas limites, les bugs incompréhensibles - étaient ma résistance. C'est contre cette résistance que j'ai construit ma compétence pendant 17 ans. C'est dans cette friction que je trouvais le plaisir.

Les LLM aplanissent cette friction. Pas complètement - il en reste, sous d'autres formes. Mais suffisamment pour que l'activité change de nature. Et quand l'activité change de nature, le fait que le résultat soit le même ne suffit pas. L'artisan ne cherche pas le meuble. Il cherche le geste.

Le syndrome de Stockholm du développeur

Et voilà la partie la plus dure à avouer.

Je ne peux pas m'en passer.

Je viens de passer plusieurs paragraphes à vous expliquer que les LLM ont détruit les conditions de ma joie - et je les utilise tous les jours, pas à contrecœur mais volontairement, parce qu'un développeur qui livre en trois jours ce qu'un autre met deux semaines à produire garde ses clients. Parce que le marché ne récompense pas le voyage - il récompense la destination.

Il y a un nom pour ça en psychologie quand on développe une forme d'attachement pour ce qui nous contraint, quand on finit par défendre ce qui nous diminue parce qu'on ne voit plus d'alternative viable, vous connaissez bien-sûr: c'est le syndrome de Stockholm. C'est excessif, bien sûr. Claude Code ne me séquestre pas. Mais la dynamique a quelque chose de familier : je sais que cet outil m'a pris une partie de ce qui me rendait vivant dans mon métier, et malgré ça, la première chose que je fais le matin, c'est l'ouvrir.

Le plus pervers, c'est que l'outil est réellement bon. Ce n'est pas un geôlier cruel - c'est un geôlier compétent. Il m'aide, me fait gagner du temps, m'apprend des choses. Et c'est exactement ce qui rend la situation si difficile à démêler. On ne quitte pas quelque chose qui fonctionne. On s'adapte, on négocie, on trouve des arrangements.

Retrouver le chemin

C'est ce que j'essaie de faire - négocier. Je ne suis pas en train de plaider pour abandonner les LLM. Ce serait absurde, et ce n'est pas ce que je fais. La question n'est pas "faut-il les utiliser" - c'est "comment préserver des espaces où le voyage compte encore, à l'intérieur même d'un quotidien où l'outil est omniprésent".

J'ai trouvé quelques réponses, imparfaites. Je vous les donne pour ce qu'elles valent - comme on partage un truc qui marche un peu, sans promettre que ça marchera pour tout le monde.

Garder un espace sans assistance. Pas par purisme - par égoïsme. Parce que la satisfaction de résoudre un problème soi-même est irremplaçable. Un side project, un kata, l'Advent of Code, une contribution open source - n'importe quoi où l'on s'interdit délibérément l'aide, non pas parce que l'outil est mauvais, mais parce que l'effort est le but.

Penser avant l'outil. C'est peut-être le plus inattendu : je n'ai jamais autant sorti mon stylo et mon carnet que depuis que j'utilise Claude Code. Avant de lancer un prompt, je griffonne : un schéma d'architecture, une ébauche d'UI, un flux de données. Je me force à imaginer comment je ferais avant que la machine me propose sa version.

Soyons lucides : c'est parfaitement ridicule. Je dessine un schéma sur du papier pour ensuite le donner à une IA qui aurait pu le produire en trois secondes. Le résultat final est le même. L'architecture ne sera pas meilleure parce que je l'ai d'abord gribouillée au Bic. Et à la fin, c'est quand même Claude Code qui écrit le code.

Mais c'est exactement le point. La résistance n'est pas dans le résultat - elle est dans le moment. Si je laisse le LLM proposer en premier, mon cerveau passe en mode évaluation. Le schéma que j'aurais pu inventer, je ne le trouverai plus - je comparerai. Le carnet ne change pas la destination. Il préserve le voyage. C'est ma façon de rester l'auteur cinq minutes de plus avant de devenir le relecteur. Ces cinq minutes-là, elles sont précieuses.

Choisir des outils qui raccourcissent la boucle sans court-circuiter la réflexion. Un REPL, du hot-reload, un environnement interactif - ce qui distingue ces outils du LLM, c'est qu'ils accélèrent le feedback sans retirer l'effort cognitif. Ils rendent le voyage plus fluide, pas plus court. La différence est immense.

Se remettre en position de débutant. Le flow exige un équilibre entre compétence et difficulté. Si les LLM ont rendu votre zone de compétence trop facile, déplacez la zone - un nouveau langage, un paradigme différent, un domaine technique qu'on ne connaît pas. J'ai retrouvé une partie de cette joie en apprenant des choses que Claude Code ne pouvait pas faire à ma place - pas parce qu'il en était incapable, mais parce que c'était moi qui avais besoin de comprendre.

Accepter que le plaisir soit un objectif légitime. La culture tech valorise la productivité, le shipping, le résultat. Dire "je fais ça parce que ça me plaît" ressemble à un luxe ou à un manque de sérieux. Mais c'est pourtant ce qui a construit les meilleurs développeurs que je connais - des gens qui ont codé pendant des années, le soir, pour rien, juste parce qu'ils aimaient ça. Ce n'était pas de la productivité. C'était de la joie. Et la joie mérite d'être défendue.

Pourquoi je vous raconte tout ça

Parce que pendant des mois j'ai cru que c'était juste moi. Que je vieillissais. Que je perdais le feu. Et j'ai réalisé que non - les conditions avaient changé, pas moi. La joie que j'ai perdue avait un nom - le flow - et des mécanismes précis. Ces mécanismes ont été perturbés par un changement d'outils, pas par un changement en moi.

Si vous êtes ici, c'est peut-être que vous ressentez quelque chose de similaire. Que vous aussi, vous sentez quelque chose s'éteindre doucement sans savoir exactement quoi. Je ne sais pas si ce que j'ai partagé va vous aider. Mais au moins, on sait qu'on n'est pas seuls.

Le voyage n'a pas disparu. Il faut juste le chercher un peu plus délibérément qu'avant.

Merci de m'avoir lu.