Vous savez maintenant installer et lancer Claude Code. Mais entre un développeur qui obtient exactement ce qu’il veut et un autre qui tourne en rond, la différence tient rarement à l’outil. Elle tient à la façon de formuler les demandes. Dans ce module, vous allez apprendre l’art du dialogue avec un agent : quelques réflexes simples, applicables dès aujourd’hui, qui transforment une réponse approximative en résultat précis.

Ce que vous allez apprendre

• Formuler des demandes précises grâce au trio contexte, objectif, contraintes
• Référencer un fichier avec @, coller une erreur complète ou une capture d’écran
• Travailler par petites itérations et reprendre la main avec Échap
• Poser les questions qui font mouche pour explorer un projet inconnu
• Garder un contexte propre avec /clear et déclencher la réflexion approfondie

Le principe d’or : contexte, objectif, contraintes

Imaginez un nouveau collègue brillant qui arrive dans votre équipe. Il maîtrise la programmation sur le bout des doigts, mais il ne connaît ni votre projet, ni vos habitudes, ni ce que vous avez en tête. Claude Code, c’est exactement ce collègue. Si vous lui dites simplement « corrige le bug », il va deviner. Deviner quel bug, deviner où, deviner comment. Parfois il tombe juste. Souvent, il tombe à côté — et ce n’est pas sa faute, c’est celle de la demande.

Regardez la différence entre ces deux formulations.

# Demande vague
corrige le bug

# Demande précise
Les utilisateurs peuvent soumettre le formulaire d'inscription vide.
Ajoute une validation côté client ET côté serveur
sur l'email et le mot de passe.

La seconde demande contient trois ingrédients. D’abord le contexte : ce qui se passe aujourd’hui, le symptôme observé — le formulaire accepte des champs vides. Ensuite l’objectif : le résultat attendu — une validation sur l’email et le mot de passe. Enfin les contraintes : les limites de la solution — une validation des deux côtés, dans le navigateur et sur le serveur, pas seulement l’un des deux.

Retenez ce trio, c’est le principe d’or de tout le module. Contexte : ce que Claude doit savoir. Objectif : ce que vous voulez obtenir. Contraintes : ce que la solution doit respecter.

Un autre exemple pour ancrer le réflexe :

# Vague
améliore la performance

# Précis
La page d'accueil met plus de quatre secondes à charger.
Identifie ce qui prend le plus de temps au chargement,
puis propose des optimisations sans changer l'apparence du site.

Le mécanisme est toujours le même : chaque information que vous donnez est une supposition que Claude n’a plus besoin de faire. Plus votre demande est concrète, moins il devine, et plus le résultat vous ressemble.

Référencez précisément : fichiers, erreurs, captures d’écran

Un bon dialogue s’appuie sur des faits, pas sur des descriptions vagues. Claude Code vous donne trois moyens très directs de lui montrer les faits.

Le @ pour pointer un fichier

Tapez le caractère @ suivi du début d’un chemin : l’autocomplétion vous propose les fichiers du projet, et la touche Tab complète le nom. Claude ira ensuite lire le fichier lui-même, en entier.

Explique-moi ce que fait @src/utils/validation.js

Fini le copier-coller de blocs de code dans la conversation. Vous pointez, il lit. Et rien ne vous empêche de référencer plusieurs fichiers dans la même demande : « compare @src/form.js et @src/api/register.js et dis-moi où la validation devrait vivre ».

L’erreur complète, pas un résumé

Quand quelque chose plante, collez le message d’erreur en entier. Y compris la pile d’appels — la stack trace, cette liste de fonctions que le programme a traversées avant de planter. Elle paraît illisible, mais elle contient le nom du fichier fautif, le numéro de ligne exact et le type d’erreur : de l’or en barre pour un diagnostic.

⚠️ Piège courant — paraphraser une erreur. « Ça plante quand je sauvegarde » prive Claude de tous les indices contenus dans le message d’origine. Il devra deviner, là où le message brut lui aurait dit précisément où regarder. Collez toujours l’erreur complète, même si elle vous semble être du charabia : chaque ligne compte.

Une capture d’écran directement dans le terminal

Voici une capacité que beaucoup de débutants ignorent : Claude lit les images. Copiez une capture d’écran, placez-vous dans la zone de saisie de Claude Code et collez-la avec Ctrl+V. Oui, une image, dans le terminal. C’est redoutablement efficace pour montrer un défaut d’affichage, une maquette à reproduire ou le schéma d’une architecture. Une capture bien choisie remplace dix lignes de description.

💡 Astuce — si votre terminal Windows intercepte Ctrl+V pour son propre collage de texte, essayez Alt+V : c’est le raccourci de secours prévu par Claude Code sur Windows et WSL.

Itérez : petites étapes, grands résultats

