LLM : Le guide complet pour comprendre les modèles de langage sans perdre la raison

Ou : Comment des statistiques sur des mots ont convaincu la planète entière qu’elles savaient réfléchir

Imaginez que vous engagez un stagiaire. Ce stagiaire a lu Internet. Tout Internet. Chaque page Wikipédia, chaque fil Reddit, chaque article scientifique, chaque commentaire YouTube (oui, même ceux-là), chaque roman, chaque notice technique de micro-ondes jamais publiée en ligne. Ce stagiaire ne comprend rien de ce qu’il a lu — pas au sens humain du terme — mais il a développé une intuition statistique terrifiante pour deviner quel mot vient après quel autre mot. Vous lui posez une question, et il vous répond quelque chose qui ressemble beaucoup à ce qu’une personne compétente dirait. Parfois c’est brillant. Parfois c’est complètement faux mais dit avec une assurance déconcertante.

Ce stagiaire, c’est un LLM.

LLM signifie Large Language Model, soit « grand modèle de langage » en français. Et le mot important ici, c’est « grand ». Pas parce que c’est un terme technique précis (ça ne l’est pas), mais parce que c’est exactement ce qui a changé. On faisait du traitement du langage depuis des décennies. Ce qui est nouveau, c’est l’échelle.

D’accord, mais concrètement, c’est quoi ?

Un LLM est un programme informatique — un réseau de neurones, pour être plus précis — entraîné à faire une chose et une seule : prédire le prochain mot¹ dans une séquence de texte. Vous lui donnez « Le chat est assis sur le », et il calcule que « tapis » est plus probable que « réacteur nucléaire ». C’est tout. C’est littéralement tout ce qu’il fait.

Ce qui est fascinant (et un peu dérangeant, si vous y réfléchissez trop longtemps), c’est qu’en répétant cette opération des milliards de fois sur des milliards de textes, le modèle finit par développer des capacités qui ressemblent beaucoup à de la compréhension. Il peut traduire, résumer, écrire du code, rédiger des emails, expliquer la relativité générale à un enfant de dix ans, ou composer un sonnet en alexandrins sur la fiscalité québécoise. Tout ça en prédisant le mot suivant, encore et encore.

C’est comme si quelqu’un apprenait à jouer aux échecs uniquement en regardant des millions de parties sans jamais qu’on lui explique les règles. À un moment donné, il joue bien. Pas parce qu’il comprend les échecs. Parce qu’il a vu suffisamment de patterns.

L’architecture Transformer, ou : la vraie révolution derrière le buzzword

Pour comprendre pourquoi les LLM fonctionnent, il faut parler de l’architecture Transformer. C’est un article de recherche de 2017, publié par une équipe de Google avec un titre qui, rétrospectivement, était prophétique : « Attention Is All You Need »².

Avant les Transformers, les modèles de langage traitaient les mots un par un, dans l’ordre, comme quelqu’un qui lirait un livre lettre par lettre. C’était lent et ça posait un problème fondamental : quand vous arrivez à la fin d’une longue phrase, vous avez à moitié oublié le début. Les Transformers ont résolu ça avec un mécanisme appelé auto-attention (self-attention).

L’auto-attention, c’est la capacité du modèle à regarder tous les mots d’une phrase en même temps et à décider lesquels sont importants les uns par rapport aux autres. Dans la phrase « La banque du fleuve était couverte de mousse », le mécanisme d’attention permet au modèle de comprendre que « banque » ici fait référence à « fleuve » (la rive) et pas à un établissement financier. Il fait ça en calculant des scores de pertinence entre chaque paire de mots. C’est élégant. C’est aussi extraordinairement coûteux en calcul, ce qui explique pourquoi l’entraînement de ces modèles nécessite des quantités obscènes de GPU.

Le vocabulaire essentiel (parce qu’il faut bien)

Voici les termes que vous allez croiser dès qu’une conversation touche de près ou de loin aux LLM. Je vais essayer de les rendre moins ennuyeux qu’ils ne le sont.

Les paramètres

Quand on parle d’un modèle à « 70 milliards de paramètres » ou « 400 milliards de paramètres », on parle du nombre de valeurs numériques que le modèle a apprises pendant son entraînement. Pensez aux paramètres comme aux synapses d’un cerveau artificiel : chacun contient un tout petit bout d’information sur la façon dont les mots se rapportent les uns aux autres. Plus il y en a, plus le modèle peut capturer de nuances dans le langage. Et plus il coûte cher à faire tourner — c’est la partie que les présentations marketing mentionnent moins.

