Gemini Nexus : une couche IA dans Chrome, avec une dette juridique assumée

Le problème résolu : un seul panneau pour des fournisseurs qui ne se parlent pas

Un ingénieur qui veut interroger Gemini, Claude et un modèle servi par OpenRouter passe aujourd'hui par trois onglets, trois formats de clé et trois façons d'envoyer une image. Gemini Nexus ramène cela dans un panneau latéral Chrome unique. Le README décrit l'extension comme une couche IA native du navigateur, avec une barre flottante injectée, la saisie d'images et de captures d'écran, et des outils de contrôle du navigateur. Le public visé est donc précis : quelqu'un qui travaille déjà dans Chrome, qui manipule plusieurs fournisseurs et qui veut que le contexte de la page courante soit disponible sans copier-coller. Ce n'est pas un outil pour un pipeline serveur, ni pour du traitement par lots. C'est un poste de travail.

Neuf fournisseurs derrière une interface, et un fichier par famille

Le dépôt range les pilotes dans services/providers. Le README nomme les fichiers : web.js pour le client Gemini Web, official.js pour l'API Gemini officielle, openai_compatible.js pour OpenAI officiel, DeepSeek, OpenRouter, Qwen/DashScope et Zhipu, anthropic.js pour l'API Messages de Claude. Chaque fournisseur a ses propres champs Base URL, API Key et Model IDs. Le tableau du README détaille les écarts de comportement : OpenRouter récupère la liste via /models et accepte un JSON de routage de fournisseurs, DashScope utilise un endpoint compatible avec enable_thinking et l'entrée image des modèles VL, Anthropic passe par l'API Messages avec affichage du flux de réflexion étendue. Cette séparation par fichier est le point architectural le plus sain du projet : ajouter un fournisseur compatible OpenAI revient à écrire un profil, pas à modifier le cœur. À l'inverse, les fonctionnalités transverses (recherche web, raisonnement, images) doivent être négociées fournisseur par fournisseur, et le README indique lui-même que le comportement est adapté dynamiquement dans le code.

Gemini Web sans clé API : comment l'extension obtient une session

C'est la partie qui mérite une lecture attentive avant toute installation. Le README explique que le fournisseur Gemini Web accède à gemini.google.com en rétro-ingénierie d'endpoints RPC internes et en extrayant des jetons d'authentification (atValue, blValue, f.sid) depuis le HTML de la page. Ces jetons sont stockés localement et réutilisés pour imiter les requêtes du navigateur. Les requêtes partent vers gemini.google.com et push.clients6.google.com avec vos identifiants de session. Le même README écrit que cette approche viole probablement les conditions d'utilisation de Google et peut être considérée comme un accès non autorisé. Il n'y a pas de zone grise à négocier ici : le dépôt publie lui-même la réserve. Le second point documenté est la suppression des filigranes intégrés aux images générées par Gemini pour permettre le téléchargement direct, ce qui retire l'attribution du contenu. Ces deux mécanismes sont présentés comme expérimentaux, avec une clause de décharge de responsabilité. Un lecteur qui active le fournisseur Web ou la suppression de filigrane le fait en connaissance de cause, et c'est la seule position défendable.

Mise en route : les clés de configuration visibles dans le dépôt

L'installation se fait comme toute extension Chrome non empaquetée : on charge le dossier construit dans chrome://extensions avec le mode développeur. Le README mentionne Vite et TypeScript dans les badges, et le topic manifest-v3 confirme la cible. Une fois le panneau ouvert, la configuration tient à trois champs par fournisseur : Base URL, API Key, Model IDs. Pour Gemini Web, aucune clé n'est demandée, mais il faut rester connecté à un compte Google dans le navigateur, ce que le tableau des fournisseurs indique explicitement. Les clés sont stockées dans le stockage de l'extension Chrome et, d'après le README, ne sont pas transmises à un tiers autre que le fournisseur choisi. Les données envoyées (texte, images, fichiers) partent vers l'endpoint du fournisseur configuré, y compris vers un serveur MCP que vous auriez vous-même déclaré. La gestion du contexte passe par une compression par résumé et un élagage des tours récents, deux réglages à surveiller si vous travaillez sur de longues sessions.

Contrôle du navigateur et MCP : la partie qui sort du chat

