Flux de revue de code dans Claude Code : le nouveau panneau de différences en plein écran dans 2.1.260

Ce qui a changé dans Claude Code 2.1.260

Le principal ajout pour la revue des modifications de code générées par l’IA est le panneau de diff en plein écran. Les Les notes de version de 2.1.260 décrivent un panneau à côté de la conversation qui affiche les modifications non commitées au fur et à mesure que Claude modifie le code. La /diff permet d’afficher ou de masquer ce panneau.

Vous disposez ainsi d’un espace pour examiner le diff à mesure qu’il évolue, tout en gardant la conversation visible. Une bonne habitude de revue consiste à comparer ces modifications à votre demande : quels fichiers doivent changer, quel comportement doit changer et quelles contraintes doivent rester respectées ?

Ouvrir le panneau de diff en plein écran

Passez la conversation actuelle en affichage plein écran, puis affichez le panneau :

/tui fullscreen
/diff

Le mode plein écran lui-même est antérieur à cette version. La version 2.1.110 a introduit /tui et le tui paramètre ; /tui fullscreen modifie l’affichage au sein de la même conversation. Ces détails antérieurs sont consignés dans les journal des modifications rattaché à une version précise.

Cette distinction compte lorsqu’on décrit la mise à jour : Claude Code 2.1.260 a introduit le panneau de diff en temps réel, tandis que la commande permettant de passer en plein écran existait déjà.

Les notes de version retenues ne précisent aucune largeur minimale du terminal, ouverture automatique du panneau, raccourci de navigation ni comportement de filtrage des fichiers. Commencez par les deux commandes documentées plutôt que de vous appuyer sur des commandes qui n’étaient pas confirmées à la date limite de publication.

Pour une vue d’ensemble plus large, les portail des guides Claude Code constitue un point de départ pour le processus de travail qui les entoure.

Un flux de travail pratique pour la revue dans Claude Code

Utilisez trois points de contrôle distincts : définir la modification prévue, examiner le diff obtenu et demander une revue automatisée. Les autorisations accompagnent ces points de contrôle, car elles régissent la confirmation des actions des outils.

La séquence suivante est une méthode de travail recommandée. Elle combine les commandes établies dans le journal des modifications sans présenter le nouveau panneau comme une interface d’approbation.

1. Définir le périmètre avant les modifications

Confiez à Claude une tâche délimitée et des critères de revue clairs. Décrivez le comportement attendu, les contraintes pertinentes et tout élément nécessitant une attention particulière.

Par exemple, une demande de modification de la gestion des erreurs doit préciser la réponse attendue en cas d’échec. Lors de la revue, utilisez cette exigence pour déterminer si les modifications traitent l’échec de manière cohérente.

Délimitez suffisamment la demande pour pouvoir expliquer pourquoi chaque fichier modifié a sa place dans le diff. Si une modification semble sans rapport, demandez à Claude d’expliquer son lien avec la tâche avant de poursuivre.

2. Inspecter les modifications à mesure qu’elles apparaissent

Ouvrez le mode plein écran et activez /diff. Pendant que Claude modifie le code, comparez les modifications non commitées au périmètre que vous avez défini.

Voici un ordre d’inspection pratique :

1. Vérifiez que les fichiers modifiés relèvent de la tâche.
2. Examinez le comportement modifié et les hypothèses qui l’entourent.
3. Repérez les omissions, les extensions inattendues du périmètre ou les raisonnements peu clairs.
4. Demandez à Claude de répondre à des préoccupations précises, puis inspectez le diff mis à jour.

Considérez cela comme une conversation continue. Une demande de suivi précise doit indiquer le comportement modifié qui vous préoccupe et le résultat que vous attendiez.

Le panneau affiche des modifications déjà appliquées et non commitées. Son objectif documenté est de rendre ces modifications visibles ; les notes de version ne mentionnent pas de commandes d’approbation par bloc de diff.

3. Demander une revue et évaluer les constats

Une fois les modifications prêtes pour une nouvelle inspection, utilisez /review ou /code-review. Évaluez les constats au regard du diff réel et de vos exigences initiales.

