OpenAI Codex Product Lead raconte : sans normes ni feuille de route, comment avons-nous créé le produit ?

« L’intérêt et l’autonomie sont les qualités humaines les plus essentielles et les plus importantes à l’ère de l’AGI. »

Compilation & compilation : Deep Tide TechFlow

Invités : Alex, responsable produit chez Codex ; Romain, développeur de l’expérience développeur

Animateur : Peter Yang

Source du podcast : Peter Yang

Titre original : How OpenAI’s Codex Team Builds with Codex (43 Min) | Alex & Romain

Date de diffusion : 2026年4月5日

Points clés

Alex est le responsable produit de Codex, et Romain gère l’expérience développeur. Ils m’ont fait découvrir, rarement, la façon dont l’équipe Codex fonctionne, notamment la manière dont ils utilisent Codex pour construire des produits, ainsi que la façon dont ils publient un produit sans les normes produit traditionnelles ni de feuille de route. Alex a aussi partagé des perspectives uniques sur l’évolution future du métier de chef de produit (PM), ainsi que sur les facteurs qui comptent réellement lors du recrutement.

Résumé des points forts

Construction en temps réel et « vitesse de pensée » de Codex Spark

• « Quand tu veux construire quelque chose… tu peux passer en mode rapide, voire sur Codex Spark, et tu obtiens cette vitesse de pensée folle, pour construire n’importe quoi. À gauche, il y a GPT-5.4, et à droite, Codex Spark. Et en moyenne, environ 1200 données (tokens) par seconde. Cette vitesse est totalement dingue. » —Romain

À propos des documents de spécifications et du processus de décision

• « Je pense que l’équipe Codex écrit vraiment, vraiment très peu de documents de spécifications. En fait, je pense qu’une grande partie du travail consiste à permettre aux personnes les plus proches de la réalité de prendre le maximum de décisions possible, donc nous n’écrivons des spécifications que lorsque le problème finit par devenir un type de problème si difficile à faire rentrer dans la tête d’une seule personne. » —Alex

Les frontières de carrière qui s’estompent et l’évolution des designers

• « Les designers de notre équipe écrivent aujourd’hui plus de code que les ingénieurs il y a six mois. Maintenant, notre priorité n’est plus “est-ce qu’on peut générer du code”, mais plutôt : ce que nous décidons de construire, et comment garantir la haute qualité du produit. C’est aussi pour ça que, pour des fonctionnalités très complexes, je préfère trouver un responsable solide pour piloter plutôt que de laisser le chef de produit (PM) être responsable de la mise en œuvre et de la maintenance de ces systèmes. » —Alex

Philosophie de conception produit : rendre le modèle “invisible”

• « Nous concevons avec beaucoup de prudence les fonctionnalités centrales, pour nous assurer qu’elles ne deviennent pas un obstacle entre les utilisateurs et le modèle, mais au contraire pour rendre le modèle plus intelligent, qui accomplit automatiquement davantage de tâches. » —Alex
• « Ensuite, à partir de là, nous réfléchissons à la façon d’emballer le produit pour les utilisateurs avancés de manière aussi configurable que possible, afin qu’ils puissent eux-mêmes l’explorer et l’utiliser. Par exemple, maintenant, certains utilisateurs ont déjà mis en œuvre des sub-agents (sous-agents). » —Romain

Philosophie de planification : refuser le “malaise de la mi-parcours”

• « Chez OpenAI, soit on planifie des objectifs à court terme, soit des objectifs à long terme, mais on ne fait jamais de planification à mi-parcours, parce que la planification à mi-parcours est trop complexe. La planification à court terme désigne généralement des objectifs allant d’aujourd’hui jusqu’à au plus huit semaines ; huit semaines, c’est la plage de temps la plus longue que nous pouvons définir. Nous définissons aussi une vision à long terme. Par exemple, on peut se projeter dans l’avenir d’ici un an, en imaginant qu’à ce moment-là le modèle sera devenu plus intelligent ; mais la planification à mi-parcours devient alors un peu gênante : elle se présente généralement comme une feuille de route produit détaillée, mais nous n’avons fondamentalement pas ce genre de choses. Nous nous appuyons davantage sur la vision à long terme et nous nous concentrons sur des tâches concrètes qui peuvent nous aider à atteindre nos objectifs. » —Alex

Transformation de l’interface grâce à la “délégation d’agents intelligents”

• « Le codage se fera d’une manière de “délégation d’agents intelligents” (agentic delegation). Tu te dis que, dans un terminal, ouvrir plusieurs onglets et les laisser tourner pendant quelques heures, c’est une forme d’interaction assez étrange. Nous avons besoin d’une toute nouvelle interface, et ce moment est parfaitement opportun. » —Romain

Disparition des échelons professionnels et “effondrement du vivier de talents”

• « Cela rend presque flous tous les échelons professionnels traditionnels. En réalité, nous sommes tous des “builders (constructeurs)”, et tout le monde coopère pour construire. Si une startup a un PM, mais moins d’environ 20 ingénieurs, cela peut être un signal dangereux. L’intérêt et l’autonomie sont les qualités humaines les plus fondamentales et les plus importantes à l’ère de l’AGI. » —Romain / Alex

Critères de recrutement : les réalisations valent mieux que le CV

• « Quand quelqu’un me contacte en message privé pour me dire qu’il est intéressé à rejoindre notre équipe, ma première réaction est de vérifier s’il y a des liens vers des réalisations. S’il y a des liens, j’ouvre toujours pour voir s’ils construisent vraiment quelque chose : je préfère voir leurs idées et ce qu’ils ont réellement construit. Je n’ai absolument aucune idée de quelle université ces personnes ont fréquentée. » —Alex

Démo en direct : construire un jeu en quelques secondes avec Codex Spark

Animateur Peter : Je suis vraiment excité d’animer Alex et Romain aujourd’hui : ils viennent de l’équipe Codex chez OpenAI. Ils vont faire une démonstration pour montrer comment construire les nouvelles fonctionnalités de Codex, quelles sont ses capacités, et comment l’équipe Codex publie en continu des produits. Vous voulez une démo rapide de ce qu’il est concrètement possible de construire avec une seule instruction (one-shot) ?

Romain :

Bien sûr. Laissez-moi partager mon écran. En réalité, il y a plein de choses que je peux montrer, mais peut-être un aperçu rapide : par exemple, voici une application iOS sur laquelle je travaille en ce moment. Si je veux créer une nouvelle fonctionnalité pour cette application, je peux simplement dicter : « Hé, peux-tu ajouter un nouvel écran à une mission de retour vers la lune pour la NASA ? » Ensuite, j’envoie cette instruction avec GPT-5.4, et le modèle crée un nouvel écran spécifique pour cette APP.

