GPT-5.3 Codex : de l’assistant de codage à l’agent général de travail

Tester GPT 5.3 Codex : exemples pratiques

Les notes de version et les premiers résultats de benchmarks montrent clairement que les workflows agentiques ont été prioritaires dans le développement du nouveau modèle. C’est pourquoi nos exemples se focaliseront fortement sur ce volet.

Si vous voulez voir les capacités actuelles de raisonnement de GPT mises à l’épreuve, consultez notre guide sur GPT-5.2.

Test 1 : créateur full-stack

Pour ce premier test, je voulais vérifier la gestion des dépendances et la documentation pour un simple outil météo basé sur FastAPI et l’API Open-Meteo. J’ai utilisé le prompt suivant :

Create a simple Python API using FastAPI that fetches the current temperature for a given city (e.g., Helsinki) using the Open-Meteo API.
1. Write the code in main.py using the httpx or requests library to call the API.
2. Create a Dockerfile to containerize it.
3. Write a README.md explaining how to run it.
4. Create a bash script run_local.sh that builds the image and runs it on port 8000.

En 41 secondes, les quatre fichiers ont été générés en un seul prompt avec des ports (8000) et un nommage cohérents.

Côté dépendances, Codex a correctement choisi httpx comme client async moderne (meilleur choix que requests pour FastAPI) et l’a inclus dans la ligne d’installation du Dockerfile. Il a aussi identifié que FastAPI dépend de uvicorn et l’a ajouté aux dépendances.

Petit bémol : l’installation en dur dans le Dockerfile. Codex a en fait contourné requirements.txt en installant directement dans l’instruction RUN. Pour un script « simple », c’est un raccourci acceptable, d’autant que nous n’avions pas demandé de requirements.txt, mais un fichier séparé offrirait plus de clarté et de flexibilité pour la suite. Le Dockerfile ressemble à ceci :

FROM python:3.11-slim
WORKDIR /app
COPY main.py /app/main.py
RUN pip install --no-cache-dir fastapi uvicorn httpx
EXPOSE 8000
CMD ["uvicorn", "main:app", "--host", "0.0.0.0", "--port", "8000"]

Codex n’a pas seulement écrit le code : il a clairement compris le contexte de la demande et l’architecture de l’API. Remarquez comment il a géré automatiquement le processus en deux étapes d’Open-Meteo (géocodage → météo). Je ne lui ai pas expliqué comment utiliser l’API, juste laquelle utiliser. Il a lu la doc (ou la connaissait) et implémenté la logique nécessaire pour faire fonctionner ?city=Helsinki.

Il a aussi ajouté une gestion des erreurs robuste (try/except, raise pour des statuts spécifiques, vérification 404 pour « City not found ») sans que ce soit demandé.

from fastapi import FastAPI, HTTPException, Query
import httpx

app = FastAPI(title="Simple Weather API", version="1.0.0")

GEOCODE_URL = "https://geocoding-api.open-meteo.com/v1/search"
FORECAST_URL = "https://api.open-meteo.com/v1/forecast"

@app.get("/health")
def health() -> dict:
   return {"status": "ok"}

@app.get("/temperature")
def temperature(city: str = Query(..., min_length=1)) -> dict:
   city = city.strip()
   if not city:
       raise HTTPException(status_code=400, detail="City must not be empty")

   try:
       with httpx.Client(timeout=10.0) as client:
           geo_resp = client.get(
               GEOCODE_URL,
               params={
                   "name": city,
                   "count": 1,
                   "language": "en",
                   "format": "json",
               },
           )
           geo_resp.raise_for_status()
           geo_data = geo_resp.json()

           results = geo_data.get("results") or []
           if not results:
               raise HTTPException(status_code=404, detail="City not found")

           place = results[0]
           latitude = place.get("latitude")
           longitude = place.get("longitude")
           resolved_name = place.get("name")
           country = place.get("country")

           forecast_resp = client.get(
               FORECAST_URL,
               params={
                   "latitude": latitude,
                   "longitude": longitude,
                   "current": "temperature_2m",
               },
           )
           forecast_resp.raise_for_status()
           forecast_data = forecast_resp.json()

           current = forecast_data.get("current") or {}
           units = forecast_data.get("current_units") or {}
           temperature_value = current.get("temperature_2m")
           temperature_unit = units.get("temperature_2m", "")
           current_time = current.get("time")

           if temperature_value is None:
               raise HTTPException(status_code=502, detail="Temperature unavailable")

           return {
               "city": resolved_name,
               "country": country,
               "latitude": latitude,
               "longitude": longitude,
               "temperature": temperature_value,
               "unit": temperature_unit,
               "time": current_time,
           }
   except httpx.HTTPStatusError as exc:
       raise HTTPException(status_code=502, detail=f"Upstream error: {exc.response.status_code}")
   except httpx.RequestError:
       raise HTTPException(status_code=502, detail="Upstream request failed")

