Héberger l'IA en interne : ce qu'il faut et quand c'est rentable

Ce que signifie "héberger l'IA en interne"

Héberger l'IA en interne, c'est faire tourner le modèle sur une infrastructure que vous maîtrisez, au lieu d'envoyer vos prompts à une API tierce comme celle d'OpenAI ou d'Anthropic. Les modèles hébergeables sont dits "open-weight" : leurs paramètres entraînés sont téléchargeables (Llama, Mistral, Qwen, Gemma, DeepSeek et le suisse Apertus). Vous téléchargez les poids et les servez vous-même.

L'hébergement interne est un spectre, pas un choix unique :

• Appareil local : un ordinateur portable ou une station de travail avec Ollama ou LM Studio - idéal pour le prototypage et un usage mono-utilisateur.
• Serveur on-premises : une machine GPU dans vos locaux ou votre centre de données - les données ne quittent jamais le bâtiment.
• Cloud privé/dédié : des instances GPU louées mais isolées (ex. un VPC dédié) - vous maîtrisez l'environnement sans posséder de matériel.

Ce qu'il faut : le matériel

Le goulet d'étranglement est la VRAM, la mémoire vidéo du GPU, qui doit contenir le modèle et son contexte. Des modèles plus grands et un contexte plus long exigent plus de VRAM. La quantification - compresser les poids en 4 ou 8 bits - réduit fortement les besoins pour une perte de qualité modeste. En règles empiriques :

• Petit (3-8 Mds de paramètres), 4 bits : ~4-8 Go VRAM - tourne sur un GPU grand public ou un Mac Apple Silicon récent ; bon pour chat, résumé, RAG.
• Moyen (12-34 Mds), 4 bits : ~10-24 Go VRAM - un GPU grand public haut de gamme (ex. 24 Go) ou une carte station de travail.
• Grand (70 Mds), 4 bits : ~40+ Go VRAM - GPU professionnels ou multi-GPU ; nettement plus proche de la qualité de pointe.
• Frontière open (100 Mds+/MoE) : plusieurs GPU de centre de données - rarement justifié hors cloud privé.

La pile logicielle et les compétences

Au-delà du GPU : la concurrence multiplie tout - dix utilisateurs simultanés exigent bien plus qu'un seul. Comptez le CPU, la RAM, un stockage rapide, l'électricité et le refroidissement. NVIDIA (CUDA) domine ; Apple Silicon à mémoire unifiée est excellent pour un usage local mono-utilisateur ; AMD progresse mais a un écosystème plus restreint.

L'outillage a mûri. Pour débuter, Ollama et LM Studio regroupent tout en une expérience quasi en un clic. Pour la production, vLLM et Hugging Face TGI ajoutent le batching, un débit supérieur et une API compatible OpenAI, de sorte que vos applications changent à peine. llama.cpp est le socle de beaucoup d'entre eux et tourne efficacement même sur du matériel modeste.

Le plus dur est l'exploitation, pas l'installation. Quelqu'un doit :

