Exécuter une première tâche

📚 Navigation de la série : Le chapitre précédent 05 · Connexion à des modèles tiers comme DeepSeek a présenté l'intégration de modèles alternatifs. Ce chapitre initie la phase pratique : déléguer une première modification de code à Codex et valider son exécution par l'analyse du diff. Le chapitre 07 · Présentation de l'application de bureau détaillera les fonctionnalités de l'interface graphique.

Voici un retour d'expérience personnel pour illustrer l'importance de la méthode.

Lors de ma première utilisation de la CLI de Codex, j'ai souhaité tester ses capacités sur un dépôt existant de plusieurs centaines de fichiers. J'ai formulé un prompt générique : « Refactorise le module utilisateur, c'est trop désordonné ». Codex a analysé les fichiers pendant quelques secondes puis a généré des modifications sur une dizaine de fichiers. J'ai validé la proposition sans analyser le détail des lignes modifiées.

Le résultat a été immédiat : les signatures de deux API critiques non ciblées ont été altérées, provoquant des erreurs de compilation en cascade. Il m'a fallu plus d'une heure pour trier et annuler manuellement les modifications erronées. Ma principale erreur n'était pas liée aux capacités de Codex, mais à l'absence de relecture critique du diff avant validation.

Ce chapitre se concentre sur cette phase de validation. Nous allons créer un projet de test de quelques lignes pour parcourir le cycle complet en 5 minutes : formulation de la consigne → modification dans la sandbox → relecture du diff → validation ou annulation. Les démarches via la CLI et via l'application de bureau y sont décrites.

À la fin de ce chapitre, vous obtiendrez :

• Le déroulé complet pour initialiser et exécuter une première tâche
• L'habitude systématique de lire le diff avant de valider une action
• Les instructions détaillées et validations attendues pour la CLI et l'application de bureau
• Les bonnes pratiques en cas d'erreur de génération (formuler une correction, restaurer le code via git)

⚠️ Note : Les commandes, options et comportements décrits ci-dessous font référence à la documentation officielle de Codex ; les interfaces graphiques et noms de modèles sont sujets à des mises à jour.

---

01 Créer un projet de test temporaire

Règle d'apprentissage : pour vos premiers pas sur Codex, n'intervenez pas sur un dépôt de production ; initialisez un projet factice de quelques lignes.

La complexité d'un projet réel (multiplicité des fichiers, arborescence complexe) empêche d'évaluer rapidement la pertinence des modifications générées par l'agent, ce qui favorise les validations erronées. Sur un projet d'apprentissage restreint, chaque caractère modifié est identifiable.

Analogie : L'apprentissage du vélo. On ne commence pas son apprentissage sur un boulevard à forte circulation, mais dans une ruelle déserte où une chute reste sans conséquence. Le projet factice est cette zone sécurisée : en cas d'erreur de manipulation, il suffit de supprimer le répertoire et de le recréer en quelques secondes.

Ce conseil s'adresse particulièrement aux profils suivants :

• Débutants en ligne de commande : l'affichage des logs d'exploration des fichiers par l'agent dans la console peut être déroutant sans expérience préalable.
• Développeurs habitués à d'autres outils (ex. Claude Code) : les comportements par défaut de la sandbox et des approbations de Codex présentent des spécificités à appréhender.
• Utilisateurs dans l'urgence : valider la chaîne de traitement sur un test simple fait gagner du temps par rapport à la résolution de bugs sur un projet actif.

Ouvrez votre terminal (Terminal sous macOS, PowerShell sous Windows) et saisissez :

mkdir hello-codex
cd hello-codex

La commande mkdir crée le dossier hello-codex, et cd vous positionne à l'intérieur de ce répertoire.

Générez un fichier Python simple. Sous macOS / Linux, lancez :

echo 'def add(a, b):
    return a + b' > main.py

Sous Windows (PowerShell), vous pouvez utiliser le bloc-notes pour créer main.py et y coller ces lignes :

def add(a, b):
    return a + b

💡 En résumé : Démarrez avec un projet de test restreint — les modifications y sont immédiatement identifiables et une réinitialisation s'effectue en quelques secondes.

---

02 Formuler des consignes structurées

Avant de démarrer Codex, déterminez précisément la tâche à lui attribuer.

