Débuter avec Claude Code : de l'installation au premier commit en 30 minutes

Vous tapez claude dans le terminal, vous appuyez sur Entrée.

On sent bien que quelque chose se met en route. Mais la première fois que j’ai fait ça, tout ce qui s’est affiché à l’écran, c’était « Connectez-vous » — et je suis resté figé là pendant cinq bonnes minutes. Me connecter où ? Est-ce que ça va me coûter de l’argent ? Est-ce que l’outil va lire tout mon code ? Résultat : ce jour-là, j’ai fermé la fenêtre sans avoir touché à une seule ligne.

Avec le recul, le premier mur n’était ni l’installation ni l’anglais : c’était « une fois lancé, qu’est-ce que je lui demande ? ». Alors dans cet article, on franchit cette étape par le chemin le plus court. Installation → connexion via le navigateur → première instruction → premier commit, le tout en 30 minutes. Et les trois embûches sur lesquelles j’ai moi-même trébuché en chemin (autoriser les permissions, la conversation qui devient lourde, la première ligne du CLAUDE.md), je les pose à l’avance pour que vous ne tombiez pas dedans.

L’intention de recherche est simple : « comment débuter avec Claude Code », « utilisation pour débutants ». Je réponds à ça, sans détour.

Points clés

• L’installation se fait d’un seul coup avec l’installeur officiel. Sur macOS/Linux, curl ... | bash ; sur Windows, irm ... | iex. Si vous préférez passer par Node.js : npm i -g @anthropic-ai/claude-code (Node 18 ou supérieur).
• L’authentification passe par le navigateur. Lancer claude vous redirige vers la page de connexion. Il faut un abonnement Claude Pro/Max ou un compte Console (l’offre gratuite Claude.ai n’est pas éligible).
• Les 30 premières minutes, on ne laisse rien modifier. On apprivoise l’outil dans l’ordre : lui faire lire → lui faire expliquer → ne faire relire qu’un seul fichier.
• L’objectif, c’est d’aller jusqu’au premier commit. Prenez dès le premier jour l’habitude de vérifier le diff de vos propres yeux avant de valider.
• Trois mines sur lesquelles les débutants sautent souvent : ne pas tout autoriser, compresser la conversation quand elle devient lourde, et écrire une ligne « comment lancer les tests » dans le CLAUDE.md.

On y va dans l’ordre. Je ne mets que du code qui marche tel quel, copier-coller.

D’abord la vue d’ensemble : la carte des 30 minutes

Avant d’entrer dans le détail, voici la carte jusqu’à l’objectif. On se perd beaucoup moins comme ça.

Temps	À faire	Objectif
0–5 min	Installation + connexion via le navigateur	Avoir un claude qui se lance
5–10 min	Créer une branche d’entraînement	Se ménager un terrain où l’on peut revenir en arrière
10–20 min	Faire lire, faire expliquer	Saisir « sur quoi se fonde la réponse »
20–25 min	Demander une petite modification	Vivre le flux édition → vérification du diff
25–30 min	Premier commit	Prendre l’habitude de valider en connaissance de cause

Le point essentiel : ne pas faire de grosse refonte le premier jour. Une demande du genre « nettoie-moi tout ce projet » attendra que vous soyez à l’aise. Au début, petit, et dans un périmètre où l’on peut revenir en arrière.

Étape 1 : installer (0–3 min)

Il y a peu, « l’installer avec npm » était la norme. Aujourd’hui, la méthode officielle privilégiée, c’est l’installeur dédié. Il s’installe sans se soucier de la présence ou non de Node.js.

Sur macOS / Linux / WSL, c’est ceci.

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

Dans PowerShell sous Windows, c’est cela.

irm https://claude.ai/install.ps1 | iex

« Moi, je veux gérer ça avec Node.js » : l’installation par npm reste possible comme avant. Il faut Node.js 18 ou supérieur.

npm install -g @anthropic-ai/claude-code

On vérifie que c’est bien installé. Si un numéro de version s’affiche, c’est bon.

claude --version

Si vous obtenez command not found à ce stade, claude doctor vous dira d’où vient le problème.

claude doctor

