LLM : définition, fonctionnement et limites

LLM : un modèle de langage, pas une application complète

LLM signifie « large language model », généralement traduit par « grand modèle de langage ». Il s’agit d’un modèle statistique entraîné à reconnaître des régularités dans des séquences et à estimer les tokens compatibles avec un contexte. Il peut servir à rédiger, résumer, extraire, reformuler ou compléter du texte. Une interface de conversation peut l’exploiter, mais cette interface, son historique et ses éventuels outils ne font pas partie automatiquement du modèle. [2]

Tous les modèles de langage ne servent pas à générer une réponse mot après mot. Certains utilisent des objectifs d’entraînement adaptés à l’analyse du texte ; d’autres sont conçus pour la génération. Un LLM est donc une famille de modèles, pas un synonyme d’« assistant » ni de moteur de recherche. Retrouvez aussi nos guides sur l’intelligence artificielle pour situer les usages.

Du texte aux tokens : ce que le modèle reçoit réellement

Avant le traitement, un tokenizer transforme le texte en unités appelées tokens. Un token peut représenter un mot, une partie de mot, un signe ou un fragment fréquent ; un mot n’équivaut donc pas toujours à un token. Chaque identifiant de token est ensuite associé à une représentation numérique que le réseau peut manipuler. Cette étape dépend du tokenizer utilisé et de la langue du texte. [2]

Imaginez la consigne « résume cette note ». Le modèle ne voit pas directement des intentions humaines : il traite des unités numériques et le contexte qui les entoure. Les espaces, la ponctuation et certaines formes rares peuvent modifier ce découpage ; il faut en tenir compte lorsqu’on estime la longueur maximale d’une entrée.

Pourquoi le Transformer et l’attention comptent

Le Transformer, proposé en 2017, s’appuie sur l’attention pour calculer quelles parties d’une séquence sont utiles au traitement d’autres parties. Dans les systèmes autorégressifs de génération, l’attention causale limite chaque position au contexte qui la précède. Des couches successives produisent des représentations adaptées à la tâche. Cela ne signifie pas qu’un score d’attention est une explication complète de la décision du modèle. [1] [3]

Le mot « Transformer » ne désigne pas un réseau unique. On rencontre des variantes de type encodeur, décodeur et encodeur-décodeur, avec des objectifs différents : représentation, prédiction de tokens manquants ou génération séquentielle. La documentation pédagogique distingue notamment le langage masqué du langage causal. [4]

Pré-entraînement et adaptation : à quel moment le modèle apprend

Au pré-entraînement, le modèle ajuste progressivement ses paramètres sur des exemples afin de réduire une erreur de prédiction. Les données sont préparées, le texte tokenisé, les prédictions comparées aux cibles d’apprentissage, puis les poids modifiés par optimisation. Selon l’architecture, la tâche peut être de prévoir le token suivant ou de retrouver des tokens masqués. Ce travail précède l’utilisation ordinaire du modèle. [3] [4]

Après cette phase, certaines variantes reçoivent un entraînement complémentaire sur des consignes ou des exemples spécialisés. Le fine-tuning modifie les paramètres ; à l’inverse, reformuler un prompt ou joindre un document change le contexte de la requête sans réentraîner automatiquement le modèle. Les objectifs, les jeux de données et les validations doivent être distingués. [5]

L’inférence : de la consigne à la réponse, étape par étape

Lorsqu’une application soumet une question, elle prépare une entrée comprenant la consigne et éventuellement des documents ou l’historique retenu. Le tokenizer encode cette entrée ; le modèle calcule une distribution de scores sur les prochains tokens ; une stratégie de décodage choisit le token suivant, puis la procédure se répète jusqu’à une condition d’arrêt. C’est l’inférence, distincte de l’optimisation des poids pendant l’entraînement. [2] [3]

