Démarrage rapide de Vane (Perplexica 2.0) avec Ollama et llama.cpp
Recherche d’IA auto-hébergée avec des LLM locaux
Vane est l’une des entrées les plus pragmatiques de l’espace de la « recherche IA avec citations » : un moteur de réponses auto-hébergé qui mêle 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 seulement cosmétique : il reflète à la fois une rationalisation de la marque et un changement constant du positionnement, passant d’un « clone » à un moteur de réponse généraliste.

Étant donné que la partie utile de la pile ne se limite pas à l’interface utilisateur mais inclut également l’emplacement de l’inférence et des données, cette comparaison de l’hébergement de LLM en 2026 rassemble les configurations locales, auto-hébergées et cloud pour que vous puissiez comparer Vane à d’autres environnements 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 Docker minimal, et comment l’exécuter avec une inférence locale via Ollama et llama.cpp (directement ou via LM Studio). Au fil de l’explication, chaque sujet de la FAQ est répondu en contexte, et non laissé pour la fin.
Vane est délibérément un moteur de réponse et non un système de recherche récursif, et il est utile d’être précis quant à cette distinction. Systèmes de recherche approfondie auto-hébergés : 12 outils comparés place Vane face à douze architectures de recherche auto-hébergées et explique pourquoi « exécuter plusieurs recherches » n’est pas la même chose que « effectuer une recherche approfondie (Deep Research) ».
Ce qu’est Vane et comment fonctionnent les moteurs de recherche IA
À un niveau élevé, Vane est une application Next.js qui combine une interface de chat avec la recherche et les citations. Les éléments architecturaux fondamentaux sont exactement ceux que l’on attend d’un moteur de recherche IA moderne : des routes API pour le chat et la recherche, une orchestration qui décide quand effectuer la récupération d’informations, et un rédacteur de réponses conscient des citations.
Lorsque vous soumettez une requête dans l’interface, Vane appelle POST /api/chat. Intérieurement, le flux de travail est structuré de manière délibérée :
- Il classe d’abord la question pour déterminer si une recherche est nécessaire et quels outils auxiliaires 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 de « moteur de recherche IA » est importante, car il ne s’agit pas simplement d’un frontend de chat. La différence clé réside dans la génération augmentée par récupération (RAG) : au lieu de se fier purement aux 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 ce matériau comme base de justification pour la réponse finale. Sa documentation mentionne explicitement la recherche web et la « recherche dans les fichiers uploadés par l’utilisateur » comme partie intégrante de la recherche, avec l’utilisation d’embeddings pour la recherche sémantique sur les uploads.
Les citations ne sont pas une après-pensée. Vane demande au modèle de citer les références utilisées, puis l’interface affiche ces citations à côté de la réponse. En pratique, c’est ce qui distingue une recherche IA « utile » d’un générateur d’hallucinations confiant qui se trouve juste avoir un bouton de recherche.
SearxNG se situe sous la couche de récupération web pour la plupart des configurations. SearxNG est un moteur de méta-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 d’un seul fournisseur et un contrat de données commercial.
Historique et renommage de Perplexica à Vane
Perplexica a démarré comme un moteur de réponse open source, auto-hébergeable, inspiré de Perplexity AI. Plusieurs guides publics décrivent encore le projet comme « anciennement connu sous le nom de Perplexica » et considèrent Vane comme la continuation plutôt que comme un fork hostil.
Le renommage a été implémenté directement dans le dépôt upstream. 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 du README : il met à jour les noms des images Docker de itzcrazykns1337/perplexica à itzcrazykns1337/vane, ajuste les chemins du système de fichiers du conteneur de /home/perplexica à /home/vane, et met à jour le texte et les ressources du projet en conséquence.
Si vous vous demandez pourquoi les projets IA open source sont renommés, Vane est un exemple type des moteurs habituels :
- La proximité du nom avec une marque commerciale crée de la confusion (et parfois un risque légal).
- Le périmètre du projet s’élargit au-delà du cadrage initial (de « clone » à « moteur de réponse »).
- Les artefacts de distribution ont besoin d’une identité cohérente (images Docker, documentation, libellés de l’interface).
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 encore des 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 étonnamment direct : exécutez un seul conteneur et vous obtenez Vane ainsi qu’un backend de recherche SearxNG intégré. Le démarrage rapide 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 le chemin « qui fonctionne immédiatement » car elle inclut déjà SearxNG, vous n’avez donc pas besoin d’un backend de recherche externe juste pour tester l’interface utilisateur. 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 suppose que vous la pointez 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
Maintenir Vane à jour est également documenté dans le dépôt. Le flux de mise à jour officiel consiste essentiellement à tirer l’image la plus récente 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 que cela fonctionne, Vane peut être utilisé comme un raccourci de moteur de recherche dans le navigateur en pointant un moteur personnalisé vers http://localhost:3000/?q=%s. C’est une petite fonctionnalité avec un impact disproportionné si vous souhaitez que la « recherche IA » se ressente comme une recherche plutôt que comme une application à laquelle on accède.
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’embeddings, des sources et un optimizationMode (vitesse, équilibré, qualité).
Configuration de LLM local avec Ollama
Vane prend en charge les LLM locaux via Ollama et les fournisseurs cloud dans la même interface, ce qui est l’abstraction adéquate si vous pensez en termes de « connexions » et de « modèles » plutôt que de « fournisseurs ».
L’Aide-mémoire Ollama liste les commandes CLI courantes et les vérifications API rapides qui se marient bien avec le choix des modèles et la vérification d’Ollama avant de traquer des problèmes de réseau Docker.
Le problème le plus courant n’est pas le choix du modèle, c’est le réseau. Lorsque Vane s’exécute dans Docker et Ollama s’exécute sur l’hôte, « localhost » ne signifie pas ce que vous pensez à l’intérieur du conteneur. Vane documente des 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 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 au chaud et choisir les modèles
Si vous exécutez une inférence locale, vous ressentirez les démarrages à froid. Ollama a 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 écrase le paramètre par défaut du serveur.
Vane a ajouté son propre support 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 sortie de la version 1.10.0 de Vane.
La sélection des modèles est la partie qui devient trop compliquée sur Internet. Pour un travail de type Vane, le découpage le plus pratique est :
- Un modèle de chat ajusté pour les instructions (pour la synthèse et la résumation).
- Un modèle d’embeddings pour la recherche de similarité sur les uploads et le texte récupéré. La documentation de l’API de Vane montre que la requête de recherche choisit explicitement à la fois un modèle de chat et un modèle d’embeddings.
Ollama lui-même prend en charge les workflows d’embeddings, et même la documentation de la CLI inclut un exemple utilisant nomic-embed-text pour les embeddings.
C’est aussi la réponse à la FAQ concernant l’exécution de la 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 uploads de documents privés au sein de votre propre périmètre réseau. (Si vous décidez de vous connecter à un fournisseur cloud à la place, la connexion change évidemment le chemin de données.)
Configuration de LLM local 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).
- Exécuter le propre serveur HTTP de llama.cpp (llama-server) et se connecter via un point de terminaison compatible OpenAI.
Vane prend explicitement en charge les « Serveurs locaux compatibles API OpenAI » et mentionne les exigences habituelles : lier à 0.0.0.0 plutôt qu’à 127.0.0.1, utiliser le port correct, 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 points de terminaison compatibles OpenAI pris en charge et montre un exemple d’URL de base utilisant http://localhost:1234/v1 (en supposant le port 1234). C’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, [Démarrage rapide llama.cpp avec CLI et Serveur](https://www.glukhov.org/fr/llm-hosting/llama-cpp/ “Installez llama.cpp, exécutez des modèles GGUF avec llama-cli, et servez des API compatibles OpenAI en utilisant llama-server. Principales options, exemples et conseils d’ajustement avec un aide-mémoire de commandes court”}) couvre l’installation, llama-cli, et llama-server. Le serveur HTTP officiel de llama.cpp prend en charge les complétions de chat compatibles API OpenAI, les réponses et les routes d’embeddings, ainsi qu’une longue liste de fonctionnalités serveur (mise en lot, monitoring, utilisation d’outils).
Même si vous ne mémorisez pas les options, les parties importantes sont :
- Le serveur existe et est activement documenté.
- La surface de l’API est suffisamment compatible pour que les clients de style OpenAI puissent communiquer avec, ce dont Vane a besoin pour son modèle de connexion « compatible OpenAI ».
Ce qui a été publié 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 sortie et l’historique de la branche master plutôt que le battage médiatique.
Au 10 avril 2026 (Australie/Melbourne), la dernière sortie GitHub taguée visible sur la page des sorties est la v1.12.1 (31 décembre 2025). Cette sortie note l’ajout d’un fournisseur LM Studio et des corrections autour de l’appel de fonctions avec des fournisseurs compatibles OpenAI et l’analyse JSON.
Les sorties précédentes esquissent les plus grands changements :
- v1.11.0 (21 octobre 2025) a introduit un nouvel assistant de configuration et un système de configuration refondu, ainsi qu’un support plus large des fournisseurs et un chemin d’installation Docker en une seule commande. Elle mentionne également la récupération dynamique des modèles et diverses améliorations de l’interface et de l’expérience développeur.
- v1.12.0 (27 décembre 2025) est un reset architectural : elle supprime LangChain au profit d’une implémentation personnalisée pour le streaming, la génération et les comportements spécifiques aux fournisseurs. Elle renomme également les « fournisseurs » en « connexions », ajoute des améliorations de rendu de l’interface et du code, et déplace plus de capacités dans les abstractions propres au projet (y compris un appel de fonctions amélioré par rapport aux approches d’analyse précédentes).
- Plus tôt, v1.10.0 (20 mars 2025) a ajouté les uploads de fichiers (PDF, TXT, DOCX), a ajouté un paramètre Ollama keep_alive, a ajouté une classe d’agent de méta-recherche pour améliorer la maintenabilité et la création du mode focus, et a ajouté la fonctionnalité de recherche automatique d’images et de vidéos.
Côté branding, le renommage en Vane a eu lieu le 9 mars 2026 dans master (feat(app): rename to 'vane'), mettant à jour à la fois la nomenclature du code et les artefacts Docker.
Et le projet n’a pas cessé d’évoluer après la sortie de décembre 2025. Les commits de la branche master du 8 au 9 avril 2026 incluent des travaux décrits comme « mode de recherche approfondie mis à jour, gestion du contexte » et de nouveaux changements d’exécution de recherche et de scraping. En d’autres termes, la partie « moteur de recherche IA » est toujours activement itérée, et non figée derrière les tags de sortie.