Installer et faire sa première vraie modification

Tu es décidé, et une objection t’arrête : je ne lâche pas ça sur mon vrai code. Elle est saine. Mais un projet jetable ne t’apprendra rien — tout y marche, c’est même à ça qu’on les reconnaît. Ce que tu veux savoir, c’est comment ça se comporte dans tes cinq ans de raccourcis.

On ouvre donc le vrai. Cette leçon sert à le faire sans se mettre en danger, et ça commence par une question que personne ne pose.

Piège — Ton vrai dépôt, oui : sur ta machine, pas sur celle qui sert tes utilisateurs. Si tu modifies ton site directement sur le serveur qui le fait tourner (c’est plus fréquent qu’on ne le dit), alors chez toi, écrire un fichier est un déploiement. Aucune des précautions de cette leçon ne te protège de ça, parce qu’elles supposent toutes qu’un fichier modifié ne part nulle part.

Dans ce cas, ton sujet du jour n’est pas ta première modification : c’est de récupérer une copie du projet en local et de travailler dessus. Le reste de la leçon t’attend après.

Ce qui se passe vraiment

L’installation n’est pas le sujet, et cette leçon ne va pas la raconter longuement. Elle tient en une commande, elle est documentée officiellement, et une page qui la recopie sera fausse au prochain changement d’écran.

Ce qui décide de ta première heure, ce sont trois comportements de l’outil — Claude Code, donc : le programme qui lit tes fichiers, lance des commandes et modifie ton code lui-même, comme la leçon 1 l’a posé. Aucun des trois n’est une étape, et c’est pour ça qu’aucune procédure de démarrage ne les met en avant.

Il s’arrête quand le travail a l’air fini

Pas quand il est fini. S’il n’existe rien, dans ta session, qui renvoie réussi ou échoué, « ça a l’air fini » est le seul signal dont il dispose pour décider qu’il a terminé.

Et alors la boucle de vérification, c’est toi. Chaque erreur attend que tu la remarques — plus tard, parfois beaucoup plus tard, sur un problème qui a eu le temps de s’installer et de se ramifier.

Un contrôle, ici, ce n’est pas forcément une suite de tests. C’est tout ce qui renvoie un verdict lisible dans la conversation :

• une suite de tests ;
• le code de sortie d’une compilation ou d’une construction ;
• un analyseur de code ;
• un script qui compare une sortie à un modèle ;
• une capture d’écran comparée à une maquette.

Deux familles, à ne pas confondre — c’est ce qui décide de la façon dont tu formuleras ta demande, plus bas :

	Ce qu’il boucle tout seul	Ce que tu constates toi
Exemples	tests, compilation, analyseur, script de comparaison	l’écran, le comportement, la capture
Il peut	relancer jusqu’à ce que ça passe	faire la modification, puis te dire quoi regarder
Tu obtiens	une session que tu peux quitter	une session que tu dois finir toi-même

La première famille referme la boucle sans passer par toi, et c’est ce qu’on vise. Mais la seconde est parfaitement valable — elle est même le seul recours quand rien n’est automatisé, et c’est le sujet entier de la leçon 10.

Sans contrôle qu’il puisse lancer, « ça a l’air fini » est le seul signal disponible — et c’est toi qui deviens la boucle de vérification, plus tard.

Cette section reformule la page de bonnes pratiques officielle, qui va plus loin — code.claude.com/docs/en/best-practices.

La preuve est produite par celui qu’on contrôle

C’est la deuxième chose, et c’est celle qu’on oublie en écrivant la première. Tu vas lui demander de lancer un contrôle et de te montrer le résultat. Ce résultat, c’est lui qui le fabrique.

La documentation officielle en nomme une, et c’est la plus courante : supprimer l’erreur au lieu de traiter sa cause. Sur nos projets, on en voit passer d’autres — un test assoupli, un cas mis de côté, une dépendance qui coince remplacée par une simulation. Rien de tout ça n’est de la triche. C’est une manière raisonnable d’atteindre l’objectif qu’on lui a donné, et l’objectif qu’on lui a donné, c’était « que ça passe ».

D’où la règle que ce parcours répète jusqu’au bout : celui qui fait le travail ne doit pas être celui qui le note. Le premier jour, ça se traduit en deux ajouts d’une ligne — ils sont plus bas.

