Illustration originale GEEKKECH. Schéma de méthode : les exclusions, les fichiers suivis et les anciens commits doivent être vérifiés séparément. Aucun secret réel n’est représenté.
Texte rédigé le 09/11/2026. La date affichée correspond à la rédaction. Mise en ligne ultérieure.
Le client accepte le prototype et demande le dépôt. Les tests passent. Pourtant, une autorisation donnée pendant le développement peut se retrouver dans un fichier de réglages, puis dans un ancien commit. Un fichier absent du dernier état du projet peut donc rester accessible à qui reçoit son historique. Avant la remise, vérifiez séparément les réglages de l’agent, les fichiers suivis et les références Git accessibles.
Ce qu’une autorisation mémorisée peut laisser
Claude Code peut enregistrer l’autorisation durable d’une commande
Bash dans .claude/settings.local.json, sous la forme d’une
règle allow. Ce fichier sert aux réglages personnels du
projet. Anthropic documente son exclusion Git lors de sa création par
l’outil, ainsi que le cas d’un fichier créé manuellement. Le fichier
partagé .claude/settings.json a une autre fonction. Une
équipe peut le versionner pour distribuer ses règles et ses hooks. Il
mérite donc une revue distincte. Documentation Anthropic,
consultée le 9 novembre 2026.
Dans un rapport publié le 5 novembre 2026, Apiiro dit avoir identifié
des secrets dans 1 122 des 104 185 copies publiques de
.claude/settings.local.json analysées sur GitHub. La
collecte s’est déroulée du 1er au 3 novembre. Ce résultat porte sur des
fichiers publics repérés par la recherche de GitHub. Les auteurs ont
classé les valeurs selon leur format et leur contexte, sans tester leur
validité. Parmi les cas étudiés, des commandes autorisées contenaient un
mot de passe ou une clé en clair. Rapport
original d’Apiiro.
Reproduire le problème sans secret réel
Exécutez cette démonstration dans un terminal Bash. Elle crée un dépôt temporaire local et un fichier synthétique. Git 2.51.1 a servi à vérifier l’exemple. Claude Code et un compte GitHub sont facultatifs pour reproduire le comportement de Git.
(
set -eu
cd "$(mktemp -d)"
git init -q
git config user.name 'Démo'
git config user.email 'demo@example.invalid'
fichier=.claude/settings.local.json
mkdir -p .claude
printf '%s\n' '{"permissions":{"allow":["Bash(echo EXEMPLE_FICTIF)"]}}' > "$fichier"
git add -f -- "$fichier"
git commit -qm 'Ajouter un réglage fictif'
printf '%s\n' '/.claude/settings.local.json' > .gitignore
git ls-files -- "$fichier"
git rm --cached -q -- "$fichier"
git add .gitignore
git commit -qm 'Exclure le réglage local'
git ls-files -- "$fichier"
git check-ignore -- "$fichier"
git log --all --full-history --format='%h %s' -- "$fichier"
)Le premier git ls-files affiche le chemin malgré
.gitignore. Après le retrait de l’index, le second est
silencieux et git check-ignore affiche le chemin. Le
journal affiche encore les deux commits. Le -f sert
uniquement à créer la situation de départ dans cette démonstration, même
avec une exclusion globale active. Sur un dépôt client, commencez par
les commandes de lecture. Documentation Git sur les
exclusions et sur
l’historique.
Quatre vérifications avant la remise
- Fixer le périmètre. Notez le commit examiné, les branches et tags disponibles, les agents et leurs versions. Un clone superficiel réduit l’historique accessible. Faites l’inventaire des chemins réellement utilisés, y compris les sous-projets. Anthropic précise que les versions antérieures à Claude Code v2.1.211 pouvaient laisser le fichier local dans le répertoire de démarrage. Documentation Anthropic.
- Relire les autorisations. Examinez les réglages locaux et partagés dans un environnement autorisé. Cherchez les commandes trop larges, les chemins sensibles et les identifiants écrits en clair. Un script borné, relu et alimenté par le gestionnaire de secrets du client est plus facile à examiner qu’une longue commande assemblée par l’agent.
- Vérifier les traces. Recherchez dans les références Git disponibles les fichiers de réglages, notes de livraison et exports de conversation identifiés. Utilisez un détecteur de secrets et une lecture ciblée des commandes enregistrées. Consignez le chemin, le commit et la catégorie du risque dans le rapport. Masquez les valeurs.
- Traiter une exposition. Alertez le propriétaire et faites révoquer ou renouveler l’identifiant par la personne habilitée. Coordonnez ensuite le nettoyage de l’historique et les vérifications sur les copies, forks et références de la plateforme. Une recherche par chemin peut manquer une copie renommée et ne couvre que les références auxquelles l’auditeur a accès. Procédure GitHub sur les données sensibles.
Chiffrer une prestation sur un dépôt
Une agence qui livre un plugin WordPress ou une équipe qui reprend un SaaS peut acheter une revue bornée à un dépôt et à un agent. Le livrable comprend les références inspectées, les constats expurgés, les corrections prioritaires et une contre-vérification sur un commit désigné. Le devis précise qui peut modifier les réglages, remplacer les clés et coordonner un éventuel nettoyage. Pour un APK ou un jeu, cette même revue s’applique au dépôt. La chaîne de signature et les comptes de distribution demandent un périmètre propre.
Simulation en MAD. Un forfait hypothétique de 1 800
MAD couvre six heures valorisées à 180 MAD et 120 MAD de coûts directs.
Le coût direct total est de 1 200 MAD. Il reste 600 MAD, soit 33,3 % du
prix avant frais indirects et impôts. À neuf heures, il reste 60 MAD,
soit 3,3 %. Le calcul est
prix − heures × coût horaire − dépenses directes. Ces
valeurs sont des hypothèses de devis. Un test de demande consiste à
présenter un rapport expurgé issu du dépôt fictif, puis à mesurer si une
agence accepte un diagnostic payé à périmètre écrit.
Le contrôle Git complète la recette fonctionnelle. Le premier porte sur les traces du développement et les droits de l’agent. La seconde vérifie que l’application résiste à des usages réels, comme un import en double ou une tentative d’accès à un autre compte. Recette d’un prototype avant livraison, Geekkech, 7 novembre 2026.