Codex devient un workspace, pas seulement un agent de code
· 3 min read · Filippo Spinella · AI, Codex, Developer Tools, Productivity
Ce qui m'a marqué dans la nouvelle annonce autour de Codex, ce n'est pas le mot plugin. C'est l'idée que Codex essaie de devenir un endroit où le travail prend forme.
OpenAI a publié Codex for every role, tool, and workflow le 2 juin 2026. Les nouveautés visibles sont les plugins par rôle, Sites et les annotations. Mais la vraie question est plus simple: est-ce qu'un agent peut transformer du contexte dispersé en quelque chose qu'une équipe peut relire, discuter et améliorer?
Le vrai changement
Pendant longtemps, Codex était facile à résumer: il aidait les développeurs à modifier du code. Cette mise à jour rend cette définition trop petite. Les nouveaux plugins parlent aussi à l'analytics, au sales, au product design, à la production créative, à l'investissement public et à la banque d'affaires.
Cela veut dire que Codex ne lit plus seulement un dépôt. Il peut partir d'un dashboard, d'une note CRM, d'un document, d'une feuille de calcul, d'un brief design ou d'une source financière pour produire un artefact de travail.
C'est là que ça devient utile. La plupart des équipes n'ont pas besoin d'une nouvelle réponse dans un chat. Elles ont besoin d'une page, d'une salle de lancement, d'un board de revue, d'un planner, d'une petite app interne ou d'un dashboard que tout le monde peut ouvrir.
Sites est la partie à surveiller
Sites me semble être la pièce la plus concrète. Une réponse de chat disparaît dans le fil. Un site a une URL. On peut le partager, le commenter, y revenir et demander à Codex de mettre à jour seulement ce qui a changé.
Je le vois bien pour un lancement produit, une revue client, une business review hebdomadaire, un mémo investisseur ou un outil interne. Pas parce que la première version sera parfaite. Elle ne le sera pas. L'intérêt est de donner à l'équipe un objet commun.
Les annotations rendent le feedback moins flou
Les annotations comptent aussi. Si je dis rends ça plus clair, l'agent peut toucher trop de choses. Si je pointe un graphique, un paragraphe ou une section, la demande devient plus nette.
C'est ainsi que l'édition fonctionne vraiment. On veut rarement tout réécrire. On veut une phrase plus précise, un graphique moins confus, une slide moins chargée, un tableau mieux trié.
Comment je le testerais
Je ne connecterais pas tous les outils le premier jour. Je choisirais un workflow ennuyeux, avec des responsables clairs. Une revue business hebdomadaire est parfaite: quelques métriques, quelques notes, un livrable partagé, puis une revue humaine avant l'envoi.
La checklist tient en peu de lignes:
- décider quelles sources Codex peut lire;
- décider ce qu'il peut écrire;
- exiger des liens vers les sources importantes;
- nommer un propriétaire pour chaque artefact;
- archiver ou supprimer ce qui ne sert plus.
Le danger n'est pas une mauvaise première version. Les équipes savent survivre aux mauvaises premières versions. Le danger, c'est la prolifération: dix sites générés, aucun propriétaire, aucune trace des sources et personne ne sait quelle version fait foi.
Ma lecture
Cette annonce montre que les agents quittent la scène de la démo. Les bons agents ne seront pas les plus spectaculaires. Ce seront ceux qui entrent dans le rythme d'une équipe: rassembler le contexte, produire un brouillon, garder la trace, accepter un feedback précis et respecter les limites.
Pour les développeurs, cela ne rend pas l'ingénierie moins importante. Cela la rend plus importante. Quelqu'un doit encore définir les permissions, les valeurs par défaut, les points de revue et ce que fini veut dire.