Qu'est-ce que Claude Code

Pourquoi ce chapitre est le plus utile

La plupart des explications sur Claude CodeClaude CodeIAInterface en ligne de commande agentique qui lit, édite et exécute des actions dans un dépôt de code sous contrôle de permissions, par opposition à un simple chat web.Voir dans le glossaire commencent par une liste de fonctionnalités. Ce n'est pas l'angle utile. Ce qui détermine si l'outil vous fait gagner du temps ou vous en fait perdre, c'est de comprendre ce qu'il fait mécaniquement quand vous lui donnez une instruction — et où se situe la frontière entre ce qu'il décide seul et ce qui requiert votre validation.

Ce chapitre pose cette mécanique avant d'entrer dans l'installation et les commandes (chapitres suivants). Sans elle, on utilise l'outil soit avec une méfiance excessive qui annule le gain de productivité, soit avec une confiance excessive qui finit par produire un commit cassé ou une commande destructrice exécutée sans relecture.

Chat web et agent CLI : une différence de nature, pas de degré

Un chat web — celui que vous utilisez dans un navigateur pour poser une question — produit du texte. Il n'a pas accès à votre dépôt, ne voit pas l'arborescence de vos fichiers, ne peut pas lancer une commande. Le cycle est simple : vous copiez une question, le modèle répond, vous copiez la réponse dans votre éditeur ou votre terminal. Toute la médiation entre la réponse et le résultat concret repose sur vous.

Claude Code change ce cycle. C'est un agent en ligne de commandeAgent CLIIAProgramme en terminal qui enchaîne raisonnement et outils (lecture, édition, commandes) pour accomplir une tâche dans un environnement local.Voir dans le glossaire : il tourne dans votre terminal, à l'intérieur (ou à proximité) d'un dépôt de code réel. Il peut lire des fichiers, proposer des modifications, exécuter des commandes shell, lancer des tests, consulter des logs d'erreur, puis ajuster son action en fonction du résultat obtenu. La différence n'est pas une question d'intelligence du modèle sous-jacent — c'est une question d'outillage : le chat web n'a que du texte en entrée et en sortie, l'agentagentIASystème qui enchaîne des appels d'outils de façon autonome pour atteindre un objectif : il planifie, agit, observe, recommence. Sa fiabilité décroît exponentiellement avec le nombre d'étapes.Voir dans le glossaire CLI a des outilstool callingIACapacité d'un agent ou d'un LLM à invoquer des outils externes (API, calcul, recherche) pendant le raisonnement.Voir dans le glossaire (lecture de fichier, édition, exécution shell, recherche) qu'il choisit d'invoquer selon la tâche.

Un chat web vous décrit comment corriger un bug. Claude Code peut lire le fichier concerné, appliquer le correctif, lancer la suite de tests, lire le résultat, et recommencer si un test échoue — jusqu'à obtenir un état cohérent ou jusqu'à vous demander un arbitrage. La boucle de vérification fait partie de l'outil, elle n'est plus entièrement à votre charge.

La boucle lire / éditer / exécuter / vérifier

C'est le mécanisme central à retenir de ce chapitre. Face à une instruction (« corrige ce bug », « ajoute un test pour cette fonction », « migre ce fichier vers la nouvelle API »), l'agent ne génère pas une réponse figée en un seul passage. Il itère :

1. Lire — parcourir les fichiers pertinents, chercher les définitions, comprendre les conventions déjà en place dans le dépôt.
2. Éditer — proposer une modification ciblée, généralement sous forme de diff plutôt que de réécriture complète.
3. Exécuter — lancer une commande pour vérifier l'effet : tests, linter, compilation, script de reproduction du bug.
4. Vérifier — lire le résultat de l'exécution et décider s'il faut ajuster, continuer, ou s'arrêter pour demander une clarification.

Cette boucle est aussi ce qui rend l'outil coûteux en jetons et parfois lent : chaque relecture de fichier, chaque exécution de test consomme du contextefenêtre de contexteIAQuantité de texte qu'un modèle peut prendre en compte simultanément : question, documents fournis et historique. Au-delà, les éléments les plus anciens sortent du champ.Voir dans le glossaire et du temps. Un agent CLI bien utilisé n'est pas celui qui boucle le plus longtemps possible, mais celui à qui l'on donne une tâche assez bornée pour que la boucle converge en peu d'itérations.