Le README annonce des outils de contrôle basés sur le Chrome DevTools Protocol et des outils MCP externes optionnels. Deux détails concrets ressortent. D'abord, les tâches de contrôle sont marquées par des groupes d'onglets natifs de Chrome, et list_pages et select_page restent cantonnés au périmètre contrôlé. Ensuite, les liens externes s'ouvrent dans de nouveaux onglets pour éviter les échecs de chargement tiers dans le panneau latéral. Ces choix indiquent une conception qui a rencontré les limites réelles du side panel. La limitation est structurelle : le contrôle du navigateur dépend du CDP, donc d'un navigateur de type Chrome et de permissions étendues. Sur un autre moteur, cette partie du produit n'existe pas. Et un outil qui pilote des onglets sur des pages authentifiées hérite de vos sessions, ce qui élargit la surface bien au-delà d'une simple fenêtre de conversation.

Ce que le dépôt ne dit pas

Le README ne documente ni les permissions déclarées dans le manifeste, ni le détail du stockage des jetons au-delà de la mention locale, ni la façon dont la compression de contexte décide quoi résumer. Le rythme des versions récentes (v5.2.0, v5.2.4, v5.3.0 entre août et septembre 2026) montre un projet actif, mais un numéro de version ne dit rien de la stabilité d'un endpoint RPC interne à Google. C'est le risque principal de ce type de projet : le fournisseur Web dépend d'un HTML et d'endpoints non contractuels, qui peuvent changer sans préavis. Le README ne fournit aucune procédure de repli si l'extraction des jetons casse. Un utilisateur qui s'appuie sur Gemini Web comme fournisseur principal n'a aucune garantie de continuité, et le dépôt ne prétend pas le contraire.

Face à une extension qui ne prend qu'un seul fournisseur

L'alternative la plus directe est une extension mono-fournisseur, du type de celles qui se connectent uniquement à une API officielle avec une clé. La différence n'est pas cosmétique. Une extension mono-fournisseur n'a pas besoin de normaliser les formats de raisonnement, de recherche web et d'images entre neuf backends, donc son code reste court et son comportement prévisible. Gemini Nexus paie cette flexibilité par une couche d'adaptation par fournisseur et par des fonctionnalités qui ne sont pas disponibles partout : la réédition des messages utilisateur historiques est réservée aux fournisseurs API d'après le README, et la recherche web change de mécanisme selon l'endpoint (Responses API web_search ou Chat Completions web_search_options). Si vous n'utilisez qu'un seul modèle, l'agrégation ne vous apporte rien et vous héritez de la surface de risque du fournisseur Web. Si vous comparez réellement plusieurs modèles sur les mêmes pages, le coût d'adaptation se justifie.

Licence MIT, et ce qu'elle ne couvre pas

Le code est publié sous MIT, ce qui autorise la réutilisation, la modification et la redistribution avec conservation de la mention de licence. Cette licence porte sur le code du dépôt. Elle ne vous couvre pas vis-à-vis de Google : les conditions d'utilisation de Gemini Web et les règles sur le contenu généré restent applicables indépendamment de la licence du projet, et le README le rappelle dans sa clause de décharge. Le coût de maintenance, lui, est double. Côté code, suivre un projet qui publie plusieurs versions par mois demande de relire les changements de fournisseurs. Côté dépendance externe, chaque modification du HTML de gemini.google.com ou des endpoints RPC peut casser le fournisseur Web sans qu'aucune version ne soit publiée. Pour un usage individuel et expérimental, ce coût reste faible. Pour un déploiement sur un parc de postes, il faut compter une personne capable de lire services/providers/web.js et de le réparer.

Conclusion éditoriale

Gemini Nexus convient à un développeur qui veut un panneau latéral unique pour comparer plusieurs fournisseurs et qui accepte de lire le code avant de saisir une clé. Il ne convient pas à une équipe qui doit justifier ses outils auprès d'un service juridique, ni à un usage en production sur des données client. Avant toute installation, vérifiez deux points précis : le fichier services/providers/web.js, qui contient l'extraction des jetons atValue, blValue et f.sid, et le chemin de suppression de filigrane décrit dans le README. Si l'un des deux est actif dans votre configuration, vous avez choisi votre fournisseur.

Sources officielles

1. Issues
2. License: MIT
3. README
4. Releases
5. yeahhe365/Gemini-Nexus on GitHub