Mais nous avons aussi un modèle Codex Spark, qui peut vous aider à concevoir et itérer sur n’importe quoi en seulement quelques secondes. Laissez-moi vous montrer la différence de réponse rapide : à gauche, GPT-5.4 ; à droite, Codex Spark. Ensuite, en moyenne, vous obtenez environ 1200 données par seconde, c’est complètement dingue. Donc quand vous voulez construire quelque chose, par exemple un jeu — juste avant de démarrer cette conversation, je suis allé dans l’application Codex et j’ai créé, avec une instruction rapide, un petit jeu 2D qui ressemble à Animal Crossing.

Quand j’ai des idées claires, j’adore aussi utiliser une autre fonctionnalité de Codex : j’ouvre Codex, et la conversation flotte en haut de l’écran, ce qui me permet de continuer à itérer et à produire encore plus d’idées pendant que je fais réellement ce jeu. Tu as des idées, Peter, sur ce que tu voudrais changer dans ce jeu ?

Peter : Peut-être ajouter quelques décorations en plus, des maisons, des arbres, etc., pour que ce soit plus vivant ?

Romain :

Alors je vais envoyer cette tâche, et en gros, en quelques secondes, Codex Spark va faire l’édition. On va voir les changements en temps réel, et c’est tout : on vient de voir apparaître de nouveaux arbres.

C’est donc pour ça que je suis aussi tellement excité par Codex : tu peux vraiment disposer de modèles de pointe comme GPT-5.4, qui peuvent gérer des tâches extrêmement complexes, comme analyser ou migrer des millions de lignes de code. Mais quand l’inspiration arrive et que tu as les idées claires, tu peux passer en mode rapide, voire sur Codex Spark, et tu obtiens cette vitesse de pensée folle pour construire n’importe quoi.

Pour les spécifications produit, on n’en écrit qu’environ 10 points, c’est tout

Animateur Peter : Je suis vraiment curieux de savoir comment vous construisez réellement des produits au sein de votre équipe avec Codex. Alex, vous écrivez encore des spécifications ? Ou vous laissez GPT écrire une spécification ? Quel modèle utilisez-vous pour faire fonctionner tout ça ?

Alex :

Je pense que dans l’équipe Codex, on écrit vraiment, vraiment très peu de documents de spécifications. En fait, je pense que la majeure partie du travail consiste à faire en sorte que les personnes les plus proches de la réalité prennent le maximum de décisions possible, donc nous n’écrivons des spécifications que lorsque le problème finit par devenir quelque chose d’impossible à faire entrer dans la tête d’une seule personne. Pour dire les choses clairement : une personne peut mettre énormément de choses dans sa tête, parce qu’elle peut faire beaucoup de choses — elle délègue la majeure partie du travail de codage, donc une personne peut en faire beaucoup. Mais si, au final, cela nécessite de coordonner plusieurs personnes, ou peut-être de prendre une décision très délicate, alors peut-être qu’on écrit une spécification. Mais dans ces cas-là, les documents qu’on écrit sont en général très, très courts. On en parle comme 10 points clés, puis c’est tout.

Animateur Peter : D’accord. Vous pouvez me montrer comment ça marche ? Par exemple, vous donnez à Codex quelques points clés, et ensuite il écrit d’abord des besoins concrets ?

Romain :

Bien sûr. Mais je veux d’abord te montrer un exemple plus simple. Supposons que nous développions une application iOS, et qu’elle a déjà accompli certaines tâches. Maintenant, tu as des idées pour de nouvelles fonctionnalités pour ce projet, mais tu n’es pas sûr de la direction exacte. À ce moment-là, la force de Codex, c’est qu’il peut nous aider à planifier la prochaine étape. Par exemple, il me suffit d’appuyer sur Shift+Tab pour entrer dans le “mode de planification” (Plan Mode), puis de saisir “Ce qu’on doit construire”. Codex va automatiquement générer un premier plan. Il analysera la base de code existante, comprendra l’état actuel du projet, et proposera quelques idées potentielles. En parallèle, je peux aussi ajouter mes propres idées et guider le modèle pour générer un plan plus abouti.

Au cours de ce processus, tu vas voir que Codex fait des suggestions en fonction du code et des fichiers actuels. Par exemple, il peut demander : « Faut-il continuer à améliorer la fonctionnalité mentionnée plus tôt ? Ou faut-il optimiser le tableau de bord de fiabilité ? » Si on décide d’optimiser le tableau de bord de fiabilité, il va aussi nous guider à réfléchir : quel est l’objectif utilisateur de cette optimisation ? Tout le processus ressemble à une collaboration avec un partenaire de brainstorming.

J’utilise souvent ce genre de méthode pour faire émerger des idées. Par exemple, pour certains changements simples, je peux directement entrer une instruction et laisser Codex générer le code.

Alex :

Et pour des changements de complexité moyenne, je le laisse générer un plan concret, ou m’aider à raisonner sur la façon de l’implémenter. Et quand j’ai une idée floue, j’ouvre généralement directement Codex pour qu’il m’aide à réfléchir à comment résoudre le problème. Même si je n’ai pas de besoins fonctionnels précis en tête, Codex peut m’aider à clarifier grâce à des questions et à l’exploration.

Mais, pour être honnête, il m’arrive de ne pas utiliser directement les solutions générées par Codex, surtout quand les changements sont plus complexes. Je vais explorer via le “mode de planification” de Codex pour me former une idée claire, puis je partage ces idées à l’équipe d’ingénieurs. Au final, ce processus de réflexion est plus important que le plan généré lui-même.

Au passage, on a maintenant des designers qui écrivent plus de code que les ingénieurs il y a six mois — c’était inimaginable avant. Cela vient principalement des progrès des outils, ce qui permet aux designers de s’impliquer plus profondément dans le développement. Mais je me fais aussi souvent taquiner par l’équipe : l’année dernière, j’ai soumis trop peu de PR (demandes de fusion de code). Même si beaucoup de changements ne sont que de petits ajustements, je pense que je devrais en faire davantage.

Aujourd’hui, notre** priorité n’est plus “est-ce qu’on peut générer du code”,** parce que les agents (Agent) peuvent accomplir la majorité des tâches de codage.** Ce qui compte vraiment, c’est : ce que nous décidons de construire, et comment garantir la haute qualité du produit.** C’est aussi pour ça que, pour des fonctionnalités très complexes, je préfère trouver un responsable solide pour gérer plutôt que de laisser le chef de produit (PM) être responsable de la mise en œuvre et de la maintenance de ces systèmes.

Les designers écrivent plus de code que les ingénieurs il y a 6 mois

Animateur Peter : L’application Codex est très intuitive et facile à utiliser. En comparaison avec certains autres produits plus “professionnels”, je trouve que la courbe d’apprentissage de Codex est beaucoup plus faible. D’autres produits spécialisés, bien que puissants, exigent beaucoup de temps pour apprendre à s’en servir. Je me dis même que si je ne suivais pas ces informations sur Twitter, je ne saurais peut-être même pas comment les utiliser.

