Guillaume Assier

Étude de cas

IA privée

Déploiement d’une plateforme d’inférence IA privée

Contexte

Éditeur de logiciels, forte culture open source : les équipes de développement utilisaient déjà l'IA au quotidien. Passer à l'échelle de toute l'entreprise butait sur deux obstacles. La souveraineté d'abord : prompts, données et usages partaient se faire traiter chez un tiers. Le modèle économique ensuite : une licence par utilisateur, qu'il s'en serve ou non, rendait la généralisation intenable. Étendre le dispositif en l'état, c'était prendre des risques de conformité et s'engager sur une facture impossible à tenir.

Le défi

Donner à tout le monde les mêmes capacités, sans abonnement externe. Concrètement : une plateforme d’IA privée, un proxy LLM central pour distribuer les clés et suivre les usages, et des modèles hébergés en France, sur du matériel dédié.

  • Souveraineté

    Prompts, données, usages : dépendre d'un acteur étranger pour toute une entreprise est un risque stratégique. Modèles bloqués selon la région, conformité incertaine, évènements géopolitiques.

  • Coût

    L’abonnement grimpe à chaque nouvel utilisateur, qu’il consomme ou non. Un coût de licences, pas un coût d’usage.

  • Adoption

    Généraliser sans casser les habitudes. Les développeurs gardent leurs agents et leurs IDE ; les autres équipes découvrent l’IA.

L’approche

01 · L’entrée unique

Un proxy LLM, point d’entrée unique

Plutôt que d’éparpiller les clés API, LiteLLM centralise tout. Les IDE et les agents l’appellent : les développeurs gardent leurs habitudes, les requêtes tournent sur les modèles privés. Clés, quotas par équipe et par utilisateur, traçabilité de chaque appel : le proxy s’en occupe. Ajouter un modèle open weight ou retirer l’ancien tient en une ligne de configuration : les nouveautés vont vite, les outils ne bougent pas. Les utilisateurs non techniques, eux, passent surtout par les intégrations IA des outils internes, et par Open WebUI pour le chat : une URL à ouvrir, rien à installer.

02 · Le routage

Deux modèles pour deux usages

Qwen3.6 Dense 27B pour l’aide au code : excellents résultats, mais gourmand en ressources. Qwen3.6 MoE 35B-A3B pour les usages généralistes : bons résultats, beaucoup plus léger à l’échelle. Les deux modèles tournent en versions compressées NVFP4.

03 · Le socle bare metal

Des machines physiques dédiées et hébergées en France

Les modèles tournent sur des machines dédiées opérées par l’entreprise, dans un datacenter français. Le parc GPU mélange plusieurs générations de cartes NVIDIA.

Les résultats

  1. Adoption rapide

    L’entreprise a vite intégré l’IA au quotidien : IDE et agents côté développeurs, intégrations dans les outils internes et Open WebUI pour les autres.

  2. Coût à l'usage

    Le coût suit l’usage réel. Chaque équipe voit le nombre de tokens qu’elle consomme ; on ne paie plus de licences dormantes.

  3. Souveraineté complète

    Modèles, prompts et données restent dans l'entreprise : plus de fuite de secrets ni d'informations commerciales.

  4. Plateforme autonome

    La plateforme vit sans moi. Architecture, exploitation, gestion des clés : tout est documenté, l’équipe est autonome.

  5. Les modèles bougent vite

    Ajouter un modèle open weight ou retirer l’ancien tient en une ligne de configuration du proxy ; les outils des équipes ne bougent pas.

  6. Réversibilité

    Tout repose sur le standard des endpoints OpenAI : les outils appellent une API connue. Changer de modèle, de fournisseur d'inférence ou d’hébergeur est simple, et ne demande pas de migration.

La stack

Accès

  • LiteLLM
  • Open WebUI

Modèles

  • Qwen3.6 Dense
  • Qwen3.6 MoE

Orchestration

  • Kubernetes
  • Ansible
  • Ubuntu

Infra

  • Bare metal
  • GPU NVIDIA

L’IA circule dans vos équipes et vous ne savez pas où passent les données ?

Trente minutes pour regarder vos usages réels et ce que demanderait une plateforme hébergée chez vous.

Envoyer un mail