Héberger un modèle d'IA open-weight en Europe : le guide

L'IA générative est devenue un outil de travail sérieux : rédaction, synthèse de documents, tri d'e-mails, assistants internes. Mais la plupart des usages passent par les API de quelques grands éditeurs, et chaque prompt envoyé fait voyager vos données, parfois vos documents les plus sensibles, vers une infrastructure que vous ne maîtrisez pas.

Il existe une autre voie : héberger soi-même un modèle open-weight, en Europe, derrière une API privée. Voici comment s'y prendre, et quand c'est pertinent.

1. Pourquoi héberger son propre modèle

Les API professionnelles des grands éditeurs s'engagent en général à ne pas entraîner leurs modèles sur les données de leurs clients. Le problème n'est donc pas seulement l'entraînement : c'est que vos prompts et vos documents sont traités par une société soumise à sa propre législation, souvent américaine, et que vous ne savez pas exactement où ni combien de temps ils transitent.

Pour un cabinet tenu au secret professionnel, une collectivité ou une entreprise qui manipule des données personnelles ou confidentielles, héberger le modèle apporte trois garanties : les données restent en Europe, elles ne sont réutilisées par personne, et vous gardez la maîtrise des versions et des coûts.

2. Qu'est-ce qu'un modèle open-weight

Un modèle open-weight est un modèle dont les poids, c'est-à-dire le résultat de l'entraînement, sont publiés et téléchargeables. On peut donc l'exécuter sur sa propre infrastructure. Les familles les plus utilisées sont Llama, Mistral et leurs équivalents.

Attention aux licences : elles varient d'un modèle à l'autre. Certaines autorisent tout usage commercial, d'autres imposent des conditions. Le choix du modèle commence par la vérification de sa licence.

3. Choisir le modèle et sa taille

La taille d'un modèle se compte en milliards de paramètres. Plus il est grand, plus il est capable, et plus il coûte cher à faire tourner. En pratique :

• Les petits modèles (autour de 7 à 8 milliards de paramètres) suffisent pour la classification, l'extraction d'informations, le tri de demandes ou les réponses courtes en temps réel.

• Les modèles plus grands apportent de meilleurs résultats en rédaction, en synthèse longue et en raisonnement.

La quantification, qui consiste à réduire la précision des poids, divise fortement la mémoire nécessaire au prix d'une légère perte de qualité. C'est souvent le meilleur compromis pour un usage professionnel.

4. Dimensionner le GPU

La contrainte principale est la mémoire de la carte graphique : le modèle doit y tenir, avec une marge pour le contexte des conversations. Un ordre de grandeur utile : en précision 16 bits, il faut environ 2 octets par paramètre. Un modèle de 7 milliards de paramètres demande donc une quinzaine de gigaoctets, et environ trois fois moins une fois quantifié sur 4 bits.

Au-delà de la mémoire, deux besoins se distinguent : la latence (un assistant en temps réel doit répondre vite) et le débit (un traitement par lots de milliers de documents doit avancer vite). Le dimensionnement se fait sur le cas d'usage réel, pas sur le plus gros modèle disponible.

5. Servir le modèle par une API privée

Le modèle tourne sur un serveur d'inférence qui expose une API. La plupart des serveurs d'inférence open source proposent une API compatible avec les formats les plus répandus (chat, complétion, embeddings), ce qui permet de brancher des applications existantes en changeant simplement l'adresse de l'API et la clé d'accès.

Côté sécurité, le minimum est le suivant :

• un accès authentifié par clé, une clé par application ;

• une isolation entre clients ou entre services ;

• une journalisation des accès et un suivi de la consommation ;

• une conservation des prompts limitée au strict nécessaire, en cohérence avec le RGPD.

6. Répondre à partir de vos documents

Un modèle ne connaît ni vos contrats, ni vos procédures, ni votre catalogue. Pour qu'il réponde à partir de vos documents, on met en place une recherche documentaire augmentée (RAG) : les documents sont découpés, indexés sous forme d'embeddings, et les passages pertinents sont fournis au modèle à chaque question, avec leurs sources. C'est ce qui permet un assistant qui cite ses références et dit « je ne sais pas » quand l'information n'est pas dans la base.

Ce travail relève du développement d'agent IA : l'hébergement du modèle en est la fondation.

7. Et les coûts ?

Un GPU coûte cher à l'heure, et c'est le premier poste de dépense. Pour un usage ponctuel, un modèle mutualisé ou démarré à la demande est plus raisonnable qu'une machine dédiée qui tourne en permanence. Pour un usage soutenu (assistant interne utilisé toute la journée, traitement de gros volumes), un GPU dédié devient rentable et offre des temps de réponse stables. Dans les deux cas, choisir le plus petit modèle qui répond au besoin reste la meilleure économie.

C'est l'approche de l'hébergement IA souverain ELVACloud : des modèles open-weight hébergés en Europe, derrière une API privée, isolés par client. Pour aller plus loin sur l'exploitation au quotidien, voir aussi l'agent IA d'infogérance. Vous avez un cas d'usage en tête ? Parlons-en : on commence par le cadrage, puis on choisit le modèle et le dimensionnement adaptés.