IA auto-hébergée : quand l'IA privée vaut l'effort d'ingénierie

Auto-héberger l'IA signifie que votre organisation exploite elle-même l'infrastructure qui fait tourner le modèle, au lieu d'envoyer ses requêtes à l'API d'un fournisseur. Cela peut être un modèle à poids ouverts sur un serveur GPU dans un centre de données suisse, ou une plateforme d'inférence sur Kubernetes dans votre propre cloud privé.

Avec des données sensibles, héberger soi-même le modèle peut sembler évident. Cela ne suffit pourtant pas à choisir entre des GPU dédiés, un service régional managé ou une combinaison des deux. La décision dépend du contrôle nécessaire, de la qualité attendue et de ce que votre équipe peut exploiter de façon fiable.

Ce que l'auto-hébergement signifie vraiment

L'IA privée recouvre plusieurs modes d'exploitation. Avant de choisir une architecture ou de signer un contrat, précisez qui exécute le modèle, où les données sont traitées et quelles responsabilités restent à votre équipe.

Ces catégories se recoupent. Faire tourner un modèle à poids ouverts sur des GPU cloud loués, à l'intérieur de votre propre VPC, relève à la fois de l'IA cloud et de l'IA auto-hébergée. Ce qui compte n'est pas l'étiquette mais quatre questions distinctes : où circulent les données, qui exploite l'inférence, qui répond de la sécurité, et quelles obligations légales s'attachent au cas d'usage.

Un point d'accès privé n'est pas un hébergement privé

C'est la distinction qui se perd le plus souvent, et la corriger tardivement coûte cher.

AWS documente PrivateLink comme un moyen d'atteindre Amazon Bedrock depuis un VPC sans passerelle internet, de sorte que le service se comporte comme s'il était dans le VPC (documentation AWS). Le trafic est privé. Bedrock reste un service managé par AWS, et le modèle tourne toujours chez AWS. De même, les VPC Service Controls de Google créent un périmètre de service autour de ses services d'IA managés afin de limiter l'exfiltration de données (Google Cloud). C'est un contrôle autour d'un service managé, non la preuve que le modèle tourne sur votre matériel.

La localisation du traitement forme un troisième axe, indépendant. Microsoft distingue dans la documentation Foundry le lieu de stockage du lieu de traitement : les déploiements Global peuvent traiter une requête dans n'importe quelle région Azure, les déploiements Data Zone maintiennent le traitement dans une zone déterminée, et les déploiements par géographie le maintiennent dans la géographie Azure choisie (Microsoft Learn).

Un chemin réseau privé n'implique donc pas un traitement exclusivement suisse, et un traitement en Suisse n'implique pas que vous exploitiez le modèle. Une équipe achats qui demande seulement « où se trouve le point d'accès ? » obtiendra une réponse rassurante qui ne règle rien. La bonne question porte sur le lieu de traitement des requêtes, des documents récupérés, des embeddings, des journaux, des sauvegardes et de l'inférence, sur les entités concernées, et sur les règles de conservation et d'accès du support.

Ce que vous gagnez et ce que vous devez prendre en charge

L'auto-hébergement vous donne un contrôle direct sur l'exécution du modèle et les flux de données. Le gain de confidentialité dépend des mesures mises en place.

Avec le serveur de modèle sous votre contrôle, vous décidez quels poids sont déployés et quand les versions changent, quel format de quantification est utilisé, ce qui est journalisé, s'il existe un trafic sortant vers internet, quelles sources documentaires sont accessibles, combien de temps les requêtes persistent, et si l'inférence continue quand le réseau externe tombe. La personnalisation profonde devient aussi plus simple : des environnements comme vLLM prennent en charge plusieurs méthodes de quantification ainsi que l'inférence distribuée en parallélisme de tenseurs et de pipeline, ce qui permet de répartir un modèle sur plusieurs GPU quand un accélérateur manque de mémoire (documentation vLLM).

