Mon workflow de développement IA entre ChatGPT, Codex, GitHub et une devbox

Je ne cherche pas à faire travailler une IA « toute seule » sur un projet. Mon objectif est presque inverse : construire un environnement où chaque outil a un rôle clair, où le code circule proprement entre mes machines et où je ne repaie pas plusieurs fois le même contexte.

Le système auquel je suis arrivé repose sur quatre briques : ChatGPT garde le contexte large et aide à décider, Codex travaille au contact du repository, GitHub transporte l’état du projet, et une devbox Linux distante me donne un environnement de travail disponible même quand ma machine principale n’est pas la bonne cible.

Cette séparation paraît plus compliquée qu’un seul gros agent au départ. En pratique, elle réduit beaucoup de friction : moins de conversations qui redécouvrent le projet, moins de clones contradictoires, moins de tentatives inutiles dans un environnement mal adapté, et surtout une utilisation plus rationnelle des modèles coûteux.

Séparer le cerveau, les mains et le transport

La première règle est de ne pas demander au même outil de tout faire.

Dans mon workflow, ChatGPT est le cockpit. J’y garde les conversations longues : compréhension du produit, arbitrages, architecture, diagnostic, choix de prochaine étape. C’est l’endroit où le problème peut encore être flou.

Codex est l’exécutant. Je l’utilise quand il faut ouvrir le repository, retrouver les patterns existants, modifier plusieurs fichiers, lancer des tests ou auditer une implémentation réelle.

GitHub est le bus de synchronisation. Il ne sert pas seulement à sauvegarder le code : il évite que chaque ordinateur ou agent devienne une source de vérité différente.

Enfin, la devbox distante est une machine de travail, pas une nouvelle source de vérité. Elle reçoit les repositories depuis GitHub, exécute les outils nécessaires et renvoie ses changements par Git.

Le modèle mental est donc simple :

ChatGPT
  ↓ cadre / décide
Codex local ou distant
  ↓ modifie le repository
Git
  ↓
GitHub
  ↓
autre machine / devbox

La conversation n’est pas le projet. Le VPS n’est pas le projet. Le dossier de mon PC n’est pas le projet. Le projet existe dans son repository versionné.

Garder le contexte large dans ChatGPT

Une erreur coûteuse consiste à demander à chaque nouvelle session de code de refaire toute l’analyse.

Je préfère conserver une conversation ChatGPT relativement longue autour d’un projet. Elle contient ce qui est encore mouvant : pourquoi une fonctionnalité existe, les alternatives examinées, les contraintes métier, ce que j’ai rejeté et ce que j’essaie d’obtenir.

Une fois la direction suffisamment claire, je transforme cette réflexion en mission beaucoup plus bornée pour Codex.

Au lieu de demander :

> Analyse le projet et améliore cette fonctionnalité.

je cherche plutôt à arriver à une instruction du type :

> Le problème est identifié. La direction retenue est celle-ci. Inspecte d’abord les propriétaires actuels de cette responsabilité, implémente le changement sans dupliquer de logique, lance les validations pertinentes et rapporte les limites restantes.

Codex n’a alors pas besoin de consommer des milliers de tokens pour reconstruire une décision déjà prise ailleurs.

La documentation du repository prend ensuite le relais pour les vérités durables. Une conversation conserve bien la réflexion active ; Git conserve mieux ce qui doit survivre aux conversations.

Utiliser Codex au contact du code, pas comme seconde réunion produit

Codex est particulièrement rentable lorsqu’il travaille sur quelque chose qu’il peut observer directement.

Je l’utilise pour :

• explorer une codebase avec une question précise ;
• retrouver les responsabilités existantes avant de créer du code ;
• modifier les fichiers concernés ;
• lancer lint, tests, typecheck ou build ;
• comparer l’implémentation à un contrat documenté ;
• effectuer un audit technique ou visuel lorsqu’il dispose réellement des outils nécessaires.

Je lui demande aussi de distinguer audit et exécution. Les deux n’ont pas toujours besoin du même modèle.

Par exemple, un diagnostic architectural difficile peut être confié à un modèle plus fort, puis l’implémentation d’une direction déjà décidée à un modèle plus économique.

Dans mon usage actuel de Codex, je raisonne grossièrement ainsi :

