Authentification, clés API et organisation

Avant d’écrire une seule ligne de code, vous devez configurer votre accès à l’API. Cette leçon couvre la création des clés, la structuration des accès en organisations et projets, et les précautions de sécurité qui évitent la mauvaise surprise classique : une clé poussée par mégarde sur un dépôt public et consommée par un inconnu dans la nuit.

Créer votre compte et obtenir une clé

La procédure tient en trois temps. Rendez-vous d’abord sur platform.openai.com et créez un compte ; vous obtiendrez automatiquement des crédits gratuits pour commencer à expérimenter. Accédez ensuite à la section API Keys du tableau de bord et générez une nouvelle clé. Elle ne vous sera affichée qu’une fois : copiez-la immédiatement, mais pas dans votre code.

# Votre clé API ressemble à ceci (ne la partagez jamais !)
# sk-proj-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

# La bonne pratique : variable d'environnement
import os
api_key = os.environ.get("OPENAI_API_KEY")

Troisième temps, la déclaration de la variable d’environnement, dont la syntaxe dépend de votre plateforme. Sur un poste de développement, le fichier .env chargé par python-dotenv est souvent le plus commode ; sur un serveur, préférez la variable d’environnement définie par votre orchestrateur ou votre service de secrets.

# Linux / macOS — ajoutez dans ~/.bashrc ou ~/.zshrc
export OPENAI_API_KEY="sk-proj-votre-cle-ici"

# Windows PowerShell
$env:OPENAI_API_KEY = "sk-proj-votre-cle-ici"

# Fichier .env (avec python-dotenv)
# .env
OPENAI_API_KEY=sk-proj-votre-cle-ici

Quel type de clé choisir

Les clés de projet, reconnaissables à leur préfixe sk-proj-, sont liées à un projet précis et offrent le meilleur contrôle : ce sont celles que vous utiliserez dans la quasi-totalité des cas. Le SDK les détecte tout seul dès que la variable d’environnement est en place, ce qui explique pourquoi OpenAI() s’instancie sans argument dans tous les exemples de cette formation.

from openai import OpenAI

# Le SDK détecte automatiquement OPENAI_API_KEY
client = OpenAI()

# Ou spécifiez explicitement (déconseillé en production)
client = OpenAI(api_key="sk-proj-...")

Les clés de service constituent le second type. Destinées aux applications serveur qui nécessitent un accès élevé, elles ouvrent des permissions supplémentaires et méritent en conséquence une attention particulière : rangez-les dans un coffre à secrets et n’en distribuez jamais la valeur à un poste de développement.

Organisations et projets

L’accès s’articule sur trois niveaux emboîtés :

Organisation : votre entreprise ou équipe
Projet : un regroupement logique (ex: “Chatbot production”, “Analyse données”)
Clé API : liée à un projet spécifique

Si vous appartenez à plusieurs organisations, précisez celle que vous visez à l’instanciation du client :

from openai import OpenAI

# Spécifier l'organisation (utile si vous appartenez à plusieurs)
client = OpenAI(
    organization="org-xxxxxxxxxxxx",
    project="proj-xxxxxxxxxxxx"
)

Prenez le temps de découper vos usages en projets plutôt que de tout faire transiter par une clé unique : le bénéfice se manifeste dès le premier incident. Chaque projet dispose de son propre suivi de consommation, ce qui vous permet d’attribuer un coût à une fonctionnalité précise plutôt qu’à un total mensuel opaque. Les rate limits sont également séparés : un batch nocturne qui sature son quota n’empêchera pas votre chatbot de répondre aux clients. Vous assignez ensuite des membres différents à chaque projet, et surtout vous pouvez révoquer une clé compromise sans interrompre les autres applications.

Ne jamais exposer vos clés

La règle est simple et sans exception : une clé n’apparaît jamais dans le code source. Le contraste entre les deux écritures ci-dessous vaut mieux qu’un long discours.

# MAUVAIS — clé en dur dans le code
client = OpenAI(api_key="sk-proj-abc123")  # DANGER !

# BON — variable d'environnement
client = OpenAI()  # Lit OPENAI_API_KEY automatiquement

# BON — fichier .env avec python-dotenv
from dotenv import load_dotenv
load_dotenv()
client = OpenAI()

Le corollaire concerne votre .gitignore, qui doit exclure les fichiers de configuration locaux avant votre premier commit, pas après. Une clé publiée puis supprimée reste présente dans l’historique du dépôt.

# Ajoutez TOUJOURS ces lignes à votre .gitignore
.env
.env.local
.env.production
*.key

Prévoyez enfin une rotation régulière, tous les 90 jours. La manœuvre se fait sans coupure : vous créez une nouvelle clé, vous mettez à jour vos déploiements, puis vous supprimez seulement l’ancienne une fois que plus rien ne l’utilise.

Vérifier votre configuration

Avant de passer à la suite, exécutez ce script : il contrôle la présence de la clé, en affiche une version tronquée pour confirmer qu’il s’agit de la bonne, puis effectue un appel réel. C’est le test à relancer à chaque fois qu’un environnement se comporte bizarrement.

from openai import OpenAI
import os

def verifier_configuration():
    """Vérifie que la configuration API est correcte."""
    
    # Vérifier la présence de la clé
    api_key = os.environ.get("OPENAI_API_KEY")
    if not api_key:
        print("ERREUR : OPENAI_API_KEY non définie")
        return False
    
    print(f"Clé détectée : {api_key[:8]}...{api_key[-4:]}")
    
    # Tester la connexion
    try:
        client = OpenAI()
        response = client.responses.create(
            model="gpt-5.6-terra",
            input="Répondez uniquement : OK"
        )
        print(f"Connexion réussie : {response.output_text}")
        return True
    except Exception as e:
        print(f"ERREUR de connexion : {e}")
        return False

verifier_configuration()
# Résultat attendu :
# Clé détectée : sk-proj-...xxxx
# Connexion réussie : OK

Points clés à retenir

Utilisez des clés de projet (sk-proj-...) pour chaque application
Stockez vos clés dans des variables d’environnement, jamais dans le code
Organisez vos accès avec la hiérarchie Organisation → Projet → Clé
Effectuez une rotation régulière de vos clés (tous les 90 jours)
Ajoutez .env à votre .gitignore systématiquement