Aller au contenu principal

Claude Code en action

Mis à jour le 29 juillet 2026

Claude Code en action

Claude Code est livré avec un ensemble complet d’outils intégrés qui couvrent les tâches courantes de développement : lire des fichiers, écrire du code, exécuter des commandes, parcourir des répertoires. Pris isolément, aucun de ces outils n’a de quoi impressionner — n’importe quel script shell fait la même chose depuis trente ans. Ce qui rend Claude Code réellement puissant, c’est la façon dont il combine ces outils pour résoudre des problèmes complexes en plusieurs étapes, en décidant de l’action suivante à partir de ce que la précédente vient de lui apprendre.

Les outils intégrés

Dès que vous lancez Claude Code dans votre terminal, il dispose du jeu d’outils suivant, sans aucune configuration de votre part :

OutilDescription
ReadLire le contenu d’un fichier
WriteCréer ou écraser un fichier
EditModifier une partie spécifique d’un fichier
BashExécuter une commande shell
GlobRechercher des fichiers par motif (ex: **/*.tsx)
GrepRechercher du texte dans le contenu des fichiers
TodoWriteGérer une liste de tâches internes

Ces sept outils de base couvrent la majorité des besoins réels. Remarquez la présence de TodoWrite, qui détonne dans la liste : il n’agit pas sur votre projet mais sur l’organisation interne de Claude. Il lui sert à découper une tâche longue en étapes et à ne pas perdre le fil au bout de vingt minutes de travail. La puissance de l’ensemble ne vient donc pas de l’inventaire, mais de l’enchaînement.

Un exemple concret

Imaginons une demande formulée comme vous la formuleriez à un collègue : « Corrige le bug dans le formulaire de connexion — les utilisateurs voient une erreur 500 quand ils soumettent. » Vous n’indiquez aucun fichier, aucune ligne, aucune piste de départ. Voici la séquence que Claude déroule :

  1. Grep — recherche les fichiers liés à « login », « connexion » ou « auth »
  2. Read — lit le handler de l’endpoint et le composant formulaire
  3. Bash — lance les tests existants pour reproduire l’erreur
  4. Edit — corrige le bug identifié (par exemple une validation manquante)
  5. Bash — relance les tests pour vérifier que le fix fonctionne
  6. Read — vérifie qu’il n’y a pas d’autres appels au même code qui pourraient être affectés

Tout cela se déroule automatiquement, sans que vous ayez à valider chaque transition. L’essentiel se joue dans la logique de l’enchaînement plutôt que dans les outils eux-mêmes : le Grep de l’étape 1 détermine ce que Read ouvre à l’étape 2, l’échec du test à l’étape 3 oriente la correction de l’étape 4, et la dernière lecture n’existe que parce que Claude a constaté, en corrigeant, que la fonction touchée était appelée ailleurs. Aucune de ces six étapes n’était écrite d’avance. C’est un raisonnement conduit sur des faits observés, et c’est pour cette raison qu’il résiste à un projet dont personne ne lui a expliqué l’architecture.

Ce qui différencie Claude Code

La comparaison la plus parlante reste celle de l’assistant conversationnel classique. Celui-ci vous rend un extrait à copier-coller : il ignore vos noms de variables, ne connaît pas votre version de framework et ne saura jamais si son code compile chez vous. Claude Code explore votre projet réel — vos fichiers, vos conventions, votre architecture — et non un exemple générique tiré d’une documentation.

Il exécute ensuite de vraies commandes, et c’est le point qui change la nature du travail. Lancer votre suite de tests, votre build ou votre linter transforme la correction proposée : ce n’est plus une hypothèse plausible, c’est un changement vérifié avant de vous être soumis. Cette vérification alimente à son tour la suite, car Claude ne s’arrête pas après une seule action et poursuit jusqu’à ce que la tâche soit terminée.

Reste l’adaptation au contexte, qui est la conséquence naturelle des deux précédentes. Claude tient compte de ce qu’il découvre en cours de route : un test qui échoue pour une raison inattendue le fait changer de direction, là où un plan écrit à l’avance l’aurait conduit à s’entêter. C’est cette capacité à combiner lecture, écriture et exécution qui transforme un simple modèle de langage en véritable partenaire de développement.