LLM en local : les bonnes pratiques pour une installation sécurisée

Faire tourner un modèle de langage directement sur sa propre machine ou son serveur interne est devenu accessible en 2026. Des outils comme Ollama, LM Studio ou Jan permettent de télécharger et de lancer un LLM en quelques minutes, sans dépendre d’un service cloud. Les motivations sont connues, il s’agit en effet de garder la main sur ses données, de maîtriser ses coûts d’inférence et de se conformer aux exigences du RGPD.

Mais installer un LLM en local ne suffit pas à garantir la sécurité du déploiement. Le périmètre à protéger change radicalement par rapport à un usage cloud. C’est l’entreprise (ou l’utilisateur/utilisatrice) qui porte l’entière responsabilité de l’infrastructure, de l’accès au modèle et des données qui transitent. Voici les bons réflexes à adopter et les erreurs les plus courantes à éviter.

Installer un LLM en local : les réflexes à adopter

Dimensionner son matériel avant de choisir un modèle

Le facteur limitant d’un LLM local, c’est la VRAM, c’est-à-dire la mémoire dédiée de la carte graphique (GPU), où sont chargés les paramètres du modèle pendant l’exécution. Un modèle dit « 7B » (7 milliards de paramètres), une fois quantifié (c’est-à-dire compressé pour réduire sa taille en mémoire), nécessite environ 4 à 5 Go de VRAM. Un modèle 14B en demande 8 à 10 Go. Pour un modèle 70B, il faut compter 32 Go ou plus. Le bon réflexe consiste à choisir le modèle en fonction de son matériel, et non l’inverse.

Verrouiller l’accès au point d’entrée du modèle

Quand un LLM tourne en local, il expose un point d’accès réseau (appelé « endpoint ») que les applications utilisent pour lui envoyer des requêtes. Sans authentification, toute personne connectée au même réseau peut interroger le modèle, y compris en dehors des cas d’usage prévus. La bonne pratique consiste à mettre en place une authentification par jeton (token JWT, par exemple) et à définir des rôles distincts, notamment qui peut interroger le modèle, qui peut modifier sa configuration, qui peut consulter les logs… Cette séparation des droits d’accès limite considérablement les dégâts en cas de compromission d’un compte.

Isoler et chiffrer les fichiers du modèle

Les fichiers de poids d’un modèle (les « weights », qui contiennent l’ensemble de ce que le modèle a appris lors de son entraînement) peuvent peser de quelques gigaoctets à plus de 100 Go. S’ils sont accessibles en lecture à tous les utilisateurs et utilisatrices du système, n’importe qui peut les copier sur un support externe. La parade est donc de stocker ces fichiers sur un volume chiffré, monté en lecture seule dans l’environnement d’exécution, avec des permissions restreintes au seul processus qui fait tourner le modèle.

Sécuriser la base documentaire connectée au modèle

Certains déploiements connectent le LLM à une base de connaissances interne grâce à un mécanisme appelé RAG (Retrieval-Augmented Generation). Ainsi, le modèle peut interroger des documents internes pour enrichir ses réponses. Si cette base documentaire n’est pas protégée au même niveau que le modèle lui-même, un utilisateur ou une utilisatrice peut, via ses requêtes, accéder à des documents auxquels il ou elle n’est pas censé avoir accès. L’erreur classique consiste à sécuriser l’API d’inférence tout en laissant la base vectorielle ouverte sur le réseau interne. Un cloisonnement par équipe ou par projet dans la base documentaire est indispensable.

Installer un LLM en local : les erreurs à éviter

Télécharger des modèles depuis des sources non vérifiées

Les modèles open source sont distribués sous forme de fichiers volumineux hébergés sur des plateformes comme Hugging Face ou la bibliothèque officielle d’Ollama. Mais des versions modifiées circulent aussi sur des dépôts tiers, des forums ou des liens partagés sur les réseaux sociaux. Un modèle altéré peut intégrer des biais délibérés, des portes dérobées ou des comportements indésirables invisibles à l’usage courant. Le réflexe de base est donc de ne télécharger que depuis les sources officielles et de vérifier l’éditeur du modèle avant toute installation.

Rendre le modèle accessible sur le réseau sans protection

Par défaut, un outil comme Ollama n’est accessible que depuis la machine sur laquelle il est installé. Personne d’autre sur le réseau ne peut l’interroger. Mais dès qu’on modifie cette configuration pour permettre à d’autres postes (des collègues, par exemple) d’y accéder, le modèle devient ouvert à toutes les machines du réseau. Cependant, Ollama, comme d’autres, ne propose aucun système d’identification intégré. Sans couche de protection ajoutée en amont, n’importe qui peut envoyer des requêtes au modèle, sans limite.

Négliger les logs et le cadre réglementaire

Beaucoup d’installations locales tournent sans aucune journalisation des requêtes. La conséquence directe, c’est qu’il est impossible de savoir qui a interrogé le modèle, à quel moment, ni avec quelles données. Au-delà du risque opérationnel, c’est un problème de conformité. L’AI Act européen, dont les obligations pour les systèmes IA à haut risque s’appliquent à partir d’août 2026, impose des exigences de traçabilité, de gestion des risques et de gouvernance des données. Les logs d’inférence doivent par ailleurs respecter le RGPD : toute donnée personnelle présente dans les requêtes doit être détectée et anonymisée avant stockage.

Croire que « local » rime avec « sécurisé »

C’est le piège le plus courant. Le raisonnement « mes données restent sur ma machine, donc je suis protégé » est incomplet. L’injection de prompt, qui consiste à manipuler le modèle à l’aide de requêtes formulées pour contourner ses consignes de fonctionnement, est tout aussi efficace en local que sur un service cloud. Un modèle peut être amené à révéler son prompt système, à ignorer ses filtres de sécurité ou à extraire des informations de la base documentaire connectée. La sécurité d’un déploiement local exige donc la même rigueur qu’un service hébergé dans le cloud, d’autant que ce type de vulnérabilité est l’une des plus communes.