Solution française • Hébergement souverain • Conformité européenne Blog IA souveraine

Chapitre 3 — Le choix technologique : LLM, infrastructure et modèles de déploiement

Le choix du bon LLM et de la bonne infrastructure est la décision la plus structurante d'un projet IA souverain. Trop souvent, les équipes choisissent un modèle par défaut (le plus connu, le plus médiatisé) sans analyser ses performances réelles sur leurs cas d'usage, ni son coût total de possession. Ce chapitre du Livre Blanc IA Souveraine pour DSI 2026 donne les outils pour prendre cette décision avec méthode.

Cet article fait partie de la série Livre Blanc IA Souveraine pour DSI 2026 — une ressource premium en 6 chapitres. Vous lisez le Chapitre 3 (Technologie). Les autres chapitres :

Panorama des modèles LLM souverains disponibles en 2026

Le marché des modèles de langage souverains a considérablement mûri depuis 2024. En 2026, les entreprises françaises disposent d'un écosystème de modèles performants, conformes à la réglementation européenne, et disponibles pour un déploiement on-premise ou sur cloud souverain. Voici le panorama des principales options :

ELODIE — Le modèle français de référence

ELODIE (développé par Intelligence Privée) est un modèle de langage conçu spécifiquement pour les besoins des entreprises françaises. La version 32B (32 milliards de paramètres) est la version de production recommandée pour la majorité des cas d'usage enterprise.

  • Paramètres : 32B (version standard) et 7B (version edge/embarquée)
  • VRAM requise : 64 Go (32B en FP16), 32 Go (32B en quantification 8-bit), 16 Go (32B en quantification 4-bit Q4_K_M)
  • Langues : Français natif (premier modèle optimisé pour le français juridique, administratif et technique), anglais, espagnol, allemand, italien
  • Licence : Commerciale propriétaire, déploiement on-premise inclus dans la licence enterprise, pas de restriction de secteur
  • Conformité : Entraîné exclusivement sur des données de sources européennes documentées, conforme aux exigences de transparence AI Act GPAI, RGPD by design
  • Points forts : Performances supérieures sur les tâches juridiques françaises (analyse de contrats, synthèse réglementaire), droit du travail, comptabilité française, administration publique
  • KEVINA 32B : Variante spécialisée pour les secteurs réglementés (santé, finance, assurance) avec des guardrails renforcés et une traçabilité augmentée des décisions

Mistral — L'écosystème ouvert français

Mistral AI (Paris) a développé une gamme de modèles qui couvre l'ensemble des besoins enterprise :

  • Mistral 7B / 7B Instruct : Modèle léger, licence Apache 2.0 (usage commercial libre), idéal pour les tâches de classification, extraction d'information, et résumé. VRAM : 16 Go (FP16), 8 Go (Q4). Performances comparables à LLaMA 2-13B sur la plupart des benchmarks.
  • Mistral Small 3 (24B) : Excellent équilibre performance/coût pour les applications entreprise à fort volume. VRAM : 48 Go (FP16), 24 Go (Q4). Licence Apache 2.0.
  • Mistral Large 2 (123B) : Niveau de performance comparable à GPT-4 sur les tâches de raisonnement complexe, code, et analyse. VRAM : 250 Go (FP16, nécessite multi-GPU), ou 65 Go en quantification aggressive. Licence commerciale Mistral.
  • Codestral : Modèle spécialisé code (22B), apache 2.0, optimisé pour le code Python, JavaScript, SQL, Java. VRAM : 44 Go FP16.
  • Mistral Embed : Modèle d'embedding pour RAG, performant sur le français, disponible via API ou déploiement local.

Meta LLaMA — L'open source de référence

