LLM open source auto-hébergé ou API propriétaire : comment arbitrer ?

On arbitre sur quatre critères, dans cet ordre : ce que vos données ont le droit de faire, la qualité exigée sur votre cas, mesurée par un jeu d’évaluation, le coût sur trois ans, et ce que l’équipe sait exploiter. L’API gagne souvent sur les trois derniers ; l’auto-hébergement gagne sur le premier quand il est contraignant, et c’est lui qui décide.

Que veut dire « open source » pour un modèle de langue ?

Moins qu’on ne le croit. Un modèle « ouvert » est un modèle dont les poids, le résultat de l’entraînement, sont téléchargeables et exécutables sur votre matériel. Le code d’inférence est en général ouvert aussi. Les données d’entraînement, elles, restent presque toujours fermées, et le procédé d’entraînement avec. On parle donc de poids ouverts, pas de logiciel libre au sens classique : vous pouvez faire tourner le modèle, vous ne pouvez pas le reconstruire.

Ce qui compte pour un DSI, c’est la licence, et elles diffèrent. Deux exemples vérifiés le 8 septembre 2026 sur les fiches officielles. Mistral Small 3.1, 24 milliards de paramètres, est publié sous licence Apache 2.0, sans restriction d’usage, et sa fiche précise qu’il tient sur un portable avec 32 Go de mémoire une fois quantifié, contre environ 55 Go de mémoire GPU en pleine précision. Llama 3.1 est publié sous une licence communautaire propre à Meta, datée du 23 juillet 2024 : usage commercial permis, mais une licence supplémentaire à demander au-delà de 700 millions d’utilisateurs mensuels, et une mention « Built with Llama » à afficher sur le produit. Aucun de ces deux textes ne pose de problème à une entreprise ordinaire ; le point est qu’il faut les lire, et que « open source » sur une présentation ne dit pas lequel s’applique.

Que demande vraiment l’auto-hébergement ?

Une machine, quelqu’un qui la fait tourner, et du temps qu’on n’avait pas prévu. Je peux le dire avec des chiffres, parce que j’ai monté le mien.

Mon serveur est un MacBook Pro de 2019, un processeur i9 mobile avec 32 Go de mémoire, passé sous Linux et transformé en serveur sans écran en mai 2026. La mise en place a pris environ sept heures sur deux sessions, dont une bonne part à faire reconnaître le GPU AMD, que la pile logicielle officielle du constructeur ne prend pas en charge sur cette carte, par un autre chemin. Une fois en place, j’ai mesuré. Sur un modèle de 8 milliards de paramètres, le processeur seul génère environ trois jetons par seconde, ce qui est lent, et lit le contexte à six jetons par seconde. Avec le GPU, la génération gagne peu, mais la lecture du contexte passe à une vingtaine de jetons par seconde. Pour un assistant documentaire, c’est la lecture qui domine : chaque question arrive avec plusieurs milliers de jetons de passages à lire avant d’écrire trois lignes. Le GPU a donc changé l’usage, même s’il n’a pas changé la vitesse d’écriture.

La conclusion que j’ai notée à l’époque tient toujours : un matériel récupéré permet d’apprendre et de prototyper, pas de servir des utilisateurs. Un processeur mobile de 2019 plafonne, chauffe et ralentit sous charge continue. Pour de la production, le matériel s’achète ou se loue pour l’usage, et son coût entre dans l’arbitrage. J’ai chiffré ce poste, location d’un GPU comprise, dans combien coûte un assistant IA sur les documents internes.

Il reste ce que la machine ne montre pas : quelqu’un doit mettre à jour le serveur, sauvegarder, superviser, relancer, et savoir ce qu’il fait quand un modèle ne se charge plus. Ce sont des compétences d’exploitation ordinaires, mais il faut les avoir, ou les acheter.

Un petit modèle suffit-il ?

