Déplacez vos embeddings côté client : le guide pratique du CTO pour une recherche privée et rapide

Vous POSTez encore du texte utilisateur vers une API d’embeddings tierce. Ça passait en 2024. En 2026, c’est une solution de facilité, lente, coûteuse et de moins en moins conforme. La communauté vient de livrer un modèle d’embedding de 7 Mo qui s’exécute dans le navigateur (WASM). Les petits modèles locaux gagnent du terrain précisément là où le réseau est peu fiable. Le message est clair : une grande partie de la recherche sémantique et du prétraitement RAG a vocation à vivre côté client.

Ce n’est pas une posture idéologique. C’est une refonte pragmatique qui réduit vos coûts d’inférence, renforce votre posture de confidentialité et fait tomber la latence jusqu’à donner une sensation d’instantané. Si vous dirigez une équipe d’ingénierie dans une startup ou une scale‑up, vous avez besoin d’un cadre de décision clair pour savoir quand déplacer les embeddings à la périphérie et comment le déployer en sécurité.

Ce qui a changé depuis 2024

• Les modèles ont rétréci. Une nouvelle vague de tout petits modèles d’embedding (par exemple, un modèle WASM ~7 Mo mis en avant sur Hacker News) tourne désormais complètement hors ligne dans le navigateur. Vous n’avez plus besoin d’un téléchargement de 200–500 Mo pour obtenir des vecteurs acceptables.
• La maturité des runtimes. WebAssembly SIMD, les threads et WebGPU ont relevé les plafonds. Sur des portables milieu de gamme, générer l’embedding d’un paragraphe ne ressemble plus à une recompilation de Chromium.
• Le hors‑ligne redevient la norme. Vous l’avez vu avec les cartes FOSS hors ligne et la tendance plus large des « petits modèles pour réseaux peu fiables ». Les utilisateurs s’attendent à ce que les fonctionnalités clés fonctionnent Wi‑Fi coupé.
• La pression sur la confidentialité a augmenté. Identifiants d’appareil, télémétrie silencieuse et pistage inter‑applications font la une. Envoyer du texte brut vers des endpoints d’embedding est de plus en plus difficile à justifier auprès du juridique, des auditeurs et des clients entreprises.

Quand les embeddings côté client ont du sens

Tous les besoins de recherche ne se valent pas. Déplacez les bons 60 % côté client et laissez le reste tranquille.

Bons candidats

• Recherche et RAG à périmètre utilisateur. Notes, tickets, documents, conversations, extraits CRM, extraits de code. Pensez 1–50 k éléments par utilisateur, pas un corpus global.
• Données zero‑knowledge ou chiffrées de bout en bout. Si vos serveurs ne doivent pas lire le contenu, ne leur demandez pas de le vectoriser.
• Domaines sensibles en matière de confidentialité. Santé, finance, RH. Même avec une base légale, minimiser l’exposition est un argument fort en ventes grands comptes.
• UX sensible à la latence. Saisie prédictive, suggestions dès le collage, recherche « quick‑open ». Des gains sous 100 ms sont évidents pour les utilisateurs finaux.
• Connectivité intermittente. Travail de terrain, transports, avion, marchés émergents. « Fonctionne hors ligne » rapporte des points NPS.

Mauvais candidats (à garder côté serveur)

• Recherche globale inter‑utilisateurs/tenants. Agrégations, signaux de popularité et défenses anti‑abus nécessitent généralement une centralisation.
• Exigences d’audit central strictes. Si chaque requête et mise à jour d’index doivent être journalisées et reproductibles de façon centralisée, des flux 100 % client compliquent la vie.
• Très grands corpus par utilisateur. Si un utilisateur recherche régulièrement dans 1 M+ d’éléments, vous atteindrez les limites de stockage et de mémoire du navigateur.

Coûts et latence : les ordres de grandeur

Les CTO se soucient des dollars et des millisecondes. Voici le modèle mental rapide :

