Claude Code comment ça marche : l’outil lit votre dépôt, transforme votre demande en plan d’action, propose ou exécute des appels d’outils, puis vérifie le résultat avec les tests et Git. Il ne s’agit pas d’un simple chatbot dans un terminal, mais d’un agent qui boucle entre raisonnement, lecture du contexte, modification des fichiers et validation. Vous gardez toutefois la main sur les permissions et sur chaque opération sensible.

La bonne méthode consiste à ouvrir Claude Code à la racine du projet, lui demander d’abord d’inspecter l’architecture, puis de formuler un plan avant toute écriture. Ce guide explique son fonctionnement interne, son cycle d’exécution, la gestion des fichiers, les permissions, Git, MCP et les limites à connaître en production.

Claude Code comment ça marche en pratique

Claude Code est l’agent de développement en ligne de commande d’Anthropic. Il utilise un modèle de la famille Claude, notamment Claude Sonnet 5 ou Claude Opus 4.8 selon votre compte et la tâche, pour interpréter une instruction en langage naturel. Le modèle ne modifie pas directement votre ordinateur. Il demande à l’application Claude Code d’exécuter des outils autorisés, comme lire un fichier, rechercher un symbole, lancer une commande ou écrire une modification.

Cette distinction est essentielle. Le modèle produit une décision et un appel d’outil, tandis que le programme local applique les règles de sécurité, affiche une confirmation si nécessaire et renvoie le résultat au modèle. Claude Code peut donc comprendre un dépôt réel, mais il ne possède pas un accès magique et illimité à votre machine. Son périmètre dépend du dossier courant, de la configuration et des autorisations que vous avez acceptées.

cd mon-projet
claude

# Première demande recommandée
> Analyse l’architecture du projet, indique les points d’entrée,
> les commandes de test et les risques avant de modifier quoi que ce soit.

Pour une première installation, consultez aussi notre guide d’installation de Claude Code sur Windows, macOS, Ubuntu et VS Code. L’installation et le fonctionnement sont deux sujets différents : le premier prépare le terminal, le second organise la collaboration avec l’agent.

L’architecture agentique : modèle, outils et boucle d’exécution

Le fonctionnement repose sur une boucle agentique. Vous donnez une consigne. Claude analyse le contexte disponible et choisit une action. L’application exécute cette action, renvoie sa sortie, puis le modèle décide s’il doit poursuivre. La boucle s’arrête lorsque la tâche est terminée, lorsqu’une permission est refusée ou lorsque Claude estime qu’une question nécessite votre décision.

Dans un correctif classique, la séquence ressemble à ceci : recherche des fichiers concernés, lecture des fonctions, formulation d’un plan, modification, exécution d’un test, lecture de l’erreur éventuelle, correction et résumé final. Chaque résultat de commande devient une nouvelle pièce de contexte. L’agent ne devine donc pas toujours l’état du dépôt, il l’observe progressivement.

Demande utilisateur
        ↓
Analyse du contexte et du plan
        ↓
Appel d’un outil autorisé
        ↓
Résultat du fichier, du test ou de la commande
        ↓
Nouvelle décision de l’agent
        ↓
Validation humaine ou étape suivante

Cette boucle explique aussi pourquoi une consigne précise donne de meilleurs résultats. « Répare ce projet » laisse trop de décisions ouvertes. « Identifie la cause du test rouge, propose un plan sans écrire, puis applique uniquement le correctif minimal et relance la commande de test » définit un objectif, une limite et une preuve attendue.

Comment Claude Code comprend votre projet

Claude Code ne charge pas automatiquement chaque fichier du dépôt dans une seule fenêtre. Il commence avec votre demande, les fichiers de règles éventuellement présents et les éléments qu’il juge pertinents. Il peut parcourir l’arborescence, rechercher des noms de fonctions, lire des fichiers ciblés et consulter l’historique Git. Cette sélection progressive réduit le bruit et évite de gaspiller le contexte sur des dossiers générés.

Les fichiers de configuration du projet jouent un rôle important. Un fichier de consignes peut préciser les commandes de test, le style de code, les conventions de commit, les dossiers à ne pas toucher et les contraintes de déploiement. Ces règles doivent rester courtes, vérifiables et orientées vers le dépôt. Une longue documentation contradictoire devient un signal difficile à hiérarchiser.

# Exemples de zones utiles à inspecter
find . -maxdepth 2 -type f | sort
grep -R "TODO|FIXME" -n src tests
npm test
git status --short

Il faut distinguer mémoire de session et mémoire métier. Claude Code peut conserver le fil de la conversation courante, mais il ne connaît pas automatiquement les décisions prises dans tous vos anciens projets. Pour un dépôt durable, écrivez les conventions importantes dans la documentation versionnée, par exemple dans un fichier de contribution ou dans un guide du projet. Cela rend le comportement reproductible pour l’équipe et pour l’agent.

