Corriger l’erreur « API Key Not Found in Cookies »

TL;DR

• API key not found in cookies ne signifie presque jamais que votre clé est incorrecte. Cela signifie que l’application web qui a stocké votre clé dans un cookie ne peut pas relire ce cookie.
• Le coupable habituel : les cookies tiers sont bloqués. Safari, Brave, Firefox et chaque fenêtre de navigation privée les bloquent par défaut — le cookie contenant votre clé n’est donc tout simplement jamais conservé.
• Solution rapide : autorisez les cookies pour le domaine exact de l’application, déconnectez-vous puis reconnectez-vous, puis collez à nouveau votre clé. Navigateur différent ou navigation privée ? C’est pour cela qu’elle a « disparu ».
• Solution permanente (pour les développeurs) : cessez de faire confiance au gestionnaire de cookies. Envoyez votre clé dans un en-tête Authorization: Bearer vers un endpoint stable. Pas de cookie, pas de problème de cookie.

Si vous êtes arrivé ici parce qu’un guide vous a dit qu’il s’agissait d’une erreur « Cursor » ou « Windsurf » — ce n’est pas le cas. Ce message vient d’applications web qui conservent votre clé API côté client, et la solution n’a rien à voir avec votre IDE.

Que signifie réellement « API key not found in cookies » ?

Cela signifie que l’application s’attendait à trouver votre clé API dans un cookie du navigateur, a vérifié, et que le cookie n’était pas là. Votre clé est probablement correcte. C’est le stockage qui la contenait qui a échoué.

Voici le mécanisme. Certaines applications web — interfaces de chat IA, tableaux de bord de reverse proxy, quelques consoles SaaS — ne veulent pas conserver votre clé sur leur serveur. Donc, lorsque vous la collez, elles l’enregistrent dans un [cookie](https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/Cookies) (ou une session adossée à un cookie) dans votre propre navigateur. Chaque requête relit ensuite la clé depuis ce cookie. Lorsque le cookie est manquant, bloqué, expiré ou limité à un domaine sur lequel vous ne vous trouvez pas actuellement, la lecture ne renvoie rien. Vous obtenez API key not found in cookies.

Il s’agit donc d’une erreur d’état d’authentification côté client, pas d’une erreur « identifiants invalides ». Personne n’a rejeté votre clé. L’application n’a simplement pas pu la trouver pour l’envoyer.

Quelles applications affichent cette erreur — et pourquoi ce n’est pas votre clé API

Toute application web qui stocke votre clé API dans un cookie peut l’afficher. C’est la réponse honnête, et cela vaut la peine de le préciser, car le guide le mieux classé pour cette requête attribue à tort l’erreur à des outils IDE comme Cursor, Windsurf et Cline — avec des numéros de version précis qui ne correspondent à aucune erreur réelle fondée sur les cookies. Ces outils stockent les clés dans des fichiers de configuration locaux, pas dans des cookies de navigateur.

Là où vous voyez réellement API key not found in cookies :

Le point commun : votre clé n’a jamais atteint un compte côté serveur. Elle se trouve dans votre navigateur, et votre navigateur en a perdu la trace. Cela recadre toutes les solutions ci-dessous — vous ne réparez pas une clé, vous réparez le stockage des cookies.

Pourquoi le cookie de clé API disparaît-il sans cesse ?

Parce que les navigateurs modernes bloquent les cookies tiers par défaut, et que le cookie contenant votre clé est souvent traité comme tel. C’est la cause racine que la plupart des guides « videz votre cache » ignorent.

Regardez les paramètres par défaut. Ils ont changé sans que beaucoup ne s’en rendent compte :

Ainsi, la même clé qui « fonctionne sur mon ordinateur portable » échoue dans une fenêtre privée, sur un navigateur professionnel verrouillé, ou après une mise à jour du navigateur qui a modifié un paramètre de confidentialité par défaut. La poignée de main semble se terminer — l’application ne peut simplement pas écrire ou lire le cookie ensuite.

Quelques autres raisons pour lesquelles le cookie disparaît :

