Le contrôle de 3 minutes avant un commit: vérifier ce que Claude Code a vraiment touché

Un vendredi en fin de journée, j’ai demandé à Claude Code « change juste le texte du bouton dans l’article ». Quand il m’a rendu la main et que j’ai lancé git status, dix-huit fichiers étaient modifiés. Pour un simple texte de bouton, je voyais défiler la carte des liens produits, des articles connexes insérés un peu partout, et même des fichiers de traduction « corrigés au passage ».

Pris isolément, chacun de ces changements partait d’une bonne intention. Mais si j’avais tout committé tel quel, j’aurais aussi emporté avec moi une correction non sauvegardée d’un autre chantier en cours, et j’aurais passé la moitié du lendemain à chercher l’origine d’une erreur de déploiement.

Plus une IA est compétente, plus elle déborde légèrement du périmètre demandé. Sans mauvaise intention. C’est précisément pour ça qu’il faut un temps d’arrêt juste avant de valider: « on s’arrête là, et un humain regarde de ses yeux ».

Points clés

• Claude Code reste fidèle à la demande, mais le périmètre des fichiers touchés s’élargit en silence. Le contrôle avant validation sert à repérer ce débordement.
• Le contrôle suit toujours le même ordre, en 3 minutes: vérifier le périmètre, lire le diff, vérifier, puis indexer les fichiers choisis. Quatre étapes.
• Ce qu’on délègue à l’IA: l’exécution des modifications. Ce que l’humain décide: jusqu’où ces modifications entrent dans ce commit. Ne mélangez jamais les deux.
• Un script de vérification prêt à copier-coller est fourni. Il affiche git status et un résumé du diff sur un seul écran pour réduire les oublis.
• Une compilation qui passe ne doit pas vous rassurer. L’affichage après publication et le contenu des traductions demandent un autre regard.

Pourquoi placer le contrôle juste avant de valider

Le bon moment n’est ni avant de commencer le travail, ni au milieu: c’est juste avant le commit que le contrôle est le plus efficace. La raison est simple: ce n’est qu’à cet instant que la liste complète des fichiers réellement touchés par l’IA est figée.

Vous aurez beau dire « ne touche qu’à ça » avant de démarrer, l’IA mettra quand même la main sur ce qu’elle a jugé « bon de corriger au passage » pendant son travail. Et si vous l’arrêtez en cours de route, rien n’est terminé: vous ne savez pas quoi regarder. Tout est fini, juste un pas avant la validation. C’est là, et seulement là, que vous pouvez confronter « ce que j’ai demandé » à « ce qui a réellement changé ».

Là où je me plante souvent, c’est sur la partie qui touche au revenu. Par exemple, un lien vers une page produit décalé d’un seul caractère, et le lecteur qui clique atterrit sur une page « introuvable ». Peu importe la qualité du texte: si la cible du lien est morte, l’occasion de vente s’arrête là. Alors quand je lis un diff, la première chose que je vérifie, c’est que les cibles des liens n’ont pas bougé.

Si vous n’avez pas encore stabilisé votre usage de base de Claude Code, lisez d’abord le guide de démarrage Claude Code: vous comprendrez ensuite bien mieux le sens de cette procédure de contrôle.

L’ordre du contrôle, en 3 minutes

Si on ne peut pas le tenir tous les jours, ça ne sert à rien. La procédure tient donc en quatre étapes. Ce n’est pas un audit parfait, juste un léger garde-fou.

1. Énoncer le périmètre à voix haute. Reformulez la demande du jour en une phrase. Du genre « corriger le texte du bouton de l’article ». Cette phrase devient votre étalon de mesure pour la suite.
2. Regarder la liste des fichiers modifiés. Avec git status, observez le visage des fichiers qui ont changé. Dès qu’un fichier sort de la phrase que vous avez prononcée, marquez-le mentalement, comme un post-it.
3. Lire le diff des fichiers marqués. N’ouvrez que les fichiers hors périmètre. Décidez, un par un: changement utile, je le garde; changement sans rapport, je l’exclus pour cette fois.
4. N’indexer que les fichiers nécessaires. Pas de git add . qui prend tout. Ajoutez nommément les seuls fichiers requis par la demande du jour.

Le point décisif, c’est la troisième étape. Ne réduisez pas le périmètre élargi par l’IA à un choix binaire « tout accepter » ou « tout rejeter ». Un par un, c’est l’humain qui décide de garder ou d’écarter. C’est ingrat, mais sauter cette étape, c’est rejouer l’accident des dix-huit fichiers du début.

