Un internaute tape « citadine électrique pas chère » dans la recherche d’un site automobile. Avec l’API de décision, que Google prépare pour Chrome, le site pourra demander au navigateur de cocher les bons filtres, sans passer par un serveur. Nous l’avons testée avec les trois modèles d’IA qui peuvent la faire tourner, puis comparé le modèle actuel de Chrome à sa version 2, sortie le 6 octobre.
Google prépare dans Chrome deux outils d’IA que les sites pourront appeler. L’API d’embedding résume le sens d’un texte en une « signature de sens », une liste de nombres qui sert par exemple à ranger des pages par thème. L’API de décision répond à des questions fermées (oui ou non, un choix dans une liste, une note) sur ce que l’internaute tape sur le site. Les deux calculent sur l’ordinateur de l’internaute, et aucune n’est encore active. Le 6 octobre, Google a publié EmbeddingGemma 2, la nouvelle version du modèle de Chrome, et ajouté l’API de décision au code de Chrome. Nous avons testé l’API de décision sur 414 requêtes et comparé les deux versions du modèle sur 151 pages.
Les trois raisons que donne Google (proposition de l’API de décision, fiche Chrome de l’API d’embedding, annonce d’EmbeddingGemma 2), notre lecture, puis l’état réel de Chrome au 7 octobre 2026.
Le calcul se fait sur l’ordinateur de l’internaute : pas de serveur à payer, aucune donnée personnelle envoyée. Quand un visiteur tape « veste imperméable femme pas chère » dans la recherche d’un site de mode, le site peut ranger sa demande dans les bons rayons sans payer une IA en ligne. Et tous les sites partagent le même modèle.
Google vise les sites qui doivent décider vite à partir d’une phrase. Sur un site d’hôtels, quels filtres cocher pour « acceptant les chiens, pas trop cher » ? Dans un service de stockage en ligne, quel bouton actionner quand on tape « partager ce fichier avec mes collègues » ?
Selon Google, faire rédiger une réponse par un grand modèle pour choisir entre trois options est « 10 à 50 fois » plus lourd. Google reprend l’idée de Jev, lancé le 15 septembre par la start-up TypeSafe AI : un modèle qui ne rédige pas, mais choisit entre des réponses fixées d’avance. Il le cite dans sa fiche Chrome et a publié sa proposition quinze jours plus tard. Chrome ne fait pas tourner Jev pour autant : ses moteurs sont EmbeddingGemma, Laya (un équivalent open source de Jev) et Gemma 4, un grand modèle plus juste mais plus lent.
Google a d’abord voulu classer les internautes pour la publicité (Topics), puis les pages selon la taxonomie publicitaire IAB (Classifier API), et a abandonné les deux. Il donne désormais aux éditeurs l’outil pour créer leurs propres rubriques, comme « trail en montagne » ou « premier marathon », et y ranger leurs pages. Ni la proposition de l’API de décision ni la fiche Chrome de l’API d’embedding ne parlent de publicité.
Tout se prépare dans les versions de test de Chrome. Rappel : une « signature de sens » est une liste de 768 nombres qui résume un texte ; « veste imperméable femme » et « manteau de pluie pour femme » obtiennent des signatures proches sans avoir un mot en commun.
| Élément | Ce que c’est | Dans Chrome au 7 octobre |
|---|---|---|
| EmbeddingGemma 2 | Modèle ouvert qui transforme texte, image, son ou vidéo en signature de sens ; 100 langues | Absent : Chrome livre toujours EmbeddingGemma 1 (mai 2026) |
| API d’embedding | Calcule la signature de sens d’un texte pour le site | Présente mais désactivée, même dans Chrome grand public |
| API de décision | Répond aux questions fermées d’un site sur ce que tape l’internaute | Arrivée dans Chrome Canary le 7 octobre, derrière un réglage avancé. Sans moteur, elle répond « indisponible » |
| Laya | Équivalent open source de Jev, créé hors de Google | Déclaré depuis le 5 octobre, mais Chrome ne sait pas encore l’exécuter |
| Gemma 4 | Grand modèle qui rédige, déjà utilisé par d’autres outils IA de Chrome | Son branchement à l’API de décision est en relecture chez Google |
Rien n’est encore actif, mais nos tests disent déjà quoi faire, métier par métier.
| Métier | Ce qui arrive | Ce que vous pouvez faire, et où |
|---|---|---|
| E‑commerce | Chrome pourra transformer une recherche tapée sur le site en filtres | Dans le code de la page : écrire le schéma, avec une phrase par filtre et par valeur (exemple ci-dessous). Dans l’historique de votre moteur de recherche interne : réunir de vraies requêtes pour le tester dès l’ouverture de l’API |
| SEO et contenu | Des sites et des tags pourront classer les pages par thème dans Chrome, qui n’en lit que les 1 500 premiers mots environ | Dans le contenu de la page : dire de quoi elle parle dès le titre, le chapô et les deux premiers paragraphes |
| Brand safety et ciblage contextuel | Un tag tiers autorisé par l’éditeur pourra classer la page au moment de l’affichage | Dans les réglages de votre outil de brand safety : définir chaque thème interdit en une phrase, et prévoir de revoir les seuils à chaque changement de modèle |
| Data et produit | Des signatures de sens calculées gratuitement sur l’ordinateur du visiteur | Dans votre base de données : stocker avec chaque signature le texte source et le nom du modèle, pour tout recalculer. Ne jamais comparer les signatures de deux modèles |
En pratique, le développeur du site ajoute à la page un petit script. Ce script décrit les questions dans un « schéma », un objet proche du JSON : pour chaque question, son intitulé et ses réponses possibles. Quand le visiteur lance sa recherche, le script transmet le texte tapé à Chrome, qui renvoie pour chaque question la réponse choisie et un score de confiance ; le script coche alors les filtres. Exemple pour un site automobile :
// Le schéma : les questions que Chrome devra trancher const schema = { context: "", // laissé vide questions: [{ id: "carrosserie", type: "choice", prompt: "Quelle carrosserie le visiteur cherche-t-il ?", options: [ { label: "citadine", description: "petite voiture urbaine, facile à garer" }, { label: "berline", description: "voiture familiale avec un grand coffre" }, { label: "suv", description: "véhicule haut et spacieux, type 4x4" } ] }] }; // Le texte tapé par le visiteur part vers Chrome, qui choisit une réponse const modele = await DecisionModel.create(schema); const reponse = await modele.decide(texteTape); // reponse.carrosserie : réponse choisie + score de confiance de 0 à 1
Dans nos tests, quatre réglages de ce schéma font passer le modèle actuel de Chrome de 38 % à 58 % de bonnes réponses :
Ces réglages sont à refaire à chaque modèle : le même schéma tombe à 45 % avec EmbeddingGemma 2.
L’API ne fonctionne pas encore dans Chrome : nous l’avons reconstruite d’après son code. Nous avons ensuite écrit les questions de 11 sites fictifs (automobile, hôtels, électroménager…), puis tapé 414 recherches et messages, en français et en anglais, pour vérifier si l’API choisit les bonnes réponses.
L’API confie chaque question à un modèle d’IA, son « moteur ». Google en prévoit trois : EmbeddingGemma, déjà dans Chrome et rapide (0,2 seconde par décision) ; Laya, un équivalent open source de Jev créé hors de Google (1,5 seconde) ; Gemma 4, un grand modèle déjà utilisé par d’autres outils de Chrome (2,4 secondes).
Questions oui/non : la bonne réponse est « non » dans 80,5 % des cas, car la plupart des requêtes ne parlent pas du critère demandé.
| Filtre du site automobile | Bonne réponse | EmbeddingGemma | Laya | Gemma 4 |
|---|---|---|---|---|
| Carrosserie | citadine | peu importe | berline | citadine |
| Motorisation | électrique | peu importe | électrique | électrique |
| Boîte automatique exigée | non | oui | non | non |
| Faible kilométrage exigé | non | oui | non | non |
| Budget, de 1 à 4 | 1 | 4 | 2 | 1 |
| Filtres justes | 5 | 0 sur 5 | 3 sur 5 | 5 sur 5 |
Fond vert : réponse juste. Fond rose : réponse fausse.
Pour « chalet à la montagne pour 8 personnes », tapé sur un site de location, il coche « animaux acceptés », « piscine » et « parking ». 14 questions oui/non sur 18 reçoivent la même réponse, quoi que l’on tape.
EmbeddingGemma choisit « autre » ou « peu importe » 70 % du temps, alors que c’est la bonne réponse dans 26 % des cas. « Lave-linge silencieux 9 kg » finit dans « autre appareil ».
Chaque réponse arrive avec un score de confiance, de 0 à 1. Dans ses exemples, Google n’applique la réponse qu’au-dessus de 0,85. Une seule décision sur 1 365 dépasse ce seuil.
Chrome ne compare pas la recherche seule aux réponses possibles : il l’insère dans une phrase avec la question et la présentation du site, où elle ne pèse plus qu’un cinquième. Toutes les recherches finissent par se ressembler. Avec le même modèle, comparer la recherche seule à chaque réponse donne 63 % de bonnes réponses, 25 points de plus.
C’est le seul moteur dont le score de confiance est utile : 80 % des réponses dépassent 0,85, et 91 % de celles-ci sont justes. Mais il lui faut 2,4 secondes par décision et plus de 4 Go sur l’ordinateur. Son branchement est en relecture chez Google.
Laya fait 64 % et tombe bien moins dans les options « peu importe » (21 % au lieu de 70 %). Chrome déclare trois modèles Laya depuis le 5 octobre, mais Google a retiré le code qui les branchait : Chrome ne sait pas encore les faire tourner. Nous l’avons testé avec les fichiers publics du même nom.
51,5 % de bonnes réponses, mais seulement parce qu’il répond plus souvent « non », ce qui tombe juste quand la recherche ne parle pas du critère. Sur les listes de choix, aucun progrès.
Les moteurs reproduisent du code que Google peut encore modifier avant toute sortie.
L’autre usage du modèle de Chrome : ranger des pages par thème avec l’API d’embedding, pour un site ou un tag publicitaire qui veut savoir de quoi parle une page. Nous avons comparé les deux versions sur 151 pages réelles de 45 sites, en français et en anglais, réparties en 12 thèmes.
Avec le modèle actuel, ce seuil de 0,62 ne signalait aucune page normale ; avec EmbeddingGemma 2, il les signale toutes. Et les signatures des deux modèles n’ont presque rien en commun : toute base calculée avec l’ancien est à refaire.
Une pub de paris sportifs et un avant-match de football obtiennent presque le même score face à un profil « contenus à éviter » (0,871 et 0,845). Ce qui marche, avec les deux modèles : décrire chaque thème interdit en une phrase, comme « contenu qui incite à parier : offres de paris, cotes boostées, bonus de casino ».
EmbeddingGemma 2 est 2 à 5 fois plus lent que le modèle actuel. Ajouter trois exemples par thème lui fait perdre 11 points : une seule phrase de définition fonctionne mieux.
Sur le texte, EmbeddingGemma 2 ne progresse presque pas (61,36 contre 61,15 sur MTEB, le banc de test de référence). Il gagne 9,9 points sur le code informatique et lit désormais images, son et vidéo. Rien de cela n’arrive dans Chrome, dont l’API ne traite que du texte.