Quatre services distincts, une seule variable d’environnement : c’est la configuration retrouvée sur un site e-commerce de taille moyenne, où THIRD_PARTY_API_KEY servait à la fois pour Stripe, Algolia, HubSpot et un service d’envoi de SMS. Un développeur pressé avait réutilisé le même nom de constante à chaque nouvelle intégration, pensant simplifier la configuration.
Le problème est apparu au moment de révoquer la clé Stripe après un changement de compte bancaire : impossible de le faire sans casser également la recherche Algolia, l’envoi des formulaires vers HubSpot et les SMS de confirmation de commande, tous dépendants de la même variable réutilisée dans le code sans distinction claire.
Pourquoi une clé maîtresse est une fausse économie
Mutualiser une clé entre plusieurs services n’existe presque jamais réellement dans les API modernes : chaque service génère ses propres identifiants, avec ses propres portées. Ce qui se mutualise en pratique, c’est le nom de la variable d’environnement dans le code, ce qui crée une confusion entre plusieurs secrets distincts, stockés sous une étiquette unique. Cette confusion a un coût direct dès qu’il faut réagir à un incident : révoquer, faire pivoter ou auditer une clé impose de comprendre d’abord tous les usages qui en dépendent, ce qui prend du temps précisément au moment où il en manque.
Elle a aussi un coût en cas de fuite : si un seul de ces usages expose la valeur (message d’erreur, journal de débogage, dépôt de code), c’est l’ensemble des quatre services qui doit être considéré comme compromis, même si trois d’entre eux n’ont rien à voir avec la fuite initiale.
La checklist de cloisonnement
- Une constante par service et par usage :
STRIPE_SECRET_KEY,ALGOLIA_SEARCH_KEY,HUBSPOT_FORMS_TOKEN,SMS_PROVIDER_KEY, jamais une variable générique. - Une portée minimale par clé : côté Stripe, une clé restreinte (Restricted key) limitée aux endpoints réellement utilisés plutôt que la clé secrète complète du compte.
- Un environnement par clé : les clés de test (
sk_test_,pk_test_) ne doivent jamais cohabiter dans le même fichier.envque les clés de production, même commentées. - Un tableau de suivi des clés actives : service, usage précis, portée, date de création, date de dernière rotation, personne responsable.
- Une revue trimestrielle : chaque clé du tableau est confrontée au code source pour vérifier qu’elle est toujours utilisée quelque part.
Restreindre concrètement une clé Stripe
Stripe permet de créer des clés restreintes directement depuis le tableau de bord, en cochant précisément les ressources autorisées (lecture des paiements, création de PaymentIntent, sans accès aux remboursements ni aux virements par exemple). Cette granularité change la nature du risque : une fuite de cette clé restreinte permet de créer des paiements, pas de vider le solde du compte ni de modifier la configuration des webhooks.
Le même principe s’applique à Algolia, où une clé de recherche peut être générée avec generateSecuredApiKey pour ne couvrir qu’un index précis, et à HubSpot, où les jetons d’application privée permettent de sélectionner finement les portées (scopes) accordées, plutôt que d’utiliser une clé d’API historique aux droits larges.
Ce que révèle un tableau de suivi bien tenu
Sur ce projet, la mise en place du tableau de suivi a révélé deux clés Algolia actives qui ne servaient plus à rien, créées lors d’un test d’intégration jamais nettoyé, ainsi qu’une clé HubSpot dont les portées incluaient la gestion des contacts alors que seul l’envoi de formulaires était réellement utilisé. Ces découvertes n’auraient jamais émergé d’un simple audit du code, car les clés fonctionnaient toutes correctement : le problème n’était pas un dysfonctionnement, mais une surface d’exposition inutilement large.
En résumé
Le réflexe d’une clé unique par commodité se paie toujours plus tard, au moment où il faut réagir vite à un incident ou révoquer un accès précis sans tout casser. Nommer chaque clé selon son usage exact, restreindre sa portée au strict nécessaire et tenir un tableau de suivi vivant transforment une gestion de secrets confuse en système lisible, où chaque révocation devient un geste ciblé plutôt qu’un pari sur ce qui va casser ailleurs.
