Techniques avancées et accélération : ce qui vous ralentit n'est pas le modèle, c'est votre contexte désordonné
📚 Navigation de la série : Le chapitre précédent 〔30 Comment choisir son modèle〕 expliquait quel modèle et quelle intensité de raisonnement utiliser pour une même consigne. Ce chapitre va plus loin : choisir le bon modèle ne suffit pas. Ce qui détermine réellement la quantité de travail accomplie en une journée, c'est la façon dont vous fournissez le contexte, gérez les sessions et menez plusieurs tâches de front. Le chapitre suivant 〔32 Migrer depuis Claude Code〕 expliquera aux utilisateurs expérimentés comment effectuer une transition en douceur.
À la fin du chapitre précédent, j'ai écrit : souvent, les ralentissements proviennent d'un contexte désordonné qui égare le modèle, plutôt que d'un manque de puissance de ce dernier. Ce chapitre y est consacré.
Laissez-moi vous donner un exemple personnel. En mars 2025, alors que je développais un petit outil en Python, une fonctionnalité m'a fait faire des allers-retours avec Codex tout un après-midi. En consultant l'historique des sessions via /status, j'ai compté que cette seule demande avait nécessité 11 tours. Pendant ce temps, le modèle a modifié deux fois les mauvais fichiers et a « optimisé » de lui-même des configurations que je ne lui avais pas demandé de toucher. En analysant la situation après coup, j'ai compris que gpt-5.5 n'était pas en cause : c'est moi qui, dès le départ, avais simplement demandé « d'ajouter une fonction d'export », passant les dix tours suivants à corriger le manque de contexte que j'aurais dû donner dès le début.
En vérité, dans la programmation avec IA, la principale lenteur ne vient pas des secondes de réflexion du modèle, mais des corrections nécessaires (le code à refaire). Si vous ne vous exprimez pas clairement dès le début, le modèle prend une mauvaise direction, vous devez le réorienter, et après trois allers-retours, vous avez perdu une demi-heure. Quelle que soit la vitesse du modèle, elle ne compensera jamais le temps gagné par un code « correct dès le premier essai ».
Ce chapitre ne propose pas de formules magiques, mais présente six actions concrètes pour réduire le travail à refaire et fluidifier votre flux de travail.
Ce que vous obtiendrez après avoir lu ce chapitre :
- Une règle d'efficacité contre-intuitive : limiter les corrections > chercher la rapidité absolue. Viser juste dès le départ est le meilleur moyen de gagner du temps.
- La structure d'une « bonne requête » : Objectif + Contexte + Contraintes + Critères d'acceptation, avec un tableau comparatif Avant/Après.
- Trois techniques pour gérer la fenêtre de contexte : la commande
/compact, l'ouverture de nouvelles sessions au bon moment, et l'utilisation de@pour cibler précisément les fichiers plutôt que de charger tout le projet. - Une méthode pour adapter le niveau du modèle selon la complexité de la tâche afin de gagner du temps et d'économiser des ressources (en lien avec le chapitre précédent).
- Des techniques avancées pour exécuter plusieurs tâches en parallèle et laisser Codex valider lui-même son travail.
- Un exercice pratique immédiat : reformuler une demande floue selon la structure en quatre points pour observer la baisse du taux de correction.
⚠️ Les commandes, les clés de configuration et les comportements par défaut décrits ici se réfèrent à la documentation officielle de Codex. Les noms de modèles, les taux d'utilisation des crédits (l'unité de facturation de Codex) et des commandes comme
/fastpeuvent évoluer. Fiez-vous à la commande localecodex --helpet à la documentation officielle.
01 Le principe de la rapidité : limiter les corrections plutôt que courir après la vitesse
Il est essentiel de comprendre ce principe, sans quoi les techniques suivantes seront inutiles.
Pour les débutants, accélérer le travail signifie « utiliser un modèle plus rapide », « baisser l'intensité du raisonnement » ou « activer un mode accéléré ». Nous aborderons ces points, mais ils sont secondaires. Le facteur principal de ralentissement reste les corrections.
Analogie : La cuisine. Si vous mettez du temps à préparer un plat, c'est rarement parce que le feu n'est pas assez fort. C'est le plus souvent parce qu'en cours de route, vous réalisez qu'il vous manque des oignons, que vous avez mis trop de sel et devez recommencer, ou que vous avez mal lu les étapes de la recette. Ce sont ces retours en arrière qui consomment du temps, pas la puissance du feu. Pousser le feu au maximum ne sauvera pas un cuisinier qui doit sans cesse recommencer sa préparation.
En programmation avec IA, c'est identique. Si Codex prend une mauvaise direction, modifie le mauvais fichier ou comprend mal vos intentions, vous devez corriger le tir : le coût de cet aller-retour dépasse largement les quelques secondes de réflexion supplémentaires du modèle.
Une phrase de la documentation officielle m'a marqué : Codex produit des résultats de qualité nettement supérieure lorsqu'il est en mesure de valider lui-même son travail. Autrement dit, veiller à ce qu'il avance correctement et sûrement dès le premier essai est bien plus important que de chercher à le faire répondre vite.
J'ai vécu une situation très représentative à la fin de l'année dernière. J'ai demandé au modèle « d'optimiser cette fonction », sans préciser ce qu'il fallait optimiser, ce qu'il fallait laisser inchangé, ni comment évaluer le succès de l'optimisation. Avec beaucoup d'enthousiasme, il a réécrit la fonction, modifié la signature de l'interface et provoqué des erreurs chez trois composants appelants. J'ai passé vingt minutes à réparer les dégâts de son « optimisation ». Depuis ce jour, j'applique une règle stricte : ne jamais utiliser de formulations floues comme « optimise ceci », quitte à écrire deux lignes de détails en plus.
Gardez cette comparaison à l'esprit :
| Ce que vous pensez être de la rapidité | Ce qui fait réellement gagner du temps |
|---|---|
| ❌ Utiliser à la hâte un modèle plus rapide | ✅ Clarifier la demande dès le premier message pour limiter les allers-retours |
| ❌ Baisser systématiquement l'intensité du raisonnement pour aller vite | ✅ Adapter la puissance de calcul à la difficulté de la tâche (voir chapitre précédent) |
| ❌ Lui donner tout le projet à analyser | ✅ Utiliser @ pour cibler précisément les fichiers concernés |
| ❌ Conserver la même session du matin au soir | ✅ Ouvrir une session par tâche, et utiliser la compression ou de nouvelles sessions |
| ❌ Relire soi-même le code ligne par ligne | ✅ Fournir des critères de validation et laisser le modèle exécuter les tests |
💡 Résumé en une phrase : La principale perte de temps avec l'IA provient du code à refaire. Le secret de l'efficacité réside dans la précision initiale (« faire correctement du premier coup ») plutôt que dans la vitesse brute du modèle.
02 Fournir le contexte nécessaire sans faire deviner le modèle : la structure d'une bonne requête
Si les corrections sont la principale source de ralentissement, d'où viennent-elles ? Le plus souvent d'un manque de clarté dans le premier message, forçant Codex à deviner vos intentions. Dès qu'il doit deviner, il risque de se tromper, et vous devez corriger.
Analogie : Les instructions de livraison. Si vous écrivez simplement « je veux un riz sauté », le livreur et la cuisine feront au plus simple : le plat contiendra peut-être des oignons ou sera trop épicé à votre goût. Si vous écrivez « Riz sauté cantonais, sans oignons, peu épicé, riz bien cuit », vous obtiendrez exactement ce que vous souhaitez. Pour Codex, c'est identique : chaque détail que vous omettez est un détail qu'il doit deviner, augmentant le risque d'erreur.
La documentation officielle suggère une structure que j'utilise systématiquement. Une bonne requête doit contenir ces quatre éléments :
- Objectif (Goal) : Qu'avez-vous besoin de modifier ou de créer précisément ?
- Contexte (Context) : Quels fichiers, documentations ou erreurs sont concernés ? Utilisez
@pour les désigner. - Contraintes (Constraints) : Quelles sont les règles d'architecture ou les interdictions à respecter ?
- Critères d'acceptation (Done when) : À quoi reconnaît-on que le travail est terminé ? (tests réussis, comportement vérifié, bug résolu)
Il n'est pas nécessaire de détailler chaque point à l'extrême, mais l'objectif et les critères d'acceptation sont indispensables. Même pressé, je m'assure toujours de couvrir ces aspects avant de valider mon message.
Voici un tableau comparatif basé sur mes propres erreurs passées pour mesurer la différence :
| ❌ Avant (Flou, allers-retours garantis) | ✅ Après (Structuré, fortes chances de succès dès le premier essai) |
|---|---|
| Ajoute une fonction d'export | Objectif : Ajouter dans report.py une fonction pour exporter le rapport au format CSV. Contexte : S'inspirer de la logique existante dans @export/json_export.py. Contraintes : Réutiliser la classe de données Report existante sans modifier ses champs. Critères de validation : L'export doit générer un fichier CSV avec les en-têtes corrects, et tous les tests dans tests/test_export.py doivent réussir. |
| Cette fonction est lente, optimise-la | Objectif : Réduire le temps d'exécution de search() de 2 secondes à moins de 200 ms sur un échantillon de 10 000 enregistrements. Contexte : La fonction se trouve dans @core/search.py. Contraintes : Ne pas modifier la signature de la fonction ni la structure des données retournées. Critères de validation : Le test de performance pytest tests/test_search.py::test_perf (affirmant une durée < 0.2s) doit réussir. |
| Répare ce bug | Objectif : Résoudre le problème de redirection vers une page vide après la connexion. Contexte : Les étapes de reproduction sont « saisir les identifiants valides → cliquer sur connexion → page blanche ». Code concerné : @auth/login.py. Contraintes : Ne pas modifier la logique de validation des autorisations. Critères de validation : Suivre les étapes de reproduction doit maintenant mener à la page d'accueil. |
Vous l'aurez compris : la colonne de droite n'est pas simplement plus bavarde, elle explicite des informations que vous avez déjà en tête mais que vous auriez pu omettre d'écrire. En fournissant ces détails, vous évitez au modèle de faire des suppositions et lui permettez d'aller droit au but.
Sur mon projet en Python, j'ai calculé qu'une demande formulée comme à gauche nécessitait en moyenne 5 à 8 tours pour aboutir, tandis que la structure de droite permettait de clore la tâche en 1 ou 2 tours dans la majorité des cas. Écrire ces quelques lignes supplémentaires permet d'économiser plusieurs cycles de correction par la suite.
Une astuce simple lorsque la tâche est complexe et que vous peinez à la formuler : n'écrivez pas le code directement, utilisez le mode planification de Codex. Activez le mode Plan (Plan mode) via /plan ou le raccourci Shift+Tab dans le CLI. Le modèle commencera par analyser le contexte, vous posera des questions de clarification et proposera une stratégie avant d'effectuer toute modification. Mieux vaut passer une minute à valider un plan que de devoir corriger un code qui a fait fausse route.
💡 Résumé en une phrase : Une requête efficace combine Objectif + Contexte + Contraintes + Critères d'acceptation. Chaque omission oblige le modèle à deviner, ce qui conduit souvent à devoir réécrire le code.
03 Gérer la fenêtre de contexte : éviter de surcharger le modèle
Le point précédent traitait de la clarté ; celui-ci concerne la pertinence de l'information. L'enjeu est de fournir tout le contexte nécessaire, sans y ajouter d'éléments superflus.
Chaque session de travail (appelée « thread » par Codex) possède une limite de capacité : la fenêtre de contexte (context window). Elle représente la quantité maximale d'informations que le modèle peut « garder en mémoire » à un instant T. Lorsque cette limite est atteinte, les informations les plus anciennes sont soit compressées, soit supprimées, ce qui altère la qualité des réponses.
Analogie : Un bureau de travail. La surface disponible est limitée. Si vous y déposez uniquement les trois dossiers nécessaires à votre tâche en cours, vous travaillerez efficacement. Si vous y videz l'intégralité d'une armoire de classement contenant des centaines de documents, vous ne vous y retrouverez plus. La fenêtre de contexte de Codex fonctionne de la même manière : plus le contexte est ciblé, plus le modèle est performant ; y ajouter tout le projet l'égare dans des détails inutiles.
Voici trois règles pour gérer efficacement cette fenêtre :
Règle 1 : Utiliser @ pour cibler précisément les fichiers. Si vous connaissez les fichiers concernés par la modification, désignez-les explicitement avec @. Le modèle n'aura pas à effectuer de recherches globales (grep) dans tout le projet, ce qui économise de l'espace de contexte et améliore la rapidité. Dans mon exemple personnel, le modèle avait analysé sept ou huit modules inutiles avant de trouver le bon emplacement, encombrant la mémoire pour rien.
Règle 2 : Utiliser /compact lors des sessions prolongées. Au fil d'une longue conversation, le contexte s'accumule. La commande /compact demande à Codex de résumer les échanges précédents pour libérer de l'espace mémoire. Bien que Codex compresse automatiquement le contexte lorsque cela est nécessaire, utiliser /compact manuellement permet de repartir sur des bases saines avant que le modèle ne commence à perdre en précision.
Règle 3 : Ouvrir une session par tâche (recommandation officielle). La documentation officielle met en garde contre l'utilisation d'une session unique pour tout un projet. Conserver la même session accumule le contexte et dégrade progressivement la qualité des réponses.
J'applique désormais cette règle simple : une fois une tâche terminée, j'ouvre une nouvelle session pour la tâche suivante. Les commandes du CLI facilitent cette gestion :
/compact Compresse l'historique de la session pour libérer du contexte
/status Affiche l'état de la session (notamment l'espace de contexte restant)
/fork Crée une nouvelle branche de session à partir de l'état actuel
/resume Restaure une session enregistrée précédemmentRègle d'or : privilégiez la pertinence du contexte plutôt que sa quantité. Conservez la même session pour travailler sur un problème précis afin de maintenir le fil de réflexion ; si le travail prend une autre direction, utilisez /fork ou démarrez une nouvelle session.
Le critère est simple : s'il s'agit du même sujet, restez dans la session ; s'il s'agit d'un sujet différent, créez-en une nouvelle. Ne cherchez pas à conserver tout l'historique dans une seule session : un contexte surchargé nuit à la qualité des réponses.
💡 Résumé en une phrase : Visez la pertinence plutôt que le volume. Ciblez avec
@, compressez avec/compactet ouvrez une session par tâche pour optimiser la fenêtre de contexte.
04 Adapter les ressources à la tâche : simplifier pour les travaux rapides
Ce point complète le chapitre précédent sous l'angle du gain de temps.
Analogie : Choisir son moyen de transport. Vous ne prendriez pas votre voiture pour acheter une bouteille d'eau au coin de la rue (vous y iriez à pied), et vous ne prendriez pas un vélo en libre-service pour un voyage d'affaires dans une autre ville. La difficulté d'une tâche détermine la puissance de calcul à y allouer, de la même manière que la distance détermine votre moyen de transport.
En pratique, retenez cette règle : pour les tâches simples et bien définies, baissez le niveau des ressources. Les recommandations de la documentation officielle concernant l'intensité du raisonnement sont claires :
- Tâches rapides à périmètre défini : intensité
low(ou inférieure pour les cas très simples) - Modifications et débogages complexes : intensité
mediumouhigh - Travaux volumineux nécessitant beaucoup de réflexion : intensité
xhigh
Il en va de même pour les modèles : pour les tâches de routine ou les analyses préliminaires des sous-agents, le modèle léger gpt-5.4-mini est suffisant. Utiliser systématiquement le modèle phare gpt-5.5 est inutile. Pour corriger une faute de frappe, renommer une variable ou effectuer une requête simple, passez à la combinaison gpt-5.4-mini + low pour un résultat rapide et économique.
Mon fichier ~/.codex/config.toml est configuré sur un niveau intermédiaire par défaut, et j'augmente l'intensité ponctuellement en cours de session si nécessaire. Évitez de verrouiller votre configuration sur gpt-5.5 + xhigh par défaut : attendre une minute de réflexion pour renommer une variable est une perte de temps inutile. Référez-vous au chapitre 30 pour revoir les méthodes de configuration.
💡 Résumé en une phrase : Pour les tâches simples, utilisez la combinaison rapide et économique
gpt-5.4-mini+low, et réservez le modèle phare et les intensités élevées pour les sujets complexes.
05 Travailler en parallèle : mener plusieurs tâches de front
Les points précédents visaient à optimiser l'exécution d'une tâche unique. Voyons maintenant comment paralléliser votre travail.
La documentation officielle souligne une erreur fréquente : considérer Codex comme un outil linéaire dont vous devez attendre chaque réponse, plutôt que comme un partenaire de programmation travaillant en parallèle. Vous pouvez tout à fait lui confier une refactorisation en arrière-plan pendant que vous continuez à travailler de votre côté.
Une précaution essentielle cependant : n'autorisez pas deux processus à modifier les mêmes fichiers simultanément, sous peine de créer des conflits dans votre espace de travail. La solution recommandée par la documentation consiste à utiliser des arbres de travail Git (git worktrees), comme détaillé dans le chapitre 25.
Analogie : Un chantier de rénovation. Pour que les électriciens, les menuisiers et les peintres travaillent en même temps, ils doivent intervenir dans des pièces différentes. Les regrouper dans la même pièce créerait des interférences. Un worktree joue le rôle de cette pièce isolée pour chaque tâche.
Il existe deux manières courantes de paralléliser le travail, présentées dans les chapitres précédents :
| Approche | Méthode d'isolation | Référence |
|---|---|---|
| Exécuter plusieurs tâches en même temps | Utiliser un git worktree par tâche pour travailler dans des répertoires distincts | Chapitre 25 (Worktrees) |
| Tâche principale et tâches secondaires | L'agent principal traite le sujet central et délègue les analyses secondaires ou les tests à des sous-agents | Chapitre 21 (Subagents) |
La recommandation officielle concernant les sous-agents (subagents) est la suivante : gardez l'agent principal concentré sur la logique centrale, et déléguez les tâches secondaires bien délimitées (exploration de code, écriture de tests, diagnostic) aux sous-agents. Libérer la tâche principale de ces éléments accélère l'ensemble du processus.
Pour les développements importants, j'ai pris l'habitude de structurer mon travail ainsi : je fais progresser la logique principale dans ma session de travail, tout en demandant à Codex de lancer les tests et les vérifications de syntaxe (linter) dans un worktree séparé. Mes vérifications sont prêtes en même temps que mon code, ce qui permet de gagner un temps précieux.
💡 Résumé en une phrase : Parallélisez vos tâches en utilisant les worktrees pour isoler le code et les sous-agents pour les tâches secondaires, en veillant à ne pas modifier les mêmes fichiers en même temps.
06 Automatiser la validation : réduire les étapes de vérification manuelle
Cette dernière technique est souvent négligée, mais elle offre un excellent retour sur investissement : laissez Codex valider lui-même son travail au lieu d'effectuer toutes les vérifications manuellement.
Comme vu au début : les corrections répétées ralentissent le travail, et les allers-retours de validation manuelle y contribuent fortement. Si vous devez ouvrir chaque fichier modifié pour vérifier le code, constater une erreur, puis demander une correction, vous devenez le goulot d'étranglement du processus. Fournir des critères d'acceptation clairs à Codex équivaut à lui donner une liste de contrôle pour qu'il valide son travail en autonomie.
Voici ce que vous pouvez laisser le modèle valider lui-même (selon les bonnes pratiques officielles) :
- Écrire ou mettre à jour les tests associés aux modifications
- Exécuter la suite de tests
- Lancer le linter, le formateur de code et les vérifications de types
- S'assurer que le comportement final correspond à la demande
- Analyser lui-même le diff de code pour identifier d'éventuels bugs ou régressions
La commande /review dans le CLI est très utile pour cela : elle permet de faire une revue de code de type Pull Request par rapport à une branche de référence, d'analyser les modifications non validées ou d'appliquer des règles personnalisées.
Pour aller plus loin : inscrivez les critères d'acceptation et les commandes de test dans votre fichier AGENTS.md. Le modèle les exécutera automatiquement à chaque tâche, vous évitant de les répéter dans vos messages. Ce point a été abordé au chapitre 11.
Dans mes demandes, j'ajoute désormais systématiquement la consigne : « Exécute pytest après modification et assure-toi que tous les tests réussissent avant de me répondre ». Le modèle effectue la vérification et ne revient vers moi qu'une fois le test validé. Cela évite le cycle classique : modification par l'IA → exécution manuelle des tests par l'utilisateur → échec → demande de correction. Laisser le modèle gérer cette validation vous libère du temps de supervision.
💡 Résumé en une phrase : Donnez des critères d'acceptation et laissez Codex exécuter les tests et la revue de code. C'est le moyen le plus efficace d'éliminer les allers-retours de validation manuelle.
07 Concernant les options secondaires : le mode rapide
Les six points précédents constituent la base de la méthodologie ; ce point est une option complémentaire à utiliser avec discernement.
Codex propose un mode rapide (Fast mode) qui permet d'accélérer les modèles compatibles d'environ 1,5 fois, en contrepartie d'une consommation de crédits plus importante. Selon la documentation officielle, ce mode est compatible avec GPT-5.5 (facturé 2,5 fois le tarif standard) et GPT-5.4 (facturé 2 fois).
Commandes de gestion dans le CLI :
/fast on Active le mode rapide
/fast off Désactive le mode rapide
/fast status Affiche le statut actuelPour activer ce mode par défaut, vous pouvez l'inscrire dans votre fichier ~/.codex/config.toml :
service_tier = "fast"
[features]
fast_mode = trueGardez à l'esprit deux conditions : d'une part, le mode rapide nécessite une connexion via un compte ChatGPT (il n'est pas disponible avec une clé API standard) ; d'autre part, cette vitesse supplémentaire a un coût financier (crédits).
En réalité, le mode rapide est une optimisation marginale. Le gros du gain de temps provient des six points précédents (précision des requêtes, gestion du contexte, adaptation du modèle, parallélisation, validation automatisée), car ils permettent d'économiser des cycles complets de modification. Le mode rapide ne fait que réduire le temps d'attente d'une réponse individuelle. Appliquez d'abord les bonnes pratiques de gestion de projet avant d'envisager de dépenser vos crédits pour cette option. Personnellement, je ne l'active que ponctuellement pour des tâches urgentes dont la valeur justifie ce coût.
💡 Résumé en une phrase : Le mode rapide augmente la vitesse de 1,5 fois contre des crédits supplémentaires. C'est une optimisation secondaire ; concentrez-vous d'abord sur la réduction des corrections en appliquant les bonnes pratiques.
08 Exercice pratique : reformuler une demande floue
Prenez cinq minutes pour faire cet exercice et mesurer l'impact sur le nombre d'allers-retours nécessaires.
Étape 1 : Choisissez une consigne floue typique, comme :
Aide-moi à ajouter un système de logs à ce projetÉtape 2 : Reformulez-la selon la structure en quatre points du paragraphe 02 :
Objectif : Mettre en place un module de journalisation (logging) unifié qui enregistre les messages INFO et ERROR dans la console et dans un fichier.
Contexte : S'inspirer de la lecture de configuration définie dans @utils/config.py, le niveau de log devant être lu depuis la configuration.
Contraintes : Utiliser la bibliothèque standard logging (pas de bibliothèque tierce) et ne pas modifier les signatures des fonctions existantes.
Critères de validation : Pouvoir importer le module dans le point d'entrée principal (main), écrire un log INFO dans logs/app.log et vérifier la création du fichier.Étape 3 : Soumettez séparément les deux versions à Codex dans deux sessions distinctes et comparez le nombre de messages. Lancez la version floue dans une première session. Observez si Codex vous pose des questions de clarification ou prend des décisions de son propre chef, et comptez le nombre d'échanges nécessaires pour obtenir le résultat voulu. Ouvrez ensuite une nouvelle session et soumettez la version structurée.
Ce que vous devriez observer :
- Avec la version floue : Codex vous demandera probablement des précisions (« où écrire les logs ? », « quels niveaux de sévérité ? », « avec quelle bibliothèque ? ») ou choisira une solution qui ne vous convient pas. Comptez au moins 3 allers-retours.
- Avec la version structurée : Le modèle va droit au but et réalise la tâche en 1 ou 2 messages, avec un résultat correspondant précisément à vos attentes.
L'intérêt de cet exercice est de vous faire réaliser concrètement que le temps passé à structurer votre demande en quelques lignes est largement récupéré en évitant les allers-retours de correction. C'est un choix toujours gagnant.
Une fois que vous maîtrisez cette formulation, inscrivez vos exigences de structure et de validation dans le fichier AGENTS.md pour que le modèle s'y conforme automatiquement à l'avenir.
💡 Résumé en une phrase : Comparez l'exécution d'une demande floue et d'une demande structurée pour constater par vous-même comment quelques lignes de contexte éliminent le besoin de retravailler le code.
Synthèse
Ce chapitre a redéfini la notion d'efficacité avec l'IA en la déplaçant de la vitesse de calcul vers la réduction des corrections de code :
- Le principe : Limiter le travail à refaire est plus efficace que de chercher la vitesse de réponse brute.
- La structure de la demande : Objectif + Contexte + Contraintes + Critères d'acceptation. Chaque détail manquant oblige le modèle à faire des suppositions.
- La gestion du contexte : Cibler les fichiers avec
@, compresser avec/compactet utiliser une session par tâche pour garder la mémoire du modèle propre. - L'adaptation du modèle : Utiliser
gpt-5.4-mini+lowpour les tâches de routine afin de gagner du temps et de l'argent. - La parallélisation : Utiliser les worktrees Git et les sous-agents pour mener plusieurs tâches de front sans conflit de code.
- La validation : Fournir des critères de validation et laisser Codex exécuter les tests et la revue de code pour réduire la supervision manuelle.
- Le mode rapide est une option secondaire à utiliser en dernier recours.
Vous devez maintenant être capable de : Structurer vos demandes selon la méthode en quatre points, cibler précisément le contexte avec @ et /compact, adapter le niveau du modèle et déléguer la validation des tests à Codex. En intégrant ces pratiques à vos habitudes de travail, vous augmenterez significativement votre productivité au quotidien en évitant au modèle de faire fausse route.
Le chapitre suivant 〔32 Migrer depuis Claude Code〕 s'adresse à un public spécifique : les utilisateurs effectuant la transition depuis Claude Code. Quelle est l'équivalence de CLAUDE.md ? Comment transposer les concepts de permissions, de Skills et de sous-agents ? Quelles habitudes conserver et lesquelles faire évoluer ? Nous verrons tout cela en détail.