Serveur IA local : RAG, fine-tuning et déploiement on-premise

La demande revient chaque mois, formulée à peu près toujours pareil : « on aimerait utiliser l'IA sur nos documents internes, mais il est hors de question qu'ils partent chez OpenAI ». C'est une demande parfaitement légitime, et techniquement réalisable. Elle est aussi, dans une bonne moitié des cas, mal dimensionnée : on nous demande un cluster de GPU pour un besoin que trois documents PDF et un moteur de recherche sémantique auraient couvert.

Cet article décrit ce qu'implique réellement un serveur d'inférence local : le matériel nécessaire, le choix entre RAG et fine-tuning, le coût total sur trois ans, et les situations dans lesquelles nous déconseillons franchement l'opération.

Pourquoi héberger son IA soi-même

Trois raisons tiennent la route, et une quatrième n'en est pas une.

La confidentialité des donnéesest la première, et de loin la plus fréquente. Cabinets d'avocats, bureaux d'études, sous-traitants industriels sous NDA, structures de santé : pour eux, envoyer un document client vers une API tierce n'est pas un arbitrage technique mais une faute contractuelle. Le RGPD tolère le transfert hors UE sous conditions ; un contrat de confidentialité client, souvent pas.

La prévisibilité des coûtsvient ensuite. Une facturation au token est confortable au démarrage et devient inconfortable dès qu'un usage se généralise en interne. Un serveur amorti a un coût fixe : le millionième appel coûte le prix de l'électricité.

La stabilité du modèleest le motif le plus sous-estimé. Un fournisseur cloud déprécie ses modèles, ajuste ses filtres de sécurité et modifie subtilement le comportement de son API. Un modèle open-source posé sur votre serveur produira les mêmes sorties dans deux ans. Pour tout ce qui touche à de la conformité ou à de l'archivage, cette reproductibilité vaut cher.

En revanche, le coût brut n'est presque jamais un bon argument. Sur des volumes modestes, une API commerciale reste moins chère qu'un serveur amorti, électricité et temps d'administration compris. Si votre seule motivation est d'économiser sur une facture d'API à 80 € par mois, l'opération n'a pas de sens.

RAG ou fine-tuning : la confusion la plus coûteuse

C'est l'erreur d'aiguillage la plus fréquente, et la plus chère. Les deux approches répondent à des questions différentes :

Le RAG (Retrieval-Augmented Generation) répond à « le modèle doit connaître mes données ». On découpe les documents, on les indexe sous forme vectorielle, et à chaque question on injecte les passages pertinents dans le contexte du modèle. Les données restent externes au modèle : ajouter un document, c'est réindexer, pas réentraîner. C'est ce que veulent 90 % des entreprises qui demandent du fine-tuning.

Le fine-tuningrépond à « le modèle doit se comporter différemment » : adopter un format de sortie strict, un ton, un vocabulaire métier, une structure de réponse. Il modifie les poids du modèle. Il n'apprend pas de faits de façon fiable — un modèle affiné sur vos documents inventera des variantes plausibles de leur contenu avec un aplomb inquiétant.

La règle de tri : si la réponse doit citer un document, c'est du RAG ; si la réponse doit ressembler à quelque chose, c'est du fine-tuning. La question du budget se pose ensuite — et elle n'est pas du même ordre : un RAG fonctionnel se monte en quelques jours, un fine-tuning correct demande un jeu de données annoté qu'il faut construire, ce qui représente souvent l'essentiel de la charge. Nous détaillons cet arbitrage dans fine-tuning ou RAG.

Dans la pratique, l'architecture qui fonctionne combine les deux dans cet ordre : RAG d'abord, systématiquement. Fine-tuning ensuite, et seulement si la forme des réponses reste insatisfaisante après avoir sérieusement travaillé les prompts.

Le matériel réellement nécessaire

C'est le point où les devis dérapent. La contrainte dominante est la mémoire vidéo, pas la puissance de calcul : un modèle qui ne tient pas en VRAM ne tourne pas, ou tourne si lentement que personne ne l'utilisera.

En quantification 4 bits — la norme en production, avec une perte de qualité à peine perceptible sur des tâches métier — l'ordre de grandeur est simple : comptez environ 0,6 Go de VRAM par milliard de paramètres, plus une marge pour le contexte. Un modèle de 8 milliards de paramètres tient confortablement sur une carte de 16 Go. Un modèle de 30 milliards demande 24 Go et devient serré dès que le contexte s'allonge. Au-delà, on passe sur du matériel professionnel dont le prix change de catégorie.