Ce qu’on délègue à l’IA et ce que l’humain décide

Si cette frontière reste floue, le contrôle devient purement formel. Voici comment je répartis les rôles.

Tâche	Responsable	Pourquoi
Exécuter les corrections de texte ou de code	IA	Volume important, traitement mécanique
Corriger les erreurs de syntaxe et fautes évidentes	IA	Règles claires, facile à automatiser
Décider si un changement entre dans ce commit	Humain	Seul l’humain connaît l’intention de la demande
Vérifier les cibles de liens et l’affichage publié	Humain	Une compilation qui passe ne garantit pas le contenu
Suppressions, données de production, facturation	Humain	Les accidents irréversibles exigent un accord humain

Si vous déléguez à l’IA jusqu’au « décide quoi inclure », elle voudra naturellement inclure tout ce qu’elle a corrigé. Gardez la décision sous la main. C’est le point névralgique numéro un pour réduire les accidents.

Modèle de prompt prêt à copier-coller

Quand vous faites aider l’IA pour le contrôle, l’astuce est de ne pas la laisser « s’auto-noter », mais de lui faire « aligner les faits ». Collez ce modèle tel quel.

Je vais committer. Avant de valider, rapporte uniquement les faits suivants. C'est moi qui déciderai.

1. Résume la demande du jour en une phrase.
2. Liste les fichiers modifiés via git status (y compris les non suivis).
3. Parmi eux, ceux qui semblent sortir de la phrase de la demande, et pourquoi.
4. S'il existe des changements pouvant affecter les liens ou l'affichage publié, indique les passages concernés.

N'écris pas « tout va bien ». Aligne seulement les éléments de décision.

La dernière phrase est celle qui compte. Sans elle, l’IA conclut avec entrain « rien à signaler, vous pouvez committer », et le contrôle perd tout son sens. Pour le détail de la construction des prompts, voir le guide avancé de prompt engineering.

Script de vérification prêt à l’emploi

Taper git status puis git diff à chaque fois est pénible, alors voici un script qui affiche la vue d’ensemble des changements sur un seul écran. Une version PowerShell et une version bash. Il se contente d’aligner « la liste des fichiers modifiés » et « le nombre de lignes ajoutées et supprimées par fichier ».

Version PowerShell (Windows).

# precommit-check.ps1
# Avant un commit, vérifier sur un seul écran les fichiers modifiés et leur volume

Write-Host "=== Fichiers touchés cette fois ===" -ForegroundColor Cyan
git status --short

Write-Host "`n=== Volume par fichier (ajouts / suppressions) ===" -ForegroundColor Cyan
git diff --stat HEAD

Write-Host "`n=== Liste de contrôle ===" -ForegroundColor Yellow
@(
  "Je peux énoncer la demande en une phrase",
  "Aucun fichier hors périmètre ne s'est glissé",
  "J'ai vérifié les liens et l'affichage publié",
  "Je n'indexe que les fichiers nécessaires cette fois"
) | ForEach-Object { Write-Host "  [ ] $_" }

Version bash (macOS / Linux / Git Bash).

#!/usr/bin/env bash
# precommit-check.sh
# Avant un commit, vérifier sur un seul écran les fichiers modifiés et leur volume

echo "=== Fichiers touchés cette fois ==="
git status --short

echo ""
echo "=== Volume par fichier (ajouts / suppressions) ==="
git diff --stat HEAD

echo ""
echo "=== Liste de contrôle ==="
for item in \
  "Je peux énoncer la demande en une phrase" \
  "Aucun fichier hors périmètre ne s'est glissé" \
  "J'ai vérifié les liens et l'affichage publié" \
  "Je n'indexe que les fichiers nécessaires cette fois"; do
  echo "  [ ] $item"
done

L’exécution se résume à ça.

bash precommit-check.sh

Ce script ne décide rien automatiquement. Pour ne pas trahir le principe « la décision revient à l’humain », il se contente volontairement d’« aligner et montrer ». Une fois les quatre points de la liste cochés, ajoutez les seuls fichiers nécessaires avec git add nom-du-fichier, puis committez.

Trois situations où ça paie sur le terrain

1. Avant de publier articles ou supports. Quand on publie d’un coup des articles multilingues, il arrive qu’un fichier de traduction soit resté en anglais. La compilation passe, mais le contenu n’est pas traduit. Ne vous contentez pas de voir le nom du fichier dans le diff: vérifiez la langue du corps de texte sur la page une fois publiée.