Un seul avertissement. Même en cas d’erreur de permission, ne lancez pas par réflexe sudo npm install -g. La doc officielle le précise noir sur blanc : à éviter, car cela ouvre la porte à des problèmes de droits et à des risques de sécurité. Sans paniquer, suivre les indications de claude doctor est plus rapide.

Étape 2 : se connecter via le navigateur (3–5 min)

Une fois l’installation faite, on lance.

claude

Au premier démarrage, vous êtes automatiquement redirigé vers l’écran de connexion. Le navigateur s’ouvre ; il suffit de suivre les instructions à l’écran pour se connecter. Une fois validé, les identifiants sont enregistrés et l’outil ne vous redemandera plus rien.

C’est ici que beaucoup de débutants bloquent : « bon, mais quel compte ? ». Pour y voir clair, voici le tableau.

• Abonnement Claude Pro / Max / Team / Enterprise … le plus simple pour démarrer seul (recommandé)
• Anthropic Console (API, crédits prépayés) … pour ceux qui veulent gérer une clé API et centraliser les coûts
• Amazon Bedrock / Google Vertex AI / Microsoft Foundry … quand la politique cloud de l’entreprise est déjà fixée

Un point d’attention. L’offre gratuite Claude.ai ne permet pas d’utiliser Claude Code. Beaucoup l’ignorent et se cassent la tête en répétant « je n’arrive pas à me connecter » — alors autant le dire d’emblée.

Pour changer de compte, tapez /login dans la session en cours et vous pourrez vous réauthentifier.

Étape 3 : se créer un endroit où l’on peut revenir en arrière (5–10 min)

Ça paraît anodin, mais c’est important. Ne jouez pas directement dans un dépôt de production. Ouvrez un petit dépôt d’entraînement, ou un projet perso que ça ne dérange pas de casser.

Si vous testez sur du code de travail, créez systématiquement une branche dédiée.

git status
git switch -c try-claude-code

Regarder git status en premier, c’est pour ne pas embarquer des modifications non commitées. Si l’on démarre alors que l’état initial est flou, on finit par ne plus savoir « ce diff, c’est l’IA ou c’est moi ? ». Ça, c’est exactement ce que j’ai foiré le premier jour.

On lance Claude Code dans ce dossier.

cd /chemin/vers/votre/projet
claude

Au lancement, la version, le modèle utilisé et le répertoire de travail s’affichent en haut. /help montre la liste des commandes.

Étape 4 : d’abord, juste « faire lire » (10–20 min)

C’est ici que ça devient sérieux. Mais on ne laisse toujours rien modifier. Au début, on fait lire, et on fait expliquer. Rien que ça suffit à attraper le réflexe : « sur quoi Claude Code fonde-t-il sa réponse ? ».

En mode interactif, parlez-lui simplement en français naturel. Pas besoin de syntaxe compliquée.

Lis uniquement README.md et package.json, puis explique-moi en français l'objectif de ce projet et comment le lancer

Le point clé : restreindre le périmètre avec « lis uniquement ». Si, dès le départ, l’outil se met à lire des tas de fichiers, on ne peut plus remonter à la source de la réponse. Et ça rejoint directement le problème de « la conversation qui devient lourde » dont je parle plus loin.

Quand vous serez plus à l’aise, demandez une relecture portant sur un seul fichier.

Lis uniquement src/utils/date.ts et signale-moi au maximum 3 points susceptibles de causer des bugs. Ne modifie rien pour l'instant

En ajoutant « ne modifie rien pour l’instant », vous évitez de mélanger relecture et implémentation. D’abord l’entraînement à lire les propositions ; mettre les mains dans le code, c’est pour après.

À propos : quand vous voulez exécuter une recherche ou une tâche routinière une seule fois, vite fait, sans entrer en mode interactif, le one-shot est pratique. Avec -p, l’outil renvoie le résultat puis s’arrête.

claude -p "Exécute git log --oneline -10 et résume-moi les changements en français"

Ma règle de répartition est simple : mode interactif pour l’implémentation où l’on tâtonne, one-shot pour la recherche et le résumé. Au début, ces deux modes suffisent largement.

Étape 5 : la première petite modification (20–25 min)

