Actu Code 17 Oct 2026

GitHub bloque maintenant tes clés API Claude avant qu’elles partent en ligne

Depuis le 13 octobre, GitHub refuse les push qui contiennent une clé API Claude : ce que ça change et comment débloquer ton commit

GitHub bloque tes clés API : la push protection refuse désormais les clés Claude

Depuis le 13 octobre 2026, GitHub refuse par défaut un push qui contient une clé API Claude, même sur un dépôt public gratuit : ta clé ne part plus en ligne aussi facilement par accident. Si tu codes avec l’IA, c’est une bonne nouvelle, mais ça ne règle pas tout.

Qu’est-ce que GitHub a changé exactement ?

GitHub ajoute deux nouveaux types de clés Anthropic, et sa « push protection » les bloque maintenant sans réglage de ta part. La push protection, c’est un contrôle qui lit ce que tu envoies au moment du git push et qui refuse l’envoi s’il repère un secret connu. Elle est activée par défaut sur les comptes personnels pour les dépôts publics.

Jusqu’ici, ça se passait après coup. Depuis 2024, GitHub scannait les dépôts publics, prévenait Anthropic, et Anthropic désactivait la clé exposée en t’envoyant un e-mail. Ton compte était protégé, mais ton appli s’arrêtait d’un coup, et la clé avait bel et bien été publique. Maintenant, ton push est refusé avant que la clé n’arrive sur GitHub. Si une clé passe quand même, cette révocation reste le filet de sécurité.

Nouveau sur Git ? Le guide pour commencer sur GitHub t’explique le commit et le push.

Ton push est bloqué : tu fais quoi ?

Le terminal t’indique le commit et le fichier qui contiennent la clé : tu la retires, tu corriges le commit, et tu repousses. Clé dans ton dernier commit ? C’est rapide :

  • enlève la clé du fichier et mets-la dans un fichier .env, que tu ajoutes à ton .gitignore ;
  • lance git add .gitignore, puis git commit --amend --all pour réécrire ce commit sans la clé ;
  • refais ton git push.

Si la clé traîne dans un commit plus ancien, repère avec git log le premier commit qui la contient, puis :

  1. lance git rebase -i ID-DU-COMMIT~1 ;
  2. dans l’éditeur, remplace pick par edit sur ce commit, puis enregistre ;
  3. retire la clé du fichier ;
  4. lance git add . puis git commit --amend ;
  5. termine avec git rebase --continue, puis git push.

Détails dans la documentation de GitHub sur la push protection. GitHub te propose aussi un lien pour forcer le passage. Ne choisis surtout pas « I’ll fix it later » (je corrigerai plus tard) : ta clé partirait en ligne et Anthropic la désactiverait. Dans le doute, révoque la clé plutôt que de forcer le passage.

Est-ce que ça te protège à 100 % ?

Non : le blocage par défaut vise les dépôts publics, et il ne reconnaît que les secrets que GitHub connaît. Sur un dépôt privé, ne compte pas dessus. Et pour un autre service, tout dépend de la liste des secrets que GitHub reconnaît : ne pars pas du principe que ta clé sera bloquée.

La bonne habitude ne change donc pas : une clé ne va jamais dans le code. En local, elle vit dans ton .env. En ligne, elle va dans les variables d’environnement de ton hébergeur : Netlify, par exemple, recommande de les saisir dans son interface. Le comparatif Netlify, Vercel, Cloudflare Pages et GitHub Pages t’aide à choisir où mettre ton projet.

Et si tu penses qu’une clé a déjà fuité, ne te contente pas d’effacer le fichier : l’ancien commit reste dans l’historique. Supprime la clé dans la Console Claude (page des clés API, menu à trois points, « Delete API Key ») puis crée-en une nouvelle. C’est le réflexe à avoir en vibe coding, où l’IA colle parfois la clé là où il ne faut pas.