Utiliser GPT-6

Introduction

GPT-5.6 établit une nouvelle référence en matière de qualité et d’efficacité pour les workflows complexes en production. GPT-5.6 est particulièrement économe en tokens et améliore la qualité visuelle des interfaces grâce à de meilleurs choix de conception, de mise en page et de hiérarchie visuelle.

GPT-5.6 introduit également une nouvelle convention de nommage. L’alias gpt-5.6 dirige les requêtes vers gpt-5.6-sol, le modèle phare de la famille. Utilisez gpt-5.6-terra pour obtenir de bonnes performances à moindre coût et gpt-5.6-luna pour traiter efficacement de grands volumes de requêtes.

Si vous migrez depuis GPT-5.5 ou GPT-5.4, partez du niveau de raisonnement que vous utilisez avec ce modèle. Testez ensuite ce niveau et le niveau immédiatement inférieur sur des tâches représentatives. GPT-5.6 peut souvent maintenir ou améliorer la qualité avec moins de tokens, mais le meilleur réglage dépend de votre charge de travail.

Nouveautés

• Appels d’outils programmatiques : GPT-5.6 peut écrire du JavaScript pour appeler les outils éligibles, transmettre les résultats d’un appel à l’autre et traiter les sorties intermédiaires dans un environnement d’exécution hébergé. Utilisez les appels d’outils programmatiques pour les workflows bien délimités qui sollicitent beaucoup d’outils et dans lesquels le modèle n’a pas besoin de prendre une nouvelle décision à chaque étape. Les appels d’outils programmatiques sont compatibles avec la politique de non-conservation des données (ZDR) et n’entraînent pas de frais de conteneur supplémentaires.
• Fonctionnement multi-agent [bêta] : le fonctionnement multi-agent permet à une instance de GPT-5.6 de coordonner plusieurs sous-agents en parallèle et de synthétiser leurs résultats. Comme le mode Ultra de Codex, il peut réduire le temps d’exécution total et améliorer les performances sur les tâches complexes qui se décomposent facilement en travaux indépendants. Cette fonctionnalité est disponible en bêta dans l’API Responses et évolue en fonction des retours des développeurs.
• Mise en cache explicite des prompts : GPT-5.6 vous permet d’indiquer précisément quels préfixes de prompt réutilisables OpenAI doit mettre en cache. Vous pouvez toujours utiliser la mise en cache automatique en mode implicite. OpenAI facture les écritures dans le cache à 1,25 fois le tarif des entrées non mises en cache. Les lectures bénéficient toujours d’un tarif réduit. Découvrez comment configurer la mise en cache des prompts.
• Conservation du raisonnement : GPT-5.6 peut réutiliser les éléments de raisonnement disponibles d’un tour à l’autre pour améliorer la qualité des échanges sur plusieurs tours et l’efficacité du cache. Utilisez reasoning.context pour choisir le comportement souhaité. Découvrez comment conserver le raisonnement d’un appel à l’autre.
• Effort de raisonnement maximal : GPT-5.6 prend en charge le niveau d’effort max pour les tâches exigeantes qui nécessitent davantage d’exploration et de vérification. Si vous utilisez actuellement xhigh, comparez les deux réglages sur des charges de travail représentatives.
• Mode pro : GPT-5.6 peut consacrer davantage de calcul à une tâche difficile pour gagner en fiabilité et renvoyer une seule réponse finale. Activez ce mode avec reasoning.mode: "pro" lorsque la qualité prime sur la latence et la consommation de tokens. Découvrez comment utiliser le mode pro.
• Économie de tokens : GPT-5.6 atteint les performances d’un modèle phare avec moins de tokens de sortie.
• Conception d’interfaces : GPT-5.6 crée des sites et des applications plus soignés et plus faciles à utiliser grâce à de meilleurs choix de mise en page, de hiérarchie visuelle et de conception.
• Compréhension des intentions : GPT-5.6 déduit plus facilement du contexte l’objectif de l’utilisateur et l’ampleur du travail attendu. Vous n’avez donc souvent plus besoin de détailler chaque étape. Continuez à préciser le contexte métier, les contraintes impératives, les actions soumises à approbation et les critères de réussite. Indiquez au modèle dans quels cas une ambiguïté importante doit l’amener à poser une question.
• Niveau de détail d’origine des images : GPT-5.6 conserve les dimensions des images avec les niveaux de détail original ou auto. Si la largeur ou la hauteur dépasse 65 535 pixels, l’image est réduite pour respecter cette limite. L’API rejette les images qui dépassent encore la limite de 30 000 patchs sans les redimensionner davantage. Les grandes images peuvent consommer plus de tokens d’entrée et augmenter la latence. Découvrez comment choisir le niveau de détail d’une image.

