Pourquoi nous avons rapatrié la recherche, les tags et les recommandations hors du cloud

La plupart des extensions de navigateur « dopées à l'IA » envoient l'intégralité des données vers un serveur — y compris les fonctions qui n'ont absolument aucun rapport avec l'IA. Recherche, normalisation de tags, détection de contenus similaires : ce sont des techniques éprouvées depuis des décennies. Elles n'exigent aucun modèle de langage et n'ont absolument pas besoin d'un aller-retour réseau. Nous avons passé au crible chaque fonctionnalité d'AI Summary Helper en nous posant une question systématique : cette fonction a-t-elle réellement besoin du cloud, ou l'utilisons-nous par défaut par simple facilité architecturale ?

La plupart n'en avaient aucunement besoin.

Ce qui s'exécute désormais directement sur votre appareil

Recherche. À l'origine, l'extension effectuait des correspondances uniquement sur le titre de l'article et ses tags — une méthode rapide, mais aveugle au corps du texte. Plutôt que de scanner le texte intégral en force brute à chaque frappe au clavier ou d'envoyer chaque requête à un serveur, nous avons conçu un index TF-IDF compact à partir de vos propres archives enregistrées. Les champs légers — titre, tags — sont vérifiés en premier et instantanément, comme auparavant. Les requêtes plus longues interrogent l'index, généré une seule fois par session et mis à jour de manière incrémentale, sans réanalyse à chaque frappe.

Détection des doublons. Avant la finalisation d'un enregistrement, une vérification par paliers s'exécute : d'abord une correspondance exacte sur l'URL normalisée (opération légère, O(1)), puis une similarité de titre sur la poignée de candidats retenus, et seulement ensuite — pour les rares cas restants — une comparaison complète de similarité cosinus via TF-IDF. La majorité des enregistrements n'atteint jamais le palier le plus coûteux, les filtres initiaux suffisant à trancher.

Normalisation des tags. Avec le temps, les tags dérivent : « ML », « Machine Learning » et « machine-learning » ont le même sens pour un humain, mais pas pour un filtre. Une table d'alias intercepte les cas évidents ; une fusion floue basée sur la distance d'édition sur l'ensemble du vocabulaire de tags traite le reste, en retenant l'orthographe que vous utilisez le plus fréquemment comme forme canonique, sans vous imposer une norme arbitraire.

Lisibilité et tonalité. Le score de lisibilité Flesch–Kincaid relève du simple calcul arithmétique sur le nombre de phrases et de syllabes — aucun modèle n'est requis. L'analyse de sentiment repose sur une liste de mots AFINN intégrée avec vérification de négation sur les deux tokens précédents. Aucune de ces opérations n'avait besoin de quitter votre navigateur.

« Articles similaires » et Digest. Ces deux fonctionnalités réutilisent exactement les mêmes vecteurs TF-IDF déjà calculés pour la recherche. Il aurait été facile de concevoir trois systèmes de similarité distincts pour trois fonctions différentes. Mais mutualiser un index unique pour la recherche, les recommandations et la sélection du digest permet de maintenir le système léger et d'optimiser ces trois fonctionnalités d'un seul coup à chaque amélioration de l'index.

Ce que nous avons délibérément conservé dans le cloud

L'étape de résumé proprement dite — celle qui nécessite réellement un modèle de langage — exige toujours un appel réseau. Avec la taille actuelle des modèles locaux, c'est incontournable si vous visez la qualité d'un modèle cloud de premier ordre. Vous pouvez renseigner votre propre clé d'API pour cette étape (OpenAI, Gemini, Mistral, DeepSeek), ou pointer l'extension vers une instance locale Ollama pour vous affranchir totalement du réseau. C'est le seul aspect où l'exécution locale n'est pas activée par défaut : elle reste optionnelle, car le compromis est réel — un modèle local est plus lent et moins précis qu'un modèle hébergé, et nous ne souhaitions pas prétendre le contraire.

Pourquoi cela va bien au-delà de la simple protection des données

L'enjeu de confidentialité est bien réel : une extension disposant de permissions d'accès étendues qui transmet le contenu des pages à un serveur pour des tâches qui s'en passent pose une vraie question de confiance, pas seulement d'image. Mais la raison la plus pragmatique reste la rigueur d'ingénierie. Une recherche TF-IDF n'a pas besoin de 200 ms de latence réseau. La déduplication de tags ne justifie aucune facture d'API. Choisir l'outil adapté au besoin exact, au lieu de tout router systématiquement vers le cloud, donne un résultat plus rapide, plus économique et fonctionnel hors ligne — la protection de vos données en découle naturellement, et non l'inverse.