Gouvernance des clés OpenAI API : création, propriété, expiration et rotation sans interruption

Vous voulez imposer une expiration aux clés OpenAI API sans qu’une nouvelle règle interrompe une application ni découvrir, lors de la prochaine rotation, que la bonne clé de remplacement ne peut plus être créée. Vous devez aussi décider si la production utilise des comptes de service tandis que les développeurs conservent des clés personnelles.

Ce guide vous donne un ordre pratique : choisir le propriétaire selon la charge, fixer une durée réellement opérable, puis remplacer les anciennes clés avec une période de chevauchement contrôlée. Gardez deux faits en tête : les nouvelles règles de création ne modifient pas les clés existantes, et la politique de l’organisation prévaut sur celle du projet.

Commencez par la réponse : les nouveaux contrôles gouvernent les futures clés, pas les anciennes

Vous pouvez résumer les changements de septembre en deux contrôles : les types de nouvelles clés autorisés et la durée maximale des nouvelles clés de projet.

Date	Mise à jour OpenAI	Conséquence opérationnelle
10 septembre 2026	Une clé API de projet peut être créée avec une date d’expiration. Les administrateurs peuvent imposer une durée de vie maximale au niveau de l’organisation ou du projet.	Les nouvelles clés peuvent devenir temporaires par défaut, mais une rotation reproductible doit exister avant d’imposer une durée courte.
15 septembre 2026	Une organisation ou un projet peut n’autoriser que les service-account keys, n’autoriser que les user-owned project keys, ou interdire toute création de nouvelle clé API.	Production, développement individuel et projets gelés peuvent suivre des règles d’émission différentes.
15 septembre 2026	Les restrictions de l’organisation priment sur les paramètres du projet.	Un projet peut être plus strict, mais il ne peut pas assouplir la politique de l’organisation.
15 septembre 2026	Les clés API existantes ne sont pas affectées par les nouveaux contrôles de création.	Activer une règle ne révoque pas les anciennes clés et ne termine pas leur migration.

Deux limites sont essentielles. « Interdire les nouvelles clés » ne signifie pas « révoquer toutes les clés actuelles ». De plus, l’annonce du 10 septembre décrit une durée maximale appliquée aux clés nouvellement créées. Ne supposez pas qu’une ancienne clé recevra rétroactivement une date d’expiration sans le vérifier dans le projet concerné.

Séparez trois décisions : qui crée, combien de temps la clé vit et comment elle sort

Concevez ces trois décisions séparément : un seul réglage de la Platform ne gère pas tout le cycle de vie.

La politique d’émission décide si le projet autorise les clés de compte de service, les clés de projet détenues par un utilisateur, ou aucune nouvelle clé.

La politique d’expiration décide si une nouvelle clé doit expirer et fixe la durée maximale autorisée par l’organisation et le projet.

L’exécution du cycle de vie désigne la personne qui crée la clé de remplacement, le lieu de stockage, la méthode de diffusion aux applications, les preuves de validation, le moment de révocation et le plan de retour arrière.

Les deux premières décisions peuvent être imposées dans OpenAI Platform. La troisième dépend toujours du gestionnaire de secrets, du processus de déploiement, de l’observabilité, des responsabilités et des procédures d’incident. Une durée maximale sans responsable de rotation ni délai de livraison suffisant transforme un contrôle de sécurité en panne programmée.

Choisissez selon l’usage : compte de service en production, clé utilisateur en développement individuel

Privilégiez une service-account key pour la production et les charges partagées, une user-owned project key pour le travail local ou temporaire, et bloquez l’émission seulement pour les projets réellement gelés ou en arrêt.

Charge de travail	Type généralement adapté	Pourquoi	Risque à maîtriser
Service de production, backend partagé, tâche planifiée, agent exploité par une équipe	service-account key	L’information d’identification appartient à la charge de travail plutôt qu’à un salarié ; les changements d’équipe affectent moins la continuité.	Un compte de service partagé par trop d’applications augmente le rayon d’impact. Le séparer par projet ou charge.
Développement local, débogage ponctuel, script exploratoire	user-owned project key	Le propriétaire et la responsabilité individuelle sont clairs, et le départ d’un utilisateur peut inclure la suppression de ses accès.	Une clé personnelle ne doit pas devenir discrètement une dépendance partagée de production.
Projet archivé, en cours d’arrêt ou temporairement gelé	Interdire les nouvelles clés	Évite d’agrandir l’inventaire pendant la fermeture ou l’enquête.	Un gel prématuré peut empêcher de créer la clé nécessaire à une rotation ou une reprise.

