Databricks et GPT-5.5 font de la localisation des agents une question de gravité des données

Databricks a intégré GPT-5.5 directement dans les workflows d'agents d'entreprise, et GPT-5.5 occupe désormais la première place sur le benchmark OfficeQA Pro. Pour la plupart des CTOs, ce titre ressemble à une mise à jour de modèle. Ce n'en est pas une — c'est une contrainte structurelle sur l'endroit où tes agents vivent par rapport à tes données, et la fenêtre pour trancher sans trop dépenser se referme.

Ce qui a changé

OpenAI et Databricks ont annoncé que GPT-5.5 est désormais disponible nativement dans les workflows d'agents d'entreprise de Databricks. L'intégration permet aux équipes déjà sur le lakehouse Databricks de pointer GPT-5.5 vers leurs catalogues existants, leurs règles de gouvernance et leur capacité de calcul — sans exporter les données vers une plateforme d'agents séparée. GPT-5.5 a atteint la première position sur le benchmark OfficeQA Pro, un test conçu pour approcher le travail de raisonnement multi-étapes et orienté documents qui caractérise les agents back-office d'entreprise : révision de contrats, analyse financière, recherches multi-systèmes.

Le résultat concret : un client Databricks peut désormais faire tourner un modèle de niveau raisonnement à l'intérieur du même périmètre de sécurité que ses tables Delta et ses politiques Unity Catalog. Auparavant, connecter un modèle frontier capable aux données d'entreprise impliquait soit d'accepter l'egress de données vers une API externe, soit de construire un middleware conséquent pour appliquer la gouvernance à la frontière. Ce coût de middleware — en temps ingénierie, en latence et en surface d'audit — était souvent l'argument caché contre l'adoption des agents d'entreprise.

Ce n'est pas une préversion de recherche. Databricks dispose d'une large base installée parmi les entreprises de 200 à 2 000 ETP, et ces entreprises ont généralement déjà des données structurées et semi-structurées dans la plateforme. Les performances de GPT-5.5 sur le benchmark signifient que le modèle est suffisamment capable pour gérer la complexité de raisonnement que ces cas d'usage requièrent réellement — pas simplement de la récupération basique.

Pourquoi cela recadre la décision build-vs-buy pour ton stack

Le débat classique sur l'architecture d'agents d'entreprise a trois positions : construire un stack d'agents custom sur des API brutes, acheter un outil SaaS vertical spécialisé, ou utiliser un framework d'orchestration généraliste comme LangChain ou CrewAI devant ta propre infrastructure. Chacune de ces options suppose que la couche agent est séparée de la couche données, reliée par des pipelines de récupération que tu possèdes et maintiens.

L'intégration Databricks/GPT-5.5 brise cette hypothèse. Si tes données vivent déjà dans Databricks, faire tourner les agents nativement dans cet environnement élimine un pipeline de récupération, une couche d'application de gouvernance et une facture de calcul séparée. L'avantage architectural ne tient pas à la qualité du modèle seule — c'est que le modèle tourne là où sont les données, ce qui supprime la latence et la charge de conformité qui font échouer les projets d'agents d'entreprise en production. La gravité des données — le principe selon lequel le calcul se déplace vers les données, et non l'inverse — s'applique désormais directement à l'orchestration des agents.

Le risque est symétrique. Si tu as construit, ou es en train de construire, un stack d'agents hors de Databricks alors que ton entrepôt de données se trouve à l'intérieur, tu fais face à une comparaison plus difficile. Le stack autonome doit être significativement meilleur sur ton cas d'usage spécifique, ou moins cher à l'échelle, ou plus flexible de manières que tu peux nommer concrètement. "Nous possédons l'architecture" n'est pas une justification suffisante si le coût de cette propriété inclut une charge ETL continue et un écart de gouvernance. Les CTOs qui ont fait ce choix il y a 18 mois, avant qu'un modèle de cette capacité de raisonnement soit disponible nativement dans la plateforme, devraient refaire les calculs.

