LLM : qu'est-ce qu'un grand modèle de langage

Un LLM, en clair

Un LLM ne ressemble ni à un logiciel classique ni à un algorithme au sens habituel du terme. C'est un modèle statistique entraîné sur des volumes de texte considérables pour prédire, mot après mot, la suite la plus probable d'une phrase. « Grand » renvoie à deux choses : le nombre de paramètres ajustés pendant l'entraînement, qui va de quelques milliards à plus de mille milliards selon les modèles, et la taille du corpus de textes utilisé pour les régler. Le mécanisme qui permet à ce modèle de pondérer chaque mot du texte en fonction de tout ce qui l'entoure s'appelle un transformeur, une architecture décrite par des chercheurs de Google dans l'article de recherche « Attention Is All You Need » publié en 2017 et reprise depuis par la quasi-totalité des modèles commerciaux.

Le calcul se fait par blocs appelés tokens, un fragment de mot ou un mot entier selon la langue. Les fournisseurs facturent leurs API au token, pas au mois ni au poste utilisateur : ce détail compte, il conditionne toute la section sur le coût plus bas dans cet article. Pour un décideur, l'important tient en une phrase : le LLM est le moteur, pas le produit fini. Un chatbot de support, un assistant qui rédige des comptes rendus, un moteur de recherche interne sont des applications construites autour d'un modèle, avec des instructions, des outils connectés et du code qui encadre ce que le modèle peut voir et faire.

Sur les projets suivis chez Noxcod, l'erreur la plus fréquente au démarrage consiste à traiter le choix du modèle comme la décision qui structure le projet. En pratique, ce qui détermine si un projet tient la route se joue ailleurs : quelles données le modèle peut consulter, ce qu'il fait quand il ne sait pas, qui relit sa sortie avant qu'elle n'atteigne un client. Le modèle choisi vient après ces réponses, pas avant.

Ce qu'un LLM sait faire, et où il échoue

Un LLM correctement guidé rédige, reformule, résume un document long, classe un texte dans une catégorie, extrait des champs structurés d'un email, traduit, et tient une conversation cohérente sur plusieurs échanges. Ces capacités couvrent une bonne partie des tâches administratives et de rédaction d'une entreprise, ce qui explique l'engouement des trois dernières années. Elles couvrent nettement moins bien tout ce qui exige une vérité vérifiable en temps réel : un prix, un stock, une date d'échéance, une donnée propre à l'entreprise que le modèle n'a jamais vue pendant son entraînement.

La limite la plus citée reste l'hallucination : le modèle génère une réponse fausse avec la même assurance qu'une réponse juste, parce qu'il ne « sait » rien au sens où l'entend un humain, il complète un texte de façon statistiquement plausible. À cela s'ajoute une date de coupure d'entraînement, au-delà de laquelle le modèle ignore tout, sauf s'il est connecté à une recherche web ou à une base documentaire externe. Enfin, chaque modèle traite une quantité limitée de texte en une fois, sa fenêtre de contexte. Les modèles les plus récents d'Anthropic, Claude Sonnet 5 et Claude Opus 4.8, acceptent jusqu'à un million de tokens de contexte au tarif standard, largement au-dessus de ce que proposaient les modèles d'il y a deux ans, mais cette limite reste variable d'un fournisseur à l'autre et se paie au même tarif que le reste du texte envoyé.

Pour une entreprise, le vrai risque n'est pas que le modèle échoue en test. Il échoue rarement sur les questions préparées à l'avance. Il échoue sur la question de travers qu'un client pose en vrai, celle que personne n'a testée, et il y répond quand même, avec assurance, plutôt que de dire qu'il ne sait pas. C'est ce cas-là qu'il faut anticiper avant la mise en production, pas après.

API propriétaire ou modèle open source auto-hébergé : le vrai choix business

Deux voies s'offrent à une entreprise qui veut exploiter un LLM. La première consiste à consommer un modèle via une API hébergée par son fournisseur, OpenAI, Anthropic ou Mistral en tête. Aucune infrastructure à gérer, une facture au token, un modèle mis à jour par le fournisseur sans intervention de votre côté. En contrepartie, les données envoyées transitent par les serveurs du fournisseur, la disponibilité dépend de lui, et les tarifs comme les modèles disponibles peuvent changer sans préavis.