Posez une question simple : l’application doit-elle continuer à fonctionner après le départ d’une personne précise ? Si oui, son accès de production ne devrait généralement pas dépendre du compte de cette personne. À l’inverse, distribuer une même clé de service sur tous les postes de développeurs diminue l’attribution et multiplie les copies du secret.

Aucun type n’est sûr par nature. Le risque réel dépend du périmètre, du stockage, des droits, de la durée, de la rotation et de la révocation. Une clé de service durable utilisée par des dizaines d’applications reste un point d’exposition important.

La politique de l’organisation est le plafond : un projet peut durcir, pas assouplir

La restriction de l’organisation est le plafond de tous les projets ; testez donc la prochaine rotation avant de l’appliquer largement.

Si l’organisation n’autorise que les clés de compte de service, un projet de développement ne peut pas réactiver les clés détenues par les utilisateurs. Il peut restreindre davantage son propre périmètre, mais pas rendre la politique globale plus permissive.

Avant de modifier la règle de l’organisation :

1. recensez les projets et classez-les en production, préproduction, développement, test, temporaire, archivé ou en arrêt ;
2. notez le type de clé dont chacun aura besoin lors de sa prochaine rotation, pas seulement les types actuels ;
3. identifiez la clé de remplacement de chaque charge active et vérifiez que la future règle permettra sa création ;
4. répétez création, diffusion, validation et révocation dans un projet à faible risque ;
5. appliquez la restriction globale seulement après avoir démontré qu’une rotation normale reste possible.

Puisque les anciennes clés continuent de fonctionner, une règle trop stricte peut sembler sans effet le jour de son activation. Le problème apparaîtra plus tard, à l’approche d’une expiration, lorsque l’équipe découvrira qu’elle ne peut pas créer la bonne clé de remplacement. Testez la prochaine rotation, pas seulement le trafic actuel.

N’imposez pas la même durée partout : partez du temps réel d’une rotation

La durée maximale doit dépasser le temps complet nécessaire pour approuver, créer, distribuer, déployer, observer et annuler un remplacement.

Définissez au minimum :

Champ	Question à résoudre
Durée maximale N	Combien de temps peut s’écouler entre création et expiration ?
Anticipation R	Combien de temps avant expiration faut-il commencer le remplacement ?
Responsable principal et remplaçant	Qui agit et qui prend le relais en cas d’absence ?
Mode de diffusion	L’application recharge-t-elle une nouvelle version du secret ou faut-il redémarrer/redéployer ?
Preuves de validation	Quelles requêtes, traces, erreurs et données d’usage prouvent le basculement ?
Fenêtre de retour arrière	Combien de temps conserver l’ancienne clé après le basculement ?
Exceptions	Qui peut prolonger, pour combien de temps et avec quelles mesures compensatoires ?

R doit couvrir l’ensemble du processus. Une durée très courte, associée à des copier-coller manuels, des approbations entre fuseaux horaires et aucun suppléant, est moins fiable qu’une durée légèrement plus longue avec alertes automatiques et procédure répétée.

Utilisez la valeur de l’organisation comme plafond commun. Les projets à risque élevé peuvent adopter une limite plus courte, jamais plus longue. Production, développement personnel, tests temporaires et projets en fin de vie n’ont pas le même impact ni la même vitesse de rétablissement ; ils n’ont donc pas forcément besoin du même nombre.

Évitez l’interruption avec cette rotation en sept étapes

Le schéma le plus sûr consiste à faire coexister brièvement l’ancienne et la nouvelle clé, puis à révoquer l’ancienne lorsque le trafic réel confirme le basculement.

1. Inventorier les clés actuelles

