LLM sur serveur privé : aucune donnée ne quitte l'entreprise

Chaque fois que votre équipe envoie un prompt à un service d'IA dans le cloud, les données voyagent vers les serveurs d'un tiers. Dans la plupart des contrats grand public, cela implique un transfert international de données personnelles ou, au moins, une communication à un sous-traitant qui doit être formalisée par contrat. Pour une clinique, un cabinet d'avocats, une fiduciaire ou toute entreprise traitant des informations sensibles, ce flux peut devenir un risque RGPD réel. L'alternative consiste à déployer le modèle au sein de votre propre périmètre : sur votre serveur physique, sur votre VPS dédié ou dans votre cloud privé. Dans cet article, nous expliquons comment procéder, quel matériel vous est nécessaire, quelles plateformes logicielles sont les plus utilisées en 2025-2026 et ce que cela implique du point de vue réglementaire.

Pourquoi la donnée «ne sort pas» lorsque vous exécutez un LLM on-premise ?

Un modèle de langage est, en substance, un fichier de poids (des dizaines ou centaines de gigaoctets) qui, une fois chargé en mémoire, génère du texte sans avoir besoin de se connecter à un serveur externe. Lorsque vous installez ce modèle sur votre propre serveur et n'exposez qu'une API interne, le cycle complet — prompt envoyé → inférence → réponse reçue — se déroule au sein de votre réseau. Il n'y a aucun appel sortant, aucun enregistrement dans les systèmes du fournisseur, aucune possibilité que le texte de vos employés ou de vos clients se retrouve dans un journal d'un tiers.

Cela contraste avec les modèles SaaS standard (ChatGPT, Claude.ai, Gemini dans leurs versions grand public), où les données sont traitées sur une infrastructure externe. Les versions enterprise de ces mêmes fournisseurs peuvent inclure des garanties contractuelles plus solides — zéro rétention de prompt, DPA signé, région de données européenne — mais la certitude technique qu'offre l'exécution locale est structurellement supérieure : il n'y a pas de communication car il n'y a pas de transmission.

Cadre réglementaire : RGPD et principe de minimisation des données

Le Règlement Général sur la Protection des Données (RGPD, Règlement UE 2016/679) impose d'identifier et de justifier chaque flux de données personnelles. Lors de l'utilisation d'un service d'IA SaaS, l'entreprise agit en tant que responsable du traitement et le fournisseur en tant que sous-traitant, ce qui exige un contrat de sous-traitance (art. 28 RGPD) avec des garanties explicites concernant la localisation des serveurs, les mesures de sécurité et les sous-traitants ultérieurs.

Si les serveurs du fournisseur se trouvent en dehors de l'Espace Économique Européen (EEE), le Chapitre V du RGPD (transferts internationaux) s'applique, ce qui — depuis l'annulation du Privacy Shield en 2020 — exige des clauses contractuelles types (CCT) adoptées par la Commission européenne ou des mécanismes équivalents. Le Comité Européen de la Protection des Données (CEPD) a émis des recommandations (01/2020 et suivantes) qui exigent également une évaluation de l'impact du transfert (TIA) lorsque les données vont vers des juridictions dotées de pouvoirs de surveillance incompatibles avec le RGPD.

Déployer le LLM sur votre propre serveur élimine à la racine cette chaîne d'obligations pour les données que vous traitez en interne. Le traitement existe toujours — et doit être documenté dans le Registre des Activités de Traitement — mais la communication à des tiers disparaît. Pour les secteurs assujettis à des obligations spécifiques (santé, services financiers, éducation), cela simplifie considérablement l'analyse des risques.

Si vous souhaitez approfondir la structuration de la gouvernance technique de l'IA pour vous conformer également à l'AI Act, consultez notre service d'IA souveraine et infrastructure privée, où nous abordons la couche technique et la couche réglementaire de façon intégrée.

Modèles open-weight disponibles en 2025-2026

L'écosystème de modèles exécutables localement a mûri de façon accélérée. En 2025 et 2026, il existe des options de haute qualité pour pratiquement tous les cas d'usage en entreprise :