• Gérer Linux, les pilotes GPU et les versions de CUDA
• servir le modèle de manière fiable, surveiller la latence et la disponibilité, et gérer la montée en charge
• appliquer les correctifs de sécurité, contrôler les accès et tenir une piste d'audit
• évaluer et remplacer les modèles dès que de meilleurs paraissent (l'écosystème ouvert avance vite)
• construire la vraie couche de valeur : RAG, prompts, garde-fous, intégration

Coût : interne vs. API

En pratique, une PME a besoin d'au moins un ingénieur compétent ou d'un partenaire externe ; sous-estimer cet effort continu est la cause la plus fréquente de déception. L'économie dépend du volume et du taux d'utilisation. Une API facture au token : aucun coût initial, mise à l'échelle immédiate, vous ne payez que ce que vous consommez. L'hébergement interne concentre les coûts en amont : vous achetez ou louez des GPU et payez l'électricité, le refroidissement et - le poste caché le plus lourd - le temps d'ingénierie, que le GPU soit occupé ou inactif.

Le seuil de rentabilité favorise l'interne quand l'utilisation est élevée et régulière - une charge continue amortit les coûts fixes. Pour un volume faible ou irrégulier, un GPU inactif rend l'API moins chère. Modélisez cela honnêtement, temps de personnel inclus, avant d'acheter du matériel. Comparaison rapide :

• Coût initial : API nul ; interne élevé (matériel) ou modéré (location)
• Coût marginal par requête : API au token ; interne quasi nul une fois en service
• Mise à l'échelle : API élastique ; interne limité par votre matériel
• Coût à vide : API nul ; interne vous payez quel que soit l'usage
• Charge d'exploitation : API minimale ; interne importante

Avantages et inconvénients en un coup d'oeil

• Avantage - Souveraineté des données : prompts et documents ne quittent jamais votre contrôle ; décisif pour les données sensibles.
• Avantage - Coût prévisible à grande échelle : plus de facture au token une fois le matériel amorti.
• Avantage - Indépendance : pas de verrouillage fournisseur, pas de changement surprise de prix ou de règles, fonctionne hors ligne/isolé.
• Avantage - Contrôle : choisir la version exacte du modèle, personnaliser et affiner (fine-tuning), régler la latence.
• Inconvénient - Capital et exploitation : dépense matérielle plus ingénierie continue.
• Inconvénient - Écart de qualité : les meilleurs modèles ouverts restent derrière les meilleurs propriétaires sur le raisonnement difficile - mais l'écart se réduit.
• Inconvénient - Frictions de mise à l'échelle et pleine responsabilité : les pics de demande sont durs à absorber ; sécurité, disponibilité et conformité vous incombent entièrement, y compris l'adoption continue de nouveaux modèles.

Quand est-ce rentable pour une PME ?

L'hébergement interne a le plus de sens si au moins l'un de ces points est vrai :

Ce n'est généralement pas rentable quand le volume est faible ou imprévisible, quand il faut le raisonnement le plus puissant possible, ou quand la capacité d'exploitation manque - alors une API conforme ou un déploiement en cloud privé (ex. une région suisse/UE d'un fournisseur ou un VPC isolé) convient souvent mieux. Beaucoup de PME optent pour l'hybride : héberger en interne les tâches petites, à fort volume et sensibles ; appeler une API pour les plus difficiles.

Deux points propres à la Suisse. D'abord, l'hébergement interne ne vous rend pas conforme en soi - la revDSG, les orientations du PFPDT et l'extraterritorial EU AI Act s'appliquent à votre usage de l'IA quel que soit le lieu d'exécution ; l'hébergement interne supprime surtout le problème des transferts transfrontaliers de données. Ensuite, la Suisse dispose désormais d'Apertus, un grand modèle de langage entièrement ouvert de l'ETH Zurich, de l'EPFL et du CSCS - une option notable quand la transparence et la provenance suisse comptent.

• Vous traitez des données sensibles ou réglementées (santé, juridique, finance, RH) où garder les données en interne simplifie la conformité à la revDSG/nLPD et la confiance des clients.
• Le volume est assez élevé et régulier pour amortir le matériel.
• Vous avez besoin d'un fonctionnement hors ligne, d'une latence garantie ou d'environnements isolés.
• Vous disposez déjà de solides compétences IT/ingénierie ou d'un partenaire de confiance.

Une feuille de route pragmatique

• Commencez par un pilote local : lancez Ollama avec un petit modèle ouvert sur une station de travail et testez-le sur des tâches réelles pendant une semaine.
• Mesurez honnêtement : qualité selon votre cas d'usage, volume mensuel attendu et latence requise.
• Comparez le coût total : matériel plus temps de personnel face à une facture API équivalente.
• Choisissez le niveau : local, on-prem, cloud privé - ou hybride.
• Investissez dans la couche de valeur (RAG, intégration, garde-fous), qui compte plus que le modèle brut.