Pour chaque clé, consignez le projet, le type de propriétaire, la charge, l’application, l’environnement, le responsable, l’emplacement du secret, le mode de déploiement, la date de création, l’expiration connue et le dernier usage observé. Une clé dont le propriétaire ou l’usage est inconnu doit faire l’objet d’une enquête prioritaire plutôt que d’une révocation massive à l’aveugle.

L’entrée du 4 août 2026 indique que les tableaux Usage et Costs ainsi que Usage API et Costs API permettent de filtrer et regrouper par clé API. Cette dimension aide à savoir si une clé produit encore des requêtes. Elle ne suffit pas seule : une tâche mensuelle ou un chemin de reprise peut rester silencieux longtemps.

2. Créer une clé de remplacement conforme

Créez la nouvelle clé dans le bon projet, avec le type de propriétaire autorisé, et une expiration qui ne dépasse pas le plafond applicable. Vérifiez cette possibilité avant la fenêtre de maintenance.

3. Stocker une nouvelle version du secret

N’écrasez pas immédiatement l’unique valeur ancienne. Pendant la transition, conservez les deux versions avec des états explicites : « production actuelle », « candidate à la rotation », « en attente de révocation ». Ne placez pas la clé dans le code, l’image de conteneur, un ticket, un journal ou une conversation.

4. Déplacer le trafic progressivement

Commencez par une instance, une tâche peu risquée ou une faible part du trafic. Vérifiez l’authentification, l’attribution au projet, les autorisations et le comportement des requêtes, puis élargissez. Si l’application ne lit son secret qu’au démarrage, intégrez les redémarrages et la capacité disponible au plan.

5. Observer la santé et l’usage par clé

Contrôlez les requêtes réussies, erreurs d’authentification, limites, latence et résultats métier. Confirmez parallèlement que la nouvelle clé reçoit l’usage attendu et que l’ancienne décline. Un déploiement « réussi » ne prouve pas que le trafic a basculé.

6. Limiter la fenêtre de retour arrière

Conservez l’ancienne clé pendant une période définie après stabilisation, puis révoquez-la. La fenêtre doit couvrir les workers retardés, régions et tâches rares, sans rester ouverte indéfiniment. Deux clés valides en permanence doublent l’exposition sans terminer la rotation.

7. Révoquer, vérifier et planifier la suivante

Après révocation, vérifiez que l’ancienne clé échoue et que la nouvelle continue de fonctionner. Mettez à jour l’inventaire, les notes d’astreinte, le responsable, l’expiration et la prochaine échéance.

Les anciennes clés ne deviennent pas conformes seules : migrez-les par risque

Après activation des nouvelles règles, vous avez encore besoin d’une file distincte pour les anciennes clés, car leur propriétaire et leur durée ne changent pas automatiquement.

Créez une file de migration séparée et priorisez :

1. les clés apparues dans du code, des tickets, des journaux ou des conversations ;
2. les clés dont le propriétaire ou l’objectif est inconnu ;
3. les clés d’utilisateurs partis ou ayant changé de rôle ;
4. les clés partagées entre plusieurs applications de production ;
5. les clés à large périmètre ou fort impact ;
6. les clés ayant un propriétaire clair, une seule charge et un chemin de remplacement testé.

Ne mesurez pas le succès au nombre de clés révoquées le même jour. Une migration sûre signifie que chaque ancienne clé possède une cartographie des dépendances, un remplacement approuvé, des preuves de basculement et une date de révocation. Pour une exception temporaire, documentez le blocage exact, le propriétaire, les mesures compensatoires et sa date de fin.

Votre politique interne doit couvrir au moins ces 11 champs

Une politique exécutable doit préciser la règle, le responsable, les preuves de validation, la fenêtre de retour arrière et la condition de révocation.

