J'ai mémorisé toutes les commandes Claude Code, et mes doigts se figent : le premier geste sûr

Un vendredi soir, j’ai reçu ce message sur Slack d’un collègue plus jeune : « Claude Code, j’ai mémorisé toutes les commandes, mais je n’arrive pas à décider quoi taper ensuite, alors je reste bloqué. » Il sait dire /init, /clear, claude -p. Et pourtant, face à son propre dépôt, ses doigts se figent.

Ce n’est pas une question de compétence. Une fiche de commandes n’est qu’une liste de « noms d’outils ». Elle ne dit jamais quoi confier en premier, jusqu’où, ni comment vérifier le résultat. Du coup, plus on en mémorise, moins on arrive à bouger.

Cet article parle de ça : comment sortir de ce blocage « je connais tout mais je n’avance pas » en lançant le plus petit geste possible.

Points clés

• Si on bloque même en connaissant les commandes, c’est que quatre choses ne sont pas décidées : le périmètre autorisé, les fichiers interdits, le retour arrière et la preuve.
• Le premier résultat peut être minuscule : « corriger un seul paragraphe » ou « faire expliquer le sens d’un test rouge ».
• Avant de déléguer, demandez « renvoie-moi seulement le plan, ne modifie rien » : les accidents chutent.
• Pour la vérification, décidez d’abord une commande machine comme git diff, plutôt que de vous fier à l’œil humain.
• Une fois à l’aise, faites monter progressivement vers l’automatique seulement les opérations dont vous avez prouvé la sûreté.

Pourquoi on se fige même en connaissant la fiche

Une liste de commandes, c’est comme une « liste de panneaux de signalisation » sur une carte. Même si vous savez nommer tous les panneaux, tant que la destination et l’endroit où tourner ne sont pas fixés, la voiture ne démarre pas.

Ce qui manque à ceux qui bloquent n’est pas du savoir, mais l’habitude de mettre ces quatre points en mots :

• Quels fichiers faire lire, et lesquels ne jamais laisser toucher.
• À quel point découper petit la première modification.
• Quelle est la condition pour dire « ça a marché » (que regarder pour valider).
• Comment revenir en arrière en cas d’échec.

Moi aussi, au début, j’ai lancé un « rends ce projet un peu mieux » et je me suis figé devant un diff de 30 fichiers réécrits. Un diff illisible ne se vérifie pas. Et une modification qu’on ne peut pas vérifier, on a trop peur de l’adopter. C’est pour ça qu’au début, il faut commencer ridiculement petit. C’est la bonne réponse.

Le premier geste peut être aussi petit que ça

Quand on entend « résultat », on imagine une grosse fonctionnalité, mais au début ce niveau suffit largement :

• Rendre les 3 premières lignes du README plus lisibles, c’est tout.
• Ajouter une seule phrase au texte d’invitation en bas d’un article.
• Faire expliquer le sens d’un test qui échoue, « sans le corriger ».

Le troisième est particulièrement recommandé. On ne change pas une seule ligne de code, donc rien ne peut casser. Et pourtant on obtient la première sensation : « J’ai fait lire mon dépôt à Claude Code, et une réponse est revenue. » Si vous êtes bloqué, commencez à bouger les doigts ici.

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

Le travail confié à Claude Code et le jugement que l’humain garde, séparez-les clairement dès le départ. Si on lance les choses dans le flou, l’IA avance presque toujours jusque dans le territoire où c’est à l’humain de décider.

Situation	Confié à Claude Code	Décidé par l’humain
Définir le périmètre	Chercher et proposer des fichiers candidats	Décision finale des fichiers autorisés
Édition	Brouillon de texte ou de code	Adopter ou non
Vérification	Lancer les tests, résumer le diff	Juger si on publie
Opérations risquées	Proposer la méthode, pas plus	Suppression, mise en prod, paiement

Le point clé, c’est la colonne de droite. La suppression, la mise en production, les opérations qui font bouger de l’argent, les manœuvres difficiles à annuler comme git push --force : au début, fixez-les toutes sur « c’est l’humain qui appuie ». Seulement ce dont vous avez vous-même vérifié la sûreté passe ensuite à gauche. Rien qu’en respectant cet ordre, le nombre de sueurs froides en pleine nuit chute nettement.

