Blog / · 6 min de lecture
Codex sort du terminal. C'est là que les choses deviennent sérieuses.
Codex arrive dans GitHub, mobile, IDE et sites partageables. Le sujet n'est plus seulement l'agent qui code, mais l'endroit où son travail devient visible.
Au début, Codex ressemblait encore à un outil de dev.
Un terminal. Un repo. Une tâche. Un diff. Une PR.
C’était déjà puissant, mais l’image mentale restait confortable : un agent de code pour des gens qui codent.
Les annonces récentes changent un détail important. Codex se rapproche de GitHub, des IDE, du mobile, et même de surfaces où il peut produire des sites ou apps interactives partageables.
Dit autrement : Codex sort du terminal.
Et quand un agent sort du terminal, il ne change pas seulement le workflow des développeurs. Il commence à changer la manière dont une équipe produit fabrique, montre, valide et jette des idées.
L’agent de code était un outil. Il devient une surface de travail.
Un outil de code prend une instruction et modifie un repo.
Une surface de travail fait plus que ça :
- elle reçoit une demande depuis un ticket ;
- elle produit un artefact visible ;
- elle permet à quelqu’un de commenter ;
- elle garde une trace ;
- elle s’intègre au cycle de décision ;
- elle rend le travail partageable à des non-devs.
C’est là que les choses deviennent intéressantes.
Tant que Codex vit seulement dans le terminal, il reste dans les mains des développeurs. Quand il arrive dans GitHub, dans mobile, dans les workflows business et enterprise, il commence à toucher les PM, les designers, les ops, les fondateurs.
Pas parce que tout le monde va devenir développeur.
Parce que plus de gens pourront déclencher du travail logiciel sans ouvrir un éditeur.
Le vrai produit, c’est la délégation
OpenAI décrit Codex comme un agent capable de travailler sur plusieurs tâches en parallèle dans des environnements isolés. GitHub permet déjà de lancer des agents depuis des issues, des PR, VS Code ou l’interface web. On voit la direction.
Le produit n’est plus “écris du code”.
Le produit devient : délègue une intention technique à un système qui sait où travailler.
Exemples :
- “prépare une variante de cette landing page” ;
- “corrige le bug remonté dans cette issue” ;
- “ajoute un export CSV à ce dashboard” ;
- “fais une première passe sur cette dette technique” ;
- “transforme ce brief en prototype cliquable”.
Le résultat peut être une PR. Mais il peut aussi être une preview, un site temporaire, un rapport, une branche, une checklist de blocages.
Le diff n’est qu’un format de sortie parmi d’autres.
Ça va changer le rôle du développeur, mais pas comme on le raconte
Le discours paresseux dit : “les développeurs vont disparaître”.
Non.
Ce qui disparaît, c’est une partie du monopole sur le déclenchement du travail technique.
Avant, si un PM voulait tester une micro-variation produit, il fallait convaincre un dev, attendre un créneau, écrire un ticket, passer dans le backlog. Demain, il pourra peut-être lancer un agent qui prépare une branche ou un prototype, puis demander une review.
Ça ne supprime pas le dev.
Ça déplace son rôle vers :
- cadrer les garde-fous ;
- relire les changements ;
- maintenir l’architecture ;
- décider ce qui mérite d’être mergé ;
- transformer des prototypes jetables en logiciel durable.
Le danger n’est pas que les non-devs fassent des prototypes. C’est qu’on merge des prototypes comme si c’était du code produit.
La dette va naître plus vite
Un agent qui rend la création moins chère rend aussi la création excessive plus probable.
On va voir des branches partout. Des variantes de pages. Des composants temporaires. Des scripts “juste pour tester”. Des prototypes qui devaient mourir et qui restent parce qu’un client les a vus.
La vitesse de génération augmente.
La discipline de suppression devra augmenter aussi.
Le workflow mature ne sera pas “Codex peut tout créer”. Ce sera :
- créer vite ;
- montrer vite ;
- jeter vite ;
- ne garder que ce qui mérite une vraie intégration.
La capacité à supprimer va devenir une compétence produit. C’est moins glamour que “vibe coding”, mais beaucoup plus important.
Le mobile est plus intéressant qu’il n’en a l’air
Codex dans une app mobile peut sembler gadget. Personne ne va review une migration Laravel sérieuse sur un écran de téléphone.
Mais ce n’est pas le cas d’usage.
Le cas d’usage, c’est :
- lancer une tâche en sortant d’un rendez-vous ;
- commenter un résultat ;
- approuver une direction ;
- demander une variante ;
- vérifier qu’un agent n’est pas bloqué ;
- lire un résumé propre.
Le mobile transforme l’agent en collègue asynchrone. Pas en IDE miniature.
Et ça, pour les fondateurs, PM, freelances et petites équipes, c’est très concret. Une idée capturée à 18h12 peut devenir une branche prête à relire à 19h.
Reste à savoir si c’est une bonne idée. Mais techniquement, le chemin s’ouvre.
Là où je reste prudent
Plus l’agent devient accessible, plus il faut des permissions propres.
Un agent lancé depuis GitHub ou mobile doit savoir :
- quels repos il peut toucher ;
- quelles commandes il peut exécuter ;
- quelles données il peut lire ;
- s’il peut pousser une branche ;
- s’il peut ouvrir une PR ;
- s’il peut déclencher une preview ;
- s’il doit demander validation avant certaines actions.
Sinon, on remplace le vieux problème “un stagiaire a push sur main” par “un agent a modifié un truc parce que quelqu’un a mal formulé une demande”.
La délégation sans garde-fous n’est pas de l’autonomie. C’est juste du flou avec des permissions.
Le changement culturel
Le point le plus intéressant n’est pas technique. Il est culturel.
Les équipes vont devoir apprendre à écrire des demandes qui produisent du bon logiciel. Pas des prompts magiques. Des briefs de travail.
Un bon brief Codex devrait ressembler à un bon ticket :
- contexte ;
- objectif ;
- non-objectifs ;
- fichiers ou zones concernées ;
- critères d’acceptation ;
- commandes de vérification ;
- niveau de liberté ;
- format attendu du résultat.
La différence, c’est que le ticket ne dort plus trois semaines dans un backlog. Il peut commencer à s’exécuter immédiatement.
Donc les mauvais briefs coûteront plus vite quelque chose.
Mon verdict
Codex qui sort du terminal est une étape plus importante qu’elle n’en a l’air.
Pas parce que l’agent devient soudain magique. Parce qu’il entre dans les surfaces où les décisions se prennent : GitHub, IDE, mobile, previews, workflows d’équipe.
La prochaine bataille ne sera pas seulement “quel modèle code le mieux”.
Ce sera : quel outil transforme une intention floue en artefact reviewable sans salir le produit ?
Celui qui gagne ça ne sera pas juste un assistant de code. Ce sera une nouvelle couche de fabrication logicielle.
Et comme toutes les couches de fabrication, elle aura besoin d’une chose que les démos oublient souvent : des règles.
Sources
Continuer la lecture