Même écran éteint, le système Android compose un instantané de vous : déplacements, sons, état de l'appareil. Et quand vous dictez, il reconnaît vos mots à vous, appris sur l'appareil. Deux volets : les signaux captés, puis le vocabulaire appris.
La détection de contexte ne vit pas dans une application : elle habite les couches système d'Android, en amont des apps, et tourne en continu. Trois briques embarquées composent l'image : là où vous êtes et comment vous bougez, ce que le micro peut entendre autour de vous, et l'état de l'appareil. Chaque signal capté est rattaché à un service que vous utilisez déjà.
Ce n'est pas une application qui observe, c'est le système lui-même.
À intervalles réguliers, l'appareil assemble un objet unique qui réunit dix dimensions. Chacune vient d'un capteur ou d'un service système différent, mais elles sont agrégées en un seul instantané horodaté, comparé au précédent. Faites défiler : les capteurs s'allument un par un autour du cœur.
déduite des capteurs de mouvement : immobile, à pied, en course, à vélo ou en véhicule
position calculée en croisant GPS, réseaux WiFi visibles et antennes cellulaires
écouteurs branchés ou non, et appareils appairés à portée (montre, voiture, enceinte)
petits émetteurs Bluetooth installés dans certains lieux (magasins, musées), détectés au passage
connecté à un WiFi reconnu (domicile, bureau), en données mobiles ou hors ligne
niveau de batterie, appareil en charge ou branché sur secteur
allumé ou éteint : le téléphone est-il en cours d'utilisation ou posé quelque part
conditions locales (température, pluie) fournies par le service météo au moment de la capture
catégorie du moment : matin, soir, nuit, semaine, week-end, jour férié
le conteneur générique du gestionnaire de contexte de Play Services : des signaux déjà interprétés ailleurs, ajoutés en bloc
Chaque instantané embarque trois champs de suivi relevés dans le code : l'heure de la capture en cours, l'heure de la capture précédente, et le nombre d'événements de mouvement enregistrés entre les deux. C'est l'horodatage précédent qui change tout : chaque capture est reliée à celle d'avant, et la série forme une chaîne continue plutôt qu'une suite de photos isolées. Le système sait donc non seulement dans quel état vous êtes à cet instant, mais aussi depuis combien de temps il ne vous avait pas observé et combien vous avez bougé entre-temps.
La journée découpée en segments, chacun étiqueté par un mode et un lieu.
Un modèle embarqué prend la trace de position (GPS, WiFi, cellulaire, altitude) et la découpe en segments. À chaque segment, il attribue deux choses : un mode de déplacement et le lieu le plus probable parmi des candidats. Treize modes de transport, un score d'arrêt, un score de séparation entre segments, et dix scores de lieux candidats : vingt-cinq sorties au total.
// 25 sorties de score du segmenteur de mobilité // 13 modes de transport WALKING RUNNING CYCLING MOTORCYCLING IN_PASSENGER_VEHICLE IN_BUS IN_SUBWAY IN_TRAIN IN_TRAM IN_FERRY FLYING SAILING SKIING // arrêt sur un lieu + frontière entre deux segments VISIT_SCORE DIVISION_SCORE // 10 lieux candidats départagés par un score FLOAT_CANDIDATE_SCORE_N00 … FLOAT_CANDIDATE_SCORE_N09
Les deux scores du milieu structurent tout le reste. VISIT_SCORE mesure la probabilité qu'un segment soit un arrêt : l'appareil ne se déplace plus, il séjourne quelque part. Ce score entre en concurrence avec les treize modes de transport : à chaque instant de la trace, soit vous êtes en mouvement dans un mode donné, soit vous êtes en visite. DIVISION_SCORE mesure autre chose : la probabilité qu'une frontière tombe à ce point précis de la trace. C'est lui qui décide où la journée se coupe, l'instant où le trajet à pied se termine et où la visite commence. L'alternance qui en résulte, trajets d'un côté, visites de l'autre, est exactement la structure que la Timeline Google affiche : un VISIT_SCORE élevé crée un lieu visité, un DIVISION_SCORE élevé ferme le segment précédent et en ouvre un nouveau.
Pour trancher entre deux lieux à la même adresse mais à des étages différents, le modèle compare l'altitude de l'appareil à la hauteur connue du lieu. Mis bout à bout, ces segments forment le « pattern of life » : la répétition des trajets, des arrêts et des horaires qui décrit une vie ordinaire.
527 sons scorables, 45 armés d'un seuil de déclenchement.
Le modèle sait scorer 527 types de sons (l'ontologie AudioSet complète), mais l'app n'agit que sur 45 d'entre eux : ceux qui portent un seuil de déclenchement codé. Sur les jauges, la barre représente ce seuil. Barre courte = seuil bas = gâchette facile, le son est attrapé au moindre indice. Barre longue = quasi-certitude exigée avant de réagir.
Le contraste est frappant. Les planchers (claquement à 0,0045, gémissement à 0,008, applaudissements à 0,010) sont réglés pour déclencher au premier soupçon. À l'autre bout, la musique exige 0,9259, le seuil le plus haut de tous : le système attend une quasi-certitude avant de croire qu'un morceau joue, pour éviter d'enclencher un contexte « musique » sur un simple bruit de fond.
Mobilité, sons, état de l'appareil : pris séparément, ce sont des fragments. Réunis dans un seul instantané, ils dessinent un moment de votre vie. Les signaux convergent.
La répétition des trajets se transforme en automatismes anticipés.
Les lieux que le segmenteur de mobilité voit revenir jour après jour ne restent pas des points sur une carte. L'appareil les transforme en géofences : des zones autour desquelles il arme des déclencheurs. Arriver quelque part, en repartir, et une action se prépare : une routine, un rappel, une suggestion.
La mécanique se lit dans le code en trois étapes. D'abord, les visites répétées s'accumulent : le segmenteur de mobilité produit des lieux candidats scorés, que le code regroupe dans un objet nommé GroupedScoredPlaces. Ensuite, les lieux qui reviennent assez souvent sont promus : un composant baptisé RoutinesGeofenceHandler enregistre autour d'eux un périmètre virtuel auprès du service de localisation. Enfin, le franchissement de ce périmètre réveille l'application, même fermée : l'instantané de contexte qualifie le moment (heure, activité, casque, réseau) et l'action préparée part.
Ce que le système sait de vos allées et venues devient ainsi le calendrier implicite de ce qu'il vous proposera. Les trois scénarios ci-dessous sont des reconstitutions plausibles, pas des captures : les enchaînements sont illustratifs, mais chaque événement en petites capitales correspond à un signal réel relevé dans le code.
Après quelques semaines du même enchaînement, la simple sortie de la zone suffit : l'écran se prépare avant que vous ayez demandé quoi que ce soit.
La répétition hebdomadaire (même lieu, mardi et jeudi) arme le déclencheur ; le casque branché, une des dix dimensions de l'instantané, confirme le moment.
Le rappel a été posé des jours plus tôt ; c'est le franchissement du périmètre, pas une horloge, qui le fait remonter.
Le « pour mieux vous servir » : chaque commodité a une contrepartie de captation nommée.
La boucle se ferme ici. Les signaux ne sont pas captés pour eux-mêmes : ils alimentent des produits que vous ouvrez tous les jours. À chaque service correspond un ensemble de signaux nommés.
Le flux d'articles se calibre sur où vous êtes, à quelle heure, comment vous vous déplacez et dans quel état est l'appareil.
Ce que la barre de recherche propose avant que vous tapiez la moindre lettre, calé sur le contexte présent.
La même question ne produit pas la même réponse. Casque branché : la réponse est lue à voix haute. En voiture : interface réduite, tout passe par la voix. À la maison le soir : raccourcis vers les appareils connectés et les routines ; au bureau : agenda et rappels du jour.
Détecteur de fumée, sonnette, bébé qui pleure : le téléphone vibre, allume le flash et alerte à l'écran et sur la montre (la fonction d'accessibilité pour les malentendants). Les sons ordinaires deviennent une étiquette d'ambiance qui recoupe les autres signaux : la circulation confirme le trajet GPS, la musique qualifie le moment.
Capter le contexte n'est qu'une moitié de l'histoire. L'autre moitié se joue sur l'appareil : votre téléphone apprend votre vocabulaire à vous et corrige ce que vous dictez, avec des modèles embarqués, sans qu'un octet parte vers le cloud. Voici ce trajet, en six blocs.
Pourquoi votre téléphone sait écrire vos mots à vous.
Comment votre téléphone sait cela ? Deux mémoires : ce que vous dites, et ce que vous avez déjà écrit. Elles vont se rejoindre.
Découpée, nettoyée, puis projetée dans le même espace que les mots.
Le son n'est pas « reconnu » d'un coup. Il est d'abord transformé en une suite de nombres, des vecteurs (ce que les ingénieurs appellent des embeddings), placés dans le même espace mathématique que les mots écrits. C'est ce qui permet, plus loin, de comparer votre voix à votre vocabulaire. Un point important : ces vecteurs de voix sont éphémères. Ils servent à transcrire la phrase en cours, puis sont jetés ; votre voix elle-même n'est pas archivée sous cette forme.
Le fichier audio_adapter_lora_asr_v3.tflite prend des features acoustiques de forme [3 × 1536] et les projette vers des tokens de forme [3 × 2048]. C'est un adaptateur LoRA : une petite couche entraînée qui « branche » l'audio sur l'espace du modèle de langue, sans réentraîner tout le modèle.
En amont, un front-end audio (ROSIE_ROBOT : Framer, Stacker, Subsample, AutoGain) met le signal en forme en continu, trame par trame.
Contacts, mots appris par votre clavier, apps et agenda, encodés en banque mémoire chiffrée.
Vos noms propres ne sont pas dans le modèle de base. Votre téléphone les récolte : vos contacts, le dictionnaire personnel du clavier (ces noms, sigles et expressions que vous tapez souvent, et que le correcteur a fini par apprendre au lieu de les souligner), les noms de vos applications, votre agenda. Il en fait une « antisèche » compacte et chiffrée, limitée en taille, qu'il pourra relire à chaque phrase.
Une entrée est une séquence courte qui vous est propre : un nom de contact, un nom d'application, une expression. Elle est tokenisée puis encodée, dans la limite de 32 tokens (quelques mots).
Combien de mots cela représente ? Le plafond est exprimé en entrées et en tokens, pas en mots, mais on peut donner une fourchette. Une entrée réelle contient un à cinq mots (« Maïwenn Le Guellec », « Doctolib », « réunion Codir ») : rempli, le dictionnaire personnalisé retient donc de l'ordre de 2 000 à 10 000 mots qui vous sont propres. Et une fois vectorisée, cette mémoire est minuscule : la banque pleine pèse environ 0,26 Mo, moins qu'une seule photo.
L'encodeur nam_retriever.tflite prend des phrases de [N × 32 tokens] et sort une banque mémoire [N × 128]. C'est un mini-transformer de type Gemma figé : 4 couches, attention GQA, activation GeGLU, RMSNorm, quantifié en INT8, environ 5 Mo.
La liste n'a pas une taille libre : des sous-graphes sont pré-compilés pour des tailles fixes (128, 256, 512, 1024, 2048 phrases). Au-delà de 2048, il faut prioriser.
Volumétrie : 2048 entrées de 32 tokens donnent un maximum théorique de 65 536 tokens, soit environ 40 000 à 50 000 mots si chaque entrée était remplie à ras bord. En pratique, les entrées sont bien plus courtes, d'où la fourchette de 2 000 à 10 000 mots. La banque encodée fait [2048 × 128] en INT8, soit 262 144 octets : environ 0,26 Mo.
Au départ, il ne connaît que la langue ; son lexique personnel se construit à l'usage.
Sorti de la boîte, un téléphone connaît la langue mais pas vos noms propres : il écrira « réseau néo ». Il embarque un « cerveau d'usine » générique, puis son lexique personnel se remplit, et la liste monte par paliers.
Une idée reçue à écarter : votre téléphone ne réentraîne pas son « cerveau » à chaque mot tapé. Il tient plutôt à jour un lexique personnel, une liste de vocabulaire qui vit à côté du modèle. Ce sont vos usages qui font le tri : un nouveau contact enregistré, une application installée, un mot que le clavier vous voit taper souvent gagnent leur place dans la liste ; quand les 2 048 places se remplissent, les entrées les moins utilisées cèdent la leur aux plus fréquentes et aux plus récentes. À chaque changement, le lexique est ré-encodé en vecteurs, prêt à être consulté. C'est de la mémoire relue, pas un réglage des poids du modèle sur l'appareil.
Le « cerveau d'usine » est prouvé par les fichiers *_default_adapter.bin (LoRA générique, environ 36 à 37 Mo). La montée en paliers (128, 256, 512, 1024, 2048) l'est aussi, via les sous-graphes pré-compilés.
Comment le lexique se remplit, concrètement : l'appareil récolte des entrées qui vous sont propres (contacts via la permission READ_CONTACTS, noms de personnes, dictionnaire du clavier, noms d'apps, agenda). Elles sont tokenisées (nam_tokenizer_spm), puis encodées par nam_retriever en vecteurs [N × 128]. Quand la liste change, la banque est ré-encodée. Ce n'est pas un réentraînement : la personnalisation vit dans une banque de récupération que le décodeur consulte, pas dans les poids du modèle, qui sont figés et intégrés au modèle livré.
La fréquence d'usage compte, mais en amont : c'est le clavier et la base contacts qui savent quels mots reviennent, et cette fréquence sert à choisir puis prioriser les entrées quand le plafond de 2048 est atteint. La récolte (contacts, noms de personnes) est prouvée par les fichiers ; la curation par fréquence et le ré-encodage à chaque changement relèvent du design documenté [D].
À chaque ouverture de session, des graphes prefill (fichiers .nncz) pré-remplissent le cache d'attention (KV-cache) pour démarrer plus vite.
Le modèle compare votre voix à votre lexique personnel, et penche vers vos mots.
C'est le moment central. Deux flux convergent : votre voix encodée (bleu) et votre banque mémoire (orange). Au moment de choisir les mots, le décodeur Gemini Nano consulte votre lexique et penche vers vos noms à vous.
« Envoie un message à Maïwenn : j'arrive dans 10 minutes » grâce à vos contacts
« Ouvre Doctolib et confirme le rendez-vous » grâce à vos noms d'apps
« Prépare la réunion Resoneo du 26 juin » grâce à votre agenda
* trait en pointillés : maillon issu du design documenté par Google, pas d'un tenseur présent dans les fichiers ouverts.
La banque mémoire [N × 128] est reliée au décodeur par une projection en 128 dimensions. Concrètement, pendant la génération, le décodeur « consulte » la banque et augmente la probabilité de vos entrées : c'est le biais.
Majuscules, ponctuation, chiffres : une dernière couche rend le texte lisible, toujours sur l'appareil.
Ce que le décodeur produit est encore du texte brut : tout en minuscules, sans ponctuation, avec les nombres écrits en toutes lettres, comme un télégramme. Une chaîne de mise au propre repasse derrière : elle découpe les phrases, pose majuscules et ponctuation, et réécrit en chiffres ce qui a été dicté en mots. « vingt-six juin » devient « 26 juin », « quinze heures trente » devient « 15h30 ». Neuf langues sont couvertes, et tout se passe encore sur l'appareil.
sortie brute : rendez-vous chez resoneo le vingt-six juin à quinze heures trente
La même mécanique s'applique aux montants, aux numéros et aux titres :
« deux mille cinq cents euros » → « 2 500 € »
« zéro six douze trente-quatre cinquante-six » → « 06 12 34 56 »
« docteur nguyen » → « Dr Nguyen »
octet envoyé au cloud pour cette phrase
La finition s'appuie sur la famille greco_* (dé-normalisation, ponctuation, capitalisation, découpage en phrases), multilingue : de, en, es, fr, it, ja, pt, hi, zh. Neuf langues attestées dans les fichiers.
Analyse des modèles AICore on-device (manifests PublicComputeServices), juin 2026. Les blobs CDN sont en zlib, décodés et vérifiés. Le trajet d'encodage (voix et lexique en vecteurs) est prouvé par les fichiers ; le maillon de biais acoustique (cross-attention décodeur et banque mémoire) relève du design NAM documenté de Google, pas d'un tenseur présent dans les fichiers ouverts.
Une distinction gardée par rigueur : mT5_cached_bias16.bin est un biais d'attention relatif interne au modèle, pas le vocabulaire personnel.
Le contexte capté et le vocabulaire appris sont le socle. Voici ce que Google construit au-dessus.
Ces six scénarios ne sont plus de la science-fiction : ils sont en préparation dans le code de Google, et ils reposent sur les briques décrites dans cette page. Extraits de notre étude « Le téléphone IA de demain, vu de l'intérieur d'un APK Google ».