Mais le point qui m’a vraiment marqué avec Codex, c’est que non seulement c’est simple et facile, mais en plus ça offre beaucoup de fonctionnalités avancées, comme skills (compétences) et automations (automatisations). Est-ce que vous utilisez ces fonctionnalités très souvent à l’intérieur de votre équipe ?

Romain :

Oui, on les utilise énormément. En fait, je pense que skills est l’une des fonctionnalités les plus intéressantes de l’application Codex. Par exemple, maintenant, si tu utilises Figma avec un designer, il te suffit d’ouvrir la skill de Figma : tu peux extraire directement tous les détails du fichier Figma, comme les composants React, les variables, etc., et Codex génère automatiquement le code correspondant. Par exemple aussi : si tu développes une application et que tu veux la partager ou la déployer sur Vercel, Cloudflare ou Render, il suffit de donner une instruction simple via les skills, et Codex accomplit automatiquement ces tâches.

J’ai récemment discuté avec un ami : il m’a dit qu’il avait beaucoup d’idées pour améliorer un produit. Il a donc dit à Codex : “Écris toutes ces tâches sur Linear pour que je puisse les suivre.” Puis il a utilisé la skill de Linear. Ensuite il a dit à Codex : “Je vais dormir, continue d’accomplir toutes les tâches qu’on vient de discuter et marque-les comme terminées.” Le lendemain matin, il a constaté que toutes les tâches avaient vraiment été accomplies.

Alex :

Concernant la simplicité de l’application dont tu parlais, je pense qu’on peut partager notre manière de concevoir sa conception. Dans ce domaine, les développeurs sont généralement passionnés par la construction d’outils d’automatisation pour simplifier le travail au quotidien. Nous pensons qu’une caractéristique clé du produit doit être hautement configurable. Pour Codex, c’est comme une boîte à outils open source : les utilisateurs peuvent s’y plonger et la personnaliser selon leurs besoins.

À chaque fois que nous lançons une nouvelle fonctionnalité, il y a toujours des utilisateurs qui se plaignent sur Twitter que cette fonctionnalité a un problème (même si elle n’est pas encore officiellement lancée). Et la cause est généralement qu’ils ont eux-mêmes modifié le code ou l’ont fork. Mais, de mon point de vue, ça prouve que notre produit est un succès : ces utilisateurs très en avance explorent avec nous l’avenir et font avancer le produit.

Cependant, nous avons aussi conscience que ne construire que pour ces utilisateurs de pointe ne suffit pas ; sinon, le produit finira par devenir trop complexe et difficile à comprendre. Nous devons trouver un équilibre : satisfaire les besoins des utilisateurs avancés tout en rendant le produit simple et intuitif pour les utilisateurs ordinaires. Par conséquent** nous concevons avec beaucoup de prudence les fonctionnalités centrales, en veillant à ce qu’elles ne deviennent pas un obstacle entre les utilisateurs et le modèle, mais au contraire pour rendre le modèle plus intelligent et lui permettre d’accomplir automatiquement davantage de tâches.**

Romain :

Ensuite, sur cette base, nous réfléchissons à la façon d’empaqueter le produit pour les utilisateurs avancés de manière aussi configurable que possible, afin qu’ils puissent eux-mêmes explorer et l’utiliser. Par exemple, maintenant, certains utilisateurs ont déjà mis en œuvre des sub-agents (sous-agents). Ces fonctionnalités ne proviennent pas de notre conception initiale : ce sont les utilisateurs qui les ont découvertes et testées. En observant la manière dont les utilisateurs utilisent ces fonctionnalités, nous avons appris beaucoup de choses.

Ensuite, nous allons réfléchir : comment rendre ces fonctionnalités aussi super simples pour d’autres utilisateurs ? Codex app en est un excellent exemple. Environ au moment où GPT-5.2 Codex a été publié en décembre dernier, les capacités du modèle ont commencé à se stabiliser progressivement, mais aussi à passer un seuil. Les utilisateurs peuvent alors commencer à déléguer des tâches plus longues et plus complexes au modèle, et le modèle peut accomplir ces tâches d’un seul coup.

Nous avons commencé à remarquer que certains utilisateurs utilisent du tmuxing (faire tourner plusieurs tâches en parallèle dans un terminal). C’est une manière de découper l’écran dans le terminal pour exécuter plusieurs tâches en même temps. Sur les réseaux sociaux, on a vu des exemples très intéressants : par exemple, il y a une photo de Peter Steinberger, où on voit 18 fenêtres de terminal sur son écran, réparties sur trois moniteurs, et ça ressemble à une sorte de “griffe créative ouverte”. On a vu des utilisateurs utiliser Codex de manière vraiment avancée, et ça nous rend très enthousiastes.

En parallèle, nous continuons à optimiser les fonctionnalités de délégation de base du produit (comme le CLI) pour nous assurer que ça fonctionne bien. Mais nous nous sommes aussi rendu compte que peut-être seuls les 1% d’ingénieurs les plus talentueux utilisent cette façon de travailler. Alors nous nous sommes demandé : comment rendre ces fonctionnalités plus intuitives ? C’est pour ça que nous avons développé Codex app.

Quand tu ouvres Codex app pour la première fois, ça ressemble à une simple fenêtre de chat. Tu peux commencer à l’utiliser directement, ça fonctionne normalement, mais avec le temps, tu vas découvrir progressivement plus de fonctionnalités : la barre latérale, la capacité d’exécuter plusieurs tâches et la possibilité de basculer facilement entre les tâches. Tu as l’impression de devenir extrêmement efficace. Ensuite, tu remarques peut-être l’onglet “skills”, et tu cliques dedans pour explorer davantage. Nous voulons que les utilisateurs aient une expérience presque comme un jeu en utilisant Codex app, en découvrant sans cesse de nouvelles possibilités.

Romain :

Tout à fait d’accord. Et c’est aussi exactement la vision que nous avions dès le début : le codage se fera d’une manière de “délégation d’agents intelligents” (agentic delegation). Même quand nous avons commencé à développer Codex il y a presque un an, nous pensions déjà à ce futur. Nous pensons que les ingénieurs seront capables de gérer plusieurs tâches en même temps, tandis que le modèle se chargera d’exécuter les détails complexes.

Mais en toute franchise, à ce moment-là, les capacités des modèles n’étaient pas encore à ce niveau. Nous avons dû attendre la sortie de GPT-5.2 Codex, et le seuil qui a suivi, pour voir que les modèles pouvaient fonctionner de manière très complète et fiable pendant plusieurs heures, voire plusieurs jours. C’est à ce moment-là que nous avons soudain compris que l’interface de terminal traditionnelle n’était plus adaptée à ce mode de travail. Tu te dis que, dans le terminal, ouvrir plusieurs onglets et les laisser tourner pendant quelques heures, c’est une forme d’interaction assez bizarre. Donc nous avions besoin d’une toute nouvelle interface, et le timing était parfaitement bon.

