C'est quoi une clé d'API ? Le badge d'hôtel qui ouvre vos outils à votre agent IA
Vous voulez brancher un nouvel outil à votre agent. Un MCP, un service dans n8n, une petite application. Tout se passe bien, et puis arrive un champ vide avec cette consigne : « Collez votre clé d’API ici ».
Une clé d’API, c’est une longue suite de lettres et de chiffres qui pourrait ressembler à sk-4f9a2c.... Et partout où on en parle, le même avertissement revient : ne la partagez avec personne.
Alors c’est quoi au juste ? Un mot de passe ? Un code d’accès ? Un peu des deux. Pour l’expliquer, je vous propose une image : le badge d’une chambre d’hôtel. Gardez-la en tête, on va s’en servir tout le long.
Pourquoi connecter son agent, déjà ?
Petit rappel, si vous arrivez directement ici.
Un agent IA repose sur un modèle qui a appris énormément de choses sur le monde. Mais il ne sait rien de vous. Il n’a jamais vu vos mails, votre agenda, vos notes ou vos projets. Ses réponses sont justes en général, rarement justes pour vous.
En le branchant à vos outils, il travaille avec vos vraies données, à jour. Et il peut agir à votre place : ranger, créer, préparer, envoyer.
C’est le sujet de l’article qui ouvre cette série, si vous voulez creuser.
D’abord, c’est quoi une API ?
Quand vous utilisez Notion, vous passez par son interface : des pages, des boutons, des menus. C’est pensé pour des humains, avec des yeux et une interface pour interagir (souris, trackpad, écran tactile).
Un programme lui n’a pas besoin de toute cette mise en page et navigation. Il se sert d’une autre entrée : l’API, pour Application Programming Interface (interface de programmation, en français). C’est une liste de demandes que le service accepte, formulées d’une manière bien précise.
Ce sont les développeurs du service qui vont créer et gérer l’API pour que d’autres développeurs (et donc programmes) puissent interragir avec le service en question d’une manière cadrée et définie à l’avance. Une documentation n’est jamais bien loin - « Pour créer une tâche, il faut appeler cette url et il faudra indiquer ces informations dans ces champs là ».
Presque tous les services en ont une : Notion, Slack, et bien sûr les IA elles-mêmes. Petite note, les MCP et connecteurs dont je parlais dans les articles précédents ne font parfois rien d’autre que parler à cette API à votre place.
Et la clé, alors ?
Une API ne répond pas à n’importe qui. Avant de donner vos pages Notion, elle veut savoir deux choses : qui demande ? A-t-il le droit ?
La clé répond aux deux d’un coup. Le programme la joint à chacune de ses demandes, et l’API sait à qui elle a affaire.
C’est là que l’hôtel entre en scène. À votre arrivée, la réception vérifie votre identité une fois, puis vous tend un badge. Ensuite, plus besoin de sortir votre passeport devant chaque porte : vous passez le badge, et ça s’ouvre. La porte ne sait pas vraiment qui vous êtes. Elle sait que ce badge est lié à la chambre 117 et qu’il a le droit d’entrer.
La clé d’API fonctionne pareil. Vous vous connectez une fois à votre compte, vous créez une clé, et vous la donnez à l’outil ou à l’agent. Il ne connaîtra jamais votre mot de passe. Et le service considère chaque demande faite avec cette clé comme venant de vous.
Pour moi, ça n’a rien de nouveau. En tant que développeur, je manipule des clés d’API depuis bien avant les LLM et les agents. Dès qu’on veut qu’un programme utilise un service, c’est le geste de base : on fait ses appels avec une clé pour s’authentifier. Dans les applications mobiles que j’ai créées pour mes clients, il y en avait parfois pour des services tiers.
Ce qui change aujourd’hui, c’est que ce ne sont plus seulement les développeurs qui en voient passer. Avec les agents, tout le monde finit par tomber dessus.
Ce qui est bien avec une clé d’API
Ça marche presque partout. Les clés d’API existent depuis longtemps, et quasiment tous les services en proposent. Même ceux qui n’ont ni connecteur ni MCP. Et ça ne dépend pas de l’IA que vous utilisez : la même clé fonctionne avec Claude, ChatGPT, n8n ou un petit script.
Elle agit en votre nom. Au bar de l’hôtel, on vous propose de mettre la consommation sur la note de la chambre. Le badge est lié à vous. Une clé aussi : ce que l’agent fait avec, le service le compte comme fait par vous, sur votre compte, avec vos données.
On peut en avoir plusieurs. La réception fait un badge par personne de la chambre. De la même façon, on peut créer une clé par usage : une pour l’agent, une pour n8n, une pour telle application. Chacune avec son nom. On sait qui fait quoi, et on peut en couper une sans toucher aux autres.
On choisit les portes. Votre badge ouvre votre chambre, la salle de sport et la piscine. Pas les autres chambres, ni la cuisine. Beaucoup de services permettent la même chose : une clé en lecture seule, une clé qui ne voit qu’un seul projet, une clé qui peut créer mais pas supprimer. On dit qu’on « scope » la clé, qu’on limite sa portée.
J’aime bien quand un service le permet. Je peux restreindre la clé à ce dont l’outil a vraiment besoin. C’est le principe que je défends depuis le début de cette série : le meilleur moyen d’empêcher un agent de faire une bêtise, ce n’est pas de le lui interdire dans un prompt, c’est de ne pas lui en donner la capacité.
On ne donne pas son mot de passe. L’agent n’a jamais vos identifiants. Il ne peut pas essayer de se connecter avec sur un autre service. Il ne va pas non plus le divulguer, volontairement ou non. Attention par contre, la clé, elle, pourrait fuiter selon la façon dont on la donne à l’agent.
On la retire en un clic. Badge perdu ? La réception le désactive et vous en refait un. Votre séjour continue. Une clé, c’est pareil : vous la supprimez, votre compte reste intact, votre mot de passe ne change pas, vos autres clés continuent de fonctionner. Si quelqu’un a trouve une clé qui a fuité, il ne peut rien en faire, elle a été désactivé.
Où on la trouve, où on la met
Pour la trouver, direction les paramètres du service. La rubrique s’appelle souvent « API », « Développeurs », « Intégrations » ou « Clés ». On clique sur « Créer une clé », on lui donne un nom, parfois on choisit ses droits, et la clé apparaît.
Souvent, elle n’est affichée qu’une seule fois. Copiez-la tout de suite. Si vous la perdez, pas de panique : on la supprime et on en refait une. Comme le badge.
Pour la mettre, ça dépend de l’outil. Certains ont un champ prévu pour (n8n, la configuration d’un MCP, une application). Les agents qui tournent sur votre machine la lisent souvent dans un fichier de réglages, rangé à part.
Un réflexe à prendre, par contre : évitez de coller la clé directement dans la conversation. Ce que vous écrivez dans le chat est conservé dans l’historique, chez le fournisseur de l’IA, et peut se retrouver dans d’autres fichiers. Une clé, c’est mieux rangée à un seul endroit, prévu pour ça.
Clé d’API ou connexion avec son compte ?
Dans l’article sur les connecteurs, je disais que l’un de leurs avantages, c’est de ne pas avoir de clé à manipuler. On clique sur « Se connecter avec Google », on accepte les accès, et c’est fini.
En coulisse, il y a quand même une sorte de clé. Sauf que c’est le service qui la fabrique, la range et la renouvelle tout seul. Vous n’y touchez jamais. (Ça s’appelle OAuth, et vous n’avez pas besoin de retenir le nom.)
Alors, laquelle choisir ? J’ai envie dire, peu importe, ça aura souvent la même finalité. Regardez peut-être s’il y a une différence dans les droits d’accès accordés (le scope).
Les risques
C’est un secret utile. Un badge trouvé dans le couloir ouvre votre chambre. La porte ne vérifie pas que c’est bien vous qui le tenez. Une clé d’API, c’est pareil : celui qui la possède agit en votre nom. Il peut lire vos données, les modifier ou les supprimer selon les droits de la clé. Et si le service est payant, il dépense votre argent.
Elle fuit facilement. Une capture d’écran partagée un peu vite, un message à un collègue, un document collaboratif, un projet publié en ligne… Une clé, c’est du texte, et le texte se copie partout. Certains services repèrent les clés publiées par erreur et les désactivent d’office mais ne comptez pas trop dessus.
Les agents aussi peuvent la lire. Un agent qui a accès à vos fichiers a accès à ceux où dorment vos clés. Un MCP ou un skill malveillant peut aller les chercher. C’est un des risques que je décrivais à propos des skills : vérifiez ce que vous installez.
Quelques réflexes simples, donc :
- une clé par usage, avec un nom clair ;
- les droits minimum, quand le service permet de les choisir ;
- un plafond de dépense, quand le service est payant ;
- jamais dans le chat, sur une capture ou dans un document partagé ;
- au moindre doute, on la supprime et on en refait une. C’est l’affaire d’une minute.
Un badge, pas une baguette magique
Une clé d’API n’a rien de mystérieux, ni de réservé aux développeurs. C’est un badge. Il ouvre les bonnes portes à votre agent, en votre nom, sans jamais lui confier votre mot de passe.
Et comme un badge d’hôtel, on le garde pour soi, on ne lui donne pas plus de portes que nécessaire, et on le fait désactiver au moindre doute.
Prochaine étape de la série : le CLI. Ces outils qu’on pilote en tapant des commandes, que les agents adorent, et qui réclament souvent… une clé d’API.
Connecter un agent IA à d’autres services :
- Comment connecter son agent IA à ses outils (Gmail, Notion, Google Agenda…) ?
- C’est quoi un connecteur IA ? Relier Claude ou ChatGPT à vos outils en quelques clics
- C’est quoi un MCP ? Le port USB-C qui branche votre agent IA à vos outils
- C’est quoi une clé d’API ? Le badge d’hôtel qui ouvre vos outils à votre agent IA
- C’est quoi un CLI ?
- C’est quoi un webhook ?