• Luna pour les changements mécaniques très cadrés ;
• Terra pour exécuter une direction claire sur plusieurs fichiers ou couches ;
• Sol pour les audits, diagnostics, choix d’architecture, de produit ou de design.

Même logique pour l’effort de raisonnement : je cherche le niveau le plus bas qui garde une fiabilité suffisante. Mettre systématiquement le meilleur modèle en effort maximal revient à envoyer un architecte senior changer chaque libellé d’un formulaire.

Faire de GitHub le point de passage entre les machines

Je travaille selon les périodes depuis Windows, WSL, macOS ou une machine Linux distante. Le piège naturel est d’accumuler les copies : un clone créé par Codex Desktop, un autre dans WSL, un troisième pour un test, un quatrième sur le VPS.

Très vite, on ne sait plus lequel contient le dernier travail non poussé.

Ma règle cible est donc : un clone canonique d’un projet par environnement dans lequel j’en ai réellement besoin.

Si je travaille principalement sur le repository depuis Windows, je ne le clone pas automatiquement dans WSL. Si j’ai besoin de l’exécuter sur ma devbox Linux, elle possède son clone à elle. Les deux communiquent par GitHub.

Le passage d’une machine à l’autre ressemble à quelque chose de volontairement banal :

git status
git add .
git commit -m "..."
git push

puis sur l’autre environnement :

git pull

Une branche peut évidemment être utilisée lorsque le chantier le justifie. L’important est surtout qu’un changement transportable devienne un état Git explicite plutôt qu’un dossier mystérieux à recopier.

Cette banalité est une force : Git résout déjà le problème de synchronisation du code. Je n’ai pas besoin d’inventer un système parallèle pour mes agents.

Ajouter une devbox distante toujours disponible

J’ai ensuite ajouté une petite VM Oracle Cloud sous Ubuntu comme devbox distante.

Son rôle n’est pas d’héberger tous mes services ni de devenir une plateforme de production. Elle sert d’environnement Linux stable sur lequel je peux installer Git, Codex CLI et les dépendances de mes projets.

Les clones canoniques peuvent par exemple vivre dans :

~/dev/
├── brand-os/
├── media-kit-v2/
├── dev-agent-config/
└── ...

L’intérêt principal n’est pas la puissance brute. C’est la continuité.

Mon PC peut être éteint. Je peux être sur un autre ordinateur. Je peux avoir besoin d’un environnement Linux propre sans mélanger ce travail avec WSL. La devbox reste disponible avec les mêmes repositories et les mêmes outils.

Elle est cependant traitée comme n’importe quelle autre machine : elle récupère le code depuis GitHub et pousse ses changements vers GitHub. Je ne synchronise pas directement ses dossiers avec mon PC.

Utiliser SSH comme couche d’accès et de preview

L’accès à la devbox se fait par SSH avec une clé.

Je configure généralement un alias local afin qu’une commande courte suffise :

Host codex
  HostName <adresse-du-serveur>
  User <utilisateur>
  IdentityFile ~/.ssh/<cle>

Je peux ensuite ouvrir la machine avec :

ssh codex

Le même principe fonctionne depuis plusieurs ordinateurs, et même depuis un mobile avec un client SSH lorsque je veux simplement reprendre une session, vérifier un état ou lancer une commande.

SSH sert aussi à voir une application distante sans ouvrir son port de développement sur Internet.

Si une application écoute sur 127.0.0.1:5173 sur la devbox :

ssh -L 5173:127.0.0.1:5173 codex

me permet de l’ouvrir depuis le navigateur de mon ordinateur sur :

http://localhost:5173

Le serveur reste privé ; le tunnel crée temporairement le tuyau entre les deux machines.

Cette approche évite d’ajouter un reverse proxy, un domaine ou une exposition réseau permanente pour une simple preview de développement.

Rendre l’agent conscient de son environnement

Une des dépenses de tokens les plus absurdes vient d’un agent qui essaie longtemps une action impossible.

Une session Codex sur mon PC, dans WSL ou sur ma devbox n’a pas les mêmes accès. Un navigateur présent sur une machine distante n’est par exemple pas forcément authentifié sur mes services web. Insister cinq fois ne le rendra pas plus authentifié.

J’essaie donc de documenter une règle d’environment awareness : avant une opération dépendante de la machine, l’agent doit identifier l’environnement dans lequel il tourne et adapter sa stratégie.

