Checkpoints : un filet de sécurité pour revenir en arrière à tout moment

📚 Navigation de la série : L'article précédent 36 Commandes slash / a passé en revue la longue liste de commandes commençant par /, et /rewind y a fait une apparition. Cet article est dédié à ce sujet — les checkpoints are « instantanés avant modification » automatiquement enregistrés par Claude Code, vous permettant de revenir à tout moment à un état précédent. Comment ils sont enregistrés automatiquement, comment revenir en arrière, ce qui peut ou ne peut pas être restauré, et comment ils se répartissent le travail avec git : nous vous expliquons tout. (les checkpoints sont des « instantanés avant modification » automatiquement enregistrés par Claude Code, vous permettant de revenir à tout moment à un état précédent. Comment ils sont enregistrés automatiquement, comment revenir en arrière, ce qui peut ou ne peut pas être restauré, et comment ils se répartissent le travail avec git : nous vous expliquons tout.)

On dit souvent que les checkpoints sont votre « pilule de regret » et qu'avec ce filet de sécurité, vous pouvez laisser Claude agir librement — mais pour être honnête, les utiliser comme git vous mènera tôt ou tard à la catastrophe.

Imaginez quelqu'un qui débute avec Claude Code : ayant entendu parler de /rewind, il se détend et laisse Claude modifier une dizaine de fichiers d'un coup, tout en exécutant quelques commandes rm et mv pour nettoyer les répertoires. À la troisième étape, il se rend compte que la direction prise n'est pas la bonne, et lance sereinement un /rewind pour revenir en arrière — résultat : le code est partiellement restauré, mais aucun des fichiers supprimés par rm n'est revenu. Il se retrouve alors totalement désemparé : « On ne m'avait pas dit qu'on pouvait tout annuler ? »

Il est possible d'annuler, mais cela ne concerne que les fichiers modifiés par Claude via ses outils d'édition, pas les traces laissées sur votre disque par l'exécution de commandes bash, et encore moins un historique permanent comme celui de git. Un checkpoint est une « annulation locale au niveau de la session », dont la force réside dans sa rapidité, son automatisation et sa capacité à restaurer également l'historique de la conversation ; mais il a des limites bien définies, et il ne peut pas gérer ce qui les dépasse.

Cet article se concentre sur deux objectifs : d'abord, vous expliquer le fonctionnement de cette « sauvegarde automatique + retour en arrière » pour que vous puissiez l'utiliser les yeux fermés ; ensuite, définir précisément ses limites — ce qui peut être restauré, ce qui ne le peut pas, quand s'appuyer sur elle, et quand utiliser obligatoirement git. Ce n'est qu'en comprenant ses limites qu'elle sera un véritable filet de sécurité, et non un filet trompeur.

À la fin de cet article, vous obtiendrez :

• Une explication en une phrase de ce qu'est un checkpoint et de quand il est automatiquement enregistré (sans action manuelle de votre part)
• Les deux méthodes d'ouverture via /rewind ou le double-clic sur Esc dans un champ de saisie vide, ainsi que le rôle des différentes options du menu de retour en arrière
• Un tableau comparatif « Restaurable vs Non restaurable » — le code et la conversation peuvent être annulés, mais pas les effets secondaires de bash ni les états externes
• La répartition claire des rôles entre les checkpoints et git : quand utiliser l'un ou l'autre, et pourquoi ils ne sont pas interchangeables
• Un exercice pratique guidé avec les résultats attendus : provoquez volontairement une « erreur d'édition » puis utilisez le retour en arrière pour la corriger

---

01 Qu'est-ce qu'un checkpoint : Il prend discrètement un instantané avant chacune de vos interventions

Commençons par la conclusion : un checkpoint est un « instantané avant modification » de votre code pris automatiquement par Claude Code — il en réalise un à chaque fois que vous soumettez une invite ; si vous souhaitez revenir en arrière, il vous suffit d'utiliser /rewind pour y retourner.