Alex :

En regardant l’évolution de Codex, on a connu deux moments importants de “vibe shift” (changements de tendance). Le premier a eu lieu en août dernier : nous avons lancé le produit Codex Cloud. C’était une très bonne idée : à l’époque, les utilisateurs étaient très enthousiastes, mais c’était peut-être un peu tôt. Donc en août, nous avons publié GPT-5, un modèle de codage interactif vraiment remarquable, et nous avons décidé de nous concentrer sur la résolution des problèmes que le modèle arrivait à traiter à ce moment-là. Nous avons donc lancé Codex CLI et des plugins pour IDE ; en quelques mois, le nombre d’utilisateurs a augmenté rapidement de 20 à 30 fois, c’était tout simplement incroyable.

Le deuxième tournant a eu lieu entre décembre dernier et janvier de cette année. À ce moment-là, nous avons enfin réalisé la vision initiale : déléguer des tâches au modèle. Les capacités du modèle ont atteint un nouveau niveau, lui permettant d’accomplir de façon autonome des tâches plus complexes ; cela marque l’entrée dans une toute nouvelle phase.

Notre planification se divise en court terme et long terme, sans planification à mi-parcours

Animateur Peter : Je me demande comment Codex app a été développée. Est-ce que, il y a un an, vous aviez défini une certaine feuille de route annuelle, du type : “nous prévoyons de lancer Codex app à tel moment” ? Ou bien vous étiez plutôt en train d’observer les besoins du marché, et de prototyper rapidement quelques idées ?

Alex :

En fait, ni l’un ni l’autre. J’ai entendu une idée très intéressante de la part d’Andre, notre chercheur : chez OpenAI, soit on planifie des objectifs à court terme, soit on planifie des objectifs à long terme, mais on ne fait pas de planification à mi-parcours, parce que la planification à mi-parcours est trop complexe.

La planification à court terme correspond généralement à des objectifs sur une période maximale de huit semaines à partir d’aujourd’hui, et huit semaines est la plage de temps la plus longue que nous pouvons définir. Dans ce cadre, nous définissons un objectif concret, et nous mobilisons l’équipe entière pour tout faire afin de l’atteindre. C’est une force chez OpenAI : nous sommes très bons pour organiser l’équipe autour d’un objectif clair.

De l’autre côté, nous définissons aussi une vision à long terme. Par exemple, nous pouvons nous projeter dans l’avenir dans un an, en imaginant que le modèle sera devenu plus intelligent. Par exemple, nous pouvons imaginer que, dans le futur, les modèles pourraient travailler de manière autonome, sans avoir besoin d’utiliser nos ressources informatiques, et qu’ils ne seraient plus limités à exécuter une seule tâche à la fois. Nous voulons disposer d’une infinité de modèles qui peuvent accomplir des tâches de manière autonome, valider leur propre code, voire se déployer et se surveiller eux-mêmes, sans que nous ayons besoin de les guider manuellement via des instructions.

Cependant, la planification à mi-parcours est un peu gênante. Elle prend généralement la forme d’une feuille de route produit détaillée, mais nous n’avons fondamentalement pas ce genre de document. Nous nous appuyons plutôt sur la vision à long terme et nous nous concentrons sur des tâches concrètes qui peuvent nous aider à atteindre nos objectifs.

Prenons l’exemple de Codex app. À l’époque, l’un de nos objectifs stratégiques était de libérer les utilisateurs de certains espaces de travail (workspace). Les outils de développement traditionnels (par exemple VS Code) sont généralement liés à un espace de travail spécifique : un point de checkout particulier d’une base de code, ou un dossier précis. Même avec git worktree, on ne peut ouvrir qu’un seul répertoire de travail à la fois, et le CLI impose des contraintes similaires.

Mais notre vision était : les utilisateurs peuvent collaborer avec des agents intelligents dans le cloud, et ces agents peuvent travailler de façon autonome. Nous voulons que les utilisateurs puissent interagir avec plusieurs agents en même temps, et même qu’un agent coordonne le travail de plusieurs agents pour l’utilisateur ; cette expérience doit être naturelle et intuitive.

En même temps, nous avons aussi compris qu’en s’appuyant entièrement sur le cloud dès le départ, les développeurs pourraient trouver cela moins pratique, parce qu’ils doivent configurer l’environnement. Et lorsque le modèle exécute des tâches, s’il faut une intervention manuelle ou des ajustements, cela devient aussi pénible. C’est pourquoi nous avons décidé de développer une expérience localisée : elle peut coopérer en toute fluidité avec les dossiers locaux tout en restant connectée aux agents intelligents du cloud.

Quand nous avons commencé à développer cette application, nous avions toute une série de “réflexions de vision” comme celles-ci : des idées assez abstraites. En parallèle, nos ingénieurs faisaient toutes sortes de prototypes. Ils disaient : “J’aimerais qu’on ait une application.” Et c’est parti : on a commencé à essayer de développer différentes versions. En fait, nous avons même organisé une “hack week”, au cours de laquelle plusieurs ingénieurs ont développé indépendamment différentes versions de l’application. Tu y as peut-être participé, je ne m’en souviens plus trop.

Quand le projet a réellement commencé, la seule chose qu’il fallait clarifier clairement, c’était** : pourquoi nous pensons que développer une application est une bonne idée. Nous n’avons pas défini de spécifications produit précises pour cette application ; nous avons progressivement clarifié la direction produit grâce au travail réel de développement. **

Mais à ce moment-là, le projet faisait encore face à certaines controverses : est-ce qu’on avait vraiment besoin de développer une application ? Nos plugins IDE étaient déjà très populaires : fallait-il plutôt se concentrer sur l’amélioration de la qualité des plugins ? Le CLI avait aussi un potentiel. Alors, si on développait une application, quelle en serait la signification ? Vers quelle direction devrait-on se diriger ? Voilà certaines des questions auxquelles on faisait face au début de ce projet.

Romain :

Oui. Et heureusement, à cette période, nous avions déjà une solution de plugins IDE très mature, que nous avons longuement optimisée. Les utilisateurs pouvaient utiliser ces plugins dans VS Code, Cursor, Windsurf et d’autres IDE. Nous avions accumulé énormément d’expérience à partir du codebase des plugins IDE, ce qui nous donnait un point de départ très solide pour développer Codex app.

Alex :

C’est exact. En fait, Codex app et les plugins IDE partagent une grande quantité de code en dessous. Ils se connectent tous au même core Codex harness, un framework open source écrit en Rust, que le CLI utilise aussi. Nous avons volontairement choisi une architecture en couches pour permettre le partage de code et l’extension des fonctionnalités entre différents outils.

