Héberger soi-même n'efface ni le coût ni la complexité
Le self-hosted LLM attire parce qu'il promet contrôle, confidentialité et indépendance. Mais héberger soi-même un modèle ne supprime ni les risques, ni les coûts, ni la complexité d'exploitation. Cela déplace simplement une partie de la responsabilité vers l'entreprise.
Le bon arbitrage ne consiste pas à opposer API managée et self-hosted par principe. Il consiste à regarder les usages, les données, la latence, le volume, la qualité attendue, le coût complet et la capacité réelle à opérer le service.
"Le self-hosted était pertinent pour trois cas, pas pour toute l'entreprise."
Le fantasme du contrôle total cache souvent le coût d'exploitation
Un modèle self-hosted doit être déployé, monitoré, mis à jour, sécurisé, dimensionné et supporté. Il faut gérer la disponibilité, les performances, les versions, les coûts GPU, les logs, les embeddings, les outils de guardrails, la scalabilité et les incidents.
Les angles morts reviennent souvent :
- croire que self-hosted signifie automatiquement sécurisé ;
- sous-estimer le coût des GPU et de l'inférence ;
- laisser les modèles devenir obsolètes ;
- négliger le support et l'observabilité ;
- choisir un modèle moins performant pour des usages qui n'en ont pas besoin ;
- oublier les fallback quand le service interne ralentit ou tombe.
Le self-hosted peut être pertinent. Il doit simplement être réservé aux cas où ses bénéfices dépassent clairement son coût d'exploitation.
Séparer les cas sensibles des cas simplement coûteux
La meilleure architecture est souvent hybride : API managée pour les usages standards, modèle privé ou self-hosted pour des flux sensibles, et règles de routage selon données, coût, latence et criticité.
1. Classer les données manipulées
La classification doit distinguer données publiques, internes, confidentielles, personnelles, régulées et secrets métier. Le self-hosted se justifie plus facilement quand les données ne peuvent pas sortir du périmètre contrôlé ou quand les contraintes contractuelles l'imposent.
La matrice de sensibilité doit être reliée aux usages, pas rédigée dans l'abstrait.
2. Séparer usages sensibles et non sensibles
Tous les usages ne méritent pas la même architecture. Résumer une note interne standard, aider à rédiger un mail ou reformuler une documentation publique peut passer par une API managée encadrée. Interroger une base technique sensible, analyser des données clients régulées ou opérer dans un environnement déconnecté peut justifier une option self-hosted.
L'architecture cible doit décrire les routes : quel type d'usage va vers quel modèle, avec quelles règles de sécurité, de logs, de rétention et de fallback.
3. Mesurer coût GPU, MLOps et support
Le TCO comparatif doit inclure plus que le coût par token ou par requête : infrastructure, GPU, stockage, réseau, monitoring, MLOps, patching, évaluation, support, astreinte, sécurité, mises à jour de modèle et perte éventuelle de performance.
Un coût par requête faible sur le papier peut devenir élevé si le taux d'utilisation est faible, si la latence impose du surdimensionnement ou si l'équipe doit maintenir une pile complexe.
4. Prévoir fallback et observabilité
Un service self-hosted doit être piloté comme un service de production : latence p95, disponibilité, taux d'erreur, coût par requête, saturation, qualité de réponse, incidents de confidentialité, versions de modèle, capacité de fallback.
| Étape | Livrable | Signal de qualité |
|---|---|---|
| Données | Matrice de sensibilité | Le choix d'architecture part des données réelles |
| Routage | Architecture cible | Les usages sensibles et standards sont séparés |
| Coût | TCO comparatif | GPU, MLOps, support et qualité sont inclus |
| Run | Plan d'exploitation | Latence, erreurs, fallback et incidents sont suivis |
:::
Ce qui change quand l'architecture est choisie pour un usage réel
Quand l'architecture est choisie par usage, le débat devient plus sain. Certains flux restent sur API managée pour bénéficier de la performance et de la simplicité. D'autres passent sur self-hosted parce que la sensibilité, la souveraineté ou l'environnement l'impose. L'entreprise évite le dogme et pilote le compromis.
Le point fort de cette approche est la sélectivité. Le self-hosted n'est pas une bannière de sécurité, mais une réponse à des contraintes identifiées.
Un pilote d'arbitrage avant de mobiliser l'infrastructure
Avant de réserver de l'infrastructure, réalisez un pilote d'arbitrage. Sélectionnez quelques cas représentatifs : un usage standard, un usage sensible, un usage à forte volumétrie, un usage à contrainte de latence. Comparez API managée, modèle privé managé et self-hosted.
Le pilote doit produire :
- une matrice de sensibilité ;
- un benchmark qualité-latence-coût ;
- un TCO comparatif ;
- une architecture de routage ;
- un plan d'exploitation minimal.
La décision doit être prise à partir de données réelles, pas d'une préférence architecturale.
Les signaux qui disent si le self-hosted est vraiment justifié
Le self-hosted est justifié quand il répond à une contrainte forte : données qui ne peuvent pas sortir, environnement isolé, besoin de contrôle fin, coût unitaire meilleur à volume élevé, latence maîtrisée, exigences contractuelles ou réglementaires.
Il est moins justifié quand le volume est faible, les données peu sensibles, l'équipe d'exploitation limitée ou la qualité des modèles managés nettement supérieure pour l'usage visé.
Combien de temps faut-il pour obtenir un signal fiable ?
Deux à quatre semaines suffisent pour un benchmark d'arbitrage. La décision de production demande ensuite une estimation d'exploitation plus complète.
Faut-il commencer par un outil ou par un cas d'usage ?
Par les usages et les données. Le choix de modèle et d'hébergement doit suivre ces contraintes.
Comment éviter les gains déclaratifs ?
Comparez qualité, coût par requête, latence p95, taux d'erreur, charge d'exploitation et incidents de confidentialité.
Quand faut-il arrêter un pilote IA ?
Quand le self-hosted apporte peu de sécurité ou de coût en plus, mais beaucoup de complexité d'exploitation.
Le coût par requête remet vite le sujet à sa place
Choisir un self-hosted LLM en entreprise est pertinent pour certains usages, pas comme posture générale. La bonne architecture est celle qui protège les données sensibles, tient la charge, reste observable et garde un coût complet acceptable.