Exemple fictif : on fournit une courte note d’incident et on demande une synthèse en trois points. Le LLM peut formuler « symptôme, action, point à vérifier » à partir du texte reçu. Ce scénario illustre un flux possible, pas un essai réellement exécuté. Il faudrait comparer la sortie à la note d’origine pour vérifier qu’aucun horaire, diagnostic ou résultat n’a été inventé.

• Préparer la question et les extraits autorisés.
• Transmettre les tokens et le contexte au modèle.
• Générer la réponse selon les paramètres de décodage.
• Contrôler les affirmations importantes sur les données sources.

Fenêtre de contexte, connaissances et mémoire : trois notions différentes

La fenêtre de contexte est la quantité d’informations que le système peut présenter au modèle lors d’une inférence, exprimée en tokens. Les poids appris pendant l’entraînement ne sont pas cette fenêtre ; un historique de conversation ou un document joint peut y figurer, mais sa présence n’implique pas une mémorisation durable. Une entrée trop longue doit être tronquée, résumée ou traitée autrement. [2] [3]

Un LLM seul n’interroge pas spontanément une source actuelle. Une application peut lui fournir des documents récupérés par recherche, ou le connecter à des outils : ces capacités relèvent de l’architecture autour du modèle. Pour comprendre cette séparation, notre guide sur le Model Context Protocol décrit comment exposer des outils et ressources sans confondre protocole, modèle et agent.

Ce qu’un LLM peut apporter à une tâche réelle

Un modèle peut aider à résumer une documentation, extraire des champs dans un texte, classifier des demandes, reformuler une explication ou préparer une première version de code. La qualité dépend du contexte, de la spécialisation, des exemples et des critères de contrôle. Une réponse bien écrite n’est pas nécessairement celle qui respecte les règles métier ou le format attendu.

Pour une extraction structurée, définissez les champs autorisés et le traitement des valeurs manquantes. Pour une synthèse, fournissez les sources et une consigne explicite interdisant les informations absentes. Pour du code, ajoutez les tests, l’analyse de sécurité et la relecture technique habituels : la génération ne les remplace pas.

Limites et risques : ce qu’un texte convaincant ne garantit pas

Un LLM peut présenter une information fausse avec assurance, reproduire des biais, mal interpréter une instruction ou se montrer sensible à de petites variations de formulation. Les documents transmis peuvent contenir des instructions malveillantes ; les données confidentielles et les droits d’usage exigent donc des contrôles indépendants. Le profil NIST consacré à l’IA générative recense notamment les risques d’intégrité de l’information, de sécurité et de surconfiance. [6]

Ni la taille annoncée d’un modèle ni la longueur maximale de contexte ne suffisent à garantir sa précision sur votre tâche. Un assistant relié à des outils peut en outre produire des effets réels : il faut limiter les permissions, isoler les entrées non fiables et demander confirmation pour les actions sensibles. Notre checklist de sécurité MCP complète ces précautions.

Comment évaluer un LLM avant de lui confier un travail

Définissez d’abord une tâche précise, un ensemble de cas représentatifs et les erreurs réellement pénalisantes. Comparez les sorties avec des réponses de référence, relevez les omissions, les erreurs factuelles, les refus justifiés, la stabilité du format et le temps de correction humaine. Consignez la version et la configuration employées : sans protocole constant, une comparaison ne prouve pas grand-chose.

Mesurez séparément les contraintes de confidentialité, de latence, de coûts et de maintenance. Notre grille d’évaluation des outils IA propose une méthode reproductible et le guide IA locale ou cloud aide à décider où exécuter le système. L’objectif n’est pas de trouver un « meilleur LLM » universel, mais un système contrôlable pour une tâche définie.

• Décrire les données d’entrée et les informations interdites.
• Définir les critères de réussite et les erreurs éliminatoires.
• Tester les cas ambigus, incomplets et adversariaux.
• Vérifier la traçabilité des réponses sensibles.
• Documenter les conditions où l’automatisation doit s’arrêter.