Si l'on vous demandait quel produit d'IA a connu la croissance la plus remarquable en 2026, « Codex » serait certainement en tête de liste.
Depuis le mois de janvier de cette année, le nombre d'utilisateurs actifs hebdomadaires de ce produit a été multiplié par plus de 5, présentant une courbe de croissance très raide. Actuellement, son échelle d'utilisateurs actifs hebdomadaires a atteint 5 millions. Parmi eux, la vitesse d'adoption de Codex par les travailleurs du savoir (non-développeurs) est plus de 3 fois supérieure à celle du groupe des développeurs.
Il est à noter que ces courbes de croissance abruptes ont un catalyseur important : la sortie de l'application de bureau en février. Cette version de bureau offre une interface d'utilisation exclusive et optimisée, abaissant considérablement la barrière d'entrée et conduisant à une croissance explosive des téléchargements et de l'adoption de Codex.
Derrière cette courbe de croissance vertigineuse, le rôle qui pousse l'évolution de la forme du produit est un acteur relativement moins discuté publiquement : Andrew Ambrosino, responsable de l'équipe de l'application de bureau Codex.
En tant que personne directement responsable de l'évolution du produit côté bureau de Codex, il se trouve à la jonction de deux mondes qui convergent rapidement : d'un côté, la chaîne d'outils des développeurs centrée sur « l'écriture de code », et de l'autre, un point d'entrée de travail en IA générale qui s'étend rapidement à presque tous les scénarios de travail du savoir. Du rythme de sortie des produits aux changements de comportement des utilisateurs, en passant par la manière dont l'équipe redéfinit les frontières entre « design », « ingénierie » et « produit », ce qu'il observe est souvent plus proche de l'essence de ce changement que les données de croissance elles-mêmes.
L'interview qui suit part de sa perspective pour décortiquer ce que Codex a changé, pourquoi il a fusionné avec ChatGPT, et quelles sont ses futures directions d'itération.
Lien vidéo : https://www.youtube.com/watch?v=P3KDebPTUrw
Nous avons organisé une partie du contenu de l'interview, pour les détails veuillez vous référer à la vidéo originale.
La mise en œuvre devient moins chère,
mais quoi devient plus cher ?
Il y a quelques années, la logique du développement produit était la suivante : la mise en œuvre était chère. Donc, avant de se mettre à écrire du code, il fallait faire un énorme travail préparatoire pour limiter les risques : écrire de la documentation, faire des recherches, créer des prototypes, le but étant de rendre le design moins coûteux. Parce que la mise en œuvre elle-même était coûteuse, il fallait tout clarifier en amont.
Mais maintenant, cette hypothèse s'est complètement inversée. Chez OpenAI, la situation est devenue : donnez aux gens beaucoup de tokens, tout le monde a de bonnes idées, donc tout le monde construit des choses. Le résultat, c'est qu'une fonctionnalité à faire, ce sont potentiellement 90 équipes différentes explorant simultanément 90 manières différentes de l'implémenter.
Cela signifie que la mise en œuvre n'est plus la partie coûteuse. Alors, quoi devient plus cher ? Andrew est direct : c'est le goût. Plus concrètement, c'est le processus de curation. Lorsque vous êtes face à ces 90 tentatives différentes, vous devez avoir l'œil pour juger : quelles choses sont bien faites ? Comment devraient-elles être intégrées dans d'autres fonctionnalités ? Comment ceci devrait-il être cadré ? Ce bouton de bascule devrait-il avoir combien de niveaux ? Ces décisions en elles-mêmes sont désormais l'endroit le plus cher, le plus demandeur de réflexion.
Qu'est-ce que le goût exactement ?
Le mot « goût » est galvaudé dans la Silicon Valley. Mais pour Andrew, il a une signification très concrète.
Il y a une anecdote intéressante : le responsable produit de Linear disait que certaines personnes surestiment la partie esthétique du goût, citant Paul Graham en exemple — Paul Graham a clairement du bon goût, mais il porte des salopettes. Cela montre que le goût va bien au-delà de l'apparence. Andrew énumère les connotations du goût : il y a un niveau esthétique, mais ce n'est qu'une partie ; il y a un niveau de pensée systémique, c'est-à-dire comment cette chose s'intègre dans le système entier ; il y a un niveau de sens de la direction, de quelle partie d'un thème cela fait partie ; il y a un niveau de manière de présenter les choses. Bien sûr, il y a aussi des niveaux de détail, comme savoir si l'animation d'interaction correspond au sens sémantique qu'elle veut exprimer — est-ce qu'elle est trop rapide pour exprimer ce concept.
Mais la vraie question centrale du goût est celle-ci : si nous pouvons construire n'importe quoi, alors que voulons-nous ? Qu'est-ce que c'est ? Comment y arrivons-nous ? Ce sont là les vraies questions de goût.
Il ne s'agit pas seulement de choisir quoi faire. Il s'agit aussi de savoir comment présenter l'information, comment atteindre l'objectif, quel support utiliser. Le goût est, dans cette nouvelle ère, l'endroit où le cerveau humain reste le plus précieux.
Pourquoi l'IA n'arrive-t-elle toujours pas à bien faire le design ?
C'est un paradoxe intéressant : Codex est déjà très puissant pour écrire du code, mais quand on l'utilise pour générer du design, la qualité de la sortie est souvent médiocre. Il est rare de dire « waouh, il a tout compris ».
Andrew pense qu'il y a plusieurs raisons à cela. Premièrement, une raison pratique : le design est plus difficile à noter que le logiciel, car le goût humain qui évalue la qualité du design fait lui-même partie du mécanisme de rétroaction. Cela rend l'entraînement des modèles difficile — contrairement au code, il est difficile d'utiliser des critères objectifs (est-ce que le code compile ? La fonction marche-t-elle ?) pour mesurer. Ensuite, du point de vue de l'investissement en recherche, les laboratoires ont traditionnellement mis le plus de ressources à améliorer les capacités qui accélèrent la recherche en IA elle-même. Aux débuts des modèles de codage, il était clair que pouvoir écrire du code correct accélérait la recherche. Mais la qualité des capacités de design n'accélère pas directement la recherche en IA de la même manière.
Un problème plus profond concerne la complexité du travail de design lui-même. Il y a une dimension culturelle dans le design — ce qui constitue un « bon design » est déterminé par la culture. L'année dernière, tous les nouveaux sites web copiaient le design de Linear, c'était du bon design, du goût. Mais si un modèle sortait à chaque fois quelque chose qui ressemble à Linear, ce ne serait pas un progrès, mais un échec. Le design a besoin de nouveauté, tandis que l'ingénierie logicielle est l'inverse, on veut presque toujours que le code suive des modèles connus.
Le problème le plus difficile à résoudre concerne le niveau d'abstraction. Lorsque le code pilote le design visuel, il existe une interaction profonde entre les deux. Par exemple, quelque chose en haut à gauche devrait partager la même abstraction dans la base de code qu'un endroit en bas. Il ne s'agit pas seulement de dire que le modèle doit devenir un meilleur designer, mais que le modèle doit comprendre ces relations structurelles plus profondes — si l'entreprise refaisait sa marque demain, l'approche superficielle serait de mettre à jour un à un 263 composants, mais la compréhension profonde serait : ces deux choses qui semblent différentes sont sémantiquement les mêmes, ce sont toutes deux des listes, ont le même style, communiquent le même mode d'interaction. Cette compréhension du niveau d'abstraction reste actuellement hors de portée pour l'IA.
Pourquoi Codex n'a-t-il pas pu sortir plus tôt ?
C'est une observation très profonde : le succès d'un produit ne dépend pas seulement du design lui-même, mais aussi du moment des capacités du modèle.
Andrew est très certain que si l'application Codex était sortie en novembre dernier, elle aurait échoué complètement sur le marché. Alors que le même produit, avec la même forme, sorti en février, a connu un énorme succès. La seule variable est l'amélioration des capacités du modèle au cours de ces quelques mois intermédiaires. En d'autres termes, le design d'interaction, l'interface utilisateur, tout le concept du produit n'ont pas changé, mais l'amélioration de l'intelligence du modèle a complètement changé le résultat.
Cela révèle une vérité profonde : à l'ère de l'IA, le fait qu'un produit soit facile à utiliser ou précieux n'est pas déterminé uniquement par le design de l'UI ou de l'UX, mais par « ce que le modèle peut faire à ce moment précis ». Une même idée, implémentée avec un ancien modèle, peut être inutile, mais avec un nouveau modèle, elle peut être passionnante.
Cela change aussi la manière de planifier les produits. Andrew a vu cette transition dans une entreprise précédente : ce n'est plus « nous planifions ce que nous ferons toute l'année », mais c'est devenu « nous croyons à ce que le modèle pourra faire à tel moment, listons toutes les choses qui nous intéressent, faisons des prototypes pour toutes, puis décidons lesquelles nous pouvons faire maintenant, les autres nous les mettons en attente, et quand le modèle fera un nouveau bond en avant, nous réessaierons ces idées mises de côté précédemment avec le modèle amélioré ». Parce que la condition préalable pour qu'une fonctionnalité soit bonne à utiliser n'est pas la forme du design, mais si le modèle est suffisamment intelligent.
Les frontières entre ingénieur, designer et chef de produit ont-elles disparu ?
Lenny mentionne qu'en regardant le parcours d'Andrew, il a été ingénieur, designer, chef de produit, entrepreneur, et qu'il dirige maintenant toute l'application de bureau, et demande si l'équipe design lui rapporte aussi. Andrew rit en disant « cela dépend de la semaine » — les relations hiérarchiques changent constamment, mais l'équipe a toujours travaillé étroitement assise ensemble, intégrée les uns avec les autres.
Andrew dit que l'extérieur discute déjà de « l'effondrement des rôles », en disant qu'à l'avenir il n'y aura plus de rôles séparés, son équipe n'en est pas encore là, mais le chevauchement entre les rôles est en effet plus marqué que dans d'autres départements de l'entreprise, voire dans toute l'industrie — en partie parce que Codex est à l'origine un produit technique pour ingénieurs, les designers de l'équipe parlent le langage des ingénieurs, les chefs de produit savent aussi coder, par exemple l'autre responsable produit Alexander a un master en informatique, tandis qu'Andrew lui-même n'en a pas.
Il pense que maintenant, une façon plus précise de le dire est : une personne n'est plus définie par des frontières comme « où le design s'arrête, où l'ingénierie commence », mais par ce sur quoi elle passe son temps en moyenne — cela est aussi lié à la manière de travailler de l'équipe, car toute l'appli a été construite en « mangeant sa propre nourriture pour chiens » en interne, tout le monde veut essayer de faire les choses dans l'appli autant que possible, même si ce n'est pas encore le meilleur outil pour le faire, afin qu'elle puisse progressivement devenir le meilleur outil. Ils discutent aussi de l'origine du titre « member of technical staff », Andrew pense que c'est peut-être Xerox qui a commencé à l'appeler ainsi, et que c'est maintenant une tradition dans les entreprises axées sur la recherche.
Lenny demande si cela signifie que tout le monde deviendra à l'avenir des « constructeurs » sans distinction de fonction, et si les classifications de compétences comme PM, design, ingénierie existeront encore. L'attitude d'Andrew est claire : il n'est pas d'accord avec une suppression totale des rôles. Il a vu des entreprises déclarer « supprimons le poste de produit, tout le monde est un constructeur », le résultat étant que les meilleures pratiques et l'expérience accumulées pendant des années par cette profession sont jetées comme inutiles à cause de l'idée « je peux aussi coder ». Il accueille favorablement la disparition de ce sentiment de frontière du type « ce n'est pas ton territoire », mais chaque métier conserve ses propres seuils de compétence — ce n'est pas parce que quelqu'un utilise Excel qu'il peut aller remplacer le service financier.
Il mentionne aussi qu'il est effectivement plus facile de changer de rôle maintenant, car les capacités ne sont plus rigidement liées à la « maîtrise d'un outil spécifique » : lui-même a longtemps pensé qu'il ne devrait pas être ingénieur parce qu'il n'aimait pas plonger dans le langage d'assemblage, mémoriser la syntaxe TypeScript, et ce seuil de « maîtriser un outil spécifique pour bien faire le travail » est en train de s'effondrer. Cependant, il rappelle que cette tendance est actuellement exagérée par le monde extérieur.
La méthode la plus avancée actuelle de développement assisté par l'IA
Lenny ramène la conversation d'un cran : du code écrit purement à la main, à l'IA capable d'écrire 100% du code, et maintenant « écrire du code » devient « guider l'IA » — évaluer combien de code une personne a écrit devient presque « combien de fois as-tu corrigé la direction de l'IA ». Il demande si la pratique la plus avancée maintenant n'est pas le « loop » (développement en boucle autonome). Comment fonctionnent concrètement les équipes d'IA les plus en pointe aujourd'hui ?
Andrew mentionne qu'une question fondamentale est que « combien de code est écrit par l'IA » n'a plus d'importance en soi, car selon les standards de l'année dernière, maintenant presque 100% du code est écrit par l'IA ; la vraie question à se poser est : ce code a-t-il été écrit de manière « supervisée » ou « non supervisée », ce sont deux choses complètement différentes. Il dit être heureux de voir ces critères d'évaluation constamment renouvelés, car cela montre justement que le produit avance. L'équipe a fait beaucoup d'exploration dans la direction du « développement de logiciel autonome », y compris de nombreuses tentatives liées au « harness engineering », par exemple imaginer que le modèle s'exécute seul la nuit, faisant un nettoyage de type « garbage collection » de la base de code.
Il admet aussi que tous les modèles ont actuellement un défaut commun — ils ont tendance à rendre le code de plus en plus complexe. Il dit en plaisantant à moitié que si une équipe de recherche d'une entreprise écoute, il espère qu'ils amélioreront la capacité du modèle à « supprimer du code ». C'est aussi un problème pratique rencontré lorsqu'on confie complètement le développement à une conduite autonome, des deux côtés, humain et base de code : comment apprendre au modèle à juger quelles fonctionnalités faire, lesquelles ignorer, lesquelles fusionner et reclasser ; comment apprendre au modèle à construire la bonne structure d'abstraction. Ces capacités s'améliorent, mais il pense qu'actuellement, on ne peut pas encore atteindre le niveau « définir une boucle pour qu'il améliore le produit tout seul, tout en surveillant Twitter, Slack, les emails », mais l'équipe travaille continuellement dans cette direction.
Lenny demande s'il arrivera un jour où l'équipe se contentera de définir un objectif ultime à l'IA comme « gagner » ou « me rapporter un milliard ». Andrew répond en souriant qu'il n'ose pas dire des choses définitives, il n'affirmera pas facilement « jamais » ou « absolument ».
Pourquoi fallait-il absolument fusionner Codex et ChatGPT ?
Quel est l'avenir de Codex ?
Codex était à l'origine un outil en ligne de commande, devenu plus tard une application indépendante, avec un positionnement initial très clair : un « outil pour développeurs » — pas un IDE, pouvant voir du code, mais ne permettant pas d'éditer du code.
Avant la sortie officielle de l'appli, l'équipe a d'abord fait un essai interne chez OpenAI (janvier-février). Les retours dans les scénarios d'ingénierie et de recherche étaient très clairs, très positifs. Mais l'équipe a simultanément découvert que les gens de presque tous les autres départements — marketing, relations publiques, finance, juridique — utilisaient aussi cette appli, même si elle n'était pas conviviale pour eux, l'interface étant pleine de code et de demandes d'autorisation en ligne de commande, ce n'était absolument pas une expérience conçue pour eux.
La première réaction de l'équipe a été de déplacer les capacités de Codex vers d'autres interfaces de produits, comme l'application de bureau ChatGPT et le navigateur Atlas, pour en faire des outils plus généraux pour le travail du savoir. Mais le résultat a été que personne ne voulait quitter l'appli Codex pour utiliser ces applis « spécialisées ». Cela a fait réaliser à l'équipe : la frontière entre outil pour développeurs et outil général pour le travail du savoir est en train de s'effondrer, Codex et ChatGPT ressemblent plus à différentes entrées vers la même capacité, plutôt qu'à deux produits indépendants.
La conclusion de l'équipe est : ce produit devrait être construit comme une base suffisamment générique et extensible, capable de prendre en charge simultanément des scénarios profonds comme la finance, le juridique, la science. Le vrai défi n'est que de « savoir comment le rendre suffisamment générique » — c'est aussi la réponse de l'équipe à la question « Codex est-il un outil pour développeurs, ou est-ce simplement ChatGPT ? ».
L'animateur Lenny souligne alors : Codex est déjà devenu plus facile à utiliser, plus amusant que l'appli ChatGPT elle-même, les utilisateurs vont l'utiliser, donc la fusion est une direction inévitable pour éviter la confusion cognitive.
Andrew répond en souriant que certaines personnes appellent cette direction « super application », il regrette un peu que quelqu'un ait prononcé ce terme, car depuis, il est entouré quotidiennement par cette expression.
Lenny demande : sans l'appeler « super application », l'idée centrale est-elle « l'utilisateur arrive à un endroit et peut tout faire » ? Ou est-ce que cela n'est pas encore décidé ?
La réponse d'Andrew est le concept de « home base » (base d'opérations) : cela devrait être un bon « camp de base », un endroit où l'utilisateur peut suivre toutes ses tâches en cours sur différentes interfaces de produits. Certaines choses, l'utilisateur peut les accomplir entièrement à l'intérieur de l'appli ; pour d'autres choses, l'appli est responsable d'appeler, d'ouvrir d'autres applications pour les accomplir — par exemple, l'appli peut se connecter à Excel, l'appli a effectivement un éditeur de feuille de calcul intégré, mais pour quelqu'un qui fait une levée de fonds de plusieurs milliards de dollars chez OpenAI et a besoin de modélisations financières complexes, cet éditeur intégré est probablement très insuffisant. Donc l'appli dialoguera directement avec le plugin Microsoft Excel sur le bureau de l'utilisateur, et une fois terminé, l'utilisateur pourra simplement fermer Excel.
En d'autres termes, cela n'a jamais été « nous dessinons un rectangle à l'écran, tout doit se passer dans ce rectangle », mais plutôt — cette chose devrait devenir une « maison » pour l'utilisateur : vous commencez votre travail ici, vous le terminez ici, vous automatisez votre travail, et quand vous avez besoin d'un outil, il va appeler cet outil.
Pour illustrer cela, Andrew raconte une histoire concrète. Lors de la sortie initiale de l'appli Codex, l'équipe a tourné des vidéos de promotion, et le travail de montage de ces vidéos est revenu au photographe interne. Résultat, le photographe a monté entièrement ces vidéos en utilisant Codex — c'était l'un des premiers moments où l'équipe a vraiment réalisé « mon dieu, les gens utilisent vraiment ça pour ça ».
Le photographe a pensé à utiliser Codex pour monter des vidéos purement par curiosité, juste pour voir si Codex pouvait vraiment faire ça. Codex n'est pas du tout un éditeur vidéo en soi, son interface n'a aucune UI liée au montage, mais il pouvait comprendre que le photographe utilisait Premiere Pro, et en éditant directement les fichiers d'ingénierie en arrière-plan qui soutiennent l'affichage à l'écran de Premiere Pro, il pouvait accomplir une partie des opérations de montage — mais cela ne couvrait pas tous les besoins. Alors, ce que Codex a fait ensuite, c'est s'écrire à lui-même une extension qui pouvait s'installer dans Premiere Pro, puis communiquer avec Premiere Pro via cette extension — « Hé, extension Premiere Pro, peux-tu changer ce point de repère ? » La première fois que l'équipe a vu ce processus se produire réellement, tout le monde a trouvé cela incroyable.
De là, Andrew résume un modèle : il existe déjà dans le monde un grand nombre d'outils professionnels excellents dans leur domaine, Codex — et maintenant il faut ajouter ChatGPT — veut faire deux choses simultanément.
La première chose, c'est comment collaborer de manière transparente avec les outils que l'utilisateur utilise déjà : l'équipe n'a pas besoin de reconstruire un meilleur éditeur vidéo, mais d'apprendre à Codex et ChatGPT à utiliser les outils existants — pouvoir interagir avec eux, leur passer des tâches, généralement via des connecteurs, des capacités d'utilisation de l'ordinateur, ou comme dans le cas de Premiere Pro, via des extensions.
La deuxième chose, c'est le scénario mentionné par Dan Shipper : l'utilisateur a déjà une série d'applications web sur lesquelles il peut cliquer, mais il aimerait pouvoir les ouvrir directement dans Codex, laissant Codex y faire plus de choses pour lui. Ces deux modèles sont presque des images miroir l'un de l'autre, et l'équipe pousse activement ces deux pistes en parallèle actuellement.
Cet article provient du compte WeChat officiel « Machine Heart » (ID : almosthuman2014), auteur : Machine Heart