Deuxième réflexe d’or : avancer par petites étapes vérifiables. Demandez une chose, regardez le résultat, puis demandez la suivante. Comme en randonnée : une étape à la fois, avec un point de contrôle à chaque fois. Voici à quoi ressemble une séquence bien découpée :

1. Montre-moi comment le formulaire d'inscription est géré aujourd'hui.
2. Propose une approche pour valider l'email côté client.
3. D'accord, implémente cette approche.
4. Maintenant, ajoute la même validation côté serveur.

À chaque étape, vous validez avant de continuer. Si l’approche proposée à l’étape 2 ne vous plaît pas, vous la corrigez avant qu’une seule ligne de code ne soit écrite. C’est beaucoup moins coûteux que de détricoter un gros travail parti dans la mauvaise direction.

⚠️ Piège courant — la demande fleuve. Quinze instructions dans un seul message, et Claude doit tout arbitrer seul : l’ordre, les priorités, les cas limites. Si une étape déraille, tout ce qui suit déraille avec elle. Découpez : une étape, une vérification, puis la suivante.

Et si Claude part dans une mauvaise direction en pleine action ? Vous n’êtes jamais spectateur. Appuyez sur Échap : Claude s’interrompt poliment, en conservant le travail déjà accompli, et vous reprenez la parole pour le réorienter. Pas besoin d’attendre la fin d’une modification que vous savez déjà mauvaise.

Deux autres touches méritent leur place dans vos doigts. La flèche du haut rappelle vos messages précédents — pratique pour corriger une demande sans tout retaper. Et un double appui sur Échap, quand la zone de saisie est vide, remonte dans l’historique de la conversation : vous revenez à un message antérieur et vous reformulez à partir de là, comme si la suite n’avait jamais eu lieu. La documentation officielle recense tous les raccourcis de la session interactive si vous voulez aller plus loin : https://code.claude.com/docs

Explorez un projet : les questions qui marchent

Claude Code excelle dans un exercice précis : comprendre un codebase — c’est-à-dire l’ensemble du code source d’un projet. Il lit les fichiers, suit les imports, recoupe les informations. Encore faut-il lui poser les bonnes questions. En voici trois qui marchent remarquablement bien, à adapter à votre projet.

Où est gérée l'authentification dans ce projet ?

Cette question donne un thème précis et laisse Claude mener l’enquête. Il vous répondra avec les fichiers concernés, leur rôle, et souvent un résumé du mécanisme. Variez le thème : la gestion des erreurs, l’envoi d’emails, la configuration.

Trace le parcours d'une requête d'inscription,
de la route jusqu'à la base de données.

La route, c’est l’adresse qui déclenche un traitement côté serveur. Cette question demande un cheminement complet : quel fichier reçoit la requête, quelles fonctions se passent le relais, quelle requête SQL — le langage des bases de données — part à la fin. C’est la meilleure façon de comprendre comment un projet respire, couche par couche.

Quelles conventions ce projet suit-il ?

Nommage des fichiers, organisation des dossiers, style de code, bibliothèques favorites : chaque projet a ses habitudes. Claude sait les déduire en observant l’existant.

💡 Astuce — posez la question des conventions avant votre toute première modification dans un projet inconnu. Claude s’alignera ensuite sur ces conventions pendant toute la session, et son code se fondra dans l’existant au lieu de détonner.

Le point commun de ces trois questions ? Un périmètre clair et un verbe d’action : où, trace, quelles. Évitez les questions océans comme « explique-moi tout le projet » : vous recevrez un résumé trop général pour être utile.

Dites ce que vous voulez constater

Voici l’idée la plus puissante de ce module. Ne décrivez pas seulement le code à produire : décrivez ce que vous voulez constater à la fin. Autrement dit, donnez à Claude un critère de réussite vérifiable.

Ajoute la validation de l'email dans @src/form.js.
Critère de réussite : les tests existants doivent continuer à passer.

Le bouton Envoyer doit rester désactivé
tant que l'email saisi n'est pas valide.

Pourquoi est-ce si efficace ? Parce que Claude peut vérifier lui-même. S’il connaît votre définition de « fini », il lance les tests, constate l’échec éventuel, corrige, et recommence jusqu’à ce que le critère soit rempli. Vous ne lui confiez plus une tâche à l’aveugle : vous lui donnez un but et un moyen de savoir qu’il l’a atteint.

Prenez l’habitude de terminer vos demandes importantes par une phrase qui commence par « à la fin, je dois pouvoir constater que… ». Les tests passent. La page s’affiche sans erreur dans la console. Le formulaire refuse un email sans arobase. Un critère concret, observable, binaire : c’est rempli ou ça ne l’est pas.

L’hygiène du contexte : /clear entre deux tâches

