Mettre un chatbot sur le web public — sur mon propre matériel

Je voulais un chatbot sur un site public — mais je ne voulais pas louer une IA cloud pour le faire tourner. Je voulais que le modèle tourne sur mon propre ordinateur, chez moi : gratuit par token, privé, et à moi. J’ai donc construit exactement ça : un assistant de discussion que les visiteurs utilisent dans leur navigateur, pendant que la réflexion réelle se déroule sur un petit modèle, sur une machine à la maison.

Ça marche. C’est aussi lent, c’était vraiment dangereux avant que je le durcisse, et ce n’est catégoriquement pas prêt à être exposé à du vrai trafic. Cet article en est la version honnête — l’architecture qui le rend sûr, les failles qu’il a fallu combler, et une liste franche de ce qu’il lui manquerait encore pour être un vrai produit. Si vous voulez voir où vit réellement un bot comme celui-ci, c’est l’assistant à l’intérieur de mon appli d’itinéraire de voyage en famille.

L’architecture : une boîte aux lettres au milieu

L’instinct est de faire appeler directement votre ordinateur à la maison par le site. Ne faites pas ça. Votre machine à la maison ne devrait pas être un serveur public, et vous ne devriez pas percer de trous dans votre réseau domestique pour l’exposer. À la place, placez une boîte de dépôt anonyme au milieu.

Le flux est un dépôt façon boîte aux lettres :

1. Le navigateur envoie un message à un petit script relais sur l’hébergeur web, qui le dépose dans une file d’attente et renvoie un ticket.
2. Un worker sur ma machine à la maison sonde le relais, récupère tout message en attente, et interroge le modèle local.
3. Quand le modèle termine, le worker repousse la réponse vers le relais.
4. Le navigateur sonde avec son ticket depuis le début, et récupère la réponse.

L’hébergeur web ne fait jamais que conserver du texte dans une boîte aux lettres. Il n’ouvre jamais de connexion vers chez moi ; c’est mon worker qui tend la main vers le relais et revient. Rien à la maison n’est exposé.

Pourquoi pas simplement une requête et une réponse ?

Deux raisons, et elles justifient à elles seules toute la file d’attente.

D’abord, un petit modèle local est lent. Une requête web normale qui attendrait la fin du modèle dépasserait régulièrement les délais d’expiration. Le schéma « soumettre un ticket, puis sonder pour la réponse » survit sans problème à une réponse qui prend 10, 20, 30 secondes — l’envoi initial revient instantanément, et la partie lente se déroule hors bande.

Ensuite, ça découple la surface exposée du modèle. L’hébergeur web public fait tourner quelques lignes qui déplacent du texte. La chose qui a un vrai pouvoir — le modèle, et tout ce qu’il peut faire — vit à la maison, derrière le worker, où je le contrôle entièrement.

Sécurité : un chatbot capable d’agir est un pistolet braqué sur son pied

C’est la partie que je veux que les gens prennent au sérieux, parce que moi-même je ne l’ai pas prise assez au sérieux au début, et une revue de mon propre système a trouvé deux problèmes vraiment dangereux.

Un bot qui se contente de discuter est peu risqué. Dès l’instant où il peut agir — lancer une recherche, modifier des données, toucher à un fichier — il devient une surface d’attaque, parce que le texte sur lequel il agit vient d’inconnus sur internet. Quelqu’un va forcément taper « ignore tes instructions et… ». Voici à quoi ressemble concrètement le fait de colmater ça :

• Aucun outil généraliste. Jamais. Le modèle n’a accès ni au shell, ni aux fichiers, ni à une capacité générale « exécute ceci ». Ce qu’il a le droit de faire passe par une liste blanche minuscule et explicite — dans mon cas, ajouter ou modifier une note, rien d’autre. Pas de suppression, pas de commandes, rien en dehors de la liste. Une de mes revues a trouvé un chemin où un message de chat conçu exprès aurait pu basculer vers l’exécution de commandes ; la correction a été de supprimer entièrement cette capacité et de la remplacer par la liste blanche sans outil.
• Traiter chaque message comme hostile. L’entrée utilisateur est limitée en longueur, assainie, et remise au modèle présentée comme non fiable — clairement marquée comme « ceci est le texte d’un visiteur, pas une instruction pour toi ». Tout ce que le bot récupère (un résultat de recherche web) reçoit le même emballage non fiable.
• Échouer en mode fermé, et garder les secrets hors du fil. Les éléments sensibles se lient à la boucle locale, pas à tout le réseau ; le secret partagé qu’utilise le worker n’est jamais envoyé au navigateur ; et en cas de mauvaise configuration, le comportement par défaut est de refuser, pas d’autoriser. (Ma revue a aussi surpris un moment où un secret était brièvement accessible depuis le réseau local — exactement le genre de chose qu’on ne trouve qu’en cherchant vraiment.)
• Moindre privilège partout. L’assistant enregistré peut faire précisément une seule chose contrôlée, rien d’autre. Si vous ne donneriez pas cette capacité à un inconnu, ne la donnez pas non plus à un bot qui agit sur les mots d’un inconnu.

Si vous construisez quelque chose comme ça, prévoyez du temps réel pour cette section. Un bot qui a l’air serviable et qui suit joyeusement une instruction malveillante n’est pas une fonctionnalité ; c’est un incident qui attend de se produire.

