Vous avez poussé une clé d'API : les dix premières minutes, dans l'ordre

Vous avez lancé git push, ouvert le diff sur GitHub, et votre clé d'API est là, en clair. Le réflexe, c'est de supprimer le commit et de forcer le push avant que quelqu'un ne la voie. Ne commencez pas par là. Considérez la clé comme compromise dès l'instant du push, et passez la première minute chez le fournisseur, pas dans git.

Pourquoi supprimer le commit ne suffit pas

Un push copie votre historique vers des endroits que vous ne contrôlez pas. Quiconque a cloné ou forké le dépôt possède le commit. Des robots surveillent les push publics à la recherche de tout ce qui ressemble à une clé, et ils sont rapides. Des caches et des miroirs peuvent garder une copie après la réécriture de votre branche. Retirer le commit nettoie une seule copie, la vôtre, et la clé reste valide partout ailleurs. La seule action qui rend toutes les copies inutiles d'un coup, c'est la révocation de la clé.

L'ordre qui limite les dégâts

Ce sont des conseils généraux, pas une règle d'un fournisseur en particulier, mais l'ordre compte plus que la vitesse de chaque étape.

1. Révoquez ou remplacez la clé chez le fournisseur. Créez-en une nouvelle, mettez-la dans votre environnement déployé, supprimez l'ancienne. Tant que ce n'est pas fait, le reste est cosmétique.

2. Consultez le tableau de bord d'usage et de facturation du fournisseur à la recherche d'appels que vous ne reconnaissez pas, depuis le moment du push. S'il y en a, vous avez désormais un incident à signaler, pas seulement une erreur à ranger.

3. Sortez le secret du code. Dans Laravel, la clé a sa place dans .env, lue par un fichier de configuration, et le code la récupère avec config() :

// config/services.php
'anthropic' => ['key' => env('ANTHROPIC_API_KEY')],

// anywhere in the app
$key = config('services.anthropic.key');

N'appelez jamais env() hors d'un fichier de configuration. Après php artisan config:cache, que la plupart des déploiements exécutent, env() renvoie null en dehors de la configuration, et une clé lue directement dans un contrôleur finit souvent codée en dur « juste pour que ça marche ». Vérifiez que .env figure dans .gitignore, et gardez un .env.example avec de fausses valeurs pour que personne n'ait besoin du vrai fichier pour démarrer l'application.

4. Ensuite seulement, si vous le souhaitez, nettoyez l'historique avec git filter-repo ou BFG. C'est de l'hygiène, pas une correction : il faut un push forcé, tout le monde doit recloner, et cela ne change rien aux copies du premier schéma.

5. Empêchez la prochaine fuite. Activez le secret scanning et la push protection, ajoutez un scanner en pre-commit, et donnez à chaque environnement sa propre clé à portée limitée avec un plafond de dépenses, pour que la prochaine fuite reste petite. Puis notez ce qui s'est passé tant que vous vous en souvenez.

Ce que GitHub fait désormais pour vous

GitHub a annoncé le 2026-10-13 que le secret scanning détecte de nouveaux types de secrets de Salesforce, Anthropic et Cloudsmith, et que les deux nouveaux types Anthropic, anthropic_service_api_key et anthropic_user_api_key, sont bloqués par défaut par la push protection. Selon GitHub, dans les dépôts où le secret scanning est activé, y compris les dépôts publics gratuits, les commits contenant ces clés sont bloqués automatiquement. GitHub indique aussi que les secrets de partenaires trouvés dans des dépôts publics sont transmis à l'émetteur pour qu'il puisse les révoquer avant tout abus, et que les secrets d'utilisateurs déclenchent des alertes dans les dépôts publics et privés. C'est un filet de sécurité qui vaut la peine d'être activé, mais il ne couvre que les types que GitHub connaît : quand quelque chose passe à travers, l'ordre ci-dessus reste à votre charge. Si vous n'avez pas activé le secret scanning sur vos dépôts, faites-le aujourd'hui, puis ajoutez un scanner en pre-commit pour que la clé ne quitte jamais votre machine.

Source : GitHub Changelog, 2026-10-13.