Comment sécuriser une IA installée en local dans votre entreprise

Installer une intelligence artificielle sur ses propres serveurs plutôt que de passer par un service en ligne : le choix se répand dans les entreprises françaises, souvent pour de bonnes raisons de confidentialité. Une analyse publiée par le chercheur Boyd Kane vient pourtant refroidir l'enthousiasme : dans certaines configurations, un modèle d'IA peut prendre le contrôle de la machine qui l'héberge. Le modèle lui-même n'y est pour rien. La faiblesse se loge dans le moteur d'inférence, ce logiciel discret qui fait tourner le modèle. Voici ce qu'il faut comprendre, et comment installer une IA locale sans lui confier les clés de votre informatique.

Le moteur d'inférence, un logiciel que personne ne regarde

Quand une équipe installe une IA en interne, elle installe en réalité deux choses. D'abord le modèle : un gros fichier de plusieurs gigaoctets, rempli de nombres, incapable d'agir seul. Ensuite le moteur d'inférence : le programme qui charge ce fichier et calcule les réponses. Ollama, llama.cpp et vLLM sont les plus répandus.

Ce moteur est écrit pour la vitesse, le plus souvent en C++, un langage très performant mais qui autorise des erreurs de gestion de la mémoire. Il lit des formats de fichiers complexes. Il expose une interface réseau pour recevoir les requêtes. Autrement dit : c'est un logiciel classique, avec les failles classiques d'un logiciel.

Un exemple documenté. En 2024, la faille dite Probllama (référencée CVE-2024-37032) permettait de prendre le contrôle d'un serveur Ollama avec une simple requête web piégée. Elle a été corrigée en quelques jours par l'éditeur. Plus d'un millier d'instances restaient pourtant accessibles depuis internet des mois plus tard, sans mise à jour.

Ce que la recherche a montré

L'analyse de Boyd Kane assemble ces éléments en un scénario complet. Le moteur d'inférence tourne avec les droits de la machine qui l'héberge. S'il est compromis, l'attaquant hérite de ces droits : lecture des fichiers, accès au réseau, installation de programmes.

La compromission peut venir de deux directions. Par le réseau, comme pour n'importe quel serveur mal protégé. Ou par le modèle lui-même : un fichier de modèle est analysé, décodé, chargé en mémoire par le moteur, et un fichier piégé téléchargé depuis une plateforme publique peut déclencher une faille au moment de ce chargement. Certains formats anciens, comme les fichiers pickle de l'écosystème Python, vont plus loin : par conception, ils peuvent exécuter du code dès l'ouverture.

Le point important : rien de tout cela ne suppose une IA « consciente » ou malveillante. On parle de bugs, de formats de fichiers et de droits d'accès. Des sujets de sécurité informatique très ordinaires, appliqués à un logiciel que presque personne ne pense à surveiller.

Pourquoi votre entreprise est concernée

Le paradoxe mérite d'être posé calmement. Les entreprises qui installent une IA en local le font en général pour protéger leurs données : ne rien envoyer à un service à l'étranger, garder les dossiers clients chez soi. L'intention est saine.

Puis la machine qui héberge l'IA est posée sur le réseau principal. Elle voit les partages de fichiers. Elle accède parfois à la comptabilité, parce que quelqu'un voulait faire analyser les factures. Dans les petites structures, elle tourne avec un compte administrateur, parce que c'était plus simple le jour de l'installation.

La question à se poser tient en une phrase : si cette machine était compromise ce soir, que verrait l'attaquant depuis elle ? Si la réponse est « tout », le bénéfice de confidentialité recherché au départ s'est retourné contre vous.

Isoler l'IA : la méthode, étape par étape

L'image juste est celle d'un invité : on lui donne une chambre d'amis, pas la maison. Concrètement, cinq mesures, dans l'ordre.

1. Une machine dédiée, ou à défaut une machine virtuelle. L'IA tourne seule dessus. Rien d'autre : pas de partage de fichiers, pas de session de travail du quotidien.
2. Un compte sans droits d'administration pour le moteur d'inférence. Si le moteur est compromis, l'attaquant se retrouve dans une pièce vide.
3. Un cloisonnement réseau. La machine n'accède ni aux dossiers clients, ni à la comptabilité, ni aux sauvegardes. Son interface de requêtes ne répond qu'aux postes autorisés, jamais à internet. Attention aux installations via Docker, qui exposent souvent le port de l'IA (11434 pour Ollama) bien au-delà du poste local.
4. Des mises à jour au rythme du navigateur. Les moteurs d'inférence évoluent vite et les correctifs de sécurité sortent souvent. Attendre le trimestre prochain revient à laisser ouverte chez vous une faille documentée publiquement, parfois avec le mode d'emploi de l'attaque.
5. Des modèles téléchargés depuis des sources identifiées, au format safetensors quand il existe. Ce format a précisément été conçu pour ne pas pouvoir exécuter de code au chargement.

Sur une installation existante, une demi-journée suffit pour mettre tout cela en place.

Les pièges observés sur le terrain

La machine virtuelle figée, d'abord. On isole l'IA dans une VM, on se sent protégé, et plus personne ne met à jour ce qui tourne dedans. L'isolation limite les dégâts un jour de problème ; elle ne remplace pas les correctifs.

L'interface exposée sans le savoir, ensuite. Une variable de configuration modifiée pour un test, un conteneur déployé un peu vite, et le serveur d'IA répond à tout le réseau, voire à internet. Des moteurs de recherche spécialisés comme Shodan recensent en permanence ces serveurs visibles de l'extérieur : les attaquants n'ont même pas à chercher.

Les agents trop équipés, aussi. Donner à l'IA des outils, accès au terminal, envoi de courriels, lecture de dossiers partagés, revient à élargir sa chambre d'amis à toute la maison. Chaque outil ajouté est une porte de plus, à ouvrir seulement si l'usage le justifie vraiment.

Reste la confusion la plus répandue : croire que « local » veut dire « sûr ». L'hébergement local protège de la fuite de données vers un prestataire. Face à une faille dans le logiciel installé, il ne protège de rien du tout.

Ce que ça coûte, ce que ça évite

Un ordre de grandeur, pour une structure de dix à vingt personnes. Une machine dédiée correcte, avec une carte graphique capable de faire tourner un modèle de taille moyenne : entre 1 500 et 2 500 euros, une fois. La configuration de l'isolation par un prestataire : une demi-journée, soit environ 400 à 600 euros. L'entretien ensuite : quinze à trente minutes de mises à jour par mois.

En face, le cabinet Astères estimait en 2023 le coût moyen d'une cyberattaque réussie à près de 59 000 euros pour une petite entreprise française, arrêt d'activité compris. Le rapport entre les deux chiffres se passe de commentaire. Et une machine compromise ne coûte pas que de l'argent : des dossiers clients exfiltrés engagent aussi votre responsabilité au titre du RGPD.

Recevoir l'invité, garder les clés

L'IA locale reste un bon choix pour une entreprise qui veut travailler avec ses propres données. La recherche récente ne dit pas le contraire. Elle rappelle simplement qu'un modèle d'IA s'installe comme n'importe quel logiciel connecté : avec une pièce à lui, des droits limités et des mises à jour régulières.

Si votre équipe fait déjà tourner une IA en interne et que personne ne sait précisément ce qu'elle peut atteindre sur votre réseau, la vérification se fait en une heure. Autensai accompagne les entreprises françaises sur ce type d'audit et d'installation : vous pouvez prendre rendez-vous pour en parler.