Puis-je mettre ma clé d'API dans le code de mon site ?

Pourquoi une page ne peut pas garder un secret

Un navigateur doit recevoir tout ce qu'il exécute. Ce n'est pas une faiblesse d'un hébergeur ou d'un framework particulier, c'est ce que signifie servir une page : la machine du visiteur ne peut pas exécuter votre code sans qu'on lui donne votre code. Les outils de développement intégrés au navigateur suffisent donc à lire ce qui s'y trouve, sans compétence et sans rien installer. Minifier, encoder en base64 ou assembler la clé à partir de fragments concaténés survivent exactement le temps qu'il faut à quelqu'un pour regarder la valeur assemblée, que l'onglet réseau lui montre de toute façon, à l'intérieur de la requête sortante.

La distinction qui compte n'est donc pas caché contre visible. Elle sépare deux types d'identifiants, et le fournisseur les nomme pour vous. Une clé publiable ou cliente est conçue pour vivre dans une page : la clé publiable d'un prestataire de paiement, un identifiant de mesure analytique, une clé de cartographie restreinte à votre domaine. Elles sont publiques par conception et bornées du côté du fournisseur, et c'est pourquoi les placer dans le code front-end est correct et non risqué. Une clé secrète est tout autre chose : elle porte généralement l'autorité complète de votre compte, donc elle peut débiter des cartes, lire des fiches clients, envoyer des e-mails en votre nom ou consommer votre budget d'API. Confier cela à quiconque charge la page est la véritable erreur, et « personne ne connaît encore cette adresse » n'est pas une défense, car des scanners parcourent en continu les sites fraîchement publiés et les dépôts publics à la recherche précisément de cela.

Si elle est déjà en ligne, changez-la avant de ranger

Le réflexe est de supprimer la ligne et de republier. Faites d'abord l'autre chose. Dépublier ne rappelle pas ce qui a déjà été servi : l'ancienne version peut rester dans le cache périphérique d'un CDN, dans le cache d'un moteur de recherche, dans un service d'archivage ou dans le navigateur d'un visiteur, et si la page vit dans un dépôt la clé demeure dans l'historique des commits, où retirer la ligne dans un commit ultérieur laisse le précédent parfaitement lisible. La seule étape qui met réellement fin à l'exposition est d'invalider l'identifiant chez le fournisseur, parce que le fournisseur est le seul endroit où la clé doit être vérifiée.

Où va la clé à la place, et ce que nous avons trouvé sur des pages en ligne

Le schéma qui fonctionne est que la page ne détient jamais le secret. La page appelle quelque chose que vous contrôlez, cette chose détient la clé et effectue l'appel sortant, et le navigateur du visiteur ne parle qu'à vous. Souvent vous n'avez pas à l'exploiter vous-même : le widget hébergé d'un fournisseur ou un service de backend géré fait office de serveur pour cet usage. Savoir s'il vous en faut davantage est une autre question, et mon site a-t-il besoin d'un backend traite de l'endroit où passe réellement la limite.

Exploiter notre propre hébergement nous a appris sur ce point quelque chose de contre-intuitif. AgentCeres — l'AI Growth Officer sur agentceres.com — héberge les pages que ses agents construisent pour les clients, et chacune de ces pages est servie avec une politique de sécurité du contenu qui interdit à la page toute requête réseau. Une clé intégrée dans une telle page ne peut même pas être utilisée par elle : le code peut s'exécuter, calculer et naviguer, et il n'a nulle part où envoyer quoi que ce soit. Ce confinement protège le visiteur de la page, et il ne fait absolument rien pour cacher la clé au visiteur — c'est la moitié que les gens supposent obtenir gratuitement.

Le 2026-09-17, en parcourant les pages publiées par les clients, nous en avons trouvé une dont le JavaScript affectait à une variable la clé secrète active d'un prestataire de paiement, avec le numéro de pièce d'identité d'un client écrit en dur dans une fonction de consultation plus bas dans le même fichier. Les deux ont été confirmés en récupérant la page en ligne, non déduits. Rien d'exotique ne s'était produit : le propriétaire avait collé la clé dans une conversation en demandant une fonctionnalité qui en avait besoin, et elle a été écrite dans la page. La règle qui en découle vaut d'être retenue — ne collez jamais un secret actif dans une conversation avec quelque chose qui écrit votre page, assistant de code compris, car le geste naturel pour lui est d'utiliser la clé là où se trouve le code.

La même revue a trouvé la fuite en sens inverse, ce qu'il vaut la peine de savoir car presque personne ne la cherche. Les pages générées incluent des formulaires de connexion et d'inscription quand on demande un espace membres, même là où aucun serveur n'existe derrière pour authentifier qui que ce soit, et chaque formulaire d'une telle page se retrouve branché à un collecteur de formulaires — de sorte qu'un visiteur qui y tapait un mot de passe le voyait stocké et transmis en clair. Dans deux cas de septembre 2026, cela comprenait l'adresse e-mail et le mot de passe réels d'un tiers, arrivés dans la boîte du propriétaire avec l'apparence d'une demande ordinaire. Nous reconnaissons désormais les noms de champ qui ressemblent à des identifiants et nous en retirons les valeurs avant que quoi que ce soit ne soit stocké, envoyé ou affiché, et les pages nouvellement publiées rendent un tel champ non soumettable dès le départ. La leçon générale tient quel que soit l'auteur de la page : elle peut fuir dans les deux sens, vos clés vers l'extérieur et les mots de passe de vos visiteurs vers l'intérieur.