Clés API

Un mot de passe pour votre application

La forme la plus simple d'authentification est la clé API (API key). Il s'agit d'une longue chaîne de caractères aléatoires qui identifie votre application. Considérez-la comme un mot de passe, mais pour votre application plutôt que pour une personne.

Lorsque vous vous inscrivez à un service comme Google Maps ou à une API météo, ils vous fournissent une clé API. Chaque fois que votre application effectue une requête, elle inclut cette clé pour que le serveur sache quelle application l'appelle.

Chaque service génère des clés dans son propre format. Voici quelques exemples réels :

e8a41c0f3b2d4a5e9f7c1b3d5a7e9f2c
AIzaSyB1hTfKaP3mVfG8xRz2nLwJqK9dE4cX7Yo
sk_live_4eC39HqLyjWDarjtT1zdp7dc

Elles ont toutes un aspect différent, mais elles remplissent la même fonction : identifier de manière unique l'auteur de la requête.

Où va la clé ?

Il existe deux endroits courants où les clés API sont envoyées. Vous verrez les deux dans la documentation.

Dans un paramètre de requête (query parameter) (l'approche la plus simple). Il vous suffit d'ajouter la clé à l'URL :

C'est ainsi que procèdent Google Maps, NewsAPI et OpenWeatherMap. C'est simple : vous collez la clé directement dans l'URL. Vous pouvez même la tester directement dans votre navigateur.

Dans un en-tête (header) (plus sécurisé, mais nécessite un outil) :

Les en-têtes sont plus sécurisés car les paramètres de requête peuvent se retrouver dans l'historique du navigateur, les journaux du serveur et les URL partagées. Imaginez que vous colliez accidentellement une URL contenant votre clé API dans un canal Slack. Avec les en-têtes, la clé reste cachée.

Le bémol : vous ne pouvez pas définir d'en-têtes à partir de la barre d'adresse d'un navigateur. Lorsque vous tapez une URL dans votre navigateur et appuyez sur Entrée, cela envoie une simple requête GET sans en-têtes personnalisés. Pour ajouter un en-tête Authorization, vous avez besoin d'un outil comme Postman, ou vous avez besoin que le code de votre application le fasse. C'est pourquoi les clés basées sur les paramètres de requête sont plus faciles à tester : il suffit de coller l'URL et de lancer la requête.

La documentation de l'API vous indique toujours quelle méthode utiliser. Vous ne choisissez pas.

Ce que voit le serveur

Lorsque votre requête arrive, le serveur extrait la clé API et la recherche. En coulisses, il existe une table qui fait correspondre les clés aux applications :

Le serveur vérifie : cette clé existe-t-elle ? Le forfait est-il actif ? L'application a-t-elle atteint sa limite de débit (rate limit) ? Si tout est en ordre, la requête passe. Si la clé est manquante, invalide ou si elle a dépassé sa limite, le serveur rejette la requête.

C'est ainsi que les services savent qui appelle, même sans écran de connexion. Pas de nom d'utilisateur, pas de mot de passe. Juste la clé.

Exemples concrets

Google Maps : chaque fois que vous voyez une carte intégrée sur un site web, la clé API du développeur est incluse dans la requête. Google l'utilise pour suivre l'utilisation et facturer en conséquence. Niveau gratuit : jusqu'à un certain nombre de chargements de cartes. Au-delà, vous payez.

Stripe : lorsqu'une application débite une carte de crédit, la requête inclut une clé API Stripe. La clé détermine vers quel compte Stripe le paiement est dirigé. Stripe vous donne deux clés : une clé de "test" pour le développement (pas de frais réels) et une clé "live" pour la production (argent réel).

API météo : les applications qui affichent les prévisions appellent un service météo avec une clé API. Le forfait gratuit peut vous accorder 1 000 requêtes par jour. Suffisant pour un projet personnel, pas assez pour une application populaire.

Le modèle est toujours le même : s'inscrire, obtenir une clé, l'inclure dans vos requêtes.

Les règles d'or des clés API

Les clés API sont des secrets. Elles doivent être traitées comme des mots de passe. Voici quelques règles que tout développeur connaît (et que vous devriez connaître aussi en tant que PM) :

Ne mettez jamais de clés API dans le code frontend. Si votre clé se trouve dans du JavaScript qui s'exécute dans le navigateur, n'importe qui peut ouvrir le code source de la page et la voir. C'est comme écrire son mot de passe sur un tableau blanc. Les clés API appartiennent au serveur, là où seul votre code backend peut y accéder.

Ne commitez jamais de clés API dans Git. Les dépôts de code (même privés) ne sont pas des lieux sûrs pour stocker des secrets. Si un développeur pousse accidentellement une clé sur GitHub, des robots peuvent la trouver en quelques minutes. Les entreprises utilisent des outils spéciaux appelés "gestionnaires de secrets" (secret managers) pour stocker les clés en toute sécurité.

Renouvelez les clés en cas de fuite. Si une clé est exposée, la solution consiste à en générer une nouvelle et à supprimer l'ancienne. La plupart des services vous permettent de le faire dans leur tableau de bord. C'est comme changer votre mot de passe après un piratage.

Utilisez des clés différentes pour différents environnements. Une clé pour les tests, une autre pour la production. Si la clé de test fuite, vos données réelles restent en sécurité.

Quand votre équipe technique dit "nous devons renouveler la clé API" ou "on ne peut pas mettre cette clé dans le frontend", c'est ce qu'ils veulent dire. Ce n'est pas de la paranoïa. C'est une pratique standard.

Points clés à retenir

• Une clé API est une chaîne secrète qui identifie votre application auprès d'un serveur.
• Les clés sont envoyées dans les paramètres de requête (simple, testable dans un navigateur) ou dans les en-têtes (plus sécurisé, nécessite un outil).
• On ne peut pas définir d'en-têtes à partir de la barre d'adresse d'un navigateur. Il faut un outil comme Postman ou le code de l'application.
• Le serveur associe la clé à une application, vérifie le forfait et les limites, puis répond.
• Les clés API sont des secrets : ne les exposez jamais dans le code frontend, ne les commitez jamais dans Git.