Pour donner un ordre de grandeur : GPT-3 avait 175 milliards de paramètres en 2020. Les modèles actuels les plus grands dépassent le trillion (mille milliards). On est passé d’un truc impressionnant à un truc qui nécessite une petite centrale électrique pour fonctionner.

Les tokens

Un token n’est pas exactement un mot. C’est l’unité de base que le modèle manipule. En anglais, « tokenization » découpe généralement un mot courant en un seul token, mais un mot rare ou long peut être découpé en plusieurs morceaux. En français, c’est pareil, sauf que nos accents et notre grammaire compliquent un peu les choses (comme d’habitude).

Pour donner un repère pratique : un token correspond en moyenne à environ trois quarts d’un mot en anglais, un peu moins en français. Un texte de 1 000 mots fait environ 1 300 à 1 500 tokens. Pourquoi c’est important ? Parce que tout se compte en tokens : la facturation des API, les limites d’entrée et de sortie, et surtout la fameuse fenêtre de contexte.

La fenêtre de contexte

La fenêtre de contexte (context window), c’est la quantité maximale de texte que le modèle peut « voir » en même temps. Si vous lui envoyez un prompt, l’historique de la conversation, des instructions système, et un document de 50 pages, tout ça doit tenir dans la fenêtre de contexte. Si ça dépasse, le modèle oublie le début — ou, plus précisément, il ne l’a jamais vu.

Les premiers modèles avaient des fenêtres de contexte de quelques milliers de tokens (environ deux pages de texte). Les modèles actuels montent à 128 000, 200 000, voire un million de tokens. Claude, par exemple, offre une fenêtre allant jusqu’à 200 000 tokens en standard — et jusqu’à un million sur certains modèles — ce qui correspond à plusieurs romans complets. Vous pouvez lui coller un document entier et lui demander de le résumer. Il y a cinq ans, ça relevait de la science-fiction. Aujourd’hui, c’est un mardi après-midi.

Le prompt

Le prompt, c’est tout ce que vous envoyez au modèle : votre question, vos instructions, le contexte, les exemples, les contraintes. C’est le texte d’entrée. Et la qualité de ce que vous obtenez en sortie dépend énormément de la qualité de ce que vous mettez en entrée. Ce qui nous amène à…

Le prompt engineering

Le prompt engineering (ou « ingénierie de prompt », si vous tenez à le dire en français), c’est l’art et la science de formuler vos prompts pour obtenir les meilleurs résultats possibles. C’est un domaine à part entière, avec ses techniques, ses bonnes pratiques, et ses gens sur LinkedIn qui se présentent comme « prompt engineers » (ce qui est un métier qui n’existait pas il y a trois ans et qui, si les modèles continuent de s’améliorer, n’existera peut-être plus dans trois ans — mais c’est un autre débat).

Les techniques de base incluent le few-shot prompting (donner des exemples de ce qu’on attend), le chain-of-thought (demander au modèle de raisonner étape par étape), et la définition de rôles (« Tu es un expert en droit fiscal québécois »). La technique la plus sous-estimée reste la plus simple : être précis dans ce qu’on demande. Les modèles ne lisent pas dans vos pensées. Ils lisent vos mots.

Les instructions système

Les instructions système (system prompt), c’est un texte que le développeur place en amont de la conversation pour cadrer le comportement du modèle. C’est là qu’on définit le ton, le rôle, les règles, les limites. L’utilisateur final ne les voit généralement pas, mais elles influencent tout ce que le modèle génère.

C’est un peu comme les consignes qu’on donne à un employé avant qu’il prenne son poste : « Tu es poli, tu réponds en français, tu ne donnes pas de conseils médicaux, tu ne fais pas de blagues sur la politique. » Sauf que l’employé en question a tendance à les oublier si la conversation dure trop longtemps, ce qui est un problème assez spécifique à ce type d’employé.

Comment on fabrique un LLM (la version honnête)

La création d’un LLM se déroule en plusieurs phases, et chacune coûte plus cher que ce que vous pensez.

Phase 1 : Le pré-entraînement

Le pré-entraînement (pre-training), c’est la phase où le modèle apprend le langage en général. On lui donne des quantités astronomiques de texte — des milliards de pages web, des livres, du code source, des articles scientifiques, des forums — et on lui demande de prédire le prochain mot, encore et encore, pendant des semaines, sur des milliers de GPU.