Animateur Peter : Concernant la décision de développer Codex app… En regardant en arrière, ça semble être une décision évidente, parce que Codex app est beaucoup plus intuitive que l’ouverture d’une pile de fenêtres de terminal. Mais à l’époque, la raison principale était : Codex app est plus convivial pour les débutants, et c’est aussi la meilleure interface pour gérer la collaboration de plusieurs agents intelligents.

Alex :

Je pense que la façon de réfléchir de notre équipe est très influencée par la vision de l’AGI (intelligence artificielle générale). Nous nous demandions : à quoi ressemblera le mode de travail du futur ?

En fait, je vais le reformuler autrement : nous savions très bien que nous avions besoin d’une interface qui permette aux utilisateurs de déléguer naturellement des tâches à plusieurs agents intelligents. Nous savions que les modèles futurs auraient cette capacité — et en fait, nous avons déjà vu des utilisateurs essayer de déléguer des tâches à travers plusieurs agents intelligents. Il fallait une interface qui rende cette façon de coopérer évidente, tout en pouvant s’étendre de manière transparente vers le cloud.

Nous espérions que cette interface serait ergonomique et donnerait l’impression aux utilisateurs que coopérer avec plusieurs agents intelligents était une expérience naturelle et intuitive, plutôt qu’un processus nécessitant des opérations complexes ou des astuces.

Romain :

Oui, et l’audience de cette application n’est pas uniquement composée de débutants. En réalité, même des ingénieurs très chevronnés, très expérimentés — y compris des ingénieurs de pointe à l’intérieur d’OpenAI, comme Peter, OpenClaw et Greg Brockman — commencent maintenant à utiliser Codex app comme outil principal de développement. Cela montre que** notre vision de la délégation d’agents intelligents (agentic delegation) devient progressivement une réalité.**

Alex :

Oui. Nous mentionnons Peter parce qu’il vient juste de rejoindre OpenAI, et nous sommes très enthousiastes. En octobre dernier, lorsque je marchais avec lui à Fort Mason à San Francisco, j’avais évoqué l’idée de développer une nouvelle interface. Je lui ai dit que nous voulions quelque chose qui rende la délégation (delegation) plus naturelle, et il m’a répondu qu’il ne l’utiliserait jamais.

Mais le week-end dernier, il a posté un tweet disant : « En fait, cette application est assez pratique. Je l’aime maintenant. »

Alex, le travail quotidien d’un chef de produit (PM) chez Codex

Animateur Peter : Alex, tu étais pendant un moment le seul chef de produit (PM) de l’équipe Codex, c’est bien ça ? Et maintenant, combien de personnes y a-t-il dans l’équipe Codex ? On serait entre 50 et 100, environ ?

Alex :

À peu près, oui : c’est dans cette fourchette. En mai, nous n’étions qu’environ 8 personnes, je ne me souviens pas du chiffre exact. Mais depuis, notre équipe a connu une croissance très rapide, et aujourd’hui c’est environ 50 à 100 personnes.

Animateur Peter : Alors, comment répartis-tu ton temps au quotidien ? À quoi ressemble ta routine ? Est-ce que tu n’as même pas vraiment de journée type ?

Alex :

Je réfléchis aussi à cette question récemment, parce que je trouve que c’est difficile d’y répondre. Je me rends compte que mon mode de travail est en fait par étapes, c’est juste ma façon de faire, et ça ne convient peut-être pas à tout le monde.

Par exemple, au moment où nous avons publié Codex app, j’étais entièrement en mode exécution. À ce moment-là, toute mon énergie était consacrée à la qualité du produit : m’assurer qu’on n’a rien oublié, que chaque détail et chaque petite chose soient bien couverts. Dans ce mode, je passe beaucoup de temps à utiliser les outils de Codex.

Nous utilisons Codex pour obtenir des retours, par exemple comprendre ce qui est discuté sur Slack, ainsi que les retours des utilisateurs. Je demande à Codex de résumer ces informations, puis je les consigne dans Linear. En plus, j’utilise Codex pour analyser la qualité du code, et je fais aussi directement de petites modifications de code. Parce que parfois, traiter directement de petits problèmes avec Codex est beaucoup plus rapide que de devoir trouver quelqu’un d’autre, coordonner les tâches et leur faire prioriser, surtout quand notre objectif est de publier l’application dans un délai de deux semaines.

Dans ce processus, il y a évidemment aussi beaucoup de travail “humain” : encourager l’équipe, motiver tout le monde, tout en gardant un regard critique sur le produit sur lequel on travaille. En fait, je me suis rendu compte que savoir si je suis en mode exécution dépend de la fréquence à laquelle j’utilise Twitter. Je ne sais pas pourquoi, mais quand j’ai besoin d’interagir avec des gens, j’utilise davantage Twitter.

Ensuite, il y a une autre mode, par exemple : en ce moment, dans ma tête c’est très clair : nous avons atteint une nouvelle étape. Nous avons maintenant des modèles très puissants, comme GPT-5.4, qui est vraiment excellent. Et notre expérience d’application dépasse aussi les attentes : elle couvre désormais toutes les plateformes, y compris Windows. Donc maintenant, je pense qu’il est temps de revenir vraiment vers le cloud et d’y investir plus d’efforts.

Quand nous entrons dans ce type de phase, je passe plus de temps à réfléchir à ce qu’on doit faire ensuite et à comprendre l’état actuel, ce qui correspond à un mode de coordination. Dans ce mode, je passe moins de temps sur Codex : plus question de communiquer via Codex que d’écrire du code. Donc au moins j’ai ces deux modes de travail, et probablement d’autres aussi.

Animateur Peter : De combien d’alignement inter-fonctionnel avez-vous besoin ?

Alex :

En interne, nous avons presque pas besoin de faire trop d’alignement inter-fonctionnel. On se considère un peu comme une équipe “d’équipage de pirates”. Même au sein de l’équipe Codex, il n’y a que moi et deux nouveaux chefs de produit qui viennent de rejoindre récemment. On a quelques responsables, et même si jusqu’à récemment tout le monde me reportait essentiellement directement, on avance globalement dans un certain flou ensemble sur le projet, donc il n’y a pas beaucoup d’alignement au sein de l’équipe.

Mais il devient de plus en plus évident que construire Codex, c’est aussi développer cet agent de codage. Et tout le monde comprend de plus en plus clairement que l’agent de codage ne sert pas seulement à écrire du code, mais qu’il est aussi très utile pour d’autres tâches.

