Clé API : un badge au nom de votre entreprise, et quatre décisions qui vous reviennent

Une clé API est un code secret, une longue suite de lettres et de chiffres, qu’un logiciel vous remet pour qu’un autre outil puisse lui parler au nom de votre entreprise. Une clé API fonctionne comme un badge d’accès : la personne qui l’a en main entre, comme vous, sans qu’on lui demande qui elle est. Google range les clés API parmi les « identifiants au porteur » (bonnes pratiques de Google Cloud sur les clés API, page mise à jour le 26 octobre 2026).

C’est pour cette raison que je tiens la clé API pour une affaire de dirigeant, pas de technicien. Elle engage le compte de l’entreprise, ses données, et parfois sa carte bancaire quand le service se paie à l’usage. Si vous ne le connaissez pas, n8n est un outil qui relie vos logiciels entre eux sans avoir à tout programmer. Quand vous y branchez une clé, quatre décisions vous reviennent :

1. Où la créer : dans le logiciel que l’on connecte (Stripe, Google, votre CRM), depuis le compte de l’entreprise, jamais dans n8n.
2. Avec quels droits : une clé par usage, limitée au strict nécessaire. Stripe déconseille sa clé secrète sans restriction pour tout nouvel usage et recommande la clé restreinte.
3. Où la ranger : à un seul endroit, les identifiants de n8n, « stockés de façon sécurisée ». Jamais dans un mail, une messagerie ou un tableur partagé.
4. Qui s’en sert, et jusqu’à quand : un prestataire reçoit le droit de l’utiliser, pas celui de la voir. Dans n8n, c’est le rôle « Can use » (« peut utiliser »). Et dès que la clé a fuité ou qu’une personne qui y avait accès s’en va, on la remplace.

Pour le sens du sigle API et son usage en général, voyez notre définition simple de l’API. Ici, on reste sur la clé elle-même, valable pour tous les logiciels, et sur la façon de la ranger dans n8n.

C’est quoi une clé API ?

Une clé API est un identifiant secret qu’un logiciel délivre pour reconnaître qui l’appelle et décider de ce qu’il a le droit de faire. Stripe, le service de paiement en ligne, l’écrit ainsi : il utilise les clés API « pour authentifier les requêtes de votre intégration et déterminer à quelles ressources Stripe elle peut accéder ». Une clé, c’est donc une identité et une liste de droits, réunies dans une seule chaîne de caractères.

Concrètement, une clé API sert à quatre choses :

• Identifier : le logiciel sait que c’est votre compte qui frappe à la porte.
• Autoriser : il ouvre certaines portes et pas d’autres, selon les droits attachés à la clé.
• Compter : il suit le volume d’appels passés avec chaque clé.
• Facturer : sur un service payant à l’usage, cette consommation vous est facturée.

AWS, le cloud d’Amazon, résume les deux derniers rôles : les fournisseurs utilisent les clés API « pour suivre l’utilisation et gérer la consommation d’API », et ils « facturent aux utilisateurs les ressources informatiques consommées par l’API » (AWS, « Qu’est-ce qu’une clé API ? », page non datée, lue le 28 octobre 2026).

Conséquence pour vous : qui détient la clé agit au nom de l’entreprise, et c’est l’entreprise qui paie. Stripe le formule pour sa clé secrète : si une personne malveillante l’obtient, elle « peut nuire à votre entreprise » (documentation Stripe sur les clés API, lue le 28 octobre 2026).

Stripe distingue quatre types de clés : la clé publiable, la clé restreinte, la clé secrète, aux droits illimités, et la clé d’organisation. Seule la première peut être montrée : « seules les clés publiables peuvent être exposées » hors de vos serveurs, et protéger les autres, « clés restreintes comprises », relève de votre responsabilité.

Comment obtenir une clé API ?

On obtient une clé API dans le logiciel qu’on veut connecter, jamais dans n8n : dans ses réglages, à une rubrique du type « API keys » ou « Identifiants ». On la crée depuis le compte de l’entreprise, on lui donne un nom, on choisit ses droits, puis on la copie. Chez Stripe, une clé secrète créée en mode réel ne s’affiche qu’une seule fois : il faut l’enregistrer tout de suite au bon endroit.