C’est la phase la plus coûteuse. On parle de dizaines, voire de centaines de millions de dollars pour les modèles les plus grands. C’est aussi la raison pour laquelle seule une poignée d’entreprises dans le monde peut se permettre de créer des LLM « from scratch » : OpenAI, Anthropic, Google, Meta, Mistral, et quelques autres. C’est un club assez exclusif, dont le droit d’entrée se mesure en factures d’électricité.

Le résultat de cette phase, c’est un modèle de base (base model) : il est bon pour compléter du texte, mais il n’est pas encore très utile en tant qu’assistant. Si vous lui posez une question, il risque de continuer votre texte comme s’il écrivait un article, au lieu de vous répondre. C’est un peu comme un étudiant qui a lu toute la bibliothèque mais qui n’a jamais appris à avoir une conversation.

Phase 2 : Le fine-tuning

Le fine-tuning (ou « affinage »), c’est la phase où on prend le modèle de base et on continue son entraînement sur un jeu de données plus petit mais plus ciblé. On lui montre des exemples de conversations : voici une question, voici une bonne réponse. Voici une instruction, voici comment l’exécuter correctement. Voici un texte en anglais, voici sa traduction en français.

C’est cette phase qui transforme un modèle de base en un modèle utile. Le coût est beaucoup plus raisonnable que le pré-entraînement — de quelques milliers à quelques centaines de milliers de dollars, selon l’ampleur — et c’est aussi la phase que les entreprises peuvent réaliser elles-mêmes pour adapter un modèle existant à leur domaine. Si vous avez un modèle généraliste et que vous voulez qu’il devienne expert en analyse de contrats d’assurance, le fine-tuning est votre ami.

Il existe des variantes économiques du fine-tuning, dont les plus connues sont LoRA (Low-Rank Adaptation) et QLoRA. Au lieu de modifier les milliards de paramètres du modèle entier, ces techniques n’ajustent qu’une petite fraction des poids, ce qui réduit drastiquement les besoins en mémoire GPU et en temps de calcul. C’est comme rénover une cuisine au lieu de reconstruire toute la maison.

Plus généralement, ces approches font partie de ce qu’on appelle le PEFT (Parameter-Efficient Fine-Tuning), une famille de méthodes qui dit essentiellement : « On peut adapter ce modèle sans tout refaire, et ça marche étonnamment bien. »

Phase 3 : L’alignement

L’alignement est probablement la partie la plus importante et la moins comprise du processus. C’est la phase où on essaie de faire en sorte que le modèle se comporte comme un humain raisonnable voudrait qu’il se comporte. C’est-à-dire : qu’il soit utile, qu’il soit honnête, qu’il ne produise pas de contenu dangereux, et qu’il admette quand il ne sait pas (ce dernier point étant, en pratique, le plus difficile à obtenir).

La technique la plus connue pour l’alignement s’appelle RLHF (Reinforcement Learning from Human Feedback), soit « apprentissage par renforcement à partir de retours humains ». Le principe : des humains évaluent différentes réponses du modèle à la même question, et le modèle apprend à préférer les réponses jugées meilleures. C’est comme dresser un chien, sauf que le chien a lu toute la littérature mondiale et qu’il a tendance à improviser.

L’alignement est aussi un sujet de recherche très actif et un enjeu majeur de l’industrie. La question « comment s’assurer qu’un système très capable fait ce qu’on veut qu’il fasse » est, si vous y pensez deux minutes, une question assez fondamentale. Et on n’a pas fini d’y répondre.

L’inférence, ou : quand le modèle travaille enfin

L’inférence, c’est le moment où le modèle génère une réponse à partir de votre prompt. Par opposition à l’entraînement (où on ajuste les paramètres), l’inférence ne modifie rien dans le modèle : elle utilise les paramètres existants pour produire du texte. C’est la phase qui vous concerne si vous êtes utilisateur ou si vous payez une facture d’API.

Et la facture dépend de plusieurs facteurs, mesurés par des métriques que tout le monde cite dans les benchmarks et que personne n’explique jamais :

TPS (Tokens Per Second) : le nombre de tokens que le modèle génère par seconde. Plus c’est élevé, plus la réponse arrive vite. Les modèles actuels varient de quelques dizaines à plusieurs centaines de TPS, selon la taille du modèle et le matériel utilisé.