Les permissions : ce que l’agent peut réellement faire

Les permissions constituent le garde-fou principal. Selon l’action et la configuration, Claude Code peut demander votre validation avant d’écrire un fichier, d’exécuter une commande ou de réaliser une opération potentiellement destructive. Une lecture de code est généralement moins risquée qu’un rm, une migration de base de données ou un déploiement distant.

Ne désactivez pas les confirmations par réflexe. Le mode sans permission peut être utile dans un environnement éphémère, avec un dépôt jetable et des tests automatisés, mais il est dangereux sur votre poste principal ou sur un serveur. La règle la plus saine est de commencer en mode supervisé, d’observer les commandes proposées, puis d’automatiser uniquement une étape comprise et réversible.

Avant d’autoriser une commande, vérifiez :
1. Le dossier courant
2. Les fichiers touchés
3. La présence d’une sauvegarde ou d’un commit
4. Les effets réseau et les secrets lus
5. La possibilité d’annuler l’opération

Les secrets ne doivent jamais être collés dans une conversation. Utilisez des variables d’environnement, des fichiers ignorés par Git et des permissions minimales. Un agent capable de lire un fichier peut exposer une clé si vous lui demandez de diagnostiquer un répertoire contenant des identifiants. L’outil améliore le développement, il ne remplace ni la gestion des secrets ni la revue humaine.

Modifier du code sans perdre le contrôle

Une modification fiable suit quatre temps : comprendre, planifier, appliquer, vérifier. Demandez d’abord les fichiers concernés et la cause probable. Faites ensuite préciser les changements prévus. Après l’écriture, inspectez le diff et exigez un test adapté. Cette discipline évite les refactorisations excessives déclenchées par une demande qui semblait pourtant locale.

Les demandes à périmètre fermé fonctionnent particulièrement bien. Indiquez le dossier autorisé, le comportement attendu, les fichiers exclus et la commande de validation. Pour un bug WordPress, vous pouvez par exemple demander une analyse de la fonction précise, sans autoriser de modification dans le répertoire des dépendances ni dans la configuration de production.

Corrige uniquement le bug dans src/auth/session.ts.
Ne change pas l’API publique et ne modifie pas package-lock.json.
Commence par un plan de trois étapes. Après le correctif,
exécute le test ciblé puis affiche git diff --check.

Claude Code peut produire une réponse plausible malgré une compréhension incomplète. Le test, le diff et la revue restent donc indispensables. Un résultat « terminé » signifie que l’agent a fini sa boucle, pas que le correctif est prouvé dans tous les environnements. Les erreurs de dépendance, les cas limites et les effets de bord métier exigent une validation indépendante.

Git, tests et travail en équipe

Git fournit à Claude Code un historique et un filet de sécurité. L’agent peut lire le statut, comparer des versions, rechercher l’origine d’une ligne et préparer un commit si vous l’y autorisez. Travaillez de préférence sur une branche dédiée ou dans un worktree isolé. Vous pourrez ainsi rejeter les changements sans mélanger une expérimentation avec une fonctionnalité en cours.

git switch -c fix/session-expiration
claude

# Après le travail de l’agent
git diff --stat
git diff --check
npm test
git status --short

Ne demandez pas à l’agent de créer un commit tant que vous n’avez pas lu le diff. Le message de commit doit décrire un changement réellement vérifié, pas une intention. Pour les équipes, ajoutez une revue humaine et une intégration continue. Claude Code peut préparer une pull request, mais le dépôt distant, les règles de branche et les secrets de CI restent des responsabilités de l’équipe.

Notre guide sur Claude Code avec GitHub, les actions et les pull requests détaille ce workflow. Pour comparer une approche différente, voyez aussi ce qui est réellement possible avec Claude Code gratuit.

Le rôle de MCP et des services externes

MCP, pour Model Context Protocol, permet de connecter Claude Code à des outils externes qui exposent leurs propres ressources et actions. Un serveur MCP peut donner accès à une base de données de test, à une documentation, à un outil de ticketing ou à un environnement WordPress local. Claude choisit alors une action dans cette interface, mais le risque augmente avec le nombre de systèmes connectés.

Commencez par des serveurs en lecture seule. Séparez les environnements de test et de production, documentez les permissions et refusez toute action qui n’a pas besoin d’être automatisée. Un serveur MCP compromis ou mal configuré peut transformer une simple demande de diagnostic en accès indirect à des données sensibles.

{
  "mcpServers": {
    "docs-locales": {
      "command": "node",
      "args": ["./tools/docs-server.mjs"],
      "env": {
        "DOCS_ROOT": "./docs"
      }
    }
  }
}

Le fichier de configuration doit être revu comme du code. N’ajoutez pas de serveur téléchargé au hasard, vérifiez sa source et limitez les variables d’environnement transmises. Pour un projet WordPress, un environnement local jetable est préférable à une connexion directe à la base du site en ligne.

