Quand Codex est sorti, quelqu'un de l'équipe m'a demandé : « Que ferons-nous quand Codex pourra résoudre du premier coup les cas d'usage sur lesquels nous avons passé 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 un progrès. Si nous nous rendons obsolètes tous les deux ou trois mois, notre équipe FDE fait 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 processus nécessaires pour les mettre en œuvre. Parfois, la pièce manquante est un produit. Parfois, un modèle performe bien sur un benchmark mais ne peut pas faire le travail avec des variables et des contraintes du monde réel.
Nous nous concentrons sur les problèmes les plus difficiles des clients. Lorsque 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 ; lorsqu'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 engagement 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 pour John Deere, une entreprise agricole vieille de 200 ans, était de savoir comment passer à l'é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 savent comment 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 soutien personnalisé et évolutif.
L'IA peut répondre aux questions des agriculteurs en langage naturel, fournir des conseils de configuration et des recommandations sur mesure, identifier quand un équipement ne délivre peut-être pas tout son potentiel, et aider les agriculteurs à comprendre la valeur qu'ils tirent de la technologie.
L'opportunité va au-delà d'une simple interaction : 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 genre 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 et complexes.
Mais les problèmes sont souvent totalement ouverts, il peut ne pas exister de 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 nombreux sont ceux qui veulent faire ce qu'il faut pour y parvenir.
Trouver des FDE talentueux tout en élevant le niveau de référence du « suffisant » 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.
À la mi-2025, nous avions environ 15 FDE travaillant avec un grand client dans les 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 ce secteur. L'opportunité était énorme, et il existait de nombreux points de départ possibles.
Certains FDE avaient rejoint OpenAI quelques jours plus tôt 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 des 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. Le résultat s'est concrétisé par les indicateurs suivants :
~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 des noyaux.
Des semaines de débogage comprimées en quelques heures
Quand nous avons réécouté tout cela, le Chief Hardware Officer a demandé : « Est-ce que vous travailliez 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.
À mesure que les assistants de code rendent le développement logiciel plus rapide, comprendre l’activité du client devient encore plus important. Nous constituons des équipes mêlant généralistes et experts du domaine.
Il faut suffisamment de connaissances pour porter des jugements solides, et assez de curiosité pour remettre en question les hypothèses sur le statu quo.
Dans les sciences du vivant, par exemple, les formations scientifiques de nos FDE les aident à gagner la confiance des chercheurs travaillant sur des tâches de découverte de médicaments préclinique telles que la validation et la priorisation de cibles, l’analyse de l’expression des gènes 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 répétable
Nous avions démontré que ces flux de travail pouvaient créer de la valeur, mais chacun nécessitait encore trop d’intégration personnalisée 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 capacités. Un FDE a testé la reconstruction de son application autour de Codex, 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 compétences construits sur des primitives Codex communes. Codex est également devenu l’interface, nous permettant de retirer les interfaces 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é notre façon de construire, maintenir et faire évoluer ces flux de travail :
Nous pouvions bénéficier des améliorations centralisées de Codex, réduisant la quantité de code de colle nécessaire pour chaque cas d’usage individuel
Les fonctionnalités clés étaient regroupées en compétences et plugins, ce qui les rendait plus faciles à partager entre nous et à contrôler de manière centrale par l’AI CoE. Cela signifiait que passer d’une équipe à la suivante pouvait être aussi simple que d’échanger de nouveaux connecteurs/serveurs MCP, de construire de nouvelles évaluations (pour lesquelles nous avions aussi une compétence) et de se lancer.
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 montions en échelle — cela s’est poursuivi, avec un cas d’usage en août 2026 prenant 1 jour pour la deuxième équipe après que le déploiement initial a pris 2 mois.
C’est une version de ce que signifie 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, apprendre ce qui tient en pratique, puis faire évoluer ce qui fonctionne.
Le même principe s’applique à tous les engagements.
OpenAI Presence, notre produit pour agents vocaux et de chat en entreprise, est né de déploiements clients réels. Le travail a commencé avec Swarm(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 éléments de base d’autres équipes pouvaient réutiliser. Nous avons intégré ces éléments de base dans Presence, facilitant l’automatisation de 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 revue 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 — en construisant des systèmes qui s’améliorent grâce aux retours des praticiens et à l’usage réel.
Combler les lacunes d’intelligence dès 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 d'aujourd'hui rendent déjà possible, nous ne découvrirons pas les lacunes d'intelligence que Research doit combler ensuite. C'est pourquoi beaucoup de nos engagements importants commencent à ces limites, avec le client, les FDE et Research engagés à les surmonter ensemble.
Nous avions déjà développé une plateforme de service client avec un grand client dans le secteur des 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 ont apporté toute une série de nouveaux défis techniques pour porter les accents, le ton et la latence/précision à un niveau de qualité production. Y parvenir ferait une différence substantielle pour leur activité.
Lors du cadrage, notre modèle a obtenu environ 60 % sur les évaluations clés que nous utilisions pour déterminer s'il pouvait accomplir la tâche en production. Nous avions atteint les limites de ses capacités. L'appel de fonctions et le suivi des instructions dans des scénarios de service client devaient être améliorés.
Nous l'avons expliqué au client et avons fait participer Research au projet. FDE a travaillé avec le client pour construire la plateforme et définir ce que le modèle devait faire. Research a travaillé à combler les écarts de capacités, les instantanés successifs du modèle nous permettant de tester les progrès par rapport aux exigences du client.
En 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 les 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 beaucoup d'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 cadrer ce problème, construire la plateforme et piloter le projet 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 de demain pourront fournir. Le retour sur notre travail va au-delà des 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 une industrie ternie par l'hyperbole, 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 projet 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 voulez résoudre, nous serions ravis de travailler avec vous. Si vous voulez aider à 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.