Ton filet n’est pas celui qu’on te tend

L’outil déroule un fil derrière toi. À chaque message envoyé, il pose un point de restauration — checkpoint dans la documentation et à l’écran. C’est une photo des fichiers, prise avant qu’ils ne soient modifiés. Tu peux revenir sur tes pas.

Mais le fil ne passe pas par les portes dérobées. Ce qui est fait par des commandes shell n’est pas dessus — et c’est exactement ce que tu vas lui demander dans dix minutes, quand tu lui diras de lancer tes tests. Ce n’est pas le seul trou : ils sont détaillés plus bas, et la documentation officielle intitule elle-même une section entière « ce n’est pas un remplacement du contrôle de version ».

Donc on la prend au mot. Ce qui rend raisonnable d’ouvrir ton vrai projet aujourd’hui, ce n’est pas ce fil : c’est un dépôt propre et ton travail enregistré avant de lancer. C’est la différence entre « il a cassé un truc » et « il a cassé un truc, j’annule ».

Ce qu’on fait

1. Vérifier que ton compte y donne droit

Le plan gratuit de claude.ai ne donne pas accès à Claude Code. Il faut le dire dans ce sens-là, parce qu’une liste d’offres compatibles se lit trop vite : on y cherche son propre cas, on trouve un mot qui ressemble, on installe, et on se cogne au mur à la connexion — en croyant avoir raté l’installation.

Ce qui ouvre l’accès : un abonnement Pro, Max, Team ou Enterprise, un compte Claude Console, ou l’accès fourni par un cloud d’entreprise.

Cette ligne-là décide d’autre chose, et personne ne te le dira au moment de payer. Tu t’apprêtes à ouvrir ton vrai projet : autant savoir ce qui en sort. Pour fonctionner, l’outil envoie à Anthropic ce que tu écris et ce qu’il lit — ce n’est pas une option, c’est le mécanisme. Ce qui change selon l’offre, c’est la suite. Sur les offres grand public (Free, Pro, Max), tes données peuvent servir à entraîner de futurs modèles si le réglage correspondant est actif sur ton compte ; il se change sur claude.ai, pas dans l’outil. Et ce réglage décide aussi de la durée de conservation : cinq ans quand il est actif, trente jours sinon. Les offres commerciales (Team, Enterprise, API) sont sous un autre régime, sans entraînement par défaut.

Va vérifier plutôt que me croire — les règles bougent, et c’est la page usage des données qui fait foi. Le point à retenir n’est pas un chiffre : c’est que le choix d’offre que tu viens de faire est aussi un choix de confidentialité, et qu’il ne se présente jamais comme tel.

2. Installer

L’installation native est celle qui est recommandée. Sur macOS, Linux et WSL :

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

Sur Windows, en PowerShell :

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

Puis, pour confirmer :

claude --version

La commande affiche un numéro de version suivi de (Claude Code).

Le reste est dans la documentation officielle, sur code.claude.com/docs/en/setup : l’invite de commandes Windows, Homebrew, WinGet, apt, dnf, apk, et les cas particuliers de chaque système. Elle est à jour, elle est maintenue, et rien ne se gagne à la recopier ici.

Si le terminal répond que la commande est introuvable, ouvre-en un nouveau : le programme vient d’être ajouté et ta session en cours ne le voit pas encore.

Si c’est autre chose, ne bricole pas. C’est le moment du parcours où l’on abandonne le plus, et c’est précisément celui où il existe une page faite pour ça : dépannage de l’installation traite les échecs connus du script (l’erreur de syntaxe qui trahit une page HTML reçue à la place du script, les refus réseau, les autres retours de curl) et donne les méthodes d’installation de repli. Et une fois que la commande répond, claude doctor diagnostique l’installation elle-même : c’est le premier réflexe à avoir quand quelque chose ne se comporte pas comme cette leçon le décrit.

