Tu veux les meilleurs outils IA avant les autres ?
On teste et on décrypte les nouveaux outils IA chaque soir, en 5 min. Gratuit.
Inclus dès l'inscription : notre sélection des meilleurs guides & comparatifs IA.
Choisis ton rythme
Gratuit · Pas de spam · Désabonnement en 1 clic
LLM en local : une avancée technologique à double tranchant
En 2026, l'installation de modèles de langage sur des machines locales est devenue une réalité accessible grâce à des outils comme Ollama, LM Studio et Jan. Ces logiciels permettent de télécharger et de faire fonctionner un modèle de langage en quelques minutes, sans dépendre d'un service cloud. Cette avancée technologique répond à plusieurs motivations clés : garder le contrôle sur ses données, réduire les coûts d'inférence et se conformer aux exigences strictes du RGPD.
Cependant, le simple fait d'installer un LLM en local ne garantit pas la sécurité de son déploiement. En effet, le passage d'une infrastructure cloud à une gestion locale modifie radicalement le périmètre de sécurité. L'utilisateur ou l'entreprise devient entièrement responsable de l'infrastructure, de l'accès au modèle et des données qui y transitent. Voici les bonnes pratiques à adopter pour sécuriser efficacement un LLM local.
Dimensionner son matériel : une étape cruciale
L'un des principaux défis lors de l'installation d'un LLM en local est de s'assurer que le matériel est adéquatement dimensionné. La mémoire dédiée de la carte graphique, ou VRAM, est le facteur limitant pour faire tourner un modèle. Par exemple, un modèle de 7 milliards de paramètres, une fois compressé, nécessite entre 4 et 5 Go de VRAM. Pour un modèle de 14 milliards de paramètres, il faut compter entre 8 et 10 Go, tandis qu'un modèle de 70 milliards de paramètres requiert au moins 32 Go de VRAM. Il est donc essentiel de choisir le modèle en fonction des capacités matérielles disponibles, et non l'inverse.
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)
Sécuriser l'accès au modèle : une priorité
Lorsqu'un LLM fonctionne en local, il expose un point d'accès réseau, ou endpoint, utilisé par les applications pour envoyer des requêtes. Sans authentification, n'importe qui sur le même réseau peut interagir avec le modèle, ce qui peut conduire à des usages non autorisés. Pour éviter cela, il est recommandé de mettre en place une authentification par jeton, comme le JWT, et de définir des rôles distincts pour contrôler qui peut interroger le modèle, modifier sa configuration ou consulter les logs. Cette séparation des droits d'accès est cruciale pour limiter les risques en cas de compromission.
Comprendre le token JWT
Le JSON Web Token (JWT) est un fichier chiffré qui est remis à un utilisateur après authentification. Il contient des informations sur l'identité de l'utilisateur, ses droits d'accès et une date d'expiration. À chaque requête envoyée au modèle, le token est vérifié automatiquement. Si le token est absent, expiré ou altéré, la requête est refusée. Ce mécanisme est similaire à celui utilisé par la plupart des API cloud.
Protéger les fichiers du modèle : une nécessité
Les fichiers de poids d'un modèle, qui contiennent toutes les données apprises lors de l'entraînement, peuvent être très volumineux, allant de quelques gigaoctets à plus de 100 Go. Si ces fichiers sont accessibles en lecture à tous les utilisateurs du système, ils peuvent être copiés sur un support externe. Pour éviter cela, il est conseillé 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 exécute le modèle.
Sécuriser la base documentaire : un impératif
Certains déploiements de LLM sont connectés à une base de connaissances interne via un mécanisme appelé Retrieval-Augmented Generation (RAG). Cela permet au modèle d'interroger des documents internes pour enrichir ses réponses. Cependant, si cette base documentaire n'est pas protégée au même niveau que le modèle, un utilisateur pourrait accéder à des documents non autorisés. Une erreur courante est de sécuriser l'API d'inférence tout en laissant la base vectorielle ouverte sur le réseau interne. Il est donc indispensable de cloisonner l'accès à la base documentaire par équipe ou par projet.
Les 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 souvent disponibles sous forme de fichiers volumineux sur des plateformes comme Hugging Face ou la bibliothèque officielle d'Ollama. Cependant, des versions modifiées peuvent circuler sur des dépôts tiers, des forums ou des réseaux sociaux. Ces modèles altérés peuvent contenir des biais délibérés, des portes dérobées ou des comportements indésirables. Il est donc crucial de télécharger uniquement depuis des sources officielles et de vérifier l'éditeur du modèle avant toute installation.
Rendre le modèle accessible sans protection
Par défaut, un outil comme Ollama n'est accessible que depuis la machine sur laquelle il est installé. Cependant, si la configuration est modifiée pour permettre l'accès à d'autres postes, le modèle devient accessible à toutes les machines du réseau. Ollama, comme d'autres outils, ne propose pas de système d'identification intégré. Sans une couche de protection supplémentaire, n'importe qui peut envoyer des requêtes au modèle.
Les outils pour faire tourner un LLM en local
Des logiciels comme Ollama, LM Studio et Jan permettent de télécharger et de faire fonctionner un modèle de langage directement sur un ordinateur, sans connexion internet. Ollama s'utilise en ligne de commande, LM Studio offre une interface graphique avec une fenêtre de chat, et Jan mise sur la simplicité d'usage et le fonctionnement 100 % hors ligne. Tous ces outils exposent une API locale que d'autres applications peuvent interroger.
Négliger les logs et le cadre réglementaire
De nombreuses installations locales fonctionnent sans journalisation des requêtes, ce qui rend impossible de savoir qui a interrogé le modèle et avec quelles données. 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 risques à partir d'août 2026. Les logs d'inférence doivent également respecter le RGPD, en détectant et anonymisant les données personnelles avant stockage.
Croire que « local » rime avec « sécurisé »
Il est courant de penser que garder ses données sur sa propre machine assure une protection suffisante. Cependant, des vulnérabilités comme l'injection de prompt, qui manipule le modèle pour contourner ses consignes, sont tout aussi efficaces en local que sur le cloud. Un modèle peut 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 nécessite donc la même rigueur que celle d'un service cloud.
