Claude Code : retour au terminal

Le buzz

Impossible de passer à côté sur X ces dernières semaines : tout le monde parle de Claude Code. Les développeurs s'extasient, partagent leurs captures d'écran, leurs setups tous plus fous les uns que les autres. Claude Code, c'est installer un LLM dans votre ordinateur, brancher un cerveau sur votre kernel, si vous voulez. On rentre dans un répertoire, on tape claude et c'est parti : vous n'êtes plus seul(e), vous collaborez littéralement avec l'ordinateur.

C'est aussi spectaculaire à vivre que difficile à retranscrire.

J'utilisais Cursor depuis des mois. J'ai hésité un petit moment. Retourner au terminal ? Vraiment ?

Oui.

L'ère Cursor

J'ai déjà parlé de Cursor ici : c'est un outil puissant qui a transformé ma façon de coder. Le contrôle visuel, la transparence du code généré, l'intégration IDE, l'indexation du code source, les rules, le choix du modèle — tout était là. Mais il y avait deux problèmes de fond : le coût et la difficulté de traiter des tâches complexes (limite de contexte).

Avec Cursor, utiliser Opus (le modèle le plus puissant de Claude) devenait vite une hémorragie. 20 dollars en deux jours, facile. Cursor a cette tendance à devenir vite glouton. Si on ne le cadre pas, il va très vite lire des tonnes de fichiers et votre contexte atteint rapidement des centaines de milliers de tokens, voire des millions. A ce rythme, ce n'est pas rare d'avoir une requête qui termine à 1 ou 2$... Avec Opus, c'est quasiment 10 $ la journée en moyenne. Et Opus, c'est précisément ce dont j'ai besoin pour Anantys — un projet complexe qui demande de la finesse et de la compréhension profonde du code.

Je m'en accommodais : j'avais défini des règles Cursor drastiques pour limiter sa gloutonnerie (interdiction de lire des fichiers hors scope sans ma permission) et je n'utilisais Opus que pour planifier mes développements (il avait pour mission d'écrire une spec markdown), puis je passais la main à Gemini 3 pour développer (moins cher et pas mauvais en code pour autant, même si moins bon architecte qu'Opus).

Ça fonctionnait. Mais j'en étais arrivé à payer environ 60/70$ par mois.

Premier contact

Donc voilà, je me lance début janvier. J'installe Claude Code. Je rentre dans le repo de anantys, je tape claude. Première impression : oui c'est le terminal, mais paradoxalement, c'est très ergonomique. C'est bien fait, bien léché.

Avant tout, je switch sur Opus avec la commande /model. Ça fait une énorme différence. Rester sur Sonnet c'est comme demander à un lycéen de prendre la main sur votre clavier, alors qu'Opus serait un Ph D. En somme.

Première heure : quota dépassé. MAIS — et c'est important — j'étais déjà impressionné. Ce qui m'a frappé immédiatement, c'est le système d'approbations. Claude Code demande confirmation avant chaque action sensible. Je vois exactement ce qu'il s'apprête à faire. Je valide ou je refuse. Cette transparence, ce contrôle explicite, c'est exactement ce que je cherchais.

On suit le flux de travail ensemble. Je ne suis pas spectateur d'une boîte noire — je suis aux commandes.

Le jeu du pricing

J'ai basculé sur le plan Max à 90$/mois. Et là, révélation.

Je n'ai plus jamais dépassé mon quota. Les limites se réinitialisent toutes les quelques heures, chaque semaine. Avec une utilisation constante d'une instance Claude Code — et je l'utilise vraiment tout le temps — je ne dépasse jamais 70% de ma limite journalière.

Comparé à Cursor avec Opus activé en permanence ? On parle facilement de 200 à 300$/mois. Avec Claude Code : un coût fixe, prévisible, et la paix de l'esprit. Plus de calculs mentaux pour savoir si je peux me permettre de lancer une session longue.

Les fonctionnalités qui font la différence

/init et CLAUDE.md

La commande /init génère un fichier CLAUDE.md à la racine du projet. C'est la "bible" du projet pour Claude. Il y lit les conventions, l'architecture, les commandes importantes. Résultat : des réponses contextualisées dès le premier prompt, sans avoir à tout réexpliquer à chaque session.

Les Skills

Dans .claude/commands/, on peut créer des "skills" — de simples fichiers Markdown contenant des prompts. Le pattern est d'une simplicité désarmante : un fichier, une instruction, et Claude sait exactement quoi faire.

Exemple concret : j'ai créé /anantys-review <scope> pour les audits de code. Un simple prompt qui déclenche une analyse complète du scope demandé. Simple + puissant = exactement ce qu'il faut.

Le bond en productivité

Deux semaines d'utilisation intensive. Le verdict ?

Un bond massif en avant.

Avec Cursor, je partais régulièrement sur de fausses pistes — une ou deux fois par semaine, des sessions entières à corriger du code mal orienté. Avec Claude Code ? Quasi zéro. Les écarts sont mineurs, pas des réécritures majeures. La qualité du code produit est remarquable et surtout constante.

Ce n'est pas juste "mieux" — c'est un changement de régime.

Le nouveau setup

J'ai résilié mon abonnement Cursor.

Retour à VSCode simple + l'extension Claude Code. Le meilleur des deux mondes : un éditeur que je maîtrise parfaitement, et un assistant IA en ligne de commande qui ne me cache rien.

Pour aller plus loin : Spec-Kit

Une découverte récente pour les gros chantiers : Spec-Kit. L'idée : structurer ses spécifications pour que Claude puisse les consommer efficacement sur des sessions longues.

Je l'ai testé sur un vrai sujet : la synchronisation bancaire pour Anantys. Un chantier complexe — OAuth, webhooks, mapping sur la DB locale pour lier des comptes bancaires à des stratégies d'investissement. Le genre de feature qui demande normalement plusieurs semaines.

Avec Spec-Kit + Claude Code : une journée. J'ai démarré le matin, à 18h je testais avec la sandbox du provider. Ça fonctionnait.

Plot twist : le pricing du provider n'était pas celui attendu (licence minimum hors budget). Petit coup au moral. Mais pas de quoi se démotiver — de toute façon, il fallait implémenter du multi-provider (les providers EU ne supportent que les banques EU, et inversement aux US).

Nouvelle EPIC avec Spec-Kit : refactorer tout le code en classes abstraites pour supporter n'importe quel provider. 48h plus tard : c'est fait, testé, fonctionnel. Implémenter un nouveau provider se résume maintenant à coder sa classe métier spécifique et convertir ses payloads en objets standardisés Anantys.

Le sales du provider était surpris que mon implémentation soit déjà fonctionnelle. Ils ont l'habitude d'allouer un "sales engineer" à leurs clients pour les accompagner...

2026 : le constat

Le passage à Claude Code me rappelle exactement ce que j'avais ressenti en passant du code "à la main" à Cursor. Le même gap. Le même sentiment de franchir un palier.

Sauf que cette fois, c'est encore plus fort. J'ai l'impression de travailler avec quelqu'un d'extrêmement qualifié. Pas un outil, pas un assistant — un collaborateur. Qui comprend le contexte, propose des solutions pertinentes, et produit du code que je n'ai pas honte de merger.

Les chiffres parlent d'eux-mêmes : une EPIC qui m'aurait pris deux à trois semaines se boucle en une ou deux journées. Et je ne sacrifie pas la qualité — au contraire. Les reviews systématiques d'Opus en fin de session me donnent un filet de sécurité que je n'avais jamais eu.

Ce n'est plus "coder avec de l'aide". C'est une transformation radicale du métier de développeur. Le monde a changé. Complètement.