OpenAI détaille le travail de ses FDE : 90% du code sur mesure a disparu au profit des skills Codex

OpenAI a publié un retour détaillé sur le fonctionnement de ses forward deployed engineers (FDE). L'équipe a été constituée début 2025 pour répondre à un problème précis : sur le papier, le modèle sait faire beaucoup de choses, mais les utilisateurs ne peuvent pas encore s'appuyer sur lui dans leur flux de travail. C'est ce qu'OpenAI appelle le « deployment gap ». Bilan de quatre projets : de 3–6 mois pour atteindre la production dans les semi-conducteurs, +50% de débit chez des comptables fiscalistes, un modèle vocal passé de 60% à 90%+ sur les evals clés, et environ 90% du code sur mesure jeté après la sortie de Codex.

La devise de l'équipe : commencer par le résultat, tout faire pour y arriver, passer à l'échelle ensuite. Igor Akimov, auteur de la chaîne AI Product, observe que les éditeurs vantent en chœur des modèles ultra-intelligents, alors que les déploiements par verticale manquent. Selon lui, les tokens sont aujourd'hui surtout brûlés par des startups aux frais d'autrui. Les FDE interviennent précisément là où cet écart doit être comblé à la main.

Puces, fiscalité et télécoms : quatre cas chiffrés

• Ingénierie des semi-conducteurs, mi-2025. Environ 15 FDE ont travaillé sur 10+ cas d'usage : génération de tests, recherche des causes de pannes, assistant d'architecture. Dans ce secteur, la vérification absorbe environ 70% de l'effort d'un projet. Une partie des ingénieurs avait rejoint OpenAI quelques jours avant le lancement et ne connaissait rien aux puces. Ils se sont assis aux côtés des ingénieurs du client, ont étudié le domaine et construit les métriques avec eux. En 3–6 mois, tous les cas d'usage sont arrivés en production. Résultat : environ 48% de temps gagné sur la génération de tests, un gain de performance médian de 22% sur l'optimisation des kernels, et des semaines de débogage ramenées à quelques heures.
• Migration vers Codex. Quand Codex a gagné en maturité, tous les cas d'usage ont été portés sur un socle commun centré sur lui. Les applications sur mesure sont devenues des plugins et des skills, et les CLI et interfaces maison ont été abandonnées. Dans chaque projet, environ 90% du code sur mesure a disparu. Dans l'un des cas, le premier déploiement a pris 2 mois, l'extension à une deuxième équipe 1 jour.
• IA fiscale pour les cabinets comptables de Thrive Holdings. Le pilote a traité 7 000 déclarations, avec un débit en hausse d'environ 50%. Les plus difficiles ont été les déclarations liées aux transactions immobilières : 6 semaines d'ingénierie et de vérifications par des praticiens pour atteindre 90% de precision et de recall.
• Voix pour le télécom. La voix représente environ 90% des demandes au support. Le modèle affichait environ 60% sur les evals clés, ce qui ne suffit pas pour la production. L'équipe Research a été mobilisée : en 6 mois, le résultat est monté à 80%, puis à 90%+. Ce modèle vocal sert désormais aussi d'autres clients.

Le code sur mesure a une durée de vie de six mois

Sur le plan technique, l'histoire de Codex est la partie la plus intéressante. Les projets reposaient sur des applications, des CLI et des interfaces maison : chaque client avait son propre outillage. Dès que la plateforme a su prendre en charge l'orchestration, tout cela s'est transformé en plugins et en skills. L'écart entre 2 mois pour le premier déploiement et 1 jour pour l'extension montre où s'accumule la valeur. Moins un projet contient de code unique, moins chaque client ou équipe supplémentaire coûte cher.

Il y a aussi un virage d'architecture. Selon Akimov, OpenAI est passée d'un schéma multi-agents à un agent unique doté de skills. C'est exactement ce que recommandait Anthropic. Les deux plus grands laboratoires convergent vers le même pattern : un agent plus un ensemble de compétences branchables.

Pour l'économie des tokens, la conclusion est directe. Tant que la couche de logique maison grossit autour du modèle, les coûts de maintenance augmentent, tout comme le risque que la plateforme propose la même chose en natif d'ici six mois. L'équipe en a fait un principe de travail : le critère de réussite d'un FDE est de se rendre inutile tous les deux mois environ. Quand Codex a su assembler d'un coup ce que les ingénieurs construisaient en plusieurs mois, la question « que faire ? » a trouvé une réponse simple : chercher une tâche plus difficile.

Ce que l'intégrateur doit retenir

Il existe trois actifs durables : la connaissance du domaine, les datasets et métriques construits avec les experts du client, et la compréhension des limites du modèle. Le cas fiscal le confirme : les 90% de precision et de recall sur l'immobilier ne viennent pas de fonctionnalités, mais de six semaines de vérifications par des praticiens. Le cas vocal le montre sous un autre angle : passer de 60% à 90%+ a exigé de faire appel à Research. Pour un product manager comme pour un intégrateur, cela se traduit par des mesures concrètes :

• commencer par les evals et des métriques validées avec les experts du client, et non par l'interface ;
• bâtir la solution sur des primitives de plateforme (skills, plugins), et non sur des CLI maison ;
• s'en tenir à un seul agent doté de skills, tant que le multi-agents n'a pas prouvé son utilité sur les métriques ;
• prévoir que l'outillage devra être réécrit tous les quelques mois.

Aux développeurs qui craignent que Codex leur prenne leur travail, ce retour d'expérience répond que la valeur se déplace vers la formulation des tâches et la mesure de la qualité. C'est précisément ce que faisaient des gens qui, une semaine avant le début du projet sur les puces, ne savaient rien des puces.