• Coût des API d’embeddings. Les principaux fournisseurs facturent à l’usage selon les tokens traités. Même à quelques dollars par million de tokens, indexer le contenu utilisateur finit par chiffrer. Un kilo‑octet correspond en moyenne à quelques centaines de tokens. Des millions d’éléments sur votre base représentent cinq à six chiffres par an, avant même les re‑embeddings lors des montées de version.
• Latence aller‑retour. Un appel réseau plus l’inférence chez le fournisseur, c’est typiquement 200–800 ms dans le meilleur des cas ; pire sur mobile. En local, l’embedding d’un court paragraphe s’exécute souvent en 10–70 ms sur un portable 2023–2025, plus long sur des téléphones d’entrée de gamme. Mais c’est prévisible et ça marche hors ligne.
• Empreinte de stockage sur l’appareil. Un vecteur 384‑D en int8 fait ~384 octets. Pour 10 k éléments, les vecteurs bruts pèsent ~3,8 Mo. Ajoutez un index d’approximate nearest neighbor (HNSW/IVF) et un peu de métadonnées et vous restez dans les dizaines de mégaoctets, acceptable pour les navigateurs modernes et les apps mobiles si vous gérez cache et quotas.
• Trafic sortant serveur. En cessant d’expédier du texte utilisateur à vectoriser, vous réduisez l’egress à chaque ingestion. Si vos clients sont hors de votre région, ce n’est pas négligeable.

Le gain ne tient pas qu’aux coûts unitaires. C’est que vous pouvez vous permettre de vectoriser à chaque frappe, chaque collage, chaque édition, car vous avez supprimé la taxe réseau.

Un cadre de décision applicable ce trimestre

1) Définir le périmètre contenu et la cible qualité

• Taille du corpus par utilisateur : 1 k, 10 k, 100 k, 1 M d’éléments. Les navigateurs et mobiles sont à l’aise jusqu’à quelques dizaines de milliers si vous êtes soigneux. À six chiffres, ça coince sans sharding.
• Longueur du texte : titres courts vs. corps multi‑paragraphes. Les petits modèles locaux performent mieux sur du court à moyen. Pour les longs docs, découpez en chunks côté client et recousez côté serveur si nécessaire.
• Barre de qualité : définissez recall@K et MRR sur un jeu de test représentatif. Si les vecteurs serveur donnent un recall@10 de 0,90, acceptez 0,85 en local avec un rerank côté client ? Décidez maintenant.

2) Choisir un modèle et un runtime selon la classe d’appareil

• Navigateurs : commencez avec un tout petit modèle d’embedding WASM (classe 7 Mo) pour une couverture universelle. Là où WebGPU est dispo, proposez en option un modèle plus grand (100–200 Mo) derrière un réglage « Haute précision » pour les power users.
• Android : ciblez NNAPI avec un modèle quantifié via TensorFlow Lite/ONNX ; la pile IA on‑device d’Android 17 est enfin fiable pour cette charge.
• iOS : livrez une version Core ML et utilisez le Neural Engine quand il est disponible ; repli CPU pour l’indexation en arrière‑plan.

Figez la dimension des vecteurs et le schéma de normalisation. Des dimensions incohérentes ou un mélange cosinus vs produit scalaire vous brûleront un sprint plus tard.

3) Choisir une stratégie d’indexation

• Petits corpus (<10 k éléments) : du brute force (cosinus/L2) sur des tableaux optimisés suffit. Utilisez Web Workers et SIMD.
• Corpus moyens (10 k–200 k) : HNSW (graphes hiérarchiques) ou IVF (inverted file) construits côté client ou livrés en shard préconstruit. hnswlib dispose de ports WASM ; mesurez la surconsommation mémoire.
• Hybride : le serveur fait un filtrage grossier (par métadonnées/temps), le client fait un rerank exact ou basé graphe sur quelques milliers de candidats. On préserve la confidentialité tout en gardant des requêtes vives.

4) Intégrer confidentialité et gouvernance dès le départ

• N’envoyez jamais de texte brut. La télémétrie doit être des timings et des compteurs, pas du contenu. Si vous avez besoin d’analytics de recherche, agrégerez sur l’appareil et remontez des synthèses avec confidentialité différentielle.
• Considérez les vecteurs comme sensibles. Les vecteurs peuvent fuiter de la sémantique. Chiffrez au repos sur l’appareil quand c’est possible ; avec un espace de noms par tenant. Si vous synchronisez des vecteurs, chiffrez de bout en bout ou faites une rotation lors des mises à niveau de modèle.
• Versionnage des modèles. Étiquetez chaque vecteur avec un model_id et un normalize_version. Ne mélangez jamais des vecteurs issus de modèles incompatibles. Faites avancer avec re‑vectorisation en arrière‑plan.

5) Fournir des fallbacks selon les capacités