Ce contrôle s'accompagne d'un travail continu. Votre équipe ou un partenaire doit prendre en charge les mises à jour, la capacité, la supervision et la gestion des incidents.

La plateforme est plus vaste que le modèle

Un système d'IA privée en production, ce n'est pas un GPU avec un modèle dessus. Le chemin va de l'utilisateur à l'authentification unique et à l'identité, puis dans l'application, à travers une passerelle qui applique la politique, vers la recherche et les outils, et seulement ensuite vers le serveur de modèle et ses GPU. Autour se trouvent les bases vectorielles, le stockage documentaire, la gestion des secrets, les clés de chiffrement, les journaux d'audit, la supervision, les chaînes d'évaluation et l'automatisation du déploiement.

Sur Kubernetes, les GPU ajoutent encore une couche. Kubernetes expose les accélérateurs via des plugins de périphérique fournis par le constructeur, qui déclarent des ressources telles que nvidia.com/gpu (documentation Kubernetes), et le GPU Operator de NVIDIA gère les pilotes, le plugin, l'outillage conteneur, l'étiquetage des nœuds et la supervision GPU qui rendent ces nœuds exploitables (NVIDIA). Ces outils sont bien établis, mais quelqu'un doit les maintenir et intervenir en cas de panne.

« Nous savons télécharger le modèle » n'est pas un test de maturité pour la production.

Dimensionner les GPU d'après la charge, pas d'après le nombre de paramètres

La taille du modèle est une première approximation. Ce n'est pas un plan de capacité.

Les chiffres publiés par Google pour Gemma 3 montrent l'effet du format numérique sur la mémoire, avant même de tenir compte des requêtes simultanées. Le modèle à 27 milliards de paramètres demande environ 54 Go pour des poids en BF16, contre 14,1 Go une fois quantifié en INT4 ; le modèle 12B passe d'environ 24 Go à 6,6 Go, et le 4B de 8 Go à 2,6 Go (Google Developers). Il s'agit des poids seuls. Google Compute Engine indique aujourd'hui 80 Go de mémoire GPU par accélérateur pour les NVIDIA H100 et 141 Go pour les H200 (Google Cloud).

Il n'en découle pas qu'un modèle de 79 Go de poids tient sur une carte de 80 Go. L'exécution nécessite aussi de la mémoire pour le cache de clés et valeurs (KV) utilisé par l'attention, les activations, la surcharge du moteur et le traitement par lots ; les contextes longs avec de nombreuses requêtes simultanées dépassent largement la taille du fichier de poids. Quand un modèle ne tient pas sur un accélérateur, vLLM prend en charge le parallélisme de tenseurs entre GPU, et le parallélisme de pipeline entre nœuds quand il ne tient pas dans un serveur (vLLM).

La règle d'achat qui en découle : dimensionnez d'après le nombre maximal de requêtes simultanées mesuré, la longueur des entrées et des sorties et les objectifs de latence. La quantification réduit réellement la facture mémoire, comme le montrent les chiffres de Google, mais elle doit être évaluée face à vos exigences de qualité plutôt que traitée comme une compression gratuite.

Les petits modèles ouvrent d'autres possibilités

Toutes les applications d'IA privée n'ont pas besoin d'un GPU H100. Gemma 3 a été lancé avec des modèles de 1, 4, 12 et 27 milliards de paramètres (Google Developers), et Google a conçu la variante à un milliard de paramètres spécifiquement pour un déploiement sur l'appareil (Google Developers).

Le déploiement en périphérie devient ainsi crédible pour des tâches bien délimitées : classification, extraction de champs, interface locale d'un équipement, résumé d'un contenu qui ne doit pas quitter la machine. L'erreur consiste à extrapoler vers le raisonnement métier général. Choisissez un petit modèle local parce que vos tests montrent qu'il suffit à la tâche définie, pas parce que « privé » est supposé meilleur.

Combien coûtent les API d'IA hébergées

