En 2026, faire tourner un modèle de langage sur sa propre machine ou un serveur interne est désormais à la portée de tous. Des outils tels qu’Ollama, LM Studio ou Jan permettent de télécharger et lancer un LLM rapidement, sans dépendance vis-à-vis d’un service cloud. Les raisons sont claires : conserver la maîtrise de ses données, contrôler les coûts d’inférence et respecter les exigences du RGPD.
Installer un LLM localement ne garantit pas la sécurité du déploiement. Le périmètre à protéger diffère considérablement d’un usage cloud. L’entreprise (ou l’utilisateur/utilisatrice) assume la responsabilité totale de l’infrastructure, de l’accès au modèle et des données échangées. Voici les bons réflexes à adopter, ainsi que les erreurs fréquentes à éviter.
Réflexes à adopter pour installer un LLM en local
Dimensionner son matériel avant de choisir un modèle
Le principal facteur limitant d’un LLM local est la VRAM (mémoire dédiée de la carte graphique), nécessaire pour charger les paramètres du modèle. Un modèle « 7B » (7 milliards de paramètres) quantifié nécessite environ 4 à 5 Go de VRAM, tandis qu’un modèle « 14B » requiert 8 à 10 Go. Pour un modèle « 70B », prévoyez 32 Go ou plus. Choisissez toujours le modèle en fonction de votre matériel.
VRAM nécessaire par taille de modèle (en compression 4 bits)
- 7B de paramètres : 4 à 5 Go de VRAM (RTX 3060 12 Go, Mac M2 Pro 16 Go)
- 14B de paramètres : 8 à 10 Go de VRAM (RTX 4070 12 Go, Mac M4 Pro 24 Go)
- 70B de paramètres : 32 à 35 Go de VRAM (RTX 5090 32 Go, Mac M4 Max 64 Go)
Verrouiller l’accès au point d’entrée du modèle
Un LLM local expose un point d’accès réseau (ou « endpoint ») que les applications utilisent pour envoyer des requêtes. Sans authentification, quiconque sur le même réseau peut interroger le modèle, parfois en dehors des cas d’usage prévus. Implementer une authentification par jeton (JWT, par exemple) et définir des rôles distincts est crucial : qui peut interroger le modèle, qui peut modifier sa configuration, qui a accès aux logs… Cette séparation des droits d’accès minimiserait les conséquences d’une éventuelle compromission de compte.
Qu’est-ce qu’un token JWT ?
Un JWT (JSON Web Token) est un fichier chiffré fourni à un utilisateur après authentification. Il inclut son identité, ses droits d’accès et une date d’expiration. À chaque requête envoyée au modèle, le token est vérifié. Si le token est absent, expiré, ou falsifié, la requête est rejetée. Ce système est semblable à celui utilisé par la majorité des API cloud.
Isoler et chiffrer les fichiers du modèle
Les fichiers de poids d’un modèle (« weights ») peuvent varier de quelques Go à plus de 100 Go. S’ils sont accessibles à tous les utilisateurs, n’importe qui peut les copier. Stocker ces fichiers sur un volume chiffré et monté en lecture seule dans l’environnement d’exécution, avec des permissions strictement limitées, est impératif.
Sécuriser la base documentaire connectée au modèle
Certains déploiements peuvent relier le LLM à une base de connaissances interne via un mécanisme nommé RAG (Retrieval-Augmented Generation). Cela permet au modèle d’interroger des documents internes pour enrichir ses réponses. Si cette base n’est pas aussi protégée que le modèle, un utilisateur risquerait d’accéder à des informations sensibles. Eveillez votre vigilance : sécurisez l’API d’inférence tout en veillant à cloisonner votre base documentaire.
Erreurs à éviter lors de l’installation d’un LLM en local
Télécharger des modèles depuis des sources non vérifiées
Les modèles open source sont disponibles sur des plateformes comme Hugging Face ou la bibliothèque officielle d’Ollama. Des versions modifiées peuvent circuler sur des dépôts tiers ou forums. Un modèle altéré pourrait contenir des biais ou des portes dérobées. Téléchargez uniquement depuis des sources officielles et vérifiez l’éditeur du modèle avant l’installation.
Rendre le modèle accessible sans protection
Un outil comme Ollama est par défaut accessible uniquement depuis la machine où il est installé. Modifier cette configuration pour permettre l’accès à d’autres postes (vos collègues, par exemple) expose le modèle à tout le réseau. Sans système d’authentification, n’importe quel poste peut interroger le modèle sans restriction.
Ollama, LM Studio, Jan… ces outils qui font tourner un LLM en local
Ces logiciels gratuits permettent de faire fonctionner un modèle de langage sur son ordinateur, sans nécessité d’un compte ou connexion internet. Ollama s’opère en ligne de commande (une simple instruction suffit), LM Studio offre une interface graphique avec une fenêtre de chat, et Jan privilégie la simplicité d’utilisation, le tout hors ligne. Les trois exposent également une interface de programmation (API) locale que d’autres applications peuvent interroger.
Négliger l’importance des logs et la conformité réglementaire
De nombreuses installations locales ne conservent aucune journalisation des requêtes. Cela empêche de savoir qui a interrogé le modèle, à quel moment et avec quelles données. Cela soulève non seulement un risque opérationnel, mais aussi un problème de conformité. L’AI Act européen impose des exigences de traçabilité, en particulier pour les systèmes IA à haut risque. Les logs d’inférence doivent respecter le RGPD : toute donnée personnelle dans les requêtes doit être détectée et anonymisée avant stockage.
Nier que « local » garantit « sécurisé »
C’est une erreur fréquente. Le raisonnement selon lequel « mes données sont sur ma machine, donc je suis en sécurité » est incomplet. Les problèmes d’injection de prompt, qui permettent de manipuler le modèle via des requêtes conçues pour contourner ses consignes, sont tout aussi efficaces en environnement local que sur un service cloud. Un modèle peut divulguer des informations sensibles ou ignorer ses filtres de sécurité. La sécurité d’un déploiement local requiert la même rigueur qu’un service hébergé dans le cloud.