Deux éditeurs, deux parcours très proches :

1. Stripe : page « API keys » du tableau de bord, bouton « Create secret key », code de vérification reçu par mail ou par SMS, nom de la clé, puis copie. Stripe prévient : « Enregistrez la valeur de la clé. Vous ne pourrez pas la récupérer plus tard. » Et il recommande la clé restreinte « pour la plupart des usages ».
2. Google Cloud : dans la console, page « Identifiants », bouton « Créer des identifiants », puis « Clé API » dans le menu. L’étape suivante, selon Google : « Ajoutez au moins une restriction de clé API. » (Google Cloud, « Gérer des clés API », page mise à jour le 27 octobre 2026, lue le 28 octobre 2026).

Le point qui compte pour un dirigeant : le compte. Une clé créée sur le compte personnel d’un salarié ou d’un prestataire dépend de ce compte, pas du vôtre. Je conseille de la faire créer par une personne qui a les droits d’administration du compte de l’entreprise, et de ne jamais déléguer ce geste à quelqu’un d’extérieur.

Pour le parcours complet chez OpenAI, avec la facturation et le plafond de dépense, voyez notre guide de la clé API OpenAI.

Où ranger une clé API dans n8n ?

Dans n8n, une clé API se range dans les identifiants (« credentials » en anglais) : une fiche par service, créée une fois, que chaque workflow, c’est-à-dire chaque scénario automatisé, réutilise. n8n les décrit comme des informations d’authentification « stockées de façon sécurisée » et les chiffre avant de les enregistrer dans sa base de données. La clé ne se colle jamais en clair dans un nœud ou un champ de texte.

Les étapes, selon la documentation n8n sur la création des identifiants (libellés lus le 28 octobre 2026, l’interface peut évoluer) :

1. Cliquez sur Create dans le menu latéral, puis sur Credential. Vous pouvez aussi créer l’identifiant depuis la liste déroulante d’un nœud, dans l’éditeur.
2. Choisissez le service à connecter.
3. Remplissez les champs demandés par ce service, dont la clé.
4. Enregistrez : « quand vous enregistrez un identifiant, n8n le teste pour confirmer qu’il fonctionne ».
5. Renommez-le. n8n conseille un nom qui dit le service, le type et l’usage, par exemple « Stripe, clé restreinte, relances de factures ».

Dans un identifiant, un champ « Allowed HTTP Request Domains » limite les domaines vers lesquels l’identifiant peut servir dans un nœud HTTP Request, la brique de n8n qui appelle une adresse web. Selon n8n, ce champ « empêche l’usage détourné de l’identifiant, par exemple son envoi vers des adresses hors du domaine prévu ». Je conseille de le régler sur le seul domaine du service.

Côté chiffrement, n8n crée une clé de chiffrement aléatoire au premier lancement et « utilise cette clé pour chiffrer les identifiants avant qu’ils soient enregistrés dans la base de données » (n8n, réglage de la clé de chiffrement, page lue le 28 octobre 2026). Précision : cette page vise un n8n installé sur votre propre serveur. Dans ce cas, je conseille de garder cette clé de chiffrement avec le même soin que vos clés API.

Ne confondez pas avec la clé de l’API de n8n : n8n « utilise des clés API pour authentifier les appels » faits à sa propre API (documentation n8n sur l’authentification de l’API, page non datée, lue le 28 octobre 2026). C’est un autre sujet, traité dans notre guide de l’API n8n pour PME.

Comment sécuriser une clé API ?

Sécuriser une clé API, c’est réduire ce qu’elle peut faire et le nombre d’endroits où elle se trouve. Google publie neuf bonnes pratiques sur sa page dédiée, mise à jour le 26 octobre 2026. Parmi elles : restreindre la clé, supprimer celles qui ne servent plus, ne jamais l’écrire dans le code ni dans un dépôt de code partagé (type GitHub), donner à chaque membre de l’équipe sa propre clé pour chaque application, surveiller leur usage pour repérer un usage non autorisé, les renouveler régulièrement. Pour une PME, cela tient en six règles.