Par exemple, on a découvert que les utilisateurs utilisent Codex app non seulement pour écrire du code. Ils s’en servent pour toutes sortes de tâches tout au long du cycle de développement de logiciels. Et maintenant, la majorité des employés d’OpenAI utilisent Codex app : même des personnes non techniques, je vois souvent qu’elles utilisent cette application.

Cette prise de conscience nous amène à nous dire qu’on doit réfléchir à comment faire en sorte que Codex ne soit pas seulement utile aux développeurs. Cela implique davantage d’alignement inter-fonctionnel, parce qu’en tant qu’équipe OpenAI, nous avons aussi ChatGPT, et beaucoup d’utilisateurs l’utilisent : il faut donc être très prudent quant à la meilleure façon de combiner ces produits.

Romain :

De mon point de vue, notre équipe d’expérience développeur ressemble un peu à une extension de l’équipe Codex. L’essentiel de notre temps et de notre énergie est consacré à Codex, principalement pour quelques raisons.

D’abord, c’est un produit extrêmement excitant et les développeurs adorent l’utiliser. On veut le rendre encore meilleur. Comme Alex l’a dit, notre mode de travail se fait par étapes : nous nous impliquons avec l’équipe Codex dans la préparation des lancements, par exemple préparer les éléments nécessaires au lancement et apprendre aux développeurs comment maximiser l’usage de Codex. Après le lancement, nous guidons aussi les développeurs pour explorer comment Codex s’utilise dans différents contextes.

Ensuite, ce qui nous intrigue beaucoup, c’est que si tu regardes toute la plateforme OpenAI : aujourd’hui, des millions de développeurs utilisent notre API pour construire des applications multimodales allant de l’image à la voix, etc.

Désormais, la meilleure manière de développer passe par Codex comme point d’entrée. Si tu regardes un an en arrière, ou même l’été dernier quand nous venions de lancer GPT-5, il fallait écrire beaucoup de guides pour expliquer aux gens comment écrire des prompts pour GPT-5. GPT-5 est un modèle dont la capacité de raisonnement est très forte, et il est très différent de GPT-4. Aujourd’hui, on essaie de permettre aux développeurs, même dans ces cas d’usage, d’accomplir leurs tâches via Codex et skills.

Par exemple, si tu dois mettre à jour un système d’intégration, on te suggère d’utiliser Codex et sa fonctionnalité skills. Résultat : Codex peut quasiment accomplir la tâche à ta place. Donc notre équipe met aussi fortement l’accent sur la collaboration inter-fonctionnelle et considère Codex comme une pierre angulaire de toute la plateforme développeur chez OpenAI.

Alex :

Je pense que l’équipe Codex a une caractéristique de fonctionnement très intéressante : pour moi, la meilleure partie, c’est l’interaction avec la communauté. Que ce soit en ligne ou lors d’événements dans la vraie vie, nous mettons énormément l’accent sur le fait de rester connectés à la communauté.

Pendant les lancements de produit, notre travail est très orienté lancement : on définit clairement quand publier quoi. Dans le même temps, nous sommes aussi très orientés retours : dès que la communauté fournit des retours, nous agissons rapidement, corrigeons les problèmes et discutons avec eux. Donc notre équipe reste très “en ligne”, et je pense que c’est crucial.

Par exemple, quand nous avons lancé Codex app, nous avons travaillé en collaboration très étroite avec Dom et son équipe. Ils nous ont aidés à organiser un alpha test à grande échelle, en invitant beaucoup d’utilisateurs pour co-développer le produit. Grâce à leurs retours, non seulement nous avons amélioré l’application, mais nous avons aussi renforcé les ressources associées, comme skills et la documentation.

Je pense que c’est exactement notre avantage unique en tant qu’équipe Codex : comme nous sommes open source, nous restons extrêmement transparents sur tout ce qu’on fait, et la communauté soutient énormément cette démarche en nous renvoyant beaucoup de retours.

Animateur Peter : Parlons de Peter (fondateur d’OpenClaw). Je suis un early user d’OpenClaw. Comment l’avez-vous intégré à l’équipe ? La vision de ce personal agent (agent personnel) est-elle liée au travail qu’il fait actuellement ? Comment vous l’avez planifiée ?

Alex :

On peut le voir de deux angles. D’abord, Peter est un utilisateur très intensif de Codex. En fait, OpenClaw a été construit en grande partie grâce à Codex. À travers sa façon de l’utiliser, il nous a fourni énormément de retours, ce qui nous a énormément aidés à améliorer Codex. Même si ce n’est que son “travail à temps partiel”, il s’y investit vraiment beaucoup, et nous sommes particulièrement excités par ça.

Ensuite, je ne peux pas divulguer trop de détails pour l’instant, mais disons qu’il nous aide à construire la prochaine génération d’agents personnels (personal agents), et à l’intégrer directement dans ChatGPT.

Romain :

Ce qui me fascine le plus dans le travail de Peter, c’est que lorsque tout le monde utilise OpenClaw, on a peut-être déjà entrevu les possibilités du futur, mais ce qui me frappe, c’est que Peter a vu cette vision très tôt.

Si tu regardes toute l’année 2025 : l’an dernier, il a développé plus de 40 projets open source, et ces projets tournaient tous autour d’une vision centrale : accéder à ses outils personnels, comme son calendrier, ses tweets et Gmail, via une interface en ligne de commande. Grâce à ces projets, il a transformé la vision des skills et des outils en ligne de commande en réalité. Et l’agent de programmation (coding agent) que nous utilisons aujourd’hui est justement construit sur cette vision.

À l’avenir, cet agent ne sera pas seulement un outil de programmation : il deviendra un personal agent (agent personnel) de n’importe quel type. Dans ce processus, Peter nous a donné des retours très précieux, parce qu’il a déjà développé de nombreux outils qui font désormais partie centrale de l’écosystème open source.

Animateur Peter :

Je trouve que des gens comme Peter, capables de construire une communauté open source aussi remarquable, c’est vraiment admirable. Ses outils sont si utiles que je n’ai même plus envie d’ouvrir d’autres applications. Je veux juste discuter avec mon petit robot.

Alex :

Tu l’as connecté à quoi ? Tu l’as connecté à tout ?

Animateur Peter :

Oui, je l’ai connecté à pas mal de services. Par exemple, il peut accéder à mes informations bancaires, à mon compte YouTube, à l’assistant vocal, à mon calendrier, ainsi qu’aux services Google. Quand je suis au lit, ma femme me demande : « Tu parles à qui ? » Et je réponds : « Je discute avec mon robot OpenClaw. »

Mais maintenant, il y a beaucoup de “spécialistes” qui facturent jusqu’à 5000 dollars pour aider les gens à configurer OpenClaw. Donc si vous pouvez le rendre plus grand public, plus facile à prendre en main, ce serait une percée immense. Et je pense que vous allez vraiment dans la bonne direction.

Les échelons de carrière traditionnels ne s’appliquent plus