Une méthode efficace pour utiliser Claude Code au quotidien

Commencez chaque session par une demande de reconnaissance. Donnez ensuite une tâche atomique, une contrainte explicite et une preuve de réussite. Si la tâche dépasse quelques fichiers, demandez un plan avant l’écriture. Enfin, faites résumer les changements, les tests exécutés et les points restant à vérifier.

Contexte : cette application utilise Node.js et PostgreSQL.
Objectif : corriger le timeout de la route /reports.
Contraintes : pas de changement de schéma, pas de nouvelle dépendance.
Processus : analyse, plan, implémentation, test ciblé, diff final.
Sortie attendue : cause, fichiers modifiés, test et limites connues.

Une bonne consigne ne demande pas à l’agent d’être créatif partout. Elle définit les endroits où il peut proposer et ceux où il doit s’arrêter. Pour une tâche sensible, demandez une analyse seule. Pour une tâche répétitive, utilisez un script contrôlé et faites vérifier sa sortie. Pour une exploration, acceptez plusieurs hypothèses, mais ne transformez pas la première hypothèse en modification sans preuve.

Le choix du modèle dépend aussi du coût et de la difficulté. Sonnet 5 convient aux corrections, tests et évolutions courantes. Opus 4.8 peut être pertinent pour un dépôt volumineux ou une analyse complexe. Ce choix ne supprime pas la nécessité d’un contexte propre : un modèle puissant avec une demande ambiguë peut produire plus de changements, pas forcément de meilleurs changements.

Limites, sécurité et erreurs à éviter

Claude Code peut halluciner un nom de fichier, mal interpréter une convention ou considérer qu’un test partiel suffit. Il peut également modifier un fichier généré, ignorer une dépendance implicite ou proposer une commande adaptée à Linux alors que votre projet tourne sous Windows. Vérifiez toujours le système d’exploitation, les versions, le statut Git et la commande de validation réelle.

La confidentialité mérite une attention particulière. N’envoyez pas de données clients, de secrets, de dumps de production ou de certificats privés dans le contexte. Nettoyez les journaux avant partage. Pour un dépôt professionnel, définissez une politique claire sur les données autorisées, la conservation, les comptes utilisés et la revue des changements. La sécurité doit être traitée comme une contrainte de conception, pas comme une option après l’installation.

Enfin, ne confondez pas automatisation et délégation complète. Claude Code accélère la recherche, la rédaction et la validation, mais la décision métier, l’acceptation d’une migration et la mise en production restent humaines. Un agent supervisé et bien cadré est souvent plus fiable qu’un agent entièrement autonome lancé sur un périmètre mal défini.

Sources

FAQ : Claude Code comment ça marche

Claude Code modifie-t-il les fichiers automatiquement ?

Claude Code peut modifier les fichiers, mais l’opération dépend des permissions accordées et du mode utilisé. Dans une session supervisée, l’agent présente généralement l’action et demande une validation pour les écritures sensibles. Il est recommandé de travailler sur une branche Git, de lire le diff et de lancer les tests avant d’accepter le résultat.

Claude Code fonctionne-t-il sans VS Code ?

Oui. Claude Code est d’abord une application en ligne de commande et fonctionne dans un terminal macOS, Linux, Windows avec WSL2, VS Code ou un IDE JetBrains. VS Code n’est donc pas une dépendance. L’agent utilise le dossier courant et les outils du système pour inspecter et modifier le projet.

Quelle est la différence entre Claude et Claude Code ?

Claude est l’assistant conversationnel, tandis que Claude Code est l’agent spécialisé dans un dépôt de développement. Claude Code dispose d’outils pour lire des fichiers, rechercher du code, exécuter des tests et travailler avec Git. Il peut donc agir sur un projet local, alors qu’une conversation web reste principalement centrée sur le contenu fourni dans l’interface.

Claude Code peut-il déployer un site en production ?

Techniquement, Claude Code peut exécuter une commande de déploiement si votre environnement et vos permissions l’autorisent. Ce n’est pas une bonne raison pour lui donner un accès direct à la production. Préférez une branche, une CI contrôlée, des secrets isolés et une validation humaine avant la mise en ligne. Le déploiement doit rester traçable et réversible.

Comment éviter que Claude Code casse mon projet ?

Demandez une analyse avant toute écriture, limitez le périmètre, utilisez Git, refusez les commandes destructrices et imposez un test de validation. Ne fournissez pas de secrets et utilisez un environnement de test. Cette combinaison réduit les risques bien plus efficacement qu’une consigne vague demandant simplement à l’agent de « tout réparer ».

G
WP Admin Lab

Architecte web full-stack. WordPress, performance, data et sécurité. Notes de terrain, tests reproductibles et retours d'expérience.