C'est quoi la différence entre un token et une clé API ?

Publié le 12 juin 2026

Si vous avez déjà connecté un outil externe à un service web, intégré une API dans un projet, ou tout simplement configuré une application no-code, vous avez probablement croisé ces deux termes. Une clé API par ici, un token par là, parfois un "Bearer token" dans une documentation, ou un "access token" dans un tableau de bord. On les utilise souvent de façon interchangeable dans le langage courant, mais ils ne désignent pas exactement la même chose. Voici comment les distinguer, à quoi ils servent concrètement, et pourquoi cette différence compte.

L'analogie pour commencer : la carte magnétique vs le badge visiteur

Imaginez un immeuble de bureaux. Les employés ont une carte magnétique personnelle : elle leur appartient, elle est liée à leur identité, elle ouvre toujours les mêmes portes, et si on leur vole, l'entreprise peut la désactiver depuis le système central.

Les visiteurs, eux, reçoivent un badge à l'accueil. Ce badge est temporaire, souvent limité à certaines zones, et valable uniquement pour la journée. Le lendemain, il ne fonctionne plus.

Dans cette analogie, la clé API c'est la carte magnétique de l'employé. Le token, c'est le badge visiteur. Les deux permettent d'entrer. Mais pas de la même façon, pas avec les mêmes droits, et pas pour la même durée.

La clé API : une identité stable pour une application

Une clé API est une chaîne de caractères longue et aléatoire, générée par un service, qu'on intègre dans ses requêtes pour se faire reconnaître. Elle répond à une question simple : qui appelle ce service ?

Quand vous créez un compte développeur sur OpenAI, Stripe, Google Maps ou n'importe quel autre service exposant une API, on vous attribue une clé. Cette clé est associée à votre compte. Elle ne change pas dans le temps (sauf si vous la régénérez manuellement ou si elle est compromise). Et elle fonctionne à chaque requête, sans étape d'authentification préalable.

            // Exemple d'appel API avec une clé dans l'en-tête

            fetch('https://api.example.com/data', {

              headers: {

                'Authorization':
            'Bearer sk-votre-cle-api-ici',

                'Content-Type':
            'application/json'

              }

            });

            // La clé identifie votre compte à chaque appel.

            // Pas de login, pas d'étape intermédiaire.

Ce qui caractérise une clé API, c'est sa permanence et son rattachement à une entité précise — le plus souvent une application ou un compte développeur, pas un utilisateur final. C'est vous (ou votre appli) qui avez cette clé. Elle ne représente pas une session en cours, elle représente votre identité vis-à-vis du service.

Le token : un accès délégué et temporaire

Un token, c'est différent dans sa logique. Il n'identifie pas une application de façon permanente. Il représente une autorisation accordée à un moment donné, généralement après qu'un utilisateur s'est authentifié. Il est temporaire par conception.

L'exemple le plus courant, c'est le token de session. Quand vous vous connectez à un site, le serveur génère un token et vous le transmet. Votre navigateur le stocke et l'envoie à chaque requête suivante pour prouver que vous êtes bien connecté. Quand vous vous déconnectez, le token est invalidé. Quand sa durée de vie expire, même chose.

Il y a aussi les tokens OAuth, qu'on utilise dans les scénarios du type "Se connecter avec Google". Vous autorisez une application tierce à accéder à certaines données de votre compte Google. Google lui délivre alors un token, qui représente cette autorisation précise — pas plus. L'application peut accéder à ce que vous avez accepté de partager, pour une durée limitée, sans jamais connaître votre mot de passe.

⚠ Un token n'est pas un mot de passe. C'est une preuve qu'une autorisation a été accordée à un instant donné. Si ce token expire ou est révoqué, l'accès s'arrête, même si l'utilisateur n'a pas changé son mot de passe.

Le JWT : un token qui porte ses propres informations

Parmi les types de tokens, le JWT (JSON Web Token, prononcé "jot") mérite une mention particulière car il est aujourd'hui omniprésent. Sa particularité : il ne contient pas juste un identifiant opaque que le serveur doit aller vérifier dans une base de données. Il embarque directement des informations — l'identité de l'utilisateur, son rôle, la date d'expiration — encodées et signées numériquement.

Concrètement, un JWT ressemble à ça :

            // Structure d'un JWT (3 parties séparées par des points)

            eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9 ← en-tête (algorithme)

            .eyJ1c2VySWQiOiI0MiIsInJvbGUiOiJhZG1pbiIsImV4cCI6MTcxODIwMDAwMH0
            ← payload (données)

            .SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c ← signature

            // Une fois décodé, le payload révèle par exemple :

            {

              "userId":
            "42",

              "role":
            "admin",

              "exp": 1718200000
            ← date d'expiration

            }

Le serveur n'a pas besoin de consulter une base de données pour valider ce token : il vérifie simplement la signature, et il sait si le token est authentique et encore valide. C'est pour ça que les JWT sont très utilisés dans les architectures modernes et les applications qui passent à l'échelle.

Ce qui les distingue vraiment

	Clé API	Token