Parlons d’une ressource invisible mais précieuse : le contexte. Le contexte, c’est la mémoire de travail de votre session — tout ce qui a été dit, lu et produit depuis le début de la conversation. Chaque message, chaque fichier ouvert, chaque résultat de commande s’y ajoute. Imaginez un bureau : plus il est encombré, plus on perd de temps à retrouver ce qui compte.

D’où le réflexe d’hygiène : entre deux tâches sans rapport, tapez /clear. La conversation repart de zéro, débarrassée des détails de la tâche précédente. Claude ne risque plus de mélanger votre correction CSS du matin avec votre script d’import de l’après-midi, et vous libérez de la place pour la suite.

Un mot de prudence : /clear efface la conversation courante. Terminez donc votre tâche avant de l’utiliser, car les échanges précédents ne seront plus là pour appuyer la suite.

💡 Astuce — la règle simple : si la nouvelle tâche s’appuie sur la précédente, continuez dans la même session ; si le sujet est complètement différent, /clear. Et pour les longues sessions qui méritent de continuer sans repartir de zéro, il existe /compact, qui résume la conversation au lieu de l’effacer — nous l’explorerons en détail au module 7.

La réflexion approfondie pour les problèmes difficiles

Dernier outil de dialogue : demander à Claude de prendre son temps. Face à un problème réellement difficile — un choix d’architecture, un bug retors, un compromis technique délicat — ajoutez à votre demande une consigne explicite : « réfléchis longuement avant de répondre ».

Cette formulation encourage ce qu’on appelle la réflexion approfondie — extended thinking en anglais : Claude s’accorde un temps de raisonnement supplémentaire avant de rédiger sa réponse. Il explore plusieurs pistes, les compare, écarte les impasses, puis seulement rédige.

Réfléchis longuement avant de répondre :
faut-il découper ce module de paiement en service séparé,
ou le garder dans l'application principale ?
Liste les avantages et les risques de chaque option pour un petit projet.

Réservez cette demande aux questions qui en valent la peine : la réflexion approfondie prend plus de temps. Pour renommer une variable, inutile de convoquer le grand conseil. Et si le fonctionnement de ces modèles d’intelligence artificielle vous intrigue, notre dossier IA creuse le sujet — vous y trouverez aussi notre comparatif des IA. Les termes techniques croisés dans ce module, comme contexte, stack trace ou extended thinking, sont par ailleurs tous expliqués dans notre glossaire.

À vous de jouer

Place à la pratique. Prenez un projet — le vôtre, ou n’importe quel projet open source cloné sur votre machine. L’objectif : comprendre son architecture en trois questions, puis réussir une petite modification guidée.

1. Ouvrez un terminal à la racine du projet et lancez une session interactive :

claude   # démarre la session dans le dossier du projet

2. Première question, la vue d’ensemble : « Explique-moi l’architecture de ce projet : les dossiers principaux et le rôle de chacun. »
3. Deuxième question, le zoom : choisissez une fonctionnalité visible du projet et demandez « Trace le parcours de cette fonctionnalité de bout en bout, en citant les fichiers traversés. »
4. Troisième question, les conventions : « Quelles conventions ce projet suit-il ? Nommage, organisation des dossiers, style de code. »
5. Passez à l’action avec le principe d’or : choisissez une modification modeste — un texte à changer, un petit champ à valider — puis décrivez le contexte, l’objectif et les contraintes, en référençant le fichier concerné avec @. Terminez par un critère de réussite constatable.
6. Vérifiez le résultat. Si Claude s’égare en route, Échap, puis reformulez. Quand tout est bon, tapez /clear : le bureau est rangé pour la prochaine tâche.

Si les trois réponses d’exploration vous ont semblé claires et que votre modification fonctionne, félicitations : vous dialoguez déjà mieux que la majorité des utilisateurs débutants.

En résumé

• Le principe d’or tient en trois mots : contexte (ce que Claude doit savoir), objectif (ce que vous voulez), contraintes (ce que la solution doit respecter).
• Montrez les faits : @fichier pour pointer un fichier avec autocomplétion, l’erreur collée en entier avec sa stack trace, la capture d’écran collée avec Ctrl+V.
• Itérez par petites étapes vérifiables ; Échap interrompt Claude sans perdre le travail accompli ; double-Échap remonte l’historique pour reformuler.
• Pour explorer un projet, préférez les questions à périmètre clair : « où est gérée l’authentification ? », « trace le parcours d’une requête », « quelles conventions ce projet suit-il ? ».
• Donnez un critère de réussite constatable : les tests passent, le bouton reste désactivé, la console est sans erreur.
• /clear entre deux tâches sans rapport, et « réfléchis longuement » pour les problèmes qui méritent une réflexion approfondie.

Vous savez désormais parler à Claude. Au prochain module, vous apprendrez à garder le contrôle : les permissions, les modes d’exécution et le fameux mode plan, qui laisse Claude réfléchir et proposer avant de toucher au moindre fichier.