Animateur Peter : Je me souviens que vous avez déjà dit quelque chose comme : « Aujourd’hui, la plupart des équipes n’ont plus vraiment besoin d’autant de PM. » Vous l’avez dit, non ?

Romain :

Je pense que ce qui rend ces outils le plus surprenants pour moi, ce n’est pas seulement la question de savoir s’il faut des PM ou non. Ça rend presque flous tous les échelons de progression de carrière traditionnels. Avant, nous avions des rôles bien définis : les designers s’occupent du design, les ingénieurs du développement, les PM de la gestion, et peut-être un certain ratio précis, comme une sorte de “ratio d’or”.

Mais maintenant, si tu es ingénieur, ta productivité augmente de manière significative. Si tu es designer, tu peux obtenir des super-pouvoirs grâce à ces outils, devenir plus technique. Et si tu es PM : auparavant tu pouvais surtout écrire des documents de stratégie, mais maintenant tu peux prototyper directement. Ça ne veut pas dire que tu dois être responsable d’une fonctionnalité pour des milliards d’utilisateurs, mais tu peux vraiment construire quelque chose avec ces outils, et montrer ta vision à l’équipe.

Donc ce qui me fascine le plus, c’est que maintenant, les frontières entre tous les échelons professionnels se brouillent. En réalité, nous sommes tous des “builders (constructeurs)”, et tout le monde collabore pour construire.

Alex :

Je me souviens que j’ai peut-être dit quelque part en ligne que si une startup a un PM et moins d’environ 20 ingénieurs, ça pourrait être un signal dangereux. Peut-être que je l’ai vraiment dit.

Je pense que c’est ce que tu dis aussi : tous ces rôles commencent à fusionner. Les designers peuvent faire plus de travail d’ingénierie, les ingénieurs peuvent toucher au design, et les PM peuvent aussi participer à la construction. Mais les ingénieurs doivent généralement se concentrer sur l’écriture de code, donc auparavant ils ne faisaient pas le tri des tâches ni les autres aspects de gestion de projet qui relèvent des PM.

Mais maintenant, ces choses deviennent tellement faciles. Tu peux directement laisser un agent, par exemple Codex, analyser les retours et les priorités, et ainsi les ingénieurs peuvent libérer plus de temps pour se concentrer sur leur propre travail. Je pense que tout le monde peut désormais faire le travail des autres.

Scott Belsky a proposé une idée, “collapse the talent stack (effondrement du vivier de talents)”. J’aime beaucoup cette perspective, et je pense que c’est effectivement en train de se produire. Moins il y a besoin de gens dans la salle, plus ça avance facilement, et plus chaque décision devient claire.

Donc la question devient : que peut faire un PM ? Je pense que beaucoup de PM devraient envisager une reconversion. Par exemple, si tu es un PM et que tu as toujours voulu devenir ingénieur, mais que tu es meilleur pour gérer les personnes et que tes compétences en ingénierie ne sont pas aussi fortes, alors peut-être que maintenant tu peux devenir un engineering manager (responsable d’ingénierie). Avec des agents intelligents, ton rôle peut devenir plus clair. De la même façon, certains PM peuvent préférer devenir designers, ce qui les rapproche davantage du travail concret de construction.

Je pense que tout dépend finalement de l’intérêt personnel. Pour ma part, l’intérêt et l’autonomie sont les qualités humaines les plus essentielles et les plus importantes à l’ère de l’AGI. Donc si tu t’intéresses davantage à écrire du code et que tu occupais ce rôle uniquement parce qu’il fallait quelqu’un pour faire le travail de PM, alors tu peux tout à fait te reconvertir en ingénieur et continuer à faire la même chose sous l’angle de l’ingénierie. C’est pareil pour le domaine du design.

Mais si ce qui t’intéresse vraiment, c’est d’interagir avec les utilisateurs, même si cela te pousse à t’éloigner du travail concret de construction — par exemple essayer de comprendre les besoins des utilisateurs, saisir les tendances du marché, etc. — alors dans une équipe suffisamment grande, il reste de la place pour un PM.

Romain :

J’ajouterais une chose : je continue de penser que chaque domaine de problèmes a besoin d’une personne responsable humaine, mais je ne pense pas que cette personne doit forcément être un PM ; je pense que ça dépend largement de la nature du produit.

Nous avons de la chance ici, car nous travaillons sur Codex, qui est un outil orienté développeurs. Nous sommes nous-mêmes les meilleurs utilisateurs. Et comme c’est open source, nous pouvons interagir directement avec la communauté et co-développer.

Mais si tu reviens dix ans en arrière, par exemple quand je travaillais chez Stripe : l’entreprise comptait 250 personnes, mais il n’y avait pas de PM, et même pas d’outils d’IA. Pourquoi ? Parce que Stripe était un produit d’API, et tout le monde était ingénieur, avec une compréhension très intuitive de ce qu’est une bonne API. Nous construisions alors exactement l’API dont nous rêvions : une solution élégante qui tient en quelques lignes de code.

Mais si tu es dans un domaine différent, par exemple si les ingénieurs n’ont pas autant d’intuition pour les besoins des utilisateurs, alors tu auras probablement besoin de plus de PM pour communiquer avec les clients et comprendre leurs besoins. En particulier lorsque le secteur ou le domaine que tu sers n’est pas parfaitement aligné avec l’intuition des ingénieurs, le rôle du PM devient encore plus important. Mais dans l’équipe Codex, nous sommes chanceux, parce que nous construisons justement un outil que nous voulons utiliser nous-mêmes.

Alex :

Dans ce contexte, le rôle d’un PM peut n’être qu’une étiquette, qui désigne la personne la plus intéressée et la plus attentive aux besoins des utilisateurs. Cette personne peut très bien être un ingénieur très proche des utilisateurs. Donc je pense que ces étiquettes de carrière perdent progressivement leur signification traditionnelle, même si c’est un peu chaotique, ce n’est pas forcément une mauvaise chose.

Animateur Peter :

J’ai découvert la même chose dans mon équipe : je pense que les meilleurs ingénieurs ne me demandent pas “quoi construire ensuite”. Ils vont directement discuter avec les utilisateurs, se rendre compte eux-mêmes de ce qu’il faut développer, puis en parler avec moi. De cette façon, les objectifs de chacun sont très alignés.

Romain :

C’est exactement notre manière de travailler dans l’équipe Codex : beaucoup des fonctionnalités que vous utilisez aujourd’hui dans Codex app viennent en fait d’idées brillantes proposées par des ingénieurs dans une logique bottom-up, parce qu’eux-mêmes ont besoin de ces fonctionnalités.

Alex :