Vous l'avez déjà aperçu dans l'article 07, et vous savez que /rewind sert de filet de sécurité en cas d'erreur. Allons plus loin dans cet article. Rappelez-vous le rythme de travail avec Claude : vous envoyez une instruction → il boucle sur « Réfléchir → Agir → Observer » et modifie quelques fichiers → vous examinez le résultat et envoyez l'instruction suivante (cette boucle a été abordée dans l'article 03). Le rôle du checkpoint est de capturer l'état du code juste avant que chaque instruction ne commence à s'exécuter.

Analogie : La lecture temporelle d'un enregistreur vidéo (DVR). Votre décodeur TV enregistre le programme en continu, mais place un « marqueur de chapitre » à chaque changement d'émission. Si vous souhaitez revoir une partie, vous n'avez pas besoin de faire défiler depuis le début, il vous suffit de vous rendre sur le marqueur correspondant. C'est le même principe avec les checkpoints : chaque invite que vous envoyez représente un marqueur sur la ligne temporelle ; /rewind est le fait de rembobiner la bande jusqu'à ce marqueur pour recommencer. La seule différence est que le DVR se contente de « lire », tandis que le checkpoint restaure réellement le code et la conversation à cet instant précis, vous permettant de prendre une autre direction.

La documentation officielle le présente ainsi :

当您与 Claude 合作时，checkpointing 会自动捕获每次编辑前代码的状态。这个安全网让您可以放心地执行雄心勃勃的大规模任务，因为您始终可以返回到之前的代码状态。

Notez ce mot : automatiquement. C'est le principal avantage du checkpoint, et sa plus grande différence d'utilisation avec git : vous n'avez rien à faire. Avec git, vous devez penser à faire un git commit, sans quoi rien n'est sauvegardé ; avec les checkpoints, Claude s'occupe de tout en arrière-plan sans que vous ayez à vous demander si c'est enregistré.

L'aide officielle liste quatre cas d'usage typiques, illustrés par des exemples concrets :

• Explorer des solutions alternatives : si l'implémentation A ne vous convient pas, revenez au point de départ pour essayer l'approche B ; le point de départ reste intact, sans crainte de casser le code de manière irréversible.
• Se rétablir après une erreur : si un fichier modifié provoque l'échec des tests et que vous ne voulez pas défaire les changements ligne par ligne manuellement, revenez au checkpoint précédent pour retrouver un état propre.
• Itérer sur des fonctionnalités : demandez à Claude de réécrire complètement un module pour tester ; si le résultat s'avère moins bon, revenez à l'état antérieur comme si de rien n'était, ce qui vous permet d'expérimenter sans crainte.
• Libérer de l'espace de contexte : après une longue discussion de débogage, vous souhaitez conserver les instructions initiales mais éliminer les tentatives infructueuses intermédiaires — c'est là qu'intervient la « synthèse » (détaillée à la section 03).

Le point commun de ces quatre cas est simple : « Je veux avancer sereinement, mais je crains de casser quelque chose sans pouvoir revenir en arrière » — le checkpoint est conçu pour éliminer cette crainte.

💡 En résumé : Un checkpoint est un instantané du code pris automatiquement par Claude avant chaque modification. Chaque invite soumise crée un nouveau « marqueur de chapitre », et un simple /rewind permet de restaurer le code et la conversation à cet instant — le tout de manière totalement automatique, sans sauvegarde manuelle.

---

02 Quand est-il enregistré, où et pour combien de temps

Puisque le checkpoint est « automatique », il convient d'en comprendre les règles de fonctionnement — à quel moment il est créé, où il est stocké et sa durée de conservation. Ces points sont détaillés officiellement et présentés ici étape par étape.

Moment de déclenchement : Un checkpoint par invite

Le principe est simple : each user prompt creates a new checkpoint in Claude Code. Les mots officiels : (chaque invite (prompt) que vous envoyez génère un nouveau checkpoint dans Claude Code. Les mots officiels 😃

每个用户提示都会创建一个新的 checkpoint。

La fréquence des « marqueurs de chapitre » suit donc directement le rythme de votre conversation — si vous envoyez dix instructions, vous disposerez de dix points de restauration. C'est pourquoi le menu de retour en arrière affiche la liste exacte des invites que vous avez soumises dans la session actuelle : chaque invite constitue à la fois un début d'action et un point de sauvegarde vers lequel revenir.

Schématisons ce rythme pour comprendre comment les checkpoints se positionnent au fil de votre discussion :

Ce schéma montre comment, à chaque invite, Claude crée un checkpoint (point bleu) avant de commencer à travailler. Si vous constatez une erreur à l'invite 3, la commande /rewind vous permet de suivre la ligne pointillée pour revenir au checkpoint 1, annulant ainsi les modifications des invites 2 et 3 ainsi que les messages associés — c'est le principe même de la restauration.

Emplacement de stockage : Dans votre répertoire ~/.claude

Les instantanés ne sont pas conservés en mémoire volatile, ils sont écrits sur le disque. La documentation officielle (claude-directory.md) en précise l'emplacement :

file-history/<session>/ —— Claude 更改的文件的编辑前快照，用于 checkpoint 恢复。

Ainsi, les instantanés de chaque session sont stockés dans le dossier ~/.claude/file-history/<session>/. Vous n'avez pas besoin d'y toucher, mais connaître cet emplacement présente deux avantages : d'une part, savoir que le mécanisme repose sur des fichiers réels sur le disque ; d'autre part, pouvoir identifier l'espace disque occupé par Claude Code si nécessaire.

Persistance entre sessions : Même après fermeture, les sauvegardes restent disponibles

Le stockage sur disque offre une caractéristique précieuse : les checkpoints persistent entre les sessions. Les termes officiels :

Checkpoints 在会话之间持久存在，因此您可以在恢复的对话中访问它们。

Qu'est-ce que cela signifie ? Si vous quittez Claude avec Ctrl+D au milieu de votre travail aujourd'hui, et reprenez la session demain avec claude --resume (ou --continue), la liste des checkpoints précédents sera conservée, et vous pourrez toujours utiliser /rewind pour revenir à un point de sauvegarde d'hier. On pourrait penser que /rewind ne fonctionne que dans la fenêtre active et s'efface à la fermeture, mais en reprenant une conversation d'il y a trois jours, les invites passées restent disponibles pour la restauration, car elles sont enregistrées sur disque et associées à la session. Cette sauvegarde résiste donc à un redémarrage de la machine, dans la limite définie par le paramètre cleanupPeriodDays.

Durée de conservation : 30 jours par défaut, ajustable

Les checkpoints ne sont pas conservés indéfiniment, un nettoyage automatique est configuré :

在 30 天后自动清理（可配置）。

Quel est le paramètre associé à cette configuration ? Il s'agit de l'option cleanupPeriodDays dans settings.json (présentée à l'article 31 sur la configuration au niveau utilisateur et projet). La documentation officielle de settings.md précise qu'elle nettoie par défaut les enregistrements des sessions inactives après 30 jours (avec un minimum de 1 jour, la valeur 0 étant refusée). Ce paramètre régit également la conservation des checkpoints. Conseil aux débutants : n'y touchez pas. La valeur par défaut est suffisante, et les étapes que vous souhaitez conserver à long terme doivent être gérées avec git (voir section 05) plutôt que de reposer sur les checkpoints pendant des mois.

Si vous explorez un jour le répertoire ~/.claude pour libérer de l'espace et que vous remarquez le dossier file-history, vous comprendrez alors : les outils d'annulation de vos commandes /rewind quotidiennes sont stockés discrètement à cet endroit. Le fait qu'ils se fassent oublier au quotidien démontre toute l'utilité d'un système automatique.

Résumons ces éléments dans un tableau :

Dimension	Règle de fonctionnement	Actions requises
Moment de création	Un checkpoint est créé automatiquement à chaque invite	Aucune action requise, poursuivez la conversation normalement
Emplacement	~/.claude/file-history/<session>/	N'y touchez pas, sachez simplement où il se trouve
Persistance	Persiste entre les sessions, disponible après restauration	Récupérable même après fermeture et réouverture
Durée	Nettoyé par défaut selon cleanupPeriodDays	Ne pas modifier ; confier la conservation à long terme à git

💡 En résumé : Les checkpoints sont créés à chaque invite et stockés dans ~/.claude/file-history/. Ils persistent entre les sessions et sont nettoyés automatiquement selon la valeur de cleanupPeriodDays. Vous devez simplement connaître ce fonctionnement, aucune action n'est requise de votre part — le processus est entièrement automatisé.

---

03 怎么倒带：/rewind、双击 Esc，和那张回退菜单

Maintenant que vous savez qu'ils sont enregistrés automatiquement, voyons comment les exploiter. Il n'existe que deux points d'accès à retenir : la commande /rewind, ou le double-clic sur Esc dans un champ de saisie vide.

Deux points d'accès

Le premier consiste à saisir la commande slash dans la session :

/rewind

Le second, plus rapide — lorsque le champ de saisie est vide, appuyez deux fois sur Esc :

（输入框空着，连按 Esc Esc）

Ces deux méthodes ouvrent le même menu de retour en arrière (rewind menu). Les mots officiels :

运行 /rewind，或在提示输入为空时按两次 Esc，打开回溯菜单。

Voici un piège déjà mentionné à l'article 14 sur lequel il convient d'insister à nouveau :

如果提示输入包含文本，双 Esc 会清除它而不是打开菜单。清除的文本会保存到您的输入历史记录中，因此在您完成回溯菜单后，按 Up 可以调用它。

En d'autres termes : lorsque le champ contient du texte, double-cliquer sur Esc vit le champ au lieu d'ouvrir le menu. Pour restaurer un état, assurez-vous d'abord que le champ est vide. C'est une erreur classique chez les débutants — après avoir saisi un début de phrase, ils appuient frénétiquement sur Esc : le texte s'efface mais le menu ne s'ouvre pas. Retenez : vider d'abord le champ, puis faire Esc Esc. En cas de doute, utilisez simplement la commande /rewind qui s'exécute indépendamment du contenu du champ de saisie.

Choix des options dans le menu de retour en arrière

Le menu affiche la liste ordonnée des invites soumises durant la session actuelle — c'est-à-dire les différents repères temporels. Sélectionnez le point de restauration ciblé, puis choisissez le mode de restauration. Cette seconde étape est essentielle car plusieurs opions s'offrent à vous. (Cette seconde étape est essentielle car plusieurs options s'offrent à vous.)

Détaillons la signification de chaque option officielle :

Option du menu	Action réalisée	Cas d'usage conseillé
Restaurer le code et la conversation	Le code et la conversation sont restaurés conjointement à ce point	Repartir à zéro pour l'ensemble de l'étape : faire comme si ces échanges n'avaient pas eu lieu
Restaurer la conversation	Seule la conversation est restaurée, le code reste inchangé	Conserver les modifications de code mais reformuler ou réorganiser le fil de la discussion
Restaurer le code	Seules les modifications de code sont annulées, la conversation est conservée	Annuler des modifications de code défectueuses tout en conservant l'historique des discussions pour continuer à l'exploiter
Synthétiser à partir d'ici	Compresse ce message et les suivants sous forme de résumé	Éliminer un fil de discussion secondaire inutile pour préserver la clarté des échanges initiaux
Synthétiser jusqu'ici	Compresse les messages précédant celui-ci sous forme de résumé	Masquer les discussions préliminaires pour se concentrer sur les détails des développements récents
Annuler	Ne rien modifier, retourner à la liste	Sélection erronée ou simple consultation

Les options intermédiaires de restauration partielle intriguent souvent les débutants. Illustrons leur utilité par deux cas concrets :

• « Restaurer le code » uniquement : après de nombreux échanges avec Claude, vous validez une approche ; il l'implémente, mais le code échoue à l'exécution. Vous souhaitez annuler ce code défectueux sans perdre le contexte des échanges préalables (qu'il serait fastidieux de réexpliquer) — choisissez « Restaurer le code » : le code revient à son état initial tandis que la discussion reste intacte, permettant à Claude de proposer une nouvelle écriture sur la base de vos explications existantes.
• « Restaurer la conversation » uniquement : à l'inverse, le code généré vous donne satisfaction et vous souhaitez le conserver, mais le fil des échanges s'est éparpillé suite à des questions hors sujet — sélectionnez « Restaurer la conversation » : la discussion revient à l'étape précédant la digression tandis que le code reste dans son état actuel, vous permettant de reprendre le contrôle avec des instructions claires.

Vous l'aurez compris — « Restaurer le code » et « Restaurer la conversation » sont deux leviers distincts mis à votre disposition ; il n'est pas obligatoire d'annuler les deux de concert. L'option « Restaurer le code » est généralement la plus sollicitée : la logique retenue est correcte mais l'implémentation de Claude a dévié, annuler le code pour lui faire réécrire la portion est bien plus rapide que de redéfinir le besoin depuis le départ.

Il convient également de ne pas confondre « Restaurer » et « Synthétiser », qui décrivent deux actions distinctes. Bien qu'elles figurent dans le même menu, leurs rôles diffèrent :

• Restaurer (restore) = modifie l'état actuel : réinitialise le code, la conversation, ou les deux au point choisi. C'est un retour en arrière.
• Synthétiser (summarize) = ne modifie pas les fichiers sur le disque, mais compresse une partie des messages sous forme de résumé généré par l'IA afin de libérer de l'espace de contexte. Il s'agit d'une optimisation de l'espace, pas d'un retour en arrière.

La documentation officielle exprime cette distinction de manière très claire :

恢复选项恢复状态：它们撤销代码更改、对话历史或两者。总结选项将对话的一部分压缩为 AI 生成的摘要，而不改变磁盘上的文件。

Vous l'aurez compris — la « synthèse » est une variante ciblée de la commande /compact présentée à l'article 19. Tandis que /compact compresse l'intégralité des échanges, l'option « Synthétiser à partir d'ici / jusqu'ici » vous permet de cibler un message précis pour n'en condenser qu'un côté : une digression tardive sera éliminée avec « Synthétiser à partir d'ici », tandis qu'une introduction laborieuse sera condensée avec « Synthétiser jusqu'ici ». La documentation officielle fait elle-même ce parallèle :

这类似于 /compact，但更有针对性：您不是总结整个对话，而是选择所选消息的哪一侧进行压缩。

Un détail pratique à noter : après avoir choisi « Restaurer la conversation » ou « Synthétiser à partir d'ici », le contenu de l'invite sélectionnée est réinjecté dans le champ de saisie, vous permettant de la modifier avant de la soumettre à nouveau — cela revient à vous donner l'opportunité de reformuler votre instruction. (L'option « Synthétiser jusqu'ici » se comporte différemment : elle valide le résumé et vous laisse à la fin de la discussion avec un champ de saisie vide.)

Deux difficultés courantes chez les débutants

« Le menu de retour en arrière est vide ou ne propose que très peu d'options » — c'est tout à fait normal. Le menu liste les invites soumises au cours de la session active. Si vous venez de démarrer et n'avez envoyé qu'un ou deux messages, le choix est restreint. Les points de sauvegarde s'accumulent au fil des interactions : plus vous échangez, plus vous aurez d'options.

« J'ai fait une mauvaise manipulation et suis revenu trop loin en arrière, puis-je annuler cette action ? » — pas d'inquiétude. Les checkpoints sont enregistrés sur disque et persistent entre les sessions (comme vu à la section 02). Effectuer un /rewind ne les supprime pas ; la liste des points de sauvegarde reste accessible et vous pouvez rouvrir le menu de retour en arrière pour cibler un point plus récent. Toutefois, le comportement précis du menu pouvant varier selon la version, la règle d'or reste inchangée : effectuez systématiquement un git commit avant d'entreprendre des modifications à haut risque — l'historique permanent de git constitue votre barrière de sécurité ultime (détaillée à la section suivante).

💡 En résumé : L'accès au retour en arrière s'effectue via /rewind ou par un double-clic sur Esc dans un champ vide. Sélectionnez ensuite le point ciblé et le mode d'action : « Restaurer » modifie l'état tandis que « Synthétiser » compresse le contexte sans toucher aux fichiers. Ne confondez pas ces deux actions. En cas d'erreur de manipulation, la véritable sécurité réside dans un git commit préalable.

---

04 边界在哪：能回滚什么，什么死活回不来

Cette section aborde le point le plus important de l'article, celui-là même qui a provoqué l'erreur mentionnée en introduction. Le checkpoint n'est pas un bouton d'annulation universel : il suit uniquement une catégorie d'actions — les modifications directes effectuées par Claude via ses outils d'édition de fichiers. Tout ce qui s'écarte de cette définition lui échappe totalement.

Reprenons l'analogie de l'enregistreur vidéo : il enregistre « l'image affichée à l'écran », pas « ce qui se passe dans votre salon ». Si vous revenez en arrière, l'image recule, mais la tasse de café renversée sur la table, la lettre envoyée par la poste ou le fichier supprimé du disque — ces événements du monde réel se sont produits et ne peuvent être annulés. Le checkpoint capture l'état des fichiers de code et gère l'historique de leur contenu ; il n'a aucune action sur les opérations système lancées par Claude via le terminal.

La documentation officielle détaille ce qui peut ou ne peut pas être restauré dans la section sur les limites. Voici une synthèse sous forme de tableau comparatif — à mémoriser absolument :

Catégorie	Restaurable ?	Explication
Contenu des fichiers modifiés par Claude via ses outils d'édition	✅ Oui	C'est l'objet même du suivi par checkpoint
Historique de la conversation	✅ Oui	Restaurable séparément ou conjointement via le menu
Fichiers modifiés par des commandes bash lancées par Claude (rm, mv, cp, etc.)	❌ Non	Les modifications système via bash ne sont pas suivies
Fichiers non modifiés dans la session actuelle	❌ Non	Le suivi se restreint aux fichiers manipulés durant la session
Fichiers modifiés manuellement en dehors de Claude Code	❌ Non	Les modifications externes ne sont pas capturées
Modifications issues d'autres sessions parallèles	❌ Non	Même logique, sauf si le même fichier a été modifié simultanément
Effets secondaires externes déjà appliqués (requêtes HTTP, suppression de lignes en base de données, pushes git...)	❌ Non	Il s'agit d'états externes, hors de portée des checkpoints

Les deux premières catégories non restaurables sont les plus importantes et sont explicitement mises en avant dans la documentation officielle. Analisons d'abord les commandes bash :

Checkpointing 不跟踪由 bash 命令修改的文件。例如，如果 Claude Code 运行 rm file.txt、mv old.txt new.txt、cp source.txt dest.txt……这些文件修改无法通过回溯撤销。只有通过 Claude 的文件编辑工具进行的直接文件编辑才会被跟踪。

C'est exactement l'erreur présentée en introduction — Claude a supprimé le fichier avec rm, ce qui ne correspond pas à une édition, empêchant /rewind d'intervenir. Retenez bien ceci : les modifications de fichiers par Claude se divisent en deux catégories — celles effectuées via ses outils d'édition (suivies et restaurables), et celles réalisées via des commandes bash (non suivies et non restaurables). Ces deux actions modifient vos fichiers, mais sont traitées de manière radicalement différente par le système de checkpoints.

Comment identifier immédiatement la catégorie d'action en cours ? Observez le nom de l'outil affiché lors de son exécution (le raccourci Ctrl+O permet d'afficher la transcription détaillée, comme vu à l'article 14) :

• Si vous voyez s'exécuter un outil d'édition comme Edit, Write ou MultiEdit — l'action est suivie par checkpoint, /rewind pourra la corriger en cas de problème.
• Si vous voyez l'outil Bash exécuter des commandes telles que rm, mv, cp ou > (redirection d'écriture) — l'action n'est pas suivie, et /rewind ne pourra rien restaurer.

Ces outils apparaissent distinctement dans la transcription. Prenez le réflexe d'observer le nom de l'outil actif lorsque vous demandez des actions sensibles ; cela vous permettra de savoir si vous disposerez de l'option /rewind en cas d'erreur. Si ce n'est pas le cas, effectuez d'abord un git commit.

Analisons maintenant la ligne sur les modifications externes :

Checkpointing 仅跟踪在当前会话中编辑过的文件。您在 Claude Code 外部对文件所做的手动更改以及来自其他并发会话的编辑通常不会被捕获，除非它们碰巧修改了与当前会话相同的文件。

Cela signifie que les modifications appliquées depuis un éditeur externe ou depuis une autre session Claude Code parallèle ne sont pas prises en compte par les checkpoints de la session active.

Voici une règle empirique à appliquer : dès lors que vous demandez à Claude des actions aux effets irréversibles (suppression de fichiers, déplacement de répertoires, modifications en base, requêtes réseau), ne comptez jamais sur /rewind — validez vos changements avec git commit et effectuez des sauvegardes préalables. Les checkpoints ne constituent une solution fiable que dans le cas de modifications de code erronées générées par ses outils d'édition.

La comparaison entre les attentes des débutants et la réalité du fonctionnement confirme les limites du système :

Problème rencontré	Attente vis-à-vis de /rewind	Réalité	Solution appropriée
Claude a modifié le code de manière erronée via ses outils d'édition	✅	✅ Rétabli	/rewind
Claude a supprimé un fichier par erreur avec rm	✅	❌ Non restaurable	Effectuer un git commit préalable / sauvegarde
Claude a exécuté un script modifiant la base de données	✅	❌ Non restaurable	Sauvegarde de la base / rollback de transaction
Claude a poussé les changements avec git push	✅	❌ Non restaurable	Annulation au niveau git (revert) car le serveur a été modifié
Vous avez altéré un fichier depuis un éditeur tiers	✅	❌ Non pris en compte	Historique de votre éditeur / git

Les lignes marquées d'une croix « ❌ » illustrent les pièges décrits en introduction — leur point commun est que les modifications se produisent en dehors du périmètre de suivi des checkpoints : soit via bash au lieu d'outils d'édition, soit hors de Claude Code, soit en impactant des systèmes tiers. Dès lors que les conséquences dépassent le cadre strict des fichiers de code présents sur le disque, le checkpoint est inopérant. Retenir cette règle simple évite de devoir apprendre le tableau des limites par cœur.

💡 En résumé : Les checkpoints gèrent uniquement les fichiers modifiés par les outils d'édition et la conversation, qui peuvent être restaurés. Les effets système de bash (rm, mv), les modifications externes et les requêtes déjà exécutées ne peuvent pas être annulés. Retenez cette règle d'évaluation : si les conséquences dépassent les fichiers de code locaux, le checkpoint est inopérant. Ne considérez pas /rewind comme une assurance tout risque.

---

05 和 git 的分工：本地撤销 vs 永久历史，谁也替不了谁

Ce constat permet de clarifier l'avertissement initial : « n'utilisez pas les checkpoints à la place de git ». Beaucoup d'utilisateurs se demandent s'il convient de conserver git lorsque les checkpoints sont actifs — la réponse est oui, car leurs rôles sont parfaitement complémentaires.

La documentation officielle définit cette relation de manière très claire :

将 checkpoints 视为「本地撤销」，将 Git 视为「永久历史」。

Analogie : Les ratures sur un cahier de brouillon par rapport au document final archivé. Le checkpoint s'apparente à des notes jetées sur un brouillon — vous effacez un mot et recommencez rapidement, de manière informelle, pour votre propre usage, et le cahier finit à la poubelle à terme (après 30 jours). Git s'apparente à l'impression, la signature et l'archivage du document définitif — il assure la traçabilité, permet le partage avec des tiers, conserve l'historique de chaque version et assure une conservation permanente. Vous ne renonceriez pas à l'archivage sous prétexte que vous disposez d'un brouillon, et vous n'utiliseriez pas les archives officielles pour faire vos calculs intermédiaires. Les deux outils sont indispensables et remplissent des rôles différents.

La répartition des tâches recommandée officiellement est la suivante :

• 继续使用版本控制（例如 Git）进行提交、分支和长期历史；
• Checkpoints 补充但不替代适当的版本控制。

Leurs différences apparaissent clairement lorsqu'on les compare :

Dimension	Checkpoint	Git
Déclenchement	Automatique (à chaque invite)	Manuel (via vos commandes git commit)
Granularité	Très fine (un point par invite)	Définie par vos commits
Prise en charge des effets bash	❌ Non	✅ Restaure les fichiers suivis et validés
Durée de conservation	Nettoyé par défaut selon cleanupPeriodDays	Permanente (sauf suppression manuelle)
Partage / Collaboration	❌ Local uniquement, propre à l'utilisateur	✅ Partageable avec l'équipe après publication
Usage recommandé	Annulation immédiate en cours de développement	Jalons majeurs, historique permanent, collaboration

Note : de la même manière, git ne peut pas annuler les requêtes réseau ou les écritures en base de données, mais il vous permet de restaurer les fichiers déjà validés sur le disque.

Voici une méthode simple pour choisir l'outil approprié :

• Itérations rapides, modifications expérimentales → Checkpoint. Si un essai échoue, faites un /rewind et tentez une autre approche, de manière fluide sans manipuler git.
• Jalons validés, étapes clés franchies → git commit. Une fois qu'une fonctionnalité est opérationnelle et validée par les tests, enregistrez-la ; c'est votre sauvegarde durable.
• Restauration incluant les effets de bash → Git uniquement. Comme vu précédemment, les checkpoints ignorent les suppressions par rm, mais des commits réguliers permettent à git de reconstruire l'état de l'espace de travail.

Le rythme le plus sûr est le suivant : durant le travail avec Claude, appuyez-vous sur les checkpoints pour expérimenter et annuler rapidement ; dès qu'une étape est validée, effectuez un git commit pour créer un jalon permanent. Cette association combine une annulation immédiate et fine avec des jalons d'archivage robustes, offrant une double sécurité. Le piège classique consiste à accorder une confiance aveugle aux checkpoints et à travailler tout un après-midi sans commiter. Si la session s'interrompt et doit être relancée, les fichiers de code seront conservés mais l'historique des marqueurs de checkpoints sera perdu — vous empêchant de revenir à un état intermédiaire d'il y a trois heures. D'où l'importance de prendre le réflexe d'enregistrer chaque étape validée.

L'intégration de git avec Claude Code (pour la rédaction des messages de commit ou la gestion des branches) est détaillée à l'article 43 « Flux de travail Git ». Pour l'instant, retenez cette règle essentielle : le checkpoint sert à l'annulation locale, git assure l'historique permanent ; le premier complète le second mais ne s'y substitue pas.

Ajoutons un conseil avancé issu de la documentation : si vous souhaitez expérimenter une autre approche tout en préservant la session active intacte, évitez l'option de « synthèse » (qui modifierait le contexte de la session en cours) et utilisez plutôt le fork :

claude --continue --fork-session

Cette commande crée une nouvelle branche de session pour vos tests, en laissant la session d'origine inchangée. Gardez cette option en tête, elle vous sera utile lorsque vous souhaiterez évaluer deux approches en parallèle, comme détaillé à l'article 34 « Reprendre / Restaurer une session ».

---

06 动手：亲手制造一次「改错」，再倒带回去

La théorie sans pratique ne permet pas de retenir. Voici un exercice pratique minimal pour expérimenter le cycle complet : « Modification par Claude → Décision d'annulation → Commande /rewind pour restaurer l'état ». Il s'exécute dans un dossier vide sans nécessiter de projet complexe. Ouvrez votre terminal et suivez les étapes.

Étape 1 : Créez un répertoire de test et insérez-y un fichier simple

mkdir ~/rewind-demo && cd ~/rewind-demo
git init
printf 'hello\n' > note.txt
git add note.txt && git commit -m "init: 初始 note"

Résultat attendu : Le fichier note.txt contient le mot hello et un premier commit git a été effectué (ce qui permettra de comparer le comportement du checkpoint avec celui de git).

Étape 2 : Lancez Claude et demandez-lui de modifier ce fichier

claude

Une fois la session ouverte, envoyez la première instruction (qui créera le premier checkpoint) :

把 note.txt 的内容改成三行：apple、banana、cherry，用编辑工具改

Résultat attendu : Claude utilise ses outils d'édition pour inscrire les trois noms de fruits dans note.txt (en mode par défaut, il présente un diff et attend votre validation ; acceptez-la). La précision « via les outils d'édition » est importante pour s'assurer que la modification entre dans le périmètre de suivi des checkpoints — le cas typique géré par /rewind.

Étape 3 : Soumettez une seconde invite pour appliquer une modification plus radicale

再把这三行全删掉，换成一行：这是我不想要的版本

Résultat attendu : Le fichier note.txt ne contient plus que la phrase « 这是我不想要的版本 » (Ceci est la version dont je ne veux pas). À cette étape, deux invites ont été envoyées, créant deux marqueurs temporels.

Étape 4 : Ouvrez le menu de retour en arrière et restaurez l'état

Vérifiez que le champ de saisie est vide, puis appuyez deux fois sur Esc (ou saisissez la commande /rewind) :

（输入框空着，Esc Esc）

Résultat attendu : Le menu s'affiche et liste vos deux invites précédentes. Sélectionnez le point situé avant la première invite (celle des trois fruits), puis choisissez « Restaurer le code et la conversation ».

Étape 5 : Vérifiez la réussite de la restauration

Retournez dans le terminal (ou utilisez le préfixe ! dans la session) pour consulter le fichier :

! cat note.txt

Résultat attendu : Le contenu de note.txt contient à nouveau le mot hello — vos deux modifications successives ont été annulées, et le code ainsi que la discussion sont revenus à l'état initial. Le retour de hello valide le fonctionnement du checkpoint. C'est l'intérêt de l'« annulation locale » : les modifications de deux invites sont annulées proprement sans faire appel à git.

Étape 6 (Comparaison essentielle) : Vérifiez que les effets de bash ne sont pas restaurables

Demandez maintenant à Claude de supprimer le fichier en utilisant une commande bash, afin d'expérimenter la limite décrite à la section 04. Saisissez dans la session :

用 bash 命令（rm）把 note.txt 删掉

Une fois la suppression effectuée, tentez d'utiliser /rewind pour revenir au point précédant la suppression en sélectionnant « Restaurer le code ». Vérifiez ensuite :

! ls

Résultat attendu : Le fichier note.txt n'apparaît pas et reste absent des résultats de ls. Cela démontre que les modifications induites par des commandes bash (rm) échappent au suivi par checkpoint et ne peuvent être restaurées par /rewind. C'est ici qu'intervient git pour corriger la situation :

git checkout note.txt

(Cette commande utilise la version validée lors du commit init de git pour restaurer le fichier.) Résultat attendu : Le fichier note.txt est restauré et contient à nouveau hello — l'« historique permanent » de git prend le relais là où le checkpoint est inopérant.

La réalisation de ces six étapes vous a permis de valider par la pratique les deux principes fondamentaux de ce chapitre : le checkpoint permet d'annuler facilement les modifications apportées par les outils d'édition (étape 5), mais n'a aucune action sur les opérations système lancées via bash, dont la restauration nécessite git (étape 6). Ces deux observations concrètes sont le meilleur moyen d'assimiler les limites du système.

---

07 Résumé

Cet article a détaillé le fonctionnement du filet de sécurité de Claude Code — le checkpoint est un instantané du code créé automatiquement avant chaque modification, permettant un retour en arrière rapide mais soumis à des limites strictes. Il travaille en binôme avec git et ne le remplace pas.

Voici une synthèse des points clés à retenir :

Objectif	Conclusion	Point clé
Qu'est-ce qu'un checkpoint	Instantané automatique créé avant chaque invite	Entièrement automatisé, aucune action requise
Comment l'utiliser	Commande /rewind ou double-clic sur Esc dans un champ vide	Si le champ contient du texte, double-cliquer sur Esc l'efface au lieu d'ouvrir le menu
Options du menu	Sélectionner le point de retour puis le mode d'action	« Restaurer » réinitialise l'état / « Synthétiser » compresse le contexte, ne pas confondre
Éléments restaurables	Fichiers modifiés par les outils d'édition et discussion	Ces éléments peuvent être restaurés
Éléments non restaurables	Effets système de bash, modifications externes, requêtes réseau	Les suppressions par rm ou déplacements par mv ne sont pas gérés
Relation avec git	Annulation locale vs historique permanent	Expérimentation rapide via les checkpoints, jalons durables et restaurations système via git

Vous êtes désormais en mesure de : définir ce qu'est un checkpoint et à quel moment il est créé automatiquement ; ouvrir le menu de retour en arrière via /rewind ou par double-clic sur Esc et distinguer « Restaurer » de « Synthétiser » ; identifier précisément la frontière d'application — les éditions par outil de modification sont prises en charge, tandis que les commandes bash et les états externes lui échappent ; et comprendre comment coordonner son utilisation avec git. En gardant ces limites à l'esprit, le checkpoint constituera un filet de sécurité efficace et sans surprise.

Comme indiqué en introduction : le checkpoint est un outil précieux pour annuler des modifications de code défectueuses, mais il est inopérant face à une suppression par rm. Utilisez /rewind pour les premières, et anticipez les secondes avec un git commit. Choisir le bon outil vous évitera bien des désagréments.

---

L'article suivant, 38 « Manuel de référence des plug-ins », vous expliquera comment regrouper les notions acquises (Skills, Hooks, Subagents, MCP) ainsi que les commandes associées pour concevoir un « plug-in » installable et partageable. Après l'introduction proposée à l'article 24, ce volet détaille la structure complète et les champs du manifeste pour servir de guide de référence. Si vous souhaitez distribuer vos configurations prêtes à l'emploi à des tiers, découvrez comment structurer votre paquet. (L'article suivant, 38 « Manuel de référence des plug-ins », vous expliquera comment regrouper les notions acquises (Skills, Hooks, Subagents, MCP) ainsi que les commandes associées pour concevoir un « plug-in » installable et partageable. Après l'introduction proposée à l'article 24, ce volet détaille la structure complète et les champs du manifeste pour servir de guide de référence. Si vous souhaitez distribuer vos configurations prêtes à l'emploi à des tiers, découvrez comment structurer votre paquet.)

---

Lectures recommandées

• Tâches parallèles : Faire travailler plusieurs instances de Claude simultanément plutôt que de faire la queue
• MCP : Connecter Claude au monde extérieur
• Intégration VS Code