Pour chaque correction suggérée, demandez-vous si elle identifie un problème concret, si la modification proposée correspond à la tâche et si elle élargit le périmètre. Inspectez ensuite à nouveau les modifications qui en résultent.

Cela crée une boucle de revue : inspecter, demander une revue, résoudre les problèmes relevés et vérifier à nouveau le code modifié. Évitez de considérer qu’un diff visible ou une réponse de revue automatisée constitue à lui seul une preuve suffisante.

Ce que /diff, /review, ainsi que /code-review ne

Les commandes ont des fonctions différentes. /diff contrôle le panneau en temps réel ; /review appelle la commande de revue au moyen d’un alias.

Le Les notes de version de 2.1.223, datées du 6 août 2026, établissent que /review est devenu un alias de /code-review. Ce comportement était déjà présent avant l’arrivée du panneau de diff en plein écran.

Examiner le diff actuel

Le document de cadrage établit que /review et /code-review peut examiner le diff actuel. Voici une demande de revue de base :

/review

À partir de 2.1.223, appeler /code-review sans niveau d’effort réutilise le dernier niveau saisi. Si vous souhaitez choisir explicitement le niveau d’effort, utilisez :

/code-review high

Ne supposez pas que l’absence de niveau d’effort le réinitialise à une valeur par défaut fixe. Le comportement documenté consiste à réutiliser la sélection précédente.

Examiner une pull request spécifique

Les notes de version donnent la syntaxe suivante pour les pull requests :

/code-review <level> <pr#>

Ici, <level> et <pr#> sont des paramètres fictifs représentant le niveau d’effort et le numéro de la pull request. La même commande de revue couvre donc à la fois le diff actuel et une pull request spécifique.

Pour des informations connexes sur la ligne de commande, consultez référence de la CLI de Claude Code.

Comprendre la revue approfondie dans le cloud

La commande documentée pour demander une revue approfondie dans le cloud est :

/code-review ultra

Par ailleurs, la version 2.1.260 a augmenté le délai d’attente pour les revues longues dans le cloud effectuées via /ultrareview et claude ultrareview de 30 à 45 minutes.

Gardez une formulation précise : il s’agit d’une augmentation de la limite d’attente pour ces commandes, et non d’une promesse qu’une revue se terminera en 45 minutes. Les notes de version ne fournissent pas non plus de tarif propre aux revues ; elles ne permettent donc pas d’estimer le coût de ce workflow.

Examiner les modifications et approuver les actions séparément

« Examiner avant d’approuver » peut désigner deux moments différents : vérifier une action proposée par un outil avant de l’autoriser, ou inspecter une modification avant de décider qu’elle est prête à être conservée.

L’historique des modifications documente /permissions comme un moyen d’exiger une confirmation pour certains outils :

/permissions

Utilisez cette configuration lorsque votre workflow exige une étape de confirmation pour un outil particulier. Lorsqu’une demande de confirmation apparaît, évaluez l’action proposée au regard de la tâche et de vos contraintes.

Le panneau de diff en plein écran intervient à un autre moment de la séquence. Il affiche les modifications non commitées qui ont déjà été appliquées pendant que Claude modifie le code. L’inspection de ces modifications vous aide à déterminer ce qui nécessite des explications, des corrections ou une revue supplémentaires.

Définir explicitement les points de contrôle

Une liste de vérification utile pour la revue distingue les questions suivantes :

• Avant l’approbation de l’outil : L’action proposée est-elle appropriée pour cette tâche ?
• Après les modifications : Les modifications appliquées correspondent-elles au comportement demandé ?
• Après la revue automatisée : Quels constats nécessitent une correction ou des investigations supplémentaires ?
• Avant de conserver le résultat : Avez-vous vérifié les modifications finales au regard de vos exigences ?

Cette distinction évite qu’une demande d’approbation ne se substitue à une revue de code. Elle évite également de présenter le panneau de diff comme une commande permettant d’autoriser les modifications avant qu’elles ne soient effectuées.