• Détection de capacités : au démarrage, mesurez le calcul, la mémoire et le quota de stockage disponibles. Classez l’utilisateur en trois catégories : Local‑Fast, Local‑Okay ou Remote.
• Repli distant : gardez votre chemin d’embedding serveur actif pour les appareils d’entrée de gamme et les navigateurs verrouillés. Rendez‑le configurable par tenant.
• Dégradation progressive : si un appareil chauffe ou a peu de batterie, réduisez l’indexation en arrière‑plan et appuyez‑vous sur les filtres de métadonnées plus les derniers vecteurs connus.

Trois architectures de référence

1) Client seul, métadonnées synchronisées

À utiliser quand : positionnement zero‑knowledge, coffres de données personnels, exigences de confidentialité élevées.

• Tout le texte reste local. Le client calcule les vecteurs, construit un index ANN local et persiste dans IndexedDB/SQLite (mobile).
• Le serveur ne synchronise que des IDs d’éléments, des horodatages et d’éventuels blobs chiffrés. La recherche s’exécute entièrement sur l’appareil.
• Compromis : pas de recherche cross‑device sans synchro chiffrée de vecteurs ; téléchargement initial plus lourd pour le modèle.

2) Rerank hybride

À utiliser quand : corpus moyens, UX multi‑appareils, la conformité exige une trace côté serveur.

• Le client vectorise requêtes et éléments. Le serveur stocke des vecteurs chiffrés pour la synchro et la sélection grossière de candidats par requête (par ex. par projet/temps/propriétaire).
• Le client télécharge les vecteurs des N meilleurs candidats, effectue un rerank cosinus exact et affiche les résultats. Le texte brut n’a pas à quitter l’appareil.
• Compromis : vous devez opérer un service de synchro de vecteurs et bien chiffrer les métadonnées.

3) Filtrage serveur + embeddings côté client

À utiliser quand : vous avez une infra de recherche serveur existante que vous ne pouvez pas remplacer ce trimestre.

• Le serveur répond rapidement aux requêtes « métadonnées uniquement » (mots‑clés, filtres). Le client vectorise le contexte utilisateur et la requête, puis rerank localement le top N du serveur.
• Compromis : la qualité dépend du rappel du serveur ; un risque de fuite méta persiste si les filtres sont trop grossiers.

Pièges qualité et comment les éviter

• Décalage de domaine. De tout petits modèles généralistes peuvent sous‑performer sur le code, le médical ou le juridique. Envisagez une adaptation légère au domaine ou un dictionnaire de synonymes côté client.
• Stratégie de découpage. Pour les longs documents, la taille des chunks, le recouvrement et le boost des titres comptent plus que gratter 1 % de plus sur le modèle. Standardisez et testez.
• Dérive d’index. Les éditions en arrière‑plan doivent re‑vectoriser et mettre à jour le graphe ANN de façon atomique. Utilisez un write‑ahead log et des segments d’index versionnés.
• Hallucinations RAG. N’alimentez pas silencieusement votre générateur avec des résultats locaux de piètre qualité. Attachez la provenance et imposez des contrôles « answerable‑by‑context » avant les appels modèle.

Stockage et performance dans le navigateur

• Où stocker : IndexedDB pour des blobs structurés, OPFS (Origin Private File System) pour de gros shards binaires dans les navigateurs modernes basés sur Chromium, SQLite via WASM pour des performances prévisibles dans Electron/Tauri ou sur mobile.
• Compression : des vecteurs en int8 divisent la mémoire par 4 vs. float32 avec un impact mineur sur le rappel. La quantification produit peut apporter encore un facteur 2–4 si vous tolérez une petite perte d’exactitude.
• Mémoire ANN : HNSW charge ses arêtes en mémoire ; prévoyez 2–3× la taille des vecteurs en surcoût quand tout est en RAM. Limitez la concurrence et réchauffez des sous‑ensembles par espace de noms.
• Workers : déplacez toujours l’embedding et l’ANN dans des Web Workers. Gardez le thread UI sous le budget de 16 ms par frame.
• Thermiques : conditionnez l’indexation en arrière‑plan à la batterie et à la température CPU quand disponible. Sur mobile, indexez en charge ou juste après une activité.

Conformité, contrats et facilitation des ventes

Si vous vendez aux entreprises, les embeddings côté client sont un cadeau pour vos questionnaires de sécurité.

• Résidence des données : « Aucun contenu utilisateur ne quitte l’appareil pour la recherche » coupe court à la moitié des débats de résidence.
• DPIA et DSR : minimiser le traitement de données personnelles côté serveur réduit votre exposition dans les analyses d’impact et les demandes des personnes concernées.
• Risque fournisseur : vous retirez un fournisseur d’embeddings tiers de la liste des « sous‑traitants » pour cette fonctionnalité. Cela débloque l’achat plus vite.

