Temps de lecture : 5 min
Points clés à retenir
- VRAM : dimensionnez votre matériel en fonction du modèle – 4 à 5 Go pour un 7B, 8-10 Go pour un 14B, 32 Go+ pour un 70B.
- Authentification : verrouillez l’endpoint du LLM avec un jeton JWT et des rôles distincts pour éviter tout accès non autorisé.
- Traçabilité : activez les logs d’inférence pour respecter le RGPD et l’AI Act – sans cela, impossible de savoir qui utilise quoi.
Pourquoi un LLM local n’est pas sécurisé par défaut
Faire tourner un modèle de langage sur son propre matériel séduit de plus en plus de professionnels en 2026. Avec des outils comme Ollama, LM Studio ou Jan, l’installation est rapide. Les motivations sont claires : garder la main sur ses données, maîtriser les coûts d’inférence, respecter le RGPD.
Mais “local” ne signifie pas “sécurisé”. Le périmètre à protéger change radicalement. L’entreprise porte désormais l’entière responsabilité de l’infrastructure, des accès et des données qui transitent. Passons au concret : voici les réflexes à adopter et les pièges à éviter.
Réflexe n°1 : dimensionner le matériel avant le modèle
Le facteur limitant d’un LLM local, c’est la VRAM. Sans VRAM suffisante, le modèle ne charge pas ou fonctionne en swap mémoire, ce qui dégrade les performances et la sécurité.
Voici les besoins réels pour une compression 4 bits :
- 7B de paramètres : 4 à 5 Go – compatible RTX 3060 12 Go, Mac M2 Pro 16 Go.
- 14B de paramètres : 8 à 10 Go – RTX 4070 12 Go, Mac M4 Pro 24 Go.
- 70B de paramètres : 32 à 35 Go – RTX 5090 32 Go, Mac M4 Max 64 Go.
En pratique, choisissez le modèle en fonction de votre matériel, pas l’inverse. Si c’est complexe, c’est que c’est mal réglé.
Réflexe n°2 : verrouiller l’accès au point d’entrée
Quand un LLM tourne en local, il expose un point d’accès réseau (endpoint). Sans authentification, toute personne connectée au même réseau peut l’interroger.
Sur le terrain, la bonne pratique consiste à mettre en place une authentification par jeton JWT. Ce petit fichier chiffré contient l’identité, les droits d’accès et une date d’expiration. À chaque requête, le token est vérifié : s’il est absent, expiré ou falsifié, la requête est refusée.
Définissez aussi des rôles distincts : qui peut interroger, modifier la configuration, consulter les logs. La variance, ça se gère avec des permissions claires.
Réflexe n°3 : isoler et chiffrer les fichiers du modèle
Les fichiers de poids d’un modèle peuvent peser de quelques Go à plus de 100 Go. Leur accès en lecture à tous les utilisateurs expose à des copies non autorisées.
La parade : stockez 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. Sans langue de bois : si un fichier est accessible en écriture, le risque de corruption est réel.
Réflexe n°4 : sécuriser la base documentaire (RAG)
Certains déploiements connectent le LLM à une base de connaissances interne via un mécanisme appelé RAG (Retrieval-Augmented Generation). Le modèle interroge des documents pour 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 auxquels il n’a pas droit.
Décortiquons la structure : sécuriser l’API d’inférence mais laisser la base vectorielle ouverte est une erreur classique. Implémentez un cloisonnement par équipe ou projet dans la base documentaire.
Réflexe n°5 : ne pas négliger les logs et la conformité
Beaucoup d’installations locales tournent sans journalisation des requêtes. Résultat : 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 impose la traçabilité pour les systèmes IA à haut risque. Les logs doivent respecter le RGPD : toute donnée personnelle présente dans les requêtes doit être détectée et anonymisée avant stockage.
Ce qui compte vraiment, c’est d’anticiper ces contraintes dès la configuration, pas après une fuite.
Les erreurs à éviter absolument
Télécharger des modèles depuis des sources non vérifiées
Les modèles open source sont distribués sur des plateformes officielles comme Hugging Face ou la bibliothèque Ollama. Mais des versions modifiées circulent sur des dépôts tiers. Un modèle altéré peut intégrer des biais, des portes dérobées ou des comportements indésirables. J’insiste : ne téléchargez que depuis les sources officielles.
Rendre le modèle accessible sur le réseau sans protection
Par défaut, Ollama n’est accessible que depuis la machine locale. Dès qu’on ouvre l’accès à d’autres postes, le modèle devient ouvert à tout le réseau. Sans couche d’authentification ajoutée, n’importe qui peut envoyer des requêtes sans limite.
Croire que “local” rime avec “sécurisé”
C’est le piège le plus courant. L’injection de prompt est tout aussi efficace en local que sur le cloud. Un modèle peut révéler son prompt système ou extraire des informations de la base documentaire. La sécurité exige la même rigueur qu’un service hébergé.