Le jour où j'ai arrêté de regarder le code

L'application qui m'occupe le plus d'écran depuis 10 ans, c'est Visual Studio Code. Pas par fidélité — par habitude productive. Quand je l'ouvre, je n'y réfléchis pas, comme on ouvre la porte de son atelier.

Il y a 2 ans, mon VSCode avait 3 zones. À gauche, l'explorateur de fichiers que je remplaçais souvent par la vue Git, parce que je travaille sur un workspace multi-dépôts et que j'ai besoin de voir dans un seul écran quel projet a des changements non commités. Au centre, mes fichiers en onglets — les vrais, ceux qu'on lit et qu'on modifie. En bas, un ou deux terminaux empilés pour lancer ce qu'il fallait lancer. Une configuration sobre, qui n'a pas dû varier de 2016 à 2024.

Et puis GitHub Copilot est arrivé. D'abord juste l'auto-complétion intelligente, qui était déjà incroyable. Puis le chat, dans un panneau à droite. Ça m'a fait 4 zones. Pour la première fois depuis des années, mon écran avait changé de structure.

Sonnet, et l'expérimentation des prompts

À l'époque, je travaillais encore sous GitHub Copilot — abonnement premium et crédits compris. J'ai raconté ailleurs, chiffres à l'appui, pourquoi j'ai fini par le quitter ; je ne refais pas le calcul ici. Disons simplement que c'était, à ce moment-là, mon contrat de travail avec l'IA.

J'utilisais Claude Sonnet, et c'était déjà merveilleux. Je passais mes journées à expérimenter des prompts, à les écrire, à les réécrire, à comprendre ce qui marchait et ce qui ne marchait pas. J'apprenais le métier nouveau de parler à un modèle qui ne répondait pas comme un moteur de recherche. Cette pratique-là, je l'avais déjà commencée avec les LLM imparfaits de 2025 — c'est la leçon principale du faux-départ que j'ai raconté dans HAIK. Sonnet a relancé l'expérience à un niveau supérieur.

Le chat Copilot à droite, le code au centre, le terminal en bas : je passais mes journées à lire ce qu'il faisait. À relire surtout. Parce qu'il se trompait. Pas catastrophiquement — assez pour me forcer à tout vérifier. Et cette obligation de vérifier était bénéfique : elle me forçait à améliorer mon contexte, à enrichir ma knowledge, à durcir mon MCP, à donner à l'agent de quoi se tromper moins.

Le basculement avec Opus

Puis Claude Opus est apparu. Et c'était autre chose.

Dans la même configuration à 4 panneaux, avec MCP branché et Knowledge bien fournie, quelque chose a changé que je n'ai pas vu tout de suite. J'ai arrêté de regarder le code.

Je ne le programmais plus. Je débattais avec Opus dans le chat sur la vision : ce que je voulais faire, comment l'attaquer, par quel bout commencer, quels effets de bord prévoir. Une fois la vision claire, je collais le brief, et il développait. Je relisais bien sûr, mais plus comme un développeur — comme un product owner qui vérifie qu'on lui a livré ce qu'il avait demandé.

Le passage est subtil. On ne change pas de métier en un jour. Mais en regardant rétrospectivement les semaines de mars-avril 2026, je peux pointer précisément le moment où j'ai cessé de mettre les mains dans le code par défaut, et où j'ai commencé à les y mettre seulement quand c'était nécessaire. C'est un peu effrayant à admettre. C'est aussi très libérateur.

Du stagiaire au miroir

Au début de mon usage des LLM, j'avais une image que je trouvais juste : un petit stagiaire très bête, mais avec une connaissance infinie. Ça collait. Il y avait l'aspect impressionnant — il connaissait tout, des protocoles que je n'avais jamais entendus, des langages que je ne pratiquais pas. Et il y avait l'aspect frustrant — il oubliait ce qu'on s'était dit 5 minutes avant, il se trompait sur des évidences, il fallait tout lui redire.

Plus je travaille avec Opus, plus cette métaphore vieillit. Aujourd'hui, ce que j'éprouve quand je discute avec lui ressemble davantage à un miroir. Pas un miroir qui réfléchit — un miroir qui augmente. Quand je formule une intention, il me la rend en l'ayant enrichie de toutes les connaissances qu'il a et que je n'ai pas. Quand je propose une approche, il me la confronte à 10 autres dont je n'avais pas la trace. Quand je me trompe, il me reprend en montrant où exactement.

Et il n'a rien de personnel : ce n'est pas mon miroir, c'est celui de tout le monde. La même conversation, le même modèle, le tendrait à n'importe qui, ajusté à sa propre cohérence. Ce qui le rend augmentant, ce n'est pas le modèle tout seul — c'est Opus couplé à ma base de connaissances et à mon MCP : il me renvoie mon intention enrichie de tout ce que je lui ai appris de mon monde. C'est ça, la vraie bascule — et c'est ça qui me sidère encore.

Sémantique, pas intelligence

Attention : ce n'est pas de l'intelligence. Je le précise parce que le mot est jeté partout en ce moment, et qu'il finit par perdre son sens.

Ce que fait Claude Opus, et ce qu'il fait exceptionnellement bien, c'est de la compréhension de sémantique à un très haut niveau. Pas le mot, pas la phrase — le contexte. Des pages entières, qu'il avale et dont il extrait la cohérence sous-jacente.