Sur Windows, ce n’est pas une méthode d’installation que tu choisis, c’est une plateforme. La documentation présente trois voies : Windows natif, WSL 2, WSL 1. Elles ne donnent pas la même chose, et le tableau de décision est dans la page d’installation, à lire avant de taper la commande plutôt qu’après. Deux points décident pour toi et se rattrapent mal ensuite. Git for Windows d’abord : sans lui, l’outil PowerShell est activé d’office et tes commandes shell passent par lui ; avec lui, tu as l’outil Bash, qui les lance via Git Bash. Mais ce n’est pas un choix entre deux cases : sur une machine qui a Git for Windows, l’outil PowerShell s’ajoute à Bash par un déploiement progressif. Tu peux donc l’avoir sans l’avoir demandé et sans rien avoir changé. Quand il est actif, PowerShell devient le shell principal, Bash restant disponible pour les scripts POSIX tant que Git Bash est installé. Sur Linux, macOS et WSL, l’outil PowerShell existe aussi, mais il faut le demander explicitement. Ça n’a l’air de rien, et c’est le nom que porteront les barrières que tu poseras à la leçon 8 : une règle écrite pour Bash ne regarde pas ce qui passe par PowerShell, et l’inverse est vrai aussi. Le bac à sable ensuite — le sandboxing de la documentation, sandbox dans tous les réglages que tu croiseras : l’isolation posée par le système d’exploitation sur les commandes shell et leurs processus fils, qui borne les fichiers et les domaines réseau qu’ils peuvent atteindre. Il demande WSL 2 et n’existe pas sur Windows natif. Autant le savoir maintenant, pendant que le choix est encore gratuit.

La façon dont tu installes décide de la façon dont tu te mettras à jour. L’installation native se met à jour toute seule, en arrière-plan. Par un gestionnaire de paquets (Homebrew, WinGet, apt, dnf, apk), non, pas par défaut, et il faudra y penser. Sur un outil remanié plusieurs fois par semaine, une installation figée est une dette silencieuse : tu liras des explications qui ne correspondent pas à ton écran, et tu croiras que c’est toi. Les commandes de mise à jour et le réglage qui l’automatise sont dans la documentation d’installation.

3. Enregistrer ton travail, puis ouvrir ton vrai dépôt

Dans cet ordre. C’est l’étape que les guides de démarrage n’ont aucune raison de mentionner, et c’est celle qui autorise tout le reste.

cd /chemin/vers/ton/projet
git status

Lis ce que git status affiche avant d’aller plus loin. Pas seulement « il y a des choses en attente » : lesquelles. Sur un projet de cinq ans, c’est souvent là qu’on découvre un fichier de configuration avec des identifiants dedans, jamais ignoré, qui attendait sagement d’être enregistré par mégarde. Si tu vois un fichier qui n’a rien à faire dans le dépôt, c’est maintenant qu’on s’en occupe — et le geste dépend de la case où git status le range.

• Sous « fichiers non suivis » : git ne le connaît pas encore. Ajouter son nom à ton .gitignore suffit.
• Ailleurs dans la liste : git le suit déjà, et là .gitignore n’a aucun effet sur lui — c’est écrit dans la documentation de git, un fichier déjà suivi n’est pas concerné. Il faut d’abord git rm --cached <le fichier>, qui le retire du suivi sans l’effacer de ton disque, puis ajouter son nom au .gitignore. Et sois lucide sur ce que ça répare : les versions déjà enregistrées restent dans l’historique. Si le dépôt est publié, considère l’identifiant comme compromis et fais-le tourner. Nettoyer un historique déjà partagé est un autre métier, et ce n’est pas le sujet du jour.

Une chose que ce geste ne fait pas, et il vaut mieux le savoir avant de lancer l’outil : .gitignore décide de ce qui part dans le dépôt, pas de ce que l’agent a le droit de lire. Le fichier reste sur ton disque, et il reste lisible. Se prémunir de ça se fait autrement, avec une règle d’autorisation — c’est la leçon 8, et elle ne peut pas se résumer en une ligne ici. En attendant, tu sais que la question n’est pas réglée, ce qui vaut mieux que de croire qu’elle l’est.

Tout ce qui traîne non enregistré n’est protégé par rien : ni par git, qui ne le connaît pas, ni par le fil de points de restauration, qui a des trous. Enregistre ce qui doit l’être, puis pose une branche jetable. Relance git status avant la première commande : le fichier sensible ne doit plus y figurer. Si tu le vois encore, ne tape pas la suite — c’est le premier geste de ce parcours qui ne se reprend pas.

git status
git add -A && git commit -m "avant premier essai"
git switch -c essai-claude
claude

