Consommer un modèle d'IA générative par API n'a jamais été aussi simple : une clé, trois lignes de code, et l'on dispose d'un modèle de pointe. Alors pourquoi acheter des cartes graphiques, monter un serveur et exploiter soi-même des modèles ? La réponse tient rarement à la performance brute — elle tient à ce qu'on ne veut pas déléguer.
1. Les données ne sortent pas
C'est la raison numéro un, et souvent la seule qui compte vraiment. Dès qu'un service interne envoie du texte à une API externe, ce texte quitte l'organisation : dossiers, courriers, notes internes, extraits de bases métier. Les conditions d'utilisation évoluent, les sous-traitants changent, la localisation des traitements aussi.
Avec une exécution interne, la question ne se pose plus : rien ne sort. Ce n'est pas un argument de confort mais de conformité — analyse d'impact, secret professionnel, données personnelles, documents à diffusion restreinte. Beaucoup de projets qui n'auraient jamais passé le stade de l'étude deviennent possibles simplement parce que le traitement reste sur place.
2. Le coût cesse d'être proportionnel à l'usage
Une API se facture au jeton. Tant que l'usage est expérimental, c'est imbattable. Mais un assistant réellement adopté, branché sur des documents et sollicité toute la journée, voit sa facture croître avec son succès — ce qui conduit à la limiter, donc à brider l'usage.
Un serveur, lui, est un coût fixe : matériel, électricité, exploitation. Au-delà d'un certain volume, la bascule est nette, et surtout l'usage marginal devient gratuit. Cela change les comportements : on ose indexer tout un fonds documentaire, relancer un traitement, laisser une équipe expérimenter.
Autant le dire franchement : sous ce volume, l'internalisation coûte plus cher. Le calcul doit être fait, pas supposé.
3. La disponibilité ne dépend plus de personne
Un fournisseur peut déprécier un modèle, modifier ses quotas, changer ses tarifs ou fermer un service. Un modèle exécuté en interne, lui, ne change pas tant qu'on ne le décide pas — et il continue de fonctionner sans accès Internet.
Cette stabilité a une conséquence sous-estimée : elle rend les résultats reproductibles. Un traitement rejoué six mois plus tard donnera la même chose, ce qui est indispensable dès qu'une décision s'appuie dessus.
4. La maîtrise technique, et ce qu'elle permet
- Choisir ses modèles — un modèle généraliste pour le chat, un modèle d'embeddings pour la recherche documentaire, un modèle d'OCR spécialisé, un modèle audio. Chacun sur la partition GPU qui lui convient.
- Adapter le contexte, la quantification, les paramètres de service — en fonction de l'usage et non d'une grille tarifaire.
- Mesurer réellement : latence, débit, saturation. Les métriques appartiennent à l'exploitant.
- Ajouter ses propres données sans les exposer : recherche augmentée, index internes, futures adaptations fines.
Ce que ça coûte vraiment — l'autre moitié du sujet
Internaliser n'est pas gratuit, et présenter le sujet autrement serait malhonnête :
- l'investissement matériel — un accélérateur récent, un serveur capable de l'accueillir, l'alimentation et le refroidissement qui vont avec ;
- les compétences — pilotes GPU, partitionnement, orchestration, moteurs d'inférence, supervision : rien d'insurmontable, mais rien d'automatique non plus ;
- l'écart de capacité — les plus gros modèles propriétaires restent hors de portée d'une machine unique. Sur beaucoup de tâches internes — résumer, classer, extraire, rechercher — un modèle ouvert de taille moyenne suffit très largement ; sur d'autres, il ne suffira pas ;
- l'exploitation — un serveur d'inférence est un service de production, avec ses sauvegardes, ses mises à jour et ses incidents.
Le bon critère de décision
La question n'est pas « interne ou API ? » mais « qu'est-ce qui ne doit pas sortir, et à quel volume ? ».
- Données sensibles, volume régulier, besoin de reproductibilité → l'internalisation se justifie seule ;
- usage ponctuel, données publiques, besoin du meilleur modèle disponible → l'API reste plus raisonnable ;
- et dans bien des cas, les deux coexistent : l'interne pour le quotidien et le sensible, l'externe pour l'exceptionnel.
Reste que monter cette plateforme apprend énormément — sur ce que coûte réellement un jeton, sur ce qu'un modèle sait faire et ne sait pas faire, et sur la différence entre une démonstration et un service. Les articles suivants décrivent comment une telle plateforme est construite : la carte, son partitionnement, son intégration à Kubernetes et l'exécution des modèles.
La série « IA en interne »
Cinq articles, du choix d'architecture à la mise en service :
- Pourquoi internaliser l'exécution des modèles — vous y êtes
- La H200 : anatomie d'un accélérateur
- Partitionner une H200 avec MIG
- Présenter des GPU à Kubernetes
- Exécuter des modèles sur K3s avec vLLM
Ces articles s'appuient sur une plateforme réellement exploitée. Les éléments d'infrastructure — noms de machines, adresses internes, espaces de noms — ont été neutralisés ; les principes, commandes et manifestes, eux, sont ceux qui tournent.