L'argument économique de l'IA privée arrive généralement déjà simplifié : les API coûtent cher, posséder des GPU revient moins cher. À une échelle suffisante, c'est possible. Comme affirmation générale, c'est faux.

Partez du coût réel de l'inférence hébergée. Les prix catalogue standard d'OpenAI pour les contextes courts, vérifiés le 13 septembre 2026, sont de 10 dollars par million de jetons d'entrée et 50 par million en sortie pour GPT-6 Astra, 2 et 12 pour GPT-5.6 Terra, et 0,20 et 1,20 pour GPT-5.6 Luna, avec une majoration de 10 % sur les points d'accès régionaux offrant la localisation des données, pour les modèles publiés à partir du 5 mars 2026 (OpenAI). Anthropic affiche 2 dollars par million de jetons d'entrée et 10 par million en sortie pour Claude Sonnet 5, et 1 et 5 pour Haiku 4.5, tandis que l'inférence limitée aux États-Unis entraîne une majoration de 10 % pour les modèles Claude à partir de la version 4.6 ; les plateformes partenaires fixent leurs propres tarifs régionaux (Anthropic).

Ces exemples montrent combien le coût d'une API varie selon le modèle. Ils ne signifient pas qu'un modèle auto-hébergé atteindra la même qualité. Tous les montants sont en dollars américains.

Coûts mixtes calculés à partir des prix catalogue liés ci-dessus, hors mise en cache, tarifs par lots, coûts d'outils, majorations régionales et conditions négociées. Le nœud de référence est expliqué plus bas.

Dans ces exemples, le choix du modèle fait varier le volume d'équivalence des dépenses d'un facteur 45. Identifiez le modèle à remplacer et testez son alternative sur les mêmes tâches avant de conclure sur les coûts.

Ce que coûte réellement un nœud GPU

Les prix publics des GPU varient selon la région, le type de réservation et le mode de consommation. Google affiche la configuration a3-highgpu-8g à huit H100 à environ 88,49 dollars de l'heure à la demande et 38,86 dollars avec un engagement de ressources sur trois ans (Google Cloud). En fonctionnement continu, en retenant 730 heures comme mois de référence, cela représente environ 28 400 à 64 600 dollars de calcul par mois, avant développement applicatif, stockage, réseau et personnel. Google décrit A3 High dans sa configuration maximale avec huit H100 et 640 Go de mémoire GPU (Google Cloud) ; un modèle plus petit peut demander nettement moins. Le tarif inférieur suppose un engagement sur trois ans. Ces prix servent de référence et ne constituent pas un devis pour une région suisse : vérifiez le lieu, la capacité et les conditions contractuelles avant de fixer le budget.

Avec une API facturée au jeton, les dépenses d'inférence baissent lorsque la demande diminue. Un cluster réservé coûte presque autant à 10 % d'utilisation qu'à 90 %, et Google indique clairement que les instances en fonctionnement sont facturées même inactives et que les ressources engagées conservent leurs frais d'engagement (Google Cloud).

L'auto-hébergement se justifie d'autant mieux que la demande est à la fois forte et prévisible. L'une sans l'autre ne suffit pas.

Une dépense équivalente n'est pas un seuil de rentabilité

La dernière colonne du tableau met en regard la dépense API et le seul coût du nœud, ce qui n'est délibérément pas un calcul de rentabilité. Une comparaison sérieuse doit dire si le modèle ouvert atteint la qualité requise, si ce matériel précis soutient le débit et la latence demandés, quelle utilisation sera réellement atteinte, combien de réplicas la haute disponibilité exige, et ce qu'ajoutent l'ingénierie, la sécurité, le stockage, le réseau, les sauvegardes, l'observabilité et le support.