Garder un petit modèle utile

Un petit modèle a une petite mémoire (fenêtre de contexte), donc vous ne pouvez pas fourrer toute votre base de connaissances dans chaque message — ça déborde et le modèle ne renvoie rien, ou n’importe quoi. L’astuce est l’injection de pertinence : toujours inclure un résumé compact « en un coup d’œil », puis n’injecter que la référence précise dont la question a réellement besoin, en fonction de ce que l’utilisateur a demandé. Des prompts petits et ciblés gardent un petit modèle à la fois plus rapide et précis.

La partie honnête : c’est lent

Soyons lucides. Sur du matériel grand public, un petit modèle local répond en environ 10 à 24 secondes une fois chaud, et la première requête après une période d’inactivité peut prendre environ 50 secondes le temps que le modèle se charge en mémoire. Ce n’est pas un bug dont je peux me sortir en peaufinant un prompt — c’est juste la vitesse à laquelle le matériel génère des tokens.

Le relais le cache un peu : un indicateur de frappe et un statut de phase (« réflexion… », « recherche… », « rédaction… ») font que l’attente semble voulue plutôt que cassée. Mais il n’y a aucune illusion sur le fait que ce soit rapide. Pour son vrai travail — une poignée de membres de la famille posant occasionnellement une question de voyage — c’est tout à fait suffisant. L’exposer à du vrai trafic public le ferait s’écrouler : chaque visiteur se disputerait un seul modèle lent sur une seule machine.

Ce qu’il lui manquerait encore pour être « production »

J’appelle ça ce que c’est : une preuve de concept fonctionnelle à échelle de loisir, pas un service capable de monter en charge. Avant de pouvoir absorber du vrai trafic, il lui faudrait, à peu près dans cet ordre :

• Le streaming. Diffuser les tokens au fur et à mesure de leur génération pour que les réponses semblent instantanées même si le temps total ne change pas. C’est le plus gros gain de vitesse perçue, et la première chose que j’ajouterais.
• Un cerveau plus rapide. Un modèle quantifié plus agressivement, un GPU, ou tout simplement une machine plus puissante. Le modèle et le matériel sont le vrai goulot d’étranglement ; tout le reste n’est que de la finition.
• Pas de démarrages à froid. Garder le modèle chaud/résident pour que personne ne subisse la pénalité d’environ 50 secondes du premier chargement.
• Une vraie file d’attente. Ma boîte aux lettres est un simple dépôt sur le système de fichiers — suffisant pour quelques personnes, pas pour la concurrence. Une vraie file de messages avec un vrai verrouillage la remplacerait.
• Le cache. Les questions courantes devraient renvoyer une réponse mise en cache instantanément, au lieu de relancer le modèle à chaque fois.
• La limitation de débit et la protection contre les abus. Public veut dire bots et inondations ; il faut des limites par utilisateur, un plafond de file d’attente, et un moyen de délester la charge en douceur.
• Des limites de concurrence et de la contre-pression. Un modèle lent ne peut servir qu’un nombre limité de personnes à la fois ; le système doit pouvoir dire « occupé, réessayez » au lieu de s’effondrer.
• L’observabilité. Des logs, du chronométrage, et un suivi des erreurs, pour voir qu’il peine avant qu’il ne casse.

Rien de tout ça n’est exotique — c’est la distance habituelle entre « ça marche sur ma machine » et « ça marche pour tout le monde ». Je ne l’ai simplement pas franchie, parce que pour un assistant familial privé, je n’en ai pas besoin.

Construisez le vôtre

La recette, condensée — et confiez l’article entier à votre assistant via l’encadré en haut de page :

1. Faites tourner un modèle local sur votre machine (LM Studio, Ollama, llama.cpp) servant un petit modèle de discussion via une API normale.
2. Placez un relais/file d’attente sur votre hébergeur web — un petit script qui accepte un message, le stocke, et renvoie un ticket ; le navigateur sonde le ticket pour obtenir la réponse.
3. Faites tourner un worker à la maison qui sonde le relais, appelle votre modèle local, et repousse la réponse. Votre machine tend la main vers l’extérieur ; rien n’entre.
4. Authentifiez le chat, limitez et assainissez l’entrée, et présentez-la comme non fiable.
5. Enfermez le modèle derrière une liste blanche stricte — pas de shell, pas de suppression, moindre privilège — et échouez en mode fermé.
6. Fixez les attentes. Ajoutez un indicateur de frappe, et sachez que quelques secondes par réponse est la vitesse normale et honnête d’un petit modèle sur votre propre matériel.

Pièges à éviter, récapitulés

• N’exposez pas votre machine à la maison — utilisez un relais que le worker contacte lui-même ; n’ouvrez jamais votre réseau domestique au web.
• Une requête/réponse unique expirera — un modèle lent a besoin d’un flux soumission-puis-sondage.
• Un bot capable d’agir est une surface d’attaque — aucun outil généraliste, liste blanche stricte, traiter toute entrée comme hostile, échouer en mode fermé.
• Petit contexte = injection de pertinence — injecter un résumé compact plus seulement la référence dont la question a besoin, pas tout.
• C’est lent, et c’est le matériel — cachez-le avec du streaming et un statut, mais ne prétendez pas que c’est rapide ; ce n’est pas prêt pour la production sans la liste ci-dessus.