Si ton projet n’est pas sous git, c’est le moment de faire une copie du dossier ailleurs. Aujourd’hui, ça suffit ; la vraie réponse est la leçon 14, « essayer sans rien casser ».

Ce qui se passe au premier lancement. Une page de connexion s’ouvre dans ton navigateur — c’est normal, et c’est le moment où un plan gratuit se fait refuser. Sur une machine distante à laquelle tu es connecté à distance, prévois que ce navigateur devra s’ouvrir quelque part. La fois suivante, tu ne repasses plus par là.

Puis une question de confiance s’affiche, parce que c’est la première fois que ce dossier est ouvert. Réponds oui seulement si le chemin affiché est bien celui de ton projet. Si tu t’es trompé de dossier, refuse, quitte, et relance depuis le bon.

Et avant de lui demander quoi que ce soit, trois gestes qui rassurent : Échap interrompt ce qu’il est en train de faire. Mais quand une fenêtre est ouverte, typiquement une demande d’autorisation, il ferme cette fenêtre au lieu d’interrompre. /exit ferme la session, et /help liste ce que ton installation propose. Retiens surtout le troisième : ce parcours cite une quarantaine de commandes, et certaines demandent une version récente. Le jour où l’une d’elles n’existe pas chez toi, /help te dit en deux secondes si c’est ta version ou ta faute de frappe. La barre d’état affiche le mode d’autorisation en cours ; Shift+Tab en change. Regarde-le maintenant, puis regarde-le encore demain : la toute première session qui suit une installation ou une mise à jour démarre en mode manuel, quelle que soit ton offre. Dès la suivante, sur les offres Pro, Max et Team, tu peux démarrer dans un mode où il agit sans te demander — à partir de la v2.1.228 sur macOS, Linux et WSL, et de la v2.1.233 sur Windows natif. C’est la leçon 8 qui traite le sujet, mais tu as le droit de savoir dans quoi tu es avant de commencer.

Ton dépôt, pas un dépôt de démonstration. Celui qui a des conventions non écrites et une partie que tu n’aurais pas construite comme ça aujourd’hui. C’est le seul terrain où tu apprends quelque chose, parce que c’est le seul où il peut se tromper de façon intéressante.

Une précision sur la question de confiance : lance toujours depuis le dossier du projet, jamais depuis ton dossier personnel. Lancé de là, l’accord n’est pas mémorisé et la question reviendra à chaque démarrage, sans aucun réglage pour l’éviter. Au-dessus de la zone de saisie, une ligne affiche la version, le modèle et le dossier de travail — c’est cette dernière information que tu vérifies avant de taper quoi que ce soit.

4. Choisir la modification : le critère est la vérifiabilité

Ni la taille, ni l’utilité. La question à te poser est celle-ci : est-ce que je saurai constater le résultat moi-même, aujourd’hui ?

Une modification vérifiable et sans grand intérêt vaut mieux, ce premier jour, qu’une modification utile dont tu ne sauras rien dire. Tu n’évalues pas l’outil sur ce qu’il produit — tu montes ta façon de travailler avec, et cette façon commence par savoir constater.

Concrètement, écarte pour aujourd’hui : ce qui touche une base de données, ce qui part vers un service distant, ce qui déclenche un déploiement. Non pas parce que c’est trop dur, mais parce que ce n’est pas rembobinable.

5. Trouver ta preuve, même si tu n’as aucun test

Beaucoup de projets menés seuls n’ont pas de suite de tests. Ce n’est pas un préalable, et ce n’est pas une raison de reporter. Trois preuves sont praticables aujourd’hui, sans rien installer — et elles ne se rangent pas dans la même famille, ce qui change la demande que tu écriras à l’étape suivante :

• Ta commande de compilation, de construction ou d’analyse. Elle se termine et renvoie un verdict : elle passe ou elle échoue. C’est un contrôle, et il est là depuis toujours. Il peut la boucler tout seul. Attention : ton serveur de développement, lui, ne s’arrête jamais et ne dit donc jamais rien — ce n’est pas un contrôle.
• Comparer deux images. Sur une interface, une capture avant et une capture après. Ça se regarde en trois secondes et ça ne se discute pas. C’est toi qui constates.
• Écrire une commande jetable pour l’occasion. Quelques lignes qui appellent le morceau modifié avec deux entrées dont tu connais la réponse, et qui affichent le résultat. Il peut la boucler tout seul — à une condition, ci-dessous.