Le côté hébergé mérite la même rigueur. La mise en cache des requêtes, les tarifs par lots asynchrones, les remises volume et le routage des tâches simples vers des modèles moins chers déplacent tous le chiffre. Les déploiements Foundry Batch de Microsoft annoncent 50 % d'économie face à Global Standard en échange d'un traitement asynchrone avec un délai cible allant jusqu'à 24 heures (Microsoft Learn), et l'API Batch d'Anthropic applique la même remise de 50 % sur les jetons d'entrée et de sortie (Anthropic). Si vos tâches peuvent attendre un traitement par lots, intégrez ces tarifs réduits dans la comparaison.

La comparaison qui a du sens porte sur le coût par tâche réussie, à la qualité et au niveau de service requis, et non sur le coût par jeton.

En pratique, l'auto-hébergement se justifie mal pour un assistant interne utilisé par intermittence, un pilote à adoption incertaine, un travail qui dépend de capacités de pointe renouvelées tous les quelques mois, ou une organisation qui monterait une équipe plateforme GPU pour une seule application. Il devient plausible pour de l'extraction, de la classification, du résumé ou de la recherche à volume stable et élevé, lorsqu'un modèle ouvert plus petit a déjà passé vos évaluations et que le matériel reste occupé.

L'auto-hébergement ne garantit pas la sécurité

Un serveur de modèle sur site avec un mot de passe par défaut, des accès réseau trop larges, des images de conteneur non corrigées et un connecteur de recherche sans restriction est moins sûr qu'une plateforme managée bien configurée. Le lieu d'hébergement ne suffit pas à garantir la sécurité.

La sécurité est une propriété du système, pas du bâtiment où se trouvent les GPU.

AWS énonce le principe pour Bedrock : AWS protège l'infrastructure, et le client reste responsable de son contenu et de la configuration du service, y compris des contrôles d'identité et d'accès (AWS). Avec l'auto-hébergement, votre équipe prend aussi en charge la sécurité des serveurs de modèles et de leur infrastructure.

L'IA générative apporte en outre des risques qu'un périmètre réseau ne couvre pas. Le Generative AI Profile du NIST étend le cadre de gestion des risques de l'IA à cette classe de systèmes (NIST), et l'OWASP traite l'injection de prompt comme un problème de sécurité applicative à part entière (OWASP). Pour un assistant documentaire interne, la revue doit couvrir l'autorisation appliquée avant la recherche, afin que l'assistant ne révèle aucun document que la personne ne pourrait ouvrir directement, la gestion de l'injection de prompt dans les documents et contenus web non fiables, la chaîne d'approvisionnement des modèles et des conteneurs, les secrets et les droits des outils, la conservation et l'expurgation des journaux, le trafic sortant, la gestion des clés, la provenance des versions de modèle, et l'approbation humaine des actions aux conséquences importantes.

Le droit suisse et européen suit le cas d'usage, pas le serveur

Héberger un modèle à Zurich ne démontre aucune conformité. Le Préposé fédéral à la protection des données et à la transparence indique que la loi fédérale sur la protection des données s'applique directement aux traitements de données personnelles assistés par l'IA (PFPDT), et la LPD elle-même pose des obligations de protection des données dès la conception et par défaut, et encadre les sous-traitants, la sécurité et la communication à l'étranger (Fedlex). Vous devez toujours savoir quelles données personnelles entrent dans les requêtes et les index de recherche, à quelle fin, qui peut y accéder, ce qui est journalisé, quels sous-traitants interviennent et si les mesures sont proportionnées.

La LPD n'impose pas non plus, de façon générale, que les données personnelles suisses restent physiquement en Suisse. Elle encadre la communication à l'étranger sous des garanties définies plutôt que de l'interdire (Fedlex). Une architecture exclusivement suisse est la bonne réponse lorsque l'analyse juridique, un engagement contractuel, une réglementation sectorielle ou une exigence client la commandent, et elle ne remplace pas cette analyse.

Le RGPD encadre lui aussi les transferts internationaux. Le chapitre V fixe des conditions destinées à maintenir le niveau de protection lorsque des données personnelles quittent l'EEE, ce que le Comité européen de la protection des données résume en disant que la protection accompagne les données (CEPD). Un modèle privé peut réduire le nombre de sous-traitants externes et de transferts internationaux. Il ne supprime pas les obligations de gouvernance des sous-traitants, de sécurité du traitement ni d'analyse d'impact.

