Un assistant React qui associe l’IA de Chrome à Gemini doit séparer trois actions : résumer le brief dans le navigateur, demander une proposition à Gemini par le backend, puis appliquer les changements après examen. Cette organisation, décrite par Raju Dandigam pour Trip Workbench, garde le texte d’origine comme référence et évite qu’une réponse générée modifie le brouillon sans validation humaine.
Dans cet article
- Séparer les trois actions et leurs flux de données
- Vérifier les appareils compatibles avec Summarizer
- Gérer disponibilité, annulation et textes longs
- Empêcher l’application d’une proposition périmée
- Montrer les changements avant de les enregistrer
Séparer les trois actions et leurs flux de données
Le résumé local et la proposition Gemini ne traitent pas les données de la même façon. Dans Trip Workbench, l’action Chrome Summarizer produit un texte destiné à aider la personne à lire le brief. Elle n’envoie pas de requête au cloud. L’action Gemini, elle, transmet le brief original au backend de l’application, qui appelle le modèle et renvoie une proposition de modifications ainsi que des questions de clarification.
Chrome indique que l’utilisation de son modèle intégré n’envoie aucune donnée à Google ni à un tiers et que, après le téléchargement initial, le modèle peut fonctionner sans connexion. Cette déclaration concerne l’utilisation du modèle intégré. Elle ne décrit pas l’action Gemini distincte, qui envoie le brief au backend de l’application.
Une troisième action applique la proposition examinée par l’utilisateur au moyen du chemin normal de mise à jour du backend. Dans l’exemple de Trip Workbench, appliquer les changements enregistre le brouillon; l’envoi du dossier et la réservation du voyage restent des actions séparées.
Vérifier les appareils compatibles avec Summarizer
La page Chrome consacrée à l’API Summarizer, mise à jour le 30 juillet 2025, indique une disponibilité à partir de Chrome 138 stable. Elle décrit les configurations ci-dessous; ces indications sont celles de la documentation, pas un contrôle en direct d’un appareil.
| Vérification | Indication de la documentation Chrome | Conséquence pratique |
| Système et appareil | Windows 10 ou 11, macOS 13 ou ultérieur, Linux, ou ChromeOS à partir de Platform 16389.0.0 sur Chromebook Plus. Les API de modèles de fondation couvertes par cette page ne prennent pas en charge Android, iOS ni les appareils ChromeOS qui ne sont pas des Chromebook Plus. | Vérifiez que l’environnement visé correspond à l’une des configurations indiquées avant de faire de l’IA locale un passage obligatoire. |
| Espace disque | Au moins 22 Go libres sur le volume qui contient le profil Chrome. | Prévoyez cet espace pour le modèle local. |
| Matériel | Soit un GPU doté de plus de 4 Go de mémoire vidéo, soit un système avec un processeur d’au moins 4 cœurs et 16 Go de RAM. | Les deux configurations sont des options, pas des exigences à cumuler. |
La documentation mentionne aussi une connexion non limitée pour le téléchargement initial. Une fois le modèle téléchargé, son utilisation locale ne nécessite pas de connexion réseau.
Gérer disponibilité, annulation et textes longs
Avant de créer une session, appelez Summarizer.availability() avec les mêmes options que pour Summarizer.create(). Chrome décrit quatre états : available, downloadable, downloading et unavailable. Si la création exige un téléchargement, elle doit partir d’une interaction de l’utilisateur. L’application peut ainsi afficher l’état avant de proposer le lancement de la session. La documentation de l’API Summarizer détaille ces options et les exigences associées.
MDN documente un AbortSignal dans les options de Summarizer.create(). Si le signal est interrompu avant la résolution de la promesse, la création est annulée. S’il l’est après la création, l’instance est libérée et les appels Summarizer en cours ou ultérieurs rejettent une erreur AbortError. Transmettre le signal à la création permet donc aussi d’interrompre l’attente d’un téléchargement ou de l’ouverture de la session.
La capacité d’entrée ne se résume pas à un nombre universel de jetons : inputQuota dépend de l’implémentation. Une application peut consulter cette valeur et appeler measureInputUsage() pour mesurer un texte précis avant de le résumer. Pour un document trop long, Chrome recommande de le découper aux frontières de paragraphes ou de sujets, de résumer chaque partie, puis de résumer ces résumés, avec une nouvelle étape de découpage si nécessaire. Cette méthode peut réduire la précision et augmenter le temps de traitement; gardez le texte original accessible. Les indications de Chrome sur les textes longs décrivent cette approche.
Empêcher l’application d’une proposition périmée
Dans l’architecture décrite pour Trip Workbench, le backend vérifie l’accès au brouillon enregistré avant de préparer la proposition Gemini. Le coordinateur suit l’identité du brouillon et de la session, la révision enregistrée, les modifications locales et la version du brief. Il vérifie que la proposition correspond toujours à cet état lorsque la réponse arrive, puis vérifie de nouveau au moment de l’application.
Cette double vérification évite d’appliquer une réponse calculée à partir d’une ancienne version après une modification du brouillon ou du brief. La réponse JSON est analysée et validée par l’application; l’adaptateur décrit demande une réponse au format JSON, sans transmettre de schéma de sortie. Laisser le backend appliquer les changements par son chemin habituel conserve la validation qui accompagne cette mise à jour.
Montrer les changements avant de les enregistrer
Présentez les valeurs actuelles à côté des valeurs proposées, puis laissez l’utilisateur examiner chaque modification avant de l’appliquer. Les questions de clarification doivent rester visibles avec la proposition à laquelle elles se rapportent. Le résumé local reste un outil de lecture; il ne remplace pas le brief original utilisé pour demander une proposition Gemini.
Dans son article publié le 28 octobre 2026, Raju Dandigam rapporte huit contrôles du cycle de vie effectués avec un Summarizer simulé. Il décrit aussi trois problèmes observés dans son adaptateur candidat : une erreur de disponibilité échappait à la gestion des erreurs, une demande déjà annulée pouvait quand même créer une session et l’appel de création ne recevait pas le signal d’annulation. Ces contrôles portent sur le comportement de l’adaptateur simulé; ils ne mesurent ni la qualité du modèle natif, ni ses performances, ni les données réseau. L’extension React décrite n’avait pas été montée ni vérifiée par compilation de types.
La référence MDN de Summarizer.create() précise le comportement du signal d’annulation pendant et après la création de la session.