Mais je veux dire qu’il existe un type d’ingénieur que j’aime beaucoup travailler avec. Ils aiment parler aux utilisateurs et réfléchir aux fonctionnalités à construire. Ces personnes sont généralement très fortes pour construire des systèmes : elles sont rapides, très compétentes, avec un raisonnement clair. Mais certains ingénieurs n’ont aucun intérêt à interagir avec les utilisateurs ; ils veulent juste se concentrer sur la construction du système. Je pense que ces personnes ont aussi un énorme potentiel d’évolution.

Encore une fois, c’est ma vision de l’ère de l’IA : nous pouvons tous devenir plus “nous-mêmes”. L’IA et l’équipe t’aident à faire les choses que tu n’aimes pas faire, pour que tu puisses te concentrer sur tes centres d’intérêt et tes forces.

Animateur Peter :

Je pense aussi que l’étiquette “builder (constructeur)” est très importante. Je pense que beaucoup de PM veulent devenir des leaders, mais dans les échelons de carrière traditionnels : une fois que tu deviens VP ou des postes comme ça, tu n’as plus le temps de construire. Chaque jour tu es en train d’évaluer le produit, de donner juste des retours, mais tu n’as pas le temps de développer réellement. Je pense que beaucoup de PM ne veulent pas vivre ça : je veux rester proche des utilisateurs et vraiment publier des produits.

Alex :

Je suis totalement d’accord. Je ne pense pas que PM soit réellement un rôle de leadership ; j’ai plutôt tendance à le voir comme un rôle qui comble un vide. Parfois, ce rôle peut nécessiter d’assumer une certaine responsabilité de leadership. Mais même dans ce cas, le leadership sert davantage à aider l’équipe à trouver un accord, plutôt qu’à dépendre du fait qu’une seule personne propose une solution géniale.

Une chose est sûre : chez OpenAI, les meilleurs PM plongent dans des détails très concrets. Et je pense aussi que rejoindre OpenAI à un poste de leadership senior est particulièrement difficile, parce que la culture ici continue de mettre l’accent sur l’attention aux détails. Donc la meilleure façon est de plonger directement dans les détails dès le début.

Qu’est-ce que l’équipe Codex valorise en recrutant ? (la réponse n’est pas ton CV)

Animateur Peter : Quand vous recrutez pour l’équipe Codex, en plus d’exiger que les candidats soient des utilisateurs très intensifs de Codex, quelles autres qualités vous cherchez ?

Alex :

Comme je l’ai déjà mentionné, j’accorde beaucoup d’importance à l’“autonomie” (agency) du candidat. On veut trouver des personnes qui passent à l’action de leur propre initiative ; c’est l’une des qualités les plus importantes.

Chez OpenAI, surtout au sein de l’équipe Codex, notre culture n’est pas du genre “quand tu rejoins, on te donne une liste de 12 tâches avec une difficulté qui augmente étape par étape”. Notre approche ressemble plutôt à : “Bienvenue ! Maintenant, commence ton exploration.”

C’est pour ça qu’on cherche plutôt des personnes autodirigées — elles ont de l’élan, ont leurs propres idées, savent ce qu’elles veulent faire, et n’ont pas peur de challenger les idées existantes. Parce que soyons honnêtes : certaines idées existantes sont peut-être même incorrectes, et elles peuvent n’avoir été qu’une décision accidentelle au départ.

Mon coéquipier idéal est quelqu’un qui est prêt à prendre des responsabilités supplémentaires, voire à gérer des domaines inconnus. Ce sont des qualités que l’on valorise particulièrement. Pour les compétences spécifiques, on priorise généralement les candidats avec de solides capacités techniques, liées à l’ingénierie.

Romain :

Je suis totalement d’accord. Dans mon équipe d’expérience développeur (DevX), je cherche généralement des personnes qui ont une forte autonomie. Elles doivent être très solides techniquement, surtout lorsqu’il s’agit d’utiliser des outils comme Codex. Mais au-delà de ça, je valorise aussi particulièrement les personnes qui sont passionnées par le fait de travailler avec des développeurs et des builders (constructeurs), et qui aiment partager leurs connaissances.

Par exemple, cette semaine, nous venons d’annoncer que Thomas va rejoindre mon équipe : c’est lui qui a développé l’open source Codex monitor. Il est non seulement très créatif, mais c’est aussi un utilisateur très intensif de Codex, et il est enthousiaste à l’idée de partager comment il utilise Codex pour construire des outils.

Nous avons besoin de ce type de talents, parce que nous essayons d’amener des millions de développeurs vers un avenir lumineux que Codex représente. Je crois que l’agentic coding est en train de bouleverser complètement notre façon traditionnelle de penser le développement logiciel, la construction d’applications et la création de produits. Notre objectif est de montrer au monde entier ce qui est possible, et d’aider les développeurs à apprendre à utiliser ces outils pour réaliser leurs propres idées. Voilà exactement les qualités que je recherche.

Alex :

Je rajouterais que, de mon point de vue, les candidats idéaux pour l’équipe DevX peuvent être décrits simplement comme : “d’excellents ingénieurs, qui savent aussi utiliser les réseaux sociaux et interagir avec la communauté.”

Romain :

Tu as raison sur une partie. Mais je veux ajouter un élément : nous voulons que les candidats aient une forte responsabilité envers la communauté, et il faut aussi tenir compte des habitudes d’utilisation des réseaux sociaux selon les régions du monde. Par exemple : dans certains endroits, les développeurs préfèrent utiliser LinkedIn ou d’autres plateformes plutôt que Twitter. Donc nous devons élargir cette définition : il faut que les candidats aient une bonne présence sur les réseaux sociaux à l’échelle mondiale. Nous valorisons tout particulièrement ceux qui aiment interagir avec la communauté, et qui sont passionnés par l’enseignement et le partage des connaissances

Animateur Peter :

En fait, l’autonomie d’une personne se voit déjà avant même l’entretien. Par exemple : ont-ils déjà publié des réalisations en ligne ? Ont-ils des side projects ?

Alex :

Quand quelqu’un m’envoie un message privé pour me dire qu’il est intéressé à rejoindre notre équipe, ma première réaction est : “Il y a des liens ?” S’il y a des liens, je les ouvre presque toujours pour voir. Je suis curieux de vérifier ce qu’ils ont fait, et de voir s’ils construisent vraiment quelque chose.

Bien sûr, certaines personnes joignent aussi une lettre de candidature pour expliquer pourquoi elles sont intéressées par ce poste, voire ajoutent leur CV, mais je préfère lire leurs idées et voir ce qu’ils ont réellement construit. La semaine dernière, j’ai aussi remarqué quelque chose de drôle : je n’ai absolument aucune idée de quelle université ces gens ont fréquentée.

Animateur Peter : Qui se soucie de ça ? Qui s’en souciera ? Je suis vraiment content qu’on vive à une époque où ces diplômes stupides comptent moins : tant que je vois ce que tu as réellement construit, ça me suffit.