Votre premier task Codex

Leçon corrigée le 3 novembre 2026 d’après la référence des commandes de Codex (CLI 0.166.0) : les options --show-diff et --apply n’existent pas. En local, Codex modifie directement les fichiers dans son bac à sable ; on relit avec /diff ou git diff. La commande de l’extension « Codex: New Task » est remplacée par Codex: Open Codex Sidebar. Sources : Developer commands · Codex IDE extension.

Lancer votre première tâche

Le compte est configuré, GitHub est connecté, AGENTS.md est en place : il est temps de voir l’agent au travail. Un conseil vaut ici pour tous les niveaux — commencez par une tâche dont vous connaissez déjà la bonne réponse. Vous n’apprendrez rien en regardant Codex résoudre un problème que vous ne savez pas juger, alors que vous apprendrez énormément à le voir opérer sur un terrain que vous maîtrisez.

Depuis Codex Cloud

Sur le web ou dans l’application de bureau, choisissez Work in › Cloud, sélectionnez l’environnement publié pour votre dépôt (leçon 2), puis tapez la tâche dans le champ de saisie. Quelque chose de délibérément modeste fait très bien l’affaire.

Tâche : "Ajoute un fichier .gitignore adapté à un projet 
         Node.js/TypeScript si ce n'est pas déjà fait."

Cette formulation contient une condition — « si ce n’est pas déjà fait » — et c’est précisément ce qui la rend intéressante à observer. Dans Codex Cloud, la tâche s’exécute dans l’environnement que vous avez publié pour ce dépôt : Codex vérifie si un .gitignore existe, contrôle le cas échéant qu’il couvre bien Node.js et TypeScript, crée ou complète le fichier, puis vous montre le résultat sous forme de diff. Le journal d’exécution défile en temps réel : c’est là que vous verrez si l’agent a respecté la condition ou s’il a écrasé votre fichier existant.

Depuis l’IDE

Ouvrez votre projet dans VS Code (ou Cursor, Windsurf) et ouvrez Codex par son icône, ou par la palette de commandes :

Ctrl+Shift+P → "Codex: Open Codex Sidebar"

Formulez alors une demande qui tire parti du contexte local, en nommant le fichier concerné :

"Ajoute la validation d'email dans le formulaire 
 de contact src/components/ContactForm.tsx"

L’extension présente un résumé et les lignes modifiées à côté du code ; vous gardez les modifications voulues et demandez une suite dans la même conversation. La documentation conseille de créer un point de contrôle Git avant et après la tâche, pour pouvoir revenir en arrière.

Depuis le CLI

# Se placer dans le répertoire du projet
cd mon-projet

# Ouvrir une session avec une première consigne
codex "Ajoute un README.md avec la description du projet, les instructions d'installation et les commandes disponibles"

En local, Codex modifie directement les fichiers de votre dossier de travail, dans les limites du bac à sable et de la politique d’approbation : il vous demande l’autorisation avant les actions qui l’exigent. Pour relire ce qui a changé avant de commiter, tapez /diff dans la session : la commande affiche le diff Git, fichiers non suivis compris. /review demande à Codex de relire lui-même votre arbre de travail. Pour un usage scripté, codex exec lance la même tâche sans interaction (leçon 14) — c’est alors à Git, et à votre pipeline, de décider de ce qui sera conservé.

Anatomie d’un résultat Codex

Quel que soit le point d’entrée, une tâche terminée vous rend toujours les quatre mêmes éléments. Parcourez-les dans cet ordre : le diff dit ce qui a changé, le journal dit pourquoi, les tests disent si c’est sûr, les actions vous rendent la main.

Le journal est l’élément que les débutants négligent le plus, et c’est pourtant lui qui vous apprend à formuler vos tâches. En voyant quels fichiers Codex a ouverts avant de se décider, vous découvrez ce qu’il cherchait sans le trouver — souvent une convention qui aurait dû figurer dans AGENTS.md.

Écrire de bonnes instructions

La qualité du résultat dépend directement de celle de vos instructions, et l’écart entre les deux formulations ci-dessous est bien plus grand que l’écart entre deux modèles.

"Améliore le code"

"Dans src/lib/auth.ts, remplace la gestion manuelle des JWT 
par la bibliothèque jose. Conserve la même interface publique 
(signToken, verifyToken). Mets à jour les tests correspondants."

La seconde version fonctionne parce qu’elle répond à quatre questions que l’agent se pose de toute façon. Elle indique les fichiers concernés, ce qui lui évite d’explorer et de se tromper de cible. Elle précise le résultat attendu — comportement, interface, format — donc il sait quand s’arrêter. Elle pose des contraintes, ici la conservation de l’interface publique, qui l’empêchent d’« améliorer » en cassant les appelants ; ailleurs ce sera « ne casse pas les tests ». Et lorsque l’enjeu le justifie, elle ajoute le contexte métier : préciser « c’est un formulaire de paiement, la sécurité est critique » change réellement ses arbitrages.

Pour vous approprier tout cela, prenez un projet existant et enchaînez trois tâches de nature différente : une analyse sans modification, « Liste tous les fichiers TypeScript qui n’ont pas de tests associés » ; une génération ciblée, « Génère un test unitaire pour ce fichier » ; une correction à périmètre limité, « Corrige les warnings ESLint dans src/utils/ ». Notez pour chacune ce que vous auriez dû préciser dès le départ : cette liste de regrets est votre premier brouillon d’AGENTS.md.

Points clés à retenir

• Lancez vos premières tâches avec des demandes simples et ciblées
• Codex fournit un journal d’exécution complet pour chaque tâche
• La qualité du résultat dépend de la précision de vos instructions
• Vous gardez toujours le contrôle : approuver, modifier ou rejeter
• Commencez par des tâches de faible risque avant de passer aux modifications critiques