La famille de modèles OpenAI : GPT, modèles de raisonnement, et quand utiliser chacun

OpenAI livre deux types de comportement fondamentalement différents sous un même toit : la réponse générale rapide, et le raisonnement délibéré qui réfléchit avant de répondre. Choisir le mauvais mode vous coûte soit de l'argent, soit de la précision. Cette leçon porte sur le routage : associer la tâche au modèle (ou au niveau de raisonnement) pour arrarrL'Annual Recurring Revenue (ARR) est le revenu normalisé et prévisible qu'une entreprise par abonnement attend de ses contrats actifs sur une année.Voir la définition complète →êter de surpayer le travail trivial et de sous-dimensionner le travail difficile.

Deux comportements, qui convergent vers un seul produit

Historiquement, OpenAI avait séparé les deux en deux gammes nommées : les modèles GPT « chat » (GPT-4o et compagnie) et les modèles de raisonnement de la série « o » (o3, o4-mini). Avec la famille GPT-5, cette séparation s'est largement effondrée en un seul modèle qui décide de l'intensité de sa réflexion, mais le compromis sous-jacent est exactement le même, donc la logique de routage ci-dessous tient toujours.

La réponse générale rapide est optimisée pour la largeur et la latence. Vous envoyez un prompt, les tokenstokensUn token est l'unité de base de texte que traitent les modèles de langage : le plus souvent un fragment de mot, un mot entier ou un signe de ponctuation, plutôt qu'un simple caractère.Voir la définition complète → reviennent en streaming presque immédiatement. Ce mode est excellent pour la rédaction, le résumé, la classification, la mise en forme, la complétion de code et la conversation.

Le raisonnement dépense du calcul caché supplémentaire pour travailler un problème avant d'émettre la réponse finale. Ce travail caché s'appelle les *reasoning tokens* : des étapes internes que vous payez et que vous ne voyez jamais. Il échange de la latence et du coût contre de la précision sur les problèmes à plusieurs étapes : mathématiques, débogage difficile, planification, analyse scientifique, et tout ce où une étape intermédiaire fausse ruine le résultat.

La famille existe aussi en variantes plus petites (paliers mini et nano). Même profil de capacité générale, coût plus faible, latence plus faible, profondeur légèrement moindre. Un modèle `mini` avec le raisonnement poussé « réfléchit » quand même, simplement à moindre coût.

La carte officielle de qui est qui et de ce pour quoi chacun est réglé se trouve dans la documentation des modèles. Consultez-la quand les noms changent ; la logique de routage ci-dessous, elle, ne change pas.

La décision de routage en une question

Demandez-vous : cette tâche comporte-t-elle une chaîne d'étapes vérifiable où une erreur précoce casse le résultat ?

• Non → réponse générale rapide. Réécritures, changements de ton, rédaction, extraction, résumé, questions-réponses simples, discussion informelle.
• Oui → poussez le raisonnement. Analyse sous contraintes multiples, preuves mathématiques, chasses aux bugs ambigus, synthèse multi-documents avec de la logique, planification d'une séquence d'actions.

Posez ensuite une seconde question pour le coût : s'agit-il d'un gros volume ou d'un usage sensible à la latence ? Si oui, descendez vers une variante `mini`/`nano`.

Exemple concret : réécriture vs analyse

Tâche A : « Réécris ce paragraphe pour qu'il soit plus concis et plus affirmé. »

C'est une transformation en un coup. Il n'y a pas de chaîne à rater. Gardez le raisonnement bas (ou désactivé) et laissez-le répondre vite.

from openai import OpenAI
client = OpenAI()

resp = client.responses.create(
    model="gpt-5",
    reasoning={"effort": "minimal"},
    input="Rewrite to be concise and confident:\n\n" + paragraph,
)
print(resp.output_text)

Tâche B : « Voici trois contrats fournisseurs. Trouve chaque clause où les conditions de renouvellement se contredisent, et dis-moi quel contrat l'emporte selon les règles de préséance de la section 12. »

C'est du multi-étapes : extraire les clauses, les comparer, appliquer la logique de préséance, résoudre les conflits. Une mauvaise lecture initiale se propage. Poussez le raisonnement et laissez-le dépenser des tokens.

resp = client.responses.create(
    model="gpt-5",
    reasoning={"effort": "high"},
    input=contracts_text + "\n\nFind conflicting renewal clauses and resolve per section 12.",
)
print(resp.output_text)