Pour le règlement européen sur l'IA, le calendrier 2026 a bougé. Le règlement (UE) 2026/1744 confirme le 2 août 2026 comme date d'application générale, mais reporte les sections 1 à 3 du chapitre III, à l'exception de l'article 6, paragraphe 5, pour les grandes catégories de systèmes à haut risque au 2 décembre 2027 pour les systèmes de l'annexe III relevant de l'article 6, paragraphe 2, et au 2 août 2028 pour ceux de l'annexe I relevant de l'article 6, paragraphe 1 (EUR-Lex). Pour le choix de l'architecture, le point essentiel reste le même : la classification dépend de ce que fait le système et du rôle de votre organisation, indépendamment du lieu d'hébergement des poids. Un modèle hébergé localement pour un usage réglementé à haut risque ne devient pas à faible risque parce qu'aucun fournisseur ne voit les requêtes, et un assistant interne ordinaire ne devient pas à haut risque parce qu'il appelle une API managée.

Trois architectures qui fonctionnent

Une petite entreprise et son assistant documentaire interne. Les collaborateurs interrogent les politiques internes, les contrats et la documentation. Le chemin va de la personne, via l'authentification unique, à l'application web, à travers une couche d'autorisation et de politique, vers la recherche sur un corpus documentaire approuvé et un index vectoriel, puis par une passerelle de modèle vers un modèle managé régional. S'y ajoutent le chiffrement, la recherche soumise aux droits, les journaux d'audit applicatifs, la minimisation des données dans les requêtes et un jeu d'évaluation. La passerelle est l'élément décisif : elle permet d'introduire plus tard un modèle privé sans réécrire l'application. Évaluez le traitement régional managé ou la connectivité privée avant d'acheter des GPU, car ils satisfont souvent l'exigence réelle de confidentialité pour une fraction du coût d'exploitation.

Une entreprise de taille moyenne avec plusieurs applications d'IA. Les utilisateurs et les applications atteignent une passerelle d'IA d'entreprise, qui oriente les requêtes selon les règles internes et la classification des données. Le travail peu sensible et tout ce qui exige les capacités de pointe part vers des modèles managés. Le travail sensible, volumineux et prévisible part vers une plateforme d'inférence privée sur Kubernetes, où vLLM utilise un ensemble de GPU. Les deux parcours utilisent les mêmes services de gestion des identités et des secrets, de supervision, d'évaluation et de suivi des coûts. L'entreprise peut ainsi changer de fournisseur ou de modèle sans revoir toute l'application.

Une organisation soumise à des exigences réglementaires strictes. Des postes managés et l'identité d'entreprise alimentent une zone applicative contrôlée, puis une passerelle de contrôle et de prévention des fuites, puis la recherche autorisée, puis un cluster d'inférence privé sans trafic sortant par défaut, avec import d'artefacts de modèle sur liste blanche, registre de conteneurs privé, clés adossées à un HSM ou un KMS, piste d'audit immuable, accès d'administration restreints, chaîne de mise à jour contrôlée et environnement de reprise séparé. Les actions à fort impact restent derrière une validation déterministe ou une approbation humaine plutôt que d'être exécutées de façon autonome. L'architecture améliore la maîtrise des flux de données ; elle ne remplace ni la gouvernance documentée, ni les analyses de risque, ni les contrôles fournisseurs, ni l'évaluation des modèles, ni les tests de sécurité, ni la gestion des incidents, ni l'analyse de rôle au titre du règlement sur l'IA.

Faut-il auto-héberger ?

Utilisez ces questions pour évaluer votre besoin et vos capacités d'exploitation.

Auto-hébergez lorsque le contrôle, la localisation, le fonctionnement hors ligne, la latence ou une utilisation soutenue créent une valeur supérieure à l'écart de capacité et à la charge d'exploitation. Sinon, achetez de l'inférence managée, ou faites tourner les deux derrière une même passerelle.