Mesures de protection

Avec les modèles GPT-5.6, certaines requêtes peuvent être bloquées ou refusées. Des classifieurs analysent les sorties en temps réel pendant leur génération pour détecter les usages abusifs en cybersécurité et en biologie. D’autres requêtes peuvent prendre plus de temps si la génération s’interrompt en cours de réponse pendant quelques secondes, le temps que les classifieurs examinent les sorties de manière synchrone. Ces protections peuvent parfois intervenir lors de travaux légitimes, notamment dans les domaines à double usage où les activités défensives et offensives peuvent se ressembler au départ.

Si votre application s’adresse à des utilisateurs finaux individuels, envoyez avec chaque requête un identifiant safety_identifier stable qui préserve leur vie privée. Consultez la section Mettre en place des identifiants de sécurité pour savoir comment procéder.

Nous faisons évoluer ces protections en continu pour qu’elles résistent efficacement aux tentatives de contournement tout en permettant les travaux légitimes, comme la revue de code, la recherche de vulnérabilités, le développement de correctifs, le débogage, la formation à la sécurité et les tests défensifs.

Guide de migration rapide

Migrer avec Codex

Codex peut appliquer les changements recommandés dans ce guide à l’aide du skill OpenAI Docs.

$openai-docs faites migrer ce projet vers la famille de modèles GPT-5.6

Pour utiliser ce skill avec d’autres agents de programmation, téléchargez-le depuis le dépôt de skills d’OpenAI.

Mettre à jour les paramètres de l’API et du modèle

• Choisissez le modèle cible en fonction de votre charge de travail. Utilisez gpt-5.6-sol pour bénéficier des capacités les plus avancées, gpt-5.6-terra pour concilier intelligence et coût, ou gpt-5.6-luna pour traiter efficacement de grands volumes de requêtes. L’alias gpt-5.6 dirige les requêtes vers gpt-5.6-sol.
• Utilisez l’API Responses pour les workflows qui font appel au raisonnement, utilisent des outils ou se déroulent sur plusieurs tours.
• Choisissez la valeur de reasoning.effort en fonction de vos besoins. GPT-5.6 prend en charge none, low, medium, high, xhigh et max.
  • Si vous migrez depuis GPT-5.5 ou GPT-5.4, gardez votre niveau d’effort de raisonnement actuel comme référence, puis comparez-le au niveau immédiatement inférieur.
  • Si vous utilisez none, gardez ce réglage comme référence pour la latence. Testez aussi low si le raisonnement ou l’utilisation d’outils apporte un bénéfice au workflow.
  • Utilisez medium comme point de départ équilibré et low pour les charges de travail sensibles à la latence.
  • Utilisez high ou xhigh si vos mesures montrent qu’un effort de raisonnement accru améliore la qualité.
  • Réservez max aux charges de travail les plus difficiles pour lesquelles la qualité prime. Comparez max et xhigh pour trouver le meilleur compromis entre qualité, latence et coût pour votre cas d’usage.
• Pour utiliser le mode pro, gardez le modèle GPT-5.6 que vous avez choisi et réglez reasoning.mode sur pro dans l’API Responses. Ne passez pas à un slug de modèle Pro distinct. Choisissez reasoning.effort indépendamment du mode. Si vous omettez ce paramètre, GPT-5.6 utilise medium par défaut en mode standard comme en mode pro. La section sur le mode de raisonnement présente un exemple de requête et les modalités de facturation.
• Configurez la conservation du raisonnement selon la part du raisonnement antérieur qui reste pertinente. Les modèles GPT-5.6 utilisent all_turns par défaut, et les modèles antérieurs current_turn.
  • Omettez reasoning.context ou réglez-le sur auto pour utiliser all_turns, la valeur par défaut de GPT-5.6. Vérifiez le champ reasoning.context de la réponse pour confirmer le mode effectivement utilisé.
  • Réglez reasoning.context sur all_turns si les objectifs, les hypothèses et les priorités de la tâche restent stables d’un tour à l’autre.
  • Avec all_turns, poursuivez l’échange avec previous_response_id pour que le modèle ait accès au raisonnement des réponses précédentes.
  • Si vous gérez l’historique manuellement, conservez et renvoyez les entrées utilisateur précédentes ainsi que tous les éléments de sortie de chaque réponse. Avec store: false ou la politique de non-conservation des données, renvoyez les éléments de raisonnement chiffrés que l’API fournit par défaut.
  • Réglez reasoning.context sur current_turn lorsque le raisonnement antérieur n’est plus pertinent.
