Google a repensé son architecture de données pour que l'IA cesse d'échouer dans les entreprises
Pendant des années, les équipes de données et les équipes d'IA au sein des grandes entreprises ont fonctionné comme des départements appartenant à des pays différents. Les premières construisaient des entrepôts, des catalogues et des pipelines. Les secondes déployaient des modèles, des API et des agents. Ces deux mondes communiquaient à travers des exports manuels, des processus discontinus et une foi aveugle dans le fait que « l'autre équipe s'en occupait ». Le résultat était prévisible : les agents d'IA arrivaient en environnement de production et s'effondraient face à des données que personne n'avait préparées pour qu'une machine autonome puisse les lire, les interpréter et agir en conséquence.
Lors de Google Cloud Next 2026, Google a nommé cet effondrement avec précision : la séparation entre la plateforme de données et la plateforme d'IA constitue le principal frein au déploiement d'agents autonomes en entreprise. Sa réponse a pris la forme du Cloud de Données Agentique, une reconfiguration profonde de son architecture de données qui n'ajoute pas une couche d'IA par-dessus l'existant, mais qui redessine les fondations afin que les agents soient des utilisateurs de première classe de la donnée d'entreprise.
La différence d'ambition n'est pas anodine. Il ne s'agit pas de nouveaux connecteurs ni de tableaux de bord enrichis en langage naturel. Il s'agit d'une refonte structurelle qui oblige à repenser la façon dont toute entreprise du Fortune 500 — avec des données réparties entre AWS, Azure et Google Cloud — va gouverner, servir et monétiser les informations qu'elle possède déjà.
Le diagnostic que les dirigeants préfèrent ignorer
Il existe un chiffre qui dérange : selon les recherches accompagnant ce lancement, environ 70 % des entreprises découvrent les défaillances de leur infrastructure de données après avoir déployé les agents, et non avant. Ce n'est pas un problème technique. C'est un problème de leadership déguisé en problème technique.
Les données fragmentées, sans gouvernance, enfermées dans des silos appartenant à différents clouds, ne sont pas apparues du jour au lendemain. Elles se sont accumulées au fil d'années de décisions précipitées, d'acquisitions d'entreprises mal intégrées et d'une tendance organisationnelle très humaine : reporter la conversation difficile sur l'architecture réelle de la donnée parce que « les affaires continuent de tourner ». Jusqu'au jour où elles cessent de tourner.
L'architecture que Google a présentée est composée de six composants qui ne sont pas indépendants les uns des autres, mais qui forment un système à logique séquentielle. À la base, le Data Lakehouse Multinuage, construit sur le format ouvert Apache Iceberg, permet à BigQuery d'interroger des données hébergées sur AWS S3 et Azure ADLS sans avoir besoin de les déplacer ni de les répliquer, éliminant ainsi les coûts de sortie et le risque d'incohérence entre les copies. Sur cette base opère le Moteur Lightning pour Apache Spark, une couche d'exécution vectorisée en C++ qui délivre jusqu'à 4,9 fois les performances de Spark conventionnel. La donnée n'est pas seulement accessible ; elle est traitable à une vitesse qui rend viable le fait qu'un agent génère, exécute et corrige du code Spark dans des cycles continus sans que les coûts s'envolent.
Au-dessus de cette infrastructure d'exécution vient la couche d'intelligence contextuelle : le Catalogue de Connaissances, l'évolution du Dataplex Universal Catalog présenté le 10 avril 2026. C'est la pièce qui devrait le plus retenir l'attention des architectes d'entreprise. Le catalogue ne requiert pas que les équipes de données cataloguent manuellement les actifs. Il examine les journaux de requêtes, profile les tables, analyse les modèles sémantiques d'outils comme Looker et extrait les relations entre entités à partir de fichiers non structurés. Le résultat est un graphe de connaissance dynamique, maintenu automatiquement, qui répond à la question que tout agent doit résoudre avant d'agir : quelles données existent, que signifient-elles avec précision et sont-elles fiables.
Quand le stockage cesse d'être passif
La pièce qui modifie le plus radicalement la géométrie opérationnelle de la donnée est le Stockage Intelligent, actuellement en préversion. Jusqu'à présent, un fichier arrivant dans un bucket Google Cloud Storage était inerte jusqu'à ce que quelqu'un décide de le traiter. Avec cette fonctionnalité, au moment même où un fichier arrive dans le bucket, le système l'étiquette automatiquement, génère des embeddings, extrait les entités pertinentes et le relie au Catalogue de Connaissances. PDFs, contrats, tickets de support, enregistrements audio : tout devient un actif consultable sans qu'aucun ingénieur n'intervienne.
Pour les dirigeants qui ont repoussé des projets de préparation de données non structurées — ceux qui « prendront six mois » d'extraction, d'OCR, d'indexation et de catalogage — ceci reconfigure l'équation temps-coût d'une manière qui ne permet plus de report confortable. Ce qui était auparavant un projet avec un sponsor exécutif, un budget propre et une date de livraison incertaine devient une conséquence automatique de la politique de stockage.
L'Agent de Recherche Approfondie, basé sur Gemini 3.1 Pro, illustre le cas d'usage terminal de toute cette infrastructure. Il opère en combinant des sources internes provenant du Catalogue de Connaissances et du Lakehouse avec des sources ouvertes sur internet, génère des plans de recherche structurés et délivre des rapports avec des citations vérifiables en quelques minutes. Des tâches qui, dans des domaines tels que l'intelligence concurrentielle, les sciences de la vie ou les services financiers, mobilisaient entre une et trois semaines de travail analytique deviennent le point de départ, et non le point d'arrivée.
Le Kit d'Agents de Données complète le tableau du côté des développeurs. Il offre des outils MCP préconfigurés et trois agents spécialisés : l'un qui convertit des instructions en langage naturel en pipelines gérés en choisissant entre BigQuery, dbt, Spark ou Airflow ; un autre qui automatise le cycle complet des modèles de science des données ; et un troisième dédié à l'observabilité de l'infrastructure. Le Protocole de Contexte de Modèle agit comme une couche d'interopérabilité permettant aux agents de n'importe quel fournisseur — Gemini, Claude, modèles propriétaires — d'accéder aux actifs de données sans connecteurs sur mesure.
Le multinuage cesse d'être une plainte et devient une décision d'architecture
Aucune entreprise du Fortune 500 n'opère exclusivement sur Google Cloud. Les systèmes SAP, Salesforce, Workday et Oracle sont répartis entre AWS et Azure pour des raisons historiques, contractuelles et opérationnelles qu'aucun mandat de DSI ne peut résoudre par un mémorandum. Pendant des années, le multinuage a constitué l'argument récurrent pour ne pas avancer sur aucune initiative d'IA à grande échelle : « nous devons d'abord consolider la donnée ».
Le Data Lakehouse Multinuage démonte cet argument avec une précision technique. En utilisant le Catalogue REST d'Iceberg, l'Interconnexion Multinuage et une couche de cache intelligent, BigQuery peut interroger des données sur AWS S3 et Azure ADLS avec une latence et un coût comparables à ceux des données natives sur Google Cloud. Un agent chargé des achats peut combiner dans une seule requête des données de contrats stockés sur S3, des données d'inventaire sur Azure et des registres transactionnels dans BigQuery, le tout sous un catalogue Iceberg unifié, sans qu'aucune équipe d'ingénierie n'ait à gérer un processus d'ETL entre clouds.
L'implication pour les architectes d'intégration est d'ordre stratégique. La conversation cesse d'être « comment migrons-nous tout vers un seul cloud » pour devenir « comment gouvernons-nous un catalogue unique sur la distribution de données que nous possédons déjà ». Ce n'est pas la même conversation. La première implique un coût politique et financier prohibitif dans la plupart des organisations matures. La seconde est exécutable sans perturber les contrats existants avec les autres fournisseurs.
Ce que Google propose dans son ensemble est un changement de paradigme aux conséquences organisationnelles qui vont bien au-delà de l'architecture technique. Le MCP en tant que couche de gouvernance des agents doit être géré avec la même discipline que celle appliquée aujourd'hui à une passerelle d'API : versionnage, authentification, monitoring, limites d'utilisation. Le Catalogue de Connaissances cesse d'être un projet de documentation pour devenir une dépendance opérationnelle en temps réel, ce qui implique des accords de niveau de service, une maintenance continue et un modèle d'exploitation que les équipes de données n'ont pas encore conçu.
La culture d'une organisation n'est pas l'affiche encadrée dans la salle de réunion ni le discours du PDG lors de la convention annuelle. C'est la somme accumulée de toutes les décisions que les dirigeants ont prises lorsqu'il était plus confortable de reporter que de décider, plus sûr de déléguer que d'assumer, plus facile d'accuser la dette technique que de reconnaître que l'architecture de la donnée reflète avec une précision chirurgicale l'architecture du pouvoir, de la peur et des conversations que la direction n'a jamais eu le courage de tenir.