Une fois l’entraînement à la lecture fait, on passe enfin aux modifications. Au début, à l’échelle « un fichier, une fonction ».

En mode interactif, demandez ceci.

Ajoute un test unitaire à la fonction getUserById de src/api/users.ts. Aligne-toi sur la façon dont les tests existants sont écrits

Et là, Claude Code vous demande systématiquement « je peux appliquer cette modification ? ». Il ne réécrit jamais un fichier de son propre chef. Vous regardez le diff proposé, et vous l’approuvez une fois convaincu. C’est le garde-fou par défaut.

La première mine est là. Las d’appuyer sur Entrée à chaque confirmation, je suis vite passé en mode « tout autoriser ». Résultat : des fichiers que je n’avais pas demandés se sont retrouvés « rangés au passage », et j’ai blêmi. La leçon : approuver un par un, au début, c’est finalement le plus rapide. Quand vous voudrez régler les permissions dans le détail, direction l’article dédié plus bas.

Une fois la modification acceptée, vérifiez toujours le diff de vos propres yeux.

git diff
npm test

« Ça a l’air de marcher » et « le diff ne contient que ce que je voulais », ce sont deux choses différentes. Diff et tests vont par paire.

Étape 6 : le premier commit (25–30 min)

Le diff est vérifié, les tests passent. Arrivé là, l’objectif est tout proche.

Le commit aussi se demande en langage naturel.

Vérifie les changements et fais un commit avec un message clair

Claude Code lit le git diff, rédige un message, et redemande confirmation avant de committer. Bien sûr, vous pouvez aussi le taper à la main.

git add src/api/users.ts
git commit -m "test: ajoute un test unitaire pour getUserById"

Et voilà : « installation → connexion → faire lire → modifier petit → vérifier le diff et committer » a bouclé un tour complet. En 30 minutes, vous avez fait tourner la boucle minimale de Claude Code de vos propres mains. Pour un premier jour, c’est largement suffisant. Fermez la fenêtre la tête haute.

Copier-coller : les 30 minutes condensées en un script de démarrage

Comme retrouver les commandes à chaque fois est pénible, je garde un script shell qui « démarre une session d’entraînement en sécurité ». Il crée une branche et va jusqu’à la demande de lecture, d’une traite. Pas besoin de Node.js, ça tourne avec bash seul.

#!/usr/bin/env bash
# start-claude-practice.sh — démarrer une pratique de Claude Code en sécurité
set -euo pipefail

# 1) Vérifier qu'il ne reste pas de modifications non commitées (éviter de tout embarquer)
if [ -n "$(git status --porcelain)" ]; then
  echo "⚠ Des modifications non commitées sont présentes. Faites d'abord un commit ou un stash."
  git status --short
  exit 1
fi

# 2) Créer une branche d'entraînement (datée ; si elle existe déjà, on bascule simplement dessus)
BRANCH="try-claude-$(date +%Y%m%d)"
git switch -c "$BRANCH" 2>/dev/null || git switch "$BRANCH"
echo "✅ Travail sur la branche $BRANCH"

# 3) Lancer en one-shot une demande « juste lire » pour commencer
claude -p "S'il y a un README, lis le README ; sinon, lis les fichiers principaux,
puis explique-moi en 3 lignes en français l'objectif du projet, comment le lancer
et quel fichier lire ensuite. Ne modifie absolument rien."

Son utilisation, c’est juste ça.

chmod +x start-claude-practice.sh
./start-claude-practice.sh

À l’exécution, s’il y a des modifications non commitées, le script s’arrête ; sinon, il crée une branche d’entraînement et affiche un résumé du projet. C’est « éviter d’embarquer tout le reste », « se créer un endroit où revenir en arrière » et « d’abord faire lire » réunis en un seul fichier. J’aurais aimé le donner à moi-même, le premier jour.

Les 3 embûches sur lesquelles j’ai trébuché au début

À partir d’ici, ce sont les choses qui figurent rarement dans les modes d’emploi mais qui font le plus mal quand on tombe dedans le premier jour.

1. Tout autoriser dès le départ

Comme je le disais, agacé par les confirmations, on passe à « tout OK » — et l’accident arrive. Au début, le plus sûr est d’utiliser l’outil dans cet état : écriture et commit confirmés à chaque fois, suppression et force push interdits. Dans .claude/settings.json, on peut figer ça comme ceci.

