Une clé d'API qui peut tout faire est une clé qu'on ne peut pas confier

Vous choisissez les permissions à la création, dans le même catalogue que celui des rôles. Une clé faite pour pousser des contacts depuis votre site ne peut pas lire vos factures, et le refus vient du passage d'entrée, pas d'une convention de code. C'est le modèle des clés restreintes de Stripe ou des jetons à granularité fine de GitHub.

• Permissions choisies parmi le catalogue RBAC
• Vérification à chaque appel, côté passerelle
• Clé secrète ou clé publique, selon l'usage
• Étiquette et note, pour savoir à quoi elle sert

Une clé peut porter une date de fin. Et même sans date, une fenêtre d'inactivité de quatre-vingt-dix jours s'applique : une clé qu'on n'utilise plus cesse de fonctionner d'elle-même. C'est la fuite la plus banale — une clé posée dans un script un mardi et oubliée pendant trois ans.

• Date d'expiration explicite, au choix
• Fenêtre d'inactivité de 90 jours, en plus
• Date de dernière utilisation affichée
• Révocation immédiate, avec l'auteur de la révocation

La clé en clair n'existe qu'au moment où vous la créez : ensuite seule son empreinte est conservée, et rien ne permet de la relire — ni l'interface, ni le support, ni le journal d'audit, qui trace l'événement sans jamais porter la valeur. Si elle est perdue, on en crée une autre et on révoque l'ancienne.

• Valeur affichée une seule fois, jamais stockée en clair
• Journal d'audit sans secret ni empreinte
• Alerte par e-mail sur une adresse IP jamais vue
• Création et révocation attribuées à leur auteur