Codex exécute ses tâches de manière itérative au sein d'une boucle d'agent (concevoir → agir → vérifier). La précision de vos prompts détermine la pertinence du code produit.

Analogie : L'artisan et les travaux. Une consigne vague (« rénove cette pièce ») laisse place aux interprétations ; une demande précise (« peins cette cloison en blanc, installe une évacuation d'eau et termine d'ici vendredi ») garantit un résultat conforme. La documentation officielle de Codex (section Prompting) fournit deux conseils clés :

• Faciliter l'auto-validation : incluez des étapes de reproduction, des critères d'acceptation ou des commandes de tests unitaires pour guider les vérifications de l'agent.
• Découper les tâches complexes : divisez les objectifs d'envergure en étapes simples et contrôlables ; si nécessaire, demandez d'abord à Codex de rédiger un plan d'action.

Exemples de formulation de prompts :

Prompt imprécis ❌	Prompt structuré ✅
« Optimise cette fonction »	« Ajoute des annotations de type à add et lève une exception TypeError si les arguments ne sont pas des nombres »
« Pourquoi ce test échoue-t-il ? »	« Lance pytest, identifie la cause de l'erreur dans les rapports, applique la correction et relance la vérification »
« Refactorise le projet »	« Rédige d'abord un plan de refactorisation sans modifier les fichiers, je validerai la démarche avant exécution »

Il est recommandé de demander la rédaction d'un plan pour toute intervention d'envergure, afin de valider la démarche technique avant l'altération du code.

💡 En résumé : Codex opère selon le cycle « concevoir → agir → vérifier » ; définissez des critères d'acceptation explicites et demandez un plan d'action pour les tâches complexes.

---

03 Première étape : la lecture de fichiers (sans modification)

Pour ce premier exercice, demandez à Codex d'analyser le code existant sans l'éditer.

Cela permet de valider que l'agent accède correctement aux répertoires de votre machine et d'exécuter une tâche d'analyse sans risque de modification inopportune des fichiers.

Analogie : L'intégration d'un nouveau collaborateur. Avant de lui confier l'écriture de code de production, vous lui demandez de parcourir le dépôt et de vous en expliquer le fonctionnement général pour évaluer sa compréhension.

Saisissez la consigne suivante dans Codex :

解释 main.py 这个文件在做什么，用新手能听懂的话说

Codex identifie et analyse le fichier main.py de manière autonome, puis retourne une explication détaillant le fonctionnement de la fonction add (addition des deux paramètres).

Cette validation confirme deux aspects : la bonne configuration de Codex et sa capacité à accéder physiquement à votre espace de travail.

Trois catégories de tâches principales se distinguent :

Type de consigne	Action réalisée	Exemple	Risque associé
Analyse	Lecture et explication du code	« Explique ce module »	Aucun (lecture seule)
Édition	Altération du code existant	« Ajoute des annotations de type »	Modification de fichiers ; exige la relecture du diff
Création	Génération de nouveaux fichiers	« Rédige un fichier de test »	Ajout de fichiers ; exige la relecture du diff

Prendre l'habitude d'interroger Codex sur l'architecture d'un projet inconnu permet d'en cartographier les composants de manière passive et sécurisée.

💡 En résumé : Lancez une commande d'analyse en premier lieu pour vérifier les accès aux fichiers ; les étapes de modification ou de création exigeront quant à elles un contrôle du diff.

---

04 Action critique : la relecture du diff

Abordons la phase de modification du code, qui exige une attention particulière.

Saisissez le prompt suivant :

给 main.py 里的 add 函数加上类型注解，并补充基本的错误处理

Il est important de comprendre le comportement par défaut de l'outil : dans le cadre d'une sandbox configurée en écriture (workspace-write) associée à une approbation on-request, l'agent modifie les fichiers de l'espace de travail de manière autonome, sans vous interrompre. Les validations manuelles ne s'activent que lors des sorties de périmètre (accès réseau, modification de fichiers externes au projet). Le flux se déroule ainsi :

1. L'agent localise et applique directement les modifications sur le fichier cible dans la sandbox.
2. Il affiche un rapport de modifications sous forme de diff (en console ou dans l'interface de l'application).
3. Vous effectuez le contrôle de conformité : l'analyse du diff vous permet de valider le code ou d'annuler les modifications via git.

