Vous venez de laisser Claude réorganiser soixante fichiers. Le résultat ne vous plaît pas. Et maintenant ? Ce module répond à cette question — et c’est la seule raison pour laquelle un non-développeur devrait s’intéresser à Git.

Ce que vous allez apprendre

• Ce qu’est Git, en une phrase et sans jargon
• Pourquoi cela vous concerne même si vous ne programmez pas
• Comment faire enregistrer un point de reprise et comparer deux états, en français
• Ce que l’application ne sait pas faire — et pourquoi ça change votre méthode

Git, en une phrase

Git est un carnet d’historique : il enregistre l’état complet d’un dossier à des moments que vous choisissez, et permet d’y revenir.

C’est tout. Le reste — branches, dépôts, fusions — est de l’outillage d’équipe dont vous n’avez pas besoin aujourd’hui.

L’image la plus juste : le point de sauvegarde d’un jeu vidéo. Vous sauvegardez avant le passage difficile. Si ça tourne mal, vous rechargez. Personne ne trouve ça compliqué.

💡 Astuce — Sur Windows, Git est requis pour utiliser l’onglet Code de l’application : vous l’avez donc déjà installé au module 2, même sans le savoir. Autant s’en servir.

Ce que ça change quand on ne code pas

Sans historique	Avec un historique
Une manipulation ratée est définitive	Vous rechargez l’état d’avant
« C’était mieux avant, mais je ne sais plus comment »	Vous comparez les deux états, ligne par ligne
On n’ose pas essayer	On essaie, on regarde, on garde ou on jette
La corbeille, et la mémoire	Une trace datée de chaque étape

Le vrai gain n’est pas technique, il est psychologique : vous osez laisser l’agent travailler. Une réorganisation de deux cents fichiers devient un essai, pas un pari.

Deux précisions utiles. D’abord, Git n’envoie rien nulle part : l’historique reste dans le dossier, sur votre machine, tant que vous ne le publiez pas quelque part. Ensuite, ce n’est pas une sauvegarde : si le disque meurt, l’historique meurt avec. Gardez votre sauvegarde habituelle en plus.

Enfin, un détail propre à l’application : elle détecte les dossiers suivis par Git et donne à chaque session son propre espace de travail isolé. Deux sessions ouvertes en parallèle sur le même dossier ne se marchent donc pas dessus — chacune travaille dans son coin.

Faire faire le travail à Claude

Vous n’avez rien à taper d’autre que du français. Voici les quatre demandes qui couvrent 95 % des besoins :

Mets ce dossier sous suivi de version, si ce n'est pas déjà fait,
et enregistre l'état actuel comme point de départ.

Enregistre un point de reprise avant qu'on commence, avec une
description de ce que contient le dossier aujourd'hui.

Compare l'état actuel avec le dernier point de reprise et
résume-moi ce qui a changé, en français.

Reviens à l'état du dernier point de reprise : je préfère
repartir de là.

Selon le mode de permission actif (module 4), Claude vous demandera confirmation avant d’exécuter ces opérations. Lisez la demande, acceptez, c’est tout.

⚠️ Piège courant — Enregistrer un point de reprise après avoir constaté les dégâts. À ce moment-là, l’état d’origine a déjà disparu. Le point de reprise se prend avant : c’est un réflexe de départ, pas une réaction.

Cas pratique : le point de reprise avant la grande réorganisation

Reprenons le dossier de papiers de famille du module précédent. Le plan a été relu, corrigé, il est prêt à être exécuté. Une dernière chose avant de lancer.

1. Enregistrer l’état de départ.

Avant qu'on touche à quoi que ce soit : enregistre un point de
reprise de ce dossier, avec la description « avant réorganisation ».

2. Lancer la réorganisation en mode Accept edits, comme au module 4.

3. Regarder ce qui s’est passé, sans avoir à ouvrir soixante fichiers :

Compare avec le point de reprise « avant réorganisation ».
Liste-moi les fichiers déplacés, les fichiers renommés, et
dis-moi si quelque chose a été supprimé.

La réponse est un résumé lisible. C’est exactement l’information qui manque quand on regarde un dossier réorganisé dans l’explorateur : impossible de savoir, à l’œil, si un fichier a disparu.

4. Décider. Le classement vous convient à 90 %, mais un sous-dossier est mal découpé. Deux options :

Reviens au point de reprise « avant réorganisation ».

… ou, plus souvent, on garde et on ajuste :

Garde tout, mais refais uniquement le sous-dossier « Véhicules » :
sépare les cartes grises des assurances.

Le point important : vous avez pu décider tranquillement, avec une vue complète de ce qui a changé, sans que rien ne soit irréversible.

Pas de bouton « rembobiner » dans l’application

Une précision qui vous évitera de chercher : les checkpoints et le rembobinage de session — la possibilité de revenir à un instant antérieur de la conversation, en annulant les modifications faites depuis — n’existent pas dans l’application de bureau. Ils sont disponibles en version terminal et dans l’extension VS Code, pas ici.

C’est précisément pour cette raison que Git compte dans l’application. En l’absence de rembobinage intégré, votre filet de sécurité, c’est le point de reprise que vous avez pris avant de lancer la tâche. Ou, plus simple encore quand vous débutez : une copie du dossier avant de commencer.

💡 Astuce — Le point de reprise n’est pas réservé aux grosses opérations. Prenez-le systématiquement avant toute demande qui touchera plus de trois ou quatre fichiers. Le coût est nul, le bénéfice est de pouvoir dire oui plus souvent.

Pour les développeurs, en bref

Cette section ne concerne que ceux qui publient du code — les autres peuvent la sauter sans rien perdre.

L’application intègre un suivi des pull requests : vous voyez l’état de vos demandes de relecture sans quitter Claude Code. Une option va plus loin et permet la correction puis la fusion automatiques ; elle s’appuie sur gh, l’outil en ligne de commande de GitHub, qui doit être installé et connecté à votre compte.

Le reste — messages de commit conventionnels, branches courtes, résolution de conflits assistée — s’obtient comme tout le reste : en le demandant en français dans la session.

À vous de jouer

1. Choisissez un dossier de travail réel — pas un projet de code, un vrai dossier en désordre — et ouvrez-le dans l’application.
2. Demandez le suivi de version : « mets ce dossier sous suivi de version et enregistre l’état actuel ». Acceptez les demandes de confirmation.
3. Faites une modification volontairement discutable : « renomme tous les fichiers de ce dossier en minuscules ».
4. Comparez : « compare avec le point de reprise et résume-moi ce qui a changé ». Lisez le résumé.
5. Revenez en arrière : « reviens au point de reprise ». Vérifiez dans l’explorateur que les noms d’origine sont revenus. Vous venez d’utiliser votre filet de sécurité.

En résumé

• Git = un carnet d’historique des versions d’un dossier. Vous enregistrez, vous comparez, vous revenez en arrière.
• Le bénéfice n’est pas technique : c’est de pouvoir essayer sans risquer l’irréversible.
• Tout se demande en français : enregistrer un point de reprise, comparer deux états, revenir à un état antérieur.
• L’application détecte les dossiers suivis par Git et donne à chaque session un espace de travail isolé.
• Les checkpoints et le rembobinage n’existent pas dans l’application (terminal et VS Code uniquement) : le point de reprise est votre seul filet.
• Le point de reprise se prend avant la manipulation, jamais après.
• Développeurs : suivi des pull requests intégré ; correction et fusion automatiques en option, via l’outil gh.

Les termes de ce module — dépôt, version, historique — sont définis dans notre glossaire.

Module 6 : arrêter de tout réexpliquer à chaque session, grâce à la mémoire du projet.