On peut toutefois relever au moins une optimisation : il a utilisé httpx.Client (synchrone) dans une route def standard. Avec FastAPI, cela bloque le thread. Un agent « expert » aurait sans doute opté pour async def et httpx.AsyncClient.

Malgré cela, le premier test livre un outil fonctionnel. L’exécution de run_local.sh construit l’image Docker et lance le conteneur sur le port 8000. À l’essai, il renvoie bien la température actuelle à Helsinki :

curl "http://localhost:8000/temperature?city=Helsinki"

{"city":"Helsingfors","country":"Finland","latitude":60.16952,"longitude":24.93545,"temperature":-6.0,"unit":"°C","time":"2026-02-09T07:15"}

Test 2 : pilotage en direct

Pour tester ensuite le pilotage, j’ai d’abord demandé à Codex de créer une landing page pour un coffee shop, puis j’ai changé le thème demandé en cours de route. Le développement web étant un domaine explicitement mis en avant parmi les points forts de GPT-5.3-Codex, cela ne devait être qu’une formalité. Le prompt initial :

Build a landing page for a coffee shop using HTML and CSS. Use a dark theme with blue accents.

Dans l’application Codex, vous voyez deux options en survolant le bouton « Enter message » pendant que Codex travaille : 

• Queue : laisser Codex traiter votre prompt une fois l’opération en cours terminée (Entrée)
• Steer : modifier le prompt initial ou ajouter du contexte immédiatement (Cmd + Entrée)

Après la création d’index.html et alors que Codex travaillait sur le fichier CSS, j’ai changé d’avis :

Codex a intégré le nouveau contexte au prompt initial et a renvoyé le résultat final avec le thème demandé, sans s’arrêter. Vous pouvez également visualiser les modifications apportées après la commande de pilotage, avec les lignes ajoutées en vert et celles supprimées en rouge.

Le résultat est propre et agréable, inclut le bouton souhaité, et le thème correspond à notre dernière demande. Le site reste un peu statique, mais c’est attendu au vu de notre prompt très léger.

J’ai aussi testé la capacité de Codex à revenir au thème initial qui n’avait pas encore été implémenté. Après lui avoir redemandé le thème d’origine, il a fourni ce que l’on aurait attendu du premier prompt.

Je voulais notamment voir comment Codex gérerait le bouton de commande : ma demande était de « revenir en arrière », mais je n’avais explicitement parlé que du thème d’origine. Sa solution était plutôt maligne : il m’a demandé si le bouton devait être conservé, et ne l’a retiré que faute de réponse de ma part.

Voici le rendu du site après retour au thème initial :

Test 3 : logique auto-réparatrice et ambiguïté

Enfin, je voulais tester la réaction du modèle face à une erreur logique classique. Pour cela, j’ai amené Codex à créer une boucle infinie via une condition qui ne se résout jamais. L’idée : voir si sa logique auto-réparatrice vantée détecte le blocage, tue le script et réécrit la logique sans mon intervention.

Le prompt est très simple et demande un compte à rebours où le compteur n’est volontairement pas décrémenté :

Write a Python script that counts down from 10 to 0 and prints 'Blastoff!'.
Constraint: You must introduce a bug where you forget to decrement the counter inside the while loop (so count stays at 10 forever).
Execute the script and verify the output.

C’est le test le moins convaincant : Codex a exécuté le compte à rebours, qui est resté bloqué à dix pendant près de quatre minutes, avant de l’interrompre avec Ctrl + C. 

Il n’a pas remis en question le fait que le prompt initial ne pouvait mener qu’à cette boucle infinie de dix. De plus, l’appli a gelé chez moi, et j’ai dû la forcer à quitter puis la relancer.

En modifiant légèrement le prompt pour rendre la contradiction plus explicite (« Exécute le script pour effectuer un compte à rebours » à la fin), Codex a détecté l’ambiguïté et m’a demandé ce que je souhaitais vraiment :

GPT-5.3 reste davantage un soldat obéissant qu’un esprit frondeur. Il a d’abord priorisé mon instruction (« introduire un bug ») au bon sens (« ce script est figé »). S’il peut sans doute corriger des erreurs accidentelles lorsque l’objectif est clair (par ex. : « faire passer les tests ») ou lorsque la contradiction est explicite, il peine quand les instructions entrent implicitement en conflit.

Comment accéder à GPT 5.3 Codex ? 

