Intelligence Artificielle

IA self-hosted : garder ses données en Belgique

Publié le Par Dr Ir Hüseyin Cakmak
#ia self-hosted #IA souveraine PME #RGPD IA #Ollama #vLLM #modèles open-weight
IA self-hosted : garder ses données en Belgique

L'IA self-hosted consiste à faire tourner ses propres modèles de langage sur une infrastructure maîtrisée, en Belgique ou dans l'UE, plutôt que d'envoyer ses données à un service cloud américain. Pour une PME, l'enjeu n'est pas la mode technologique : c'est la résidence des données, la conformité RGPD et le contrôle du coût dans la durée.

Qu'est-ce que l'IA self-hosted pour une PME ?

Héberger son IA en interne, ou chez un hébergeur européen dédié, signifie exécuter un modèle de langage sur des serveurs que l'entreprise contrôle. Les requêtes des collaborateurs, les documents analysés et les réponses générées ne quittent jamais ce périmètre. On parle aussi d'IA souveraine, parce que la donnée reste sous une juridiction et un contrôle choisis.

Cela s'oppose au schéma dominant, où l'on consomme un modèle via une interface (ChatGPT, Claude, Gemini) ou une API. Dans ce cas, le texte envoyé transite par l'infrastructure du fournisseur, souvent hors UE. Ce n'est pas illégal en soi, mais cela déplace une partie de la maîtrise vers un tiers.

Pour une PME, l'auto-hébergement devient pertinent dès que les données traitées sont sensibles : dossiers clients, données de santé, secrets industriels, pièces juridiques. Le principe directeur reste simple : plus la donnée est critique, plus le fait de la garder sous son propre toit a de la valeur.

Pourquoi le RGPD pousse-t-il vers l'auto-hébergement ?

Le point de friction n'est pas l'IA en tant que telle, mais le trajet des données. Envoyer des données personnelles à un service situé hors de l'Espace économique européen déclenche des obligations spécifiques : encadrement du transfert, garanties appropriées, information des personnes. Les données personnelles sont protégées par le RGPD, et tout traitement, hébergement ou transfert doit reposer sur une base légale, respecter la minimisation, documenter la sous-traitance et privilégier une résidence des données dans l'UE, sans minimiser ces exigences.

Garder l'inférence en interne supprime le transfert hors UE et réduit la chaîne de sous-traitance. C'est un avantage réel, mais partiel : l'auto-hébergement ne dispense pas des autres piliers du règlement. Il faut toujours une base légale, un registre des traitements, une politique de conservation et des mesures de sécurité proportionnées [2][6]. L'autorité de protection des données rappelle d'ailleurs que le responsable du traitement reste comptable de l'ensemble, quel que soit l'outil employé [2].

Le futur cadre européen ajoute une couche. Le règlement sur l'intelligence artificielle (AI Act) impose des obligations graduées selon le niveau de risque du système, indépendamment du lieu d'hébergement [1]. Héberger en interne aide sur la donnée, mais ne dispense pas de cartographier ses usages d'IA. Nous détaillons la partie protection des données dans notre guide sur l'audit RGPD et la cybersécurité en PME.

Avec quoi héberge-t-on : Ollama, vLLM, modèles open-weight ?

L'écosystème open-weight a rendu l'auto-hébergement accessible. Des familles de modèles ouverts (Llama, Mistral, Qwen, Gemma) se téléchargent et s'exécutent sans passer par une API tierce. Deux briques logicielles dominent côté exécution.

ia self-hosted - serveur d'inférence en PME belge

  • Ollama privilégie la simplicité. On installe l'outil, on télécharge un modèle open-weight en une commande, et on l'interroge en local. C'est l'entrée idéale pour prototyper, tester un cas d'usage ou équiper quelques postes [4].
  • vLLM vise la production. C'est un moteur d'inférence optimisé pour le débit et les requêtes concurrentes, capable de servir plusieurs utilisateurs simultanément sur un GPU serveur [5].