1. Une clé par usage. Stripe le permet en toutes lettres : « créez autant de clés restreintes que vous voulez et attribuez-les à différentes parties de votre application ». Si une clé fuit, vous coupez celle-là, pas toute la chaîne.
2. Des droits au plus juste. Google : « en ajoutant des restrictions, vous limitez les usages possibles d’une clé API et réduisez l’impact d’une clé compromise ». La CNIL rappelle le même principe pour les données : partager « uniquement aux personnes et pour les finalités prévues ».
3. Un plafond de dépense quand l’éditeur en propose un. Une clé qui déclenche une facture à l’usage mérite une limite : si le logiciel le permet, réglez-la avant de brancher quoi que ce soit.
4. Un seul endroit de rangement. Stripe conseille de ranger les clés sensibles « dans un coffre de secrets ». Pour une automatisation n8n, ce coffre, ce sont ses identifiants.
5. Jamais dans un mail, une messagerie ou un tableur. Stripe : « ne partagez pas les clés par mail, par messagerie ou par un autre canal non chiffré ».
6. Du ménage régulier. Google : « ne gardez que les clés API que vous utilisez réellement, pour réduire au maximum votre surface d’attaque ». Autrement dit : moins de clés, moins de portes à forcer.

La CNIL classe d’ailleurs parmi ce qu’il ne faut pas faire le fait de « négliger la sécurité des clés d’accès aux API, alors que des solutions de sécurisation des secrets, tel qu’un coffre-fort numérique, existent » (CNIL, fiche « Sécurité : API, interfaces de programmation applicative », publiée le 14 mars 2024). La fiche date de mars 2024 et n’affiche pas de mise à jour. Son conseil se lit sans peine : la clé va dans un coffre-fort numérique, pas dans une boîte mail.

Qui peut voir et utiliser une clé rangée dans n8n ?

Dans n8n, partager un identifiant ne veut pas dire montrer la clé. La personne avec qui vous le partagez reçoit le rôle « Can use » : elle « peut lancer et publier des workflows avec, mais ne peut ni voir ni modifier son contenu ». Votre prestataire se sert donc de la clé sans jamais la lire. Le propriétaire et les administrateurs de l’instance, c’est-à-dire de votre installation de n8n, voient tous les identifiants.

Ce que dit la documentation n8n sur le partage des identifiants, lue le 28 octobre 2026 :

• Qui voit tout : « les propriétaires et les administrateurs de l’instance peuvent voir et partager tous les identifiants ».
• Qui décide du partage : dans l’onglet Sharing, seul le propriétaire de l’identifiant, ou une personne autorisée à partager, change la liste des destinataires.
• Ce que voit une équipe sans partage direct : un projet qui utilise l’identifiant porte l’étiquette « Can view » ; ses membres le voient dans le workflow, sans pouvoir l’utiliser ni le modifier.
• Sur quelles formules : « le partage des identifiants est disponible » sur toutes les formules n8n Cloud, et, pour un n8n installé sur votre serveur, sur les formules Business et Enterprise seulement.

D’où la règle que je recommande : le compte n8n appartient à l’entreprise, et c’est l’entreprise qui en est propriétaire. Le prestataire y est invité, il reçoit « Can use » sur les identifiants dont il a besoin, et rien de plus. Si votre n8n tourne sur votre serveur avec une formule qui n’inclut pas le partage, vérifiez-le avant de faire intervenir quelqu’un.

Que faire quand une clé API a fuité ou qu’un prestataire s’en va ?

On la remplace, sans attendre. Stripe appelle ce geste la rotation : elle « révoque la clé et génère une clé de remplacement prête à l’emploi immédiatement ». Stripe la conseille quand une clé est perdue, compromise, ou quand une personne qui y avait accès quitte l’organisation ou change de poste. Google ajoute de renouveler les clés régulièrement et de supprimer celles qui ne servent plus.

Dans l’ordre :

