Apprenez à réduire le contexte sensible dans Claude Code avec des modèles de prompt pratiques, des workflows de partage de fichiers et des étapes de redaction qui permettent d'obtenir une aide au codage utile en sécurité.
« Contexte » désigne tout ce que vous fournissez au modèle : extraits de code, traces de pile, fichiers de config, variables d'environnement, échantillons de base de données, captures d'écran et même des messages antérieurs dans le même chat. Plus il y a de contexte, plus le débogage peut aller vite, mais plus vous augmentez le risque de coller quelque chose que vous ne vouliez pas partager.
Le sur-partage arrive souvent sous pression. Un bug bloque une release, l'auth tombe juste avant une démo, ou un test instable échoue seulement en CI. Dans ces moments-là, il est facile de coller tout le fichier, puis tout le log, puis la config entière « au cas où ». Les habitudes d'équipe poussent souvent dans la même direction : en revue de code et débogage, la visibilité totale est normale, même quand seule une petite partie est nécessaire.
Les risques ne sont pas hypothétiques. Un seul collage peut divulguer des secrets, des données clients ou des détails internes du système. Exemples courants :
Le but n'est pas d'être secret. C'est de partager la plus petite portion qui reproduit le problème ou explique la décision, pour obtenir la même qualité d'aide avec moins d'exposition.
Un modèle mental simple : considérez l'assistant comme un collègue externe utile qui n'a pas besoin de tout votre repo. Commencez par une question précise (« Pourquoi cette requête renvoie-t-elle 401 ? »). Puis partagez uniquement ce qui supporte cette question : l'entrée qui échoue, le résultat attendu, le résultat réel et le chemin de code étroit impliqué.
Si un appel de login échoue, vous n'avez généralement pas besoin du module d'auth complet. Une paire requête/réponse assainie, la fonction qui construit les headers et les clés de config pertinentes (avec valeurs remplacées) suffisent souvent.
Quand vous demandez de l'aide pour du code, le « contexte » n'est pas seulement du code source. C'est tout ce qui pourrait aider quelqu'un à se connecter, identifier une personne ou cartographier vos systèmes. Commencez par savoir ce qui est toxique à coller.
Les identifiants transforment un extrait utile en incident. Cela inclut clés API et tokens, clés privées, cookies de session, URLs signées, secrets client OAuth, mots de passe de base de données et tokens « temporaires » imprimés dans les logs.
Une surprise fréquente est la fuite indirecte. Un message d'erreur peut contenir les headers complets d'une requête avec un bearer token Authorization, ou un dump de variables d'environnement en debug.
Toute donnée liée à une personne peut être sensible, même si elle semble inoffensive. Faites attention aux emails, noms, téléphones, adresses, IDs clients, IDs employés, tickets support avec conversations et informations de paiement.
Si vous avez besoin de données pour reproduire un bug, échangez les enregistrements réels contre des faux réalistes. Conservez la forme (champs et types), pas l'identité.
Les « faits ennuyeux » internes sont précieux pour des attaquants ou des concurrents : hostnames, IPs, noms de repo, IDs de ticket, noms de fournisseurs, clauses contractuelles et URLs de service internes.
Une seule stack trace peut révéler des chemins de dossiers avec noms d'utilisateur ou noms de clients, conventions de nommage de services et indices de comptes cloud (noms de bucket, région).
Tout le code n'est pas également sensible. Les morceaux les plus risqués sont ceux qui encodent le fonctionnement de votre business : règles de tarification et de remise, contrôles anti-fraude, logique de recommandation, templates d'invite pour fonctionnalités LLM et docs stratégiques.
Si vous avez besoin d'aide pour un bug, partagez la plus petite fonction qui le reproduit, pas le module entier.
Les détails sensibles se glissent souvent là où vous ne regardez pas : commentaires avec noms, messages de commit, TODOs référant des clients, et stack traces collées « telles quelles ». Les fichiers de config sont particulièrement risqués car ils mélangent paramètres inoffensifs et secrets.
Règle pratique : si le texte aiderait quelqu'un à comprendre votre système plus rapidement qu'un exemple en environnement propre, traitez-le comme sensible et redactez ou remplacez.
Le meilleur moment pour réduire l'exposition est avant d'ouvrir votre éditeur. Une pause de 30 secondes pour définir le résultat coupe souvent la majeure partie de ce que vous allez partager.
Commencez par nommer en une phrase le résultat souhaité. Cherchez-vous la cause d'un bug, un plan de refactor sécurisé ou la conception de tests ? Chaque objectif nécessite des entrées différentes. Les chasses aux bugs ont généralement besoin d'une stack trace et d'une petite fonction. Les questions de refactor demandent souvent uniquement les interfaces publiques et un court exemple d'utilisation.
Puis choisissez un « artefact minimal » qui prouve le problème. Prenez la plus petite chose qui échoue : un test qui échoue, le plus petit extrait qui déclenche l'erreur, un court extrait de log autour de l'échec ou un exemple de config simplifié avec placeholders.
Quand vous décrivez des données, privilégiez la forme plutôt que les valeurs. « L'objet user a id (UUID), email (string), role (enum), createdAt (timestamp) » suffit presque toujours. Si vous avez besoin d'exemples, utilisez des valeurs factices qui respectent le format, pas des enregistrements réels.
Soyez strict sur les fichiers. Partagez uniquement le module que vous changez plus les interfaces qu'il touche. Si une fonction appelle un autre module, vous avez souvent seulement besoin de la signature et d'une courte description de ce qu'il renvoie. Si un bug implique une requête vers un autre service, vous n'avez peut-être besoin que de la forme de la requête, d'une liste des noms d'en-têtes (pas des valeurs) et de la forme de la réponse attendue.
Fixez des limites qui ne quittent jamais votre machine : clés API, certificats privés, tokens d'accès, données clients, URLs internes, dumps de repo complet et logs de production bruts. Si vous déboguez un 401, partagez le flux d'auth et le message d'erreur, mais remplacez le token par TOKEN_REDACTED et l'email par [email protected].
Une bonne redaction ne consiste pas seulement à masquer des secrets. Elle conserve la structure du problème pour que l'assistant puisse encore raisonner. Enlever trop d'information donne des conseils génériques. Enlever trop peu expose des données.
Choisissez un style de placeholder et tenez-vous-y pour le code, la config et les logs. La cohérence facilite la lecture.
Si le même token apparaît en trois endroits, ne le remplacez pas de trois manières différentes. Utilisez des placeholders comme API_KEY_1, TOKEN_1, USER_ID_1, CUSTOMER_ID_1, EMAIL_1, et incrémentez si besoin (TOKEN_2, TOKEN_3).
Une petite légende aide sans révéler les vraies valeurs :
TOKEN_1: bearer token utilisé dans l'en-tête AuthorizationCUSTOMER_ID_1: identifiant client interne utilisé dans une recherche en baseAPI_KEY_1: clé utilisée pour appeler le fournisseur de paiementsCertains bugs dépendent de la longueur et de la structure (parsing, validation, checks de signature, regex). Dans ces cas, remplacez les chaînes uniques par des valeurs factices qui ont la même apparence.
Par exemple :
Cela vous permet de dire « le token échoue à la validation » sans exposer le vrai token.
Quand vous partagez du JSON, conservez les clés et remplacez les valeurs. Les clés indiquent ce que le système attend ; les valeurs sont souvent la partie sensible.
Au lieu de :
{"email":"[email protected]","password":"SuperSecret!","mfa_code":"123456","customer_id":"c8b1..."}
Partagez :
{"email":"EMAIL_1","password":"PASSWORD_1","mfa_code":"MFA_CODE_1","customer_id":"CUSTOMER_ID_1"}
Même idée pour le SQL : conservez les noms de table, les jointures et les conditions, mais retirez les littéraux.
WHERE user_id = USER_ID_1 AND created_at > DATE_1Si une fonction contient des règles métier ou une logique propriétaire, décrivez-la. Gardez ce qui affecte le bug : entrées, sorties, effets secondaires et gestion d'erreur.
Exemple de résumé utile :
“signRequest(payload) prend un JSON payload, ajoute timestamp et nonce, puis crée une signature HMAC SHA-256 à partir de method + path + body. Elle renvoie {headers, body}. L'erreur survient quand le payload contient des caractères non-ASCII.”
Ceci suffit généralement pour diagnostiquer des problèmes d'encodage, de canonicalisation et de mismatch de signature sans exposer l'implémentation complète.
À la fin de votre prompt, indiquez ce que vous avez retiré et ce que vous avez gardé. Ça évite des allers-retours et réduit la probabilité qu'on vous demande de coller plus.
Exemple :
“Redacted: tokens, emails, customer data, full request bodies. Kept: endpoint paths, status codes, header names, stack trace frames, and the exact error text.”
Traitez l'assistant comme un collègue qui n'a besoin que de la partie sur laquelle vous travaillez. Partagez des interfaces et des contrats plutôt que des fichiers entiers : signatures de fonctions, types, formes de requête/réponse et texte d'erreur exact. Un repro minimal en langage clair suffit souvent : l'entrée utilisée, ce que vous attendiez, ce qui s'est passé à la place et quelques notes d'environnement (version runtime, OS, version du framework). Vous n'avez pas besoin de tout l'historique du projet.
Modèles qui fonctionnent bien :
Un bloc de config assaini est un bon compromis. Il montre quels réglages existent sans exposer les secrets :
# sanitized
DB_HOST: "<set>"
DB_PORT: "5432"
DB_USER: "<set>"
DB_PASSWORD: "<redacted>"
JWT_SECRET: "<redacted>"
OAUTH_CLIENT_ID: "<set>"
OAUTH_CLIENT_SECRET: "<redacted>"
Exemple de prompt sûr :
“Login fails with 401. Expected 200. Actual response body: ‘invalid token’. Environment: Node 20, local dev, time sync enabled. Request contract: Authorization: Bearer redacted. Verify steps: token is issued by /auth/login and used on /me. What are the top causes (clock skew, audience mismatch, signing secret mismatch), and what single check confirms each?”
Une habitude fiable consiste à traiter le partage comme la préparation d'un petit package de reproduction. Partagez juste ce qui sert à diagnostiquer le problème, et rien de plus.
Une approche pratique est un dossier « share » temporaire séparé de votre repo réel. Copiez-y les fichiers manuellement plutôt que de partager tout le projet. Ça force des choix intentionnels.
Gardez le workflow simple :
Après avoir construit le dossier, lisez-le comme un outsider. Si un fichier n'aide pas au diagnostic spécifique, il n'a pas sa place.
Quand vous redactez, évitez de casser le code ou les logs. Remplacez les valeurs par des placeholders évidents qui conservent les types et la structure. Par exemple, remplacez :
DATABASE_URL=postgres://user:[email protected]:5432/app
par :
DATABASE_URL=postgres://user:REDACTED@localhost:5432/app
Si le bug dépend d'une réponse tierce, décrivez la forme de la réponse dans votre README et incluez un fichier JSON synthétique qui la reproduit. Vous pouvez obtenir un débogage significatif sans partager le trafic réel.
Utilisez une boucle répétable pour ne pas improviser sous pression.
Écrivez deux phrases d'abord.
Rassemblez les entrées minimales. Apportez seulement ce qui aide à reproduire ou raisonner sur le problème : un petit extrait autour de la ligne qui échoue, le texte d'erreur exact, versions pertinentes et 3 à 5 étapes de repro.
Redigez sans aplatir la structure. Remplacez les secrets par des placeholders et conservez la forme. Retirez les identifiants qui n'affectent pas le comportement (noms de projet, tenant IDs, emails). Gardez les placeholders cohérents.
API_KEY=sk_live_...
becomes
API_KEY=<API_KEY>
customer-1234-prod-db
becomes
<DB_HOST_PROD>
Posez des questions ciblées. Associez « Quelle est la cause la plus probable ? » avec « Que dois-je changer ? ». Si vous voulez un patch, demandez une modification limitée à l'extrait fourni et exigez que les hypothèses soient étiquetées.
Vérifiez localement, puis ajoutez un seul nouveau détail. Testez la suggestion. Si elle échoue, ajoutez une seule nouvelle information (la ligne suivante de la stack trace, un flag de config, un repro resserré). Ne passez pas directement à coller tout un fichier.
Cette divulgation incrémentale obtient généralement une vraie réponse tout en préservant secrets et code non liés hors du prompt.
Situation courante : le login marche sur votre laptop et en staging, mais échoue en production. Vous avez besoin d'aide vite, mais vous ne pouvez pas coller de vrais tokens, emails utilisateurs, hostnames internes ou votre middleware d'auth complet.
Commencez par ce que vous pouvez observer : forme de la requête et de la réponse, code de statut et une courte stack trace. Si c'est lié à des JWT, vous pouvez aussi partager des détails d'en-tête non sensibles (algorithme attendu) et des informations temporelles (dérive d'horloge). Gardez tout le reste en placeholders.
Un bundle sûr contient souvent :
Ensuite posez une question ciblée. Les échecs d'auth uniquement en production viennent souvent de dérive d'horloge, mauvais issuer/audience, clefs de signature différentes, rotation de clefs manquante, ou différences de proxy/en-têtes.
Modèle de prompt :
I have a production-only login/auth failure. Locally it passes.
Observed behavior:
- Endpoint: POST /api/login
- Production response: 401 with message "invalid token" (generic)
- Staging/local: 200
Sanitized request/response:
- Authorization: Bearer <JWT_REDACTED>
- Expected claims: iss=<ISSUER_PLACEHOLDER>, aud=<AUDIENCE_PLACEHOLDER>
- Token validation library: <LIB_NAME_AND_VERSION>
Sanitized log snippet:
<PASTE 5-10 LINES WITH TOKENS/EMAILS/HOSTS REDACTED>
Question:
Given this, what are the top causes of JWT validation failing only in production, especially clock skew or claim mismatch? What specific checks and log lines should I add to confirm which one it is?
Après avoir obtenu des hypothèses, validez en sécurité avec des changements que vous pouvez conserver. Ajoutez des logs temporaires qui n'impriment que des faits non sensibles (exp, iat, now, et le code raison de l'échec). Écrivez un petit test qui injecte un token fixture sûr (ou un token généré localement) et assert le comportement du validateur sur les cas limites.
Plan simple :
La façon la plus rapide de perdre les bénéfices de confidentialité est de partager « une petite chose » qui contient en réalité tout. Coller un .env complet ou un fichier de config est l'exemple classique. Même après avoir supprimé les secrets évidents, ces fichiers contiennent souvent hostnames internes, noms de services, feature flags et indices d'environnement qui cartographient votre système.
Les traces de pile complètes sont une autre fuite fréquente. Elles peuvent inclure noms d'utilisateur, noms de machine, noms de repo et chemins absolus comme /Users/alex/company-payments/.... Parfois elles contiennent des query strings, headers HTTP ou objets d'erreur avec tokens. Si vous avez besoin de la trace, copiez seulement les frames pertinentes et remplacez les chemins par des placeholders cohérents.
Les payloads clients réels sont risqués même s'ils sont « petits ». Un seul JSON peut contenir emails, adresses, IDs de commande ou notes en texte libre. Le mouvement plus sûr est de générer un payload factice avec la même forme et les mêmes cas limites (champs manquants, longues chaînes, caractères étranges), sans vraies valeurs.
Les placeholders incohérents posent aussi problème. Si USER_ID signifie « customer id » à un endroit et « internal account id » à un autre, vous obtiendrez un mauvais diagnostic. Choisissez un schéma et tenez-vous-y.
Si votre message aiderait un inconnu à se connecter, localiser vos serveurs ou identifier un client, il faut le retravailler.
Quand vous essayez d'être prudent, la vitesse est votre ennemie. Une routine courte vous aide à obtenir des réponses utiles tout en gardant les données sensibles hors du prompt.
Faites un passage pour les secrets, puis un second pour les identifiants qui exposent encore votre système :
Après redaction, conservez la forme. Laissez les types, schémas, noms de champs, codes de statut et structure d'exemple, mais remplacez les vraies valeurs par des placeholders.
Pour rester cohérent (surtout sous pression), notez un petit ensemble de règles de redaction et réutilisez-les. Pour les équipes, transformez cela en template partagé avec deux blocs : « ce que je partage » (fichiers, fonctions, endpoints) et « ce que je ne partage pas » (secrets, données de production, domaines internes).
Si vous voulez une couche de sécurité supplémentaire, faites vos expériences en environnement isolé et gardez les changements réversibles. Dans Koder.ai (koder.ai), le mode planning peut aider à décrire le plus petit changement nécessaire pour tester une hypothèse, et les snapshots + rollback facilitent l'essai sans amener de contexte sensible dans vos prompts.
Commencez par la plus petite portion capable de répondre à votre question : l'entrée qui échoue, le résultat attendu vs réel, et le chemin de code restreint impliqué.
Un paquet par défaut utile est :
Ne collez pas :
.env complets / dumps de config ou logs de production brutsSi cela aiderait un inconnu à se connecter, identifier une personne ou cartographier vos systèmes, redigez ou résumez.
Utilisez des placeholders cohérents pour que le flux reste lisible.
Exemple de schéma :
TOKEN_1, TOKEN_2API_KEY_1USER_ID_1, Conservez le format quand le bug dépend du parsing ou de la validation.
Cas fréquents :
8-4-4-4-12Cela rend le comportement réaliste sans exposer la vraie valeur.
Partagez la structure (clés et schéma) et remplacez les valeurs.
Pour JSON :
Pour SQL :
Exemple :
Faites-en un résumé en termes d'entrées, sorties et de la règle spécifique qui affecte le bug.
Un résumé pratique comprend :
Souvent cela suffit pour diagnostiquer sans révéler l'implémentation.
Un prompt sûr et simple ressemble à :
Ajoutez une note de redaction comme :
"Redacted: tokens, emails, customer data, internal hostnames. Kept: endpoint paths, status codes, header names, exact error text."
Parce qu'ils regroupent tout en un :
Alternative plus sûre : un template de config :
Utilisez une divulgation progressive :
Cela garde la portée petite et empêche les fuites sous pression.
Un paquet pratique :
Puis demandez :
CUSTOMER_ID_1EMAIL_1Ajoutez une petite légende si nécessaire :
TOKEN_1: bearer token utilisé sur /meCUSTOMER_ID_1: identifiant interne utilisé pour la recherche en baseWHERE user_id = USER_ID_1 AND created_at > DATE_1\u003cset\u003e ou \u003credacted\u003e