Le contrôle du diff reste une étape indispensable, déplacée en phase de revue post-écriture. Les modifications de l'espace de travail n'étant pas encore commitées, vous gardez la liberté de rejeter ou d'ajuster le code généré.

⚠️ Note : Les commandes git diff et de restauration de fichiers exigent que le projet soit géré par le contrôle de version git (initialisé avec git init). La section pratique ci-dessous détaille la configuration de ce point de contrôle.

Analogie : L'évaluation d'une Pull Request. Votre collaborateur modifie le code et soumet une branche intermédiaire. Les modifications ne sont pas encore intégrées à la branche principale ; vous examinez le diff et choisissez de fusionner la Pull Request ou de demander des corrections.

⚠️ Note : Pour forcer une validation interactive avant toute écriture de fichier, configurez Codex en mode read-only via la commande /permissions, ou demandez explicitement la rédaction d'un plan préalable.

Lire et comprendre un diff

L'affichage du diff met en évidence les écarts de code :

• Les lignes précédées d'un signe - ou colorées en rouge correspondent aux éléments supprimés.
• Les lignes précédées d'un signe + ou colorées en vert correspondent aux éléments ajoutés.
• Les lignes standards sans préfixe servent de repère contextuel.

Le fichier main.py initial :

def add(a, b):
    return a + b

Évoluera vers une structure de ce type :

def add(a: float, b: float) -> float:
    if not isinstance(a, (int, float)) or not isinstance(b, (int, float)):
        raise TypeError("a 和 b 必须是数字")
    return a + b

Lors de l'analyse, validez ces trois critères :

1. Le périmètre de modification correspond-il à la demande formulée ?
2. La logique et la syntaxe ajoutées sont-elles conformes à vos attentes ?
3. Des portions de code utiles ont-elles été supprimées par inadvertance ?

Si la relecture est concluante, conservez les modifications ; dans le cas contraire, formulez un ajustement ou restaurez l'état via git.

Les cas d'interruption pour validation

Sous la configuration par défaut, les demandes d'approbation explicites s'activent pour les opérations sortant des limites de la sandbox :

Action projetée par Codex	Comportement par défaut	Notification affichée
Lecture / écriture dans l'espace de travail	Exécution autonome	Aucune interruption, affichage du diff final
Lancement de scripts locaux (ex. tests unitaires)	Exécution autonome	Aucune interruption
Commandes réseau ou externes (ex. installation de paquets)	Interruption pour approbation	Invitation à valider/rejeter l'action
Modification externe ou accès internet direct	Interruption pour approbation	Invitation à valider/rejeter l'action

Conseil important : conservez un niveau d'approbation strict à vos débuts. Ouvrir excessivement les droits de la sandbox (mode never ou accès complet) lève les garde-fous techniques, laissant l'agent altérer de nombreux fichiers en arrière-plan sans validation préalable.

💡 En résumé : Par défaut, Codex applique les écritures locales et affiche le diff ; les alertes ne ciblent que les actions hors périmètre. Prenez le temps d'analyser le diff pour valider le code.

---

05 Corriger et réitérer après un rejet

Rejeter une proposition ou interrompre une action n'annule pas la tâche en cours ; cela permet de réorienter les choix de l'agent.

Codex conserve le contexte de l'échange au sein d'une même session (Thread). Si le diff affiché ou l'action proposée ne conviennent pas, formulez une consigne de correction directe dans la même session.

Analogie : Ajuster un plat au restaurant. Si le plat servi ne correspond pas à vos attentes, vous demandez au serveur de le corriger en cuisine sans devoir commander un autre repas. Le contexte de la commande initiale reste actif.

Exemple pratique : face à une implémentation important un module tiers non installé sur mon système, j'ai rejeté l'action et formulé la consigne suivante :

别引第三方库，用 Python 标准库 functools.lru_cache 实现就行

L'agent a immédiatement adapté sa proposition pour utiliser le module standard, validant ainsi la modification sans réinitialisation de la session.

Logique de dialogue avec l'agent :