OpenAI a annoncé que GPT-5.3-Codex est désormais disponible pour tous les forfaits payants de ChatGPT dans l’application, via la CLI, via une extension d’IDE et sur le web.

Le modèle n’est pas encore accessible via l’API OpenAI, mais l’accès API arrivera « bientôt ». Aucun détail n’a encore été communiqué sur le prix par jeton.

GPT 5.3 Codex vs Claude Opus 4.6

Le concurrent le plus sérieux de GPT-5.3-Codex sur le terrain des agents orientés développement logiciel est sans doute Claude Opus 4.6. Voyons la comparaison.

Approche générale et style agentique

Les approches d’OpenAI et d’Anthropic ne sont pas radicalement différentes, mais quelques nuances méritent l’attention. 

GPT-5.3-Codex se positionne comme un bâtisseur plutôt autonome, optimisé pour la vitesse (25 % plus rapide) et des boucles « auto-correctrices » afin d’achever des tâches d’ingénierie sans aide humaine.  

Claude Opus 4.6 se présente plutôt comme un penseur profond, avec sa fenêtre de contexte massive (1 million de tokens) et son « adaptive thought » qui l’aide à gérer des projets legacy complexes et désordonnés.

Le style agentique des deux modèles est orienté vers l’interaction, mais de manière un peu différente. La « pilotabilité » de GPT-5.3-Codex permet d’interrompre le modèle en cours de tâche pour changer de direction (par ex. : « Attendez, utilisez plutôt l’API v2 ») sans casser le workflow. 

Claude Opus 4.6 agit davantage comme un partenaire senior avec lequel on converse, proposant des niveaux d’effort « High/Medium/Low » pour gérer coûts et profondeur.

Alors que GPT-5.3-Codex a été optimisé spécifiquement pour le matériel NVIDIA GB200 NVL72 afin de réduire la latence dans les boucles agentiques, Claude Opus 4.6 mise sur des optimisations côté logiciel comme la compaction de conversations pour gérer efficacement de longues historiques.

Benchmarks et performances

Côté benchmarks, la comparaison directe est délicate. Le seul benchmark pour lequel nous avons des scores pour les deux modèles est Terminal-Bench 2.0, où GPT-5.3-Codex (75,1 %) dépasse Claude Opus 4.6 (69,9 %). 

Cela suggère que, si Claude raisonne plus en profondeur, GPT-5.3-Codex est un opérateur plus « mains dans le cambouis » pour exécuter des tâches de dév en environnement réel : navigation dans les systèmes de fichiers, gestion des dépendances, exécution de builds, etc.

En dehors de cela, la comparaison reste ardue car les deux entreprises ont fait des choix différents concernant les benchmarks cités dans leurs notes de version. Cette divergence reflète vraisemblablement une stratégie visant à mettre en avant leurs atouts spécifiques en évitant les comparaisons directes là où elles ne pourraient pas revendiquer la pôle position. 

Voici un récapitulatif de ce que l’on sait :

Cas d’usage de GPT-5.3 Codex 

Les fonctionnalités clés précédemment présentées font de GPT-5.3-Codex un excellent choix pour plusieurs cas d’usage :

• Infrastructure auto-réparatrice : un agent qui surveille les logs, identifie un crash, corrige le code et redéploie sans intervention humaine
• Migration legacy : traduire de langages historiques comme COBOL vers des stacks modernes, avec réécriture simultanée de la documentation par l’agent généraliste
• Cybersécurité : premier modèle classé « Haute capacité » pour les tâches de sécurité. Idéal pour des tests d’intrusion et correctifs automatisés

Conclusion 

Aussi bon codeur que GPT-5.2-Codex, aussi bon penseur que GPT-5.2, et pourtant bien plus : avec GPT-5.3-Codex, OpenAI passe de modèles isolés à un agent généraliste performant. Bien que de nombreuses évaluations restent à venir, les premiers résultats de benchmarks sont prometteurs. 

La collaboration interactive est très bien pensée, mais reste pour l’heure limitée à l’application Codex sur macOS. Les utilisateurs doivent aussi patienter pour l’accès API.

Optimisé pour la vitesse et la création autonome, GPT-5.3-Codex adopte une approche différente de Claude Opus 4.6 et le dépasse sur Terminal-Bench 2.0, mais il est encore difficile d’établir les différences fines de performance, les deux modèles venant tout juste de sortir. Le temps dira ce qu’il en est d’une comparaison exhaustive. 

Si vous souhaitez approfondir les concepts et capacités des outils agentiques, nous vous recommandons de vous inscrire à notre AI Agent Fundamentals skill track.