# Ton IA vient d'écrire une clé API directement dans le code. Tes visiteurs peuvent-ils la voir ?

Mik Bry · 2026-08-25 · lecture ~8 min · KB · Prêt à lancer

![Une seule clé ouvragée flotte dans les airs, sa tige se terminant en traces de circuit imprimé lumineuses au lieu de dents métalliques.](/assets/2026-08-25-kb-secrets-and-api-keys-hero.png)
Ton outil d'IA devait parler à Stripe, à OpenAI, ou à un autre service, donc il t'a demandé de coller une clé API — puis il l'a intégrée au code. Logique. Ce qui n'est pas évident, si tu ne codes pas, c'est que « intégrée au code » veut parfois dire « intégrée au code téléchargé par le navigateur de tes visiteurs ». Pas volée. Pas piratée. Juste posée en clair, à portée d'un clic droit. C'est le test que je refais systématiquement sur une app construite par IA : rapide, sans code, et « je n'ai touché à rien » n'est justement pas la garantie qu'on croit.
Ce que couvre cet article
1. [C'est quoi, concrètement ?](#s1) 2. [Pourquoi s'en soucier si tu ne codes pas ?](#s2) 3. [À quoi ressemble un projet bien structuré ?](#s3) 4. [Que peux-tu demander sans risque à ton agent IA ?](#s4)

01 — C'est quoi, concrètement ?

Une clé API est un mot de passe, sauf qu'elle n'est pas pour toi — elle sert à un logiciel qui parle à un autre logiciel. Quand ton app doit débiter une carte via Stripe, ou appeler OpenAI pour générer du texte, elle doit prouver qu'elle a le droit de faire cette requête. La clé API, c'est cette preuve : une longue chaîne envoyée avec chaque requête, un peu comme toi quand tu tapes un mot de passe pour prouver que c'est bien toi. Une poignée de main entre deux systèmes, pas entre une personne et un système. Cette image — mot de passe pour machines — couvre l'essentiel, mais le *type* de clé compte aussi. Une **clé de maison** est le cas le plus simple : qui la détient entre, un point c'est tout. Certaines clés API fonctionnent comme ça. D'autres se comportent plutôt comme une **carte de bibliothèque** : elle te fait entrer dans le bâtiment et emprunter des livres, mais ne t'ouvre ni le bureau du directeur ni la caisse — l'accès est limité. Une bonne gestion des clés privilégie les accès limités dès que c'est possible ; les outils d'IA ne choisissent pas toujours l'option la plus restreinte par défaut, et un fondateur qui relit le résultat n'a généralement aucun moyen de savoir laquelle des deux il a obtenue. Voici ce qui différencie ce cas du conseil classique « ne commite pas ton fichier `.env` ». Un cas particulièrement facile à créer dans un frontend construit avec l'IA, c'est une clé écrite directement dans le code que le navigateur exécute — plutôt que dans un fichier poussé par erreur sur GitHub. Next.js et Vite ont une convention précise : toute variable préfixée `NEXT_PUBLIC_` ou `VITE_` est intégrée au JavaScript public du site — un [comportement documenté et volontaire](https://nextjs.org/docs/app/building-your-application/configuring/environment-variables), pas un bug, prévu pour les valeurs qui doivent réellement atteindre le navigateur. Le problème, c'est un agent IA qui utilise ce préfixe par réflexe, pour une valeur censée rester côté serveur, parce que c'est le moyen le plus rapide de faire disparaître une erreur.

02 — Pourquoi s'en soucier si tu ne codes pas ?

Parce que la conséquence n'a rien d'abstrait — c'est une facture, ou ce sont les données de tes utilisateurs. Si ta clé OpenAI est posée dans ton JavaScript public, n'importe qui peut ouvrir les outils de développement, la copier, et faire des appels sur ton compte — tu l'apprends en recevant la facture, pas avant. Si c'est une clé Stripe trop permissive, quelqu'un peut lire des données de paiement qui appartiennent à tes utilisateurs, pas à toi. Ce n'est pas un cas limite réservé aux grandes entreprises. C'est aussi l'un des problèmes les plus faciles à montrer concrètement, parce qu'une valeur exposée peut parfois être visible directement dans le navigateur. Un point de précision à ne pas rater, parce que l'intuition trompe ici : **une clé API ne se comporte pas comme un mot de passe interactif.** Tu remarquerais si quelqu'un se connectait à ta messagerie — session, appareil, parfois un e-mail « nouvelle connexion ». L'utilisation d'une clé API ne produit généralement pas les mêmes signaux visibles qu'une connexion classique. Contrairement à un mot de passe interactif, elle peut rester utilisable jusqu'à son expiration *ou* jusqu'à ce que quelqu'un la révoque ou la fasse tourner — une clé qui a fuité peut donc continuer à fonctionner discrètement, pendant des semaines, sans rien qui ressemble à une « connexion ». Personne n'a besoin de pirater quoi que ce soit. La clé était déjà là, elle fonctionnait exactement comme prévu, pour quiconque la trouve. Ce schéma est facile à créer quand un agent optimise pour une démo qui marche. D'où l'intérêt de vérifier explicitement, plutôt que de supposer qu'une intégration qui fonctionne a forcément gardé chaque identifiant au bon endroit.

03 — À quoi ressemble un projet bien structuré ?

Pas besoin de savoir lire du code pour vérifier l'essentiel. Cherche : - **Les identifiants sensibles restent sur ton serveur, jamais dans le code envoyé à l'utilisateur.** Si ton app doit appeler une API payante ou privée (paiements, LLMs, email, stockage), la clé doit vivre sur ton serveur. Ton app appelle ton serveur ; ton serveur appelle l'API payante et te renvoie uniquement le résultat. Ça vaut pour le code du navigateur, les bundles d'apps mobiles et les apps desktop — tout ce qui tourne sur la machine de quelqu'un d'autre peut être extrait, quel que soit le framework ou le nom des fichiers. Les préfixes `NEXT_PUBLIC_` / `VITE_` sont un exemple courant, pas la seule façon dont cette règle peut être cassée. - **Chaque clé n'ouvre que ce qu'elle doit ouvrir** — une carte de bibliothèque plutôt qu'une clé passe-partout. - **Il existe un plan pour révoquer ou faire tourner une clé**, pas seulement pour en émettre une — une clé peut continuer à fonctionner bien après qu'elle aurait dû s'arrêter. Et voici le premier test sans code, celui que tu peux faire toi-même en moins d'une minute : ouvre ton site en ligne, fais un clic droit, choisis « Afficher le code source de la page » (ou F12 pour ouvrir les outils de développement), et cherche — Ctrl+F ou Cmd+F — `key`, `sk-`, et `token`. Si l'une de ces recherches fait remonter une longue chaîne qui ressemble à un vrai identifiant en clair, ça mérite d'être vérifié immédiatement. Je veux être précis sur ce que ce test révèle vraiment, parce qu'il est facile de le surinterpréter : **c'est un premier test, pas la preuve que rien n'est exposé.** Un résultat propre veut dire que la version évidente du problème n'apparaît pas sur la page cherchée — pas qu'aucun secret nulle part dans ton app n'est exposé. Des clés peuvent être intégrées dans des fichiers JavaScript chargés depuis d'autres pages, d'autres bundles, ou derrière une connexion non vérifiée. Prends une recherche F12 propre comme « rien n'a sauté aux yeux », pas comme un certificat.

Références : l'article de Fencer « How to Secure Your Vibe Coded App » (fencer.dev) détaille ce test pour les apps construites par IA. Côté framework, voir la doc officielle Next.js et le guide env & mode de Vite. Pour la discipline générale : le Secrets Management Cheat Sheet d'OWASP et la doc de la push protection GitHub.

04 — Que peux-tu demander sans risque à ton agent IA ?

Tu n'as pas besoin de faire cette recherche toi-même — demande à ton outil d'IA, avec une formulation qui garde la même honnêteté « pas trouvé ≠ n'existe pas » que le test F12. Copie-colle ce prompt tel quel :
Le prompt à coller dans ton outil d'IA
> Cherche dans ce projet des secrets ou clés API codés en dur — y compris ceux intégrés au navigateur/frontend (par exemple des variables `NEXT_PUBLIC_`/`VITE_`). Montre-moi où se trouve chacun et s'il est envoyé aux utilisateurs. Si ta recherche ne trouve rien, dis que la recherche n'a rien trouvé — ne conclus pas que l'app est propre. Ne change rien.
Lis ce qu'il trouve avant d'agir. S'il liste des secrets envoyés au navigateur, c'est ta liste de priorités — mais cet article s'arrête volontairement à « voici ce que j'ai trouvé », pas à « voici comment le corriger ». Déplacer une clé côté serveur, en émettre une nouvelle et révoquer celle qui a été exposée, c'est un vrai travail technique — à confier à la personne techniquement responsable du projet, pas un prompt de suivi que tu colles seul. Le [guide d'Anthropic sur les clés API](https://support.anthropic.com/fr/articles/9767949-api-key-best-practices-keeping-your-keys-safe-and-secure) est une bonne base si la clé sert un fournisseur d'IA. Cet article fait partie de la série Launch Readiness KB : un concept à la fois pour comprendre ce que le Trust Report vérifie avant de lancer ton app, d'embaucher ou de lever des fonds. Chaque article se termine par quelque chose que tu peux demander à ton agent sans modifier le code.