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. Cette approche vise à garder la main sur ses données, à maîtriser ses coûts d’inférence et à se conformer aux exigences du RGPD.
Cependant, installer un LLM en local ne garantit pas la sécurité du déploiement. Le périmètre à protéger change radicalement par rapport à un usage cloud, car l’entreprise ou l’utilisateur porte l’entière responsabilité de l’infrastructure, de l’accès au modèle et des données qui transitent. Voici les bonnes pratiques à adopter et les erreurs à é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 est la VRAM, ou 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) nécessite environ 4 à 5 Go de VRAM, tandis qu’un modèle 14B en demande 8 à 10 Go. Pour un modèle 70B, il faut compter 32 Go ou plus. Il est donc essentiel de choisir le modèle en fonction de son matériel.
Verrouiller l’accès au point d’entrée du modèle
Lorsqu’un LLM fonctionne en local, il expose un point d’accès réseau (appelé « endpoint ») pour recevoir des requêtes. Sans authentification, toute personne connectée au même réseau peut interroger le modèle. La mise en place d’une authentification par jeton (token JWT) et la définition de rôles distincts permettent de limiter les accès et de réduire les risques en cas de compromission.
Isoler et chiffrer les fichiers du modèle
Les fichiers de poids d’un modèle peuvent peser de quelques gigaoctets à plus de 100 Go. Si ces fichiers sont accessibles à tous les utilisateurs du système, ils peuvent être copiés sur un support externe. Il est recommandé de stocker ces fichiers sur un volume chiffré, monté en lecture seule dans l’environnement d’exécution, avec des permissions restreintes.
Sécuriser la base documentaire connectée au modèle
Certains déploiements connectent le LLM à une base de connaissances interne, ce qui permet d’enrichir ses réponses. Si cette base n’est pas protégée au même niveau que le modèle, un utilisateur peut accéder à des documents non autorisés. Un cloisonnement par équipe ou projet est indispensable pour éviter ce risque.
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 souvent hébergés sur des plateformes reconnues, mais des versions modifiées circulent sur des dépôts tiers. Un modèle altéré peut intégrer des biais ou des comportements indésirables. Il est crucial de ne télécharger que depuis des sources officielles et de vérifier l’éditeur du modèle.
Rendre le modèle accessible sur le réseau sans protection
Par défaut, un outil comme Ollama est accessible uniquement depuis la machine sur laquelle il est installé. Modifier cette configuration pour permettre l’accès à d’autres postes sans protection expose le modèle à tous les ordinateurs du réseau. Une couche de protection est nécessaire pour sécuriser l’accès.
Négliger les logs et le cadre réglementaire
De nombreuses installations locales ne journalisent pas les requêtes, rendant impossible la traçabilité des accès. Cela pose un problème de conformité, notamment avec l’AI Act européen, qui impose des exigences de traçabilité et de gestion des données. Les logs doivent également respecter le RGPD en anonymisant les données personnelles.
Croire que « local » rime avec « sécurisé »
Le raisonnement selon lequel « mes données restent sur ma machine, donc je suis protégé » est incomplet. L’injection de prompt, qui consiste à manipuler le modèle avec des requêtes spécifiques, peut également se produire en local. La sécurité d’un déploiement local nécessite la même rigueur qu’un service hébergé dans le cloud.
Source : Blog du Modérateur.