La famille LLaMA 3 (Meta) offre des modèles de très haute performance sous licence open source permettant un déploiement commercial :

  • LLaMA 3.1 8B : Remarquablement performant pour sa taille. Licence Meta LLaMA 3 (commerciale libre jusqu'à 700M utilisateurs mensuels). VRAM : 16 Go FP16, 6 Go Q4.
  • LLaMA 3.1 70B : Niveau de performance proche de GPT-4 Turbo sur la plupart des tâches. VRAM : 140 Go FP16 (2x H100 80G minimum), ou 40 Go Q4. Excellent pour le fine-tuning sectoriel.
  • LLaMA 3.1 405B : Le modèle open source le plus performant disponible. VRAM : 810 Go FP16 (cluster multi-GPU), ou 220 Go Q4. Réservé aux très grands déploiements ou aux cas d'usage à très haute exigence de précision.
  • LLaMA 3.2 Vision : Modèle multimodal (texte + image), 11B et 90B. Idéal pour l'analyse de documents avec images, factures, plans, radiographies.

Qwen — L'alternative performante

Les modèles Qwen (Alibaba) méritent une mention spéciale pour leurs performances techniques exceptionnelles, notamment sur les tâches de code et de raisonnement mathématique. Cependant, leur origine chinoise soulève des questions de gouvernance des données d'entraînement et de dépendance géopolitique similaires (sous un angle différent) aux modèles américains. Pour les entreprises soumises à des obligations de sécurité nationale (OIV, secteur défense), Qwen est généralement exclu. Pour les autres, Qwen 2.5 72B offre des performances intéressantes sous licence Apache 2.0 avec VRAM : 144 Go FP16.

32Bparamètres ELODIE — le sweet spot performance/coût pour 90% des cas enterprise
64 GoVRAM minimum pour ELODIE 32B en FP16 (1x H100 80G suffisant)
Apache 2.0Licence Mistral 7B et LLaMA 3.1 — usage commercial libre sans redevance
3architectures de déploiement souverain : on-premise, cloud souverain, hybride

Comparatif : on-premise vs cloud souverain vs cloud américain

Le choix de l'architecture de déploiement est aussi important que le choix du modèle. Voici une analyse multicritères sur 20 dimensions :

Critère On-premise Cloud souverain (OVH, Scaleway, Outscale) Cloud américain (AWS/Azure/GCP)
Souveraineté des données ⭐⭐⭐⭐⭐ Totale ⭐⭐⭐⭐ Très bonne ⭐⭐ Limitée (Cloud Act)
Conformité RGPD ⭐⭐⭐⭐⭐ Native ⭐⭐⭐⭐ Très bonne ⭐⭐⭐ Possible avec effort
Conformité AI Act ⭐⭐⭐⭐⭐ Maximale ⭐⭐⭐⭐ Très bonne ⭐⭐⭐ Partielle
Conformité NIS2/OIV ⭐⭐⭐⭐⭐ Maximale ⭐⭐⭐⭐ Bonne (si SecNumCloud) ⭐ Non recommandé
Coût infrastructure initial ⭐⭐ Élevé (150-500k€) ⭐⭐⭐⭐ Faible (abonnement) ⭐⭐⭐⭐ Faible (pay-as-you-go)
Coût récurrent (TCO 3 ans) ⭐⭐⭐⭐ Meilleur sur 3 ans ⭐⭐⭐ Modéré ⭐⭐ Élevé à fort volume
Délai de déploiement ⭐⭐ 3-6 mois ⭐⭐⭐⭐ 1-2 mois ⭐⭐⭐⭐⭐ Jours/semaines
Scalabilité ⭐⭐ Limitée par hardware ⭐⭐⭐⭐ Bonne ⭐⭐⭐⭐⭐ Excellente
Latence inférence ⭐⭐⭐⭐⭐ Excellente (réseau local) ⭐⭐⭐⭐ Très bonne ⭐⭐⭐⭐ Très bonne
Personnalisation / fine-tuning ⭐⭐⭐⭐⭐ Totale ⭐⭐⭐⭐ Très bonne ⭐⭐⭐ Variable selon fournisseur
Contrôle de la version du modèle ⭐⭐⭐⭐⭐ Total ⭐⭐⭐⭐ Bonne ⭐⭐ Dépendant fournisseur
Auditabilité complète ⭐⭐⭐⭐⭐ Maximale ⭐⭐⭐⭐ Très bonne ⭐⭐ Limitée
Disponibilité SLA ⭐⭐⭐ Dépend de l'infra interne ⭐⭐⭐⭐ 99.9% typique ⭐⭐⭐⭐⭐ 99.99% typique
Besoin en compétences internes ⭐⭐ Élevé (MLOps, DevOps GPU) ⭐⭐⭐⭐ Modéré ⭐⭐⭐⭐⭐ Faible (managed services)
Intégration SSO / IAM existant ⭐⭐⭐⭐⭐ Native ⭐⭐⭐⭐ Très bonne ⭐⭐⭐⭐ Très bonne
Risque fournisseur (vendor lock-in) ⭐⭐⭐⭐⭐ Nul ⭐⭐⭐⭐ Faible ⭐⭐ Élevé
Consommation énergétique maîtrisée ⭐⭐⭐⭐⭐ PUE connu ⭐⭐⭐⭐ Bons PUE ⭐⭐⭐ Variable
Certifications sécurité disponibles ⭐⭐⭐⭐ ISO 27001 possible ⭐⭐⭐⭐⭐ SecNumCloud, HDS, ISO 27001 ⭐⭐⭐ ISO 27001, SOC2
Adaptation à la réglementation FR ⭐⭐⭐⭐⭐ Totale ⭐⭐⭐⭐⭐ Totale ⭐⭐ Partielle
Recommandation pour OIV / Défense ✅ Oui ⚠️ Conditionnel (SecNumCloud requis) ❌ Non

GPU economics : H100, A100, L40S — achat vs location vs cloud

L'infrastructure GPU est le coeur d'un déploiement IA souverain. Les choix faits ici ont un impact direct sur le TCO, la performance, et la flexibilité de votre architecture. En 2026, trois GPU serveur dominent le marché enterprise :

NVIDIA H100 SXM5 80 Go

Le GPU de référence pour les LLM enterprise. Performances exceptionnelles en FP8 et FP16, interconnexion NVLink pour les configurations multi-GPU, support du Transformer Engine. En 2026, le H100 est disponible en quantités plus importantes qu'en 2024 (résolution partielle des pénuries), mais reste le composant le plus coûteux d'un déploiement IA souverain.

  • Prix d'achat (2026) : 25 000 à 35 000 € par GPU, serveur complet 8x H100 : 350 000 à 500 000 €
  • Location mensuelle : 3 000 à 4 500 €/GPU/mois chez les opérateurs français (OVHcloud, Scaleway, Gcore)
  • Modèles supportés : Tous (LLaMA 405B en multi-GPU, ELODIE 32B sur 1 GPU, Mistral Large 2 sur 4 GPU)
  • Durée d'amortissement recommandée : 36 mois (évolution rapide du matériel)
  • Point fort : Meilleur en inférence pour les très grands modèles (70B+)

NVIDIA A100 SXM4 80 Go

La génération précédente, mais encore très pertinente pour les modèles jusqu'à 70B. Souvent disponible à moindre coût que le H100, avec des performances très proches pour les modèles de taille intermédiaire (32B-70B) en inférence.

  • Prix d'achat (2026) : 12 000 à 18 000 € par GPU, serveur complet 8x A100 : 180 000 à 280 000 €
  • Location mensuelle : 1 800 à 2 800 €/GPU/mois
  • Meilleur usage : ELODIE 32B, Mistral Large, LLaMA 70B — excellent rapport performance/coût
  • Limitation : Moins efficace que le H100 pour les modèles >100B, pas de support FP8 natif

NVIDIA L40S 48 Go

Le GPU «milieu de gamme enterprise» de 2025, particulièrement adapté aux déploiements d'inférence à volume modéré. Son prix est significativement plus accessible, et ses performances sur les modèles ≤32B sont excellentes.

  • Prix d'achat (2026) : 7 000 à 10 000 € par GPU, serveur complet 4x L40S : 45 000 à 70 000 €
  • Location mensuelle : 800 à 1 500 €/GPU/mois
  • Meilleur usage : ELODIE 32B Q8, Mistral Small, LLaMA 8B — modèles ≤32B quantifiés
  • Point fort : Excellent rapport performance/coût pour les organisations avec un volume d'inférence modéré (< 100 req/min)
  • Limitation : 48 Go VRAM limitent les modèles non quantifiés à ≤30B

Achat vs location vs cloud : analyse de la décision

La règle générale : au-delà de 18-24 mois d'usage continu, l'achat devient plus économique que la location. Mais plusieurs facteurs peuvent inverser ce calcul :

  • Incertitude sur les besoins futurs : Si vous n'êtes pas sûr de vos besoins à 3 ans, commencez par louer. Convertissez en achat une fois le volume stabilisé.
  • Compétences internes : L'achat de GPU serveur nécessite des compétences MLOps/infrastructure que toutes les organisations n'ont pas. La location via un cloud souverain externalise cette complexité.
  • Flexibilité des modèles : Le marché des LLM évolue vite. Louer vous permet de switcher de GPU sans coût de revente. Acheter fige votre architecture pendant 3 ans.
  • Budget initial : Un serveur 8x H100 nécessite un CAPEX de 400 000 à 500 000 € que toutes les ETI n'ont pas. La location transforme ce CAPEX en OPEX.

Architectures de référence : RAG, fine-tuning, agents

Architecture 1 : RAG (Retrieval-Augmented Generation)

Le RAG est l'architecture à privilégier pour la grande majorité des cas d'usage enterprise. Le principe : au lieu de fine-tuner le modèle sur vos données internes (coûteux et rigide), vous créez une base de connaissances vectorielle qui est requêtée à chaque inférence. Le LLM répond en se basant à la fois sur sa connaissance générale et sur les documents pertinents récupérés en temps réel.

Composants d'une architecture RAG souveraine :

  • LLM principal : ELODIE 32B ou Mistral Large 2 (génération des réponses)
  • Modèle d'embedding : Mistral Embed ou un modèle d'embedding open source (E5-large-v2, BGE-M3) pour vectoriser les documents
  • Base de données vectorielle : Qdrant, Milvus, Weaviate, ou pgvector (extension PostgreSQL) — tous disponibles en déploiement on-premise
  • Pipeline d'ingestion : Traitement des documents source (PDF, Word, e-mails, tickets, pages web) : extraction, découpage en chunks, vectorisation, indexation
  • Orchestrateur : LangChain, LlamaIndex, ou Haystack pour gérer le flux requête → retrieval → génération

Quand utiliser le RAG : Base de connaissances qui évolue fréquemment (actualisation hebdomadaire ou plus), documents propriétaires confidentiels (ne jamais inclure dans les données d'entraînement), besoin de traçabilité (le RAG permet de citer les sources), déploiement rapide sans phase d'entraînement.

Limitations du RAG : Le modèle doit avoir la capacité de synthétiser des informations parfois contradictoires dans les documents récupérés. La qualité du retrieval (pertinence des chunks retournés) est critique — un mauvais retrieval génère des réponses erronées même avec un excellent LLM. La limite de contexte du LLM contraint le nombre de chunks utilisables simultanément.

Architecture 2 : Fine-tuning (SFT et RLHF)

Le fine-tuning consiste à réentraîner partiellement le modèle sur des données spécifiques à votre domaine ou vos usages. Il existe deux grandes approches :

Supervised Fine-Tuning (SFT) : Entraînement sur des exemples paires (instruction → réponse idéale). Permet de spécialiser le modèle sur un style de réponse, un domaine métier, ou un format de sortie particulier. Coût : de 5 000 à 50 000 € selon la taille du modèle et le volume de données, sur GPU A100/H100. Durée : 2 à 14 jours.

LoRA / QLoRA : Techniques de fine-tuning à faible rang qui permettent d'adapter un grand modèle à un coût bien inférieur en n'entraînant qu'une fraction des paramètres. Un fine-tuning QLoRA d'ELODIE 32B peut être réalisé sur un seul A100 80G en 3 à 7 jours, pour un coût de calcul de 2 000 à 5 000 €. Les performances sont comparables au SFT complet pour la plupart des tâches de spécialisation.

Quand utiliser le fine-tuning : Style ou format de réponse très spécifique (terminologie métier, format de sortie structuré), performances insuffisantes du RAG sur des tâches nécessitant une connaissance implicite du domaine, volume de requêtes très élevé (le fine-tuning réduit la complexité des prompts nécessaires, donc la latence), données d'entraînement suffisamment volumineuses et de qualité.

Mise en garde critique : Ne jamais fine-tuner un modèle sur des données personnelles si vous ne pouvez pas garantir la gestion du droit à l'effacement. Un modèle fine-tuné «mémorise» des éléments de ses données d'entraînement, et l'effacement de données personnelles d'un modèle entraîné est techniquement très difficile. Préférez le RAG pour les données personnelles.

Architecture 3 : Agents IA

Les agents IA sont des systèmes où le LLM peut prendre des décisions séquentielles, utiliser des outils (recherche web, API, code, fichiers), et accomplir des tâches complexes en plusieurs étapes. En 2026, les architectures agentiques ont considérablement mûri.

Composants d'un agent IA souverain :

  • LLM de raisonnement : ELODIE 32B ou Mistral Large 2 (prise de décision, planification)
  • Outils intégrés : Recherche documentaire (RAG), exécution de code (Python sandbox), accès API (CRM, ERP, ITSM), navigation web (via un proxy interne)
  • Mémoire : Contexte de session (short-term memory) et base de données persistante (long-term memory)
  • Orchestrateur agentique : LangGraph, CrewAI, AutoGen, ou développement custom
  • Guardrails : Contrôles de sécurité sur les actions autorisées (whitelist d'API, sandboxing du code)

Cas d'usage agentiques matures en 2026 : Analyse automatisée de documents juridiques et extraction d'informations contractuelles, support IT niveau 1-2 avec résolution automatique des tickets simples, génération de rapports financiers à partir de données multi-sources, qualification et pré-analyse de leads commerciaux, veille réglementaire avec synthèse et alertes.

Arbre de décision : quand choisir quoi

Utilisez cet arbre de décision pour identifier rapidement la bonne architecture :

1. Vos données internes doivent-elles enrichir les réponses du LLM ?

→ Non : Utilisez le modèle de base (ELODIE 32B ou Mistral) sans RAG ni fine-tuning. Idéal pour rédaction générale, code, traduction, résumé de documents fournis dans le prompt.

→ Oui → Question 2.

2. Vos données évoluent-elles fréquemment (weekly ou plus) ?

→ Oui : Utilisez le RAG. Vos données sont mises à jour dans la base vectorielle sans toucher au modèle.

→ Non → Question 3.

3. Avez-vous besoin d'un style de réponse ou d'un format très spécifique ?

→ Oui : Combinez RAG + fine-tuning (SFT ou LoRA). Le RAG pour les données, le fine-tuning pour le style.

→ Non → Question 4.

4. La tâche nécessite-t-elle plusieurs étapes, des décisions, et l'utilisation d'outils ?

→ Oui : Architecture agentique (LangGraph + outils). Exemple : analyser un dossier, interroger une API, rédiger un rapport.

→ Non : RAG simple. C'est l'architecture la plus simple, la plus robuste et la plus facile à maintenir.

Stack technologique recommandée par cas d'usage

Cas d'usage Modèle recommandé Architecture GPU minimum Coût mensuel estimé
Assistant juridique (analyse contrats) ELODIE 32B ou KEVINA 32B RAG + fine-tuning LoRA 1x A100 80G 2 500 - 4 000 €
Support client (chatbot) Mistral Small 3 (24B) RAG 1x L40S 48G 1 000 - 2 000 €
Assistance au code (développeurs) Codestral 22B + LLaMA 8B Modèle de base 1x L40S 48G 800 - 1 500 €
Analyse de données financières KEVINA 32B Agent IA + RAG 2x A100 80G 4 000 - 7 000 €
RH (tri CV, assistant recruteur) ELODIE 32B RAG + guardrails AI Act 1x A100 80G 2 500 - 4 000 €
Production de contenu marketing Mistral Large 2 ou ELODIE 32B Modèle de base 1x L40S 48G 800 - 1 500 €
Analyse de documents médicaux KEVINA 32B (HDS certifié) RAG + fine-tuning médical 2x H100 80G 7 000 - 12 000 €
Veille réglementaire automatisée Mistral Small 3 + Mistral Embed Agent IA + RAG 1x L40S 48G 1 000 - 2 000 €

Intégration dans le SI existant

Authentification et contrôle d'accès (SSO)

Tout LLM souverain déployé en enterprise doit s'intégrer au système d'identité existant. En pratique, cela signifie :

  • SAML 2.0 / OIDC : Les serveurs d'inférence LLM (vLLM, Ollama Enterprise, TGI) doivent être positionnés derrière un reverse proxy qui gère l'authentification SSO (Keycloak, Azure AD, Okta). Aucun utilisateur ne doit pouvoir accéder au LLM sans s'authentifier via le référentiel d'identité centralisé.
  • RBAC (Role-Based Access Control) : Les accès au LLM doivent être granulaires : qui peut accéder à quel modèle, avec quelles données de contexte, avec quelles permissions d'action (lecture seule vs agents capables d'écrire dans des systèmes tiers).
  • Audit trail : Chaque requête au LLM doit être journalisée avec : identifiant utilisateur, timestamp, modèle utilisé, tokens consommés, et idéalement un hash du prompt (pas nécessairement le prompt complet pour des raisons de confidentialité).

Architecture API

Le LLM souverain doit exposer une API compatible OpenAI (format standard de facto de l'industrie) pour faciliter l'intégration avec les outils existants. Les serveurs d'inférence modernes (vLLM, Ollama, TGI) supportent tous ce format. Cela permet de migrer vers un LLM souverain en changeant uniquement l'URL de l'API et la clé d'authentification dans vos applications existantes.

Monitoring et observabilité

Dès le déploiement initial, intégrez :

  • Prometheus + Grafana : Pour les métriques d'infrastructure (utilisation GPU, VRAM, latence, débit)
  • LangSmith ou Phoenix Arize : Pour les métriques applicatives LLM (qualité des réponses, hallucinations détectées, coût par requête)
  • Alerting : Alertes sur la latence p99, les erreurs 5xx, la saturation VRAM, et les anomalies de pattern d'utilisation

Gestion du cycle de vie des modèles

Un LLM déployé en production n'est pas statique. La gestion de son cycle de vie inclut :

Versioning : Traitez vos modèles comme du code. Utilisez un registre de modèles (MLflow, Weights & Biases) pour versionner chaque modèle et chaque fine-tune. Gardez les 3 dernières versions déployées pour permettre un rollback rapide.

Tests avant mise en production : Toute nouvelle version de modèle ou nouveau fine-tuning doit passer par un pipeline de tests automatisés : benchmarks de performance sur votre jeu d'évaluation interne, tests de régression sur les cas d'usage critiques, tests de sécurité (prompt injection, jailbreak), tests de biais sur vos données.

Déploiement canary : Déployez les nouvelles versions du modèle progressivement (5 % du trafic, puis 20 %, puis 100 %) avec comparaison automatique des métriques entre ancienne et nouvelle version. Le Chapitre 6 détaille les procédures MLOps complètes.

Planification de la mise à jour : Les modèles de base évoluent (nouvelles versions de Mistral, ELODIE, LLaMA). Planifiez une évaluation trimestrielle des nouvelles versions disponibles par rapport à votre jeu de benchmarks interne. Ne mettez pas à jour le modèle de base sans une évaluation rigoureuse sur vos cas d'usage réels — les améliorations générales peuvent induire des régressions sur des tâches spécialisées.

Ce qu'il faut retenir

  • En 2026, les modèles souverains (ELODIE 32B, Mistral Large 2, LLaMA 3.1 70B) offrent des performances comparables aux modèles américains sur la quasi-totalité des tâches enterprise, avec une supériorité notable sur le français juridique et administratif.
  • Le RAG est l'architecture à privilégier pour 80 % des cas d'usage enterprise : plus simple, plus maintenable, plus conforme au RGPD que le fine-tuning sur données personnelles.
  • Le L40S 48G est le meilleur GPU rapport qualité/prix pour les modèles ≤32B. Le A100 80G est le référence pour 32B-70B. Le H100 est nécessaire uniquement pour les modèles >70B ou les très hauts débits.
  • L'intégration SSO, l'audit trail et le RBAC sont non-négociables pour un déploiement enterprise — ils doivent être prévus dès la phase de conception.
  • Gérez vos modèles comme du code : versioning, tests, déploiement canary, rollback.

Questions fréquentes

ELODIE 32B vs Mistral Large 2 : lequel choisir ?

Pour des tâches impliquant du contenu juridique, administratif ou réglementaire français, ELODIE 32B est supérieur. Pour des tâches de raisonnement général, de code, ou multilingues complexes, Mistral Large 2 (123B) est plus puissant — mais nécessite une infrastructure plus conséquente. Pour les organisations souhaitant une solution clé en main avec support éditeur français, ELODIE est le choix naturel. Pour les organisations ayant des équipes MLOps solides souhaitant maximiser la personnalisation, Mistral (open source pour les modèles ≤24B) offre plus de flexibilité.

Peut-on utiliser des modèles quantifiés en production enterprise ?

Oui, avec précautions. La quantification 8-bit (GGUF Q8, GPTQ 8-bit) est quasiment sans perte de performance et divise par 2 les besoins en VRAM — recommandée sans restriction. La quantification 4-bit (Q4_K_M) réduit les besoins en VRAM de 4x avec une perte de performance de 2 à 5 % selon les benchmarks — acceptable pour la plupart des tâches de génération de texte et de résumé. Pour les tâches de raisonnement complexe, d'analyse juridique précise, ou de génération de code critique, préférez la quantification 8-bit ou le modèle pleine précision.

Quelles sont les alternatives françaises à vLLM pour servir les modèles ?

vLLM est actuellement le standard de facto pour servir des LLM en production à haute performance (optimisation PagedAttention, débit élevé). Parmi les alternatives : TGI (Text Generation Inference, de Hugging Face, franco-français) est excellente et très utilisée ; Ollama simplifie le déploiement pour les environnements moins critiques ou le développement ; LM Studio est adapté aux postes de travail individuels. Pour la production enterprise, vLLM ou TGI sont les deux choix recommandés.

Conclusion

Le choix technologique d'une IA souveraine n'est plus un choix entre conformité et performance : c'est un choix d'architecture et d'ingénierie comme un autre. Les modèles et l'infrastructure existent, sont matures, et offrent des performances excellentes pour les besoins enterprise.

La clé est de commencer avec un cas d'usage concret, une infrastructure dimensionnée pour ce cas d'usage (et pas pour tous les usages futurs imaginables), et une architecture RAG qui permet l'évolution sans verrouillage technologique. Le Chapitre 4 de ce Livre Blanc détaille la méthode de déploiement — de l'audit initial à l'industrialisation — en incluant la sécurité by design et la gouvernance.

Benchmark ELODIE sur vos cas d'usage réels

Nos architectes IA mettent en place un environnement de test avec ELODIE 32B et KEVINA 32B sur vos données réelles (anonymisées) et vos 3 cas d'usage prioritaires. Livrable : rapport comparatif de performance vs votre solution actuelle, avec recommandation d'architecture et estimation de TCO.

Demander un benchmark personnalisé →