Deux choses à noter. D'abord, les deux appels utilisent la Responses APIAPIApplication Programming Interface : une interface standardisée qui permet aux applications de communiquer et d'échanger des données sans connaître leur fonctionnement interne respectif.Voir la définition complète → (responses.create), l'interface principale actuelle d'OpenAI. Ensuite, le curseur `reasoning.effort` (`minimal` / `low` / `medium` / `high`) échange de la profondeur contre du coût et de la latence. Sur la famille GPT-5, c'est votre levier principal : même modèle, quantité de réflexion différente. Si vous visez encore un ancien modèle de raisonnement comme o3 ou o4-mini, le même paramètre s'applique, même si ce sont désormais des choix legacy dans la plupart des workflows.

Dans ChatGPT : le sélecteur en clair

Dans les applications ChatGPT, le défaut est maintenant un modèle GPT-5 unique qui fait de l'auto-routage : il décide en interne s'il répond vite ou s'il réfléchit davantage. Vous gardez un contrôle manuel :

• Le mode par défaut couvre à peu près 80 % du travail quotidien sans que vous touchiez à quoi que ce soit.
• Une option Thinking explicite force le raisonnement délibéré. Basculez dessus quand une réponse rapide revient systématiquement superficielle ou subtilement fausse.
• Quand l'auto-routage est actif, votre vrai levier est le prompt (« réfléchis soigneusement et vérifie chaque étape ») plutôt qu'un menu déroulant, car le modèle y lit un signal pour dépenser plus de raisonnement.

Les anciens noms de la série o (o3, o4-mini) peuvent encore apparaître dans des menus legacy ou avancés pour certains plans, mais la famille GPT-5 est la voie par défaut pour la suite.

Une habitude pratique : commencez rapide, escaladez vers le thinking explicite seulement quand vous prenez le modèle en flagrant délit de saut logique. Le thinking coûte plus cher et est plus lent, donc n'en faites pas votre défaut.

Là où cela croise les fonctionnalités de ChatGPT

Le choix du modèle, ou l'intensité de réflexion que vous lui demandez, change le comportement du reste de la boîte à outils ChatGPT.

Advanced Data Analysis (Code Interpreter). Quand vous chargez un CSV et demandez une analyse, le modèle écrit et exécute du Python dans un sandbox. Un effort de raisonnement élevé est bien meilleur pour planifier une analyse multi-étapes correcte (nettoyer, joindre, agréger, valider) avant d'écrire le code. Une réponse rapide suffit pour « fais-moi un histogramme rapide ».

Canvas. Pour la rédaction longue et le code que vous éditez côte à côte, la réponse rapide garde la boucle serrée. **Poussez le raisonnement seulement quand le *contenu lui-même* exige de la logique dure**, comme dériver un algorithme.

Custom GPTs et Projects. Vos instructions personnalisées et la mémoire façonnent le comportement dans les deux cas, mais un modèle qui réfléchit davantage suivra des instructions à plusieurs volets de manière plus fiable, parce qu'il peut planifier autour d'elles. Si votre Custom GPT ignore sans cesse la contrainte n° 4 sur 6, le niveau de raisonnement est peut-être le goulot d'étranglement.

L'agent ChatGPT et les tâches planifiées. Le travail autonome multi-étapes (naviguer, cliquer, synthétiser) s'appuie par conception sur un raisonnement plus lourd, parce que chaque étape dépend de la précédente.

Coût et latence : le vrai compromis

Les détails de tarification changent, donc raisonnez qualitativement (les chiffres à jour sont sur la page pricing) :

• Le raisonnement coûte plus par tâche que ne le suggère le tarif au token, parce qu'il génère des reasoning tokens invisibles en plus de la réponse visible. Un effort élevé sur un problème difficile peut coûter plusieurs fois le prix d'une réponse rapide sur un problème facile.
• Les variantes mini/nano existent précisément pour que vous puissiez faire tourner du raisonnement à l'échelle sans explosion des coûts. Pour la classification en batch de 100 000 tickets de support, un modèle mini est presque toujours le bon choix face au modèle phare.
• La latence suit le même axe. Un effort de raisonnement élevé donne une impressionimpressionLe nombre total de fois qu'une publicité ou un contenu est affiché, indépendamment des clics. Chaque affichage compte pour une impression, même auprès de la même personne.Voir la définition complète → de lenteur parce que le modèle réfléchit. C'est le but, pas un bug. Ne le mettez pas derrière une UI qui exige des réponses en moins d'une seconde, sauf si vous plafonnez effort à minimal ou low.

Une règle interne simple pour les équipes : par défaut, réponse rapide, effort de raisonnement élevé autorisé sur une allowlist explicite de types de tâches, et réservez le modèle phare à effort élevé pour le travail à faible volume et fort enjeu.

Le raisonnement change la façon de prompter

