La plupart des gens ont entendu « LLM » suffisamment de fois pour ne plus demander ce que cela signifie. C’est un problème, car le modèle mental avec lequel travaillent la plupart des équipes est erroné d’une manière qui coûte réellement de l’argent. Elles traitent les LLM comme des moteurs de recherche avec une meilleure grammaire, comme des bases de données qui savent tout, ou comme des systèmes de raisonnement qui n’auraient besoin que du bon prompt. Aucune de ces comparaisons n’est exacte, et chacune mène à une catégorie différente de défaillance en production.
Voici la version honnête : un grand modèle de langage est un moteur de texte probabiliste. Il prédit le prochain token d’une séquence à partir de motifs appris sur d’immenses volumes de données d’entraînement. Il ne recherche pas d’informations. Il ne raisonne pas. Il génère la suite la plus plausible de ce que vous lui avez fourni. Comprendre ce mécanisme unique explique la plupart des réussites des LLM, ainsi que presque tout ce qui peut mal tourner.
Là où se cachent les hypothèses coûteuses
- Les LLM prédisent un texte probable, et non des faits exacts : fluidité et véracité ne sont pas liées.
- Les transformers permettent de gérer un contexte étendu, pas de comprendre.
- L’hallucination est une caractéristique structurelle de la prédiction du prochain token, pas un bug que l’on peut corriger.
- Le RAG et le fine-tuning existent parce que les LLM de base ne peuvent pas accéder de manière fiable aux données privées ou récentes.
- Les modèles plus grands sont en moyenne plus capables, mais pas plus honnêtes.
Qu’est-ce qu’un grand modèle de langage ?
Un LLM est un type de modèle d’IA reposant sur le deep learning, plus précisément un réseau de neurones profond entraîné sur d’immenses quantités de données textuelles pour réaliser des tâches impliquant le langage humain. Comprendre et générer le langage humain est ce pour quoi cette architecture est optimisée, à une échelle qui rend possible une utilisation généraliste.
Les grands modèles de langage sont des systèmes d’IA, mais d’un type bien particulier. Ce ne sont ni des systèmes basés sur des règles ni des classificateurs traditionnels. L’équipe informatique de Stanford les décrit comme des modèles fondamentaux : de grands modèles généralistes qui peuvent ensuite être adaptés à de nombreuses tâches. Databricks les définit plus simplement : un LLM est un type de modèle d’IA qui utilise le deep learning, entraîné sur de grands corpus de textes, pour accomplir un large éventail de tâches linguistiques sans entraînement spécifique à chaque tâche.
Le mot « grand » dans cette appellation a une véritable importance. Ces modèles comptent de centaines de millions à des centaines de milliards de paramètres. C’est l’échelle qui permet à un même modèle sous-jacent de résumer un document juridique, écrire du code Python, répondre à une question de support et traduire de l’espagnol, sans être réentraîné entre les tâches.
Ce qu’ils ne peuvent pas faire, et c’est la partie qui piège tout le monde : ils ne peuvent pas rechercher des faits, vérifier des affirmations par rapport à la réalité, ni raisonner d’une manière qui ressemble à ce que les humains entendent par ce mot. Ils apprennent à quoi ressemblent les grands modèles de langage. Ils n’apprennent pas ce qui est vrai. Cette distinction compte pour chaque décision concernant le lieu et la manière de les déployer.
Comment fonctionnent les grands modèles de langage : prédiction du prochain token et probabilité
Les LLM sont entraînés sur de grandes quantités de données : textes de livres, dépôts de code, sites web, forums, articles scientifiques. Leur objectif d’entraînement est simple à décrire, mais difficile à appréhender pleinement : prédire le prochain token. Étant donné une séquence de tokens, qu’est-ce qui vient ensuite ? Le modèle apprend les relations statistiques entre les tokens à travers des milliards d’exemples d’entraînement, jusqu’à pouvoir produire des suites plausibles pour presque n’importe quelle entrée.
C’est tout. C’est le mécanisme. Tout le reste relève de l’architecture et de l’échelle construites autour de cet objectif unique.
Google Developers décrit la modélisation du langage comme la tâche de prédire le mot suivant ou une séquence de mots. ApX Machine Learning le formule plus directement : les LLM sont entraînés à prédire le mot suivant d’une phrase, ce qui en fait des systèmes d’autocomplétion sophistiqués. La partie « grand » signifie que le modèle a traité suffisamment de texte pour que ces prédictions paraissent remarquablement cohérentes, conscientes du contexte et fluides. Lorsque vous utilisez GPT-4o, cela ne ressemble pas à de l’autocomplétion. Pourtant, le mécanisme sous-jacent reste le même.
Les modèles de langage neuronaux traitent le langage sous forme de séquences de tokens. Au moment de l’inférence, le modèle calcule une distribution de probabilités sur l’ensemble de son vocabulaire pour le token suivant, échantillonne cette distribution, ajoute le résultat, puis répète l’opération. Le résultat que vous voyez est le produit de plusieurs milliers de décisions d’échantillonnage enchaînées.
C’est pourquoi les sorties de l’IA sont probabilistes plutôt que déterministes. Exécutez deux fois le même prompt et vous pourriez obtenir des réponses légèrement différentes. Le modèle ne récupère pas une réponse dans une base de données. Il la construit, token par token, selon des probabilités.
Ce qu’est réellement un token
Un token est l’unité que le modèle lit et écrit. En traitement du langage naturel, les tokens ne sont pas toujours des mots complets. Ce sont des fragments : « incroyable » pourrait devenir trois tokens, « in », « croy », « able ». Les mots courts et courants correspondent généralement à un seul token. La ponctuation et les espaces ont souvent leurs propres tokens. La plupart des LLM disposent d’un vocabulaire compris entre 50 000 et 100 000 tokens possibles.
C’est important, car le modèle ne voit jamais des « phrases » ou des « idées ». Il voit une séquence d’entiers, chacun représentant un token, transmise à un type de réseau neuronal qui traite l’ensemble du contexte afin de prédire quel entier viendra probablement ensuite. La sortie est également une séquence de tokens, ensuite décodée en texte lisible.
Le nombre de tokens détermine aussi le coût et les limites de contexte. Lorsqu’une plateforme vous indique qu’un modèle prend en charge une fenêtre de contexte de 128 000 tokens, cela signifie qu’il peut conserver environ 90 000 à 100 000 mots de contexte simultanément avant de commencer à oublier les entrées antérieures.
Pourquoi les réponses semblent sûres d’elles même lorsqu’elles sont fausses
C’est la partie que j’explique le plus souvent au support, et celle qui a les conséquences pratiques les plus importantes. Le modèle sélectionne des suites de tokens à forte probabilité. Il n’évalue pas si ces tokens sont factuellement exacts. Le signal d’entraînement était : « cette suite ressemble-t-elle à du langage naturel ? », et non : « est-ce vrai ? ».
La sortie d’un LLM paraît donc fluide et assurée, car les textes fluides et assurés sont statistiquement fréquents dans les données d’entraînement. Lorsqu’il génère du langage naturel sur un sujet précis, le modèle peut produire une réponse entièrement inventée dans le même ton qu’une réponse correcte. Même structure de phrase, mêmes formulations nuancées, même assurance d’auteur. Les modèles peuvent générer un texte plausible qui est entièrement faux.
C’est cela, l’hallucination, et ce n’est pas un bug. C’est ce à quoi ressemble la prédiction du prochain token lorsque la suite la plus probable est fausse.
🤔 Réfléchissez à ceci :
Le même mécanisme qui rend la sortie d’un LLM naturelle et lisible est précisément celui qui la rend peu fiable pour les requêtes factuelles. La fluidité vient de la prédiction d’un langage statistiquement probable. L’exactitude exige de savoir ce qui est vrai. Le modèle optimise le premier aspect. Il ne possède aucune fonction objectif liée au second.
L’architecture Transformer derrière chaque LLM moderne
Tous les principaux LLM actuellement utilisés en production, GPT-4o, Claude, Gemini, Mistral, Llama, reposent sur une architecture Transformer. Comprendre ce que cela signifie en pratique, et pas seulement connaître le nom, change votre manière d’envisager ce que ces modèles peuvent et ne peuvent pas faire.
Les modèles Transformer utilisent une technique mathématique appelée auto-attention, qui permet au modèle d’évaluer la pertinence de chaque autre token de l’entrée lorsqu’il prédit le suivant. Databricks la décrit ainsi : l’architecture Transformer permet aux LLM de traiter à grande échelle un contexte étendu et des motifs linguistiques complexes en apprenant quelles parties d’une séquence d’entrée sont pertinentes les unes pour les autres, quelle que soit la distance qui les sépare. C’est le sens pratique de l’architecture Transformer : le modèle ne lit pas de gauche à droite dans une fenêtre fixe. Il considère l’ensemble du contexte à la fois, en accordant davantage d’attention aux tokens importants pour chaque prédiction.
Avant les Transformers, les modèles de langage neuronaux avaient du mal avec les dépendances à longue distance. Si une phrase commençait par « l’entreprise qui a acquis les trois startups l’année dernière... » et que le pronom « elle » apparaissait vingt mots plus loin, les architectures précédentes perdaient souvent la référence de ce « elle ». Le mécanisme d’auto-attention des modèles Transformer résout ce problème par conception : chaque token peut porter directement son attention sur n’importe quel autre token, quelle que soit sa position.
Les modèles de deep learning construits de cette manière sont également très parallélisables durant l’entraînement, ce qui explique en partie pourquoi un entraînement à grande échelle est devenu possible. Il n’est pas nécessaire de traiter une phrase séquentiellement. Toutes les positions peuvent être traitées simultanément sur du matériel moderne.
Un détail mérite d’être mentionné : les modèles que l’on appelle « génératifs préentraînés », dont la famille GPT est l’exemple le plus clair, sont des Transformers entraînés avec un objectif de modélisation causale du langage : prédire le prochain token à partir de tous les tokens précédents. Cette combinaison précise entre architecture Transformer et préentraînement massif est ce que le terme « LLM » désigne généralement en 2026.
Ce que signifie concrètement « un modèle entraîné sur des milliards de tokens »
Databricks indique que les grands modèles Transformer sont entraînés sur des milliards à des milliers de milliards de tokens issus de sources variées. La conséquence pratique de cette échelle est la généralisation. Un modèle entraîné sur suffisamment de textes diversifiés apprend des motifs linguistiques qui se transfèrent entre les sujets, les styles et les tâches, sans entraînement supplémentaire pour chacun d’eux.
C’est pourquoi un même modèle de base peut résumer un contrat, écrire une regex, expliquer un terme médical et générer un texte marketing. Les données d’entraînement l’ont exposé simultanément à tous ces domaines. Les paramètres, qui encodent les relations statistiques apprises, constituent le résultat condensé du traitement de grands ensembles de données contenant des exemples de pratiquement tous les usages du langage.
Le nombre de paramètres compte aussi. Les modèles bien plus grands, avec des centaines de milliards de paramètres, ont généralement une meilleure capacité de généralisation sur les cas limites et les tâches complexes. Mais une taille plus importante implique également un coût d’inférence plus élevé. Le choix d’un modèle est donc généralement un compromis entre capacité et coût, et non simplement une question de choisir l’option la plus grande disponible.
Les modèles préentraînés à cette échelle sont généralistes par construction. Les adaptations spécifiques à un domaine, le fine-tuning sur des jeux de données propriétaires ou la génération augmentée par récupération sur des connaissances internes viennent ensuite, au-dessus de cette base généraliste.
À quoi servent réellement les LLM dans les différents secteurs
Les modèles de langage sont des systèmes d’IA qui sont rapidement passés de la recherche à la production. Selon le rapport sur l’état de l’IA de McKinsey & Company, 65 % des organisations utilisent régulièrement l’IA générative dans au moins une fonction métier, soit près du double du taux observé dix mois auparavant. Il ne s’agit pas d’expérimentation. Il s’agit d’un usage opérationnel à grande échelle, ce qui signifie que comprendre les capacités et les limites des LLM n’est plus facultatif pour la plupart des équipes métier. Voici à quoi ressemble réellement le déploiement pratique selon les rôles :
- Les équipes de support client utilisent les LLM pour générer des brouillons de réponses, résumer de longs historiques de tickets et classer les demandes entrantes par intention. La réduction du temps de traitement est réelle. Le risque est que le brouillon cite une politique inventée par le modèle, que l’agent envoie ensuite parce qu’elle semblait plausible. Une révision humaine reste indispensable pour tout contenu destiné aux clients.
- Les équipes de contenu et de marketing utilisent les LLM pour générer des textes en volume : premiers jets, variations d’objets d’e-mails, itérations de textes publicitaires, localisation. La sortie doit être éditée. Mais le gain de vitesse dans la production des premiers jets est réel, et la plupart des équipes qui l’essaient ne reviennent pas en arrière.
- Les ingénieurs logiciels utilisent les modèles de génération de code au quotidien. La Stack Overflow Developer Survey 2025 a révélé que 84 % des développeurs utilisent ou prévoient d’utiliser des outils d’IA dans leur processus de développement. La même enquête a mis en évidence leur plus grande frustration : 66 % déclarent que les « solutions d’IA presque correctes, mais pas tout à fait » sont celles qui leur font perdre le plus de temps. C’est le problème des hallucinations qui se manifeste dans un autre domaine.
- Les analystes et travailleurs du savoir utilisent les LLM pour interroger et résumer de grands ensembles de documents : rapports financiers, documents réglementaires, articles de recherche, retours clients. Le modèle peut extraire et structurer les informations plus rapidement qu’un lecteur humain, mais la sortie doit toujours être vérifiée lorsqu’elle est déterminante pour une décision.
- Les équipes d’entreprise déploient de plus en plus de pipelines de génération augmentée par récupération (RAG) afin de permettre à un LLM de base de répondre à des questions à partir de documents internes et de bases de connaissances. Le modèle n’a pas besoin d’être fine-tuné sur des données propriétaires. Il récupère plutôt des extraits pertinents au moment de l’inférence et fonde sa réponse sur ce qu’il a trouvé. Les LLM peuvent également être utilisés dans des modèles multimodaux qui traitent ensemble les images et les documents, ainsi que dans des modèles de raisonnement qui abordent la décomposition étape par étape des problèmes, bien que ces deux catégories soient encore en maturation.
Côté RAG en entreprise, le cas d’usage que je vois le plus souvent mentionné au support est essentiellement : « nous voulons interroger notre documentation interne et obtenir de vraies réponses, pas un lien vers une page Confluence de 2021 ». C’est un problème légitime. Dans Latenode, les équipes peuvent connecter un workflow à leur base de connaissances interne grâce au RAG intégré sur des PDF et CSV importés, exécuter une requête avec le modèle d’IA qui correspond à leurs besoins depuis une liste déroulante unique, puis envoyer la sortie structurée vers Slack, un CRM ou un outil de support. Aucune configuration de base de données vectorielle externe n’est nécessaire. Que vous construisiez un outil de conformité, un assistant de support ou une couche de recherche interne, le même canevas d’automatisation gère à la fois la logique de récupération et le routage en aval.
Fine-tuning et prompt engineering : comment les équipes adaptent les LLM au travail réel
Un LLM de base entraîné sur des données générales est utile. Un LLM de base façonné pour votre tâche, votre vocabulaire ou votre format de sortie spécifique est nettement plus utile. Il existe trois principales approches pour ce façonnage, et les équipes se tournent systématiquement d’abord vers la plus coûteuse.
Le fine-tuning consiste à prendre un modèle préentraîné et à poursuivre son entraînement sur un jeu de données spécifique à un domaine : vos tickets de support, votre documentation produit, vos contrats clients. Les LLM peuvent être fine-tunés pour adopter un comportement différent : utiliser le ton de votre entreprise, comprendre votre nomenclature interne, produire des sorties dans un format donné. Les LLM peuvent être entraînés ainsi grâce à l’apprentissage supervisé ou à l’apprentissage par renforcement à partir de retours humains, qui ajustent tous deux les poids du modèle vers les sorties que vous préférez. Le fine-tuning modifie fondamentalement ce que le modèle connaît et sa manière de répondre.
Le prompt engineering est moins coûteux et plus rapide. Il consiste à structurer l’entrée fournie au modèle, le prompt, afin de façonner la sortie sans modifier le modèle lui-même. Prompts système, exemples few-shot, instructions de raisonnement étape par étape, contraintes de format de sortie : tout cela relève du prompt engineering. La plupart des tâches d’adaptation générale ne nécessitent pas de fine-tuning et peuvent être entièrement traitées grâce à une conception soignée des prompts. C’est précisément ce pour quoi les capacités de traitement du langage naturel des LLM ont été conçues.
La troisième voie est le RAG. Comme l’a souligné MIT Sloan, la génération augmentée par récupération permet aux équipes d’ancrer les réponses des LLM dans des données propriétaires ou en temps réel en récupérant des documents pertinents au moment de l’inférence et en les injectant dans le contexte du prompt. Les capacités de traitement du langage des LLM restent intactes. Vous donnez simplement au modèle de meilleurs éléments sur lesquels travailler. Le RAG ne nécessite pas de réentraînement et n’implique pas les poids du modèle. C’est un modèle architectural, pas un processus d’entraînement.
Quand le fine-tuning justifie l’effort et quand le prompt engineering suffit
Voici la répartition pratique : le prompt engineering gère la plupart des tâches d’adaptation générale. Le fine-tuning est pertinent lorsque le modèle échoue systématiquement sur le vocabulaire, le ton ou le format de sortie spécifiques à votre domaine, même après des itérations soigneuses sur le prompt.
Les grands modèles préentraînés sur des données variées disposent déjà de solides performances de base sur la plupart des sujets. Si le problème vient du fait que le modèle ne comprend pas vos noms de produits internes ou votre terminologie juridique, quelques exemples few-shot bien choisis dans le prompt résolvent souvent le problème sans toucher au modèle. Les modèles n’ont généralement besoin que d’un nombre étonnamment faible d’exemples en contexte pour adapter significativement leur style de sortie.
Le fine-tuning mérite le coût de préparation du jeu de données et d’entraînement lorsque : vous disposez de centaines à des milliers d’exemples étiquetés du comportement de sortie exact souhaité ; le domaine est suffisamment spécialisé pour que le prompting général échoue de manière répétée ; et vous avez besoin d’un comportement stable, qui ne dépende pas de la longueur du prompt. Les objectifs de modélisation du langage masqué sont également utilisés dans certaines variantes de fine-tuning, spécifiquement pour les tâches de classification.
Le schéma que je constate régulièrement au support : les équipes investissent dans le fine-tuning avant d’avoir vérifié si un prompt bien structuré résout le problème. C’est l’ordre inverse. Commencez par le prompt engineering. Documentez les cas où il échoue. Ne construisez un jeu de données de fine-tuning qu’autour des lacunes qui subsistent après un prompting rigoureux. Ignorer cette séquence revient généralement à créer un jeu de données coûteux pour résoudre un problème qu’une révision de prompt de cinq minutes aurait réglé.
Quatre idées reçues sur les LLM qui mènent à de mauvaises décisions
Il ne s’agit pas de débats philosophiques. Chacune de ces idées reçues correspond à une erreur de décision concrète qui apparaît dans de vrais déploiements. Je m’appuie sur l’analyse d’ApX Machine Learning des idées reçues courantes sur les LLM et sur la présentation de Machine Learning Mastery des erreurs commises par les équipes, car ces problèmes sont bien documentés et leurs conséquences sont constantes.
Idée reçue 1 : les LLM comprennent le langage comme les humains. Ce n’est pas le cas. Un LLM ne comprend pas le sens. Il apprend des motifs statistiques dans le langage et prédit ce qui vient ensuite à partir de ces motifs. Le modèle n’a aucune compréhension du monde physique, aucun état interne, aucune intention. Il produit des sorties qui ressemblent à de la compréhension parce qu’il a été entraîné sur des textes écrits par des personnes qui comprenaient des choses. Ce n’est pas la même chose. L’erreur pratique qui en découle : les équipes comptent trop sur le modèle pour détecter les entrées ambiguës, les cas limites et les demandes logiquement incohérentes, parce qu’il « comprend » ce qui est demandé. Ce n’est pas le cas. Il prédit un langage qui correspond au motif.
Idée reçue 2 : les LLM sont des bases de données factuelles. Ce n’est pas le cas. Les LLM reposent sur l’apprentissage de motifs, et non sur le stockage de connaissances avec une fonction de recherche. Lorsqu’un modèle répond à une question factuelle, il génère la réponse la plus plausible selon son entraînement ; il n’interroge pas une base de connaissances vérifiée. C’est la racine structurelle de l’hallucination. Le modèle peut citer avec assurance un article qui n’existe pas, attribuer une citation à quelqu’un qui ne l’a jamais prononcée ou affirmer une statistique avec un chiffre inventé. Les systèmes d’IA générative de ce type n’intègrent aucune étape de vérification de la vérité dans leur architecture. L’erreur pratique : les équipes traitent les sorties du modèle comme une source de recherche sans vérification. Cela fonctionne très bien jusqu’au jour où ce n’est plus le cas, puis échoue devant un client ou un régulateur.
Idée reçue 3 : plus grand signifie plus exact. Plus capable, oui. Plus exact concernant les faits, pas nécessairement. Des modèles comme GPT-4o et Claude savent qu’une question leur est posée et ont été entraînés, grâce à l’apprentissage par renforcement à partir de retours humains, à produire des réponses utiles. Être utile et être correct sont corrélés, mais ne sont pas équivalents. Un modèle plus grand écrira souvent une réponse erronée plus convaincante qu’un modèle plus petit. Les modèles propriétaires continuent de progresser dans les benchmarks, et l’échelle est corrélée à un meilleur raisonnement sur les tâches complexes. Mais le risque d’hallucination ne disparaît pas avec l’échelle.
Idée reçue 4 : les LLM ont des opinions et des personnalités stables. Ce qui ressemble à une personnalité est un artefact d’entraînement. Le modèle a été façonné par ses données d’entraînement et son processus de fine-tuning, y compris l’apprentissage par renforcement à partir de retours humains, afin de produire des réponses dotées d’un ton cohérent et d’une disposition apparente. Ce n’est pas un état interne stable. C’est une distribution de sortie apprise. Des modèles comme ChatGPT peuvent exprimer différentes positions sur une même question selon la façon dont le prompt est formulé, les éléments présents dans leurs données d’entraînement et la température d’échantillonnage. Les LLM continuent de produire des sorties différentes d’une exécution à l’autre. L’erreur pratique ici : les équipes construisent des workflows qui supposent un comportement cohérent du modèle, puis découvrent qu’il se comporte différemment quand le prompt change légèrement, lorsque le contexte est plus long ou lorsqu’une version du modèle est mise à jour.
📊 En pratique :
Les LLM génèrent du texte à partir de distributions apprises, et non en interrogeant une base de connaissances vérifiée. Cela signifie qu’une citation qui semble sûre d’elle peut être entièrement fabriquée : même syntaxe, même précision, mais totalement inventée. La fluidité d’une réponse hallucinée est généralement identique à celle d’une réponse correcte. La vérification doit venir de l’extérieur du modèle, et non d’une lecture attentive de sa sortie.