• Vous avez supprimé les cookies (ou utilisé « effacer les données de navigation ») — le cookie de clé est parti avec tout le reste.
• Navigateur ou appareil différent — les cookies ne se synchronisent pas entre eux, donc la clé n’y est pas.
• Mauvais domaine ou sous-domaine — un cookie défini sur app.example.com n’est pas visible sur example.com, et inversement.
• Décalage de l’horloge système — les cookies comportent un horodatage d’expiration. Si votre horloge est décalée de quelques minutes, le navigateur peut considérer un cookie tout neuf comme déjà expiré.
• Proxy d’entreprise ou VPN avec inspection SSL — certains réécrivent ou suppriment les en-têtes Set-Cookie, donc le cookie n’arrive jamais.

Comment corriger « API key not found in cookies » maintenant ?

Suivez cette liste — les deux premières étapes résolvent la plupart des cas en moins d’une minute :

1. Autorisez les cookies pour le domaine exact de l’application. Dans Chrome/Edge : Paramètres → Confidentialité et sécurité → Cookies tiers → ajoutez l’URL de l’application sous « Autorisé à utiliser les cookies tiers ». Dans Safari : Réglages → Confidentialité → décochez « Empêcher le suivi intersite » (ou ajoutez une exception de site). Dans Firefox : icône de bouclier dans la barre d’adresse → désactivez la protection renforcée contre le pistage pour ce site.
2. Déconnectez-vous, reconnectez-vous, puis collez à nouveau votre clé. Cela force l’application à créer une nouvelle session et à écrire un cookie propre. C’est l’équivalent, pour l’état d’authentification, de l’éteindre puis de le rallumer.
3. Quittez le mode Incognito/Privé. Ces modes bloquent les cookies tiers par conception, et rien n’est conservé après la fermeture de la fenêtre. Utilisez une fenêtre normale et saisissez de nouveau la clé.
4. Désactivez les bloqueurs de publicité / extensions de confidentialité pour ce site. uBlock Origin, AdGuard et les modules de confidentialité peuvent bloquer le sous-domaine par lequel transite le cookie. Ajoutez l’application à la liste blanche, rechargez, saisissez à nouveau la clé.
5. Vérifiez votre horloge système. Activez la date/l’heure automatiques afin que NTP vous garde synchronisé. Une horloge décalée fait expirer silencieusement de bons cookies.
6. Confirmez que vous êtes sur l’URL exacte où la clé a été enregistrée. Si vous avez enregistré la clé sur app.tool.com, un cookie n’apparaîtra pas sur tool.com. Faites correspondre le sous-domaine.
7. Régénérez la clé dans le tableau de bord du fournisseur. Si un coéquipier l’a fait tourner ou supprimée, le cookie pointe désormais vers une clé morte. Créez-en une nouvelle, collez-la, terminé.

Si vous êtes sur un réseau d’entreprise et que rien ne persiste, testez pendant deux minutes avec le partage de connexion d’un téléphone. Si cela fonctionne, un proxy avec inspection SSL mange vos cookies — demandez à l’IT de contourner le domaine de l’application.

Comment arrêter définitivement cette erreur ?

Arrêtez de dépendre d’un cookie de navigateur pour transporter votre clé. Si vous contrôlez le code, envoyez plutôt la clé dans un en-tête de requête — les cookies sont optionnels, les en-têtes ne le sont pas.

Les clés stockées dans des cookies sont fragiles par conception : elles vivent dans un seul profil de navigateur, héritent des règles de confidentialité de ce navigateur et disparaissent lors d’un effacement du cache. L’authentification par en-tête évite tout cela. La clé voyage dans la requête :

curl https://api.velokey.ai/v1/chat/completions \
  -H "Authorization: Bearer $YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gpt-5.6",
    "messages": [{"role": "user", "content": "Hello"}]
  }'