Idée reçue ❌	Réalité technique ✅
Rejeter équivaut à annuler la tâche	Rejeter permet de réorienter la proposition de code
Les erreurs doivent être corrigées à la main	Spécifiez les écarts en langage naturel pour qu'il régénère le code
Chaque échec exige de relancer la session	Le contexte persiste au sein du thread pour permettre les itérations

💡 En résumé : Un rejet ou un diff incorrect est une opportunité d'ajustement. Formulez vos remarques dans la même session, Codex adaptera sa proposition en conservant le contexte.

---

06 Restauration du code : l'usage de Git

Si des modifications non souhaitées sont appliquées sur votre disque, le contrôle de version git constitue votre filet de sécurité.

La documentation officielle de Codex recommande de créer des points de restauration git avant et après chaque tâche pour sécuriser vos fichiers projets.

Analogie : Les sauvegardes de jeu. Avant d'affronter un niveau difficile, vous prenez un point de sauvegarde pour pouvoir y revenir en cas d'échec. Un commit git remplit cet office avant de lancer Codex.

Actions de sauvegarde à effectuer avant l'exécutions :

git init
git add -A && git commit -m "codex 动手前的检查点"

Pour annuler l'ensemble des modifications non commises :

git restore .

⚠️ La commande git restore . annule toutes les modifications en cours de l'espace de travail. Utilisez-la uniquement pour réinitialiser le répertoire à son état initial.

Vous pouvez également demander à Codex d'annuler son action directement dans le chat :

刚才那次改动我不满意，帮我退回到改之前的样子

Comparatif des modes de restauration :

Méthode	Action	Cas d'usage	Limite
Prompt d'annulation	Demander l'annulation dans Codex	Ajustements mineurs ciblés	Dépend de la bonne interprétation de l'agent
Restauration git	git commit puis git restore .	Réinitialisation complète du répertoire	Exige d'avoir créé un commit préalable

Prendre l'habitude d'effectuer un commit git avant de lancer Codex protège votre projet contre les modifications inopportunes et facilite les itérations.

💡 En résumé : Sécurisez votre projet — sauvegardez avec git commit avant d'agir, et restaurez avec git restore . en cas d'erreur ; gérez les ajustements à la marge par le chat.

---

07 Pratique 1 : exécution en ligne de commande (CLI)

Suivez ces étapes dans votre console pour valider le fonctionnement :

Étape 1 : Initialiser le projet et le dépôt git (macOS / Linux)

mkdir hello-codex && cd hello-codex
echo 'def add(a, b):
    return a + b' > main.py
git init && git add -A && git commit -m "初始版本"

Sous Windows : effectuez les commandes mkdir et cd, créez main.py avec le bloc-notes et lancez les commandes git correspondantes.

Résultat attendu : Le dossier hello-codex contient le fichier main.py commité dans git.

Étape 2 : Démarrer Codex dans le dossier du projet

codex

Résultat attendu : L'interface interactive de Codex s'ouvre. Si l'authentification est requise, référez-vous au chapitre 03 · Installation et connexion.

⚠️ Démarrez Codex depuis le répertoire du projet ciblé. Codex considère le répertoire d'appel comme son espace de travail actif.

Étape 3 : Demander l'analyse du code (sans risque)

解释 main.py 这个文件在做什么，用新手能听懂的话说

Résultat attendu : Codex décrit le fonctionnement de la fonction add. L'analyse valide les droits de lecture de l'agent.

Étape 4 : Lancer la modification et lire le diff

给 main.py 里的 add 函数加上类型注解，并补充基本的错误处理

Résultat attendu : Codex applique les modifications sur main.py et affiche le diff en console (retraits en rouge/-, ajouts en vert/+). Analysez les lignes affichées.

Étape 5 : Valider l'écriture sur le disque

Quittez Codex (via Ctrl + C ou la commande /exit) et vérifiez le contenu du fichier :

cat main.py

(Saisissez type main.py sous Windows PowerShell).

Résultat attendu : Le fichier comporte désormais les annotations de type et la gestion d'erreurs générées.

Pour lister les modifications gérées par le contrôle de version, lancez :

git diff

Résultat attendu : La console affiche le diff git correspondant aux modifications observées sous Codex.

