LLMs open source : mythes et réalités en entreprise

Le bruit autour des modèles ouverts

Lorsqu’une équipe de direction s’interroge pour la première fois sur les LLM open source, la conversation commence généralement par une grande promesse et un doute encore plus grand. Les mythes circulent plus vite que la documentation technique. Et les décisions se prennent, dans bien des cas, à partir d’informations de seconde main. Cet article ne vise pas à vendre l’adoption de modèles ouverts, mais à séparer ce qui peut être vérifié de ce qui se répète sans preuve.

Mythe 1 : « L’open source, c’est gratuit »

Les poids du modèle sont téléchargeables sans frais. C’est vrai. Ce qui n’est pas gratuit, c’est tout ce qu’il faut pour que ces poids fonctionnent de manière stable en production. Les coûts réels apparaissent sur quatre fronts :

• Infrastructure : un GPU disposant de suffisamment de mémoire pour servir un modèle de 70B avec un contexte long n’est pas un ordinateur portable. La location à l’heure ou l’achat du matériel représentent un coût qui se répète chaque mois.
• Ingénierie : quelqu’un doit monter le serveur d’inférence, ajuster le batching, surveiller les latences et gérer les versions du modèle.
• Évaluation : chaque mise à jour du modèle ou du prompt exige de remesurer la qualité. Sans un banc d’essai propre, on navigue à l’aveugle.
• Maintenance : les dépôts de poids et les bibliothèques d’inférence évoluent rapidement. Ce qui fonctionnait il y a six mois peut nécessiter des ajustements aujourd’hui.

En pratique, le coût par token d’un modèle ouvert servi sur sa propre infrastructure peut être compétitif, voire inférieur à celui d’une API fermée, mais seulement à partir d’un certain volume soutenu. En dessous de ce seuil, l’API l’emporte généralement en coût total. Selon la documentation des fournisseurs d’infrastructure cloud, le taux d’utilisation moyen des GPU dédiés à l’inférence dans les petites entreprises dépasse rarement 30 %, ce qui renchérit chaque token servi.

L’erreur de ne compter que le prix du token

Un schéma qui se répète dans les équipes qui sautent le pas : elles comparent le prix par million de tokens de l’API au prix par heure du GPU et concluent que le modèle ouvert est moins cher. Elles oublient le coût d’opportunité de l’équipe plateforme, les heures d’intégration et le temps consacré à résoudre les incidents. Un calcul honnête inclut ces heures, même de manière approximative.

Mythe 2 : « Si c’est ouvert, mes données sont sécurisées par défaut »

Exécuter le modèle sur sa propre infrastructure élimine la sortie de données vers un tiers, mais ne rend pas le système sécurisé par magie. La sécurité dépend de la manière dont on déploie, pas seulement de l’endroit où l’on exécute. Les points qui restent souvent hors de la conversation initiale :

• Les journaux de prompts et de réponses. S’ils sont stockés sans contrôle, la donnée sensible reste exposée, même si le modèle est local.
• L’accès au point de terminaison d’inférence. Sans authentification ni limites d’usage, n’importe qui au sein du réseau peut interroger le modèle avec les permissions du service.
• La chaîne d’approvisionnement du modèle. Les poids téléchargés depuis un dépôt public doivent être vérifiés ; un fichier corrompu ou manipulé est un vecteur réel.
• Le filtrage de contenu. Un modèle ouvert n’apporte pas par défaut les couches de modération qu’un fournisseur géré applique dans son API.

L’avantage en matière de confidentialité existe, mais c’est une condition nécessaire, pas suffisante. Il exige le même travail de gouvernance des données que tout autre système interne.

Mythe 3 : « Ils sont moins performants que les modèles fermés »

Ici, la nuance compte beaucoup, et généraliser est l’erreur. Dans les tâches de raisonnement complexe, de mathématiques et de code, les modèles fermés de premier rang ont conservé, pendant une bonne partie de 2025 et au début de 2026, un avantage dans les benchmarks publics. Mais dans des tâches délimitées — classification de tickets, extraction de champs d’un document, résumé de conversations avec un format fixe, génération de réponses à partir d’un contexte récupéré — les modèles ouverts de taille moyenne égalent ou dépassent les petits modèles fermés, avec l’avantage de pouvoir les ajuster avec ses propres données.