TtFT (Time to First Token) : le temps entre votre requête et le premier mot de la réponse. C’est ce que l’utilisateur perçoit comme « la lenteur du système ». Si le TtFT est de 3 secondes, l’utilisateur a l’impression que rien ne se passe pendant 3 secondes. Si c’est 200 millisecondes, l’expérience est fluide. C’est la métrique qui compte le plus pour l’expérience utilisateur, et c’est la première que les équipes d’infrastructure optimisent.

Latence : le temps total entre la requête et la réponse complète. La latence dépend du TtFT plus le temps de génération des tokens. Si votre application facture à l’utilisation ou si vos utilisateurs sont impatients (c’est-à-dire si vos utilisateurs sont des humains), la latence est votre ennemie.

Et pour réduire tout ça, il y a la quantification : une technique qui réduit la précision numérique des paramètres du modèle (par exemple de 16 bits à 4 ou 8 bits) pour accélérer l’inférence et diminuer la consommation de mémoire. Le compromis est une légère perte de qualité, mais en pratique, un bon modèle quantifié à 4 bits reste remarquablement performant. C’est l’équivalent de compresser une image JPEG : on perd un peu de détail, mais pour la plupart des usages, personne ne voit la différence.

Il y a aussi le KV-cache (Key-Value cache), un mécanisme d’optimisation qui garde en mémoire les calculs intermédiaires des tokens déjà traités pour ne pas les recalculer à chaque nouveau token. Sans KV-cache, générer une longue réponse serait exponentiellement plus lent. C’est le genre de détail technique qui ne passionne personne en dehors des ingénieurs en infrastructure, mais qui fait la différence entre un chatbot utilisable et un chatbot qui met 30 secondes à répondre « Bonjour ».

Le décodage : comment le modèle choisit ses mots

Le modèle ne produit pas du texte mot par mot de façon déterministe. À chaque étape, il calcule une distribution de probabilité sur tous les tokens possibles, puis il en choisit un. La méthode de choix — le décodage (sampling) — influence profondément le style et la qualité de la réponse.

La température est le paramètre le plus connu. Une température basse (proche de 0) rend le modèle très conservateur : il choisit presque toujours le token le plus probable, ce qui donne des réponses prévisibles et factuelles. Une température élevée (proche de 1 ou au-delà) rend le modèle plus créatif mais aussi plus imprévisible. C’est le curseur « ennuyeux mais fiable » vs « intéressant mais potentiellement n’importe quoi ».

D’autres méthodes de décodage existent : top-k (ne considérer que les k tokens les plus probables), top-p (ne considérer que les tokens dont les probabilités cumulées atteignent un seuil p), beam search (explorer plusieurs séquences en parallèle pour trouver la meilleure globale). En pratique, la plupart des applications utilisent une combinaison de température et de top-p, et c’est suffisant.

Les embeddings : quand les mots deviennent de la géométrie

Les embeddings sont des représentations numériques de mots, phrases ou documents sous forme de vecteurs dans un espace de haute dimension. Concrètement, chaque mot est converti en une liste de nombres (un vecteur) de sorte que des mots proches en sens se retrouvent proches en géométrie. « Chat » et « félin » sont proches. « Chat » et « amortissement fiscal » sont loin. (Sauf dans certains contextes très spécifiques.)

Les embeddings sont à la base de la recherche sémantique : au lieu de chercher des mots-clés exacts dans un document, on cherche des documents dont le sens est proche de la requête. C’est aussi un composant essentiel du RAG (on y arrive).

RAG : quand le modèle a besoin de notes de cours

Le problème fondamental des LLM, c’est qu’ils ne savent que ce qu’ils ont appris pendant leur entraînement. Si vous leur posez une question sur un événement qui s’est passé après leur date d’entraînement, ils ne savent pas. Si vous leur demandez de parler de vos documents internes, ils ne savent pas non plus. Et s’ils ne savent pas, ils ne vont pas vous dire « je ne sais pas » — ils vont inventer quelque chose de plausible.

C’est là qu’intervient le RAG (Retrieval-Augmented Generation), littéralement « génération augmentée par récupération ». Le principe est simple et élégant : avant de demander au modèle de répondre, on va d’abord chercher des documents pertinents dans une base de connaissances (en utilisant des embeddings pour la recherche sémantique), puis on les injecte dans le prompt. Le modèle génère alors sa réponse en s’appuyant sur ces documents.