Je veux notamment une séparation explicite entre :

• de son côté : inspection du code, commandes, tests, modifications, logs accessibles ;
• de mon côté : validation dans un navigateur authentifié, action nécessitant une session locale, manipulation d’un outil auquel l’agent n’a pas accès.

L’agent doit aussi choisir la validation la moins coûteuse suffisante. Tester une fonction avec une suite existante est souvent préférable à ouvrir immédiatement un navigateur. Inspecter la configuration d’un projet est préférable à tenter au hasard une connexion externe.

Un bon agent n’est pas celui qui essaie tout. C’est celui qui sait rapidement ce qu’il n’a pas besoin d’essayer.

Porter les règles et le contexte entre les machines

Une fois le workflow de base stable, j’ai ajouté une couche supplémentaire : un repository séparé, dev-agent-config.

Il contient les règles et méthodes que je veux retrouver dans mes différents environnements : configuration globale, skills spécialisés, politiques de travail et certains contextes de session.

L’intérêt d’un repository séparé est de ne pas polluer chaque projet applicatif avec ma configuration personnelle tout en gardant cette configuration versionnée.

Sur une nouvelle machine, le principe devient :

1. installer les outils de base ;
2. cloner dev-agent-config ;
3. lancer son installation ou sa synchronisation ;
4. retrouver les mêmes garde-fous dans Codex ou les autres outils compatibles.

Je complète cela par de la documentation directement dans les projets : AGENTS.md comme routeur, CURRENT.md pour l’état actif, DECISIONS.md pour les arbitrages durables, puis des documents ciblés pour les standards qui méritent réellement une source de vérité.

La règle est la même à chaque niveau : ne pas injecter tout le contexte partout. Les instructions doivent aider l’agent à charger ce dont il a besoin pour la mission présente.

Ce que j’essaie volontairement d’éviter

Ce système n’est pas une invitation à empiler l’infrastructure.

Je cherche au contraire à éviter plusieurs anti-patterns que j’ai rencontrés :

• créer un nouveau clone à chaque session ou pour chaque agent ;
• laisser un agent choisir systématiquement le modèle le plus coûteux ;
• faire relire toute la documentation du projet pour une modification locale ;
• dupliquer des vérités entre conversation, README, prompt et fichiers internes ;
• exposer un serveur de développement publiquement alors qu’un tunnel SSH suffit ;
• demander à une machine distante de reproduire des actions qui dépendent de ma session locale ;
• construire des sous-agents ou automatisations avant d’avoir un problème réel qu’ils résolvent ;
• confondre continuité de contexte et synchronisation magique du code non commité.

La documentation systématique, les skills et les résumés de session sont utiles uniquement s’ils réduisent le coût de reprise. S’ils deviennent un rituel plus lourd que la reconstruction qu’ils évitent, ils doivent être simplifiés.

Une mise en place progressive

Je ne conseillerais pas de copier tout le système d’un coup.

Pour quelqu’un qui démarre, l’ordre suivant suffit :

1. Un repository local propre et GitHub. Comprendre clairement où vit la source de vérité.
2. ChatGPT pour le cadrage, Codex pour le repository. Ne pas mélanger automatiquement leurs responsabilités.
3. Un choix explicite de modèle et d’effort. Le coût doit suivre la difficulté réelle.
4. Une discipline de clones. Un clone canonique par environnement utile.
5. Une devbox Linux seulement si le besoin existe. Elle reste un client Git parmi les autres.
6. Des clés SSH et un alias simple.
7. Les tunnels SSH lorsque des previews distantes sont nécessaires.
8. Une documentation agent-friendly quand le coût de reprise du projet commence à devenir sensible.
9. Une configuration portable des agents seulement lorsque plusieurs machines ou plusieurs outils justifient réellement cette couche.

Au final, ce workflow optimise moins « l’autonomie de l’IA » que la continuité du travail. Je peux réfléchir depuis une conversation, exécuter localement, reprendre sur une devbox, changer de machine et revenir plusieurs jours plus tard sans que chaque nouvel agent recommence depuis zéro.

C’est ce que je cherche aujourd’hui : pas un agent qui fait tout, mais un système suffisamment clair pour que le bon agent puisse faire la bonne chose, dans le bon environnement, avec juste le contexte nécessaire.