2. Réécriture d’un fichier existant. On croit corriger un texte, et ce sont les liens de la page ou les noms de produits qui se réécrivent au passage. Si vous avez fixé le périmètre par une phrase « amélioration du texte », vous pouvez vous arrêter une seconde devant la modification d’un lien, qui sort du périmètre.

3. Adoption en équipe. Notez jusqu’où Claude Code avance en automatique et où il demande l’humain. Si les règles d’approbation (opérations autorisées en automatique, opérations qui exigent toujours un humain) restent floues, chaque membre déclenche les accidents à sa façon et plus personne ne s’y retrouve.

Pièges fréquents et comment les corriger

Piège 1: tout prendre avec git add .. Vous emportez aussi les modifications non sauvegardées d’un autre chantier. Le correctif est simple: n’utilisez pas ., prenez l’habitude d’indexer les fichiers nommément. Même si ça paraît fastidieux, c’est l’assurance la plus rapide.

Piège 2: se rassurer parce que la compilation passe. La compilation ne regarde que la syntaxe; elle ne dit pas si la cible d’un lien est correcte ni si une traduction est bien traduite jusqu’au contenu. Le correctif: ouvrez vraiment la page publiée et vérifiez de vos yeux les titres, le corps de texte et les cibles de liens. Le succès d’une machine et le succès d’un humain sont deux choses différentes.

Piège 3: demander à l’IA « c’est bon ? » et s’arrêter là. Si on le lui demande, l’IA a tendance à répondre « tout va bien ». Le correctif: comme dans le modèle de prompt ci-dessus, demandez-lui « n’écris pas de jugement, aligne seulement les faits ». En rendant le sujet de la décision à l’humain, le contrôle se remet à fonctionner.

Pour ancrer ce contrôle comme une habitude, voir aussi les astuces de productivité avec Claude Code. Le comportement officiel de --stat et des autres options se vérifie dans la documentation officielle de Git.

FAQ

Q. Je n’ai pas le luxe de passer 3 minutes à chaque contrôle. R. Les jours où les changements sont petits, c’est plié en une minute. Les 3 minutes surviennent les jours où beaucoup de fichiers sortent du périmètre, et ce sont justement les jours où le contrôle est nécessaire. Voyez la durée comme un baromètre du danger.

Q. Peut-on déléguer l’indexation à l’IA ? R. Pour un petit travail dont vous savez qu’il est sûr, pourquoi pas. Mais gardez à l’humain la décision finale du « quels fichiers inclure ». C’est l’endroit qui sert le plus souvent de porte d’entrée aux accidents.

Q. Que faut-il écrire dans le message de commit ? R. Deux choses: « ce qui a changé » et « comment je l’ai vérifié ». Par exemple « correction du texte du bouton, cible du lien vérifiée sur la page publiée ». En relisant plus tard, on voit d’un coup d’œil si la vérification a eu lieu.

Q. Et si un fichier hors périmètre était en fait une correction qu’il valait mieux faire ? R. On l’exclut quand même cette fois. On le sépare simplement dans un autre commit, on ne le supprime pas. « Une intention par commit » rend le suivi bien plus facile par la suite.

Ce que j’ai constaté en pratique

Après l’affaire des dix-huit fichiers du début, j’ai pris l’habitude d’intercaler ces quatre étapes avant chaque validation. J’ai testé sur trois cas: publication d’article, réécriture de fichier, changement de configuration.

Ce qui a le plus payé, c’est la toute première étape: « reformuler la demande en une phrase ». Rien qu’à la dire à voix haute, les fichiers hors périmètre se mettent à sauter aux yeux. Quand j’ai arrêté de taper git add . après le script de vérification, pour indexer les fichiers nommément, les accidents qui emportaient un autre chantier sont tombés à zéro.

Et la vraie surprise, c’est l’effet du changement de question posée à l’IA, de « c’est bon ? » à « aligne seulement les faits ». La même IA est devenue d’un coup un partenaire de contrôle utile. Plutôt que chercher une IA plus intelligente, rendre le sujet de la décision à l’humain: c’est, pour moi, le geste le plus discret et le plus efficace.

Quand vous voulez décliner la gestion des permissions et le contrôle avant publication jusque dans le fonctionnement de toute une équipe, je construis avec vous une organisation concrète en formation et conseil.