Ma répartition est simple : par défaut, c’est Claude Code qui fait le travail lui-même. Codex ne prend que deux sortes de tâches : plusieurs tâches de code sans rapport entre elles à mener en parallèle, ou un énorme travail mécanique ponctuel. Quand j’hésite, je n’envoie rien à Codex : Claude Code s’en charge lui-même.

Ce billet ne compare ni les fonctionnalités, ni les prix, ni les versions. Il raconte seulement comment je répartis le travail, pourquoi, et dans quels pièges je suis tombé. Il fait suite à mon billet de juin, Avec Claude depuis quelques mois, j’ai mis Codex et ChatGPT de côté, où ma répartition était la suivante : Claude distribue les tâches, Codex fait le travail mécanique. Pour savoir utiliser Codex lui-même, le site propose aussi un guide complet pour les non-programmeurs.

La répartition

Voici la répartition que j’ai aujourd’hui écrite dans mes règles, sous la forme « quel travail → pour qui → pourquoi ».

  • Petites corrections, développement de fonctionnalités, débogage, itérations qui dépendent de beaucoup de contexte, et tout travail qui demande du jugement ou ne tolère pas l’erreur → Claude Code s’en charge lui-même. Pourquoi : plus rapide et plus juste, aucune information perdue, pas de coût de passation ni de relecture.
  • Plusieurs tâches de code sans rapport entre elles, à mener en même temps → Codex. Pourquoi : ce qu’il me faut, c’est du débit, plusieurs choses faites à la fois.
  • Un énorme travail mécanique ponctuel, par exemple modifier des centaines de fichiers en masse → Codex. Pourquoi : je veux garder la conversation en cours légère.
  • Dans le doute → Claude Code s’en charge lui-même. Pourquoi : confier un travail à Codex oblige à rédiger un brief complet et autonome, puis à relire le résultat avec rigueur ; en le faisant lui-même, on évite ce coût de passation et de relecture.
  • Mise en ligne, suppression, paiement, envoi vers l’extérieur → c’est moi qui valide, quel que soit celui qui travaille. Pourquoi : une fois fait, on ne peut pas revenir en arrière.

Ici, « Claude Code s’en charge lui-même » inclut aussi les sous-agents Claude qu’il envoie : de petits assistants que l’IA principale dépêche pour travailler seuls et qui ne ramènent que la conclusion.

Qui fait quoi

Claude Code est le chef d’orchestre : il découpe les tâches, les distribue, vérifie les résultats et rend compte. Codex est l’exécutant : il reçoit une tâche, la découpe lui-même, la mène jusqu’au bout, vérifie son propre travail, puis fait son rapport. Je l’ai écrit dans ses règles : il est envoyé pour terminer la tâche, pas seulement pour planifier.

Dans mon billet de juin, j’ai décrit leur tempérament. Codex ressemble à un programmeur : il faut exprimer le besoin très clairement, il est très fort de 0 à 90 %, et les 10 % restants demandent de longues retouches. Claude ressemble plutôt à un patron, plus proche de la façon de réfléchir d’une personne, avec un coût de communication un peu plus bas. Cela rejoint mes règles actuelles : tout travail confié à Codex doit être rédigé sous forme de brief complet et autonome, et le résultat est relu avec rigueur.

Le travail confié à Codex suit un processus fixe. D’abord, on arrête « quoi modifier et comment », puis on fait une simulation (on regarde ce qui changerait, sans rien changer). Une fois que j’ai donné mon accord, Codex travaille sur une branche dédiée (une ligne de modifications séparée de la version principale). Quand il a fini, Claude Code relit le diff (la liste des modifications) et lance les tests, et ce n’est qu’ensuite qu’on fusionne. Tout ce qui touche au site en ligne, à un déploiement ou à la suppression de données attend mon feu vert. Mes mots, quand j’ai fixé ce processus fin juin : « Il ne s’agit pas de tout modifier d’un coup, mais de décider d’abord, puis de modifier. »

Pourquoi Claude Code par défaut

D’abord, il y a le coût de la passation et de la relecture : chaque fois que je confie un travail à l’autre outil, j’ajoute un tour de « tout réexpliquer » et un tour de « relire après coup ». C’est encore plus vrai pour les itérations qui dépendent de beaucoup de contexte : tout le contexte est déjà dans la conversation en cours, donc quand Claude Code s’en charge lui-même, aucune information ne se perd.

L’autre coût, c’est la taille de la conversation. Ma règle : le processus va aux sous-agents, et la conversation principale ne garde que la conclusion. Mes mots : « Dans la conversation, je n’ai pas besoin de connaître le détail de l’analyse, et je n’ai pas le temps de le lire. Confiez ça aux sous-agents : je n’ai besoin que du résultat d’ensemble. » Lors d’une mesure fin septembre, les 1 110 sous-agents passés sur mon ordinateur ont consommé en interne, en médiane, environ 42 000 tokens (l’unité avec laquelle l’IA compte le texte), et n’en ont rapporté qu’environ 900 à la conversation principale. Plus la conversation principale grossit, plus elle est compressée souvent, et plus l’IA oublie. J’ai écrit cette règle dans les fichiers de règles des deux outils, et c’est l’une des raisons pour lesquelles les énormes travaux mécaniques vont à Codex.

Quatre pièges dans lesquels je suis tombé

