Claude Code est un agent en ligne de commande. Tu lui parles en langage naturel, et il agit sur ton projet : il lit les fichiers, en écrit, lance des commandes, fait des commits. La différence avec un chat, c'est l'accès : il travaille sur ton vrai code, pas sur un copier-coller.
suggère.
agit.
C'est le même changement de posture que pour les agents applicatifs : passer de « générer une réponse » à « mener une tâche ». J'en parle dans d'un prompt à l'agentique.
Installation en une commande, puis on lance la session depuis la racine du projet — c'est important : Claude prend le dossier courant comme périmètre de travail.
Une session Claude Code a besoin d'un accès API Anthropic (ou d'un abonnement compatible). Lance-la dans un dépôt git : tu pourras relire et annuler ses changements comme n'importe quel commit.
Le rythme de base : tu décris une intention, Claude explore, propose un plan, puis édite — en te montrant chaque diff avant application. Tu restes dans la boucle : tu acceptes, refuses, ou rediriges.
Si tu ne retiens qu'une chose : écris un CLAUDE.md. C'est un fichier Markdown à la racine, lu automatiquement au début de chaque session, qui sert de mémoire longue du projet. Sans lui, tu réexpliques ta stack et tes conventions à chaque fois — et l'agent devine le reste, souvent mal.
Ce qui fait un bon CLAUDE.md, ce n'est pas la longueur, c'est la densité : les décisions non évidentes, les pièges du projet, les commandes exactes. Chaque ligne t'épargne une correction répétée.
Traite-le comme du code : versionne-le, relis-le en équipe, enrichis-le dès que tu te surprends à répéter une consigne à l'agent. Un CLAUDE.md vivant, c'est un agent qui connaît ton projet au lieu de le deviner.
Il se décline : un CLAUDE.md global (~/.claude/CLAUDE.md) pour tes préférences perso, un par repo pour le projet, et même un par sous-dossier pour un module particulier.
Une skill, c'est une procédure que tu enseignes une fois et que Claude réutilise tout seul. Concrètement : un dossier avec un fichier SKILL.md qui décrit un savoir-faire (déployer, faire une revue de PR, générer un rapport) et, au besoin, des scripts. Claude lit la description et déclenche la skill quand la tâche correspond.
Le SKILL.md tient en une en-tête (nom + description — c'est ce que Claude lit pour décider) et des étapes. La description est la partie critique : dis clairement quand l'utiliser.
La différence avec CLAUDE.md : CLAUDE.md est toujours chargé (le contexte permanent), une skill n'est chargée que quand elle est pertinente. Tu ranges les procédures ponctuelles en skills pour garder le contexte léger.
Une fois les bases en place, Claude Code débloque des capacités qui le font passer d'assistant à équipe. Trois qui changent vraiment la donne :
Claude délègue des tâches isolées à des agents parallèles, chacun avec son propre contexte. Utile pour paralléliser, ou pour qu'un agent « vérificateur » relise le travail d'un autre.
Le Model Context Protocol branche des outils externes : GitLab, Sentry, une base de données, ton propre service. L'agent agit alors bien au-delà des fichiers.
Des prompts réutilisables, versionnés dans .claude/commands. /review, /ship : tes workflows deviennent une commande, partagée avec l'équipe.
Des scripts déclenchés automatiquement à des moments clés (avant un commit, après une édition) : lint, formatage, garde-fous — sans y penser.
Les sous-agents et MCP sont exactement les mêmes idées que côté produit : donner des outils et faire collaborer plusieurs agents. Je les creuse dans donner des outils à un agent.
Une fonctionnalité par boucle. Un agent lâché sur « refais toute l'app » dérive ; sur une tâche cadrée, il est chirurgical.
Commits fréquents. Un changement qui dérape se réverte en une commande — tu n'as jamais peur de le laisser essayer.
Demande-lui de lancer les tests et le build. Un agent qui lit sa propre sortie d'erreur se corrige seul.
Les diffs passent sous tes yeux. Pour les actions destructrices, garde la main — c'est du human-in-the-loop.
Ne le laisse pas courir sans relire, surtout sur des commandes qui suppriment ou déploient. Le même principe que côté produit : human-in-the-loop en vrai.