Ternlight : la recherche sémantique tourne dans votre navigateur, sans API

Le 7 juillet 2026, une démo mise en ligne sur ternlight-demo.vercel.app illustre un cas d'usage encore rare : un modèle d'embeddings de 7 Mo qui tourne entièrement dans votre navigateur, sans serveur, sans clé API, et sans qu'aucune donnée ne quitte votre machine. Vous tapez une question en langage naturel, la démo retrouve en quelques millisecondes le passage pertinent dans la documentation React, le tout calculé sur votre propre CPU.

Pour ceux qui découvrent le sujet : un modèle d'embeddings transforme un texte (une question, un paragraphe de documentation) en un vecteur numérique. Deux textes proches en sens auront des vecteurs proches dans cet espace. C'est la brique de base de la recherche sémantique, des systèmes RAG (retrieval augmented generation) et de la plupart des moteurs de recherche interne modernes. Le problème, jusqu'ici : ces modèles tournent presque toujours côté serveur, via une API payante ou une infrastructure GPU dédiée. Ternlight propose une alternative : faire tenir ce calcul dans quelques mégaoctets, directement dans l'onglet du navigateur.

Ce qui rend ce modèle capable de tourner dans un navigateur

La démo affiche noir sur blanc l'architecture du modèle testé : une couche d'embedding suivie de plusieurs couches de transformer, avec des poids linéaires ternaires, une technique connue sous le nom de BitLinear. Concrètement, au lieu de stocker chaque poids sur 16 ou 32 bits en virgule flottante, le modèle ne conserve que trois valeurs possibles par poids. Le gain se répercute directement sur la taille du bundle final, annoncée à 7 Mo, assez léger pour être chargé comme n'importe quel asset JavaScript, sans installation ni dépendance serveur.

Le package qui embarque ce moteur s'appelle @ternlight/mini. Une fois le moteur initialisé (l'indicateur « Loading the engine… » disparaît), chaque appel à la fonction embed() renvoie un vecteur en quelques millisecondes, une latence mesurée et affichée en direct dans l'interface pour un appel unique. Le tableau de bord de la démo affiche également le nombre de chunks déjà vectorisés et le débit en emb/sec, calculé en temps réel sur le CPU de la machine qui exécute la page, pas sur un serveur distant. Après le premier chargement, tout est mis en cache localement : la démo revendique zéro requête réseau pour les utilisations suivantes.

La démo en pratique : chercher dans la documentation React sans quitter la page

Le cas d'usage choisi pour illustrer le moteur est parlant : une base de connaissance constituée d'extraits de la documentation React, interrogeable en langage naturel. Les exemples de requêtes proposés dans l'interface donnent le ton : « share state across components », « skip a re-render », « run code after render », « avoid prop drilling » ou encore « form input value ». Ce ne sont pas des recherches par mot-clé : ce sont des questions formulées comme le ferait un développeur, que le moteur doit rapprocher sémantiquement du passage de documentation le plus pertinent, même si aucun mot ne correspond exactement.

C'est exactement le scénario qu'on retrouve dans un moteur de recherche interne d'entreprise, un chatbot de support, ou un plugin de documentation technique. La différence avec une solution basée sur une API cloud : ici, la requête ne sort jamais du navigateur.

Pourquoi ça compte pour les devs et les PME françaises

Deux arguments reviennent systématiquement dès qu'on parle d'embeddings côté client plutôt que via une API.

Le coût. Un appel à une API d'embeddings cloud se facture à la requête ou au volume de tokens traités. Sur un moteur de recherche interne consulté plusieurs milliers de fois par jour, la facture grimpe vite. Avec un modèle exécuté dans le navigateur de l'utilisateur, ce coût de calcul disparaît purement et simplement : c'est le CPU du visiteur qui travaille, pas votre infrastructure.

La confidentialité. Pour une PME qui manipule des données clients, des documents internes ou des échanges couverts par un secret professionnel, envoyer chaque requête de recherche à une API tierce pose une vraie question de conformité RGPD. Un modèle qui tourne intégralement en local, sans requête réseau après le premier chargement, supprime ce point de friction : aucune donnée ne transite par un tiers, aucun sous-traitant supplémentaire à ajouter au registre des traitements.

Comment l'essayer

Le package est distribué sous licence MIT via @ternlight/mini. Pour un premier test, la démo elle-même reste le point d'entrée le plus rapide : elle tourne directement dans l'onglet, sans compte à créer ni clé à configurer. Pour l'intégrer dans un projet, la logique reste la même que pour n'importe quelle librairie d'embeddings côté client : on initialise le moteur une fois (chargement du modèle et compilation WebAssembly), puis on appelle embed(texte) pour chaque chunk à vectoriser, côté ingestion comme côté requête utilisateur.

Notre lecture chez CZSyn

Ce type de projet confirme une bascule qu'on voit arriver depuis un moment sur les briques IA : tout ne doit pas passer par une API cloud. Pour de la recherche sémantique sur un volume raisonnable (une documentation produit, une FAQ, un espace client), faire tourner l'embedding directement dans le navigateur change l'équation économique et réglementaire, sans sacrifier l'expérience utilisateur puisque le calcul se fait en quelques millisecondes.

Notre point de vigilance reste la qualité des embeddings sur des corpus complexes ou multilingues : un modèle de 7 Mo fait nécessairement des compromis par rapport à des modèles serveur bien plus lourds. Pour une PME qui veut ajouter une recherche interne intelligente sur sa documentation ou son support client sans exploser son budget API ni ses obligations RGPD, ce type d'approche mérite clairement un test avant d'investir dans une architecture RAG plus lourde.

Sources primaires

• Démo officielle Ternlight, ternlight-demo.vercel.app.
• Package npm officiel, @ternlight/mini.