• Vérifiez la configuration de la mise en cache des prompts. Vous pouvez continuer à utiliser la mise en cache implicite sans modifier votre code. Avec GPT-5.6, les écritures dans le cache coûtent 1,25 fois le tarif des entrées non mises en cache. Suivez cached_tokens et cache_write_tokens pour évaluer le coût net. Utilisez des points de coupure explicites ou prompt_cache_options.mode: "explicit" pour éviter les écritures inutiles et remplacez prompt_cache_retention par prompt_cache_options.ttl.
• Pour utiliser les appels d’outils programmatiques, ajoutez l’outil programmatic_tool_calling et autorisez ces appels pour les outils éligibles avec allowed_callers. Adaptez votre application pour qu’elle traite les éléments program, les appels de fonction émis par le programme et les éléments program_output, tout en préservant le call_id de chaque appel et son lien avec caller. Le guide des appels d’outils programmatiques présente des exemples de requêtes initiales et de requêtes de suivi.
  • Évaluez les performances du workflow avec les appels d’outils programmatiques (PTC) sur des tâches représentatives. Comparez la réussite des tâches, l’exhaustivité des réponses finales, la présence des éléments de preuve requis, le nombre total de tokens, la latence et le coût. Une réduction du nombre d’appels, de tours ou de sorties intermédiaires ne constitue un progrès que si la réponse finale atteint toujours le niveau de qualité requis.

Bonnes pratiques pour rédiger des prompts

Privilégier des prompts plus concis

En éliminant les consignes et les exemples redondants et en simplifiant les descriptions des outils, vous pouvez améliorer les résultats tout en réduisant la consommation de tokens. Sur un échantillon d’évaluations internes d’agents de programmation, les configurations dotées de prompts système plus concis ont amélioré les scores d’environ 10 à 15 %, tout en réduisant le nombre total de tokens de 41 à 66 % et le coût de 33 à 67 %. Les résultats varient selon la charge de travail. Prenez ces chiffres comme des ordres de grandeur et validez vos changements sur des tâches représentatives de votre application.

Pour simplifier vos prompts tout en conservant les consignes importantes :

• Partez d’un prompt et d’un ensemble d’outils qui fonctionnent déjà. Supprimez un seul groupe de consignes, d’exemples ou d’outils à la fois, puis relancez les mêmes évaluations.
• Formulez chaque consigne une seule fois.
• Mettez à disposition uniquement les outils pertinents pour la tâche et donnez-en une description concise et précise.
• Conservez les exemples et les consignes de style qui traduisent une exigence produit ou corrigent une lacune constatée lors des évaluations.
• Suivez l’évolution du contexte dès le début de l’exécution et au fil de la conversation. Dans les longues sessions, les répétitions dans le prompt et les descriptions d’outils peuvent prendre de plus en plus de place.

Définir le degré d’autonomie et les actions soumises à approbation

GPT-5.6 peut prendre des initiatives et poursuivre des tâches en plusieurs étapes jusqu’à leur terme. Précisez quelles actions chaque requête autorise. Le modèle pourra ainsi poursuivre sans interruption inutile les travaux sûrs qui entrent dans le périmètre prévu et s’arrêter avant toute action externe, destructive, coûteuse ou qui élargirait ce périmètre.

Quelques règles suffisent généralement :

Si l’on vous demande une réponse, une explication, une revue, un diagnostic ou un plan,
examinez les éléments pertinents et communiquez le résultat. N’apportez de modifications
que si la demande le prévoit également.

Si l’on vous demande de modifier, de créer ou de corriger quelque chose, apportez les
modifications locales demandées dans le périmètre prévu et effectuez les vérifications
non destructives pertinentes sans demander d’autorisation préalable.

Obtenez une confirmation avant toute écriture dans un système externe, toute action
destructive, tout achat ou tout élargissement important du périmètre.

Énumérez explicitement les actions locales sûres, comme lire des fichiers, examiner des journaux, modifier le code concerné et exécuter des tests. Regroupez les règles au même endroit et formulez chacune une seule fois. Répéter des consignes comme « demandez d’abord », « ne modifiez rien » ou « attendez l’approbation » peut entraîner des demandes d’approbation inutiles pour des actions sûres et attendues.

