Le responsable produit d’OpenAI Codex raconte en personne : « Comment avons-nous développé ce produit sans spécifications ni feuille de route ? »
TechFlow SélectionTechFlow Sélection
Le responsable produit d’OpenAI Codex raconte en personne : « Comment avons-nous développé ce produit sans spécifications ni feuille de route ? »
« L’intérêt et l’autonomie sont les qualités les plus fondamentales et les plus importantes de l’être humain à l’ère de l’AGI. »
Dédié à des analyses Web3 approfondiesRédaction & traduction : TechFlow
Invités : Alex, responsable produit de Codex ; Romain, responsable de l’expérience développeur chez Codex
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 : 5 avril 2026
Synthèse des points clés
Alex est le responsable produit de Codex, tandis que Romain s’occupe de l’expérience développeur. Leur échange m’a permis d’approfondir de façon exceptionnelle la manière dont fonctionne l’équipe Codex — notamment comment elle utilise Codex pour construire ses produits, et comment elle parvient à lancer des produits sans recourir aux spécifications traditionnelles ni aux feuilles de route classiques. Alex partage également des réflexions originales sur l’avenir du métier de chef de produit (PM), ainsi que sur les critères réellement décisifs lors du recrutement.
Résumé des idées marquantes
Construction en temps réel et « vitesse de pensée » de Codex Spark
- « Lorsque vous voulez construire quelque chose… vous pouvez basculer en mode rapide, voire utiliser Codex Spark, et bénéficier alors d’une vitesse de pensée folle pour créer n’importe quoi. À gauche, on a GPT-5.4 ; à droite, Codex Spark, qui délivre environ 1 200 tokens par seconde en moyenne — une vitesse tout simplement incroyable. » — Romain
À propos des documents de spécification et des processus décisionnels
- « Je pense que nous rédigons très, très peu de documents de spécification au sein de l’équipe Codex. En réalité, une grande partie de notre travail consiste à permettre aux personnes les plus proches du terrain de prendre autant de décisions que possible. Nous ne rédigeons donc des spécifications que lorsque le problème devient si complexe qu’il ne peut plus être entièrement contenu dans la tête d’une seule personne. » — Alex
Brouillage des frontières professionnelles et évolution des designers
- « Nos designers écrivent aujourd’hui davantage de code que nos ingénieurs il y a six mois. Notre priorité n’est désormais plus “peut-on générer du code ?”, mais bien “quelle fonctionnalité choisissons-nous de développer ?” et “comment garantir la haute qualité du produit ?”. C’est pourquoi, pour les fonctionnalités particulièrement complexes, je préfère désigner un responsable solide chargé de leur pilotage, plutôt que de confier la mise en œuvre et la maintenance de ces systèmes à un chef de produit (PM). » — Alex
Philosophie de conception produit : rendre le modèle « invisible »
- « Nous concevons nos fonctionnalités essentielles avec une extrême prudence, afin qu’elles ne constituent jamais un obstacle entre l’utilisateur et le modèle, mais au contraire renforcent l’intelligence de ce dernier et lui permettent d’accomplir automatiquement davantage de tâches. » — Alex
- « Ensuite, nous réfléchissons à la manière de livrer le produit à des utilisateurs avancés, dans une configuration aussi flexible que possible, afin qu’ils puissent l’explorer et l’utiliser librement. Par exemple, certains utilisateurs ont déjà mis en œuvre des sous-agents (sub-agents). » — Romain
Philosophie de planification : refuser le « malaise du moyen terme »
- « Chez OpenAI, nous planifions soit à court terme, soit à long terme — jamais à moyen terme, car cela devient trop complexe. Une planification à court terme couvre généralement une période maximale de huit semaines : c’est la durée la plus longue que nous soyons capables de définir. Nous établissons également une vision à long terme : par exemple, nous pouvons imaginer l’état du modèle dans un an, où il sera nettement plus intelligent. Or, la planification à moyen terme paraît embarrassante : elle se matérialise souvent sous forme d’une feuille de route produit détaillée, or nous n’en avons pratiquement pas. Ce que nous faisons plutôt, c’est articuler notre vision à long terme avec des tâches concrètes capables de nous rapprocher progressivement de cet objectif. » — Alex
Une révolution de l’interface grâce à la délégation intelligente d’agents
- « La programmation s’effectuera désormais selon un principe de “délégation intelligente d’agents” (agentic delegation). Vous trouverez certainement étrange d’ouvrir plusieurs onglets dans votre terminal et de les laisser tourner pendant plusieurs heures. Nous avons besoin d’une interface entièrement nouvelle — et le moment est justement parfait. » — Romain
La disparition des échelles hiérarchiques traditionnelles et l’effondrement de la « pile de talents »
- « Cela brouille presque toutes les échelles hiérarchiques professionnelles traditionnelles. Chacun d’entre nous est avant tout un “constructeur” (builder), collaborant étroitement pour construire ensemble. Si une startup emploie un chef de produit (PM) tout en comptant moins d’une vingtaine d’ingénieurs, cela constitue probablement un signal d’alarme. Dans l’ère de l’AGI, l’intérêt personnel et l’autonomie sont les qualités humaines les plus fondamentales et les plus importantes. » — Romain / Alex
Critères de recrutement : les réalisations l’emportent sur le CV
- « Lorsqu’une personne m’envoie un message privé pour exprimer son intérêt à rejoindre notre équipe, ma première réaction est de demander : “Avez-vous un lien vers vos travaux ?” Dès que j’en reçois un, je clique systématiquement dessus pour vérifier si cette personne construit réellement quelque chose. Ce que je souhaite surtout voir, ce sont ses idées et les projets concrets qu’elle a réalisés. Je n’ai aucune idée de l’université qu’elle a fréquentée. » — Alex
Démonstration en direct : construire un jeu en quelques secondes avec Codex Spark
Peter, animateur : Aujourd’hui, j’ai vraiment hâte d’accueillir Alex et Romain, membres de l’équipe Codex chez OpenAI. Ils vont nous montrer comment ils construisent les nouvelles fonctionnalités de Codex, quelles capacités possède Codex, et comment l’équipe Codex parvient à publier continuellement des produits. Seriez-vous prêts à nous montrer rapidement ce qu’on peut réaliser avec une seule instruction (one-shot) ?
Romain :
Bien sûr, laissez-moi partager mon écran. J’ai tellement de choses à vous montrer que je vais opter pour un aperçu rapide : ici, par exemple, se trouve une application iOS que je suis en train de développer. Si je veux ajouter une nouvelle fonctionnalité à cette application, je peux simplement dicter : « Hé, pourriez-vous ajouter un nouvel écran consacré à la mission de retour lunaire de la NASA ? », puis envoyer cette instruction à GPT-5.4 — et le modèle générera immédiatement un nouvel écran adapté précisément à cette application.
Mais nous disposons également du modèle Codex Spark, capable de vous aider à concevoir et itérer sur n’importe quel projet en quelques secondes seulement. Permettez-moi de vous illustrer la différence de réactivité entre GPT-5.4 et Codex Spark. À gauche, GPT-5.4 ; à droite, Codex Spark. Et là encore, environ 1 200 tokens par seconde en moyenne — une vitesse tout bonnement folle. Donc, lorsque vous voulez construire quelque chose — comme un jeu, par exemple — juste avant le début de cet entretien, je me suis rendu dans l’application Codex et j’ai créé, avec une seule instruction, un petit jeu 2D inspiré d’Animal Crossing.
Lorsque mes idées sont claires, j’apprécie particulièrement une autre fonctionnalité de Codex : ouvrir Codex et faire flotter la conversation en haut de l’écran. Ainsi, si je développe effectivement ce jeu, je peux continuer à itérer et à générer de nouvelles idées. Que pensez-vous, Peter, de ce que nous pourrions modifier dans ce jeu ?
Peter : Peut-être ajouter davantage de décorations — des maisons, des arbres, etc. — pour le rendre plus vivant ?
Romain :
Je vais donc envoyer cette demande, et Codex Spark l’exécutera en quelques secondes, avec des modifications visibles en temps réel. Et voilà — les nouveaux arbres apparaissent déjà.
C’est précisément pour cela que je suis si enthousiaste à propos de Codex : vous pouvez certes disposer de modèles de pointe comme GPT-5.4, capables d’accomplir des tâches extrêmement complexes — analyser ou migrer des millions de lignes de code, par exemple. Mais dès lors que l’inspiration jaillit et que vos idées sont claires, vous pouvez passer en mode rapide, voire activer Codex Spark, et bénéficier alors d’une vitesse de pensée folle pour construire n’importe quoi.
Pour les spécifications produit, nous rédigeons environ dix points — pas plus
Peter, animateur : Je suis vraiment curieux de savoir comment vous construisez concrètement vos produits avec Codex au sein de votre équipe. Alex, rédigez-vous encore des spécifications ? Ou demandez-vous à GPT d’en rédiger une ? Quel modèle utilisez-vous pour faire fonctionner tout cela ?
Alex :
Je pense que nous rédigons très, très peu de documents de spécification au sein de l’équipe Codex. En fait, une grande partie de notre travail consiste à permettre aux personnes les plus proches du terrain de prendre autant de décisions que possible, donc nous ne rédigeons des spécifications que lorsque le problème devient si complexe qu’il ne peut plus être entièrement contenu dans la tête d’une seule personne. À titre d’information, une personne peut aujourd’hui intégrer une quantité considérable d’informations dans sa tête, car elle peut accomplir beaucoup de choses — notamment déléguer la majeure partie de la programmation. Une personne peut donc aujourd’hui réaliser beaucoup. Toutefois, si le problème finit par nécessiter la coordination de plusieurs personnes, ou implique une décision particulièrement délicate, nous rédigerons alors peut-être une spécification. Mais même dans ces cas-là, les documents que nous produisons sont extrêmement courts — nous nous limitons typiquement à une liste de dix points, et c’est tout.
Peter, animateur : Très bien. Pourriez-vous nous montrer comment cela fonctionne ? Par exemple, vous fournissez à Codex quelques points-clés, puis celui-ci rédige-t-il les exigences concrètes ?
Romain :
Bien sûr ! Mais je vais d’abord vous montrer un exemple plus simple. Imaginons que nous développons une application iOS, dont certaines fonctionnalités sont déjà terminées. Vous avez maintenant des idées pour de nouvelles fonctionnalités, mais vous n’êtes pas encore certain de la direction à suivre. C’est précisément là que Codex montre toute sa puissance : il nous aide à planifier les prochaines étapes. Il me suffit, par exemple, d’appuyer sur Maj+Tab pour entrer en « mode planification » (Plan Mode), puis de taper « Que devons-nous construire ? » — Codex génère alors automatiquement un plan préliminaire. Il analyse la base de code existante, comprend l’état actuel du projet, et propose des pistes concrètes. Parallèlement, je peux intégrer mes propres idées pour orienter le modèle vers un plan plus complet.
Dans ce processus, vous remarquerez que Codex propose des suggestions basées sur le code et les fichiers actuels. Par exemple, il pourrait demander : « Devons-nous poursuivre l’amélioration de la fonctionnalité mentionnée précédemment, ou optimiser plutôt le tableau de bord de fiabilité ? » Si nous décidons d’optimiser le tableau de bord de fiabilité, Codex nous guidera davantage dans la réflexion : qui est le public cible de cette amélioration ? Tout cela ressemble à une collaboration avec un partenaire idéal pour un brainstorming.
J’utilise fréquemment cette approche pour stimuler la génération d’idées. Pour des modifications simples, j’entre directement une instruction et je demande à Codex de générer le code correspondant.
Alex :
Pour les modifications de complexité moyenne, je peux lui demander de générer un plan détaillé ou de m’aider à raisonner sur la manière de les mettre en œuvre. Et lorsque j’ai une idée vague, j’ouvre simplement Codex et je lui demande de m’aider à réfléchir à la résolution du problème. Même si je n’ai pas encore d’exigence fonctionnelle claire en tête, Codex peut, grâce à ses questions et à son exploration, m’aider à clarifier ma pensée.
Cependant, je dois avouer que je n’utilise pas toujours directement la solution proposée par Codex, surtout pour les modifications complexes. Je me sers plutôt du « mode planification » de Codex pour explorer différentes pistes, structurer ma réflexion, puis partager ces idées avec l’équipe d’ingénieurs. En fin de compte, ce processus de réflexion est bien plus important que le plan généré lui-même.
En passant, nos designers écrivent aujourd’hui davantage de code que nos ingénieurs il y a six mois — ce qui était impensable auparavant. Cela tient principalement aux progrès des outils, qui permettent aux designers de participer bien plus activement au développement. Néanmoins, je me fais régulièrement taquiner par mon équipe pour avoir soumis trop peu de PR (demandes de fusion de code) l’année dernière. Certes, beaucoup de ces modifications étaient mineures, mais je me sens effectivement tenu de contribuer davantage.
Aujourd’hui, notre priorité n’est plus “peut-on générer du code ?”, car les agents (agents) sont désormais capables d’accomplir la majeure partie des tâches de programmation. Le véritable enjeu est désormais : “Quelle fonctionnalité choisissons-nous de développer ?” et “Comment garantir la haute qualité du produit ?”. C’est pourquoi, pour les fonctionnalités très complexes, je préfère désigner un responsable solide chargé de leur pilotage, plutôt que de confier la mise en œuvre et la maintenance de ces systèmes à un chef de produit (PM).
Les designers écrivent aujourd’hui davantage de code que les ingénieurs il y a six mois
Peter, animateur : L’application Codex est d’une utilisation intuitive et simple. Comparée à d’autres produits professionnels disponibles sur le marché, je trouve que sa courbe d’apprentissage est nettement plus douce. Certains produits professionnels, bien que très puissants, exigent un investissement considérable en temps pour en maîtriser l’usage. J’ai même l’impression que, si je ne suivais pas les actualités pertinentes sur Twitter, je ne saurais pas du tout comment les utiliser.
Mais ce qui me frappe particulièrement chez Codex, c’est qu’il allie simplicité d’usage et fonctions avancées — comme les « compétences » (skills) et les « automatisations » (automations). Vos équipes internes utilisent-elles fréquemment ces fonctionnalités ?
Romain :
Oui, nous les utilisons intensivement. En fait, je considère les « compétences » comme l’une des fonctionnalités les plus intéressantes de l’application Codex. Par exemple, si vous travaillez avec un designer dans Figma, il vous suffit d’activer la compétence Figma pour extraire automatiquement tous les composants React, les variables, etc., depuis le fichier Figma — Codex génère alors le code correspondant. De même, si vous développez une application et souhaitez la déployer sur Vercel, Cloudflare ou Render, il vous suffit d’utiliser la compétence appropriée pour donner une instruction simple — Codex s’occupe alors de tout.
Récemment, j’ai discuté avec un ami qui avait plein d’idées pour améliorer son produit. Il a alors dit à Codex : « Enregistrez toutes ces tâches dans Linear, afin que je puisse les suivre. » Il a utilisé la compétence Linear. Puis il a ajouté : « Je vais dormir. Continuez à exécuter toutes les tâches que nous venons de discuter, et marquez-les comme terminées. » Le lendemain matin, il s’est réveillé et constaté que toutes les tâches avaient bel et bien été accomplies.
Alex :
Concernant la simplicité d’usage de l’application que vous venez de mentionner, je peux vous expliquer comment nous abordons sa conception. Dans ce domaine, les développeurs ont naturellement tendance à construire eux-mêmes des outils d’automatisation pour simplifier leur travail quotidien. Nous estimons qu’une caractéristique clé d’un produit est sa haute configurabilité. Pour Codex, il s’agit d’une boîte à outils open source, que l’utilisateur peut explorer en profondeur et personnaliser selon ses besoins.
Chaque fois que nous lançons une nouvelle fonctionnalité, certains utilisateurs se plaignent sur Twitter — parfois même avant que la fonctionnalité ne soit officiellement lancée — parce qu’elle présente un problème. Or, la cause de ce problème est souvent qu’ils ont modifié le code eux-mêmes ou effectué un fork. Pour moi, c’est justement la preuve de notre succès : ces utilisateurs de pointe explorent avec nous l’avenir et contribuent activement à l’amélioration du produit.
Cependant, nous sommes conscients que construire uniquement pour ces utilisateurs avancés ne suffit pas, car le produit risquerait alors de devenir trop complexe et incompréhensible. Nous devons donc trouver un équilibre : répondre aux besoins des utilisateurs avancés tout en gardant le produit simple et intuitif pour les utilisateurs ordinaires. Ainsi, nous concevons nos fonctionnalités essentielles avec une extrême prudence, afin qu’elles ne constituent jamais un obstacle entre l’utilisateur et le modèle, mais au contraire renforcent l’intelligence de ce dernier et lui permettent d’accomplir automatiquement davantage de tâches.
Romain :
Sur cette base, nous réfléchissons ensuite à la manière de livrer le produit à des utilisateurs avancés, dans une configuration aussi flexible que possible, afin qu’ils puissent l’explorer et l’utiliser librement. Par exemple, certains utilisateurs ont déjà mis en œuvre des sous-agents (sub-agents). Ces fonctionnalités ne sont pas issues de notre conception initiale, mais ont été découvertes et expérimentées par les utilisateurs eux-mêmes. En observant leur usage, nous en tirons de précieuses leçons.
Nous nous interrogeons ensuite : comment rendre ces fonctionnalités accessibles et simples à utiliser pour tous les autres utilisateurs ? L’application Codex en est un excellent exemple. Vers décembre dernier, lors de la sortie de GPT-5.2 Codex, les capacités du modèle ont commencé à se stabiliser, franchissant un seuil critique. Les utilisateurs peuvent désormais déléguer au modèle des tâches plus longues et plus complexes, qu’il exécute d’un seul bloc.
Nous avons remarqué que certains utilisateurs commencent à employer la technique du « tmuxing » (exécution simultanée de plusieurs tâches dans le terminal), c’est-à-dire la division de la fenêtre du terminal pour faire tourner plusieurs tâches en parallèle. Sur les réseaux sociaux, nous avons vu des exemples fascinants : une photo de Peter Steinberger montrait son écran avec 18 fenêtres de terminal réparties sur trois écrans — une sorte de « patte créative ouverte ». Nous sommes enthousiasmés par cette utilisation très avancée de Codex.
Parallèlement, nous continuons à optimiser la délégation de tâches dans les produits de base (comme l’interface CLI), afin qu’elle fonctionne parfaitement. Mais nous savons aussi que seuls les 1 % d’ingénieurs les plus expérimentés travailleront ainsi. Nous nous demandons donc : comment rendre ces fonctionnalités plus intuitives ? C’est précisément pourquoi nous avons développé l’application Codex.
Lorsque vous ouvrez pour la première fois l’application Codex, elle ressemble à une simple fenêtre de discussion. Vous pouvez immédiatement l’utiliser, et elle fonctionne correctement. Mais au fil du temps, vous découvrirez progressivement davantage de fonctionnalités : la barre latérale, la capacité d’exécuter plusieurs tâches simultanément, la possibilité de basculer aisément entre celles-ci — et vous vous sentirez soudainement ultra-efficace. Vous remarquerez peut-être ensuite l’onglet « Compétences » (skills), que vous pourrez explorer pour découvrir encore plus de possibilités. Nous souhaitons que l’utilisation de l’application Codex ressemble presque à un jeu, où l’utilisateur découvre continuellement de nouvelles possibilités.
Romain :
Tout à fait d’accord. Et c’est précisément la vision que nous nourrissons depuis le tout début : la programmation s’effectuera désormais selon un principe de “délégation intelligente d’agents” (agentic delegation). Même il y a près d’un an, au moment où nous avons commencé à développer Codex, nous réfléchissions déjà à cet avenir. Nous sommes convaincus que les ingénieurs pourront traiter plusieurs tâches simultanément, tandis que le modèle s’occupera des détails complexes.
Cependant, il faut bien l’admettre : les modèles n’avaient pas encore atteint ce niveau de performance à l’époque. Nous avons dû attendre la sortie de GPT-5.2 Codex, puis ce seuil critique où le modèle est devenu capable de fonctionner de façon fiable et rigoureuse pendant plusieurs heures, voire plusieurs jours. À ce moment précis, nous avons soudain pris conscience que l’interface traditionnelle du terminal n’était plus adaptée à ce nouveau mode de travail. Vous trouvez certainement étrange d’ouvrir plusieurs onglets dans votre terminal et de les laisser tourner pendant plusieurs heures. Nous avons donc besoin d’une interface entièrement nouvelle — et le moment est justement parfait.
Alex :
En repensant à l’évolution de Codex, nous avons traversé deux « changements de tendance » (vibe shift) importants. Le premier a eu lieu en août dernier, avec le lancement de Codex Cloud. C’était une excellente idée, et les utilisateurs étaient très enthousiastes — bien que ce soit peut-être arrivé un peu trop tôt. Nous avons donc lancé en août GPT-5, un modèle interactif de codage exceptionnel, et décidé de nous concentrer sur les problèmes que le modèle pouvait résoudre à ce stade. C’est ainsi que nous avons lancé Codex CLI et les extensions IDE, dont le nombre d’utilisateurs a augmenté de 20 à 30 fois en quelques mois — un résultat formidable.
Le deuxième changement de tendance s’est produit entre décembre dernier et janvier. À ce moment-là, nous avons enfin concrétisé notre vision initiale : déléguer des tâches au modèle. Les capacités de ce dernier ont atteint un nouveau palier, lui permettant d’accomplir de façon autonome des tâches plus complexes — marquant ainsi l’entrée dans une ère totalement nouvelle.
Nous planifions à court et à long terme — jamais à moyen terme
Peter, animateur : Je suis curieux de savoir comment l’application Codex a été développée. Aviez-vous, il y a un an, défini une feuille de route annuelle — par exemple, « Nous prévoyons de lancer l’application Codex à une date précise » ? Ou bien avez-vous davantage observé les besoins du marché et rapidement prototypé certaines idées ?
Alex :
En réalité, aucune de ces deux hypothèses n’est exacte. J’ai entendu un excellent conseil de notre chercheur Andre : « Chez OpenAI, nous planifions soit à court terme, soit à long terme — jamais à moyen terme, car cela devient trop complexe. »
Une planification à court terme couvre généralement une période maximale de huit semaines, qui constitue la durée la plus longue que nous soyons capables de définir. Dans ce cadre temporel, nous fixons un objectif précis et mobilisons toute l’équipe pour le réaliser. C’est l’un des points forts d’OpenAI — nous excellons à organiser une équipe autour d’un objectif clair.
Par ailleurs, nous élaborons également une vision à long terme. Par exemple, nous pouvons imaginer l’état du modèle dans un an, où il sera nettement plus intelligent. Nous pouvons envisager un modèle futur capable de travailler de façon autonome, sans emprunter nos ressources informatiques, et sans être limité à une seule tâche à la fois. Nous rêvons d’avoir un nombre illimité de modèles, capables d’accomplir des tâches, de valider eux-mêmes leur code, voire de se déployer et de s’auto-surveiller — sans aucun besoin d’instructions manuelles de notre part.
Or, la planification à moyen terme semble embarrassante. Elle prend généralement la forme d’une feuille de route produit détaillée — or nous n’en avons pratiquement pas. Notre approche consiste plutôt à articuler notre vision à long terme avec des tâches concrètes capables de nous rapprocher progressivement de cet objectif.
Prenons l’exemple de l’application Codex : l’un de nos objectifs stratégiques était de libérer l’utilisateur de l’espace de travail (workspace) spécifique. Les outils de développement traditionnels (comme VS Code) sont généralement liés à un espace de travail spécifique — par exemple, un point de contrôle spécifique dans un dépôt Git ou un dossier particulier. Même avec git worktree, on ne peut ouvrir qu’un seul répertoire de travail à la fois ; l’interface CLI est soumise aux mêmes contraintes.
Mais notre vision est la suivante : l’utilisateur doit pouvoir collaborer avec des agents intelligents hébergés dans le cloud, capables de travailler de façon autonome. Nous voulons que l’utilisateur puisse interagir simultanément avec plusieurs agents, voire demander à un agent de coordonner le travail de plusieurs autres — une expérience naturelle et intuitive.
Parallèlement, nous savons que si nous nous appuyions exclusivement sur le cloud dès le départ, les développeurs pourraient juger cela peu pratique, car ils devraient configurer leur environnement, et toute intervention manuelle ou ajustement nécessaire durant l’exécution des tâches par le modèle deviendrait fastidieux. Nous avons donc décidé de développer une expérience locale, capable de collaborer sans heurt avec les dossiers locaux tout en restant connectée aux agents intelligents du cloud.
Lorsque nous avons commencé à développer cette application, nous avions une série de « réflexions visionnaires » — des idées assez abstraites. Parallèlement, nos ingénieurs menaient diverses expérimentations. Certains disaient : « Nous devrions créer une application », et se mettaient aussitôt à développer différentes versions. En effet, nous avons organisé une « semaine hackathon », où plusieurs ingénieurs ont développé indépendamment des versions différentes de l’application. Vous y avez peut-être participé — je ne m’en souviens plus très bien.
Lorsque ce projet a véritablement démarré, la seule chose que nous ayons dû formaliser clairement était : pourquoi pensons-nous qu’il est pertinent de développer une application ? Nous n’avons pas rédigé de spécification produit détaillée pour cette application ; c’est à travers le développement concret que sa direction s’est progressivement précisée.
Cependant, ce projet a suscité quelques controverses — devions-nous vraiment développer une application ? Notre extension IDE était déjà très populaire : ne devrions-nous pas plutôt nous concentrer sur son amélioration ? L’interface CLI présentait également un fort potentiel. Alors, si nous développions une application, quelle serait sa valeur ajoutée ? Dans quelle direction devrions-nous orienter nos efforts ? Telles étaient les questions auxquelles nous devions répondre au démarrage du projet.
Romain :
Oui, heureusement, nous disposions déjà d’une solution d’extension IDE très mature, que nous avions largement optimisée. Les utilisateurs peuvent l’utiliser dans VS Code, Cursor, Windsurf et d’autres IDE. Nous avons accumulé une grande expérience à partir de la base de code de cette extension, ce qui a fourni un point de départ extrêmement solide pour le développement de l’application Codex.
Alex :
Exactement. En réalité, l’application Codex et l’extension IDE partagent une grande partie de leur code en arrière-plan. Elles se connectent toutes deux au même cœur de Codex (Codex harness), un framework open source écrit en Rust, que l’interface CLI utilise également. Nous avons volontairement adopté une architecture en couches, afin de favoriser le partage de code et l’extension des fonctionnalités entre différents outils.
Peter, animateur : Concernant la décision de développer l’application Codex… en y repensant aujourd’hui, cela semble une décision évidente, car utiliser l’application Codex est bien plus intuitif que d’ouvrir une multitude de fenêtres de terminal. Mais à l’époque, nos raisons principales étaient : rendre Codex plus accessible aux débutants, et offrir l’interface la plus adaptée pour gérer la collaboration entre plusieurs agents intelligents.
Alex :
Je pense que notre façon de réfléchir est profondément influencée par la vision de l’AGI (intelligence artificielle générale). Nous nous posons constamment la question : à quoi ressemblera le travail de demain ?
En fait, je reformulerais cela ainsi : nous savons clairement qu’il nous faut une interface permettant à l’utilisateur de déléguer naturellement des tâches à plusieurs agents intelligents. Nous savons que les modèles futurs auront cette capacité — et nous avons déjà vu des utilisateurs tenter de déléguer des tâches entre agents. Nous avons donc besoin d’une interface qui rende cette collaboration naturelle, tout en permettant une extension fluide vers le cloud.
Nous voulons que cette interface soit ergonomique, afin que collaborer avec plusieurs agents intelligents apparaisse comme une expérience intuitive et naturelle, sans nécessiter d’opérations complexes ou de techniques particulières.
Romain :
Oui. Et cette application ne s’adresse pas uniquement aux débutants : même les ingénieurs les plus expérimentés et les plus talentueux — y compris ceux d’OpenAI, comme Peter, OpenClaw et Greg Brockman — utilisent désormais l’application Codex comme principal outil de développement. Cela prouve que notre vision de la délégation intelligente d’agents (agentic delegation) devient progressivement une réalité.
Alex :
Oui. Nous mentionnons Peter parce qu’il vient tout juste de rejoindre OpenAI — ce qui nous remplit d’enthousiasme. L’année dernière, en octobre, je me promenais avec lui à Fort Mason, à San Francisco, et je lui avais parlé de l’idée de développer une nouvelle interface. Je lui avais dit que nous voulions une interface qui rende la délégation (delegation) plus naturelle — et il m’avait répondu qu’il n’utiliserait jamais une telle chose.
Mais le week-end dernier, il a publié un tweet disant : « En fait, cette application est plutôt agréable à utiliser — j’en suis désormais fan. »
Quelles sont les activités quotidiennes d’Alex, chef de produit (PM) de Codex ?
Peter, animateur : Alex, vous étiez pendant un temps le seul chef de produit (PM) au sein de l’équipe Codex, n’est-ce pas ? Combien de personnes compte aujourd’hui l’équipe Codex ? Environ 50 à 100 personnes ?
Alex :
À peu près, oui — dans cette fourchette. En mai, nous étions environ 8 personnes, bien que je ne me souvienne plus du chiffre exact. Depuis, l’équipe a connu une croissance très rapide, et compte aujourd’hui entre 50 et 100 personnes.
Peter, animateur : Comment répartissez-vous habituellement votre temps ? Quelle est votre routine quotidienne ? Ou bien existe-t-il même une journée « typique » ?
Alex :
Je réfléchis moi-même à cette question, car je me rends compte que j’ai du mal à y répondre. Je réalise que mon mode de travail est segmenté en phases, mais il s’agit d’une approche personnelle, qui ne convient pas forcément à tout le monde.
Par exemple, lors du lancement de l’application Codex, j’étais entièrement en mode exécution. À ce moment-là, toute mon énergie était concentrée sur la qualité du produit, afin de ne négliger aucun détail et de veiller à ce que chaque petite chose soit soigneusement prise en compte. Dans ce mode, j’ai passé beaucoup de temps à utiliser les outils Codex.
Nous utilisions Codex pour collecter des retours, par exemple pour suivre les discussions sur Slack ou les commentaires des utilisateurs. Je demandais à Codex de résumer ces informations, puis les enregistrais dans Linear. En outre, j’utilisais Codex pour analyser la qualité du code et effectuer directement de petites modifications. Car parfois, traiter directement un petit problème avec Codex est plus rapide que de chercher quelqu’un d’autre, de le solliciter et de lui demander de le traiter en priorité — surtout lorsque notre objectif est de lancer l’application dans un délai de deux semaines.
Bien entendu, de nombreuses tâches humaines accompagnent ce processus : motiver l’équipe, la soutenir moralement, tout en conservant une attitude critique vis-à-vis du produit en cours de développement. Je me rends compte que je suis en mode exécution quand j’utilise fréquemment Twitter — je ne sais pas pourquoi, mais lorsque j’ai besoin d’interagir avec les gens, j’utilise davantage Twitter.
Il existe ensuite un autre mode, comme celui dans lequel je me trouve actuellement, où ma réflexion est très claire : nous avons atteint un nouveau stade. Nous disposons désormais de modèles très puissants — GPT-5.4, par exemple, fonctionne remarquablement bien. Notre expérience utilisateur dépasse même nos attentes, et couvre tous les systèmes d’exploitation, y compris Windows. Je pense donc qu’il est désormais temps de revenir pleinement sur le cloud, et d’y consacrer davantage d’énergie.
Lorsque nous entrons dans cette phase, je passe plus de temps à réfléchir à ce que nous devons faire ensuite, et à évaluer l’état actuel — c’est un mode de coordination. Dans ce mode, je passe moins de temps sur Codex, et j’utilise davantage Codex pour communiquer que pour écrire du code. J’ai donc au moins ces deux modes de travail — et probablement davantage encore.
Peter, animateur : Quelle est la fréquence des alignements interfonctionnels dont vous avez besoin ?
Alex :
Nous n’avons presque pas besoin d’alignements interfonctionnels au sein de l’équipe — nous nous considérons volontairement comme une « équipe de pirates ». Même au sein de l’équipe Codex, nous ne sommes aujourd’hui que moi et deux nouveaux chefs de produit qui viennent de rejoindre l’équipe. Nous avons quelques responsables, bien que jusqu’à récemment, presque tout le monde rapportait directement à moi. Mais nous avançons globalement de façon assez fluide, donc les alignements internes sont minimes.
Cependant, il devient de plus en plus évident qu’une composante essentielle du développement de Codex est la création de cet agent de programmation (coding agent). Et tout le monde commence à comprendre que cet agent ne sert pas uniquement à écrire du code, mais qu’il est également très utile pour d’autres tâches.
Par exemple, nous constatons que les utilisateurs de l’application Codex ne l’utilisent pas uniquement pour coder. Ils l’utilisent pour accomplir diverses tâches tout au long du cycle de vie du développement logiciel, et aujourd’hui, la majorité des employés d’OpenAI utilisent l’application Codex — y compris les non-techniciens, que je vois fréquemment l’utiliser.
Cette prise de conscience nous pousse à réfléchir à la manière de rendre Codex utile non seulement aux développeurs, mais aussi à d’autres profils. Cela exige davantage d’alignements interfonctionnels, car OpenAI dispose également de ChatGPT, utilisé par de nombreux utilisateurs — nous devons donc réfléchir avec beaucoup de rigueur à la manière d’intégrer harmonieusement ces produits.
Romain :
De mon point de vue, notre équipe d’expérience développeur (DevX) agit aujourd’hui presque comme une extension de l’équipe Codex. Nous consacrons la majeure partie de notre énergie à Codex, pour plusieurs raisons.
Tout d’abord, il s’agit d’un produit extrêmement passionnant, que les développeurs adorent utiliser — nous voulons le rendre encore meilleur. Comme l’a dit Alex, notre mode de travail se divise également en plusieurs phases : nous nous engageons aux côtés de l’équipe Codex dans les préparatifs du lancement — par exemple, la production des supports nécessaires, ou la formation des développeurs à l’utilisation optimale de Codex. Après le lancement, nous les guidons également dans l’exploration des usages de Codex dans différents scénarios.
Un autre aspect qui nous passionne particulièrement est le suivant : si l’on regarde l’ensemble de la plateforme OpenAI, des millions de développeurs utilisent déjà aujourd’hui notre API pour construire des applications multimodales — images, voix, etc.
Aujourd’hui, la meilleure méthode de développement consiste à utiliser Codex comme point d’entrée. Si l’on remonte à il y a un an, ou même à l’été dernier, au moment du lancement de GPT-5, nous devions encore rédiger de nombreux guides pour apprendre aux développeurs comment formuler des instructions (prompts) pour GPT-5. GPT-5 est un modèle doté d’une puissante capacité de raisonnement, très différent de GPT-4. Aujourd’hui, nous essayons de permettre aux développeurs d’accomplir ces tâches via Codex et ses compétences (skills), même dans ces cas d’usage.
Par exemple, si vous devez mettre à jour un système d’intégration, nous vous recommandons d’utiliser Codex et ses compétences. Le résultat est que Codex peut presque entièrement accomplir la tâche à votre place. Notre équipe accorde donc une grande importance à la collaboration interfonctionnelle, et considère Codex comme la pierre angulaire de toute la plateforme développeur d’OpenAI.
Alex :
Je pense que notre équipe Codex possède une caractéristique très intéressante dans sa façon de travailler — pour moi, la partie la plus formidable est l’interaction avec la communauté. Que ce soit en ligne ou lors d’événements physiques, nous accordons une grande importance à notre lien avec la communauté.
Lors des lancements de produits, notre travail est fortement orienté lancement — définir clairement ce qui sera lancé et à quelle date ; par ailleurs, nous sommes également très orientés retours — dès que la communauté fournit un retour, nous agissons rapidement pour corriger les problèmes et communiquer avec elle. Notre équipe reste donc constamment connectée, ce que je considère comme extrêmement important.
Par exemple, lors du lancement de l’application Codex, nous avons collaboré très étroitement avec Dom et son équipe. Ils nous ont aidés à organiser un vaste test alpha, invitant un grand nombre d’utilisateurs à participer conjointement au développement du produit. Grâce à leurs retours, nous avons non seulement amélioré l’application, mais aussi enrichi les compétences (skills) et la documentation associées.
Je pense que c’est précisément là que réside l’avantage distinctif de notre équipe Codex : étant donné que nous sommes open source, nous faisons preuve d’une transparence totale sur tout ce que nous faisons, et la communauté nous soutient chaleureusement et généreusement en retour.
Peter, animateur : Parlons un peu de Peter (fondateur d’OpenClaw). Je suis un utilisateur précoce d’OpenClaw. Comment l’avez-vous intégré à votre équipe ? Cette vision de l’agent personnel (personal agent) est-elle liée à son travail actuel ? Comment avez-vous planifié cela ?
Alex :
Il y a deux aspects à souligner. Premièrement, Peter est un utilisateur très intensif de Codex. En fait, OpenClaw a été largement construit avec Codex. Grâce à son expérience d’utilisation, il nous a fourni de nombreux retours précieux, qui ont grandement contribué à l’amélioration de Codex. Bien qu’il s’agisse d’un engagement « à temps partiel », il s’y investit pleinement — ce qui nous remplit d’enthousiasme.
Deuxièmement, je ne peux pas divulguer trop de détails pour le moment, mais je peux dire que il nous aide à construire la prochaine génération d’agents personnels (personal agents), qui seront intégrés directement à ChatGPT.
Romain :
Le point le plus fascinant, selon moi, dans le travail de Peter, est que lorsque les gens utilisent OpenClaw, ils pressentent vaguement les possibilités futures — mais ce qui me stupéfie, c’est que Peter a perçu cette vision bien avant tout le monde.
Si l’on regarde l’ensemble de l’année 2025, il a développé l’année dernière plus de 40 projets open source, tous centrés sur une vision commune : accéder à ses outils personnels — calendrier, tweets, Gmail, etc. — via une interface en ligne de commande. Grâce à ces projets, il a concrétisé la vision des compétences (skills) et des outils en ligne de commande. Et notre agent de programmation (coding agent) actuel est précisément construit sur cette vision.
Dans le futur, cet agent ne sera plus seulement un outil de programmation, mais deviendra tout type d’agent personnel (personal agent). Peter nous a donc fourni des retours extrêmement précieux, ayant déjà développé de nombreux outils qui sont aujourd’hui au cœur de l’écosystème open source.
Peter, animateur :
Je trouve vraiment admirable que des personnes comme Peter parviennent à construire une communauté open source aussi remarquable. Ses outils sont si performants que je ne souhaite plus ouvrir aucune autre application — je veux simplement discuter avec mon petit robot.
Alex :
À quels systèmes l’avez-vous connecté ? L’avez-vous connecté à tout ?
Peter, animateur :
Oui, je l’ai connecté à de nombreux services : il peut accéder à mes informations bancaires, à mon compte YouTube, à mon assistant vocal, à mon calendrier et aux services Google. Lorsque je suis au lit, ma femme me demande : « À qui parles-tu ? », et je réponds : « Je discute avec mon robot OpenClaw. »
Cependant, de nombreux « opportunistes » facturent désormais jusqu’à 5 000 dollars pour aider les autres à configurer OpenClaw. Ainsi, si vous parvenez à le rendre plus accessible et plus facile à utiliser pour tous, ce serait une percée majeure — et vous êtes clairement sur la bonne voie.
Les échelles hiérarchiques professionnelles traditionnelles ne sont plus pertinentes
Peter, animateur : Je me souviens que vous aviez dit quelque chose comme : « Aujourd’hui, la plupart des équipes n’ont plus besoin de tant de chefs de produit (PM). »
Romain :
Je pense que ce qui me stupéfie le plus dans ces outils, ce n’est pas seulement la question de savoir s’il faut ou non un chef de produit (PM). Cela brouille presque toutes les échelles hiérarchiques professionnelles traditionnelles. Autrefois, les rôles étaient clairement définis : les designers concevaient, les ingénieurs développaient, les chefs de produit géraient — et il existait même un ratio « idéal », comme une sorte de « proportion dorée ».
Mais aujourd’hui, si vous êtes ingénieur, votre productivité augmente de façon spectaculaire. Si vous êtes designer, ces outils vous donnent des « superpouvoirs », vous rendant plus technique. Si vous êtes chef de produit, vous ne vous contentez plus d’écrire des documents stratégiques — vous pouvez désormais créer des prototypes. Cela ne signifie pas que vous devez assumer la responsabilité d’une fonction destinée à des milliards d’utilisateurs, mais vous pouvez réellement construire quelque chose avec ces outils, et montrer à votre équipe votre vision concrète.
Ainsi, ce qui me fascine le plus, c’est que les frontières entre toutes ces échelles hiérarchiques s’estompent progressivement. Nous sommes tous, fondamentalement, des « constructeurs » (builders), collaborant étroitement pour construire ensemble.
Alex :
Je me souviens avoir dit quelque part sur internet que si une startup emploie un chef de produit (PM) tout en comptant moins d’une vingtaine d’ingénieurs, cela pourrait constituer un signal d’alarme — j’ai peut-être effectivement formulé une phrase similaire.
Je pense, comme vous l’avez dit, que tous ces rôles se fondent progressivement les uns dans les autres. Les designers peuvent désormais accomplir davantage de tâches d’ingénierie, les ingénieurs peuvent s’impliquer dans la conception, et les chefs de produit peuvent participer à la construction. Toutefois, les ingénieurs doivent généralement se concentrer sur l’écriture de code, donc ils ne s’occupaient pas auparavant du tri des tâches ou d’autres aspects de gestion de projet propres aux PM.
Mais aujourd’hui, ces tâches sont devenues très faciles. Vous pouvez directement demander à un agent — comme Codex — d’analyser les retours et de définir les priorités, ce qui permet aux ingénieurs de consacrer davantage de temps à leur travail propre. Je pense que chacun peut désormais accomplir le travail des autres.
Scott Belsky a formulé une idée qu’il appelle le « collapsus de la pile de talents » (collapse the talent stack). J’apprécie beaucoup cette notion, et je pense qu’elle est en train de se concrétiser. Moins il y a de personnes dans la pièce, plus les choses avancent efficacement, et plus chaque décision devient claire.
La question devient alors : que peut encore faire un chef de produit (PM) ? Je pense que beaucoup de chefs de produit devraient envisager de changer de rôle. Par exemple, si vous êtes chef de produit et que vous avez toujours voulu devenir ingénieur, mais que vous êtes plus doué pour la gestion des personnes que pour la programmation, vous pourriez désormais devenir un manager d’ingénierie (engineering manager). Avec les agents intelligents, ce rôle pourrait devenir plus clair pour vous. De même, certains chefs de produit pourraient préférer devenir designers, plus proches du travail concret de construction.
Je pense que tout dépend finalement de vos intérêts personnels. Pour ma part, l’intérêt personnel et l’autonomie sont les qualités humaines les plus fondamentales et les plus importantes à l’ère de l’AGI. Ainsi, si vous êtes plus attiré par la programmation, et que vous n’avez exercé le rôle de chef de produit que parce que quelqu’un devait assumer cette fonction, vous pouvez désormais vous reconvertir en ingénieur et accomplir la même tâche, mais sous un angle technique. Il en va de même dans le domaine de la conception.
Mais si ce qui vous passionne réellement, c’est l’interaction avec les utilisateurs, même si cela vous éloigne du travail concret de construction — comme tenter de comprendre leurs besoins ou d’identifier les tendances du marché — alors, dans une équipe suffisamment grande, le rôle de chef de produit conserve toute sa pertinence.
Romain :
J’ajoute un point : je pense qu’il faut toujours qu’une personne humaine assume la responsabilité d’un domaine problématique donné, mais je ne pense pas que cette personne doive forcément être un chef de produit (PM) — cela dépend largement de la nature du produit.
Nous avons beaucoup de chance ici, car nous travaillons sur Codex, un outil destiné aux développeurs. Nous sommes nous-mêmes nos meilleurs utilisateurs. Et comme il est open source, nous pouvons interagir directement avec la communauté et co-développer avec elle.
Mais si l’on remonte à il y a dix ans, par exemple lorsque je travaillais chez Stripe, l’entreprise comptait 250 personnes, sans aucun chef de produit (PM), ni aucun outil d’IA. Pourquoi ? Parce que Stripe est un produit API, et que nous étions tous ingénieurs, possédant une intuition très forte de ce qu’est une excellente API. Nous construisions l’API dont nous rêvions — une solution élégante, implémentable en quelques lignes de code seulement.
Mais si vous opérez dans un domaine différent, où les ingénieurs n’ont pas une intuition aussi forte des besoins des utilisateurs, vous aurez probablement besoin de davantage de chefs de produit pour dialoguer avec les clients et comprendre leurs besoins. Plus le domaine ou l’industrie que vous servez diverge de l’intuition des ingénieurs, plus le rôle du chef de produit devient crucial. Heureusement, au sein de l’équipe Codex, nous construisons précisément l’outil que nous désirons utiliser nous-mêmes.
Alex :
Dans ce contexte, le rôle de chef de produit (PM) pourrait simplement être une étiquette désignant la personne la plus intéressée par les utilisateurs et la plus attentive à leurs besoins — une personne qui pourrait tout aussi bien être un ingénieur très proche des utilisateurs. Je pense donc que ces étiquettes professionnelles perdent progressivement leur sens traditionnel — bien que cela crée un certain désordre, ce n’est pas forcément une mauvaise chose.
Peter, animateur : J’ai fait moi-même une observation similaire au sein de mon équipe. Je constate que les meilleurs ingénieurs ne me demandent pas « Que devrions-nous construire ensuite ? » — ils vont directement parler aux utilisateurs, comprennent eux-mêmes ce qu’il faut développer, puis reviennent m’en parler. Cette approche assure une parfaite cohérence des objectifs au sein de l’équipe.
Romain :
C’est précisément la manière dont fonctionne aujourd’hui l’équipe Codex : de nombreuses fonctionnalités présentes dans l’application Codex aujourd’hui sont des idées brillantes venues « d’en bas » (bottom-up) d’ingénieurs, car ils en avaient eux-mêmes besoin.
Alex :
Je voudrais toutefois souligner un type d’ingénieur avec lequel j’aime particulièrement collaborer. Ils aiment interagir avec les utilisateurs et réfléchir à ce qu’il faut construire. Ces personnes excellent également dans la construction de systèmes — elles sont rapides, performantes et claires dans leur raisonnement. Mais il existe aussi des ingénieurs qui n’ont absolument aucun intérêt pour l’interaction avec les utilisateurs — ils veulent uniquement se concentrer sur la construction de systèmes. Je pense qu’ils ont également un immense potentiel de développement.
Encore une fois, c’est ma vision de l’ère de l’IA : nous pouvons tous devenir davantage « nous-mêmes ». L’IA et l’équipe nous aideront à accomplir les tâches que nous ne souhaitons pas faire, afin que nous puissions nous concentrer sur nos intérêts et nos forces.
Peter, animateur : Je pense effectivement que l’étiquette de « constructeur » (builder) est très importante. Beaucoup de chefs de produit aspirent à devenir des leaders, mais l’échelle hiérarchique traditionnelle veut que, lorsqu’on devient VP ou autre, on n’ait plus le temps de construire quoi que ce soit. On passe ses journées en réunions d’analyse produit, à donner des retours, sans jamais avoir le temps de développer réellement — et je pense que beaucoup de chefs de produit ne souhaitent pas cela. Je souhaite rester constamment proche des utilisateurs et lancer réellement des produits.
Alex :
Je suis entièrement d’accord. Je ne considère pas le chef de produit (PM) comme un rôle de leadership, mais plutôt comme un « rôle comblant les lacunes ». Parfois, ce rôle peut impliquer certaines responsabilités de leadership, mais même dans ce cas, le leadership consiste davantage à aider l’équipe à parvenir à un consensus, plutôt qu’à compter sur une seule personne pour proposer une solution géniale.
Une chose est sûre : les meilleurs chefs de produit (PM) chez OpenAI plongent profondément dans les détails. Et je pense qu’intégrer OpenAI à un poste de direction supérieur est une tâche très exigeante, car la culture de l’entreprise continue de valoriser l’attention portée aux détails. La meilleure approche est donc de s’immerger directement dans les détails dès le départ.
Que recherche l’équipe Codex lorsqu’elle recrute ? (Ce n’est pas votre CV)
Peter, animateur : Lorsque vous recrutez pour l’équipe Codex, outre le fait que les candidats soient des utilisateurs intensifs de Codex, quelles autres qualités recherchez-vous ?
Alex :
J’ai déjà mentionné que je valorise énormément l’« autonomie » (agency) des candidats. Nous recherchons des personnes capables d’agir de leur propre initiative — c’est l’une des qualités les plus importantes.
Chez OpenAI, et plus particulièrement au sein de l’équipe Codex, notre culture n’est pas celle où l’on vous accueille en vous présentant une liste de 12 tâches, de difficulté croissante. Notre approche est plutôt : « Bienvenue ! Maintenant, lancez-vous dans l’exploration. »
Nous préférons donc rechercher des personnes autodidactes — actives, dotées de leurs propres idées, sachant ce qu’elles veulent accomplir, et n’ayant pas peur de remettre en question les idées existantes. Car, soyons honnêtes, certaines de ces idées peuvent être erronées — ou n’être que le fruit d’une décision aléatoire prise à un moment donné.
Mon collègue idéal est quelqu’un qui accepte volontiers des responsabilités supplémentaires, voire accepte de s’engager dans des domaines encore inconnus. Ce sont ces qualités que nous privilégions. Quant aux compétences techniques, nous accordons généralement la priorité aux candidats fortement orientés ingénierie.
Romain :
Je suis entièrement d’accord. Au sein de mon équipe d’expérience développeur (DevX), je recherche principalement des personnes dotées d’une forte autonomie. Elles doivent être techniquement très fortes, en particulier dans l’utilisation d’outils comme Codex. Mais au-delà de cela, je recherche particulièrement des personnes passionnées par le travail avec les développeurs et les « constructeurs » (builders), ainsi que par le partage de connaissances.
Par exemple, cette semaine, nous avons annoncé que Thomas rejoindrait mon équipe. Il est l’auteur du monitor Codex open source. Il est non seulement extrêmement créatif, mais aussi un utilisateur intensif de Codex, et passionné par le partage de ses méthodes pour construire des outils avec Codex.
Nous avons besoin de ce type de talents, car nous essayons de guider des millions de développeurs vers l’avenir radieux que représente Codex. Je crois que la programmation par agents (agentic coding) transforme radicalement notre façon traditionnelle de concevoir le développement logiciel, les applications et les produits. Notre objectif est de montrer au monde entier cette possibilité, et d’aider les développeurs à apprendre à utiliser ces outils pour concrétiser leurs idées. Voilà les qualités que je recherche.
Alex :
J’ajoute que, selon moi, le candidat idéal pour l’équipe DevX peut être décrit simplement comme « un excellent ingénieur, capable en outre d’interagir efficacement avec la communauté via les réseaux sociaux ».
Romain :
Vous avez raison sur un point. Mais je voudrais ajouter ceci : nous recherchons des candidats dotés d’un fort sens de la responsabilité envers la communauté, tout en tenant compte des habitudes variées d’utilisation des réseaux sociaux à travers le monde. Par exemple, dans certaines régions, les développeurs préfèrent LinkedIn ou d’autres plateformes plutôt que Twitter. Nous devons donc élargir cette définition : le candidat doit avoir une bonne présence sur les réseaux sociaux à l’échelle mondiale. Nous accordons une attention particulière aux personnes aimant interagir avec la communauté, enseigner et partager leurs connaissances.
Peter, animateur : En réalité, l’autonomie d’une personne se manifeste même avant l’entretien. Par exemple, publie-t-elle ses travaux en ligne ? A-t-elle des projets parallèles (side projects) ?
Alex :
Lorsqu’une personne m’envoie un message privé pour exprimer son intérêt à rejoindre notre équipe, ma première réaction est : « Avez-vous un lien ? » Si un lien est fourni, je clique presque systématiquement dessus. Je suis curieux de découvrir ses travaux, pour vérifier si elle construit réellement quelque chose.
Bien sûr, certaines personnes joignent une lettre de motivation expliquant pourquoi elles sont intéressées par ce poste, voire leur CV, mais ce que je préfère voir, ce sont leurs idées et les projets concrets qu’elles ont réalisés. J’ai récemment pris conscience d’un fait intéressant : je n’ai aucune idée de l’université qu’elles ont fréquentée.
Peter, animateur : Qui s’en soucie ? Qui y prête attention ? Je suis vraiment ravi de vivre aujourd’hui dans une ère où ces diplômes absurdes n’ont plus autant d’importance — il me suffit de voir ce que vous avez réellement construit.
Bienvenue dans la communauté officielle TechFlow
Groupe Telegram :https://t.me/TechFlowDaily
Compte Twitter officiel :https://x.com/TechFlowPost
Compte Twitter anglais :https://x.com/BlockFlow_News
深潮TechFlow