1. Le blocage. C’est le problème dont je me plains le plus. Quand j’envoie du travail à Codex ou que je lance une longue commande, si elle tourne au premier plan, ou si l’IA écrit « j’attends que Codex ait fini avant de continuer » et termine son tour, elle ne se réveillera pas toute seule, et la conversation reste figée là. Ma règle aujourd’hui : ce genre de travail tourne toujours en arrière-plan ; à la fin, le système réveille automatiquement l’IA, qui vérifie le résultat et poursuit, sans que j’aie à la relancer. Les tests, les robots d’exploration et les gros téléchargements suivent la même règle.

Dans Claude Code, il existe un piège voisin : un sous-agent qui tourne au premier plan est interrompu par n’importe quel nouveau message de ma part et enregistré comme « arrêté par l’utilisateur ». Si j’attends longtemps et que je demande « c’est fini ? », je viens de le tuer. Les tâches en arrière-plan ne sont pas concernées.

Une autre façon de rester bloqué, c’est de s’acharner sur un petit élément ; les règles des deux outils contiennent donc la même clause : sauvegarder après chaque élément terminé ; si un élément échoue deux fois, le sauter et noter « à traiter à la main » ; toujours livrer un résultat partiel, jamais zéro résultat. Par exemple, si 3 éléments sur 30 échouent, livrer quand même le tableau récapitulatif des 27 autres et la liste des 3.

2. L’écrasement mutuel. Sur un projet, Claude et Codex ont travaillé en alternance, et l’ancienne version a écrasé la nouvelle. Il s’est avéré que ce projet n’était alors pas un dépôt git (un dossier de projet qui enregistre chaque modification) : ce qui était écrit en dernier écrasait simplement ce qui avait été écrit avant, sans retour possible.

Aujourd’hui, il y a trois couches. Les projets deviennent des dépôts git, si bien qu’un écrasement accidentel se récupère. Une tâche n’a qu’un seul rédacteur à la fois : avant de modifier un projet, on vérifie que personne d’autre n’y travaille ; le verrou ne se prend que si c’est le cas ; si on ne l’obtient pas, on va faire autre chose au lieu de forcer ; et un verrou expire tout seul au bout de deux heures. Enfin, avant de commencer, on lit le fichier d’avancement du projet. Pour Codex, une règle s’ajoute : avant de lui envoyer du travail, on vérifie que le projet cible n’a pas de modifications non validées ; il ne travaille que sur une branche propre et ne supprime ni n’écrase rien.

3. Les sous-agents d’une même conversation se percutent aussi. Une conversation Claude a envoyé deux sous-agents : l’un corrigeait le menu hamburger du site, l’autre travaillait en même temps sur les performances, sur le même lot de fichiers. Le second est parti de la version en ligne et, après son déploiement, le site en ligne contenait « les optimisations de performance, sans la correction du menu ». La cause profonde, c’était un mauvais point de départ, pas la vitesse de frappe : partir de la version en ligne avale forcément toutes les modifications locales pas encore publiées. Au final, une fusion à trois voies a tout remis ensemble, mais c’était de la chance : les deux modifications n’ont simplement pas touché la même ligne. Ma règle aujourd’hui : le miroir local (la copie conservée en local) est la seule référence ; les sous-agents qui modifieraient les mêmes fichiers passent soit l’un après l’autre, soit se répartissent les fichiers.

4. Des règles écrites dans le mauvais fichier. Claude Code lit CLAUDE.md ; Codex lit l’AGENTS.md de son propre dossier global. Chacun lit le sien. Fin septembre, une IA est allée modifier les règles de Codex et a modifié un fichier miroir que Codex ne lit pas en temps normal (la copie de CLAUDE.md où « Claude » est remplacé par « Codex »). Il a fallu un test, le lendemain, pour le découvrir. Autre point : les instructions d’outil de Codex lui interdisent de lancer des sous-agents sans demande explicite de l’utilisateur ou d’un fichier de règles ; j’ai donc écrit un paragraphe d’autorisation explicite dans son fichier de règles.

Si vous ne codez pas

Quelques points à reprendre tels quels :

  • Laissez un seul outil mener le travail jusqu’au bout. N’en faites venir un second que si l’un de ces deux signaux apparaît : plusieurs choses sans rapport entre elles à faire en même temps, ou un gros travail mécanique ponctuel. Dans le doute, restez sur le premier.
  • Gardez l’avancement dans un fichier du projet, pas dans le chat. J’utilise COWORK.md, avec quatre lignes fixes en haut : état actuel, prochaine étape, point bloquant, mise à jour. Quand vous changez d’outil ou de conversation, le nouvel arrivant le lit d’abord et reprend à partir de là, et vous n’avez pas à servir de messager. La conversation n’est que la main qui travaille ; la mémoire est dans les fichiers.
  • Faites du projet un dépôt git, et ne laissez qu’une seule IA modifier un même lot de fichiers à la fois. Le premier protège contre « c’est cassé et je ne peux pas revenir en arrière », le second contre « deux modifications en même temps ».
  • Exigez des preuves quand le travail est rendu, et n’acceptez pas un simple « terminé ». Exigez que l’IA vérifie de bout en bout avant de dire « corrigé » ; quand un sous-agent fait son rapport, contrôlez par sondage les preuves clés. Pour les e-mails et les messages sortants, l’IA ne rédige que des brouillons, et n’envoie que lorsque je dis explicitement « envoie » ; « OK » ou « d’accord » ne comptent pas.