Pas de gestionnaire de cookies, pas de politique de cookies tiers, pas de surprise en navigation privée. Le même appel s’exécute depuis un script, un serveur, une tâche CI ou un backend auquel votre frontend parle — aucun d’eux n’a le problème des cookies au départ. Si vous développez une application web, le modèle durable consiste à garder la clé sur votre propre backend et à faire appeler *votre* serveur par le navigateur, plutôt que de coller une clé brute de fournisseur dans un cookie côté client.

C’est aussi pourquoi les passerelles API ne rencontrent pas cette erreur. Une passerelle comme [Velokey](https://api.velokey.ai) vous donne une clé unique qui atteint de nombreux modèles — [GPT-5.6](/model/gpt-5.6), [Claude Opus 4.8](/model/claude-opus-4-8), [Claude Sonnet 5](/model/claude-sonnet-5) — via un endpoint unique compatible OpenAI, et cette clé circule dans l’en-tête Authorization à chaque fois. Il n’y a pas de cookie à perdre. Si vous colliez une clé fournisseur dans une interface de chat juste pour essayer un modèle, appeler directement un endpoint stable est à la fois plus simple et plus difficile à casser. Pour l’aspect tarifaire, consultez notre guide des tarifs de l’API Claude ; pour un guide complet, comment appeler une API avec une clé couvre la configuration de bout en bout.

Référence de correction rapide

Questions fréquentes

« API key not found in cookies » est-il spécifique à une seule application ?

Non. C’est un message générique provenant de toute application web qui stocke votre clé API dans un cookie — les interfaces de chat IA, tableaux de bord de reverse proxy et certains playgrounds web utilisent tous ce modèle. Les guides qui l’attribuent à un seul IDE devinent. La solution est la même dans tous les cas : réparer ou remplacer le cookie contenant votre clé.

La suppression des cookies supprimera-t-elle définitivement ma clé API ?

Non. Votre clé se trouve dans le tableau de bord du fournisseur, pas dans le cookie. Supprimer les cookies ne retire que la copie locale que l’application lisait. Vous serez déconnecté et invité à coller de nouveau la clé, mais la clé elle-même reste intacte. Copiez-la depuis le fournisseur avant de supprimer les cookies, afin de pouvoir la ressaisir.

Le mode Incognito ou privé peut-il provoquer cette erreur ?

Oui, de manière fiable. Les fenêtres Incognito, Private et InPrivate bloquent les cookies tiers par défaut et effacent tout lorsque vous les fermez. Si vous avez enregistré la clé dans une fenêtre privée, elle a déjà disparu. Passez à une fenêtre normale, saisissez de nouveau la clé, et elle persistera entre les sessions.

Un VPN ou un proxy d’entreprise peut-il la déclencher ?

Oui. Un proxy d’entreprise avec inspection SSL ou certains VPN réécrivent ou suppriment l’en-tête Set-Cookie, de sorte que le cookie de clé n’arrive jamais dans votre navigateur. Test rapide : passez sur le partage de connexion d’un téléphone pendant une minute. Si l’erreur disparaît, le réseau est la cause — demandez à l’IT d’ajouter le domaine de l’application à la liste de contournement de l’inspection.

Cette erreur affecte-t-elle les appels API côté serveur ?

Non. Les appels serveur à serveur envoient la clé dans un en-tête Authorization, et aucun cookie de navigateur n’est impliqué, donc cette erreur ne peut pas se produire là. Elle n’apparaît que dans les applications web qui ont choisi de stocker votre clé côté client. Déplacer l’authentification dans un en-tête de requête est précisément la raison pour laquelle les backends et les scripts ne la voient jamais.

Pourquoi les passerelles API ou agrégateurs n’ont-ils pas ce problème ?

Parce qu’ils s’authentifient avec un en-tête, pas avec un cookie. Vous envoyez Authorization: Bearer <key> à chaque requête vers un endpoint stable, donc il n’y a pas de cookie de navigateur à bloquer, expirer ou supprimer. C’est la raison structurelle pour laquelle un appel via passerelle continue de fonctionner entre navigateurs, fenêtres privées et réseaux verrouillés là où une interface basée sur les cookies échoue silencieusement.