{
  "permissions": {
    "allow": ["Read(**)", "Grep(**)", "Bash(npm test*)", "Bash(git status*)", "Bash(git diff*)"],
    "ask": ["Write(**)", "Edit(**)", "Bash(git commit*)", "Bash(git push*)"],
    "deny": ["Bash(rm -rf*)", "Bash(git push --force*)"]
  }
}

« Lecture et tests en automatique, écriture et commit avec confirmation, suppressions dangereuses interdites. » Rien que ce dispositif à trois étages prévient la quasi-totalité des accidents. Les opérations dont vous aurez vérifié l’innocuité, vous les ferez monter ensuite dans allow. Pour le réglage fin, j’ai tout rassemblé dans le guide de configuration des permissions de Claude Code ; allez-y si vous voulez creuser sérieusement.

2. La conversation devient lourde (saturation du contexte)

À l’usage, à un moment, tout devient soudain pâteux. Ce n’est pas une panne, mais le signe que la conversation s’est allongée et que le « contexte » porté par Claude Code a trop gonflé. C’est comme le plan de travail en cuisine qui se couvre peu à peu de vaisselle sale.

Deux remèdes. Quand une étape est bouclée, compressez la conversation, ou repartez de zéro.

/compact

/clear

/compact compresse en conservant l’essentiel, /clear réinitialise tout. Dès que vous sentez « pourtant c’était fluide il y a deux minutes », n’hésitez pas à utiliser l’un des deux. Le conseil du début, « restreindre le périmètre de lecture », joue aussi ici : moins on fait lire de fichiers inutiles, moins le plan de travail se couvre. Pour faire la part des choses sur la lenteur, le guide d’optimisation de la vitesse de Claude Code entre dans le détail.

3. Ne pas écrire la première ligne du CLAUDE.md

Ça, c’est du registre « heureux de l’avoir fait ». Claude Code lit automatiquement le CLAUDE.md situé à la racine du projet. En y notant les informations du projet, vous évitez d’avoir à les expliquer à chaque fois.

Ce que je regrette, c’est de ne pas l’avoir écrit au début. J’ai dû répéter à chaque conversation « ce projet est en TypeScript, et les tests se lancent avec npm test ». La seule ligne à écrire en premier, c’est celle-ci.

## Commandes courantes
- Tests : npm test
- Serveur de développement : npm run dev

Rien qu’avec « comment lancer les tests », Claude Code tentera de lancer les tests lui-même après une modification. À l’inverse, écrire un CLAUDE.md interminable dès le départ rend les consignes plus difficiles à respecter. Ce qu’il faut écrire et ce qu’il faut taire, j’ai détaillé cette frontière dans les meilleures pratiques pour CLAUDE.md.

L’étape suivante : passer des tâches ponctuelles à « déléguer »

Une fois la boucle des 30 minutes apprivoisée, on passe du « ordre ponctuel » au stade « confier un travail un peu plus consistant ». Cela dit, on ne bascule pas en tout-automatique d’un coup.

L’ordre est toujours le même. ① restreindre clairement le périmètre de lecture → ② rendre l’objectif (le livrable) limpide → ③ confier autant que possible les vérifications à des commandes → ④ au début, faire passer toutes les opérations dangereuses par « demander à l’humain ». Cette manière de penser, qui consiste à préparer « l’échafaudage » de l’IA, je l’ai détaillée dans comment construire l’échafaudage (harness) pour déléguer du travail à l’IA. À lire juste après cette introduction : le paysage change d’un coup.

La façon de formuler les consignes change aussi les résultats, une fois prise en main. Trois astuces, pas plus.

1. Indiquez le nom du fichier (et si possible le numéro de ligne) — ça réduit le temps d’exploration
2. Décrivez concrètement le comportement attendu — « fais ça bien » ne passe pas
3. Joignez les contraintes — « aligne-toi sur les patterns existants », « ne touche pas aux autres fichiers »

Ajoute à la fonction login de src/api/auth.ts un traitement qui renvoie 400 quand le mot de passe est vide.
Aligne le message d'erreur sur les patterns de src/utils/errors.ts. Ne touche pas aux autres fichiers