Le choix du modèle compte autant que le moteur. Un petit modèle suffit souvent pour classer des emails, résumer des documents ou extraire des données ; un modèle plus lourd se justifie pour du raisonnement complexe ou de la génération longue.

Brique Rôle Adaptée quand Matériel typique
Ollama Exécution locale simple Prototype, petits usages, quelques postes CPU ou GPU d'entrée de gamme
vLLM Moteur d'inférence production Plusieurs utilisateurs, temps réel GPU serveur dédié
Modèle open-weight léger Tâches ciblées Classification, résumé, extraction Faible à modéré
Modèle open-weight lourd Raisonnement, génération longue Assistants avancés GPU haut de gamme

Self-hosted ou cloud IA public : comment trancher ?

La bonne question n'est pas idéologique. Le cloud IA public (OpenAI, Anthropic, Google) offre les modèles les plus puissants, une disponibilité immédiate et zéro maintenance. L'auto-hébergement offre le contrôle de la donnée, un coût marginal faible à l'usage et l'absence de dépendance à un fournisseur unique. Chacun a un domaine où il gagne.

L'arbitrage se fait par type de donnée et par cas d'usage, pas en bloc. Une même PME peut très bien utiliser un modèle public pour rédiger un texte marketing anodin, et un modèle interne pour analyser des contrats clients.

Critère IA self-hosted Cloud IA public
Résidence des données Sous contrôle, en UE Souvent hors UE, encadrement requis [2]
Performance des modèles Bonne, en retrait sur le très haut de gamme Accès aux modèles les plus avancés
Coût Investissement initial, marginal faible ensuite Pas d'investissement, coût à l'usage
Charge opérationnelle À la charge de l'entreprise Externalisée
Dépendance fournisseur Faible Élevée (API, tarifs, disponibilité)

Aucune de ces colonnes n'est « la bonne ». Toute promesse de performance ou d'économie doit rester qualifiée et vérifiable : personne ne peut garantir un gain chiffré universel, car il dépend du volume, des modèles et des usages réels de chaque entreprise.

Combien coûte une IA hébergée en interne ?

Le coût se décompose en trois postes rarement additionnés honnêtement. D'abord le matériel : un serveur avec un GPU adapté, du plus modeste (quelques milliers d'euros) au haut de gamme selon les modèles visés. Ensuite l'exploitation : mises à jour, supervision, sécurité, sauvegardes. Enfin les compétences, internes ou déléguées.

C'est là que le cloud public reprend l'avantage sur les petits volumes : tant que l'usage reste faible, payer à la requête coûte moins cher qu'amortir un serveur. L'auto-hébergement devient rentable quand le volume grimpe, quand la donnée est sensible, ou quand la prévisibilité du coût prime sur la flexibilité.

Une PME wallonne peut par ailleurs mobiliser des dispositifs de soutien à la transformation numérique via Digital Wallonia pour une partie de l'accompagnement. Ces aides publiques (chèques-entreprises, primes numériques) sont soumises à des conditions d'éligibilité strictes : elles ne sont jamais automatiques ni acquises, et il faut toujours vérifier les conditions en vigueur auprès de la source officielle avant de s'engager.

Quand le cloud IA public reste-t-il le bon choix ?

Il serait malhonnête de présenter l'auto-hébergement comme la réponse universelle. Le cloud IA public reste souvent le meilleur choix, et pour de bonnes raisons.

  1. L'accès aux meilleurs modèles. Les modèles fermés de pointe gardent une avance sur les tâches de raisonnement les plus exigeantes.
  2. Le time-to-value. Une API branchée en une journée bat un projet d'infrastructure de plusieurs semaines quand le besoin est urgent.
  3. Les données non sensibles. Pour un contenu public ou anonymisé, le risque RGPD est faible et l'auto-hébergement n'apporte pas grand-chose.
  4. Les petits volumes. Sans usage massif, l'investissement matériel ne s'amortit pas.

