Démarrage rapide de Vane (Perplexica 2.0) avec Ollama et llama.cpp
Recherche IA auto-hébergée avec des LLM locaux
Vane est l’une des entrées les plus pragmatiques dans le domaine de la « recherche IA avec citations » : un moteur de réponse auto-hébergé qui combine la récupération web en direct avec des LLM locaux ou cloud, tout en gardant toute la pile sous votre contrôle.
Le projet était à l’origine connu sous le nom de Perplexica, et le renommage en Vane n’est pas cosmétique : il reflète à la fois un nettoyage de la marque et un déplacement progressif de la perception d’« un clone » vers celle d’un moteur de réponse général.

Étant donné que la partie utile de la pile n’est pas seulement l’interface utilisateur mais aussi l’endroit où résident l’inférence et les données, ce comparatif de l’hébergement LLM en 2026 rassemble les configurations locales, auto-hébergées et cloud afin que vous puissiez positionner Vane à côté d’autres temps d’exécution et choix de déploiement.
Cet article se concentre sur les aspects qui intéressent réellement les lecteurs techniques : le fonctionnement du système, un démarrage rapide minimal avec Docker, et la façon de l’exécuter avec une inférence locale via Ollama et llama.cpp (directement ou via LM Studio). En cours de route, chaque sujet de FAQ est répondu dans le contexte, sans être relégué en bas de page.
Qu’est-ce que Vane et comment fonctionnent les moteurs de recherche IA
De manière générale, Vane est une application Next.js qui combine une interface de chat avec la recherche et les citations. Les éléments architecturaux principaux sont exactement ce à quoi on s’attend d’un moteur de recherche IA moderne : des routes API pour le chat et la recherche, une orchestration qui décide quand effectuer une récupération, et un générateur de réponse conscient des citations.
Lorsque vous soumettez une requête dans l’interface, Vane appelle POST /api/chat. Internement, le flux de travail est délibérément structuré :
- Il classe d’abord la question pour décider si une recherche est nécessaire et quels assistants doivent s’exécuter.
- Il exécute la recherche et les widgets en parallèle.
- Il génère la réponse finale et inclut les citations.
Cette étiquette « moteur de recherche IA » est importante, car il ne s’agit pas seulement d’un frontend de chat. La différence clé est la génération augmentée par récupération : au lieu de dépendre uniquement des paramètres du LLM, Vane récupère un contexte externe (résultats web et éventuellement des fichiers uploadés par l’utilisateur) et utilise ces éléments comme substrat d’ancrage pour la réponse finale. Sa documentation mentionne explicitement la recherche web et la « recherche dans les fichiers uploadés par l’utilisateur » comme faisant partie de la recherche, avec l’utilisation d’embeddings pour la recherche sémantique sur les uploads.
Les citations ne sont pas une réflexion après coup. Vane invite le modèle à citer les références qu’il a utilisées, puis l’interface affiche ces citations à côté de la réponse. En pratique, c’est ce qui sépare une recherche IA « utile » d’un générateur d’hallucinations confiant qui possède simplement un bouton de recherche.
SearxNG se trouve sous la couche de récupération web pour la plupart des configurations. SearxNG est un méta-moteur de recherche gratuit qui agrège les résultats de nombreux services de recherche et, par conception, ne suit ni ne profile les utilisateurs. C’est une philosophie fondamentalement différente des API de recherche payantes, qui vous offrent généralement un index unique de fournisseur et un contrat de données commercial.
Historique de Perplexica à Vane et renommage
Perplexica a commencé comme un moteur de réponse open-source et auto-hébergeable inspiré de Perplexity AI. Plusieurs guides publics décrivent toujours le projet comme « anciennement connu sous le nom de Perplexica » et considèrent Vane comme la continuation plutôt que comme un fork hostile.
Le renommage a été implémenté directement dans le dépôt amont. Dans l’historique des commits de la branche master, le commit intitulé feat(app): rename to 'vane' apparaît le 9 mars 2026 (SHA 39c0f19).
Le « comment » est plus intéressant que le titre. Ce commit de renommage n’est pas juste un ajustement de README : il met à jour les noms des images Docker de itzcrazykns1337/perplexica à itzcrazykns1337/vane, ajuste les chemins du système de fichiers des conteneurs de /home/perplexica à /home/vane, et met à jour le texte du projet et les assets en conséquence.
Si vous vous demandez pourquoi les projets IA open-source se renonment, Vane est un exemple classique des facteurs habituels :
- La proximité du nom avec une marque commerciale crée de la confusion (et parfois un risque juridique).
- La portée du projet dépasse le cadre original (de « clone » à « moteur de réponse »).
- Les artefacts de distribution ont besoin d’une identité cohérente (images Docker, documentation, étiquettes UI).
De plus, l’écosystème ne change pas de nom du jour au lendemain. Docker Hub affiche toujours les deux dépôts sous le compte du mainteneur, y compris itzcrazykns1337/vane et itzcrazykns1337/perplexica. Vous verrez donc toujours d’anciens articles de blog, des fichiers de composition et des références de registre utilisant la nomenclature Perplexica, même après le rebranding du dépôt.
Démarrage rapide Docker et configuration de base
Le README officiel de Vane est rafraîchissant de direct : exécutez un seul conteneur et vous obtenez Vane ainsi qu’un backend de recherche SearxNG inclus. Le démarrage Docker minimal ressemble à ceci.
docker run -d -p 3000:3000 -v vane-data:/home/vane/data --name vane itzcrazykns1337/vane:latest
Cette image est positionnée comme la voie « ça marche tout de suite » car elle inclut déjà SearxNG, vous n’avez donc pas besoin d’un backend de recherche externe juste pour tester l’interface. La configuration se fait dans l’écran de configuration après avoir ouvert l’interface web à http://localhost:3000.
Si vous exécutez déjà SearxNG (courant dans les homelabs), l’image « slim » de Vane s’attend à ce que vous la pointiez vers une instance SearxNG externe en utilisant SEARXNG_API_URL. Le README mentionne également deux attentes pratiques concernant les paramètres SearxNG : la sortie JSON activée et le moteur Wolfram Alpha activé.
docker run -d -p 3000:3000 \
-e SEARXNG_API_URL=http://your-searxng-url:8080 \
-v vane-data:/home/vane/data \
--name vane \
itzcrazykns1337/vane:slim-latest
Le maintien de Vane à jour est également documenté dans le dépôt. Le flux de travail de mise à jour officiel consiste essentiellement à récupérer la dernière image et à redémarrer avec le même volume, ce qui préserve les paramètres.
docker pull itzcrazykns1337/vane:latest
docker stop vane
docker rm vane
docker run -d -p 3000:3000 -v vane-data:/home/vane/data --name vane itzcrazykns1337/vane:latest
Une fois qu’il est en cours d’exécution, Vane peut être utilisé comme une raccourci de moteur de recherche navigateur en pointant un moteur personnalisé vers http://localhost:3000/?q=%s. C’est une petite fonctionnalité avec un impact disproportionné si vous voulez que la « recherche IA » ressemble à une recherche plutôt qu’à une application à visiter.
Pour l’automatisation et l’intégration, Vane expose une API. La documentation décrit GET /api/providers pour découvrir les fournisseurs et modèles configurés, et POST /api/search pour exécuter une recherche avec un modèle de chat choisi, un modèle d’embedding, des sources et un optimizationMode (vitesse, équilibré, qualité).
Configuration locale LLM avec Ollama
Vane prend en charge les LLM locaux via Ollama et les fournisseurs cloud dans la même interface, ce qui est la bonne abstraction si vous pensez en termes de « connexions » et de « modèles » plutôt qu’en « fournisseurs ».
Le problème le plus courant n’est pas le choix du modèle, mais le réseau. Lorsque Vane s’exécute dans Docker et Ollama sur l’hôte, « localhost » ne signifie pas ce que vous croyez qu’il signifie depuis l’intérieur du conteneur. Vane documente les URL de base spécifiques au système d’exploitation pour se connecter à Ollama depuis un conteneur.
Pièges de connectivité avec Docker
La section de dépannage de Vane recommande explicitement :
- Windows et macOS :
http://host.docker.internal:11434 - Linux :
http://<private_ip_of_host>:11434
Pour Linux, Vane note également qu’Ollama peut être lié par défaut à 127.0.0.1 et doit être exposé. Le README suggère de définir OLLAMA_HOST=0.0.0.0:11434 dans le service systemd et de redémarrer le service.
Cela correspond aux propres variables d’environnement serve d’Ollama, où OLLAMA_HOST contrôle l’adresse de liaison du serveur et est par défaut 127.0.0.1:11434.
Garder les modèles chauds et choisir des modèles
Si vous exécutez une inférence locale, vous ressentirez les démarrages à froid. Ollama dispose de deux mécanismes liés pour garder les modèles chargés :
OLLAMA_KEEP_ALIVEen tant que paramètre serveur.keep_aliveen tant que paramètre par requête pour/api/generateet/api/chat, qui remplace la valeur par défaut du serveur.
Vane a ajouté sa propre prise en charge de keep_alive pour les modèles Ollama (afin que l’application puisse influencer la durée pendant laquelle un modèle reste en mémoire). Cette fonctionnalité apparaît dans les notes de version v1.10.0 de Vane.
La sélection de modèles est la partie qui devient surchargée sur Internet. Pour un travail de style Vane, la séparation la plus pratique est :
- Un modèle de chat ajusté pour les instructions (pour la synthèse et la résumés).
- Un modèle d’embedding pour la recherche de similarité sur les uploads et le texte récupéré. La documentation API de Vane montre que la requête de recherche choisit explicitement à la fois un modèle de chat et un modèle d’embedding.
Ollama prend lui-même en charge les workflows d’embeddings, et même la documentation CLI inclut un exemple utilisant nomic-embed-text pour les embeddings.
C’est aussi la réponse à la FAQ sur l’exécution d’une recherche IA localement sans API cloud : avec Vane dans Docker, SearxNG local, et Ollama sur votre matériel, vous pouvez garder à la fois vos requêtes de recherche et vos documents privés uploadés dans votre propre périmètre réseau. (Si vous décidez de vous connecter à un fournisseur cloud à la place, le chemin des données change évidemment.)
Configuration locale LLM avec llama.cpp
Il existe deux façons réalistes d’associer Vane à llama.cpp :
- Utiliser LM Studio comme couche serveur (et laisser Vane communiquer avec lui).
- Exécuter son propre serveur HTTP de llama.cpp (llama-server) et se connecter via un endpoint compatible OpenAI.
Vane prend explicitement en charge les « serveurs locaux compatibles avec l’API OpenAI » et mentionne les exigences habituelles : se lier à 0.0.0.0 plutôt qu’à 127.0.0.1, utiliser le bon port, définir un nom de modèle qui existe sur le serveur, et ne pas laisser le champ de clé API vide même si le serveur n’applique pas d’authentification.
LM Studio est pertinent ici car il se situe au-dessus des backends locaux (souvent llama.cpp) tout en exposant une API compatible OpenAI. Vane v1.12.1 note spécifiquement l’ajout d’un fournisseur LM Studio.
La documentation de LM Studio liste les endpoints OpenAI compatibles pris en charge et montre un exemple d’URL de base utilisant http://localhost:1234/v1 (en supposant le port 1234). Cela est important car, du point de vue de Vane, c’est « juste un autre serveur de style OpenAI ».
Si vous préférez exécuter llama.cpp directement, le serveur HTTP officiel de llama.cpp prend en charge les complétions de chat, les réponses et les routes d’embeddings compatibles avec l’API OpenAI, ainsi qu’une longue liste de fonctionnalités serveur (regroupement, surveillance, utilisation d’outils).
Même si vous ne mémorisez pas les drapeaux, les parties importantes sont :
- Le serveur existe et est activement documenté.
- La surface API est suffisamment compatible pour que les clients de style OpenAI puissent communiquer avec lui, ce dont Vane a exactement besoin pour son schéma de connexion « compatible OpenAI ».
Ce qui a été livré récemment et ce qui change maintenant
Si vous voulez comprendre ce que Vane est devenu au cours de la dernière année, suivez les notes de version et l’historique de la branche master plutôt que le buzz.
À la date du 10 avril 2026 (Australie/Melbourne), la dernière version GitHub taggée visible sur la page des releases est la v1.12.1 (31 décembre 2025). Cette version note l’ajout d’un fournisseur LM Studio et des corrections autour de l’appel de fonctions avec des fournisseurs compatibles OpenAI et de l’analyse JSON.
Les versions précédentes décrivent les changements plus importants :
- v1.11.0 (21 octobre 2025) a introduit un nouvel assistant de configuration et un système de configuration repensé, ainsi qu’un support plus large des fournisseurs et une voie d’installation Docker en une seule commande. Elle mentionne également la récupération dynamique de modèles et diverses améliorations de l’expérience utilisateur et développeur.
- v1.12.0 (27 décembre 2025) est un reset architectural : il supprime LangChain en faveur d’une implémentation personnalisée pour le streaming, la génération et les comportements spécifiques aux fournisseurs. Il renomme également les « fournisseurs » en « connexions », ajoute des améliorations de rendu UI et de code, et déplace plus de capacités dans les propres abstractions du projet (y compris une amélioration de l’appel de fonctions par rapport aux approches d’analyse précédentes).
- Plus tôt, v1.10.0 (20 mars 2025) a ajouté des uploads de fichiers (PDF, TXT, DOCX), ajouté un paramètre Ollama keep_alive, ajouté une classe d’agent de méta-recherche pour améliorer la maintenabilité et la création de modes focus, et ajouté une fonctionnalité de recherche d’images et de vidéos automatique.
Côté marque, le renommage en Vane a été effectué le 9 mars 2026 dans master (feat(app): rename to 'vane'), mettant à jour à la fois la nomenclature de la base de code et les artefacts Docker.
Et le projet n’a pas cessé d’évoluer après la release de décembre 2025. Les commits de la branche master des 8-9 avril 2026 incluent des travaux décrits comme « mode de recherche approfondie mis à jour, gestion de contexte » et de nouveaux changements liés à l’exécution de recherche et au scraping. En d’autres termes, la partie « moteur de recherche IA » est toujours activement itérée, pas figée derrière les tags de version.