Damien Andell, cofondateur de 1492.vision, a réussi à décrypter l'architecture interne du Daily Hub de Google, révélant un système d'une complexité technique remarquable. Ces découvertes exclusives, qu'il m'a partagées en avant-première, s'inscrivent dans l'accélération fulgurante de Google vers l'hyperpersonnalisation que nous observons depuis quelques mois : Sources Préférées, pages profils d'éditeurs suivables dans Discover, Brand Profiles dans Merchant Center... Autant de briques qui convergent vers un seul objectif : anticiper vos besoins avant même que vous ne formuliez une requête.

Rappelez-vous : lors de nos investigations cet été, sur les 90 projets IA de Google via le menu debug de l'AI Mode, nous avions identifié "News Digest & Daily Brief" parmi la constellation d'agents spécialisés. Daily Hub est précisément la concrétisation de ces projets. Mais comme nous allons le voir, son architecture révèle une complexité technique qui explique pourquoi Google a dû suspendre temporairement ce service en septembre 2025, à peine un mois après son lancement sur les Pixel 10.

L'architecture à trois étages du Daily Hub

Pour comprendre le Daily Hub, imaginez un chef d'orchestre (Gemini) qui doit coordonner trois sections d'un orchestre symphonique, chacune jouant une partition différente mais devant s'harmoniser en temps réel. C'est exactement ce que tente de faire Google avec ce système.

Premier étage : la couche « mémoire & embeddings »

Le Daily Hub s'appuie sur deux types de documents fondamentaux qui constituent sa mémoire :

Le MemoryDocument représente l'unité de contenu complète. Chaque document contient :

• Le contenu textuel structuré (title, summary, rawText découpé en segments)
• Une liste d'identifiants d'entités (entityIds) extraites du Knowledge Graph
• Deux types d'embeddings : contentEmbeddings pour le document entier et chunkEmbeddings pour chaque segment
• Des métadonnées techniques (sourceDataIds, memoryTimeMs, servingState)
• Des données binaires (memoryContentBytes, memoryInfoBytes) pour le stockage optimisé

Le MemoryEntityDocument est plus léger et représente chaque entité extraite :

• Les caractéristiques de l'entité (entityType, entityText, entityDescription, entityTag)
• La liaison au document parent via parentMemoryId et memoryQualifiedId
• Un seul embedding (contentEmbeddings) sans découpage en chunks
• Un horodatage spécifique (entityTimeMs)

Concrètement, si Daily Hub traite un article sur "Lionel Messi rejoint l'Inter Miami", le système va créer :

• Un MemoryDocument contenant l'article complet avec ses embeddings
• Plusieurs MemoryEntityDocument : un pour "Lionel Messi" (type: Person), un pour "Inter Miami CF" (type: Organization), un pour "soccer" (type: Sport), etc.

Cette double structure permet au système de naviguer soit par contenu (via les documents), soit par entité (pour des recommandations thématiques).

Deuxième étage : le triptyque de la personnalisation

Damien a découvert que trois systèmes parallèles alimentent la personnalisation du Daily Hub :

1. Nephesh (le système d'embeddings universels)

C'est le système d'embeddings universels de Google que Damien avait déjà documenté dans ses analyses sur Discover (pour préserver son anonymat, le nom de ce modèle a été modifié dans cet article). Dans le contexte du Daily Hub, Nephesh :

• Stocke les centres d'intérêt dans ContentInterest.db via SQLite
• Associe à chaque sujet un score numérique (string parsé en double)
• Utilise des clés de déduplication (dedupe_key_nephesh_content_interest) pour éviter les doublons

Exemple de structure de données Nephesh :

{
  "football": "0.82",
  "cooking": "0.65",
  "AI": "0.91"
}

Le code découvert révèle le mécanisme de parsing :

CustomNepheshData.getScore() → String
parseDouble() → Double
→ injection dans le builder d'intérêt

2. AIP_TOP_ENTITIES

Ce système gère les "top entités" Knowledge Graph de l'utilisateur :

• Mise à jour quotidienne basée sur les interactions
• Alimentation via les boutons "Follow" de Discover dans le cadre...