Il existe des raisons légitimes de rester hors plateforme : des exigences de neutralité multi-cloud, des cas d'usage qui s'étendent sur plusieurs entrepôts de données non consolidés dans Databricks, ou une complexité d'agents qui requiert des primitives d'orchestration que Databricks n'expose pas encore. Mais ces raisons doivent être explicites dans tes documents d'architecture, pas implicites.

Ce qu'il faut faire dès lundi matin

L'arbre de décision ici comporte cinq entrées. Travaille-les avant ta prochaine revue d'infrastructure.

• Localisation des données : Quel pourcentage des données dont tes agents ont besoin est déjà dans Databricks ? Si c'est au-dessus de 70 %, le chemin natif mérite une évaluation formelle, pas un rejet désinvolte.
• Dépenses Databricks existantes : Paies-tu déjà pour un niveau Databricks qui inclut les outils d'agents ? Si oui, le coût marginal du chemin natif peut être inférieur aux coûts combinés d'API et d'infrastructure de ton stack autonome actuel.
• Posture de gouvernance : Ton équipe sécurité ou conformité exige-t-elle que l'inférence du modèle reste dans un périmètre de données spécifique ? Le natif-en-plateforme est souvent le chemin le plus court pour satisfaire cette exigence.
• Complexité des agents : Tes agents effectuent-ils un raisonnement multi-étapes sur des données d'entreprise structurées, ou de la simple génération augmentée par récupération sur des documents ? Les performances de GPT-5.5 sur OfficeQA Pro sont les plus pertinentes pour le premier cas.
• Propriété de l'équipe : Qui possède actuellement ton stack d'agents ? Si c'est une petite équipe data engineering qui fait déjà tourner Databricks, la consolidation réduit leur surface opérationnelle. Si c'est une équipe produit qui construit une logique différenciée, elle peut avoir besoin de la flexibilité d'une couche d'orchestration autonome.

Si tes réponses pointent vers la consolidation, lance une preuve de concept de 2 semaines sur un cas d'usage d'agent existant — choisis quelque chose en production avec des bases de latence et de coût mesurables. Tu as besoin de vrais chiffres, pas d'extrapolations de benchmarks, avant de t'engager dans une migration.

Ce que ça coûte et ce que ça économise

Le coût du chemin natif, c'est la dépendance à la plateforme. Databricks n'est pas une couche d'infrastructure neutre ; la plateforme a un pouvoir de fixation des prix, et consolider ton calcul d'agents là-bas augmente ton exposition aux futures évolutions tarifaires. Tu acceptes aussi les primitives d'orchestration de la plateforme, qui peuvent être en retard sur les frameworks open source sur des fonctionnalités comme la coordination multi-agents complexe. Pour les équipes qui ont construit des outils internes conséquents sur LangGraph ou similaire, le coût de migration représente du vrai temps ingénierie — probablement 4 à 8 semaines pour une surface d'agents non triviale.

Le compromis en faveur des économies est moins abstrait. Supprimer un pipeline de récupération entre ta couche agent et ta couche données réduit typiquement la latence p95 de façon mesurable sur les requêtes intensives en données. Appliquer la gouvernance au niveau de la couche données plutôt qu'à la frontière API réduit la surface d'audit que ton équipe sécurité doit maintenir. Et si tu fais actuellement tourner un vector store séparé et un pipeline d'embedding pour la récupération d'entreprise, l'approche lakehouse native peut faire s'effondrer toute cette infrastructure. Pour une entreprise avec 3 ou 4 workflows d'agents actifs et un périmètre Databricks modeste, les économies annuelles d'infrastructure peuvent justifier le coût de migration en un seul trimestre — mais ce calcul dépend entièrement du coût réel de ton stack actuel, que la plupart des équipes n'ont pas entièrement comptabilisé.