Plan de déploiement : 30 / 60 / 90 jours

Jour 0–30 : Prouver

• Choisissez une fonctionnalité à périmètre utilisateur (ex. recherche d’espace de travail) et implémentez un chemin 100 % client derrière un feature flag.
• Intégrez un petit modèle WASM et mesurez le cold start, le temps par paragraphe, et recall@10 vs. votre référence serveur sur un jeu de 1 k requêtes.
• Définissez les bandes de capacités et implémentez un kill switch distant et un repli serveur.
>

Jour 31–60 : Mettre en production

• Ajoutez un ANN local pour les corpus de plus de 10 k éléments. Persistez dans OPFS/IndexedDB avec des segments versionnés.
• Instrumentez une télémétrie sans contenu : timings, codes d’erreur, version du modèle, bande de l’appareil. Routez‑la vers un collecteur soumis à des règles de confidentialité.
• Rédigez la note de sécurité : les vecteurs sont sensibles, les versions de modèle sont figées, chiffrement au repos quand supporté, et E2EE si vous synchronisez des vecteurs.

Jour 61–90 : Passer à l’échelle

• Déployez auprès de 25–50 % des utilisateurs sur appareils capables. Surveillez taux de crash, cold starts et deltas de rappel par tenant.
• Proposez un modèle optionnel « Haute précision » pour les desktops compatibles WebGPU. Gardez le petit modèle par défaut.
• Planifiez votre prochaine migration : rerank côté client pour la recherche globale, ou synthèse on‑device pour les meilleurs résultats.

Les arbitrages à assumer en réunion

• Précision : un modèle de 7 Mo n’égale pas un embedder de pointe de 500 Mo sur des domaines de niche. Mais avec un bon découpage et un rerank, les utilisateurs peuvent ne pas voir la différence. Testez sur vos données, pas sur celles de Twitter.
• Complexité : vous introduisez une seconde pile de recherche et une détection de capacités. Cachez‑la derrière une fine abstraction et soyez obsessionnels sur le versionnage de modèles.
• Quotas de stockage : les navigateurs se sont améliorés, mais quotas et politiques d’éviction varient. Concevez des index partiels et des reconstructions rapides.
• Diversité des appareils : attendez‑vous à un facteur 10 sur le débit. Votre produit doit rester agréable sur un Android de deux ans comme sur un Mac M‑series récent.

Pourquoi c’est important pour les équipes nearshore (et votre roadmap)

Les embeddings côté client permettent aux équipes distribuées de livrer une vraie vitesse perceptible sans changements d’infra coûteux. Bonus pour les organisations produit US‑LATAM : bâtir des pipelines Rust‑vers‑WASM robustes, des index on‑device et des couches de recherche hybrides, c’est exactement le genre de travail systèmes dans lequel excellent des ingénieurs nearshore seniors, avec 6–8 heures de recouvrement pour itérer serré. Vous passerez du temps sur l’UX produit plutôt que sur un énième cluster de vecteurs.

L’essentiel

Vous n’avez pas à déplacer toute la recherche côté client. Mais si vous n’en déplacez aucune, vous payez plus que nécessaire, vous attendez plus que vos utilisateurs ne le tolèrent, et vous portez plus de risque de confidentialité que votre équipe sales ne peut défendre. Commencez par une fonctionnalité à périmètre utilisateur. Livrez un petit modèle. Mesurez. Puis étendez.

À retenir

• De petits modèles d’embedding tournent désormais dans le navigateur ; un modèle WASM ~7 Mo suffit pour beaucoup de recherches à périmètre utilisateur.
• Déplacez les embeddings côté client pour les fonctionnalités à périmètre utilisateur, sensibles à la confidentialité et critiques en latence ; gardez la recherche globale côté serveur.
• Comptez ~384 octets par élément en int8 ; 10 k éléments tiennent confortablement sur l’appareil avec un index ANN modeste.
• Étiquetez chaque vecteur avec une version de modèle ; ne mélangez jamais des embeddings incompatibles ; chiffrez les vecteurs au repos et pendant la synchro.
• Utilisez la détection de capacités pour segmenter les appareils et gardez un repli serveur ; instrumentez une télémétrie sans contenu.
• Les architectures hybrides (filtrage serveur, rerank client) préservent la confidentialité tout en évitant les falaises de qualité.
• Planifiez un déploiement en 90 jours : prouvez, mettez en production, puis passez à l’échelle avec des modèles à plus haute précision sur le matériel adéquat.