Une IA peut produire du code impressionnant et rester pénible à utiliser dans un vrai projet.
Il suffit de devoir relancer une conversation, retrouver le bon fichier ou comprendre pourquoi un changement a touché une partie du système qui n’avait rien demandé.
J’avais abordé cette friction dans mon article sur T3 Code, en anglais. Mon article sur Claude Code Desktop, également en anglais prolongeait la réflexion sur l’espace de travail. Codex mérite lui aussi qu’on le regarde sous cet angle.
Pas comme une liste de promesses. Comme un outil que l’on doit pouvoir intégrer à sa journée.
La méthode — donner du contexte, découper le travail, vérifier — était déjà au cœur de mon article sur le vibe coding. Je ne vais pas la réenseigner ici. Regardons plutôt comment Codex permet de l’appliquer au sein d’un projet existant.
Le projet devient le point de départ
Dans sa version terminal, Codex peut inspecter un dépôt, modifier des fichiers et exécuter les outils locaux. Il propose aussi une revue des changements et des réglages de permissions. Documentation de Codex CLI
Ce qui m’intéresse ici, c’est le déplacement du point de départ. On ne prépare plus uniquement un extrait de code à coller dans une conversation. On peut demander à l’outil de commencer par regarder ce qui existe.
Pour un projet déjà vivant, c’est important. Une solution élégante mais étrangère aux conventions de l’équipe peut coûter cher à maintenir.
Choisir l’interface qui sert le travail
L’intégration dans l’éditeur permet de fournir les fichiers ouverts comme contexte et d’examiner les modifications sur place. Elle permet aussi de déléguer du travail plus long au cloud. Documentation de l’extension Codex
Le choix dépend donc aussi de tes habitudes. Si tu travailles beaucoup dans le terminal, ce chemin peut être naturel. Si tu veux garder le code et les changements sous les yeux, l’intégration à l’éditeur peut mieux te convenir.
Je ne choisirais pas uniquement sur la longueur de la liste des fonctionnalités. Je regarderais la facilité à comprendre ce qui se passe, à interrompre une mauvaise direction et à reprendre le travail.
Une tâche utile pour commencer
Prenons une application de gestion avec un export de factures qui ignore les filtres de l’écran.
Je commencerais par demander à Codex de retrouver le parcours concerné et d’expliquer le problème, sans modification. Ensuite seulement, je lui confierais une correction limitée, avec un test qui reproduit le cas.
Ce découpage donne deux occasions de vérifier la compréhension avant de multiplier les changements. Il évite aussi de transformer un bug d’export en refonte générale du module.
Dans sa documentation sur les tâches longues, OpenAI insiste sur les objectifs explicites, les jalons et les vérifications continues. Travailler sur des tâches longues avec Codex
Ce que je vérifierais avant de l’adopter
La question ne serait pas seulement : « A-t-il corrigé le bug ? »
Je regarderais aussi s’il a respecté les permissions, ajouté des dépendances inutiles, modifié des fichiers sans rapport avec la demande ou prétendu avoir exécuté un test indisponible.
Je garderais les données sensibles et les secrets hors du contexte inutilement partagé. Les autorisations de l’outil doivent correspondre à la tâche, pas à une envie d’éviter chaque demande de confirmation.
Enfin, je comparerais le temps réellement économisé après relecture. C’est moins spectaculaire qu’une démonstration, mais beaucoup plus utile pour décider.
Un outil à évaluer, pas une identité à adopter
Utiliser Codex ne demande pas de devenir partisan d’une marque.
On peut apprécier une interface, préférer un autre outil pour certaines tâches et continuer à suivre les alternatives. L’intérêt est de trouver un environnement dans lequel la délégation reste compréhensible et le résultat vérifiable.
C’est sur ce terrain que je trouve Codex intéressant : rapprocher les capacités du modèle du travail quotidien. Le reste se juge avec un dépôt, une tâche précise et un résultat que l’on accepte réellement de maintenir.