Piège — La commande jetable, c’est lui qui va l’écrire, et on vient de dire que celui qui fait le travail ne doit pas être celui qui le note. Fais-la donc écrire dans un message séparé, avant de parler de la correction : donne-lui en français deux cas dont tu connais la réponse, « pour telle entrée je dois obtenir telle sortie », et fais-lui produire le contrôle seul. Ensuite seulement tu demandes la modification, en interdisant de toucher à ce fichier. Tu n’as pas eu besoin de lire une ligne de code, et le juge n’est plus le jugé.

Et si en cherchant tu réalises qu’il n’existe chez toi aucune commande qui dise réussi ou échoué, tu viens de découvrir quelque chose de plus sérieux que ta modification du jour. Note-le quelque part : c’est le sujet des leçons 10 à 13.

6. Écrire la demande, en trois morceaux

Ce que tu veux, comment il devra te le prouver, et ce qu’il n’a pas le droit de toucher pour y arriver. Dans le même message :

Si ta preuve est de celles qu’il peut boucler tout seul :

<ce que tu veux, précisément>. Ensuite, lance <ta commande de contrôle> et
recommence jusqu'à ce qu'elle passe. Ne modifie pas les tests : traite la
cause, ne supprime pas l'erreur. Montre-moi la sortie de la commande, et la
liste des fichiers que tu as touchés.

Si ta preuve est de celles que tu constates toi-même (une capture, un écran, un comportement), la boucle ne peut pas se refermer sans toi, et la demande le dit :

<ce que tu veux, précisément>. Ne modifie que <les fichiers concernés>. Puis
dis-moi exactement quoi lancer et quoi regarder pour vérifier moi-même que
c'est fait, et donne-moi la liste des fichiers que tu as touchés.

Tu n’as rien à lui coller : il lit lui-même les fichiers dont il a besoin — ceux qu’il juge utiles, ce qui n’est pas toujours les bons, et c’est le sujet de la leçon 3.

Le deuxième morceau change la nature de la réponse. Sans lui, tu obtiens « c’est corrigé ». Avec lui, tu obtiens la commande lancée et ce qu’elle a renvoyé — une pièce que tu peux regarder, au lieu d’une affirmation à laquelle tu peux croire. Relire une preuve coûte moins cher que refaire la vérification soi-même. C’est aussi ce qui rendra possible, plus tard, de lancer une session et d’aller faire autre chose ; pas aujourd’hui.

Le troisième morceau est ce qui empêche le deuxième de se retourner contre toi.

« Ne modifie pas les tests » et « liste les fichiers que tu as touchés » sont deux phrases, et elles font le travail que ta relecture ne fait pas. La seconde surtout : tu n’as pas besoin de savoir lire du code pour voir qu’un fichier de test apparaît dans une liste où tu n’attendais qu’un fichier de source. C’est le contrôle le moins cher du parcours, et il reste faisable dès le premier jour.

7. Lire la réponse, puis décider

Il a fini. Trois choses à regarder, dans cet ordre :

1. La liste des fichiers touchés. Est-ce que ce sont ceux que tu attendais ? Un fichier de plus, surtout un fichier de test ou de configuration, mérite une question.
2. La sortie du contrôle, ou la vérification que tu fais toi-même si ta preuve était de la seconde famille. Pas son résumé : la sortie.
3. Ce qu’il dit avoir fait, en dernier — c’est la partie la moins fiable, parce que c’est la seule qu’il rédige.

Si ça tient : enregistre.

Si ça ne tient pas, la branche seule ne te sauve pas — et c’est le piège le plus courant : tant que les modifications ne sont pas enregistrées, elles te suivent quand tu changes de branche, et supprimer la branche ne les défait pas. Il faut annuler d’abord, jeter ensuite :

git restore --staged --worktree .   # annule les modifications des fichiers suivis, indexées ou non
git status             # regarde ce qui reste : les fichiers nouvellement créés
                       # ne sont pas annulés par la commande précédente
git clean -n -d        # liste ce qui serait supprimé, sans rien toucher : lis la liste
git clean -i -d        # ouvre un menu : tape 4 pour confirmer fichier par fichier
git switch main
git branch -D essai-claude