D’abord, demandez « seulement le plan »

L’astuce : ne pas faire éditer tout de suite. Pour la première demande, ne laissez pas l’IA bouger les mains, faites-la d’abord énoncer le plan. Vous pouvez coller le prompt ci-dessous tel quel.

Je vais te demander une seule petite modification. Ne modifie encore rien.
D'abord, renvoie-moi ces 4 points sous forme de liste :

1. Le fichier touché (un seul)
2. Les fichiers à ne pas toucher (ne jamais toucher .env, l'authentification, la facturation)
3. Le contenu de la modification (ne change pas le comportement, corrige seulement le texte)
4. La commande que je lancerai après pour vérifier (git diff, etc.)

Attends mon OK sur ces 4 points avant de commencer l'édition.

Regardez les 4 points renvoyés : si le fichier touché est bien réduit à un seul et que la commande de vérification est écrite, le niveau de granularité de la demande est bon. À l’inverse, une réponse du genre « je vais revoir tout le dépôt » est le signal que la demande est encore trop large. Resserrez le périmètre et redemandez avec le même format.

Si vous avez du mal à rédiger la demande, la conception de prompts pour Claude Code et comment écrire un CLAUDE.md servent de socle. Donner les règles du projet en amont fait monter d’un cran la qualité du plan.

Une checklist du premier geste, prête à copier-coller

Réécrire chaque fois ces 4 points dans un fichier, c’est pénible. J’ai donc préparé un petit script qui produit un « mémo du premier geste » rien qu’en remplissant les réponses. Il fonctionne si vous avez Node.js.

// first-win.mjs — mettre en mots son premier geste en 1 minute
// Usage : node first-win.mjs

const plan = {
  objectif: "réussir une petite modification en toute sécurité avec Claude Code",
  fichierTouche: ["README.md"],            // un seul
  fichiersInterdits: [".env", "auth", "facturation", "BDD de prod"],
  premiereCommande: "git status --short",  // vérifier l'état actuel
  modification: "rendre l'intro lisible sur 3 lignes. Ne pas changer le comportement",
  verification: "git diff -- README.md",   // le diff est-il lisible ?
  retourArriere: "git checkout -- README.md", // si ça rate, on recommence
};

// Contrôle : le fichier touché est-il bien réduit à un seul ?
if (plan.fichierTouche.length !== 1) {
  console.error("⚠ Au début, limitez-vous à un seul fichier touché");
  process.exit(1);
}

console.log("=== Mémo du premier geste ===");
for (const [cle, valeur] of Object.entries(plan)) {
  const texte = Array.isArray(valeur) ? valeur.join(", ") : valeur;
  console.log(`${cle} : ${texte}`);
}
console.log("\nColle ce mémo dans Claude Code et demande « renvoie le plan avant d'éditer »");

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

node first-win.mjs

Collez le mémo obtenu directement dans Claude Code et utilisez-le avec le prompt « renvoie seulement le plan » ci-dessus. Dès qu’il y a deux fichiers touchés ou plus, le script s’arrête à la première ligne : ça sert aussi de garde-fou quand on devient trop gourmand.

Trois cas où ça a vraiment marché

Voici trois exemples que moi ou mon entourage avons choisis comme « premier geste », et qui ont vraiment fait avancer les choses.

1. Corriger l’intro du README. Pour le lecteur venu chercher des commandes, rendez seulement les 3 premières lignes plus simples. La vérification se fait avec git diff uniquement, donc on obtient au plus vite la sensation concrète de lire un diff. C’est là qu’on prend confiance.

2. Ajouter une phrase au texte d’invitation sous un article. Là où l’explication est trop maigre, ajoutez une seule phrase et vérifiez sur l’URL publique que le lien cible est bien vivant. Comme c’est une modification de texte uniquement, aucun risque de casser le code.

3. Faire expliquer le sens d’un test rouge. Ici, on ne fait rien corriger. Demandez seulement trois choses : « le sens de l’erreur », « les fichiers probablement concernés » et « où l’humain doit regarder ensuite ». Sans toucher une ligne de code, vous vous entraînez à deviner la cause.

Le point commun aux trois : la vérification tient en une commande, et même en cas d’échec on revient en arrière en une seconde. Si vous n’êtes pas développeur, lisez aussi Claude Code pour les non-techniciens : vous choisirez plus facilement un premier geste côté texte.

Pièges fréquents, et comment les corriger

Piège 1 : demander « améliore ce dépôt » juste après avoir vu la fiche. Le périmètre est trop large, et le diff renvoyé devient illisible. La correction est simple : resserrer jusqu’à « 1 fichier, 1 paragraphe ». Plus c’est étroit, plus le premier résultat est sûr.

Piège 2 : remettre la vérification à plus tard. Si on lance sans décider quoi regarder pour valider, même un résultat plausible ne nous dit pas s’il faut l’adopter. Écrivez dès le départ une commande de vérification comme git diff dans la demande.

Piège 3 : confier d’emblée une opération risquée. Mettre en automatique la suppression de fichiers ou la mise en prod dès le début, c’est l’accident irréversible. Au début, fixez tout sur « c’est l’humain qui appuie », et faites monter en automatique seulement ce dont vous avez prouvé la sûreté.

FAQ

Q. Combien de commandes faut-il connaître avant de commencer ? R. Trois suffisent : /init, /clear, et git diff pour vérifier les changements. Le reste, vous le chercherez le moment venu, ça ira. Bouger petit avant de tout mémoriser fait, au final, apprendre plus vite.

Q. Quel travail convient le mieux pour un premier geste ? R. Faire « seulement expliquer » le sens d’un test rouge. Comme on ne change pas le code, rien ne peut casser, et on obtient juste la sensation de faire lire son dépôt. Le déroulé de base est résumé dans le guide de démarrage.

Q. J’ai demandé un plan, mais l’IA commence à éditer tout de suite. R. Mettez « Ne modifie encore rien » en tête du prompt, et ajoutez « Attends mon OK » à la fin. Si ça continue quand même, c’est souvent que le périmètre est flou : nommez explicitement un seul fichier touché.

Q. L’œil humain ne suffit-il pas pour vérifier ? R. Les jours chargés, ça casse à tous les coups. En décidant d’abord une vérification machine — nombre de caractères, diff, succès ou échec des tests — on réduit les oublis. Le truc, c’est de concentrer le jugement humain sur « adopter ou non ».

Q. Une fois à l’aise, quelle est l’étape suivante ? R. Étendez le même « mémo du premier geste » à un travail un peu plus gros. Même si les commandes de vérification se multiplient, ne changez pas le principe : l’humain garde la main sur les opérations risquées. Pour accélérer le travail, les astuces de productivité sont une bonne référence.

Ce que j’ai constaté en l’essayant pour de vrai

Au collègue du début, j’ai d’abord fait faire le geste « explique seulement le sens d’un test rouge ». On ne touche pas au code. Ce qui est revenu : le nom du fichier en cause, et l’emplacement de la fonction à regarder ensuite. Il a dit « ça, je peux le faire » et, dans la journée, il est allé jusqu’à corriger les 3 lignes du README.

Moi-même, depuis que j’ai arrêté de tout déléguer en bloc et que j’intercale « renvoie seulement le plan », le temps passé à me figer devant un diff illisible a quasiment disparu. Ne demander que ce qu’on peut vérifier avec git diff, et garder les opérations risquées sous la main de l’humain. Rien qu’en respectant ces deux règles, le premier geste sort étonnamment léger. Pas besoin de mémoriser toutes les commandes. Bougez petit, vérifiez le périmètre réversible. Commencer là suffit amplement.

Pour passer un cran dans l’apprentissage, regardez le catalogue de supports ; pour discuter de l’intégration dans les processus de votre entreprise, voyez la formation et le conseil. Pour le comportement précis des commandes, la documentation officielle reste la source de référence la plus fiable.