Tu demandes à Claude Code de refactorer un composant React. Trois minutes plus tard, six fichiers ont changé, ton build ne compile plus, et tu ne sais pas ce qui a bougé. C'est exactement le scénario que /diff résout. Depuis la version 2.1.260 (3 septembre 2026), Claude Code affiche un panneau dédié qui liste les modifications au fur et à mesure, tour par tour, avant que tu ne commit. Si tu apprends Claude pour construire tes propres outils, cette commande devient vite ton garde-fou principal.
L'article part du principe que tu utilises Claude Code au quotidien sans être développeur senior. Tu sais lancer une session, tu prompt, tu regardes le résultat, tu commit quand ça marche. Ce qui manque, c'est l'étape du milieu : relire ce que Claude s'apprête à écrire. On va y aller pas à pas.
À quoi sert /diff dans Claude Code
La commande /diff ouvre un panneau plein écran à côté de la conversation, avec deux vues basculables aux flèches gauche/droite. La vue "Current" affiche toutes les modifications non commitées du répertoire de travail, exactement comme un git diff HEAD. La vue "Per-Turn" découpe ces mêmes modifications tour par tour. Dans les deux vues, les flèches haut/bas parcourent les fichiers touchés.
Concrètement : tu demandes à Claude de refactorer UserProfile.tsx. Il propose 12 lignes ajoutées, 4 supprimées, plus une modification silencieuse dans types.ts pour matcher une nouvelle prop. /diff te montre les deux fichiers, séparés, dans le tour concerné. Tu vois la refacto principale ET l'effet de bord.
Ne confonds pas /diff avec un outil de revue de code collaboratif. Il n'y a pas de commentaires en ligne, pas d'approbation formelle, pas de pull request. C'est un panneau de visualisation local, pensé pour toi seul, avant que le changement parte sur ta branche.
Ouvrir /diff : les trois moments où c'est utile
Il y a trois moments où ouvrir /diff change vraiment ta session.
Après un prompt de modification structurant. Tu viens de demander "ajoute NextAuth avec un provider Google". Claude ne modifie pas un fichier, il en modifie six : app/api/auth/[...nextauth]/route.ts, middleware.ts, package.json, .env.example, le layout, et probablement un composant de bouton. Tu ouvres /diff et tu vois l'ampleur réelle du changement. Souvent, ça te fait remarquer que Claude a ajouté une dépendance dans package.json mais que tu n'as pas lancé npm install.
Avant un commit. Tu as prompté cinq fois dans la session, corrigé deux erreurs, ajusté un style. La vue "Current" de /diff te donne le cumul complet des changements par rapport à HEAD. C'est le moment de vérifier que rien de fantôme ne traîne, un console.log oublié, un import inutilisé, un fichier de test bidon créé pour un aller-retour.
Quand plusieurs fichiers sont touchés en un tour. Un prompt anodin comme "renomme cette variable" peut cascader dans dix fichiers si la variable est exportée. La vue "Per-Turn" liste tous les fichiers du dernier tour, et tu peux vérifier que le renommage a bien été propagé partout, ou au contraire qu'il a oublié un endroit.
Si tu débutes avec l'agent en ligne de commande, la fiche outil Claude Code détaille l'installation et les commandes de base.
Lire un diff turn by turn sans être dev
Un diff, c'est trois symboles à connaître.
+: ligne ajoutée-: ligne supprimée@@: marqueur de contexte, indique la zone du fichier où le changement se produit (numéro de ligne avant/après)
Le reste est du code normal, affiché en gris pour te donner le contexte autour. Une modification affiche typiquement trois lignes avant et trois lignes après le changement, pour que tu comprennes où tu es dans le fichier.
Trois patterns à repérer systématiquement quand tu lis un diff :
- Une fonction supprimée (lignes
-qui contiennentfunction xxxouconst xxx = ...). Vérifie qu'elle n'est appelée nulle part ailleurs. Un simpleCtrl+Fsur le nom dans ton IDE suffit. - Un nom de variable changé dans un fichier mais pas dans les autres. Si Claude renomme
userIdencustomerIddans un fichier et oublie l'autre, ton build va casser. - Un import ajouté (ligne
+qui commence parimport) sans que la dépendance soit installée. Regardepackage.jsondans le même diff : si le package n'y est pas, il te faut unnpm install.
Astuce qui marche bien quand tu bloques sur un diff long : copie-le et colle-le dans Claude avec le prompt "Explique-moi ce que change réellement ce diff en termes fonctionnels, pas ligne par ligne. Quels sont les risques ?". Tu récupères une lecture de haut niveau en 20 secondes.
Ce que tu fais une fois le diff repéré
/diff est un panneau de lecture : pas de bouton "accepter" ou "rejeter" un chunk individuellement, contrairement à un outil de revue de code collaboratif. Une fois que tu as repéré un problème, la correction se passe dans la conversation, pas dans le panneau.
Prends ce cas courant : tu demandes à Claude de réécrire la logique de validation d'un formulaire d'inscription. Il fait le job, mais dans le même tour il supprime un commentaire qui expliquait pourquoi la validation d'email tolérait le format +alias@domain.com. Le code marche toujours, mais le contexte est perdu. Tu le repères dans /diff, et tu reprompt directement : "Remets le commentaire sur les alias email que tu as supprimé, garde le reste de la nouvelle logique."
Ce mécanisme, repérer dans /diff puis corriger par un nouveau prompt ciblé, remplace l'ancien réflexe qui consistait à relire le code après coup dans l'éditeur, ou pire, à ne pas le relire du tout.
Ce workflow évite le piège classique du dev assisté : valider tout parce que "ça compile", puis découvrir trois jours plus tard qu'une règle métier a disparu dans un changement noyé au milieu d'une refacto de 200 lignes.
Intégrer /diff dans un workflow de build hebdomadaire
Une routine qui tient sur la durée, testée en sessions de 3-4 heures :
| Moment | Action | Pourquoi |
|---|---|---|
| Après chaque prompt structurant | /diff, lecture rapide, reprompt si besoin | Repérer les effets de bord tant que le contexte est frais |
| Après 3-4 prompts validés | Commit git avec message clair | Créer un point de retour propre |
| Avant push | /diff en vue "Current", lecture cumulée | Vérifier ce qui part sur la branche partagée |
| En fin de session | /diff même si tu ne commit pas | Savoir ce qui traîne en local avant de fermer |
Le vrai piège arrive après deux heures de session. Ton attention baisse, tu enchaînes les prompts, tu valides sans relire. C'est là que les régressions silencieuses passent. La règle interne qu'on recommande : pas plus de trois prompts consécutifs sans /diff. Après le troisième, tu ouvres le panneau, même si tu es sûr de toi.
Cette discipline paie surtout quand tu combines Claude Code avec un déploiement continu. Si tu pousses vers Vercel à chaque push, un diff mal relu peut casser ta prod en 90 secondes. Pour tout le contexte du déploiement, la fiche Vercel et Next.js détaille la boucle.
Si tu construis un produit complet, l'intégration de /diff devient un des rituels de base de la création d'application avec Claude Code, au même titre que la structuration des sessions et le versioning.
Erreurs fréquentes et comment les rattraper
1. Accepter un diff qui casse le build. Ça arrive. Tu valides, tu lances npm run dev, tu vois une erreur de compilation. Deux options : git reset --hard HEAD si tu n'as pas commité (tu perds tout ce qui n'est pas commité, attention), ou tu re-prompte Claude avec l'erreur exacte : "Le build casse avec cette erreur : [colle l'erreur]. Corrige." Dans 80 % des cas, il retrouve la ligne fautive du diff précédent.
2. Juger trop vite qu'un changement est faux sans lire le contexte @@. Une ligne modifiée peut sembler bizarre en isolation mais avoir du sens dans son contexte. Avant de reprompt Claude pour la corriger, lis les trois lignes de contexte avant et après. Si tu ne comprends toujours pas, demande à Claude : "Pourquoi tu as ajouté cette ligne ?". Il justifie, tu décides si tu la gardes.
3. Confondre un changement proposé et un changement déjà écrit. Selon le mode de permission de ta session, Claude te montre parfois une modification à valider avant de l'écrire, et l'écrit parfois directement si le mode l'y autorise. La vue "Current" de /diff te dit toujours la vérité : c'est ce qui est actuellement dans les fichiers non commités. Si un changement que tu attendais n'y apparaît pas, c'est qu'il n'a pas été appliqué.
4. Ignorer les fichiers de config. Le pire angle mort. Tu regardes le diff du composant que tu voulais modifier, tu valides, tu ne remarques pas que .env.example, package.json ou tsconfig.json ont aussi bougé. Ces fichiers changent rarement, mais quand ils changent, c'est structurant. Regarde-les systématiquement dans la liste des fichiers du tour.
Un dernier point sur la sécurité : la version 2.1.260 corrige aussi une faille où les règles de permission sur des chemins contenant des parenthèses étaient ignorées. Autrement dit, un dossier censé être en lecture seule pouvait être modifié à ton insu. Mise à jour recommandée si tu n'es pas déjà sur cette version. Si tu veux aller plus loin sur la sécurité des sessions Claude Code, le mode restreint pour auditer du code non fiable couvre les scénarios plus sensibles.
Passer à la pratique
/diff paraît anodin quand on le découvre. Une commande, un panneau, deux vues. Ce qui change vraiment, c'est le réflexe qu'elle installe : ne jamais valider une modification qu'on n'a pas relue, même quand on est fatigué, même quand on est pressé. C'est la différence entre déléguer à un agent et signer les yeux fermés.
Si tu veux passer d'un usage bricoleur de Claude Code à une pratique structurée de build, avec les bonnes routines dès le départ (sessions, diff, commits, déploiement, sécurité), rejoins la prochaine cohorte Claude Builder pour construire ton produit IA en 5 semaines. On y code des applications complètes, avec les garde-fous en place, sans avoir besoin d'un profil dev senior pour tenir le rythme.