Les deux lignes du milieu sont celles qu’on oublie, et sans elles la procédure te donne l’inverse de ce qu’elle promet : un fichier qu’il vient de créer et que personne n’a enregistré n’appartient à aucune branche. Il te suit quand tu changes de branche, et il est toujours là après que tu as supprimé celle qui était censée le contenir — mélangé à ton travail, dans la branche principale.

D’où la précaution en deux temps. La première ligne ne supprime rien : elle affiche ce qui partirait. Lis cette liste — s’il y a dedans un fichier qui est à toi, sors de là et occupe-t’en d’abord. La seconde ouvre un menu numéroté : tape 4, ask each, pour qu’il te demande fichier par fichier, car l’option par défaut, celle que tu obtiens en tapant 1 ou simplement Entrée, supprime toute la liste d’un coup sans plus rien demander. Ces fichiers-là ne sont dans aucun point de restauration, donc leur suppression ne se rembobine pas. Ce que tu as exclu de git tout à l’heure, en revanche, n’est pas concerné et reste en place.

C’est le commit d’avant lancement qui te sauve, pas la branche. La branche sert seulement à ce que ton travail en cours ne soit jamais mélangé au sien.

Ce que tu viens de monter est le degré le plus faible de vérification : tout tient dans une seule demande. Il en existe de plus fermes — un objectif réévalué à chaque tour, une barrière automatique qui bloque la fin du tour tant que le contrôle échoue, un relecteur indépendant qui n’a pas fait le travail. Aucun n’est absolu : la barrière elle-même finit par céder après plusieurs blocages consécutifs. Ils viennent plus tard, quand tu en auras l’usage. Aujourd’hui, celui-ci suffit.

Ce que ça ne fait pas

Revenir en arrière n’est pas une sauvegarde. Le fil des points de restauration est troué, et le premier trou s’ouvre sous tes pieds dès aujourd’hui :

1. Les fichiers modifiés par des commandes shell ne sont pas suivis. Le piège majeur : une suite de tests qui régénère des fichiers sort du filet — et tu viens de lui demander de lancer tes tests.
2. Les modifications faites par un subagent (un ouvrier isolé qui travaille à part et ne rend qu’un résumé) ne sont, sauf exception, pas restaurées. Là, il faut git.
3. Les changements venus de l’extérieur ne sont normalement pas captés : ce que tu modifies toi-même hors de l’outil, ou depuis une autre session ouverte en parallèle.
4. Les liens symboliques et physiques sont ignorés. Cas très courants : les fichiers liés par un gestionnaire de paquets, les configurations personnelles liées depuis un dépôt de réglages.

S’y ajoutent deux plafonds : seuls les cent points les plus récents d’une session gardent leurs copies de fichiers, et tout disparaît au bout de trente jours par défaut.

Et rien de ce qui part vers l’extérieur n’est rembobinable, par aucun mécanisme. Ni une base de données, ni un service distant, ni un déploiement. C’est le sujet de la leçon 7, « reprendre, revenir en arrière, ne rien perdre ». Retiens seulement, aujourd’hui, que ton enregistrement d’avant lancement vaut mieux que tout ça.

Le dossier depuis lequel tu lances n’est pas un enclos. C’est la zone où l’approbation peut être automatique — et même dedans, ça dépend du mode : en mode manuel, en principe seules les lectures passent sans qu’on te demande. En dehors, dans les modes où tu valides on te sollicite ; dans le mode automatique, c’est un second modèle qui tranche, et il peut approuver sans rien te demander.

Et le mot « en principe » n’est pas une précaution de style : si le bac à sable intégré tourne en approbation automatique, des commandes qui modifient des fichiers s’exécutent sans rien demander, y compris en mode manuel. Ne prends donc jamais le choix du dossier ni le nom du mode pour une protection à eux seuls.

Il existe bien un vrai bac à sable intégré, mais c’est une fonction qu’on active, pas un comportement par défaut — la leçon 8 s’en occupe, avec le reste des autorisations. Va la lire avant de t’installer dans une habitude.

Une preuve verte ne prouve que ce qu’elle regarde. Il t’a montré la sortie, elle passe : tu sais que ce contrôle-là passe. Tu ne sais rien de ce qu’il ne couvre pas, ni du fait qu’il tourne encore vraiment. Un contrôle qu’on ne vérifie jamais finit par ne plus rien contrôler du tout, sans prévenir — la leçon 13 raconte deux mois vécus exactement comme ça, sur un projet en production.