Élément	Information à consigner
Périmètre	Organisation, projets, environnements et classes de charges
Type autorisé	Compte de service seulement, utilisateur seulement, ou aucune nouvelle clé
Justification	Continuité, responsabilité individuelle, gel ou autre raison documentée
Durée maximale	Plafond de l’organisation et limites de projet plus strictes
Anticipation	Moment où une alerte ou tâche est créée avant expiration
Stockage	Gestionnaire de secrets approuvé et rôles d’accès
Déploiement	Canary ou phases, redémarrage et retour arrière
Preuves	Requêtes réussies, erreurs, usage par clé et trafic de l’ancienne à zéro
Révocation	Nouvelle clé stable, tâches rares couvertes, fenêtre fermée
Exception	Approbateur, motif, compensation et expiration de l’exception
Audit	Création, changement de politique, déploiement, révocation et changement de propriétaire

Attribuez la responsabilité durable à une charge ou un rôle d’équipe, tout en nommant l’exécutant de la rotation courante. « L’équipe plateforme s’en charge » n’est pas opérationnel sans astreinte, délai et escalade.

Avant l’application, répétez la prochaine rotation

N’appliquez les restrictions d’organisation ou de projet qu’après avoir traité tous les points ci-dessous et terminé une répétition à faible risque.

• chaque application active correspond à un projet et une clé précis ;
• le type nécessaire à la prochaine rotation de chaque projet est connu ;
• la règle de l’organisation ne bloquera pas un remplacement critique ;
• la production ne dépend pas de la clé personnelle d’une seule personne ;
• le gestionnaire de secrets prend en charge les versions ou un retour fiable ;
• le chargement du nouveau secret, y compris un éventuel redémarrage, a été testé ;
• l’usage ou le coût est observable par clé en tenant compte des tâches rares ;
• un responsable principal et un remplaçant sont désignés ;
• les alertes arrivent suffisamment tôt ;
• les critères de révocation empêchent un chevauchement permanent ;
• chaque ancienne clé non résolue possède un blocage, un propriétaire et une échéance.

Questions fréquentes

Une nouvelle restriction coupe-t-elle immédiatement les applications existantes ?

Selon l’entrée du 15 septembre 2026, les clés existantes ne sont pas affectées par les contrôles de création. Modifier les types de nouvelles clés autorisés ne révoque pas automatiquement les clés en service. La règle peut toutefois bloquer la rotation suivante ; testez donc la création de la remplaçante à l’avance.

La durée maximale expire-t-elle rétroactivement les anciennes clés ?

La mise à jour du 10 septembre décrit la règle pour les nouvelles clés. Ne supposez pas d’effet rétroactif ; vérifiez les détails de chaque clé et migrez le parc historique séparément.

Un administrateur de projet peut-il assouplir la restriction de l’organisation ?

Non. La restriction de l’organisation prévaut sur les réglages du projet.

Toute l’organisation doit-elle n’utiliser que des comptes de service ?

Privilégiez les comptes de service pour la production, les backends partagés, les tâches planifiées et les agents exploités par une équipe. Privilégiez les clés de projet utilisateur pour le développement local et les explorations temporaires. Une règle « comptes de service uniquement » à l’échelle de l’organisation n’est pertinente que si presque tous les projets appartiennent au premier groupe et si le développement dispose déjà d’une alternative praticable.

Quand faut-il interdire toute nouvelle clé ?

Pour un projet archivé ou en arrêt, ou temporairement pendant une enquête de sécurité. Vérifiez d’abord qu’aucune nouvelle clé n’est nécessaire pour une rotation ou une reprise.

Comment prouver qu’une ancienne clé peut être révoquée ?

Combinez l’état du déploiement, les requêtes réussies avec la nouvelle clé, la surveillance des erreurs, l’usage par clé, l’exécution des tâches rares et la fin de la fenêtre de retour arrière. Une courte période sans trafic ne suffit généralement pas.

Par quoi commencer

Commencez par trois actions : notez le type de clé nécessaire à chaque projet lors de sa prochaine rotation, terminez une rotation avec chevauchement sur un projet à faible risque, puis seulement imposez les restrictions d’organisation et de projet.

L’ordre compte. Si vous fixez d’abord le plafond, les applications actuelles peuvent continuer à fonctionner tandis que la politique bloque discrètement la future clé de remplacement. Prouvez que la prochaine rotation fonctionne avant de durcir les règles.

Source officielle :

• OpenAI API Changelog : mises à jour des 10 et 15 septembre 2026