Pas toujours, et la différence se voit vite. Sur la même machine, j’ai comparé un modèle de 3 milliards de paramètres et un de 8 milliards sur une tâche de recherche documentaire : on fournit au modèle des pages trouvées sur le web et on lui demande d’en tirer une réponse sourcée. Le modèle de 3 milliards ignorait les sources qu’on lui donnait et répondait de mémoire, avec des informations périmées. Le modèle de 8 milliards lisait les pages et citait ses sources. Pour un assistant documentaire, la taille minimale n’est pas une question de puissance abstraite : en dessous d’un certain seuil, le modèle ne fait pas ce que le RAG lui demande, quelle que soit la qualité de la recherche en amont.

Le même modèle de 8 milliards, interrogé sur l’entreprise qui l’avait créé, a répondu avec assurance le nom d’une autre société. Anecdote, mais instructive : un modèle ouvert de taille modeste invente comme les autres, et rien dans son fonctionnement ne le signale. C’est la raison pour laquelle le choix d’un modèle, ouvert ou non, se fait sur un jeu d’évaluation rejoué, sur vos questions et vos documents, pas sur une démonstration ni sur un classement public.

Quand l’API gagne-t-elle ?

Dans la plupart des cas où les données peuvent sortir. Les meilleurs modèles des fournisseurs restent devant sur les tâches les plus exigeantes. Il n’y a rien à exploiter : pas de serveur, pas de GPU, pas de mise à jour. Le volume peut être nul un mois et élevé le suivant sans qu’on paie une machine qui dort. Et le temps entre la décision et le premier résultat se compte en jours. À volume modéré, l’API est aussi l’option la moins chère en trésorerie, et de loin.

Le prix à payer est la dépendance : le fournisseur change ses tarifs et ses modèles quand il le décide, et une version qui répondait bien peut être retirée. Un jeu d’évaluation rejoué à chaque changement est la seule parade.

Quand l’auto-hébergement gagne-t-il ?

Quand le premier critère est contraignant : des documents qui ne peuvent pas sortir du système d’information, données personnelles à grande échelle, données sensibles, secteur réglementé. J’ai détaillé ce que les fournisseurs font des données qu’on leur envoie dans nos données partent-elles chez OpenAI quand on utilise un LLM ; quand la réponse est « elles ne doivent pas partir du tout », le débat est clos.

Il gagne aussi à volume élevé et régulier, quand le coût variable de l’API finit par dépasser celui d’un serveur qui tourne en permanence ; quand l’indépendance compte, parce que les poids sont chez vous et qu’aucun fournisseur ne peut les retirer ni en changer le comportement ; et quand un comportement stable dans le temps est une exigence, par exemple pour un traitement dont les résultats doivent rester comparables d’une année sur l’autre.

Y a-t-il une voie du milieu ?

Oui, et c’est souvent la bonne pour une première mise en production : un modèle ouvert servi par un fournisseur qui l’héberge pour vous, en Europe, ou sur un serveur GPU loué dans votre périmètre. Les poids vous appartiennent, donc l’indépendance et la stabilité sont acquises ; l’exploitation de la machine est déléguée, donc la compétence n’est pas à acheter. Le coût est celui d’une location, prévisible.

Ce que ça ne règle pas : les données transitent par l’hébergeur, avec un contrat de traitement à signer et des sous-traitants à connaître ; et un modèle ouvert servi par un tiers reste un modèle de taille moyenne, à mesurer sur votre cas comme les autres.

Comment décider sur votre cas ?

Quatre critères, trois options, et un ordre.

L’ordre compte. Le premier critère élimine des options avant même de regarder les autres : si les données ne peuvent pas sortir, la colonne de gauche disparaît. Le deuxième se mesure, il ne se suppose pas : le même jeu d’évaluation rejoué sur un modèle ouvert et sur une API, sur vos questions, dit si l’écart de qualité existe et s’il compte pour votre usage. Les deux derniers se chiffrent, une fois les deux premiers tranchés.

C’est le travail d’un cadrage : classer les données, écrire le jeu d’évaluation, le rejouer sur deux ou trois modèles candidats, chiffrer les options qui restent. Le livrable est une décision argumentée, pas une préférence. Si vous en êtes à choisir, ou si un choix a été fait sans mesure et que personne ne sait s’il tient, décrivez votre cas d’usage : la première question portera sur vos données.