FAQ

Q. Est-ce gratuit ? R. Claude Code en lui-même n’est pas utilisable avec l’offre gratuite Claude.ai. Il faut un abonnement Claude Pro / Max, ou un compte Console disposant de crédits prépayés. Si le coût vous inquiète, j’explique comment fixer un budget dans le guide de gestion des coûts Claude Code/API.

Q. Sous Windows, ça marche comme sous Mac ? R. Oui. Seule l’installation change, avec irm https://claude.ai/install.ps1 | iex (PowerShell) ; le lancement et l’usage sont identiques. Installer Git Bash rend l’exécution de certaines commandes plus fluide.

Q. Faut-il une clé API ? R. Pour démarrer seul, non. Le plus simple est de lancer claude et de se connecter via le navigateur. Le montage où l’on gère une clé API via des variables d’environnement attendra que la politique d’authentification de l’équipe ou l’environnement cloud soit fixé.

Q. Est-ce que tout mon code va être envoyé ? R. Claude Code ne lit que les fichiers nécessaires, au cas par cas. Pas besoin de tout fournir à la main, et la règle de base est de ne jamais coller votre .env, vos clés de production ou des données clients. J’ai rassemblé le minimum vital côté sécurité dans les mesures de sécurité pour Claude Code.

Q. Le modèle par défaut me semble lourd / cher. R. Pour les tâches simples, vous pouvez basculer vers un modèle plus léger en cours de session. /model permet de choisir le modèle : modèle léger pour la recherche, modèle performant pour l’implémentation difficile — cette répartition rend l’usage bien plus confortable.

En résumé : boucler la « boucle minimale » en 30 minutes

Débuter avec Claude Code, au fond, tient en une seule ligne. Installation → connexion via le navigateur → faire lire → modifier petit → regarder le diff et committer. Faites tourner une fois cette boucle de 30 minutes de vos propres mains, et le « je ne sais pas par où commencer » disparaît.

Les bourdes faciles du premier jour se résument à trois : ne pas tout autoriser, compresser la conversation quand elle devient lourde, écrire une ligne « comment lancer les tests » dans le CLAUDE.md. En les évitant, votre première expérience sera nettement plus fluide.

Ce site (claudecode-lab.com) fait tourner chaque jour avec Claude Code la génération des articles, leur traduction et le déploiement. Et ça, c’est moi qui le dis — moi qui doutais au début, « est-ce vraiment possible ? ». Vous aussi, aujourd’hui : d’abord 30 minutes. Tapez claude, et allez jusqu’au premier commit.

Si vous bloquez ensuite, c’est la nature du blocage qui choisit la suite. Pour avoir les commandes et les bonnes façons de demander sous la main, l’antisèche Claude Code gratuite ; pour tout mettre en ordre jusqu’à la configuration et l’exploitation, la liste des supports de formation est un raccourci.

Vous pouvez aussi vérifier la procédure la plus à jour dans le Quickstart officiel de Claude Code (en anglais). L’installation et l’authentification évoluent parfois ; en cas de doute, consultez la source primaire.

Ce que j’ai constaté en testant réellement le contenu de cet article

Cette boucle de 30 minutes, je l’ai fait tester à côté de moi par une connaissance, développeuse front-end peu habituée au CLI. Ce qui a le mieux marché, c’est « ne rien laisser modifier au début ». Sauter l’étape « faire lire, faire expliquer », et l’on reste figé devant la première proposition de modification. À l’inverse, ceux qui intercalent explication → relecture d’un fichier sont vraiment arrivés au premier commit en un peu moins de 30 minutes.

Autre chose que j’ai ressentie concrètement : l’effet de la « ligne de test » dans le CLAUDE.md. Quand elle est écrite, après une modification, Claude Code lance de lui-même npm test, repère seul l’échec et commence à corriger. Sans elle, c’est à vous de répéter « lance les tests » à chaque fois. L’écart de deux malheureuses lignes a nettement réduit le nombre d’allers-retours qui ont suivi. Avant de partir en quête du modèle le plus intelligent, préparez un échafaudage — même pour débuter, c’est finalement là que ça compte le plus.