C’est comme la différence entre un examen à livre ouvert et un examen à livre fermé. Le même étudiant peut donner des réponses radicalement différentes selon qu’il a accès à ses notes ou non. Le RAG donne au modèle accès à ses notes.

En pratique, un pipeline RAG typique ressemble à ceci : (1) l’utilisateur pose une question, (2) on cherche les documents pertinents dans une base vectorielle, (3) on construit un prompt qui inclut la question et les documents, (4) on envoie le tout au modèle, (5) le modèle génère une réponse basée sur les documents fournis. C’est simple sur le papier. En pratique, chaque étape peut mal tourner de façons créatives et surprenantes.

Les hallucinations : le problème qui ne veut pas partir

Les hallucinations sont peut-être le concept le plus important à comprendre quand on utilise un LLM. Une hallucination, c’est quand le modèle produit une réponse factuellement fausse mais exprimée avec une confiance totale. Il invente une citation, attribue un livre à un mauvais auteur, ou vous explique avec assurance qu’une loi qui n’existe pas a été votée en 2019.

Ce n’est pas un bug. C’est une conséquence directe du fonctionnement du modèle. Le modèle optimise la vraisemblance linguistique — il génère du texte qui a l’air vrai — pas la vérité factuelle. Il ne « sait » pas ce qui est vrai. Il sait ce qui a l’air vrai. Et ces deux choses sont, malheureusement, très différentes.

C’est pour ça que les garde-fous existent. C’est pour ça que le RAG est utile (il donne au modèle des sources vérifiables). Et c’est pour ça que la règle numéro un avec les LLM reste : ne jamais faire confiance aveuglément à la sortie d’un modèle, surtout quand les faits comptent³.

Les types de modèles : du généraliste au spécialisé

Tous les LLM ne sont pas les mêmes, et il est utile de comprendre les grandes catégories.

Un modèle généraliste (comme Claude, GPT, ou Gemini) est entraîné sur un large éventail de données et peut gérer des tâches très différentes : rédaction, code, traduction, analyse, conversation. C’est le couteau suisse. Un modèle spécialisé est un modèle (souvent fine-tuné à partir d’un modèle généraliste) optimisé pour un domaine précis : médical, juridique, financier, ou un format spécifique comme la génération de code.

Un chatbot est une interface conversationnelle construite au-dessus d’un LLM, avec gestion du contexte, des rôles, des personnalités, et des contraintes de sécurité. C’est ce que la plupart des gens utilisent quand ils « parlent à l’IA ». Le modèle est le moteur ; le chatbot est la voiture.

Un agent va plus loin : c’est un système qui combine un LLM avec des outils externes — navigation web, bases de données, API, système de fichiers — et une boucle de décision. Le modèle ne se contente plus de répondre à des questions ; il planifie, exécute des actions, observe les résultats, et ajuste son approche. C’est la frontière actuelle de ce que les LLM peuvent faire, et c’est là que les choses deviennent vraiment intéressantes (et vraiment compliquées).

Et puis il y a les modèles multimodaux : des modèles capables de traiter et de générer différents types de données — texte, images, audio, vidéo. Claude peut analyser des images. GPT-4o peut comprendre de l’audio. Gemini peut traiter de la vidéo. La tendance est clairement à la convergence : un seul modèle qui gère tout. On n’y est pas encore tout à fait, mais on s’en rapproche chaque trimestre.

Les biais et la sécurité : l’éléphant dans la pièce

Les LLM reflètent les données sur lesquelles ils ont été entraînés. Si ces données contiennent des biais — et elles en contiennent, parce qu’Internet contient des biais — le modèle les reproduira. Parfois il les amplifiera. Un modèle peut avoir tendance à associer certaines professions à certains genres, certains comportements à certaines origines, ou certaines compétences à certains niveaux d’éducation. Ce n’est pas de la malveillance. C’est de la statistique.

C’est pour ça que l’alignement, le RLHF, et le filtrage de contenu (content filtering, garde-fous) existent. Des classifieurs analysent les requêtes entrantes et les réponses sortantes pour bloquer ou modifier les contenus jugés dangereux, discriminatoires ou inappropriés. C’est un travail permanent, jamais terminé, et souvent imparfait — mais c’est un travail nécessaire.

