Créer et utiliser une clé API

Une clé d’API n’a aucun droit propre : elle rejoue ceux du membre qui l’a créée — même entreprise, même rôle, mêmes affectations. Un utilisateur affecté à trois projets en voit trois par sa clé ; un administrateur voit tout. Et un identifiant d’une autre entreprise répond « introuvable », jamais « interdit » : le cloisonnement du serveur ne se négocie pas plus par l’API que par l’écran.

Lecture seule

Une clé créée en lecture seule passe sur tout GET et se voit refuser tout POST, PUT, PATCH et DELETE avant même d’atteindre la route — outils MCP compris. C’est la clé à donner à un tableau de bord ou à un assistant qui n’a rien à modifier.

Ce qu’une clé ne fait jamais

Toucher à la sécurité du compte : second facteur, appareils connectés, mot de passe, autres clés, changement d’espace. Ces gestes restent réservés à une session ouverte dans l’application, pour qu’une clé volée ne puisse pas s’en fabriquer une seconde qui survivrait à sa révocation. Elle ne se fait pas non plus passer pour le poste : ouvrir une session d’agent, signaler une présence ou un voyant Claude n’a de sens que depuis l’application. Ces routes sont marquées dans la référence.

Expiration et révocation

Une clé expire à la date choisie à sa création, ou jamais. Révoquée — par son porteur, ou par un administrateur depuis la liste des clés de l’entreprise —, elle cesse de répondre à l’instant. Désactiver un compte coupe ses clés.

Journal

La création et la révocation d’une clé sont journalisées, comme chaque révélation de secret qu’elle demande. Une clé qui lit trente mots de passe en une heure déclenche la même alerte qu’un humain qui le ferait.

Deux authentifications, toujours

Cette clé ouvre le compte Nexus. Elle n’a aucun rapport avec le compte Claude ni le compte ChatGPT de ses développeurs, que Nexus ne voit jamais : aucune route ne les concerne.