1. Créer la nouvelle clé chez l’éditeur, ou lancer la rotation depuis son tableau de bord.
2. La coller dans l’identifiant n8n existant. Comme la clé n’est rangée qu’à cet endroit, c’est le seul à mettre à jour. n8n la teste à l’enregistrement.
3. Couper l’ancienne. Chez Stripe, lors d’une rotation depuis le tableau de bord, « l’ancienne et la nouvelle clé fonctionnent toutes les deux pendant 7 jours au plus », et Stripe conseille de n’expirer l’ancienne qu’après avoir vu ses requêtes tomber à zéro pendant quelques heures ou quelques jours. En cas de fuite, ce délai de confort n’a pas lieu d’être : Stripe prévoit justement la révocation pour « bloquer les requêtes potentiellement malveillantes ».
4. Retirer les accès. Pour un prestataire qui part, enlevez-le de l’onglet Sharing des identifiants dans n8n.

Un prestataire qui n’a eu que le rôle « Can use » n’a jamais vu le contenu de la clé : vous lui retirez le partage, et je ne recommande de remplacer la clé qu’en cas de doute, par exemple si le champ des domaines autorisés n’était pas réglé. Un prestataire qui a reçu la clé par mail, ou qui l’a créée sur son propre compte, l’a eue en main : il faut la remplacer.

Un scénario imaginé, du branchement au départ du prestataire

Prenons un cabinet de huit personnes, imaginé pour l’exemple, qui relie son CRM à n8n pour que chaque demande reçue sur le site soit triée et confiée au bon associé.

• Le premier jour, la gérante crée elle-même, depuis le compte administrateur du cabinet, une clé dans le CRM, limitée à la lecture et à la création de fiches contacts. Elle la nomme « n8n, tri des demandes ».
• Le même jour, elle la colle dans un identifiant n8n, dans le compte n8n Cloud du cabinet, règle le champ des domaines autorisés sur le seul domaine du CRM, et la partage en « Can use » avec le prestataire. Il construit le workflow sans jamais voir la clé.
• À la fin de la mission, la gérante retire le partage au prestataire. Il n’a jamais eu la clé en main, et le champ des domaines autorisés ne visait que le CRM : elle garde la même clé.
• Le jour où un stagiaire colle par erreur la clé dans un message d’équipe, la gérante la remplace dans le CRM, met à jour l’identifiant n8n, et supprime l’ancienne.

Dans ce scénario, chaque décision revient à la gérante : où créer la clé, avec quels droits, où la ranger, qui s’en sert et jusqu’à quand.

C’est ainsi que je conseille de travailler avec n’importe quel prestataire : vos clés se branchent dans votre compte n8n, elles ne s’envoient pas par mail. Ma page d’automatisation n8n pour PME décrit ma façon de faire : « Je connecte vos outils via leurs API et je teste chaque scénario sur vos cas réels avant toute mise en service », que ce soit pour la qualification et le routage des leads ou la synchronisation de vos outils.

Si vous préférez que votre équipe sache le faire elle-même, la formation agent IA et automatisation n8n dure deux jours, soit 14 heures. Elle comprend un module « Atelier n8n : construire, brancher l’IA, mettre en production », et le deuxième jour sert à construire dans n8n et à poser les garde-fous. Tarif pour un groupe jusqu’à huit personnes : 2 750 € à distance, 3 400 € sur place.

Sources

Citations traduites de l’anglais, sauf AWS et CNIL.

• Google Cloud, « Best practices for managing API keys », bonnes pratiques de gestion des clés API, mise à jour le 26 octobre 2026, lue le 28 octobre 2026.
• AWS, « Qu’est-ce qu’une clé API ? », page non datée, lue le 28 octobre 2026.
• Stripe, « API keys », documentation sur les clés API, page non datée, lue le 28 octobre 2026.
• Google Cloud, « Gérer des clés API », mise à jour le 27 octobre 2026, lue le 28 octobre 2026.
• n8n, « Create and edit credentials », créer et modifier des identifiants, page non datée, lue le 28 octobre 2026.
• n8n, « Set a custom encryption key », régler la clé de chiffrement, page indiquant une mise à jour 15 jours avant sa lecture, lue le 28 octobre 2026.
• CNIL, « Sécurité : API, interfaces de programmation applicative », 14 mars 2024.
• n8n, « Share credentials securely », partager les identifiants en sécurité, page non datée, lue le 28 octobre 2026.
• n8n, « Authentication », authentification de l’API n8n, page non datée, lue le 28 octobre 2026.