Lorsque Codex est sorti, quelqu'un de l'équipe m'a demandé : « Que ferons-nous lorsque Codex pourra résoudre en un seul essai les cas d'usage auxquels nous avons consacré les derniers mois ? »
Cette question touche au cœur de ce que signifie FDE chez OpenAI. Nous travaillons aux côtés des clients pour comprendre leurs problèmes les plus difficiles et construire des solutions sur lesquelles ils peuvent compter. Ce que nous apprenons contribue à façonner nos produits et donne à la Recherche des problèmes concrets à résoudre.
C'est cela, le progrès. Si nous nous rendons obsolètes tous les deux mois, c'est que notre équipe FDE fait bien son travail.
J'ai fondé l'équipe début 2025 pour combler ce que nous appelons « l'écart de déploiement » : la distance entre ce que les modèles semblent capables de faire et ce que les gens peuvent utiliser de manière fiable pour accomplir leur travail.
Les capacités des modèles ont évolué plus vite que les systèmes et les processus nécessaires pour les mettre en œuvre. Parfois, la pièce manquante est un produit. Parfois, un modèle obtient de bons résultats sur un benchmark mais ne peut pas faire le travail avec les variables et les contraintes du monde réel.
Nous nous concentrons sur les problèmes les plus difficiles des clients. Là où nos modèles peuvent faire le travail aujourd'hui, nous travaillons avec l'équipe Produit et le client pour rendre la solution répétable ; là où ils sont insuffisants, nous travaillons avec les clients et la Recherche pour définir l'écart et apporter des améliorations. Notre objectif est que chaque mission laisse au client suivant un meilleur point de départ — si nous élevons le plancher au point que nos clients n'aient plus besoin de FDE pour résoudre ce type de problème la prochaine fois, nous avons bien fait notre travail.
Le défi de John Deere, une entreprise agricole vieille de 200 ans, était de savoir comment déployer à grande échelle des conseils personnalisés pour les agriculteurs.
Un exemple est See & Spray, sa technologie de désherbage de précision, qui utilise des caméras et l'apprentissage automatique pour identifier et pulvériser les mauvaises herbes plutôt que de traiter des champs entiers, afin de réduire l'utilisation de produits chimiques jusqu'à 70%.
Mais concrétiser ces avantages dépend du fait que les agriculteurs sachent configurer la technologie, planifier leur saison et ajuster leurs pratiques à mesure que les conditions changent.
John Deere a déployé les API d'OpenAI pour rendre ce support personnalisé et évolutif.
L'IA peut répondre aux questions des agriculteurs en langage naturel, fournir des instructions de configuration et des recommandations sur mesure, identifier le moment où un équipement peut ne pas donner son plein potentiel, et aider les agriculteurs à comprendre la valeur qu'ils tirent de la technologie.
L'opportunité va au-delà d'une simple interaction : il s'agit de fournir des conseils pertinents tout au long du parcours client, aidant les agriculteurs à mieux utiliser leur équipement tout en améliorant l'efficacité et la durabilité.
C'est le type de défi que les FDE d'OpenAI s'efforcent de résoudre : aider les organisations à passer des capacités de l'IA à des systèmes qui apportent une valeur pratique dans des environnements réels complexes.
Mais les problèmes sont souvent très ouverts, il peut n'exister aucune vérité terrain établie, et il n'y a pas de guide. Tout le monde veut construire quelque chose qui n'a jamais existé. Moins de gens veulent faire ce qu'il faut pour y parvenir.
Trouver des FDE talentueux tout en élevant le niveau de référence du « suffisamment bon » a exigé une expérimentation et une application constantes.
Commencer par le résultat
Au début de chaque session de l'équipe FDE, je projette une diapositive avec une valeur fondamentale : « Commencer par le résultat, faire ce qu'il faut pour réussir, puis passer à l'échelle ».
Une démo impressionnante peut faire long feu avant que quiconque ne demande si elle fonctionne dans le monde réel.
Notre travail est de résoudre le problème du client selon un standard sur lequel nous pouvons nous engager en production.
À mi-2025, nous avions environ 15 FDE travaillant avec un grand client dans le secteur des semi-conducteurs sur plus de 10 cas d'usage. L'ambition était de rendre leur processus de vérification natif de l'IA, couvrant :
Génération de tests dirigés
Analyse des causes racines et débogage
Un assistant d'architecture
La vérification peut représenter environ 70% de l'effort d'un projet dans cette industrie. L'opportunité était énorme, et il y avait de nombreux points de départ possibles.
Certains FDE avaient rejoint OpenAI quelques jours plus tôt seulement et n'avaient jamais travaillé dans les semi-conducteurs. Ils se sont intégrés à l'équipe de vérification du client, ont étudié la conception de puces pendant leur temps libre et ont construit des évaluations avec les ingénieurs pour tester si l'IA pouvait générer des tests utiles et diagnostiquer correctement les défaillances de puces.
Parallèlement à cet apprentissage, nous avons construit des harnais personnalisés pour les cas d'usage individuels. Au cours des 3-6 premiers mois, tous ont atteint la production et une adoption précoce par les utilisateurs. La récompense a été de voir les métriques :
~48 % de temps économisé grâce à la génération de tests dirigés par IA.
22 % d'amélioration médiane des performances grâce à l'optimisation de noyaux.
Des semaines de débogage compressées en heures
Quand nous avons présenté tout cela, le Directeur du Matériel a demandé : « Vous avez travaillé comme concepteurs de puces avant de venir ici ? »
Nos FDE n’ont pas besoin de connaître le secteur dès le premier jour, mais il est de leur responsabilité de l’apprendre.
Alors que les assistants de code rendent la création de logiciels plus rapide, comprendre l’activité du client devient encore plus important. Nous constituons des équipes mêlant généralistes et experts du domaine.
Vous avez besoin d’assez de connaissances pour porter des jugements solides, et d’assez de curiosité pour remettre en question les hypothèses sur le statu quo.
Dans les sciences de la vie, par exemple, la formation scientifique de nos FDE les aide à gagner la confiance des chercheurs travaillant sur des tâches de découverte de médicaments précliniques telles que la validation et la priorisation de cibles, l’analyse de l’expression génique et la reconstruction de voies de synthèse chimique. Cette expertise leur permet d’apporter un jugement éclairé sur la manière d’améliorer ces flux de travail.
Rendre le succès reproductible
Nous avions démontré que ces flux de travail pouvaient apporter de la valeur, mais chacun nécessitait encore trop d’intégrations personnalisées pour être étendu à une autre équipe. Le défi suivant était de préserver ces résultats tout en rendant le logiciel plus facile à déployer et à maintenir.
Entre-temps, Codex avait gagné en capabilities. Un FDE a testé la reconstruction de son application autour de celui-ci, puis a travaillé avec l’équipe pour migrer les cas d’usage vers un harnais commun avec Codex en son cœur.
Les applications personnalisées sont devenues des plugins et des skills construits sur des primitives Codex communes. Codex est également devenu l’interface, nous permettant de retirer les interfaces en terminal et les CLI distinctes que nous avions écrites pour des cas d’usage individuels.
Nous avons pu supprimer environ 90% du code personnalisé de chaque projet, et cela a changé la façon dont nous construisions, maintenions et faisions évoluer ces flux de travail :
Nous pouvions bénéficier des améliorations centralisées de Codex, réduisant la quantité de code de liaison nécessaire pour chaque cas d’usage individuel
Les fonctionnalités clés étaient regroupées sous forme de skills et de plugins, ce qui les rendait plus faciles à partager entre nous et à contrôler de manière centralisée par l’AI CoE. Cela signifiait que l’extension d’une équipe à la suivante pouvait être aussi simple que d’échanger de nouveaux connecteurs/serveurs MCP, de construire de nouveaux evals (pour lesquels nous avions aussi un skill) et de se lancer rapidement.
Dans un exemple d’août 2026, le déploiement initial a pris deux mois. Étendre la solution à une deuxième équipe a pris un jour. Les équipes suivantes ont été intégrées plus rapidement à mesure que nous développions—cela s’est poursuivi, avec un cas d’usage en août 2026 prenant 1 jour pour la deuxième équipe après un déploiement initial de 2 mois.
C’est une façon de nous rendre obsolètes. Le travail accompli pour atteindre la production a établi ce qui comptait. À mesure que le produit sous-jacent s’améliorait, nous pouvions remplacer une grande partie de notre implémentation personnalisée tout en conservant la valeur qu’elle apportait.
C’est pourquoi l’ordre compte. Les LLM nous permettent de construire rapidement. Utilisez cette vitesse pour mettre quelque chose de précieux entre les mains des utilisateurs, apprenez ce qui tient en pratique, puis faites évoluer ce qui fonctionne.
Le même principe s’applique à tous les engagements.
OpenAI Presence, notre produit pour les agents vocaux et de chat d’entreprise, est né de déploiements clients réels. Le travail a commencé avec Swarm(s’ouvre dans une nouvelle fenêtre) et a évolué à travers l’ Agents API, et aujourd’hui un client traite désormais plus de la moitié de ses appels avec l’IA.
Mener ces déploiements jusqu’en production nous a appris quels problèmes nécessitaient une solution personnalisée et quels composants d’autres équipes pouvaient utiliser. Nous avons intégré ces composants dans Presence, facilitant l’automatisation des flux de travail réglementés par les développeurs sans reconstruire l’infrastructure sous-jacente. Chaque déploiement a contribué à façonner le produit et a offert au client suivant un meilleur point de départ.
Avec Thrive Holdings, les FDE et chercheurs d’OpenAI ont travaillé aux côtés d’ingénieurs et de comptables pour construire Tax AI pour les cabinets comptables de Crete. Pendant son pilote, Tax AI a traité 7,000 déclarations fiscales et augmenté le débit d’environ 50%.
L’un des défis les plus difficiles était l’automatisation des déclarations de biens locatifs, qui a nécessité six semaines d’ingénierie et de révision par des praticiens pour atteindre 90% de précision et de rappel. Ce travail a créé des modèles réutilisables qui ont facilité l’extension de Tax AI à d’autres annexes fiscales complexes.
Les équipes appliquent désormais la même approche à la comptabilité, à l’audit et au support informatique—construisant des systèmes qui s’améliorent grâce aux retours des praticiens et à l’usage réel.
Combler les lacunes d’intelligence au fur et à mesure qu’elles apparaissent
Parfois, un meilleur produit nous permet de simplifier ce que nous avons construit, mais parfois le modèle lui-même ne peut pas encore faire le travail.
Si nous ne construisons que ce que les modèles actuels rendent déjà possible, nous ne découvrirons pas les lacunes d'intelligence que Research doit combler ensuite. C'est pourquoi un grand nombre de nos engagements importants commencent à ces limites, avec le client, FDE et Research déterminés à les surmonter ensemble.
Nous avions déjà développé une plateforme de service client avec un grand opérateur de télécommunications, et celui-ci souhaitait l'étendre à la voix.
La voix représentait environ 90 % de leur volume de service client. Ces cas étaient plus coûteux à traiter que le chat, et présentaient toute une série de nouveaux défis techniques pour porter la reconnaissance des accents, du ton et la latence/précision à un niveau de qualité production. Bien faire les choses aurait fait une différence substantielle pour leur activité.
Pendant la phase de cadrage, notre modèle a obtenu un score d'environ 60 % sur les évaluations clés que nous utilisions pour déterminer s'il pouvait faire le travail en production. Nous avions atteint les limites de ses capacités. L'appel de fonctions et le suivi d'instructions dans des scénarios de service client devaient être améliorés.
Nous l'avons expliqué au client et avons intégré l'équipe Research au travail. FDE a travaillé avec le client pour construire la plateforme et définir ce que le modèle devait faire. Research s'est concentré sur la réduction des écarts de capacité, les instantanés successifs du modèle nous permettant de tester les progrès par rapport aux exigences du client.
Sur six mois, les performances sur les évaluations clés sont passées d'environ 60 % à 80 %, puis à plus de 90 %, atteignant les niveaux nécessaires pour la production.
Le modèle vocal qui en résulte prend désormais en charge le déploiement de ce client, d'autres déploiements personnalisés de service client et des déploiements gérés via Presence. Un problème rencontré dans l'activité d'un client a permis d'identifier des améliorations susceptibles de servir de nombreux autres.
Chaque partie a compté. Le client s'est engagé à travailler sur un problème que le modèle ne pouvait pas encore résoudre. FDE est resté suffisamment proche pour formuler ce problème, construire la plateforme et piloter la mission du début à la fin. Research a amélioré les capacités du modèle sous-jacent.
C'est l'autre version du fait de nous rendre obsolètes : aider à transformer un problème que les modèles d'aujourd'hui ne peuvent pas résoudre en une capacité que les modèles futurs pourront offrir. Le retour sur notre travail dépasse les heures que nous passons avec un client donné.
Allez chercher le problème plus difficile
J'ai rejoint OpenAI pour contribuer à rendre l'IA utile dans le travail quotidien des gens. Cela guide toujours l'équipe. Je dis souvent à l'équipe que dans la plupart des cas en développement de LLM, le rasoir d'Ockham s'applique : la solution la plus simple est la meilleure. Dans une entreprise définie par sa recherche de pointe et dans un secteur entaché d'exagérations, nous voulons construire des choses qui fonctionnent de manière fiable et sur lesquelles les personnes sur le terrain peuvent compter.
L'objectif est que chaque mission améliore ce qui vient ensuite : un produit plus facile à déployer, un modèle capable de gérer une tâche plus difficile, ou moins de travail personnalisé pour le client suivant.
Si vous avez un problème difficile que vous souhaitez résoudre, nous serions ravis de travailler avec vous. Si vous voulez contribuer à résoudre ces problèmes, nous serions ravis que vous nous rejoigniez.
Alors, que faisons-nous quand Codex peut gérer le travail que nous avons passé des mois à construire ?
Allez chercher le problème plus difficile.