Dès que vous poussez le raisonnement, votre style de prompt doit changer, sinon vous gâchez sa force.

Arrêtez de lui tenir la main sur les étapes. Avec la réponse rapide, on ajoute souvent « réfléchis étape par étape ». Un modèle qui raisonne déjà en interne le fait de lui-même, et détailler les étapes peut en réalité le contraindre. À la place, énoncez l'objectif, les contraintes et les critères de succès, puis laissez-le travailler.

Prompt faible quand le raisonnement est élevé :

D'abord liste les clauses. Puis compare-les. Puis applique la section 12. Puis conclus.

Plus fort :

Résous tous les conflits de conditions de renouvellement entre ces contrats. Succès = chaque conflit identifié avec le contrat prévalant nommé et la règle de la section 12 qui le tranche. Signale tout ce qui est ambigu plutôt que de deviner.

Donnez-lui de l'espace et une ligne d'arrivée claire. Un modèle de raisonnement récompense une définition nette de « terminé » et des instructions explicites sur l'incertitude (« signale, ne devine pas »). Il respecte aussi bien les sorties structurées, donc associez-le à un schéma JSON quand la réponse alimente un autre système.

schema = {
    "name": "conflict_report",
    "schema": {
        "type": "object",
        "properties": {
            "conflicts": {
                "type": "array",
                "items": {
                    "type": "object",
                    "properties": {
                        "clause": {"type": "string"},
                        "winning_contract": {"type": "string"},
                        "rule": {"type": "string"},
                    },
                    "required": ["clause", "winning_contract", "rule"],
                    "additionalProperties": False,
                },
            }
        },
        "required": ["conflicts"],
        "additionalProperties": False,
    },
    "strict": True,
}

resp = client.responses.create(
    model="gpt-5",
    reasoning={"effort": "high"},
    input=contracts_text + "\n\nReturn the conflict report.",
    text={"format": {"type": "json_schema", **schema}},
)

strict: True garantit que le modèle renvoie exactement cette forme, ce qui compte surtout quand la sortie alimente du code en aval.

Le raisonnement à l'intérieur des agents

Quand vous construisez avec l'Agents SDK ou que vous branchez du function calling, le compromis se projette proprement sur les rôles :

• Le planner (qui décide quels outils appeler et dans quel ordre) bénéficie d'un effort de raisonnement élevé. La sélection d'outils est exactement le genre de décision multi-étapes qu'il gère bien.
• Les workers (un outil qui résume une page récupérée, formate un résultat, rédige une réponse) peuvent tourner en rapide ou sur un modèle mini moins cher. Ils font des tâches étroites, en un coup.

Cette répartition garde un agent à la fois intelligent et abordable : réfléchir fort à *quoi faire*, agir à bas coût sur *chaque étape*. Un anti-pattern courant consiste à faire tourner le modèle phare à effort élevé pour chaque appel d'outil, ce qui rend les agents lents et chers sans gain de précision.

Une checklist mentale rapide

Avant chaque tâche non triviale, passez ceci :

1. Chaîne d'étapes dépendantes ? → montez l'effort de raisonnement. Transformation unique ? → restez rapide.
2. Gros volume ou besoin de vitesse ? → descendez vers mini/nano.
3. La sortie alimente du code ou un autre outil ? → ajoutez des sorties structurées.
4. Raisonnement poussé ? → énoncez objectif + contraintes + « terminé », pas les étapes.
5. Vous construisez un agent ? → raisonner fort pour planifier, agir vite pour exécuter.

Points clés

• Routez selon la structure, pas selon le battage. Une transformation unique doit répondre vite ; une chaîne d'étapes dépendantes où une erreur casse le résultat doit raisonner davantage. Sur la famille GPT-5, c'est le curseur reasoning.effort plutôt qu'un modèle séparé.
• Les variantes mini/nano sont votre levier de coût. Pour le travail à gros volume ou sensible à la latence, un modèle plus petit au bon niveau d'effort bat le modèle phare à chaque fois.
• Le raisonnement coûte plus par tâche que ne l'implique le tarif au token, à cause des reasoning tokens invisibles. Par défaut le rapide, escaladez délibérément, et plafonnez effort quand la latence compte.
• Promptez différemment quand le raisonnement est élevé : donnez l'objectif, les contraintes et une définition de « terminé », et dites-lui de signaler l'incertitude plutôt que de deviner. Oubliez le « étape par étape » manuel.
• Dans les agents, répartissez les rôles : effort élevé pour planifier, modèles rapides pour les appels d'outils individuels. Associez la sortie de raisonnement à des sorties structurées dès qu'elle alimente d'autre code.