Permissions, mode plan et validation humaine

Un agent qui peut exécuter des commandes shell peut, en théorie, supprimer des fichiers, pousser un commit, ou modifier une configuration de production. C'est pourquoi Claude Code fonctionne avec un système de permissions : certaines actions (lecture de fichiers, recherche) sont peu risquées et peuvent s'exécuter sans confirmation, d'autres (écriture, exécution de commande, opérations réseau) déclenchent une demande de validation explicite avant d'avoir lieu, sauf si vous avez choisi d'élargir l'autorisation pour une session ou un type d'action précis.

Deux façons de travailler avec ça au quotidien :

• Mode question / plan — l'agent expose d'abord ce qu'il compte faire (fichiers concernés, commandes envisagées) avant de toucher au dépôt. Utile pour une tâche ambiguë ou à fort impact.
• Mode exécution directe avec confirmation par action — chaque commande ou édition sensible est présentée avant d'être appliquée ; vous approuvez ou refusez au cas par cas.

Approuver une commande signifie que vous l'autorisez à s'exécuter, pas que vous avez vérifié qu'elle est correcte. Lire le diff proposé avant de valider une édition, et lire la commande elle-même avant de valider une exécution, reste indispensable — en particulier pour tout ce qui touche à la suppression de fichiers, aux migrations de base de donnéesdonnéesIAEnsemble d'informations structurées ou non utilisées pour entraîner, évaluer ou alimenter un modèle. La qualité, la quantité et la représentativité des données sont les facteurs décisifs pour les performances en apprentissage automatique.Voir dans le glossaire, ou aux appels réseau vers un environnement partagé.

La revue humaine du diff produit par l'agent n'est pas une étape optionnelle de politesse : c'est le mécanisme qui transforme une proposition générée en changement engagé. Un agent CLI ne remplace pas la revue de code, il en déplace le point d'application — vous relisez un diff produit par l'agent au lieu d'écrire ce diff vous-même, mais la responsabilité du contenu qui part en commit reste humaine.

Où l'agent s'insère dans un flux de développement existant

Claude Code ne remplace aucun outil de votre chaîne actuelle : il s'insère dedans. Concrètement, il s'utilise dans un terminal ouvert sur un dépôt Git, souvent sur une branche de travail dédiée, et produit des modifications qui suivent le même chemin que celles écrites à la main : diff, revue, commit, pull request. Rien dans son fonctionnement ne contourne les garde-fous déjà en place — hooks de pré-commit, intégration continue, revue par les pairs.

Un test d'intégration échoue de façon intermittente en CI. Un chat web, avec seulement le message d'erreur collé dans la conversation, ne peut que formuler des hypothèses. Claude Code, lancé dans le dépôt, peut lire le test, remonter jusqu'à la fonction testée, exécuter le test en local plusieurs fois pour confirmer l'intermittence, inspecter les logs, et proposer un correctif accompagné d'une exécution qui montre que le test passe désormais de façon stable. La différence tient à l'accès direct au code et à l'exécution, pas à un raisonnement plus poussé.

Donner du contexte à l'agent : CLAUDE.md et MCP

Un agent qui découvre un dépôt à chaque session perd du temps à redécouvrir les mêmes conventions. Un fichier CLAUDE.mdCLAUDE.mdIAFichier Markdown de consignes stables placé dans un projet pour orienter Claude Code (stack, conventions, périmètre, interdits) sans les répéter à chaque prompt.Voir dans le glossaire, placé à la racine du projet, sert à documenter une fois pour toutes ce que l'agent doit savoir avant d'agir : commandes de test à utiliser, conventions de style, zones du code à ne jamais modifier automatiquement, particularités de l'architecture. Ce fichier est lu au démarrage et oriente les décisions de l'agent sans que vous ayez à répéter ce contexte à chaque instruction.

Trois lignes indiquant la commande de test, le gestionnaire de paquets utilisé, et un dossier à ne pas toucher réduisent déjà nettement le nombre d'allers-retours nécessaires pour cadrer une tâche. Ce fichier fait l'objet d'un chapitre dédié plus loin dans la formation.