Régler la longueur et le style des réponses

Par défaut, GPT-5.6 tend à répondre plus brièvement que GPT-5.5. Lors de la migration, vérifiez si des consignes générales comme « soyez concis » ou « faites court » restent utiles. Pour certaines tâches, elles sont superflues et peuvent donner des réponses trop brèves. Conservez-les si elles produisent de façon fiable le résultat dont votre application a besoin.

Pour obtenir un niveau de détail plus homogène d’une requête à l’autre, définissez-le par défaut avec text.verbosity, puis précisez dans le prompt les exigences propres à la tâche.

Définir un niveau de détail par défaut avec text.verbosity

Choisissez low, medium ou high comme niveau de détail par défaut de la requête. Dans le prompt, précisez les exigences de longueur, de structure ou de contenu propres à la tâche. La section Configurer text.verbosity présente un exemple d’appel à l’API.

Préciser le contenu indispensable d’une réponse courte

Si la tâche appelle une réponse courte, indiquez quelles informations le modèle doit conserver et quels détails il peut omettre. Par exemple :

Commencez par la conclusion. Présentez les éléments qui l’étayent, toute réserve
importante et la prochaine action à entreprendre. Écartez les détails secondaires
et les répétitions.

Conservez tous les faits, décisions, réserves et prochaines étapes indispensables.
Pour raccourcir la réponse, réduisez en priorité les introductions, les répétitions,
les formules rassurantes passe-partout et les éléments de contexte facultatifs.

Le modèle dispose ainsi d’un ordre de priorité clair : conserver les informations nécessaires pour mener la tâche à bien, puis supprimer les détails de moindre importance.

Définir le ton

Des qualificatifs généraux comme « amical » ou « empathique » peuvent prêter à interprétation. Décrivez les choix de rédaction qui caractérisent le ton de votre produit. Précisez par exemple dans quelle mesure la réponse doit être directe, quand reconnaître un problème et dans quels cas il convient de rassurer l’utilisateur ou d’ajouter une formule de fin.

Répondez directement. Si l’utilisateur signale un problème, reconnaissez le problème
précis qu’il décrit avant d’indiquer la prochaine étape. Rassurez-le uniquement si la
situation le justifie. Évitez les compliments passe-partout et les formules de fin
superflues.

Mode pro

Choisir le mode pro lorsque la qualité prime

Le mode pro est un mode d’exécution de l’API Responses dans lequel le modèle consacre davantage de calcul à une requête avant de renvoyer une seule réponse finale. Il peut améliorer la fiabilité sur les tâches difficiles, mais augmente la latence. Tous les tokens consommés lors de ce travail sont comptabilisés dans l’utilisation déclarée et facturés aux tarifs standard du modèle sélectionné.

Utilisez le mode pro lorsqu’un léger gain de qualité peut avoir un effet important sur le résultat et que la tâche est suffisamment difficile pour en bénéficier. C’est le cas, par exemple, pour une optimisation complexe, une tâche de programmation ou de revue de code à fort enjeu, ou une analyse approfondie assortie de critères d’évaluation clairs. Privilégiez le mode standard pour les tâches courantes, sensibles à la latence ou traitées en grand volume, ainsi que lorsque vos évaluations ne montrent aucun gain significatif en mode pro.

Le mode de raisonnement et l’effort de raisonnement se règlent indépendamment. Le mode pro fonctionne avec tous les modèles GPT-5.6 et tous les niveaux d’effort qu’ils prennent en charge. Commencez avec le modèle et le niveau d’effort qui vous servent de référence en mode standard, puis comparez les configurations sur des tâches représentatives, sans présumer que l’effort maximal offre toujours le meilleur compromis.

Configurer le mode pro dans l’API

Activez le mode pro dans la requête à l’API. Conservez le prompt centré sur le résultat que vous utilisez en mode standard : précisez l’objectif, le contexte pertinent, les contraintes, les éléments de preuve requis, les critères de réussite et le format de sortie. Vous n’avez pas besoin de demander au modèle d’« utiliser le mode pro », de « réfléchir davantage » ou de produire plusieurs réponses possibles.

Par exemple :

Examinez ce plan de migration de base de données pour repérer les défaillances
susceptibles d’entraîner une perte de données ou une interruption de service prolongée.
Pour chaque risque relevé, citez l’étape concernée, estimez son impact et sa probabilité,
puis recommandez une mesure d’atténuation précise. Présentez les cinq risques les plus
importants par ordre décroissant de gravité.