Un cas concret qui illustre bien la différence : une compagnie d’assurance qui traite des déclarations de sinistres en PDF. Un modèle fermé généraliste commettait des erreurs lors de l’extraction des montants lorsque le document mêlait tableaux et texte libre. Après avoir réalisé un fine-tuning d’un modèle ouvert de 8B avec 2 000 exemples annotés en interne, la précision sur ce format spécifique a augmenté de manière notable et le coût par document a diminué. Non pas parce que le modèle ouvert était meilleur en général, mais parce qu’il était spécialisé sur la distribution exacte de leurs documents. C’est le terrain où les modèles ouverts brillent.

Là où ils n’arrivent pas (et il convient de le reconnaître)

Un modèle ouvert de 7B ou 8B ne résoudra pas des requêtes exigeant un raisonnement multi-étapes sur des contextes de 200 000 tokens avec la même solidité qu’un modèle fermé haut de gamme. Ce n’est pas non plus l’option naturelle pour des tâches créatives de longue haleine où la cohérence stylistique est critique. Si votre cas d’usage en dépend, le modèle ouvert n’est pas la réponse, et le forcer génère de la frustration dans l’équipe et de la méfiance envers la technologie.

Mythe 4 : « Il suffit de télécharger le modèle et c’est tout »

La distance entre télécharger des poids et disposer d’un service en production est la partie la moins documentée dans les articles d’introduction. Les étapes intermédiaires comprennent :

• Choisir une bibliothèque d’inférence adaptée au matériel disponible.
• Définir le schéma de prompting et le versionner avec le code.
• Monter une couche de récupération (RAG) si le modèle a besoin de connaissances actualisées de l’entreprise.
• Établir des métriques de qualité et un ensemble d’évaluation représentatif.
• Configurer des limites d’usage, des files d’attente et une dégradation contrôlée face aux pics de demande.

Selon la documentation officielle des principales bibliothèques de serving, les performances par GPU varient beaucoup selon la technique de quantification et la taille du lot. Un même modèle peut passer de servir 10 requêtes par seconde à 40 selon la configuration. Cette différence n’apparaît pas dans la fiche du modèle ; elle apparaît à la mesure.

Mythe 5 : « L’open source garantit une indépendance totale vis-à-vis du fournisseur »

Remplacer la dépendance à une API fermée par la dépendance à un fournisseur de GPU, à une bibliothèque d’inférence spécifique ou à un dépôt de poids unique n’est pas de l’indépendance, c’est changer de dépendance. La liberté réelle arrive lorsque l’équipe peut migrer le modèle sans réécrire l’application. Cela exige une couche d’abstraction dans le code, un format de prompts portable et un banc d’essai permettant de comparer les candidats selon le même critère.

Les entreprises qui ont bien franchi cette étape disposent généralement d’un catalogue interne de modèles évalués, et non d’un modèle unique. Elles peuvent passer de l’un à l’autre selon le coût, la latence ou la qualité sur une tâche donnée. L’open source rend cette flexibilité possible ; il ne la garantit pas.

Réalité : quand cela a du sens et quand cela n’en a pas

Après avoir observé plusieurs déploiements, le schéma de décision est assez cohérent :

Signaux favorables

• Volume d’inférence élevé et stable qui justifie l’investissement en infrastructure.
• Données qui ne peuvent pas sortir du périmètre pour des exigences réglementaires ou contractuelles.
• Besoin de spécialisation approfondie dans un domaine avec des données propres étiquetées.
• Latence critique dans des environnements où le réseau vers un fournisseur externe ajoute un saut inacceptable.
• Exigence de reproductibilité : savoir exactement quelle version du modèle a répondu à quoi.

Signaux défavorables

• Équipe sans profil plateforme ou MLOps et délais serrés.
• Cas d’usage très variés exigeant un modèle généraliste de qualité maximale.
• Volumes faibles ou intermittents où l’API fermée revient moins cher.
• Absence de données propres pour spécialiser : sans fine-tuning ni RAG, le modèle ouvert concourt en position défavorable.

Un avertissement sur les évaluations

Les benchmarks publics sont une référence utile, mais ils ne prédisent pas les performances dans votre cas. Un modèle qui domine un tableau généraliste peut se retrouver en dessous sur la tâche précise qui vous importe. La seule mesure fiable est de construire un ensemble d’évaluation avec des exemples réels de votre activité, anonymisés si nécessaire, et de comparer les candidats avec le même prompt et le même critère de correction. Sans ce banc d’essai, toute décision sur des modèles ouverts repose sur des opinions, pas sur des données.

Et il convient de rappeler une limitation qui ne disparaît pas : aucun modèle, ouvert ou fermé, ne garantit de résultats. La qualité du système dépend de la donnée, de la conception du prompt, de l’évaluation continue et du jugement humain qui révise les sorties aux points critiques. L’open source ajoute du contrôle et des options ; il ne remplace pas le travail.