Claude Code : installer, configurer et coder avec (guide complet 2026)

Ce site, amandinevelt.fr, a été entièrement recodé avec Claude Code : la migration de WordPress vers Next.js, le durcissement de la sécurité du serveur, l'intégration de Google Analytics, la correction des textes alternatifs d'images, et même l'article que vous lisez peut-être juste avant celui-ci. Pas une démo, pas un test isolé — la production réelle d'un site qui reçoit du vrai trafic. Voici comment l'installer, le configurer sérieusement, et ce qui distingue un usage fiable d'un usage qui casse tout en silence.

---

Installer Claude Code

Depuis janvier 2026, l'installation recommandée n'est plus npm install -g @anthropic-ai/claude-code — cette méthode est dépréciée depuis la version 2.1.15 [3]. L'installeur natif ne dépend plus de Node.js, gère lui-même les mises à jour, et s'installe en une commande :

• macOS, Linux, WSL : curl -fsSL https://claude.ai/install.sh | bash
• Windows (PowerShell native) : irm https://claude.ai/install.ps1 | iex

Gardez la méthode npm uniquement si vous avez besoin d'épingler une version précise pour un pipeline CI/CD, ou que votre équipe standardise déjà ses outils via npm [3]. Sur ce projet, l'installation a été faite en tant qu'utilisateur non-root dédié — jamais en `root` ni avec un compte disposant d'un accès `sudo` illimité : c'est la première décision de sécurité, avant même la première ligne de code.

AGENTS.md ou CLAUDE.md : lequel utiliser ?

Les deux fichiers font la même chose en apparence — donner à l'agent le contexte du projet — mais ne sont pas interchangeables. CLAUDE.md est le format propre à Claude Code, et il est toujours prioritaire quand les deux fichiers existent [2]. AGENTS.md est un format partagé, déjà compris par Codex, Cursor, Aider, Zed, Warp et une vingtaine d'autres agents de code [2].

Depuis la version 2.1.277, sortie le 18 septembre 2026, Claude Code lit automatiquement AGENTS.md quand aucun CLAUDE.md n'est présent dans le projet [2]. Concrètement, si votre équipe fait tourner plusieurs agents sur le même dépôt, un seul fichier d'instructions suffit désormais — plus besoin de dupliquer les consignes pour chaque outil.

Sur amandinevelt.fr, les deux fichiers coexistent, avec des rôles distincts :

• CLAUDE.md porte la mémoire permanente du projet : le compte système à utiliser, les règles d'isolation entre comptes, et les contraintes de sécurité héritées d'un incident antérieur sur le serveur — des informations qui ne changent jamais d'un agent à l'autre.
• AGENTS.md porte une consigne technique précise et datée : quelle version de Next.js est utilisée, et où trouver la documentation correspondante avant de modifier du code — un fichier que next dev réécrit lui-même à chaque lancement, donc à commiter avec le reste du travail plutôt qu'à ignorer.

La règle qui se dégage à l'usage : mettez dans CLAUDE.md ce qui doit survivre à tout changement d'outil, et dans AGENTS.md ce qui est réellement portable d'un agent à l'autre. Un projet qui commence petit peut très bien n'avoir qu'un seul fichier.

Les skills : automatiser sans réexpliquer à chaque fois

Une skill est un dossier contenant un fichier SKILL.md — un en-tête YAML (nom, description) suivi d'instructions en markdown — que Claude Code charge automatiquement quand une tâche correspond à sa description [4]. Le format est un standard ouvert, pas propriétaire : il fonctionne aussi avec Codex CLI et Cursor [2].

Ce qui distingue une bonne skill d'une skill qui ne se déclenche jamais : la description doit se lire comme une règle de routage, précise sur le moment où elle s'applique — pas un résumé vague de ce qu'elle fait [4]. Le reste des bonnes pratiques tient en trois points : une action par skill plutôt qu'un couteau suisse, du code déterministe pour les tâches déterministes (un script qui trie ou valide, plutôt que de compter sur la prudence du modèle), et un fichier principal court, avec le détail poussé dans des fichiers annexes chargés à la demande [4].

