Calipia : le blog

Google veut faire de Spanner le cerveau de données des agents IA

Google Cloud a profité de la fin du mois de juin pour repositionner Spanner, sa base de données distribuée historique, non plus comme un simple moteur transactionnel mondial, mais comme la fondation de données de ce que l’entreprise appelle désormais son Agentic Data Cloud. C’est loin d’être stupide. Le message adressé aux DSI est limpide : arrêtez d’éparpiller vos données entre une base relationnelle, un moteur de recherche, une base vectorielle et une base de graphe, et confiez le tout à Spanner.

L’argument technique tient la route sur le papier. Un agent IA qui doit prendre une décision autonome a besoin simultanément d’un historique structuré, d’une compréhension sémantique via des embeddings, de relations réelles entre entités et de contenus textuels indexés. Aujourd’hui, ces quatre besoins sont généralement couverts par quatre systèmes différents, avec les pipelines ETL, la latence et les problèmes de cohérence que cela suppose. Google propose donc de réunir dans un seul moteur transactionnel les briques suivantes.

Spanner Graph offre un modèle de graphe natif, compatible avec le standard ISO GQL, superposable aux données relationnelles existantes. C’est ce que Palo Alto Networks utilise déjà pour gérer du contrôle d’accès à grande échelle sans base de graphe dédiée. La recherche vectorielle intégrée s’appuie sur ScaNN, l’algorithme d’indexation qui équipe Google Search et YouTube, et Google annonce un support d’index dépassant dix milliards de vecteurs, taillé pour du RAG à faible latence. À cela s’ajoutent un point d’accès clé valeur compatible Cassandra, pensé pour faciliter les migrations, et un moteur de recherche plein texte avec correction orthographique et gestion de synonymes automatique. Enfin, le moteur colonnaire intégré promet des requêtes analytiques jusqu’à deux cents fois plus rapides directement sur les données opérationnelles, sans dupliquer la donnée ni passer par BigQuery.

L’autre annonce, plus structurante pour les architectes qui suivent les enjeux de souveraineté, c’est Spanner Omni. Il s’agit d’une version conteneurisée et téléchargeable de Spanner, exécutable sur Kubernetes sans matériel dédié, aussi bien sur AWS, sur Azure, en on premise que sur des déploiements en périphérie. Google reprend ici la recette déjà appliquée à AlloyDB Omni pour PostgreSQL. L’argument est habile : proposer une portabilité multi cloud pour désamorcer la critique récurrente du lock in propriétaire, tout en gardant la propriété intellectuelle et le contrôle de la feuille de route.

Sur le plan de la crédibilité, Google avance des éléments solides. Spanner a été classé numéro un dans la catégorie transactions légères du dernier rapport Gartner sur les SGBD opérationnels cloud, deux années de suite, et une étude Forrester commanditée par Google évoque un ROI de 132 pour cent sur trois ans pour un profil client composite. On notera au passage que cette étude reste financée par l’éditeur, ce qui invite à la garder pour ce qu’elle est : un argument commercial, pas une évaluation indépendante.

Reste la question qui intéresse vraiment un DSI avant de se lancer : qu’est ce qui est réellement disponible aujourd’hui, et à quel prix ? Sur ce point, la communication de Google reste évasive. Aucune date de disponibilité générale, aucune grille tarifaire pour Spanner Omni et les fonctionnalités les plus avancées, et un simple renvoi vers les équipes commerciales pour les clients intéressés. Pour une architecture censée devenir le cœur de vos systèmes d’agents, c’est un flou qui mérite d’être suivi de près avant tout engagement de production.

Sur le fond, la stratégie de Google s’inscrit dans une tendance de marché plus large. Oracle pousse dans la même direction avec Oracle 23ai et ses capacités vectorielles natives, MongoDB étend Atlas vers le multi modèle, et Databricks avance sur Lakebase pour rapprocher opérationnel et analytique. La bataille du prochain cycle ne se jouera donc pas seulement sur les modèles de langage, mais sur qui contrôlera la couche de données qui les nourrit. Pour un DSI, cela veut dire une chose concrète : la vraie question n’est plus quel LLM choisir, mais sur quelle architecture de données le brancher, avec quelle réversibilité si le fournisseur change de politique tarifaire dans deux ans.

Spanner mérite clairement d’être évalué pour les organisations qui envisagent des architectures agentiques ambitieuses. Mais l’unification promise a un revers assez classique chez les hyperscalers : plus l’intégration native est poussée, plus la dépendance à l’écosystème Google se resserre, même quand ce dernier brandit l’argument multi cloud. Un comité d’architecture bien inspiré comparera ce choix à ses alternatives spécialisées, chiffrera la migration inverse si besoin, et attendra que les annonces se transforment en tarifs publics avant de graver quoi que ce soit dans le marbre.

L’article de référence est le billet officiel de Google Cloud : Supercharging the agentic era with Spanner’s multi-model architecture.