Comparer la qualité et le coût

Comparez les modes standard et pro sur les mêmes tâches représentatives. Mesurez la réussite des tâches, l’exhaustivité des réponses, la présence des éléments de preuve requis, le nombre total de tokens, la latence et le coût. Réservez le mode pro aux cas où le gain de qualité ou de fiabilité justifie le calcul supplémentaire.

Pour en savoir plus, consultez le guide du mode de raisonnement.

Appels d’outils programmatiques

Choisir les appels d’outils programmatiques selon la nature de la tâche

Les appels d’outils programmatiques (PTC) conviennent particulièrement aux workflows bien délimités dans lesquels du code peut traiter les résultats de plusieurs outils ou des sorties intermédiaires volumineuses pour renvoyer un résultat structuré beaucoup plus compact. Utilisez-les pour filtrer, joindre, classer, dédupliquer, agréger ou valider des données, ou pour effectuer d’autres traitements prévisibles.

Le seul fait que les appels soient multiples, parallèles ou dépendants les uns des autres ne justifie pas le recours aux appels d’outils programmatiques. Privilégiez les appels d’outils directs, sans PTC, dans les cas suivants :

• Un seul appel suffit
• Les sorties intermédiaires sont déjà de petite taille
• Chaque résultat peut influer sur la prochaine décision du modèle
• Une action nécessite une approbation
• La sortie finale doit conserver les citations ou les artefacts natifs

Adapter les consignes de choix du mode d’appel à la tâche

Pour que le modèle choisisse le bon mode d’appel, ne vous fiez pas à la seule disponibilité des outils ni à des consignes générales comme « utilisez efficacement les appels d’outils programmatiques ». Si les appels directs et programmatiques sont tous deux disponibles, précisez explicitement :

• L’étape bien délimitée qui doit utiliser les appels d’outils programmatiques.
• Les outils qu’il est permis d’appeler à cette étape.
• Le schéma de sortie exact et les éléments de preuve requis.
• Le nombre maximal d’appels simultanés, le nombre maximal de nouvelles tentatives et les conditions d’arrêt.
• Les tâches qui doivent continuer à utiliser des appels directs.

La description de chaque outil doit préciser les champs et les types renvoyés, ainsi que le comportement en cas d’erreur. Si le modèle ne peut pas déterminer la structure du résultat avant d’écrire le programme, privilégiez les appels d’outils directs pour qu’il puisse examiner le résultat avant de décider comment l’utiliser.

Si les deux modes d’appel sont nécessaires, définissez un point de transition unique et précis. Demandez au modèle de s’y tenir et de ne pas répéter le travail déjà effectué.

Par exemple :

<tool_orchestration>
Pour l’étape [bounded stage], utilisez les appels d’outils programmatiques avec les seuls
outils suivants : [eligible tools]. Exécutez les appels indépendants en parallèle lorsque
vous pouvez le faire sans risque. Utilisez uniquement les champs d’entrée et de sortie
documentés des outils.

Traitez les résultats intermédiaires et réduisez leur volume, puis renvoyez un résultat
qui respecte exactement le schéma [output schema] et qui contient les éléments de preuve
nécessaires à la réponse finale.

Arrêtez-vous dès que la condition [condition] est remplie. En cas d’échec temporaire,
réessayez au maximum [R] fois. Ne répétez pas les appels déjà terminés et n’effectuez
aucune action ayant des effets de bord. Si un résultat requis manque toujours, renvoyez
une description claire et structurée de l’échec.

Utilisez des appels d’outils directs pour [semantic judgment, approval, or final validation].
</tool_orchestration>

Évaluer la réponse finale

L’élément program_output et le message final de l’assistant sont deux sorties distinctes. Veillez à tester les deux. Un programme peut en effet renvoyer les bons enregistrements alors que le message omet un champ, une citation ou une réserve indispensable.

Comparez les appels directs et programmatiques sur les mêmes tâches représentatives. Vérifiez que la réponse finale est correcte, complète et qu’elle contient les éléments de preuve requis. Comparez ensuite le nombre total de tokens, la latence, le coût et le nombre d’appels, de tours et de nouvelles tentatives. Une baisse de la consommation de ressources ne constitue un progrès que si la réponse satisfait toujours aux critères de vos évaluations existantes.

Pour en savoir plus, consultez le guide des appels d’outils programmatiques.