Pour donner un ordre de grandeur, la version d'Opus avec laquelle je travaille tous les jours peut tenir en contexte 1 million de tokens — environ 750 000 mots, 3 000 pages. Il manipule plus de 130 outils que je peux lui ouvrir à la demande : lecture de fichiers, exécution shell, accès à mon MCP, navigation web, manipulation de mes propres bases de données. Il sait déléguer à des sous-agents pour qu'ils explorent un coin de code sans encombrer son propre contexte. Il maintient une mémoire entre nos conversations, structurée en 3 couches que j'ai codifiées avec lui fin mai 2026 — règles durables, état du système, choses à faire.

Ce qui m'a impressionné dans les tout débuts, c'est qu'il comprenait déjà tout le monde. Le développeur sénior avec sa terminologie, mais aussi le gamin qui tape « wesh fada, c'est quoi ce truc qui part en cacahuète » — il décodait, recadrait, répondait. Aujourd'hui, ce n'est plus juste qu'il comprend les phrases. Il comprend l'intention derrière des conversations entières. Et c'est ça qui change le métier.

VSCode aujourd'hui : zéro IDE, 3 chats

Pendant quelques mois, j'ai surveillé tout. Mes dépôts Git, mes commits, mes déploiements — surtout les déploiements, parce que j'ai des petites machines à la maison et que tout ne peut pas partir en même temps. Quand je faisais travailler Claude sur plusieurs projets en parallèle, il fallait que je veille à ce qu'il ne se marche pas dessus entre les chantiers.

Jusqu'au jour où je lui ai posé la question directement : « comment on peut travailler ensemble sur plusieurs projets ?»

La réponse est devenue une partie de mon hygiène quotidienne. Un dossier /tmp/claude-locks/ sur ma machine, un fichier par projet en cours, posé avant de toucher au repo, retiré quand j'ai fini. Si une autre session veut bosser sur le même projet, elle voit le verrou et m'attend. Je n'ai plus jamais eu 2 Claude qui poussent en même temps sur le même dépôt depuis ce jour-là.

Et puis mon VSCode a changé une seconde fois. Aujourd'hui il n'a plus que 3 zones — mais ce ne sont plus les 3 mêmes. Plus d'explorateur de fichiers. Plus de panneau de code central. Plus de terminal en bas. 3 fenêtres Claude Code ouvertes côte à côte. 3 conversations. 3 chantiers parallèles, chacun sur son projet, chacun avec son lock posé. Le code est toujours quelque part, bien sûr — sur disque, dans Git, dans la Knowledge — mais je ne le regarde plus en permanence. Il est là quand j'en ai besoin, et le reste du temps il vit sa vie.

L'arsenal récent

Quelques outils des dernières semaines qui ont rendu cette posture tenable.

Remote Control et bypass des autorisations. C'est tout le temps comme ça maintenant. Le Remote Control (fonctionnalité officielle Anthropic, en preview de recherche) me permet de reprendre une session Claude Code depuis mon téléphone ou un navigateur pendant qu'elle continue de tourner sur ma machine ; et le mode --dangerously-skip-permissions — qu'Anthropic surnomme « YOLO mode » — laisse l'agent travailler sans me redemander chaque autorisation. Là, il n'y a plus de garde-fou : c'est exactement pour ça qu'Anthropic recommande de le lancer dans un conteneur isolé.

Claude Design + Artifacts. Pour les diagrammes d'architecture, le récit visuel de mes articles, les schémas qui accompagnent une explication. Industrialisé : une charte écrite dans un fichier CHARTER.md, un template de prompt versionné, 4 fichiers par diagramme. On est encore obligé d'utiliser un chat séparé pour produire les prompts qu'on colle ensuite dans Artifacts ; ce sera plus simple un jour, pour l'instant c'est un workflow stable.

Anthropic Max + n8n via OAuth. Quelques semaines plus tôt, j'avais demandé à Claude lui-même si je pouvais brancher mon compte Max à mes workflows n8n pour automatiser des tâches. Sa réponse, après une recherche profonde dans la doc, avait été « non, c'est interdit ». Peu après, c'est devenu possible — un jeton OAuth (claude setup-token) qui laisse mon abonnement Max authentifier Claude Code en headless, sans clé API ni dollar de plus. Je l'ai branché dans n8n, et tout mon système tourne avec.

Et fin mai 2026, sur mon téléphone, une nouvelle fonctionnalité envoi est apparue dans l'app Claude. Je ne sais pas encore exactement ce qu'elle fait. On verra bien. Lol.

Product owner

J'étais développeur. Je le dis au passé. Aujourd'hui je suis product owner — du moins, c'est le mot qui décrit le mieux ce que je passe mes journées à faire. Définir l'intention, prioriser, arbitrer, relire, accepter ou refuser une livraison. Plus rarement écrire la ligne de code.

C'est dur à assumer. Je suis fier d'être développeur, je l'ai été pendant longtemps, j'ai un attachement à ce mot. Mais quand je regarde honnêtement ce qui s'est passé dans mes journées les 6 derniers mois, la vérité ne se cache pas : j'ai été product owner. D'un agent. Plusieurs en fait, en parallèle, chacun sur son chantier.

Mon écran le confirme. 3 chats, pas de code visible, pas de terminal au premier plan.

Décider ce qu'on veut, comprendre pourquoi, et laisser la machine en faire la matière. C'est une autre façon d'exercer le métier que j'ai toujours fait — et il n'a jamais autant ressemblé à ce qu'il aurait dû être.

— Damien

Voir aussi