Le premier jour, on ne configure rien. Tu vas croiser des listes de fichiers à créer et de connecteurs à brancher avant de commencer. Aucun n’a de raison d’exister tant que le manque ne s’est pas fait sentir ; chacun a son moment déclencheur, et c’est l’objet de la leçon 5.

Ce n’est pas un gain de temps, et surtout pas aujourd’hui. Chercher une modification vérifiable prend du temps. Fabriquer une preuve quand on n’en avait pas prend du temps. Écrire les trois morceaux de la demande prend du temps. Ce sont des minutes ajoutées, pas retirées. Ce qu’elles achètent, c’est de savoir ce soir si ce qui a été écrit fait ce que tu voulais.

Ce qui est exact aujourd’hui ne le restera pas. L’ensemble a été contrôlé le 20 août 2026 contre l’instantané de la documentation officielle du même jour. C’est la date du dernier contrôle, pas une promesse de fraîcheur : claude --version et /help répondent pour ta machine, aujourd’hui. Le programme, lui, bouge plus vite que les modèles — plusieurs versions par semaine, retours en arrière compris. Les notions tiennent ; les valeurs par défaut et l’apparence de l’écran se revérifient le jour où tu t’en sers.

Où c’est écrit

• Installation — toutes les méthodes, le tableau de décision Windows, et les mises à jour ;
• Dépannage de l’installation — les échecs connus du script et les méthodes de repli, à garder sous la main pour l’étape 2 ;
• Bonnes pratiques — la section sur le fait de lui donner de quoi vérifier son travail, qui va plus loin que cette leçon ;
• Points de restauration — ce que le fil couvre et ce qu’il laisse passer ;
• Usage des données — ce qui part, ce qui reste, combien de temps, et ce qui change selon l’offre.

Les liens pointent vers les pages anglaises. La version française existe, /fr/ à la place de /en/, mais elle traduit une partie des mots que tu verras sur ton écran, et elle peut être en retard sur le fond ; la leçon 4 explique pourquoi ce parcours garde l’anglais.

Le point de bascule

Tu as basculé le jour où ta demande ne s’arrête plus à ce que tu veux obtenir, mais dit aussi comment il devra te le prouver — et où tu regardes ce qu’il a touché pour fabriquer cette preuve.

Vérifier que c’est passé

Un collègue te dit : « j'ai un compte Claude, j'installe ça ce soir. » Que lui demandes-tu avant qu'il perde sa soirée ?

S’il paye. Le plan gratuit de claude.ai ne donne pas accès à Claude Code : l’installation se passera très bien, et c’est à la connexion qu’il se cognera au mur — en croyant avoir raté une étape. Ce qui ouvre l’accès : un abonnement Pro, Max, Team ou Enterprise, un compte Claude Console, ou l’accès fourni par un cloud d’entreprise.

Tu lui as demandé une correction avec la preuve. Il te montre une sortie de tests toute verte. Qu'est-ce que tu regardes ensuite ?

Quels fichiers ont été touchés. La preuve a été produite par celui que tu contrôles, et les façons de la faire passer sans mauvaise intention sont banales : assouplir un test, le marquer à ignorer, simuler une dépendance, supprimer l’erreur au lieu de traiter sa cause. Un fichier de test dans la liste alors que tu n’attendais qu’un fichier de source, ça se voit sans savoir lire le code. C’est pour ça que la demande contient « ne modifie pas les tests » et « liste les fichiers que tu as touchés ».

Il a lancé ta suite de tests, qui régénère des fichiers au passage, et quelque chose est cassé. Tu veux revenir à l'état d'avant. Sur quoi tu comptes ?

Sur ton enregistrement d’avant lancement, pas sur les points de restauration : les fichiers modifiés par des commandes shell ne sont pas suivis, et une suite de tests qui régénère des fichiers passe précisément par là. Le fil est déroulé derrière toi, mais il ne passe pas par les portes dérobées — la documentation officielle intitule d’ailleurs une section entière « ce n’est pas un remplacement du contrôle de version ». D’où l’ordre des opérations : enregistrer, puis lancer.