DocsSe connecterInstaller Kastel
Installer · Hébergé par vous

100 % local : aucune inférence ne sort.

Faire tourner votre Kastel entièrement sur vos machines : chat, recherche, construction. Aucune requête d’inférence ne quitte votre infrastructure - et ce n’est pas une phrase marketing, c’est un réglage qui se verrouille et dont l’égress se mesure.

01

Deux chemins vers le local

Il y a deux façons d’atteindre un modèle local, et elles ne sont pas équivalentes pour la lecture de souveraineté.

Ollama (recommandé)

Le fournisseur local natif, verrouillable d’un seul réglage, avec le label zéro-egress par construction.

vLLM ou LM Studio

La prise compatible OpenAI pointée vers votre serveur - les octets restent chez vous si votre adresse est bien chez vous, ce que le moteur ne peut pas vérifier depuis une adresse arbitraire : le label reste donc prudent, sauf déclaration explicite de votre part.

Les deux sont documentés ci-dessous.

02

Ollama et le réglage unique

Les modèles d’abord, sur votre serveur Ollama :

shell
ollama pull llama3      # chat (le modèle par défaut du fournisseur local)
ollama pull bge-m3      # recherche (l’appariement par défaut du profil max)

L’adresse du serveur, partagée par le chat et la recherche, se déclare dans le .env de votre déploiement. Attention au point qui fait échouer la plupart des premières tentatives : votre Kastel tourne dans un conteneur, donc cette adresse est celle que le conteneur voit, pas celle de votre navigateur. Si Ollama tourne comme service de la pile, c’est son nom de service ; s’il tourne ailleurs, mettez une adresse joignable depuis le conteneur.

shell
KASTEL_LOCAL_BASE_URL=http://ollama:11434

Puis le verrou, une ligne dans kastel.config.yaml :

yaml
sovereignty_profile: max

C’est tout le réglage. max implique le chat local et la recherche locale : vous n’avez rien d’autre à écrire. Et c’est un verrou, pas une préférence : combiner max avec la prise BYOK, côté chat comme côté recherche, est une erreur de configuration refusée au chargement. Une réserve à connaître plutôt qu’à découvrir : ce refus vise la prise BYOK ; si vous désignez explicitement un fournisseur cloud d’une autre famille dans votre configuration, le chargement ne vous arrête pas aujourd’hui. Sur un profil souverain, vérifiez que votre fournisseur de chat est bien local.

Enfin, construisez l’index sur le modèle local :

shell
kastel reindex
03

vLLM ou LM Studio

Ces serveurs exposent une API compatible OpenAI : la prise BYOK s’y branche comme à n’importe quelle adresse, pointée vers chez vous :

shell
KASTEL_BYOK_BASE_URL=http://localhost:8000/v1
KASTEL_BYOK_MODEL=le-modele-que-votre-serveur-expose
KASTEL_BYOK_OPENAI_API_KEY=local-pas-un-secret

La clé doit être non vide même si votre serveur n’en vérifie aucune : mettez une valeur factice. Pour la recherche, gardez le modèle local Ollama - rien n’oblige le chat et la recherche à vivre sur le même serveur.

Sur ce chemin, sovereignty_profile: max est refusé : le moteur ne peut pas vérifier qu’une adresse arbitraire est vraiment locale, il ne tamponne donc pas le label zéro-egress dessus. C’est la même variable qui sert à joindre un fournisseur distant : sur cette route, c’est vous qui savez où pointe votre adresse, le moteur ne le déduit pas. Si vous voulez que la lecture de souveraineté reflète votre réalité, déclarez-la vous-même dans la configuration, sous inference.provider_postures : c’est vous qui l’affirmez, sur votre parole et au dossier, pas le moteur qui devine.

04

La garantie zéro-egress, en deux couches

1
Le moteur n’appelle jamais chez nous

La télémétrie est opt-in et éteinte par défaut : dans la configuration par défaut, aucun client réseau n’est même construit. Zéro octet sortant vers nos serveurs, vérifié par des tests dédiés, pas déclaré.

2
Le label local est vrai par construction

Avec un chat local et une recherche locale, les appels de modèle vont vers votre serveur local. Ce qui est prouvé par un test, et il faut le dire précisément : une vraie indexation complète tourne sous le profil max, et le test vérifie qu’aucune requête n’a quitté la machine. C’est le chemin de la recherche ; celui du chat repose sur la même prise locale, sans test d’égress équivalent.

Une honnêteté d’architecte pour finir : « local » est une propriété de l’endroit où pointent vos adresses. La garantie tient tant que KASTEL_LOCAL_BASE_URL désigne une infrastructure qui est vraiment la vôtre.

La télémétrie mérite sa phrase : éteinte par défaut, elle ne transporte, si vous l’allumez un jour, que des signaux d’ingénierie anonymisés dont le schéma est documenté - jamais votre contenu. Sur un profil 100 % local, laissez-la éteinte : c’est le défaut.

05

Ce qui marche, ce qui se dégrade

Tourner en local est une vraie capacité, pas une note de bas de page - mais elle a un prix, et le voici sans détour :

Recherche, exposition MCP, gouvernance, audit

Intégrales. Aucun appel de modèle dans le chemin de lecture directe ; le reste est déterministe.

Qualité de la recherche (bge-m3)

Solide. C’est un très bon modèle multilingue : la partie la moins dégradée du chemin local.

Profondeur de synthèse (ingestion, entretien)

Se dégrade. Elle suit le modèle de chat local que vous faites tourner, plus faible qu’un grand modèle hébergé.

Dit sans détour : le chemin local est testé pour la plomberie et pour le zéro-egress, pas étalonné à qualité égale avec un grand modèle hébergé. Une entreprise qui ne peut envoyer ses données vers aucune API externe obtient un système réel, complet et coupé du monde pour l’inférence. Une entreprise qui cherche la meilleure synthèse sans cette contrainte sera mieux servie par une clé BYOK vers un grand modèle - où vous décidez ce que chaque IA a le droit de voir.

Une contrainte de souveraineté à valider ?

Écrivez-nous : la question posée par email trouve une réponse le jour même. Notre réseau d’intégrateurs partenaires peut aussi déployer un profil 100 % local pour vous.

Nous contacterVoir le programme intégrateurs