ChatGPT Codex

Codex aujourd’hui

un agent, pas un assistant de saisie

La plupart des outils d’IA pour le code fonctionnent par-dessus l’épaule : le développeur tape, l’assistant suggère la suite, l’humain accepte ou refuse. Codex ne travaille pas ainsi. On lui décrit une tâche en français ou en anglais — corriger un comportement, ajouter une fonction, mettre à jour une dépendance —, il récupère une copie du projet dans un environnement isolé, modifie les fichiers concernés, lance les tests, recommence quand ça échoue, puis rend son travail sous une forme relisible.

Le déplacement est net. Avec un assistant de saisie, le développeur reste aux commandes ligne par ligne et voit tout passer. Avec un agent, il délègue une intention et récupère un résultat : moins de frappe, beaucoup plus de relecture. Le métier ne disparaît pas, il change de place.

Ce déplacement explique aussi à qui l’outil s’adresse. On peut parfaitement confier à Codex une tâche qu’on ne saurait pas écrire soi-même ; on ne peut pas valider ce qu’il rend sans savoir le lire. Un agent dont personne n’évalue le travail produit une dette invisible, pas un gain de temps.

Pourquoi le nom sème la confusion

Le même mot a désigné deux produits de nature totalement différente, à quatre ans d’intervalle. En 2021, OpenAI publie un modèle appelé Codex, dérivé de GPT-3 et entraîné sur du code public : il traduisait une phrase en instructions et servait de moteur aux premières versions de l’assistant de GitHub. Ce modèle a été retiré de l’accès par interface de programmation en 2023, ses capacités ayant été absorbées par les modèles généralistes.

Le nom est réapparu en 2025 pour tout autre chose : non plus un modèle qu’on interroge, mais un agent de développement logiciel qui exécute des tâches. D’où les contenus contradictoires qu’on croise encore, certains décrivant une brique technique disparue, d’autres un outil qui n’existait pas quand ils ont été rédigés.

Le repère utile tient en une ligne : si un article parle de Codex comme d’un modèle qu’on appelle pour compléter des lignes, il décrit l’ancien ; s’il parle d’un agent qui travaille sur un dépôt et soumet des contributions, il décrit l’actuel. Les modèles qui font tourner cet agent, eux, changent plusieurs fois par an, et les retenir n’a aucun intérêt pratique.

Ce qui se passe quand on lui confie une tâche

Le cycle est identique quelle que soit l’interface. L’agent obtient une copie du projet dans un environnement isolé, séparé de la machine de travail. Il explore l’arborescence, lit les fichiers pertinents, applique ses modifications, exécute la suite de tests si le projet en possède une, lit les erreurs, corrige, recommence. Cette boucle est ce qui le distingue d’un générateur : il ne se contente pas de produire du code, il le vérifie avec les outils du projet.

À la fin, il restitue un ensemble de modifications accompagné du détail de ce qu’il a fait et, généralement, des commandes exécutées. Sur un projet hébergé sur une forge, ce résultat peut prendre la forme d’une contribution que l’équipe relit comme n’importe quelle autre. Rien n’est intégré sans validation.

La qualité du résultat dépend fortement de celle du projet. Un dépôt doté de tests sérieux, d’une organisation lisible et d’un fichier de consignes à la racine — un document court qui décrit les commandes à utiliser, les conventions de code et ce qu’il ne faut pas toucher — donne des résultats nettement plus exploitables qu’un projet sans filet, où l’agent n’a aucun moyen de savoir s’il a cassé quelque chose.

Ce qui distingue une bonne demande

C’est le seul levier réellement entre les mains de l’utilisateur, et la cause première des déceptions. Une demande exploitable ressemble à une consigne donnée à un collègue qui débarque sur le projet : elle dit ce qu’il faut obtenir, où chercher, et comment on saura que c’est réussi.

Quatre portes d’entrée selon la façon dont on travaille

Depuis ChatGPT dans le navigateur, Codex s’utilise comme un espace de tâches : on connecte son dépôt, on décrit ce qu’on veut, on suit l’avancement, on relit. En ligne de commande, l’outil s’installe sur la machine et travaille dans le répertoire courant, avec un dialogue dans le terminal — la voie de ceux qui veulent garder la main sur ce que l’agent touche. Dans l’éditeur de code, une extension permet de lancer des tâches sans changer de fenêtre. Restent les applications, sur ordinateur et sur mobile, pensées pour suivre des tâches longues ou en lancer plusieurs en parallèle.

L’usage mobile n’a rien d’anecdotique : consulter l’avancement d’une tâche et valider une étape depuis un téléphone correspond bien à la nature asynchrone de l’outil, qui travaille souvent plusieurs minutes sans supervision.

Qui y a accès, et ce que consomme réellement l’usage

Codex n’est pas vendu séparément : l’accès est inclus dans les formules payantes de ChatGPT, avec des volumes d’usage croissants selon le niveau d’abonnement. Les offres et leurs seuils évoluent régulièrement, et toute page qui grave un quota précis vieillit mal ; la grille officielle reste la seule référence fiable au moment de souscrire.

Ce qui se consomme n’est pas un nombre de questions posées mais un volume de travail. Une tâche qui explore un gros dépôt, relance les tests plusieurs fois et corrige ses erreurs pèse bien plus lourd qu’une correction ponctuelle sur deux fichiers. Pour un usage occasionnel, la question du plafond se pose rarement ; elle devient concrète dès qu’une équipe fait tourner plusieurs tâches en parallèle toute la journée. Dans ce cas, mieux vaut observer sur quelques jours combien de tâches sont réellement lancées, et de quelle ampleur, avant de généraliser l’outil.

Ce qu’il faut vérifier avant de le laisser travailler seul

Le périmètre se tranche avant la première tâche. L’agent voit ce qu’on lui donne : un dépôt entier ou un sous-ensemble. Sur un projet contenant des données sensibles, des configurations de production ou du code soumis à des obligations contractuelles, la question mérite une réponse écrite plutôt qu’un réglage pris à la volée.

Viennent ensuite les secrets. Clés d’interface de programmation, jetons d’accès et mots de passe de bases de données n’ont rien à faire dans un dépôt, et cette règle ancienne devient critique dès qu’un agent le parcourt et exécute du code. Un audit rapide des fichiers de configuration et de l’historique évite d’exposer ce qui n’aurait jamais dû s’y trouver.

L’accès au réseau depuis l’environnement d’exécution mérite une décision explicite. Le couper limite les effets de bord et les téléchargements imprévus, au prix de l’impossibilité d’installer une dépendance manquante. Le critère est simple : réseau ouvert pour une tâche qui suppose d’installer ou de mettre à jour des paquets, réseau fermé pour tout le reste, en particulier sur un dépôt sensible.