Comment utiliser Claude Code : le seuil où il devient utile

Claude Code s'utilise dans un terminal : tu l'installes en une commande, tu te connectes avec un abonnement Claude payant, tu lances claude dans le dossier de ton projet et tu écris ce que tu veux en français. Il lit les fichiers, propose des modifications et exécute des commandes avec ton accord. Il devient vraiment utile à un moment précis : quand ta demande contient sa propre vérification.

Avant le seuil : un chat qui a des mains

La mise en route tient en trois étapes. Sur macOS, Linux ou WSL, une seule commande installe Claude Code :

curl -fsSL https://claude.ai/install.sh | bash

Sous Windows, l'équivalent PowerShell est irm https://claude.ai/install.ps1 | iex, et Homebrew propose brew install --cask claude-code. Il faut ensuite un compte. Claude Code est inclus dans tous les abonnements payants (Pro à 20 dollars par mois, Max à partir de 100), ou se facture à l'usage avec des crédits prépayés sur un compte Console. Au premier lancement, claude ouvre ton navigateur pour te connecter, puis te rend la main dans le terminal.

À partir de là, tu tapes des phrases. « Que fait ce projet ? », « où est le point d'entrée ? », « ajoute une validation sur le formulaire d'inscription ». Claude Code cherche les fichiers concernés, les lit, propose une modification, et te demande la permission avant d'écrire ou de lancer une commande. Trois commandes suffisent au début : /clear pour repartir de zéro, /help pour la liste, et claude -c depuis le terminal pour reprendre la dernière conversation du dossier.

C'est l'état avant le seuil : ChatGPT avec un accès au disque. Tu demandes, il produit, tu relis. Chaque modification passe par tes yeux, parce que rien d'autre ne peut dire si elle est juste. C'est confortable, c'est lent, et c'est là que la plupart des gens s'arrêtent.

Le seuil : la demande qui contient sa vérification

Le seuil tient en une phrase. Claude Code s'arrête quand le travail a l'air fini. Sans vérification qu'il peut lancer lui-même, « ça a l'air fini » est le seul signal dont il dispose, et c'est toi qui fais office de suite de tests. Le moment où ta demande inclut quelque chose qui répond oui ou non, la boucle se ferme sans toi : il modifie, il lance la vérification, il lit le résultat, il recommence jusqu'à ce que ça passe.

Concrètement, la même demande avant et après.

Avant : « ajoute une fonction qui valide les adresses email ».

Après : « écris une fonction validateEmail. Cas attendus : user@example.com renvoie vrai, invalid renvoie faux, user@.com renvoie faux. Écris ces cas en test, lance les tests, corrige jusqu'à ce qu'ils passent, et montre-moi la sortie. »

Rien de sophistiqué n'est entré dans la deuxième version : pas de rôle, pas de contexte en plus, juste un critère de réussite exécutable. La documentation officielle le dit en une ligne, début septembre 2026 : donner à Claude une vérification qu'il peut lancer, c'est « la différence entre une session que tu surveilles et une session que tu quittes ».

La vérification n'a pas besoin d'être une suite de tests. Tout ce qui renvoie un signal lisible dans la conversation fait l'affaire : le code de sortie d'un build, un linter, un script qui compare une sortie à un fichier de référence, une capture d'écran comparée à une maquette. Le meilleur point de départ quand tu n'as aucun test : la commande qui reproduit le bug que tu viens de voir. Elle échoue maintenant, elle doit réussir après. C'est déjà un test.

Ce qui bascule au seuil, ce n'est pas la vitesse d'écriture du code. C'est ce que tu lis. Avant, tu lis le diff. Après, tu lis la sortie de la vérification, et tu ne retournes au diff que quand elle te surprend. C'est là que le temps se gagne.

“

Tant que ta demande ne contient pas sa vérification, c'est toi qui fais office de suite de tests.

”

Juste après le seuil : trois choses changent