Au-delà du contexte textuel, le Model Context ProtocolMCPIAModel Context Protocol : protocole permettant de brancher des outils et sources externes (docs, tickets, bases) à un agent LLM via des serveurs dédiés.Voir dans le glossaire (MCP) permet de connecter l'agent à des sources externes structurées — un système de tickets, une base de documentation interne, un outil de recherche — via un protocole standardisé plutôt que par copier-coller manuel dans la conversation.

C'est un protocole qui permet à l'agent d'appeler des outils externes de façon structurée (lister des tickets, interroger une base) au lieu de se limiter au texte que vous lui fournissez directement. Le sujet est développé dans un chapitre ultérieur ; à ce stade, retenez seulement qu'il existe et qu'il élargit les sources que l'agent peut consulter, sans changer la mécanique de permissions vue plus haut.

Ce que Claude Code ne fait pas

Certaines limites ne sont pas des bugs à corriger dans une version future : elles découlent de ce que l'outil est structurellement.

• Aucun jugement métier autonome. L'agent applique une instruction et les conventions qu'il trouve dans le dépôt ; il n'a pas de connaissance des priorités business, des contraintes contractuelles, ou des risques réglementaires propres à votre organisation, sauf si vous les lui donnez explicitement.
• Dépendance totale au contexte fourni. Un dépôt mal documenté, un ticket ambigu, ou une instruction imprécise produisent une proposition de correction plausible mais potentiellement hors sujet. L'agent ne devine pas une intention qui n'est écrite nulle part.
• Pas de garantie d'exhaustivité. Une modification peut faire passer les tests existants sans pour autant couvrir tous les cas limites du problème réel, en particulier si la suite de tests elle-même est incomplète.
• Capacité d'action réelle, donc risque réel. Contrairement à un chat web qui ne peut que décrire une commande destructrice, un agent CLI peut l'exécuter si vous l'y autorisez. La vigilance sur les permissions n'est pas une précaution excessive, elle correspond au niveau de risque effectivement introduit par l'outillage.
• Aucune mémoire persistante entre sessions par défaut. Sauf configuration explicite (CLAUDE.md, notes de session), chaque nouvelle conversation repart sans connaissance des décisions prises la veille.

Ces limites ne rendent pas l'outil inutile — elles définissent le périmètre dans lequel il est fiable : des tâches bornées, sur un dépôt dont le contexte est explicité, avec une revue humaine du résultat avant tout engagement définitif (commit, déploiement, suppression).

Secrets et environnements sensibles

Un agent qui lit des fichiers et exécute des commandes peut, sans intention malveillante, faire apparaître un secret dans une sortie de terminal, un log, ou un message d'erreur — clé d'API laissée dans un fichier de configuration, jeton dans une variable d'environnement affichée par une commande de debug. Aucune propriété du modèle ne garantit qu'un secret exposé dans le contexte de travail ne se retrouve pas recopié ailleurs.

La règle à appliquer est celle de tout outil partagé : ne jamais placer de clé, mot de passe ou jeton d'accès en clair dans un fichier lu par l'agent ou dans une instruction textuelle. Utiliser un gestionnaire de secrets ou des variables d'environnement non loguées, et limiter les permissions réseau de l'agent sur les environnements de production exactement comme vous limiteriez l'accès de tout script automatisé.

Ce que couvre la suite de cette formation

Ce premier chapitre a posé le vocabulaire et les mécanismes de base : agent CLI, boucle lire/éditer/exécuter, permissions, CLAUDE.md, MCP, et les limites structurelles à garder en tête. Les huit chapitres suivants entrent dans le concret : installation et premiers lancements, formulation d'instructions efficaces, lecture et validation des diffs proposés, usage du mode plan pour les tâches à risque, rédaction d'un CLAUDE.md utile, connexion à des outils externes via MCP, intégration dans un flux Git existant, et enfin les pratiques à éviter en environnement professionnel. L'objectif n'est pas de vous rendre dépendant de l'outil, mais de vous permettre de décider, tâche par tâche, s'il apporte un gain réel — et dans quelles conditions de sécurité.