Developer Mode : contrôle avancé

Le Developer Mode d’OpenAI est un environnement avancé du Playground qui vous permet de tester, itérer et déboguer vos prompts avec un contrôle granulaire sur tous les paramètres de l’API. Il tient exactement le rôle qu’un REPL tient dans un projet Python : l’endroit où l’on essaie vite, où l’on se trompe sans conséquence, et d’où l’on ressort avec quelque chose qui mérite d’être commité. C’est l’outil qui fait passer un prompt du statut de brouillon à celui de composant de production.

Accéder au Developer Mode

Le Playground OpenAI est accessible depuis platform.openai.com. Le mode développeur y expose l’ensemble des paramètres que vous retrouverez ensuite dans l’API : modèle, system prompt, température, top_p, max tokens, format de sortie et outils (tools). L’intérêt de cette correspondance stricte est qu’aucune traduction mentale n’est nécessaire entre l’interface et votre code — le réglage que vous déplacez dans un panneau devient un argument nommé dans l’appel, sous le même nom.

# Ce que vous testez dans le Playground se traduit
# directement en code API :
from openai import OpenAI

client = OpenAI()

response = client.responses.create(
    model="gpt-5.6-sol",
    instructions="Tu es un assistant de revue de code Python. "
                 "Signale les problèmes de sécurité en priorité.",
    input="Revois ce code : subprocess.call(user_input, shell=True)",
    temperature=0.2,
    max_output_tokens=1000
)

Les panneaux du Playground

Le panneau System est celui où vous rédigez et retouchez votre system prompt. Le Playground conserve l’historique de vos modifications, ce qui vous offre un versioning léger pendant la phase exploratoire, avant que le prompt ne rejoigne votre dépôt Git et n’entre dans un cycle de revue normal.

Le panneau de conversation sert à éprouver des échanges multi-tours, et c’est là que se révèle un défaut invisible sur un appel isolé : la dérive conversationnelle. Le modèle tend à « oublier » les instructions du system prompt après de longs échanges. Poussez donc le test au-delà de dix messages avant de conclure que votre prompt tient, car un assistant qui refuse proprement une question hors sujet au premier tour peut très bien y répondre au douzième, une fois le contexte saturé.

Le panneau de paramètres expose enfin tous les réglages de génération :

Model : GPT-5.6 Sol, GPT-5.6 Terra, GPT-5.6 Luna (avec le réglage de raisonnement, de none à max)
Temperature, Top P et Max output tokens
Response format : texte libre, JSON object, JSON schema
Tools : fonctions, code interpreter, file search

Les deux derniers réglages sont ceux dont l’effet surprend le plus. Basculer Response format de texte libre à JSON schema change radicalement la nature de la sortie : vous n’obtenez plus un texte à parser mais une structure dont votre code peut dépendre, ce qui déplace tout un pan de fiabilité du prompt vers l’API. Activer un outil, de son côté, autorise le modèle à sortir de sa fenêtre de contexte pour aller chercher une information ou exécuter du code, et transforme un assistant conversationnel en composant capable d’agir. Testez ces bascules dans le Playground avant de les intégrer : leur comportement se comprend mieux en le voyant qu’en le lisant.

Un workflow de développement qui tient la route

Commencez par prototyper avec le modèle le plus capable, GPT-5.6 Sol, sans vous préoccuper du coût à ce stade. L’objectif est de valider un comportement, et si vous démarrez sur le plus petit modèle vous serez incapable de dire si un échec vient de votre prompt ou des limites du modèle — vous passeriez des heures à réécrire un prompt qui n’avait rien à se reprocher.

Itérez ensuite sur les cas limites, en gardant sous la main une liste de familles de requêtes que vous rejouez systématiquement après chaque modification du prompt.

# Cas limites à tester systématiquement :
test_cases = [
    "Requête normale dans le domaine",
    "Requête hors domaine (doit refuser poliment)",
    "Requête ambiguë (doit demander clarification)",
    "Injection de prompt (doit ignorer)",
    "Requête très longue avec beaucoup de contexte",
    "Requête dans une autre langue",
    "Requête avec des données sensibles",
]

Quand le comportement vous convient, exportez : le Playground génère le code correspondant à votre configuration, que vous copiez tel quel dans votre application. Reste l’étape que l’on saute trop souvent, le downgrade de modèle. Une fois le prompt stabilisé avec GPT-5.6 Sol, rejouez-le sur GPT-5.6 Terra puis GPT-5.6 Luna pour réduire les coûts, et attendez-vous à devoir l’ajuster : les modèles plus petits réclament des instructions plus explicites là où le plus capable devinait votre intention à demi-mot.

Comparer les modèles

from openai import OpenAI

client = OpenAI()

models = ["gpt-5.6-sol", "gpt-5.6-terra", "gpt-5.6-luna"]
prompt = "Explique le pattern Observer en Python avec un exemple."
system = "Tu es un formateur Python. Réponds en français, avec du code."

for model in models:
    response = client.responses.create(
        model=model,
        instructions=system,
        input=prompt,
        temperature=0.3
    )
    print(f"\n{'='*60}")
    print(f"Modèle : {model}")
    print(f"{'='*60}")
    print(response.output_text[:500])

Déboguer avec les métadonnées

Chaque réponse de l’API transporte des métadonnées précieuses. Le Playground les affiche, mais vous avez tout intérêt à les logger également en production, où elles constituent souvent votre seule trace exploitable après coup.

response = client.responses.create(
    model="gpt-5.6-terra",
    instructions="Réponds en JSON.",
    input="Liste 3 langages de programmation populaires."
)

print(f"Tokens utilisés (input)  : {response.usage.input_tokens}")
print(f"Tokens utilisés (output) : {response.usage.output_tokens}")
print(f"Modèle effectif          : {response.model}")

Le compte de tokens d’entrée trahit immédiatement un system prompt devenu obèse à force d’ajouts successifs, chacun raisonnable pris isolément. Celui de sortie révèle les réponses trop bavardes qui gonflent la facture sans rien apporter à l’utilisateur. Quant au modèle effectif renvoyé par l’API, il vous épargne de chercher pendant une heure la cause d’une régression qui tient en réalité à un identifiant de modèle mal propagé dans votre configuration.

À faire dès maintenant dans le Playground

Ouvrez le Playground et construisez le system prompt d’un assistant qui traduit du jargon technique en langage simple. Éprouvez-le sur cinq requêtes de natures différentes, exportez le code généré, puis exécutez-le en Python pour confirmer que le comportement survit à la sortie de l’interface. Terminez par une comparaison entre GPT-5.6 Sol et GPT-5.6 Luna sur les mêmes entrées : l’écart que vous observerez vous indiquera précisément quelles instructions votre prompt laisse encore implicites.

Points clés à retenir

Le Playground est votre environnement de prototypage rapide
Testez toujours les cas limites avant de passer en production
Exportez le code du Playground vers votre application
Commencez avec le modèle le plus capable, puis descendez en gamme
Les métadonnées de réponse sont essentielles pour l’optimisation