Note sur les licences : «licence commerciale» signifie que vous pouvez utiliser le modèle pour créer de la valeur dans votre entreprise. Les restrictions varient (nombre maximum d'utilisateurs actifs mensuels, interdiction de concurrencer directement le fournisseur, etc.). Lisez toujours le texte complet avant la mise en production.

Matériel nécessaire : quel GPU ou CPU vous faut-il vraiment ?

L'inférence d'un LLM est intensive en mémoire vidéo (VRAM) lors d'une exécution sur GPU, ou en RAM conventionnelle lors d'une exécution sur CPU. La règle empirique : un modèle de N milliards de paramètres en précision FP16 nécessite environ N × 2 Go de mémoire. Avec la quantification INT4 (réduction de la précision avec une perte de qualité minimale), ce besoin est divisé par environ quatre.

• Modèles quantifiés 7-14 B (INT4) : exécutables sur un GPU grand public de 8-12 Go de VRAM (NVIDIA RTX 3080/4070) ou même sur CPU avec 32 Go de RAM. Vitesse : 20-40 tokens/seconde sur GPU, 3-8 tok/s sur un CPU moderne.
• Modèles quantifiés 30-70 B (INT4) : nécessitent un GPU professionnel de 24-48 Go (NVIDIA RTX 4090, A100 40 Go) ou deux cartes en parallèle. Vitesse : 15-30 tok/s.
• Modèles de 100+ B ou MoE importants : nécessitent plusieurs GPU A100/H100 ou un déchargement partiel en RAM (CPU offloading), avec des vitesses de 5-15 tok/s.

Pour une PME souhaitant un assistant interne sans investir dans des GPU haut de gamme, les modèles de 7-14 B quantifiés sur CPU offrent une qualité largement suffisante pour résumer des documents, rédiger des brouillons ou répondre à des requêtes sur des bases de connaissances internes. La vitesse sur CPU est plus lente, mais dans des flux non interactifs (analyse nocturne de contrats, classification d'e-mails en lot), cela ne pose pas de problème opérationnel.

Logiciels pour exécuter le modèle : Ollama, vLLM et LM Studio

Il existe trois plateformes dominantes en 2026 pour servir des LLMs sur infrastructure propre :

• Ollama : l'option la plus simple pour démarrer. Un unique binaire qui télécharge et exécute des modèles avec une seule commande (ollama run llama3.3). Il expose une API REST compatible avec la spécification OpenAI, ce qui facilite l'intégration avec les applications existantes. Idéal pour les pilotes et les environnements de développement. Limitation : non optimisé pour une forte concurrence.
• vLLM : le standard de fait pour la production avec plusieurs utilisateurs simultanés. Développé à UC Berkeley, il implémente PagedAttention pour maximiser le débit GPU. Expose une API compatible OpenAI. Requiert Linux et CUDA, mais supporte des dizaines de requêtes concurrentes sans dégradation sévère.
• LM Studio : interface bureau pour Windows et macOS. Parfait pour qu'un utilisateur non technique exécute un modèle localement sur son ordinateur portable. Non conçu pour un serveur partagé, mais valable pour des cas d'usage individuels où les données les plus sensibles ne peuvent en aucun cas quitter l'appareil.
• Llama.cpp : moteur d'inférence en C++ optimisé pour CPU (et GPU avec backends CUDA/Metal). C'est la base d'Ollama. Exécute des modèles GGUF quantifiés avec une grande efficacité sur du matériel conventionnel. Approprié si vous avez besoin d'une intégration bas niveau ou d'une portabilité maximale.

Architecture recommandée pour une PME de 20 à 150 employés

L'architecture la plus courante que nous déployons chez Summum pour les entreprises de cette taille combine trois couches :

1. Serveur d'inférence : une machine Linux (bare-metal ou VPS dédié dans un datacenter européen) faisant tourner vLLM ou Ollama avec le modèle choisi. Le serveur n'a pas d'accès sortant à internet, sauf pour des mises à jour planifiées et auditées.
2. Couche RAG : une base de données vectorielle (Qdrant, Chroma, Weaviate — toutes exécutables on-premise) qui indexe les documents internes de l'entreprise. Le LLM consulte cette base pour répondre avec le contexte réel de votre activité, et non avec une connaissance générique issue de l'entraînement. Plus d'informations dans notre service de RAG pour documents d'entreprise.
3. Couche applicative : un chatbot interne, un connecteur ERP ou une interface web légère (par exemple, Open WebUI, qui est open source et peut être déployé sur le même serveur) reliant les employés au système.

Tout le trafic circule sur le réseau interne (LAN ou VPN). Les données ne traversent jamais internet. Le journal des prompts et des réponses est stocké dans votre propre base de données, sous votre contrôle, ce qui facilite les audits internes et l'exercice des droits RGPD par les personnes concernées.

Combien coûte le déploiement d'un LLM on-premise : fourchettes indicatives du marché

Les chiffres suivants sont des fourchettes de marché au niveau européen en 2026, basées sur des projets comparables publiés par des intégrateurs et sur les prix actuels du matériel. Il ne s'agit pas des tarifs de Summum.

• Matériel GPU (achat) : une NVIDIA RTX 4090 (24 Go de VRAM) est proposée entre 1 800 € et 2 200 € dans le canal européen. Une A100 40 Go d'occasion se négocie autour de 8 000-12 000 €. Pour de petits modèles sur CPU, un serveur avec 64 Go de RAM DDR5 peut être assemblé pour 2 000-4 000 €.
• VPS GPU en Europe : des fournisseurs comme Hetzner GPU (A100 80 Go, Francfort/Helsinki) facturent entre 3,5 et 5 €/heure à la demande, ou 2 000-3 500 €/mois en instances réservées. Lambda Labs, Vast.ai et OVHcloud GPU ont des fourchettes similaires.
• Projet d'implémentation (conseil + intégration) : les intégrateurs européens spécialisés dans les LLMs privés facturent entre 8 000 € et 30 000 € selon la complexité (nombre d'utilisateurs, intégrations ERP, couche RAG, formation de l'équipe). Des projets pilotes avec un modèle 7B sans RAG peuvent être livrés pour moins de 10 000 €.
• Coût opérationnel mensuel : si le matériel est en propre, le coût dominant est l'électricité (une A100 consomme ~300 W, soit moins de 100 €/mois en fonctionnement continu) et la maintenance. S'il s'agit d'un VPS GPU, le coût est celui du loyer mensuel.

Ce que l'AI Act implique pour les modèles à usage interne

Le Règlement européen sur l'intelligence artificielle (AI Act, Règlement UE 2024/1689) est entré en vigueur en août 2024 et s'applique de façon échelonnée jusqu'en 2027. Pour une entreprise qui déploie un LLM à usage interne (sans le mettre à disposition de tiers en tant que produit), les obligations diffèrent de celles d'un fournisseur d'IA :

• Si le système n'est pas classé comme à haut risque (Annexe III de l'AI Act), les obligations sont minimales : usages interdits (art. 5) et bonnes pratiques volontaires.
• Si le système est utilisé pour prendre des décisions affectant significativement des employés ou des clients (évaluation du crédit, sélection du personnel, accès à des services essentiels), il peut tomber dans la catégorie à haut risque et nécessiter une documentation technique, un enregistrement dans la base de données européenne et des mesures de surveillance humaine.
• Les modèles d'IA à usage général (GPAI) ayant nécessité plus de 10^25 FLOPs d'entraînement comportent des obligations supplémentaires pour leurs créateurs, non pour ceux qui les déploient en local.

En pratique, la plupart des usages internes — assistant documentaire, résumé d'e-mails, génération de brouillons — ne sont pas à haut risque. Il est néanmoins utile de documenter le cas d'usage et de conserver cette évaluation.

Questions fréquentes

Est-il légal d'utiliser un modèle comme Llama ou Mistral dans mon entreprise ?

Oui, avec des nuances. Meta publie Llama 3 sous une licence communautaire autorisant l'usage commercial pour les entreprises comptant moins de 700 millions d'utilisateurs actifs mensuels, ce qui inclut toute PME. Mistral publie ses modèles sous licences Apache 2.0 ou propriétaires qui autorisent également l'usage commercial. Vous devez lire la licence spécifique du modèle que vous choisissez : certaines interdisent de l'utiliser pour entraîner d'autres modèles ou pour certains secteurs. Si le modèle est déployé sans accès internet sortant et uniquement pour un usage interne, le risque de manquement contractuel est minimal, mais une révision juridique reste conseillée.

Puis-je garantir à 100 % qu'aucune donnée ne quitte le serveur ?

Techniquement, oui, si l'architecture est correctement configurée. Le modèle d'inférence n'effectue pas d'appels réseau sortants par lui-même. Ce que vous devez contrôler, c'est que les outils qui l'entourent (le serveur d'API, la couche applicative, les connecteurs ERP) n'effectuent pas non plus de transmissions non prévues. Un pare-feu de sortie (egress firewall) bloquant tout le trafic sortant du serveur d'IA sauf ce qui est strictement nécessaire est la mesure technique complémentaire indispensable. Du point de vue du RGPD, la garantie technique élimine la communication de données ; la garantie documentaire l'accrédite en cas d'inspection de la CNIL ou de toute autorité de contrôle nationale.

Quelle qualité offre un modèle local par rapport à GPT-4o ?

L'écart s'est considérablement réduit entre 2024 et 2026. Des modèles comme Llama 3.3 70B ou Mistral Large 2 atteignent des scores comparables à GPT-3.5 sur les benchmarks standard (MMLU, HumanEval) et se rapprochent de GPT-4 sur des tâches spécifiques. Pour des cas d'usage bien délimités — répondre à des questions sur des documents propres, classifier des e-mails, rédiger dans un style défini — un modèle de 70B quantifié est parfaitement fonctionnel en production. La différence la plus notable persiste dans le raisonnement complexe multi-étapes et dans les tâches impliquant des contextes très longs et ambigus. Pour ces cas, une architecture hybride (local pour le quotidien, API externe avec DPA signé pour les requêtes critiques) peut être la solution la plus pragmatique.

Comment cela affecte-t-il la conformité au RGPD si j'externalise le serveur chez un fournisseur cloud européen ?

Si le serveur où s'exécute le modèle est hébergé dans un datacenter européen (Allemagne, France, Espagne, Pays-Bas…) exploité par un fournisseur avec DPA signé, le traitement reste au sein de l'EEE. Il n'y a pas de transfert international. Vous demeurez responsable du traitement et le fournisseur d'hébergement est un sous-traitant au titre de l'art. 28, mais c'est la même relation que celle que vous avez déjà avec votre fournisseur de messagerie ou votre ERP dans le cloud. La différence avec un SaaS d'IA est que le sous-traitant n'a pas accès au contenu des prompts, seulement à l'infrastructure physique. Des fournisseurs comme Hetzner (Allemagne) ou Scaleway (France) sont basés dans l'UE et proposent des contrats RGPD standard.

Conclusion : la souveraineté des données comme avantage concurrentiel

Déployer un LLM sur infrastructure propre n'est plus une option réservée aux grandes entreprises dotées d'équipes MLOps. En 2026, une PME disposant d'un budget raisonnable peut disposer d'un assistant IA puissant, entièrement sous son contrôle, avec des garanties techniques et réglementaires qu'aucun SaaS standard ne peut offrir. La clé réside dans le choix du modèle adapté au matériel disponible, l'utilisation de plateformes d'inférence matures et la documentation correcte du traitement dès le premier jour. Si votre secteur travaille avec des données sensibles, cet investissement n'est pas une dépense technologique : c'est un levier de confiance vis-à-vis de vos clients et de vos auditeurs.

Chez Summum, nous accompagnons depuis 2007 les entreprises dans le déploiement de technologie avec rigueur réglementaire. Si vous souhaitez évaluer si un déploiement on-premise correspond à votre cas concret, notre équipe d'IA souveraine peut réaliser cette analyse préalable avec vous.