GPT-5.3-Codex : contexte, prix et limites du modèle

Les erreurs corrigées dans cet ancien guide

La version précédente parlait de 256K tokens, présentait l’accès API comme encore à venir et employait une formulation de « modèle le plus puissant » sans date ni réserve. Ces formulations ont été retirées. Les prix API ne décrivent pas le coût d’un abonnement à une application et un score de lancement ne décrit pas tous les usages actuels.

Nous ne publions pas un faux essai personnel. Les caractéristiques viennent de la source officielle ; la méthode, l’exercice et son corrigé ci-dessous sont des propositions pédagogiques LearnIA. Aucun appel payant à un modèle n’est nécessaire pour les lire ou les compléter.

Modèle, agent et environnement : trois niveaux à séparer

Le modèle produit une réponse dans un contexte. L’agent organise les lectures, modifications et commandes. L’environnement détermine les fichiers disponibles, les dépendances installées, l’accès réseau et les tests réellement exécutables. Une différence entre deux démonstrations peut venir de chacun de ces niveaux.

Avant d’attribuer une réussite au seul modèle, relevez donc l’identifiant exact, les instructions, les outils autorisés et le dépôt de départ. Un correctif accompagné de « tests OK » reste insuffisant si le rapport ne donne ni commande ni résultat.

Comment lire un benchmark sans en faire un classement universel

Un tableau utile conserve le nom du test, sa version, la date, l’agent utilisé, les outils, le budget et les tentatives autorisées. Deux pourcentages perdent leur sens comparatif si ces conditions diffèrent. Consultez les protocoles de SWE-bench et de Terminal-Bench avant de rapprocher leurs résultats : ce sont des évaluations distinctes.

Le protocole LearnIA proposé est plus modeste : quelques tâches représentatives de votre travail, les mêmes sources et des critères écrits avant la réponse. Il sert à sélectionner un outil pour votre contexte. Il ne produit pas une estimation statistique de la performance mondiale du modèle. Notre guide de lecture des benchmarks détaille ces limites.

Atelier : repérer un correctif qui supprime la règle métier

Cas fictif : une commande nécessite une approbation et doit rester sous un plafond. Le code à examiner est :

function canSubmit(order, limit) {
  return order.approved || order.total <= limit;
}

Règle attendue : les deux conditions doivent être vraies. Le défaut est l’opérateur « ou ». Une commande approuvée dépasse le plafond sans être bloquée ; une commande non approuvée passe si son total est assez faible.

Le correctif minimal remplace « ou » par « et ». Mais un changement de code seul ne suffit pas : les quatre cas doivent être vérifiés. Ajoutez ensuite le cas limite total égal au plafond, en précisant que la règle autorise cette égalité. Les entrées invalides sont une décision de contrat à traiter explicitement, pas une raison de modifier silencieusement le périmètre.

Sur un exemple fictif, corrige uniquement la règle suivante : une commande peut partir si elle est approuvée ET si son total ne dépasse pas le plafond. Donne le cas qui échoue avant correction, la modification minimale et les quatre cas de la table de vérité. Sépare les tests proposés des tests réellement exécutés. N’ajoute ni dépendance ni appel externe.

Donner une consigne qui facilite la vérification

Une consigne exploitable indique le comportement observé, le comportement attendu, les fichiers autorisés et les critères d’acceptation. « Améliore ce code » invite à élargir le travail ; « corrige cet opérateur sans changer le contrat » permet de contrôler le résultat.

Demandez une explication courte de la cause, le diff et les limites restantes. Évitez de noter une réponse sur sa longueur ou son assurance. Si l’assistant ajoute un contournement pour faire passer le test, relisez le test et la règle ensemble.

Décider de conserver ou remplacer cette version

Pour un flux existant, inventoriez les tâches qui dépendent de cette version et gardez leurs cas de régression. Pour un nouvel usage, examinez les modèles actuellement accessibles, les conditions de données et le coût total. Une migration doit être jugée sur les mêmes tâches, avec un résultat relu, et non sur un nom plus récent.

Vous pouvez préparer ce dossier sans dépenser : spécifications fictives, grille de correction et tableaux de résultats vierges. N’écrivez « testé » qu’après une exécution conservée. Pour comparer les environnements, poursuivez avec Claude Code, Copilot et Cursor ; pour apprendre la méthode, ouvrez le guide des agents IA.