Guide · les réglages

Forcer Claude à te dire ce qui ne marche pas.

Par défaut il te ménage. Il valide tes idées, il annonce que c'est terminé quand ça ne l'est pas, puis il te laisse découvrir le problème tout seul deux heures plus tard.

Quatre réglages, du plus rapide au plus profond. Pour chacun : le texte exact à coller, où le mettre, puis l'erreur qui annule l'effet.

Tu débutes vraiment ? Commence iciL'app Claude ou Claude Code ? Ce n'est pas la même chose→

Avant tout : comprends d'où vient le problème

Ce n'est pas un défaut, c'est un réglage par défaut. Un assistant qui contredit son utilisateur toutes les trois phrases est insupportable, donc il penche du côté de l'accord. Le souci, c'est que sur du travail technique tu as besoin de l'inverse.

Trois symptômes qui doivent t'alerter : il commence sa réponse par « excellente question », il déclare une tâche terminée sans l'avoir lancée, puis il ne dit jamais « je ne sais pas ».

Le piège

Croire que ça se règle en lui demandant « sois honnête ». C'est trop vague pour changer quoi que ce soit. Une consigne qui marche décrit un comportement vérifiable, pas une qualité morale.

L'instruction anti-flatterie, à coller une fois

Elle va dans ton fichier de règles global, donc elle s'applique à tous tes projets, pour toujours. C'est le meilleur rapport entre l'effort et le résultat de tout ce guide.

Ne commence jamais une reponse par un compliment sur ma
question ou mon idee. Va directement au fait.

Quand je propose quelque chose qui te parait douteux, dis-le
en premier, avant de repondre a la demande.

Si tu n'es pas sur, ecris « je ne suis pas sur » suivi de ce
que tu verifierais pour en avoir le coeur net.

Où ça

Dans ~/.claude/CLAUDE.md, le fichier qui vaut pour tous tes projets. Trois lignes suffisent, ne le gonfle pas.

Le piège

Le mettre dans le fichier du projet plutôt que dans le global. C'est une règle de comportement, elle n'a rien à voir avec un projet précis, donc elle appartient au niveau du dessus.

Le guide qui va avecLes trois niveaux de CLAUDE.md. Lequel écrire en premier.→

L'interdire de dire « terminé » sans preuve

C'est le mensonge le plus coûteux, parce qu'il te fait avancer sur du sable. La parade est de lui demander une preuve plutôt qu'une conclusion.

Ne dis jamais qu'une tache est terminee sans avoir lance la
commande qui le prouve. Colle la sortie reelle.

Si tu n'as pas pu la lancer, ecris « non verifie » et dis
exactement quelle commande je dois taper pour verifier.

Bon à savoir

Cette règle transforme une affirmation en fait observable. C'est le même principe qu'un test : ce qui n'est pas exécuté n'est pas vérifié, quelle que soit la confiance affichée.

Le piège

Accepter une sortie recopiée de mémoire au lieu d'une sortie réelle. Si le bloc de résultat n'a ni horodatage, ni chemin, ni numéro de ligne, il n'a probablement jamais été exécuté.

Lui demander de chercher contre lui-même

Un modèle qui vient d'écrire quelque chose est le plus mauvais juge de ce qu'il a écrit. Il faut donc changer explicitement son rôle avant de lui demander un avis.

Oublie que tu viens d'ecrire ce code. Tu es maintenant la
personne qui doit le casser en production.

Donne-moi les trois scenarios ou ca tombe, du plus probable
au moins probable, avec pour chacun ce qui se passe pour
l'utilisateur.

La formulation compte : demander « est-ce que c'est bon ? » appelle un oui. Demander « comment ça casse » appelle une liste.

Le piège

Poser la question dans la même respiration que la demande initiale. Fais-en un second temps, une fois le travail rendu, sinon il anticipe la critique en écrivant puis s'auto-absout.

Rendre le doute visible dans chaque réponse

Le plus utile sur la durée. Au lieu d'un bloc de texte où le certain et l'incertain ont la même allure, tu obtiens une séparation nette.

A la fin de chaque reponse technique, ajoute deux lignes :

VERIFIE : ce que tu as reellement lance ou lu
SUPPOSE : ce que tu crois sans l'avoir verifie

Sans la règle	Avec la règle
« La fonction gère déjà ce cas. »	VÉRIFIÉ : lu dans `api.py` ligne 88. SUPPOSÉ : que l'appelant passe bien une liste.
« Ça devrait marcher. »	SUPPOSÉ : je n'ai pas pu lancer les tests ici.

Le piège

La laisser se transformer en formule creuse. Si les deux lignes arrivent toujours identiques, c'est qu'il les remplit sans y penser. Reprends-le une fois, ça suffit à recalibrer.

Premium

Le système qui empêche Claude de refaire la même erreur

Quoi faire quand le fichier de règles devient trop gros pour être lu
Le hook qui ressort la bonne leçon au moment du geste, pas au démarrage
173 leçons réelles, tirées d'un an de production

Voir ce qu'il y a dedans →

Si tu n'en gardes qu'un

Demande une preuve, pas une conclusion. Les trois autres réglages améliorent le ton. Celui-là change ce que tu peux croire. Un outil qui te dit « non vérifié » vaut infiniment plus qu'un outil qui te dit « c'est bon » sans avoir regardé.

Le guide suivantArrêter de cramer ton forfait au bout de dix prompts→

Un guide par semaine, tous ouverts.

Sans e-mail à donner. La formation complète ouvre bientôt à 39 € par mois ou 199 € l'année. Les premiers inscrits ouvrent avant les autres puis gardent ce tarif.

Passer en premier