💡 En résumé : Le flux CLI se décline en 5 étapes — initialisation et commit git, démarrage de codex, analyse de code, modification avec contrôle de diff, validation sur disque. Démarrez l'utilitaire dans le bon dossier et créez un commit préalable.

---

08 Pratique 2 : exécution via l'application de bureau

L'application graphique propose un parcours visuel équivalent pour macOS et Windows.

Le flux de travail reste identique à celui de la CLI, s'appuyant sur des sélections visuelles et la revue du diff final :

1. Ouvrez Codex et connectez-vous (via compte ChatGPT ou clé API, voir chapitre 03).
2. Sélectionnez le dossier projet hello-codex ou créez un répertoire d'apprentissage.
3. Vérifiez l'activation du mode Local dans l'interface (pour autoriser l'exécution sur votre machine et non sur le cloud).
4. Saisissez le prompt d'analyse :

解释 main.py 这个文件在做什么，用新手能听懂的话说

Puis formulez la consigne d'édition :

给 main.py 里的 add 函数加上类型注解，并补充基本的错误处理

Résultat attendu : L'application applique les modifications sur votre disque et met en évidence le diff dans le panneau de revue (review pane). L'interface affiche l'état des fichiers non commités et propose des options graphiques pour ajouter au commit, restaurer ou rejeter les modifications.

Note : L'application de bureau intègre des raccourcis git directs pour faciliter la gestion des versions (stage, commit, revert) sans avoir à ouvrir le terminal.

Comparatif d'utilisation :

Critère	CLI (Terminal)	Application de bureau
Compatibilité	✅ macOS, Windows, Linux	❌ macOS, Windows uniquement
Prise en main	Commandes terminal	Interface graphique simple
Visualisation diff	Diff textuel en console	✅ Panneau graphique optimisé
Multi-projets	Sessions de terminaux multiples	✅ Onglets de navigation intégrés
Flux de travail	Identique (Formuler prompt → modification → revue du diff)	Identique

Recommandation : La CLI est adaptée au développement quotidien. L'application graphique s'avère plus confortable pour la relecture de diffs importants.

💡 En résumé : L'application de bureau (macOS / Windows) gère le même flux de travail. Pensez à activer le mode Local. Le panneau de revue graphique simplifie la validation des modifications complexes.

---

09 Synthèse visuelle

Voici le cycle complet de traitement d'une tâche :

Le point critique de ce flux réside dans le contrôle de conformité du diff. La supervision humaine est la garantie de la qualité du code produit.

💡 En résumé : Le processus d'édition se résume à : formuler le besoin → modification automatique dans la sandbox → contrôle humain du diff → validation ou restauration. Ne sautez pas l'étape de contrôle.

---

10 Résumé

Ce chapitre a détaillé la mise en œuvre pratique de votre première tâche avec Codex (analyse, édition et relecture de diff).

Synthèse des étapes clés :

Étape	Action	Point clé
Initialisation	Création du répertoire, du fichier et commit git	Projet test restreint, sauvegarde de l'état initial
Prompting	Consigne explicite en langage naturel	Plan d'action recommandé pour les tâches complexes
Analyse	Explication de fichiers	Validation passive des accès locaux
Édition	Modifications de code	Écriture automatique locale et génération du diff
Relecture du diff	Validation du module, de la logique et des suppressions	Étape critique de contrôle de conformité
Restauration	Prompt d'annulation ou git restore .	Annulation des modifications non souhaitées

Vous maîtrisez désormais les bases de l'échange avec l'agent et la gestion sécurisée des écritures locales.

Le cycle prompt → modification → relecture du diff → validation/reversion constitue le socle de l'utilisation de Codex. Les fonctionnalités avancées (MCP, sous-agents, compétences) s'intègrent au sein de cette boucle.

💡 En résumé : La boucle de base est : formuler le besoin → modification automatique dans la sandbox → contrôle humain du diff → validation ou restauration.

---

Le chapitre suivant 07 · Présentation de l'application de bureau détaille les fonctionnalités avancées de l'interface graphique : gestion de sessions multiples, isolation des espaces de travail et tâches automatisées.

Lectures recommandées

• Mode non interactif codex exec : scripts et CI/CD
• Codex Cloud : déléguer les tâches d'agent dans le cloud
• Premiers pas avec la CLI