Clé API exposée : que faire, dans quel ordre, et comment éviter la prochaine fuite

Une clé API (le mot de passe qui permet à votre application de parler à Stripe, OpenAI, votre base de données ou votre service d'e-mails) s'est retrouvée dans le code, sur GitHub, dans une capture d'écran ou dans un message ? Votre clé API est exposée et vous vous demandez quoi faire : la réponse tient en une phrase. Révoquez-la et remplacez-la avant toute autre chose. Supprimer la ligne du code ne suffit pas, et ce n'est même pas la priorité.

C'est aussi ce que recommande GitHub dans sa documentation. Quand la donnée exposée est un mot de passe, un jeton ou un identifiant, la première étape consiste à le révoquer ou à le faire tourner, c'est-à-dire à le remplacer par un nouveau. Une fois révoquée, la clé ne donne plus aucun accès, et le reste devient du nettoyage (documentation GitHub).

Cet article s'adresse aux dirigeants qui font développer leur application avec Claude Code, Cursor ou Lovable, ou qui ont hérité d'un code qu'ils ne maîtrisent pas. Vous y trouverez l'ordre des opérations, ce qu'il faut vérifier ensuite et comment éviter que cela se reproduise.

Clé API exposée : que faire dans la première heure

L'ordre compte. Voici celui que j'applique quand on m'appelle pour ce type d'incident.

1. Identifiez la clé et le service concerné. Clé de paiement, clé d'API d'IA (OpenAI, Anthropic, Mistral…), mot de passe de base de données, clé d'accès à un hébergeur cloud : chaque service a sa console et sa procédure.
2. Générez une nouvelle clé dans la console du service, puis remplacez l'ancienne dans la configuration de votre application en production. Pas dans le code : dans les variables d'environnement du serveur ou de l'hébergeur.
3. Révoquez l'ancienne clé. C'est l'étape qui vous protège vraiment. Tant que l'ancienne clé fonctionne, quelqu'un peut s'en servir, même si elle n'apparaît plus nulle part.
4. Vérifiez que l'application fonctionne toujours : paiement, envoi d'e-mails, connexion. Une rotation mal faite peut casser un service. C'est pour cela qu'on crée la nouvelle clé avant de révoquer l'ancienne.
5. Si le dépôt de code est public, passez-le en privé le temps de faire le ménage.

Si vous ne savez pas où la clé est utilisée dans l'application, c'est le moment de demander de l'aide plutôt que de couper à l'aveugle. Mais ne remettez pas la révocation au lendemain : une clé qui a fuité ne redevient pas secrète avec le temps. GitGuardian, qui analyse chaque année les secrets publiés sur GitHub, indique que plus de 64 % des identifiants trouvés valides en 2022 l'étaient encore lors d'un nouveau test en janvier 2026 (GitGuardian, State of Secrets Sprawl 2026). Autrement dit, beaucoup d'entreprises ne révoquent jamais leurs clés exposées.

Pourquoi les applications codées avec l'IA sont plus exposées

Les fuites de clés existaient bien avant le code généré par IA. Mais plusieurs habitudes du vibe coding, qui consiste à développer en décrivant ce qu'on veut à un assistant IA sans relire le code en détail, augmentent le risque.

• L'assistant met la clé là où ça marche tout de suite. Si vous collez une clé dans la conversation pour « faire fonctionner le paiement », l'outil peut l'écrire en dur dans un fichier de code au lieu de la placer dans un fichier de configuration exclu du dépôt.
• Les agents lisent tout le projet. La société de sécurité Knostic a documenté que Claude Code lit automatiquement les fichiers .env, ceux qui contiennent justement les secrets, quand ils se trouvent dans le dossier du projet (Knostic). Ce n'est pas une fuite en soi, mais ces secrets peuvent ensuite se retrouver dans un fichier de test, un script ou un journal généré par l'agent.
• Personne ne relit avant l'envoi sur GitHub. Quand on enchaîne les commits (les enregistrements successifs du code) à grande vitesse, un fichier qui n'aurait jamais dû partir finit par partir.

Les chiffres vont dans ce sens. Dans son rapport 2026, GitGuardian a recensé 28,65 millions de nouveaux secrets exposés sur GitHub public en 2025, soit 34 % de plus qu'en 2024, et une hausse de 81 % des fuites de clés de services d'IA. Le même rapport observe que 3,2 % des commits réalisés avec l'aide de Claude Code contenaient un secret, contre 1,5 % pour l'ensemble des commits publics (GitGuardian). Le danger ne vient pas de l'outil lui-même, mais de la vitesse sans garde-fou.

Supprimer la clé du code ne suffit pas : l'historique Git

C'est le point que la plupart des dirigeants découvrent trop tard. Git, l'outil qui gère les versions du code, garde toutes les versions précédentes de chaque fichier. Si la clé a été enregistrée une fois puis supprimée dans un commit suivant, elle reste lisible dans l'historique par toute personne qui a accès au dépôt.

On peut réécrire cet historique pour effacer la clé, mais la documentation GitHub est claire sur les limites :

• les copies déjà téléchargées par d'autres personnes (les clones) ne sont pas nettoyées ;
• si le dépôt a été dupliqué (fork), la clé reste visible dans la copie ;
• certaines vues en cache sur GitHub et les demandes de modification (pull requests) qui font référence à l'ancien commit peuvent encore l'afficher ;
• un collaborateur qui renvoie son ancienne copie peut réintroduire la clé.

C'est exactement pour cela que la révocation passe en premier : une clé révoquée peut traîner dans un historique, elle ne sert plus à rien. Le nettoyage de l'historique reste utile, surtout pour un dépôt public. C'est une opération délicate, à confier à quelqu'un qui sait la faire sans casser le travail en cours.

Vérifier que la clé n'a pas été utilisée

Une fois la clé révoquée, il faut savoir si quelqu'un s'en est servi entre la fuite et la révocation. Concrètement :

• Regardez la facturation du service. Pour une clé d'API d'IA, une consommation anormale est souvent le premier signe. Chez un hébergeur cloud, cherchez des machines ou des services que vous n'avez pas créés.
• Consultez les journaux d'activité que proposent la plupart des consoles : date, adresse IP, actions réalisées avec la clé.
• Si la clé donnait accès à la base de données, vérifiez les connexions et les exports récents. Si des données personnelles ont pu être consultées et que l'incident présente un risque pour la vie privée des personnes concernées, vous devez le notifier à la CNIL, si possible dans les 72 heures. Dans tous les cas, l'incident doit être documenté en interne (CNIL).
• Notez ce que vous avez fait et quand. Si l'affaire a des suites, cette chronologie vous servira.

Si rien d'anormal n'apparaît, tant mieux. Mais l'absence de trace ne prouve pas que la clé n'a pas servi, d'où l'importance de toujours révoquer vite.

Empêcher qu'une clé API soit à nouveau exposée

Une fois l'incident réglé, le vrai travail consiste à rendre la prochaine fuite difficile. Rien de tout cela n'est réservé aux grandes entreprises.

Ranger les secrets au bon endroit

Les clés doivent vivre dans les variables d'environnement du serveur ou dans le gestionnaire de secrets de votre hébergeur, jamais dans le code. Le fichier .env local doit être exclu du dépôt (via le fichier .gitignore). Pour les agents de code, Knostic recommande de sortir les fichiers .env du dossier de travail ou d'en bloquer la lecture dans la configuration de l'outil.

Bloquer la fuite avant qu'elle parte

GitHub propose la « push protection », qui refuse l'envoi d'un commit contenant un secret reconnu. Elle est gratuite sur les dépôts publics (GitHub) ; pour les dépôts privés, tout dépend de votre offre GitHub. Des outils open source comme Gitleaks ou TruffleHog font la même détection. Ils peuvent tourner automatiquement à chaque modification du code, dans la chaîne d'intégration continue (CI : les vérifications automatiques lancées avant chaque mise en production).

Limiter les dégâts d'une fuite future

• Une clé par usage et par environnement (test et production séparés), avec le minimum de droits nécessaires.
• Des plafonds de dépense sur les API payantes, quand le service le permet.
• Une liste à jour de toutes les clés utilisées par l'application, avec les personnes qui y ont accès.

C'est précisément le socle que nous mettons en place avec Autopilote : intégration continue avec contrôles automatiques, dont la détection de secrets, monitoring et contrôle qualité du code par des agents IA. Ces vérifications ne reposent plus sur votre mémoire. Si votre application a été construite rapidement avec un outil de vibe coding, l'article Mettre en production une application vibe coding : ce qu'il faut vérifier avant complète cette liste.

Questions fréquentes

Mon dépôt est privé, suis-je tranquille ?

Moins que vous ne le pensez. Toute personne qui a eu accès au dépôt (ancien prestataire, freelance, outil tiers connecté) a pu voir la clé. GitGuardian note d'ailleurs que les dépôts internes contiennent bien plus souvent des secrets en clair que les dépôts publics. Si la clé est sortie de votre contrôle, révoquez-la.

J'ai supprimé la clé du code, faut-il quand même la changer ?

Oui. Elle reste dans l'historique Git et peut-être dans des copies que vous ne contrôlez pas.

Le prestataire qui a développé l'application est parti avec les accès. Que faire ?

Changez toutes les clés et tous les mots de passe qu'il connaissait, en commençant par les comptes principaux : hébergeur, nom de domaine, GitHub. L'article Reprise d'une application Laravel : par où commencer quand le prestataire est parti détaille la démarche.

Si vous avez un doute sur une clé, ou si vous ne savez pas lesquelles votre application utilise, on peut regarder ça ensemble. Souvent, un court échange suffit pour savoir s'il y a urgence.