La seconde voie consiste à auto-héberger un modèle à poids ouverts, Llama, Mixtral ou Qwen par exemple, sur une infrastructure que l'entreprise contrôle. Cela suppose une brique de service dédiée : faire tourner un LLM en local avec Ollama convient pour un poste de développement ou un prototype, un moteur de production comme vLLM prend le relais quand le volume de requêtes grimpe. L'avantage tient dans le contrôle : la donnée ne quitte jamais le périmètre de l'entreprise, aucune facture au token qui grimpe avec l'usage. L'inconvénient tient au même endroit : il faut désormais posséder ou louer les GPU nécessaires, et une équipe capable de faire tourner cette infrastructure, ce qui coûte cher en tenue de service pour un volume qui ne le justifie pas toujours.

Le point de bascule entre les deux options se situe rarement là où les commerciaux le placent. En dessous d'un volume soutenu, l'API hébergée revient presque toujours moins cher qu'un serveur GPU dédié qui tourne à moitié vide. Au-dessus, et seulement si l'entreprise dispose déjà d'une équipe capable d'opérer l'infrastructure, l'auto-hébergement redevient compétitif. Monter une infrastructure IA en entreprise qui tienne dans la durée, avec supervision et plan de bascule en cas de panne, demande un investissement que peu de PME rentabilisent avant plusieurs centaines de milliers de requêtes par mois.

Combien coûte un LLM à l'usage

La facturation au token déroute les décideurs habitués à un prix par poste ou par licence mensuelle. Chaque fournisseur propose plusieurs modèles, un premier prix pour l'entrée, le texte envoyé au modèle, et un second, presque toujours plus élevé, pour la sortie, le texte généré. L'écart entre le modèle économique et le modèle le plus performant d'un même fournisseur atteint fréquemment un facteur 20 à 25.

Source : developers.openai.com/api/docs/pricing, platform.claude.com/docs/en/about-claude/pricing et mistral.ai/pricing/api, tarifs consultés le 13/07/2026, susceptibles d'évoluer.

Un exemple concret aide à relativiser. Anthropic a publié son propre calcul pour un cas d'usage de support client : environ 3 700 tokens par conversation, traités avec Claude Haiku 4.5, reviennent à environ 37 dollars pour 10 000 tickets. Ce chiffre remet en perspective une inquiétude fréquente chez les PME qui imaginent une facture à quatre chiffres dès les premiers mois. Pour un volume de conversation courant, le token n'est presque jamais le poste de coût qui fait déraper un projet, c'est le choix du modèle appliqué à la mauvaise tâche qui le fait : router systématiquement vers le modèle le plus cher parce qu'il est le plus connu, alors qu'un modèle économique traite très bien la majorité des requêtes simples.

Deux leviers réduisent encore la facture sans changer de modèle : le traitement par lot, qui divise le tarif par deux sur des tâches non urgentes, et la mise en cache d'un contexte répété d'une requête à l'autre, qui réduit le coût du texte réutilisé jusqu'à 90 %. Peu d'intégrations les activent par défaut, la question mérite d'être posée à l'équipe qui construit le projet.

RGPD, souveraineté, et où vit la donnée envoyée au modèle

Envoyer une donnée client dans un prompt reste un traitement de donnée personnelle au sens du RGPD, au même titre qu'un envoi vers n'importe quel logiciel SaaS. La CNIL a publié le 7 février 2025 ses recommandations sur l'IA et le RGPD : informer les personnes concernées lorsque leurs données servent à entraîner un modèle ou transitent dans son usage, documenter chaque traitement dans un registre qui précise le modèle, les données d'entraînement et la finalité, et réaliser une analyse d'impact dédiée si le risque pour les personnes est élevé. Rien de spécifique à l'IA dans le principe : c'est le même cadre qu'un CRM ou un outil d'emailing, avec une couche supplémentaire liée au fait que le modèle peut mémoriser une partie de ce qu'on lui envoie.

La question de l'hébergement géographique de la donnée s'ajoute à celle du traitement. La plupart des API de LLM grand public hébergent leur traitement par défaut hors Union européenne, ce qui pose la question du transfert hors UE pour toute donnée sensible ou identifiante, sauf à activer une option de résidence des données quand le fournisseur la propose. Une partie croissante des entreprises françaises et européennes en tient compte dans leurs choix d'architecture : selon l'enquête menée par Deloitte auprès de 3 235 dirigeants dans 24 pays entre août et septembre 2025, 83 % considèrent la souveraineté de l'IA comme un enjeu stratégique important. Déployer Mistral, le LLM français, en entreprise répond directement à cette contrainte pour les organisations qui doivent garder leurs données dans l'Union européenne, avec un rapport qualité-prix qui a nettement progressé sur les derniers modèles de la gamme.