Le point important : un modèle de 7 à 8 milliards de paramètres suffit pour l'écrasante majorité des usages RAG en entreprise.Quand les passages pertinents sont fournis dans le contexte, le modèle n'a plus qu'à les reformuler — une tâche nettement moins exigeante que de répondre de mémoire. La qualité de votre chaîne de récupération pèse beaucoup plus lourd que la taille du modèle. Investir dans un modèle deux fois plus gros pour compenser un mauvais découpage documentaire est un mauvais calcul, et un calcul cher.

Sur le choix du modèle lui-même — Mistral, Llama, Qwen, Phi — voir notre panorama des LLM open-source. Pour les déploiements soumis à des exigences de souveraineté, les modèles européens présentent l'avantage d'une licence claire et d'un discours de conformité plus simple à tenir devant un client institutionnel.

L'architecture d'un serveur RAG en production

Une chaîne complète comporte cinq briques, et l'essentiel du travail ne se situe pas là où on l'imagine.

1. L'ingestion documentaire.Extraire du texte propre depuis des PDF scannés, des documents bureautiques mal structurés et des courriels. C'est systématiquement le poste le plus sous-estimé du projet. Un PDF issu d'un scanner demande de l'OCR ; un tableau extrait sans sa structure produit une bouillie illisible qui polluera toutes les réponses.

2. Le découpage.Trancher les documents en fragments cohérents. Un découpage à taille fixe coupe au milieu des phrases et détruit le sens ; un découpage qui respecte la structure du document (titres, sections, paragraphes) donne des résultats très supérieurs pour un effort modeste.

3. L'indexation vectorielle.Un modèle d'embedding transforme chaque fragment en vecteur, stocké dans une base spécialisée. Choisir un modèle d'embedding entraîné sur du français change nettement la qualité des résultats sur un corpus francophone.

4. La récupération. À chaque question, retrouver les fragments pertinents. La recherche purement vectorielle échoue sur les termes exacts — références produit, numéros de contrat, noms propres. Une recherche hybride, combinant vectoriel et mots-clés, corrige ce défaut et constitue le meilleur rapport effort/gain de toute la chaîne.

5. La génération.Le modèle reformule les passages récupérés en réponse. C'est la brique la plus visible et la moins déterminante pour la qualité finale.

La conséquence pratique : sur un projet RAG, la majeure partie du temps part dans les étapes 1 et 2, c'est-à-dire dans du traitement documentaire assez ingrat. Tout devis qui concentre la charge sur le modèle a mal évalué le travail. Les aspects de mise en production — évaluation, supervision, maîtrise des coûts — sont traités dans LLMOps en production.

Sécuriser l'accès

Un serveur IA local héberge, par construction, l'intégralité de la base documentaire sensible de l'entreprise sous une forme interrogeable en langage naturel. C'est un actif remarquablement pratique — et une cible remarquablement attractive.

Trois exigences minimales : le serveur ne s'expose jamais directement sur Internet (accès par VPN ou réseau interne) ; les droits de lecture des documents source sont répercutés dans l'index, faute de quoi le moteur devient un contournement élégant de vos autorisations ; et les requêtes sont journalisées, car une IA interrogeable est aussi un canal d'exfiltration discret. Notre approche est détaillée dans architecture Zero Trust.

Quand nous déconseillons l'opération

Par honnêteté commerciale, voici les cas où nous orientons vers autre chose.

Corpus de moins d'une centaine de documents.Une recherche plein-texte correcte et un peu d'organisation résoudront le problème pour une fraction du coût.

Aucune compétence système en interne, aucun budget d'infogérance.Un serveur d'inférence demande des mises à jour, de la surveillance et une astreinte. Un serveur laissé à l'abandon devient une faille avec un ventilateur.

Données non sensibles et volumétrie faible.Si rien ne s'oppose à l'usage d'une API et que le volume est modeste, l'API sera moins chère, plus rapide à mettre en œuvre et mieux maintenue.

Attente d'un modèle qui « connaît l'entreprise ». Un RAG répond à partir de documents. Il ne comprend pas votre organisation, ne devine pas les arbitrages implicites et ne remplace pas la personne qui sait pourquoi telle décision a été prise en 2019.

Ce que nous mettons en place

Notre intervention type couvre le dimensionnement matériel en fonction du corpus et du nombre d'utilisateurs, l'installation de la chaîne complète, le travail d'ingestion sur vos documents réels — c'est là que se joue la qualité —, une évaluation chiffrée sur un jeu de questions représentatives fourni par vos équipes, et la formation des personnes qui exploiteront le système.

L'évaluation chiffrée est le point sur lequel nous insistons le plus. Sans jeu de questions de référence, « la qualité des réponses » reste une impression, et une impression ne permet pas d'arbitrer. Nous construisons ce jeu avec vos équipes métier au démarrage, avant d'écrire la moindre ligne de code.

Cette prestation correspond au volet intégration IA de notre offre. Pour les contextes soumis à des exigences de sécurité renforcées, voir également IA en secteurs sensibles.