L’opacité du modèle complique les choses : il est très difficile d’expliquer pourquoi un LLM a produit une réponse particulière. Il n’y a pas de règles explicites, pas d’arbre de décision qu’on peut inspecter. Il y a un réseau de centaines de milliards de paramètres, et la réponse émerge de leurs interactions. Les chercheurs en interprétabilité travaillent à rendre ces modèles plus transparents, mais on est encore loin d’une boîte de verre.

Ce que les LLM font bien et ce qu’ils font mal

Ce qu’ils font bien

La génération de texte est leur terrain de jeu naturel : rédaction de brouillons, reformulation, traduction, résumé, storytelling, génération de code. La qualité est, pour la plupart de ces tâches, suffisamment bonne pour être utile dans un contexte professionnel, même si elle nécessite presque toujours une relecture humaine.

La généralisation est impressionnante : un seul modèle peut manipuler des emails, du code, des contrats, des notices techniques, des recettes de cuisine et des poèmes, sans être explicitement reprogrammé pour chaque type de contenu. C’est cette polyvalence qui a rendu les LLM omniprésents aussi rapidement.

Et l’interface en langage naturel est ce qui a tout changé en termes d’adoption. Avant les LLM, pour interagir avec un programme, il fallait apprendre sa syntaxe. Maintenant, vous pouvez dire « Fais-moi un tableau croisé dynamique de ces données par trimestre » et obtenir un résultat. La barrière d’entrée a été anéantie.

Ce qu’ils font mal

L’exactitude factuelle reste le talon d’Achille. Les LLM optimisent la vraisemblance du texte, pas la conformité à la réalité. Si vous les utilisez comme source d’information brute sans vérification, vous aurez des mauvaises surprises.

Les biais dans les données d’entraînement se propagent aux réponses. Ce n’est pas un problème résolu. C’est un problème atténué.

Et le raisonnement logique complexe reste fragile. Les LLM peuvent donner l’illusion d’un raisonnement rigoureux, mais confrontés à des problèmes qui nécessitent une vraie déduction multi-étapes ou une compréhension causale profonde, ils peuvent échouer de façon spectaculaire — tout en maintenant un ton parfaitement assuré.

Comment on intègre un LLM dans un produit

Pour relier tout ça à la pratique, voici à quoi ressemble un « stack LLM » typique quand on veut l’intégrer dans une application.

API vs modèle hébergé : vous pouvez consommer un LLM via l’API d’un fournisseur (OpenAI, Anthropic, Google, Mistral) ou héberger un modèle open source (Llama, Mistral, Qwen) sur vos propres serveurs. Le premier cas est simple à mettre en place mais implique une dépendance à un tiers. Le second demande plus d’infrastructure mais donne un contrôle total sur le modèle et les données.

Orchestration : une couche d’orchestration gère les prompts, les rôles (système, utilisateur, assistant), la mémoire de conversation et les appels éventuels aux outils (RAG, recherche web, bases de données métier). C’est le chef d’orchestre entre l’utilisateur et le modèle.

Observabilité : en production, on suit les métriques — latence, TPS, coûts, taux de satisfaction, incidents de sécurité — pour ajuster les prompts, les modèles et les garde-fous. Sans observabilité, on navigue à l’aveugle, et naviguer à l’aveugle avec un modèle qui peut halluciner, c’est une mauvaise idée.

Itération : le cycle réel n’est jamais « je branche un LLM et c’est terminé ». C’est plutôt : prototyper avec des prompts simples → améliorer les prompts → ajouter du RAG → peut-être fine-tuner sur vos données → observer les résultats → recommencer. C’est une boucle continue. Bienvenue.

Tableau récapitulatif

Le mot de la fin

Les LLM sont, selon le point de vue, soit le plus grand bond technologique depuis Internet, soit le plus grand exercice de marketing de l’histoire récente, soit les deux en même temps. La vérité est que ce sont des outils remarquablement puissants avec des limites réelles que beaucoup de gens préfèrent ignorer.

Ils ne comprennent pas le monde. Ils ne raisonnent pas au sens où un humain raisonne. Mais ils ont une capacité à manipuler le langage qui est, objectivement, sans précédent. Et dans un monde où une énorme partie de la valeur économique transite par le langage — contrats, code, emails, rapports, communications — un outil qui manipule bien le langage est un outil extraordinairement utile.

La clé, comme souvent avec les outils puissants, c’est de savoir ce qu’on tient entre les mains. Et ce glossaire est là pour ça.