Quand l'IA est le mauvais outil

L'auto-hébergement ne rattrape pas un mauvais cas d'usage. Un modèle de langage est généralement le mauvais mécanisme central quand un moteur de règles résout le problème plus fiablement, quand chaque réponse doit être exacte et que rien ne la valide indépendamment, quand les données fiables manquent pour fonder la décision, ou quand une action autonome peut causer un dommage financier, sécuritaire ou juridique disproportionné sans contrôle efficace en amont. Dans ces cas, l'IA peut encore aider à la recherche, à la rédaction ou au tri pendant que l'étape décisive reste déterministe ou humaine. Cette frontière fait l'objet de notre guide pour identifier les cas d'usage de l'IA qui justifient un investissement.

Par où commencer

Commencez par la charge de travail, pas par le matériel. Notez ce qu'elle produit, quel volume elle représente, à quel point ce volume est prévisible et quelle latence elle exige. Classifiez les données qui entrent dans les requêtes et la recherche, et vérifiez les exigences juridiques applicables. Vérifiez qu'un modèle ouvert disponible atteint votre niveau de qualité sur vos propres exemples, puis comparez une conception managée, une privée et une hybride face aux mêmes exigences, utilisation et coût d'ingénierie compris.

Construisez la plus petite architecture qui satisfait les contraintes, et placez une passerelle devant, pour pouvoir changer de modèle par la suite.

Chez Alpine Edge, une analyse technique réunit le profil de charge, la classification des données, les exigences confirmées avec votre équipe juridique et les tests de qualité pour aboutir à une recommandation chiffrée. Nous développons et exploitons ensuite la solution retenue dans le cadre de nos services d'intégration de l'IA et d'IA privée, avec une infrastructure cloud et DevOps adaptée.

Sources et hypothèses de prix

• Tarifs de l'API OpenAI. Prix catalogue en contexte court et majoration pour traitement régional, consultés le 13 septembre 2026.
• Tarifs Claude d'Anthropic. Prix catalogue, remise de l'API Batch et majorations des points d'accès régionaux, consultés le 13 septembre 2026.
• Google Cloud, tarifs des VM optimisées pour accélérateurs. Tarifs à la demande et avec engagement de ressources sur trois ans pour a3-highgpu-8g, vérifiés le 13 septembre 2026.
• Google Cloud, tarifs Compute Engine. Facturation des instances inactives et frais d'engagement.
• Google Cloud, types de machines GPU. Mémoire par H100 et H200, et configuration A3 High.
• Gemma 3, chiffres de quantification. BF16 contre INT4 en 27B, 12B et 4B.
• Présentation de Gemma 3 et Gemma 3 sur mobile et web. Tailles de modèles et variante pour appareils.
• Documentation vLLM et parallélisme et mise à l'échelle. Quantification, parallélisme de tenseurs et de pipeline.
• Ordonnancement des GPU sur Kubernetes et NVIDIA GPU Operator. Plugins de périphérique et cycle de vie des nœuds GPU.
• Microsoft Foundry, types de déploiement. Global, Data Zone et géographie, et tarifs Batch.
• Amazon Bedrock, points d'accès VPC et protection des données. PrivateLink et responsabilité partagée.
• Google Cloud, VPC Service Controls pour l'IA. Périmètres de service autour de l'IA managée.
• PFPDT, IA et protection des données. Applicabilité de la LPD aux traitements assistés par l'IA.
• Loi fédérale sur la protection des données. Protection dès la conception, sous-traitance et communication à l'étranger.
• CEPD, transferts internationaux de données. Conditions du chapitre V du RGPD.
• Règlement (UE) 2026/1744. Nouvelles dates d'application pour les systèmes à haut risque.
• Cadre de gestion des risques de l'IA du NIST. Generative AI Profile.
• OWASP, injection de prompt. Risque au niveau applicatif.