Comment déployer un LLM on-premise ?

Déployer un modèle sur votre propre infrastructure n’est plus réservé aux géants. Voici ce que cela suppose réellement — les modèles à poids ouverts (Llama, Mistral, Qwen), le matériel, et ce qui prend du temps (ce n’est pas le modèle).

Mis à jour le 10 juillet 2026

Pourquoi on-premise

Une seule raison, mais décisive : la donnée sensible ne quitte jamais votre périmètre.

Pas de transfert hors UE.
Pas de dépendance à la politique de rétention d’un tiers.
Pas de question sur ce que devient votre corpus.

Pour de la donnée réglementée — santé, finance, RH — c’est souvent le seul montage défendable.

Les modèles à poids ouverts

En 2026, la génération actuelle de modèles à poids ouverts (Llama, Mistral, Qwen et leurs dérivés) atteint, sur la plupart des tâches d’entreprise — extraction, classification, rédaction assistée, questions-réponses sur documents — un niveau qui rend le recours à une API propriétaire inutile. La question n’est plus « est-ce assez bon », mais « lequel pour quelle tâche, à quel coût d’inférence ». L’écart avec les meilleures API propriétaires s’est resserré à quelques points sur ces usages courants ; il reste net sur le raisonnement le plus exigeant.

L’infrastructure, sans mystique

Un modèle de taille moyenne quantifié tourne sur une seule carte de génération récente — une NVIDIA H100 (80 Go) ou RTX PRO 6000 Blackwell (96 Go) porte un modèle de plusieurs dizaines de milliards de paramètres. Inutile de viser un cluster dès le départ.
Cloud souverain / UE ou machine sur site : les deux comptent comme « on-premise » au sens qui importe — la donnée reste sous votre contrôle et votre juridiction.
L’inférence se sert derrière une API interne (vLLM, Ollama, TGI), ce qui rend le modèle interchangeable sans toucher aux applications qui l’appellent.

L’anonymisation en amont

Même sur un modèle que vous hébergez, la bonne pratique est de pseudonymiser les données identifiantes avant l’inférence : cela limite la surface en cas d’incident et simplifie l’analyse d’impact RGPD. La brique d’anonymisation se place devant le modèle, pas dedans — encore faut-il savoir ce qui distingue anonymisation et pseudonymisation, car l’une seule sort du RGPD.

Coût et délai réels

Comptez six à douze semaines pour un premier système en production, la donnée étant disponible. Le temps ne part pas dans le modèle : il part dans les accès, les droits, l’intégration au système d’information et la reprise des cas limites.

Côté matériel, une carte H100 louée dans un cloud européen revient de l’ordre de 2,5 à 3 € HT l’heure, soit environ 2 000 € par mois en fonctionnement continu — l’essentiel du budget d’un projet reste le temps humain, pas le calcul.

Questions fréquentes

Faut-il acheter des GPU coûteux ?

Pas pour commencer. Un modèle quantifié de taille moyenne tourne sur un seul GPU récent, loué à l’heure dans un cloud UE le temps de valider l’usage. On dimensionne le matériel une fois la charge réelle connue, pas avant.

Un modèle ouvert est-il vraiment au niveau de GPT ou Claude ?

Sur les tâches d’entreprise courantes, oui. Les écarts se creusent sur le raisonnement long ou les usages très généralistes — rarement le cœur d’un système métier bien cadré. La bonne comparaison n’est pas « lequel est le meilleur dans l’absolu » mais « lequel suffit pour cette tâche, à quel coût et sous quelle contrainte de données ».

Est-ce compatible avec l’EU AI Act ?

Le lieu d’hébergement ne détermine pas à lui seul votre statut au titre de l’AI Act — c’est le cas d’usage qui compte. Mais l’on-premise facilite nettement la documentation technique et la maîtrise des données qu’exigent les obligations.

Sources

CNIL — IA : les recommandations

Ressource liée

Agence IA →

Les trois métiers que recouvre le mot « agence IA », les questions à poser avant de signer, et pourquoi la conformité AI Act se décide au cadrage. Paris.