Le 29 janvier 2026, OpenAI a publié un billet qui sort un peu de son registre habituel : pas un nouveau modèle, mais le retour d’expérience sur l’agent IA qu’elle utilise en interne pour interroger ses propres données. L’idée tient en une phrase : un agent conversationnel sur lequel n’importe quel employé pose une question business en langage naturel et récupère une analyse fiable en quelques minutes, sans passer par l’équipe data.
Ce que change l’agent data d’OpenAI
Le chiffre qui frappe d’abord, c’est l’échelle. L’agent est construit sur GPT-5.2 et sert plus de 3 500 employés, qui l’utilisent pour raisonner sur 600 pétaoctets de données réparties sur 70 000 datasets. On n’est pas sur un POC de démo : c’est un outil de production branché sur l’entrepôt de données réel de la boîte.
Le point intéressant, ce n’est pas la techno, c’est qui s’en sert. D’après OpenAI, les équipes Engineering, Product, Data Science, Go-To-Market, Finance et Research s’appuient toutes sur l’agent pour répondre à des questions à fort enjeu. Concrètement, ça abaisse la barrière d’entrée à la donnée : un commercial ou un financier peut sortir une analyse nuancée sans devoir écrire du SQL ni faire la queue auprès des data analysts. Le genre de questions posées va jusqu’à des comparaisons de revenus calées sur des événements produit précis, type évolution des utilisateurs quotidiens d’une fonctionnalité produit autour d’un événement précis.
Comment ça marche sous le capot
Trois briques font la différence, et aucune n’est juste « on a pris un gros modèle ».
- Le contexte enrichi par le code. OpenAI utilise Codex pour crawler sa propre codebase et en extraire les définitions de tables, la granularité, les clés primaires et les signaux de fraîcheur directement depuis le code des pipelines. Autrement dit, l’agent ne se contente pas du schéma et des métadonnées : il comprend comment chaque table est réellement construite, donc ce qu’elle contient vraiment.
- Une mémoire qui apprend en continu. Le système capture les cas limites via les corrections. OpenAI cite un exemple parlant : l’agent ne savait pas filtrer une expérience analytique particulière, parce qu’il fallait matcher une chaîne de caractères précise définie dans une « experiment gate ». La mémoire a été décisive pour retenir ce cas une bonne fois pour toutes.
- Le raisonnement plutôt que les instructions rigides. Plutôt que de scripter chaque étape, l’équipe est passée à des consignes de plus haut niveau et laisse le raisonnement de GPT-5 choisir le bon chemin d’exécution. Résultat annoncé : un agent plus robuste et de meilleurs résultats.
Côté garde-fous, OpenAI s’appuie sur son Evals API et des jeux de questions-réponses curés, chaque question étant associée à une requête SQL « golden » écrite manuellement qui produit le résultat attendu. La sortie de l’agent est exécutée puis comparée à ce résultat de référence, et c’est ce dispositif d’évaluation continue qui sert de garde-fou avant déploiement. C’est un détail qui en dit long sur le sérieux requis quand l’agent touche à des chiffres financiers : tu ne mets pas en prod un agent qui hallucine un revenu.
Ce que tu peux en retenir
Si tu bosses sur un agent data, ou plus largement sur un système IA qui doit raisonner sur les données d’une organisation, le vrai enseignement de ce billet n’est pas « prenez GPT-5 ». C’est que la performance vient des couches de contexte que tu empiles autour du modèle : analyse du code, annotations humaines, connaissance institutionnelle capturée en mémoire. Le modèle est commoditisé, le contexte ne l’est pas.
La partie Codex est sans doute la plus transposable. Beaucoup d’équipes documentent leurs tables à la main, et cette doc dérive de la réalité dès la première migration. Aller chercher la vérité dans le code des pipelines plutôt que dans un wiki à moitié à jour, c’est une approche que tu peux appliquer même sans les moyens d’OpenAI. Le détail complet est dans le billet original d’OpenAI.
Mon avis : c’est un des rares retours d’expérience « agentic » récents qui ne survend pas l’autonomie. OpenAI assume que son agent a eu besoin de mémoire pour retenir une chaîne de caractères précise, et que l’évaluation continue contre des requêtes SQL de référence est un prérequis avant déploiement. Les boîtes qui réussiront leurs agents internes ne seront pas celles qui ont le meilleur modèle, mais celles qui ont fait le travail ingrat de rendre leur contexte exploitable. Pour la plupart des équipes, le chantier prioritaire n’est pas le prompt, c’est la qualité et l’accessibilité de la donnée en amont.
