Antisèche : repérer quand le modèle dérive
Les signes d'une réponse qui invente, et la ligne à coller pour les rendre visibles au lieu de les subir.
Un modèle ne prévient pas quand il passe du « je sais » au « je comble ». Le ton reste identique, la syntaxe aussi, et c'est précisément ce qui rend la dérive coûteuse : on la découvre trois étapes plus tard.
Cette fiche donne les signes à reconnaître, et une ligne à coller pour les rendre visibles.
Les signes
| Signe | Ce qu'il indique |
|---|---|
| Des noms d'options ou de fonctions plausibles mais introuvables | Le modèle complète un motif au lieu de citer |
| Des chiffres ronds sans source (« environ 40 % plus rapide ») | Ordre de grandeur inventé |
| Une assurance qui monte quand tu insistes | Il défend une position, il ne la vérifie plus |
| Des chemins de fichiers jamais ouverts dans la session | Il suppose la structure du dépôt |
| Un raisonnement qui recommence à chaque relance | Le contexte utile est sorti de la fenêtre |
| Des excuses répétées suivies de la même erreur | Il n'a pas identifié la cause |
Le pire moment
La dérive arrive le plus souvent après une longue session, ou juste après une série de succès. Le contexte est chargé, tu fais confiance, et la vérification se relâche exactement quand elle devient nécessaire.
La ligne à coller
Dans ton CLAUDE.md, ou en tête d'une tâche sensible :
Marque d'un [?] toute affirmation que tu n'as pas verifiee dans le code, la
documentation ou une sortie de commande de cette session. Si tu n'es pas sur
d'un nom d'option, d'une signature ou d'un chiffre, dis-le au lieu de choisir
le plus plausible.
Ce que ça change : les suppositions deviennent visibles au lieu de se fondre dans le texte. Tu ne les élimines pas, tu les vois.
Avant de commencer
- Rien à installer
- Une tâche où une erreur coûte cher
Les trois questions de contrôle
À poser dès qu'une réponse te paraît trop lisse.
1. Séparer ce qui est vu de ce qui est supposé.
Liste ce que tu as reellement lu dans cette session, et separement ce que tu
as suppose sans le verifier.
2. Demander la source, pas la reformulation.
Montre-moi la ligne exacte, avec fichier et numero, qui prouve ce que tu viens
d'affirmer. Si elle n'existe pas, dis-le.
3. Tenter la réfutation.
Essaie de demontrer que ta reponse precedente est fausse. Si tu n'y arrives
pas, dis ce qui t'en empeche.
Pourquoi ça fonctionne
Ces trois formulations demandent une vérification, pas une confirmation. Un modèle à qui l'on demande « es-tu sûr ? » répond presque toujours oui. À qui l'on demande « montre la ligne », il ouvre le fichier ou il avoue.
Ce qu'il faut faire quand ça dérive
Insister n'aide pas : le contexte est déjà pollué par les hypothèses fausses, et chaque relance les reformule.
- Couper.
/clear, ou une nouvelle session. - Reformuler seul. Réécrire la demande sans reprendre les termes de la réponse ratée.
- Donner les faits d'emblée. Le fichier concerné, la sortie d'erreur exacte, la version utilisée.
- Demander le diagnostic avant la correction. « Dis-moi ce qui se passe et comment le vérifier » avant tout changement.
Le réflexe qui coûte le moins cher
Sur toute affirmation qui va décider d'une action irréversible, une seule question :
Comment peut-on verifier ca en une commande ?
Si la réponse ne contient pas de commande exécutable, l'affirmation n'est pas encore un fait.
Tu as d’autres ressources comme ça ?
Ce que tu viens de lire est entièrement gratuit. Une nouvelle ressource part chaque semaine dans la newsletter : guides, modèles à copier et liens triés, sans compte à créer.
Me contacter
Une question, un projet, une envie de collaborer ? Écris-moi.
Cette page est en accès libre, n’hésite pas à la partager.