Les notes de version de 2.1.260 ne mentionnent pas de bouton « Accepter toutes les modifications » ni de commandes d’acceptation ou de rejet par bloc de diff. Présentez /diff comme un panneau d’inspection et prenez les décisions concernant le code résultant dans le cadre de votre processus de revue.

Correctifs du retour en arrière et vérification de la restauration

La version 2.1.260 comprend également deux correctifs liés à l’annulation des modifications. Les notes de version signalent des messages de réussite incorrects lorsque les sauvegardes des points de contrôle étaient absentes, ainsi qu’un suivi obsolète des lectures de fichiers après /rewind.

Le premier correctif concerne /rewind et --rewind-files. Auparavant, ils pouvaient signaler à tort une réussite alors qu’aucun fichier n’avait été restauré en raison de l’absence de sauvegardes des points de contrôle.

Le second correctif résout le problème de suivi obsolète des lectures de fichiers après /rewind. Il s’agit de corrections spécifiques ; elles ne garantissent pas que chaque modification puisse toujours être annulée dans toutes les conditions.

Vérifier l’état après un retour en arrière

Lorsqu’une revue vous conduit à annuler du travail, intégrez la vérification des fichiers résultants au processus de récupération. Confirmez que les modifications concernées ont été annulées avant de demander à Claude de poursuivre.

Cette recommandation découle du problème corrigé par cette version : un message de réussite ne signifiait pas toujours qu’une restauration avait eu lieu. Bien que 2.1.260 corrige ce signalement incorrect, inspecter le résultat reste un point de contrôle utile.

Le retour en arrière a également une fonction différente de celle de la revue automatisée. La revue aide à évaluer les modifications ; le retour en arrière est pertinent lorsque vous décidez d’annuler des modifications. Le panneau en plein écran facilite l’inspection des modifications non commitées, tandis que les correctifs documentés du retour en arrière concernent la restauration et le suivi ultérieur des lectures de fichiers.

Points clés

• Claude Code 2.1.260, publié le 3 septembre 2026, a introduit un panneau de diff en temps réel à côté de la conversation en mode plein écran.
• Utilisez /tui fullscreen pour passer à l’affichage en plein écran et /diff pour afficher ou masquer le panneau des modifications non commitées.
• /review est un alias de /code-review ; la commande peut examiner le diff actuel ou une pull request spécifique.
• /permissions régit la confirmation pour certains outils. Le panneau de diff affiche les modifications appliquées, et ses notes de version ne mentionnent pas de commandes d’acceptation par bloc de diff.
• La version 2.1.260 corrige les messages de réussite trompeurs du retour en arrière et porte le délai d’attente des revues longues /ultrareview et claude ultrareview dans le cloud à 45 minutes.

FAQ

Comment ouvrir le panneau de diff en plein écran de Claude Code ?

Exécutez /tui fullscreen dans la conversation, puis utilisez /diff pour afficher ou masquer le panneau en temps réel. Claude Code 2.1.260 a introduit ce panneau, qui affiche les modifications non commitées à côté de la conversation pendant que Claude modifie le code.

Quelle est la différence entre /diff et /review?

/diff affiche ou masque le panneau en plein écran permettant d’inspecter les modifications non commitées. /review est un alias de /code-review, qui examine le diff actuel ou une pull request ; cet alias a été introduit dans la version 2.1.223.

Puis-je approuver individuellement les modifications dans le panneau ?

Les notes de version de 2.1.260 ne mentionnent pas de commandes d’acceptation ou de rejet par bloc de diff ni de bouton « Accepter toutes les modifications ». Elles établissent que le panneau affiche les modifications non commitées, tandis que /permissions permet d’exiger une confirmation pour certaines actions d’outils.

Que fait /code-review ultra et combien de temps une revue dans le cloud peut-elle durer ?

/code-review ultra demande une revue approfondie dans le cloud. Par ailleurs, la version 2.1.260 a augmenté le délai d’attente pour les revues de longue durée via /ultrareview et claude ultrareview à 45 minutes, contre 30 minutes auparavant ; cette limite d’attente ne garantit pas le délai d’achèvement.