Exemple concret sur cette VM : un audit de sécurité complet (pare-feu, détection d'intrusion, mises à jour automatiques, surveillance des accès) est encapsulé dans une skill dédiée. Plutôt que de réexpliquer à chaque session ce qu'il faut vérifier et dans quel ordre, une seule commande déclenche la procédure complète, toujours identique — c'est exactement le genre de tâche répétitive, à checklist fixe, qu'une skill remplace avantageusement.

VSCode ou terminal : intégrer proprement

Claude Code fonctionne dans un terminal seul, mais l'extension VSCode ajoute la vue des modifications en cours, l'ouverture directe des fichiers touchés, et le partage du contexte de l'éditeur (fichier ouvert, sélection) avec l'agent [1]. Deux réglages à ne pas négliger dans ce contexte : installer l'extension YAML, pour que VSCode signale une erreur d'indentation dans l'en-tête d'une skill avant même de la lancer, et vérifier que le mode de permission par défaut de la session — visible dans la barre de statut de l'extension — correspond à ce que vous attendez, puisque VSCode peut lire un réglage différent de celui du terminal [1].

Vérification et reproductibilité : ce qui compte vraiment

C'est le point que les guides d'installation passent sous silence, et c'est celui qui détermine si un agent de code est un outil de production ou un risque. Claude Code applique trois couches indépendantes, qui ne se substituent pas l'une à l'autre [1] :

• Les permissions, premier filtre : elles décident si un outil a le droit de s'exécuter. Elles se configurent dans quatre fichiers settings.json empilés — réglages d'entreprise, réglages utilisateur (~/.claude/settings.json), réglages de projet partagés (.claude/settings.json, à commiter) et réglages de projet locaux (.claude/settings.local.json, propres à chaque développeur) [1]. Les règles s'évaluent dans cet ordre : refus, puis confirmation, puis autorisation — une règle d'autorisation ne peut jamais percer un refus plus large [1].
• Le bac à sable (sandbox), second filtre : une fois qu'une commande a le droit de s'exécuter, le bac à sable limite ce qu'elle peut réellement toucher, au niveau du système d'exploitation plutôt qu'au niveau des règles. Sur macOS, il s'appuie sur Seatbelt, déjà intégré au système ; sur Linux et WSL2, sur deux paquets à installer une fois [5]. Il s'active avec la commande /sandbox, qui indique elle-même ce qui manque.
• Les hooks, troisième filtre : un script personnalisé qui s'exécute avant chaque appel d'outil et peut bloquer un cas précis que les règles de permission ne couvrent pas [1].

Sur ce projet, cette discipline se traduit concrètement : aucune commande n'a jamais été lancée avec un accès root illimité, un compte technique dédié exécute le code applicatif, et chaque déploiement suit la même séquence vérifiable — vérification des types, lint, build dans un conteneur isolé, puis contrôle HTTP des pages concernées avant de considérer le travail terminé. Ce n'est pas une checklist imposée de l'extérieur : c'est la condition pour qu'un agent qui peut lire et écrire du code sur un serveur en production reste un gain de temps, pas un pari.

La reproductibilité vient de la même logique : un agent qui exécute toujours la même séquence de vérification, sur un environnement isolé et documenté, produit un résultat qu'on peut recommencer à l'identique — et surtout, dont on peut expliquer précisément ce qui a été testé et ce qui ne l'a pas été.

Ce que ça a changé, concrètement, pour amandinevelt.fr

Quelques exemples réels tirés du journal de bord de ce site, pas des cas d'usage génériques :

• La migration complète du site depuis WordPress vers Next.js, contenu par contenu, avec vérification que chaque URL réponde correctement après bascule.
• Un audit et une réécriture de la politique de confidentialité pour refléter les vrais outils utilisés (hébergeur, solution d'e-mailing) plutôt qu'une politique générique copiée-collée.
• Le remplacement d'icônes texte par des icônes SVG cohérentes sur tout le site, et la correction d'une dizaine de textes alternatifs d'images qui ne décrivaient rien.
• L'intégration d'un bandeau de consentement aux cookies avant l'ajout de Google Analytics — dans cet ordre, pas l'inverse.
• La conversion des images du contenu éditorial vers un format optimisé, avec vérification que chaque page continue de répondre correctement ensuite.

Aucune de ces tâches n'est spectaculaire prise isolément. Ce qui change, c'est qu'elles ont toutes été faites avec le même niveau de vérification qu'un développeur expérimenté appliquerait — pas parce que l'outil est infaillible, mais parce que la vérification fait partie du travail, pas une étape qu'on saute pour aller plus vite.

Faut-il vous y mettre ?

Si vous codez déjà et que vous passez du temps sur des tâches répétitives — migrations, refactoring, mise à jour de dépendances, corrections de contenu à grande échelle — l'installation prend une minute et le format AGENTS.md signifie que ce que vous apprenez ici reste valable si vous testez un jour Codex ou un autre agent [2]. Le vrai investissement n'est pas dans l'installation : il est dans la discipline de vérification, qui ne se raccourcit pas sans risque, quel que soit l'agent utilisé. Si coder ne vous intéresse pas, les plateformes no-code comme Make, Zapier ou n8n couvrent une bonne partie des mêmes besoins d'automatisation — voir notre guide sur les agents IA no-code.