Aucune de ces contraintes n'interdit d'utiliser un LLM pour traiter de la donnée client. Elles imposent de savoir, avant de signer un contrat ou de brancher une API, où vit la donnée envoyée, combien de temps elle y reste, et si le fournisseur s'en sert pour réentraîner ses propres modèles par défaut, un paramètre que chaque fournisseur permet de désactiver mais que peu d'équipes pensent à vérifier.

Ce qui décide vraiment : l'architecture autour du modèle

La majorité des projets de LLM en entreprise ne calent pas en test, ils calent au passage à l'échelle. Selon la même enquête Deloitte, seulement 25 % des organisations ont poussé 40 % ou plus de leurs projets pilotes jusqu'en production, alors que 54 % espèrent y arriver dans les trois à six prochains mois. L'écart ne vient presque jamais de la qualité brute du modèle choisi au départ, les modèles de 2026 répondent tous correctement sur un cas d'usage bien cadré. Il vient de tout ce qui n'a pas été prévu autour : que faire quand le modèle ne sait pas, comment surveiller une dérive de qualité avant qu'un client ne la signale, qui a le droit de modifier les instructions données au modèle en production.

Une pratique s'installe chez les équipes qui ont dépassé ce cap : router les requêtes vers plusieurs modèles selon la tâche plutôt que de tout envoyer au même, un modèle économique pour le volume, un modèle plus coûteux réservé aux cas ambigus qui le justifient. Une passerelle LLM compatible OpenAI centralise ce routage, la bascule d'un fournisseur à l'autre et le suivi des coûts, plutôt que de coder cette logique à la main pour chaque projet.

Comprendre ce qu'est un LLM ne suffit pas à construire un projet qui tient. Le choisir non plus, à lui seul. Ce qui reste à trancher, l'architecture, la gouvernance des données, le budget de tokens, la supervision une fois en production, est précisément le terrain où contacter Noxcod a du sens, au moment où la question passe de « quel modèle » à « comment le faire tenir en production », sur un projet neuf ou un prototype interne qui a validé l'idée sans encore prouver sa robustesse.

Questions fréquentes

GPT, Claude ou Mistral : lequel choisir pour un premier projet ?

Aucun des trois ne domine sur tous les critères. Le choix dépend de la tâche, du budget par requête et des contraintes de résidence des données : Mistral pour un hébergement européen garanti, Claude pour les tâches longues grâce à sa fenêtre de contexte étendue, OpenAI pour l'écosystème d'outils déjà disponible autour. La plupart des projets sérieux finissent par combiner plusieurs modèles plutôt que d'en imposer un seul partout.

Un LLM peut-il tourner entièrement sur les serveurs de l'entreprise ?

Oui, via un modèle à poids ouverts comme Llama, Mixtral ou Qwen, servi localement avec Ollama pour un usage limité ou vLLM pour un volume de production. Cette option évite toute sortie de données vers un tiers, mais transfère le coût du token vers un coût d'infrastructure GPU et de maintenance, rentable seulement à partir d'un volume de requêtes soutenu.

Envoyer des données clients à un LLM, est-ce autorisé par le RGPD ?

Oui, sous les mêmes conditions qu'un autre traitement de données personnelles : base légale identifiée, information des personnes concernées, documentation du traitement, et analyse d'impact si le risque est élevé, comme le précisent les recommandations de la CNIL de février 2025. Le point à vérifier en priorité reste la localisation des serveurs du fournisseur choisi.

Pourquoi deux LLM répondent-ils différemment à la même question ?

Chaque modèle a été entraîné sur un corpus différent, avec une architecture et des réglages propres à son fournisseur. Deux modèles peuvent tenir un raisonnement globalement juste et diverger sur les détails, un chiffre, une formulation, une nuance, sans qu'aucun des deux ne soit strictement en tort. C'est pour cela que la vérification humaine reste nécessaire sur tout contenu qui part vers un client.

Un abonnement ChatGPT ou Claude suffit-il, ou faut-il une API ?

Un abonnement grand public convient pour un usage individuel, rédaction, recherche, brouillon de document. Dès qu'un besoin implique d'automatiser une tâche à l'échelle de l'entreprise, connecter le modèle à des données internes ou l'intégrer dans un produit, l'API facturée au token devient la seule option, avec un contrôle plus fin sur le comportement du modèle et son coût réel.