Les fournisseurs sérieux proposent d'ailleurs des engagements contractuels (traitement des données, options de résidence, non-entraînement sur les données client) qui réduisent une partie du risque. La CNIL, référence francophone en la matière, publie des recommandations utiles sur l'usage de l'IA dans le respect du RGPD [3]. La vraie faute n'est pas de choisir le cloud, c'est de le choisir sans avoir qualifié la sensibilité de la donnée.

Comment déployer une IA souveraine sans se tromper ?

Un projet d'IA self-hosted échoue rarement sur la technique et souvent sur le cadrage. La séquence qui limite le risque tient en quelques étapes.

  • Cartographier les données et les usages : quelles données passeraient par l'IA, quelle sensibilité, quelle base légale.
  • Trancher usage par usage : interne pour le sensible, cloud public pour l'anodin, sans dogme.
  • Commencer petit : un cas d'usage, un petit modèle open-weight sous Ollama, une mesure honnête du résultat avant d'investir dans un GPU serveur et vLLM.
  • Industrialiser ce qui marche : sécurité, supervision, mise à jour des modèles, réversibilité.

Avant de choisir un partenaire pour vous accompagner, vérifiez ses références, ses certifications, ses clauses de niveau de service, son plan de réversibilité et sa posture de sécurité (RGPD, NIS2) : ces vérifications ne sont pas une formalité, elles conditionnent la solidité de l'engagement dans la durée.

Chez ITOPS.be, nous abordons ces projets en deux temps. Un Blueprint cadre les usages, la sensibilité des données et l'architecture cible (interne, cloud ou hybride), puis un Build met en œuvre la solution par vagues, avec les mêmes interlocuteurs du conseil à la réalisation. Cette continuité évite le décrochage classique entre une belle recommandation et un déploiement bâclé. Pour situer l'IA dans une stratégie plus large, voyez aussi notre panorama des cas d'usage concrets de l'IA en PME et notre lecture de la conformité NIS2 pour les PME belges.

Questions fréquentes

L'IA self-hosted est-elle vraiment plus conforme au RGPD que le cloud ?

Elle réduit un risque précis : la sortie des données hors de l'UE et la sous-traitance à un tiers non maîtrisé. Elle ne dispense pas des autres obligations RGPD (base légale, minimisation, sécurité, registre) [2][6].

Faut-il un GPU coûteux pour héberger un modèle d'IA en interne ?

Pas toujours : de petits modèles open-weight tournent sur CPU ou sur un GPU d'entrée de gamme via Ollama pour des usages simples [4]. Les besoins temps réel ou multi-utilisateurs justifient un GPU serveur et un moteur comme vLLM [5].

Quelle différence entre Ollama et vLLM ?

Ollama vise la simplicité d'installation et le prototypage local d'un modèle open-weight [4]. vLLM est un moteur d'inférence orienté production, optimisé pour le débit et plusieurs utilisateurs simultanés [5]. Beaucoup de PME commencent par le premier.

Le cloud IA public est-il à éviter pour une PME belge ?

Non. Pour des données non sensibles, un besoin ponctuel ou l'accès aux modèles les plus performants, il reste souvent le choix le plus rentable [1]. L'arbitrage se fait donnée par donnée, pas de façon dogmatique.

Sources et Références

  1. Commission européenne : Cadre réglementaire de l'UE sur l'intelligence artificielle (AI Act)
  2. Autorité de protection des données (Belgique) : Espace professionnel, obligations des responsables de traitement
  3. CNIL : Intelligence artificielle et protection des données
  4. Ollama : Exécuter des modèles de langage open-weight en local (dépôt officiel)
  5. vLLM : Moteur d'inférence à haut débit pour LLM (documentation officielle)
  6. EUR-Lex : Règlement général sur la protection des données (RGPD), texte consolidé