Durée de vie	Permanente (jusqu'à révocation manuelle)	Limitée dans le temps
Ce qu'elle représente	Une application ou un compte	Une session ou une autorisation
Contexte typique	Appels serveur à serveur, intégrations	Connexion utilisateur, accès délégué
Contient des infos ?	Non (identifiant opaque)	Parfois (ex. JWT)
Révocation	Manuelle, dans le tableau de bord	Automatique à l'expiration ou à la déconnexion

Pourquoi on confond les deux ?

Parce que, dans les deux cas, on envoie une chaîne de caractères dans un en-tête HTTP pour prouver qu'on a le droit de faire une requête. La mécanique de transport est identique. Et dans beaucoup de documentations, les deux sont appelés "token" de façon générique.

La distinction n'est pas dans la forme, elle est dans la sémantique : ce que représente cette chaîne de caractères, comment elle a été générée, combien de temps elle est valide, et ce qu'elle autorise exactement.

Dans certains services, une clé API est techniquement un token — un token d'accès à longue durée de vie. Supabase, par exemple, appelle sa clé publique "anon key", mais c'est en réalité un JWT signé. Certains services comme GitHub ou GitLab appellent explicitement leurs clés "Personal Access Tokens". Ce flou terminologique est répandu, et c'est normal.

✓ La vraie question à se poser. Plutôt que de chercher une définition universelle, posez-vous : est-ce que cet identifiant représente une application (→ clé API) ou une session utilisateur avec une date de fin (→ token) ? C'est cette distinction qui change les pratiques de sécurité associées.

Conséquences concrètes sur la sécurité

Cette distinction n'est pas que théorique. Elle a des implications directes sur la façon dont on protège ces identifiants.

Une clé API compromise, c'est durable

Si votre clé API fuite — dans un dépôt Git public, dans des logs, dans un message — l'accès est compromis indéfiniment jusqu'à ce que vous la régénériez manuellement. Les frais peuvent s'accumuler pendant des heures ou des jours. C'est pourquoi on ne met jamais une clé API directement dans du code frontend ou dans un fichier versionné.

            // ❌ À ne jamais faire : clé API en dur dans le code frontend

            const apiKey =
            "sk-abc123...";

            // ✓ Bonne pratique : variable d'environnement côté serveur

            const apiKey = process.env.API_KEY;

            // La clé ne doit jamais être visible dans le navigateur.

Un token qui expire, c'est une limite intégrée

Si un token de session est intercepté, l'attaquant a un accès limité dans le temps. Quand le token expire — parfois en quelques minutes, parfois en quelques heures selon la configuration — l'accès s'arrête automatiquement. C'est l'un des avantages de la courte durée de vie : le rayon d'impact d'une compromission est réduit mécaniquement.

C'est pour ça que les tokens d'accès OAuth ont souvent une durée de vie courte (1 heure par exemple), accompagnés d'un "refresh token" à plus longue durée de vie qui sert uniquement à en générer un nouveau sans redemander le mot de passe à l'utilisateur.

Les cas d'usage en résumé

Pour fixer les idées, voici dans quels contextes on utilise généralement l'un ou l'autre.

Clé API : quand c'est votre application qui parle à un service

Votre backend qui appelle l'API d'OpenAI pour générer du texte. Votre script qui envoie des emails via l'API Brevo. Votre intégration Zapier qui récupère des données depuis Airtable. Dans tous ces cas, c'est votre application qui s'identifie auprès d'un service tiers. Une clé API est adaptée.

Token : quand un utilisateur se connecte à votre application

Un utilisateur entre ses identifiants sur votre site. Votre serveur vérifie, génère un token de session ou un JWT, et le renvoie au navigateur. Ce token représente la session de cet utilisateur précis. Il expire quand il se déconnecte ou après un délai d'inactivité.

Token OAuth : quand une application agit au nom d'un utilisateur

Vous utilisez "Se connecter avec Google" sur un site tiers. Ce site reçoit un token OAuth qui lui permet d'accéder à votre profil Google (ou votre agenda, ou votre Drive, selon ce que vous avez autorisé). Ce token représente votre délégation d'accès — pas votre identité permanente.

⚠ Ne jamais mettre un token ou une clé API dans une URL. Les URLs apparaissent dans les logs de serveur, l'historique de navigateur, et les en-têtes Referer. Utilisez toujours les en-têtes HTTP pour transmettre ces identifiants.

Ce que ça change dans la pratique

Si vous construisez une application — même simple, même no-code — comprendre cette distinction vous aide à poser les bonnes questions. Est-ce que j'expose une clé API dans mon frontend ? Est-ce que les tokens de mes utilisateurs ont une durée de vie raisonnable ? Est-ce que je sais comment révoquer un accès si quelque chose se passe mal ?

Ces questions ne demandent pas d'être développeur expérimenté. Elles demandent juste de savoir ce qu'on manipule. Un token et une clé API, ce ne sont pas des mots de passe qu'on retient. Ce sont des identifiants que les machines échangent — et la sécurité de votre application dépend en partie de la façon dont vous les gérez.