La vérification entre dans CLAUDE.md. Ce fichier à la racine du projet est relu au début de chaque session. /init en génère un premier à partir de ton code, avec les commandes de build et de test qu'il trouve. Le contenu qui rapporte le plus : la commande qui vérifie, et la règle « lance-la avant de dire que c'est fini ». Le reste pèse dans le contexte sans changer grand-chose. Un fichier court et précis est mieux suivi qu'un fichier long : la doc le dit, et c'est aussi ce que j'observe. Même logique que pour les sept pièges du pack complet Everything Claude Code : tu n'actives que ce qui t'a déjà fait gagner une session.

Le mode plan devient utile, mais pas partout. Shift+Tab fait défiler les modes de permission jusqu'au mode plan : Claude lit et propose sans rien modifier. Utile quand la modification touche plusieurs fichiers ou que tu ne connais pas le code. Inutile si tu peux décrire le diff en une phrase ; dans ce cas, demande directement.

Les sessions raccourcissent. Une demande vérifiable a une fin nette. Tu obtiens les tests verts, tu tapes /clear, tu passes à la suivante. Avant le seuil, les conversations s'étirent parce que rien ne dit quand elles sont finies.

Pour écrire la demande, une méthode simple : pars de la réponse que tu accepterais. Décris le résultat attendu, puis remonte vers la consigne. C'est la même logique que pour un exemple de prompt ChatGPT rétro-ingénié depuis une réponse validée, avec une différence : ici, la réponse validée peut être une commande qui passe.

Ce que le seuil ne règle pas

Trois choses restent à ta charge.

L'agent peut tricher avec la vérification. Quand un test résiste, la sortie la plus courte est parfois de modifier le test, ou d'étouffer l'erreur. Dis-le explicitement : « corrige la cause, ne touche pas au test, ne désactive rien ». Et relis le test, lui, même quand tu ne relis plus le code. Une vérification que l'agent peut réécrire ne vérifie rien.

La permission reste une décision. Selon ton plan, Claude Code te demande l'accord avant chaque écriture ou commande, ou passe par un mode automatique qui relit chaque action et ne bloque que ce qui paraît risqué. Dans les deux cas, tu peux autoriser des commandes précises, le linter ou git commit, plutôt que tout accepter. Un mode existe pour sauter toutes les demandes ; il est prévu pour des bacs à sable sans accès réseau, pas pour ta machine avec tes clés dessus.

L'exécution sans toi est un autre seuil. Une demande vérifiable te permet de quitter la session, pas de la laisser tourner à heure fixe. Dès qu'un agent produit un effet que personne ne lit avant qu'il parte, tu es sur le seuil où un agent IA gratuit casse, et il réclame d'autres pièces : un état durable, un plafond, une alerte.

La décision à prendre cette semaine est petite. Prends la prochaine chose que tu comptais demander à Claude Code et, avant d'écrire la demande, écris la commande qui dira si c'est réussi. Si tu n'en trouves pas, garde cette tâche pour une conversation, et donne à l'agent la suivante.

FAQ

Claude Code est-il gratuit ? Non. Il est inclus dans les abonnements payants Claude (Pro, Max, Team, Enterprise) et fonctionne aussi avec des crédits API via la Console Anthropic. Le plan gratuit ne le comprend pas. À 20 dollars par mois, Pro suffit pour commencer ; l'usage est plafonné et partagé avec l'application Claude.

Faut-il savoir coder pour utiliser Claude Code ? Pour lancer un projet, non : tu décris ce que tu veux en langage courant. Pour franchir le seuil, un peu : il faut savoir ce qu'est une commande qui réussit ou échoue, et pouvoir lire sa sortie. Ça s'apprend en une semaine, et c'est la compétence qui compte.

Claude Code fonctionne-t-il sous Windows ? Oui, en natif via PowerShell ou WinGet, ou dans WSL. Sous Windows natif, Git for Windows est recommandé pour que Claude Code dispose d'un shell Bash.

Quelle différence entre claude et claude -p ? claude ouvre une session interactive dans laquelle tu enchaînes les demandes. claude -p "ta question" exécute une seule requête, affiche la réponse et se termine : pratique dans un script ou un alias, moins pour du travail suivi.