C'est quoi un LLM ? Comprendre les modèles de langage simplement

Des millions de personnes utilisent quotidiennement un modèle de langage. Presque personne ne sait ce qui se passe entre le moment où l'on appuie sur Entrée et celui où le texte apparaît.

Ce n'est pas grave pour conduire une voiture sans connaître le cycle à quatre temps. Ça l'est davantage ici, parce que l'ignorance du mécanisme produit deux erreurs symétriques et coûteuses : croire que la machine comprend ce qu'elle écrit, ou croire qu'elle ne fait que recopier des phrases apprises. Les deux sont fausses, et les deux conduisent à mal l'utiliser.

Cet article explique le fonctionnement réel, sans équation. À la fin, vous saurez pourquoi un LLM invente des références bibliographiques avec aplomb, pourquoi il échoue à compter les lettres d'un mot, pourquoi il vous coûte plus cher en français qu'en anglais, et ce qu'on peut faire de tout cela.

Le principe, en une phrase

Un modèle de langage fait une seule chose : il prédit le prochain morceau de texte le plus probable, compte tenu de ce qui précède.

C'est tout. Tout le reste — la capacité à écrire du code, à traduire, à résumer, à tenir une conversation — découle de cette unique opération, répétée.

Quand vous écrivez « La capitale de la France est », le modèle calcule une distribution de probabilité sur tous les morceaux de texte possibles. « Paris » y arrive largement en tête. Il en choisit un, l'ajoute à la phrase, puis recommence avec le texte augmenté. Puis encore. Un mot après l'autre, jusqu'à l'arrêt.

Cette description paraît trop simple pour expliquer ce que ces systèmes accomplissent. C'est pourtant exactement ce qui se passe. La complexité ne réside pas dans l'opération, mais dans la machinerie qui calcule cette probabilité — et c'est cette machinerie que nous allons ouvrir.

Retenez d'emblée une conséquence, car elle explique la moitié des comportements déroutants : le modèle ne sait pas où il va. Il ne planifie pas sa réponse avant de commencer. Il produit un morceau, puis se relit, puis produit le suivant. Une phrase cohérente sur trois cents mots est le résultat d'une succession de choix locaux, pas d'un plan d'ensemble.

Le token : l'unité que personne ne comprend

Premier obstacle, et il est plus important qu'il n'y paraît : le modèle ne voit pas des lettres, ni tout à fait des mots. Il voit des tokens.

Ce qu'est un token

Un token est un fragment de texte, généralement entre un caractère et un mot entier. Le découpage est appris statistiquement : les séquences fréquentes deviennent un seul token, les rares sont fragmentées.

En français, un mot courant comme « maison » constitue probablement un seul token. Un mot rare, technique ou très long — « anticonstitutionnellement » — sera découpé en plusieurs fragments. Un nom propre inhabituel le sera aussi. Les espaces et la ponctuation comptent également.

Cette étape a lieu avant tout traitement intelligent. Votre texte est converti en une suite de nombres entiers, chacun désignant un token dans un vocabulaire fixe. Le modèle ne manipule jamais autre chose que ces nombres.

La taxe linguistique

Voici un fait rarement mentionné en français, et qui devrait l'être davantage.

Les tokenizers sont majoritairement optimisés sur des corpus anglophones. Résultat : le même contenu, traduit, ne produit pas le même nombre de tokens selon la langue.

Une recherche présentée à NeurIPS 2023 par Petrov et ses coauteurs a quantifié le phénomène. Pour un texte identique traduit dans différentes langues, les longueurs de tokenisation varient jusqu'à un facteur 15 dans les cas extrêmes. Même les approches par caractère ou par octet, censées être neutres, présentent des écarts dépassant un facteur 4 entre certaines paires de langues.

Les auteurs décrivent trois conséquences concrètes pour les locuteurs des langues défavorisées :

1. Un coût supérieur. Les API se facturent au token. Plus de tokens pour le même sens, c'est une facture plus élevée pour un travail identique.
2. Une latence supérieure. Plus de tokens à traiter, c'est plus de temps de calcul.
3. Une fenêtre de contexte effectivement réduite. À capacité annoncée égale, vous logez moins de contenu réel.

Le français n'est pas parmi les langues les plus pénalisées — les écarts les plus violents concernent des langues à alphabet non latin ou à morphologie très différente. Mais il est structurellement désavantagé par rapport à l'anglais : accents, élisions, terminaisons de conjugaison, articles contractés produisent des fragments que le vocabulaire anglocentré gère mal.

Pratiquement : si vous dimensionnez un budget d'API sur des tests en anglais, ajoutez une marge pour la production en français. Et si vous comparez deux fournisseurs sur le prix affiché, mesurez d'abord combien de tokens votre corpus produit chez chacun — le classement change parfois.

Pourquoi le modèle ne sait pas compter les lettres

Vous avez peut-être vu un modèle se tromper en comptant les occurrences d'une lettre dans un mot, ou en épelant à l'envers. Ce n'est pas un défaut d'intelligence. C'est une conséquence directe de la tokenisation.

Le modèle ne voit pas « f-r-a-m-b-o-i-s-e ». Il voit un ou deux identifiants numériques. Lui demander de compter les lettres revient à demander à quelqu'un qui lit des idéogrammes de compter les traits sans jamais regarder le dessin — l'information a été détruite en amont, à l'étape de découpage.

Le même mécanisme explique une partie des erreurs d'arithmétique. Un nombre long est découpé en fragments arbitraires, qui ne correspondent pas aux unités, dizaines et centaines. Le modèle manipule des morceaux de chiffres, pas des quantités.

C'est pourquoi la bonne pratique, pour tout calcul qui compte, est de faire exécuter du code au modèle plutôt que de lui demander le résultat de tête. Le calcul devient exact parce qu'il quitte le réseau de neurones.

Comment la machine « comprend » les mots

Une fois le texte découpé en tokens, chacun est converti en un vecteur : une longue liste de nombres, typiquement plusieurs milliers.

Le sens devient de la géométrie

L'idée fondatrice, antérieure aux LLM, est que le sens d'un mot peut s'approcher par sa position dans un espace à très grand nombre de dimensions. Les mots de sens proches occupent des positions proches.

L'exemple canonique, découvert dès les années 2010 : dans un tel espace, l'opération roi − homme + femme aboutit à un point très proche de reine. La différence entre « roi » et « homme » encode quelque chose comme la royauté, qui appliquée à « femme » produit « reine ». Ce n'est pas un tour de magie, c'est une régularité statistique du langage capturée par la géométrie.

Ces vecteurs ne sont pas écrits à la main. Ils sont appris pendant l'entraînement, en ajustant les nombres de manière à améliorer la prédiction du mot suivant. Le « sens » émerge comme un sous-produit de cette tâche.

Le problème de l'ambiguïté

Un vecteur fixe par mot pose un problème évident. « Avocat » désigne un fruit ou un juriste. « Vol » relève de l'aviation ou du code pénal. Un point unique dans l'espace ne peut pas représenter les deux.

C'est précisément ce que résout l'architecture des LLM modernes : les vecteurs y sont contextuels. La représentation d'« avocat » n'est pas la même dans « un avocat bien mûr » et dans « mon avocat plaidera ». Chaque token est réécrit en fonction de son entourage.

Le mécanisme qui effectue cette réécriture s'appelle l'attention.

Le Transformer et le mécanisme d'attention

En 2017, une équipe de chercheurs publie Attention Is All You Need, un article qui introduit l'architecture Transformer. C'est le socle de tous les grands modèles de langage actuels, sans exception.

Ce que fait l'attention, concrètement

Prenez la phrase : « Le chat a poursuivi la souris parce qu'elle était rapide. »

À quoi renvoie « elle » ? À la souris. Un lecteur humain le résout sans y penser. Pour une machine, c'est un problème redoutable : il faut relier un pronom à un mot situé plusieurs positions en arrière, et choisir entre deux candidats grammaticalement acceptables.

L'attention résout cela ainsi : pour chaque token, le modèle calcule un score de pertinence envers tous les autres tokens de la séquence. En traitant « elle », il attribue un poids élevé à « souris », faible à « chat », quasi nul à « parce ». La représentation d'« elle » est alors reconstruite comme un mélange pondéré des autres, ce qui y incorpore l'information « souris ».

Répétez cette opération sur des dizaines de couches successives, avec plusieurs mécanismes d'attention en parallèle par couche — chacun se spécialisant sur un type de relation, syntaxique, sémantique, référentielle — et vous obtenez une compréhension contextuelle d'une finesse remarquable.

Pourquoi cette architecture a tout balayé

Les modèles antérieurs traitaient le texte séquentiellement, mot après mot, en propageant un état de mémoire. Deux défauts rédhibitoires : l'information se dégradait sur les longues distances, et le traitement séquentiel interdisait la parallélisation.

Le Transformer traite tous les tokens simultanément. Chacun peut regarder directement n'importe quel autre, sans traverser une chaîne. C'est ce qui a rendu possible l'entraînement sur des milliers de processeurs en parallèle — et donc l'échelle actuelle. Sans cette propriété, les modèles d'aujourd'hui seraient économiquement impossibles à entraîner.

La facture : un coût quadratique

Cette puissance a un prix, et il explique beaucoup de choses sur les tarifs que vous payez.

Si chaque token doit calculer un score envers tous les autres, alors doubler la longueur du texte quadruple le nombre de calculs. C'est la fameuse complexité quadratique de l'attention.

Voilà pourquoi les fenêtres de contexte ont mis des années à s'étendre, pourquoi les longs contextes coûtent cher, et pourquoi certains fournisseurs appliquent un tarif majoré au-delà d'un certain seuil. De nombreuses optimisations atténuent aujourd'hui ce coût, mais le principe demeure : le contexte long n'est jamais gratuit.

Comment le mot suivant est choisi : le hasard contrôlé

Nous avons dit que le modèle calcule une probabilité pour chaque token possible. Reste une question dont dépend beaucoup de son comportement : une fois cette distribution obtenue, lequel choisit-il ?

Toujours le plus probable ? Mauvaise idée

La réponse intuitive serait : le plus probable. C'est possible, et le résultat est décevant.

Un texte composé systématiquement du mot le plus probable devient plat, répétitif, et tombe fréquemment dans des boucles — le modèle se met à tourner sur la même formule parce qu'elle est, localement, toujours l'option la plus vraisemblable. La langue naturelle n'est pas la suite des mots les plus attendus ; un texte humain contient en permanence de petites surprises.

Le tirage au sort pondéré

Ce qui se fait en pratique : le modèle tire au sort parmi les tokens candidats, en respectant leurs probabilités. Un token à 60 % sort six fois sur dix ; un token à 5 % sort une fois sur vingt.

C'est ici que naît la variabilité qui déroute tant d'utilisateurs. Deux fois la même question, deux réponses différentes : ce n'est pas de l'humeur, c'est un tirage.

La température

Le paramètre qui règle ce tirage porte le nom de température, emprunté à la physique statistique.

Une température basse écrase la distribution : les écarts se creusent, le token favori devient écrasant, la sortie devient quasi déterministe et très conventionnelle. On la privilégie pour l'extraction de données, la classification, le code.

Une température élevée aplatit la distribution : les options improbables gagnent leur chance, le texte devient plus varié — et plus susceptible de partir en vrille. On la réserve à la création.

Une nuance qui compte : température zéro ne garantit pas une reproductibilité parfaite. Selon l'infrastructure, l'ordre des calculs en virgule flottante peut varier légèrement d'une exécution à l'autre et suffire à basculer un choix serré. Si votre application exige une sortie strictement identique, mettez-la en cache — ne comptez pas sur le modèle.

Notez enfin que sur plusieurs modèles récents, notamment ceux qui raisonnent, ce réglage n'est plus exposé du tout : l'éditeur le fixe lui-même. C'est une tendance de fond, et la section suivante explique pourquoi.

L'entraînement, en trois temps

Un modèle utilisable est le produit de trois phases distinctes, souvent confondues.

1. Le pré-entraînement

Le modèle lit une fraction gigantesque du texte disponible — pages web, livres, code, articles — et s'entraîne à une seule tâche : prédire le mot suivant. Des milliards de fois.

C'est la phase la plus coûteuse : des milliers de processeurs spécialisés pendant des semaines ou des mois, pour un budget qui se compte en dizaines ou centaines de millions d'euros pour un modèle de premier plan.

À l'issue de cette phase, le modèle possède une connaissance encyclopédique et une maîtrise linguistique impressionnante. Mais il est inutilisable : il complète du texte. Posez-lui une question, il est aussi susceptible de générer dix questions similaires que d'y répondre — parce que sur le web, une question est souvent suivie d'autres questions.

2. L'ajustement supervisé

On lui montre alors des dizaines de milliers d'exemples de la forme instruction → bonne réponse, rédigés par des humains.

Le modèle apprend un format de comportement : quand on te pose une question, réponds. Quand on te demande un résumé, résume. C'est ici que naît l'assistant, à partir du complèteur de texte.

3. L'alignement par retour humain

Dernière phase, la plus subtile. Des évaluateurs humains comparent plusieurs réponses du modèle à une même question et indiquent laquelle est préférable. Ces préférences servent à entraîner un second modèle qui prédit le jugement humain, lequel sert à son tour à affiner le premier.

Cette technique — connue sous le nom de RLHF, apprentissage par renforcement à partir de retours humains — a été popularisée par les travaux d'Ouyang et ses coauteurs en 2022, et c'est elle qui a transformé une curiosité de laboratoire en produit grand public.

C'est aussi elle qui façonne ce qu'on perçoit comme la « personnalité » d'un modèle : son ton, sa prudence, sa propension à nuancer ou à refuser. Deux modèles de capacité brute comparable peuvent sembler très différents parce qu'ils ont été alignés selon des préférences différentes. Quand vous trouvez qu'un modèle « écrit mieux » qu'un autre, vous jugez très souvent cette phase-là, pas la puissance sous-jacente.

La taille ne fait pas tout : la leçon de Chinchilla

Une idée reçue tenace veut que la performance dépende essentiellement du nombre de paramètres. C'est faux, et la démonstration est célèbre.

En 2022, Hoffmann et ses coauteurs, chez DeepMind, ont réexaminé la relation entre taille du modèle, quantité de données et puissance de calcul. Leur conclusion : la plupart des grands modèles de l'époque étaient massivement sous-entraînés. On avait mis trop de paramètres et pas assez de texte.

La démonstration expérimentale est spectaculaire. Ils ont entraîné un modèle de 70 milliards de paramètres sur 1 400 milliards de tokens, à budget de calcul identique à celui d'un modèle de 280 milliards de paramètres entraîné sur environ 300 milliards de tokens.

Le modèle quatre fois plus petit a battu le plus gros sur un large éventail d'évaluations.

L'article établissait un ratio approximatif d'environ 20 tokens d'entraînement par paramètre pour un usage optimal du calcul. Ce chiffre a depuis été discuté et affiné, mais le principe reste acquis : un nombre de paramètres n'est pas une mesure de capacité.

C'est une raison suffisante pour se méfier des comparaisons fondées sur ce seul critère — et pour ne pas conclure qu'un modèle annoncé comme plus petit est nécessairement plus faible.

Les modèles de raisonnement : une quatrième étape

Depuis 2024, une nouvelle catégorie s'est imposée, et vous la croiserez partout : les modèles de raisonnement.

L'idée

Revenons au principe de base : le modèle produit un token après l'autre, sans plan. Sur une question difficile — un problème de logique, un calcul en plusieurs étapes, un bug subtil — cette contrainte est sévère. Le modèle doit produire la bonne réponse immédiatement, sans espace pour réfléchir.

L'intuition qui a tout changé : et si on lui laissait cet espace ?

On a d'abord constaté qu'il suffisait de le demander. Ajouter « réfléchissons étape par étape » à une question améliorait spectaculairement les résultats sur les problèmes de raisonnement. Le modèle produisait alors des étapes intermédiaires, et chaque étape servait de contexte à la suivante. Il se construisait un brouillon à mesure.

Les modèles de raisonnement industrialisent ce principe. Ils sont entraînés à produire une longue chaîne de réflexion interne avant de formuler leur réponse. Ce brouillon ne vous est généralement pas montré, ou seulement sous forme résumée.

Ce que ça change concrètement

Ils sont bien meilleurs sur les tâches difficiles : mathématiques, logique, code complexe, planification en plusieurs étapes.

Ils sont plus lents. La réflexion prend du temps. Sur une question ardue, plusieurs dizaines de secondes peuvent s'écouler avant le premier mot visible.

Ils coûtent plus cher que ne le suggère leur réponse. Point capital, et invisible : cette réflexion interne est facturée comme du texte produit. Vous lisez une réponse de dix lignes et vous croyez payer dix lignes ; vous avez peut-être payé plusieurs pages de raisonnement que vous n'avez jamais vues.

Le conseil classique s'est retourné contre eux. C'est le renversement le plus utile à connaître : dire « réfléchis étape par étape » à un modèle de raisonnement, c'est lui demander de faire ce qu'il fait déjà. Des mesures indépendantes montrent un gain nul, parfois même une légère dégradation, pour un temps de réponse sensiblement allongé.

La règle pratique tient donc en une phrase : demandez le raisonnement explicite aux modèles classiques, donnez seulement l'objectif final aux modèles de raisonnement.

Quand les utiliser

Pas systématiquement. Sur une reformulation, une classification, une extraction de données ou une réponse de support courante, un modèle rapide fait le même travail pour une fraction du prix et du délai.

Réservez le raisonnement aux tâches où la réponse n'est pas immédiate pour un humain compétent. C'est un bon critère de tri : si vous auriez répondu sans réfléchir, le modèle n'a pas besoin de réfléchir non plus.

Les capacités « émergentes » : attention au mirage

Vous avez probablement lu qu'au-delà d'une certaine taille, les modèles acquièrent brusquement des capacités qu'ils n'avaient pas — arithmétique à plusieurs chiffres, raisonnement en plusieurs étapes. Les courbes montrent un palier, puis un saut. On parle de capacités émergentes, avec une pointe de mystère.

Cette lecture a été sérieusement contestée, et il faut le savoir.

En 2023, Schaeffer, Miranda et Koyejo publient Are Emergent Abilities of Large Language Models a Mirage? — un article qui a reçu un prix du meilleur article à NeurIPS 2023. Leur thèse : dans de nombreux cas, l'émergence est un artefact de la métrique choisie par le chercheur, pas un changement de nature du modèle.

Le raisonnement est simple une fois énoncé. Si vous évaluez une addition à plusieurs chiffres en « tout juste ou tout faux », un modèle qui passe de 20 % à 80 % de chiffres corrects reste à zéro sur votre métrique, puis bascule brutalement à un score élevé. Votre courbe montre un saut. Le modèle, lui, s'est amélioré progressivement — c'est votre instrument de mesure qui est discontinu.

Les auteurs vont plus loin : ils montrent qu'en choisissant délibérément la métrique, on peut fabriquer des émergences apparentes là où il n'y en a pas, y compris sur des tâches de vision.

Que faut-il en retenir ? Que les progrès des modèles sont plus continus et plus prévisibles que les annonces ne le suggèrent, et qu'une courbe spectaculaire doit toujours amener à demander : mesurée comment ?

Pourquoi les LLM hallucinent — la vraie raison

C'est le comportement le plus déroutant, et l'explication courante est incomplète.

L'explication habituelle, et sa limite

On dit généralement : le modèle est probabiliste, il génère ce qui est plausible plutôt que ce qui est vrai, donc il invente.

C'est exact mais insuffisant. Cela n'explique pas pourquoi il invente avec assurance plutôt que d'exprimer un doute, alors qu'il dispose en interne d'une information sur sa propre incertitude.

L'explication par les incitations

En 2025, une équipe menée par Kalai, avec Nachum, Vempala et Zhang, publie Why Language Models Hallucinate. Leur analyse déplace le problème du terrain technique vers celui des incitations, et elle est éclairante.

L'argument : les hallucinations persistent parce que la manière dont on évalue les modèles récompense la devinette plutôt que l'aveu d'ignorance.

Imaginez un examen à choix multiples sans points négatifs. Répondre au hasard sur une question dont vous ignorez la réponse ne coûte rien et peut rapporter. Laisser la case vide rapporte zéro à coup sûr. Tout candidat rationnel devine.

Les modèles sont dans cette situation en permanence. Ils sont optimisés pour bien figurer sur des évaluations qui comptent les bonnes réponses. Un modèle qui répond « je ne sais pas » obtient zéro sur cette question — exactement le même score qu'une réponse fausse. Il n'existe aucune incitation à s'abstenir, et une forte incitation à tenter sa chance.

Autrement dit : nous avons entraîné ces systèmes à bluffer, puis nous nous étonnons qu'ils bluffent.

Les auteurs formalisent également un résultat important : ils contestent l'idée que les hallucinations seraient une fatalité mathématique. Un modèle peut s'abstenir quand il est incertain. Ce n'est pas une limite théorique, c'est un choix de conception — et le remède passe autant par une évolution de la culture d'évaluation que par des correctifs techniques.

Ce que vous pouvez en faire

Cette lecture a des conséquences pratiques immédiates.

Autorisez explicitement l'ignorance. Une consigne comme « si tu n'es pas sûr, dis-le plutôt que de proposer une réponse plausible » a un effet réel, parce qu'elle modifie localement l'incitation.

Interdisez l'invention là où elle est dangereuse. « N'invente aucun chiffre, aucune date, aucune référence. Si l'information n'est pas dans le document fourni, indique-le. » C'est probablement la consigne la plus rentable en contexte professionnel.

Fournissez la source plutôt que d'interroger la mémoire. Un modèle qui a le document sous les yeux invente beaucoup moins qu'un modèle qui puise dans ses paramètres. C'est le principe du RAG, dont nous parlons plus bas.

Vérifiez systématiquement ce qui est vérifiable. Les références bibliographiques, les citations, les chiffres, les URL et les articles de loi sont les catégories les plus à risque — précisément parce que leur forme est très prévisible alors que leur contenu ne l'est pas. Un modèle produit sans effort une référence parfaitement formatée qui n'existe pas.

La fenêtre de contexte : une mémoire de travail, pas une mémoire

La fenêtre de contexte est la quantité de texte que le modèle peut prendre en compte pour produire sa réponse : votre question, les consignes système, l'historique de la conversation, les documents fournis.

Aucune mémoire entre les conversations

Voici le point le plus mal compris. Un modèle n'apprend rien de vos échanges. Ses paramètres sont figés après l'entraînement. Rien de ce que vous lui dites n'y est inscrit.

Comment expliquer alors qu'il « se souvienne » du début d'une conversation ? Parce qu'à chaque message, l'intégralité de l'historique lui est renvoyée. Il ne se souvient pas : il relit tout, à chaque fois.

Les fonctions de mémoire des assistants grand public ne dérogent pas à cette règle. Elles stockent des notes dans une base de données extérieure et les réinjectent dans le contexte au moment opportun. C'est un carnet, pas un souvenir.

Cela explique aussi le coût : dans une longue conversation, vous repayez l'intégralité de l'historique à chaque échange. Une discussion de deux heures devient significativement plus chère par message que son premier échange.

Le milieu du contexte est un angle mort

Les fenêtres actuelles atteignent le million de tokens. Impressionnant — mais un million de tokens disponibles n'est pas un million de tokens bien exploités.

Les travaux de Liu et ses coauteurs sur le phénomène dit lost in the middle ont établi que la performance suit une courbe en U selon la position de l'information utile : bonne en début de contexte, bonne en fin, dégradée au milieu. Et le constat vaut y compris pour des modèles conçus spécifiquement pour les longs contextes.

En pratique : placez l'essentiel au début et rappelez la contrainte critique à la fin. Et ne considérez pas la grande fenêtre comme une dispense de tri — vingt documents pertinents valent mieux que deux cents en vrac.

Ce qu'un LLM ne peut pas faire

Une liste honnête vaut mieux qu'un discours sur les limites.

Connaître l'actualité. Ses connaissances s'arrêtent à sa date de coupure d'entraînement. Sans outil de recherche, il ignore tout de ce qui a suivi — et peut ignorer qu'il l'ignore.

Calculer de façon fiable. Pour les raisons de tokenisation exposées plus haut. Faites-lui écrire et exécuter du code.

Manipuler les lettres d'un mot. Compter, épeler à l'envers, jouer avec les anagrammes : l'information n'existe pas à son niveau de représentation.

Être déterministe. La génération comporte une part d'aléatoire. La même question peut produire deux réponses différentes. Si vous avez besoin de reproductibilité stricte, il faut la construire autour du modèle, pas l'attendre de lui.

S'introspecter. Quand vous lui demandez pourquoi il a répondu ceci, il ne consulte pas sa trace de calcul — il produit une explication plausible. Ce n'est pas nécessairement la vraie cause. Les justifications d'un modèle sur son propre fonctionnement sont à traiter comme du texte généré, pas comme un rapport de diagnostic.

Apprendre de vos corrections. Vous le corrigez, il s'ajuste — dans cette conversation seulement, parce que la correction est désormais dans le contexte. La conversation suivante repart de zéro.

Garantir la confidentialité par lui-même. Ce que vous envoyez transite chez un fournisseur. C'est un sujet contractuel et architectural, pas un sujet de modèle.

Comment on fait mieux : les quatre leviers

Face à ces limites, il existe quatre approches. Elles ne sont pas interchangeables, et on les confond souvent.

Le prompt

Le levier le moins cher, et le plus sous-exploité. Structurer la requête — rôle, contexte, objectif, format, contraintes — améliore les résultats dans des proportions que la plupart des utilisateurs n'imaginent pas. Coût : zéro. Toujours commencer par là.

Le RAG

Retrieval-Augmented Generation : avant de répondre, on va chercher les documents pertinents dans une base et on les injecte dans le contexte.

C'est la réponse à deux problèmes d'un coup : le modèle accède à des informations postérieures à son entraînement ou propres à votre organisation, et il hallucine beaucoup moins puisqu'il travaille sur un texte fourni plutôt que sur sa mémoire.

C'est l'approche à privilégier pour toute application reposant sur une base documentaire — support client, base de connaissances interne, documentation technique, corpus juridique.

Les outils

On donne au modèle la possibilité d'appeler des fonctions : rechercher sur le web, exécuter du code, interroger une base, envoyer un message.

Le modèle cesse d'être un générateur de texte pour devenir un orchestrateur. C'est ce qui fonde les « agents ». Et c'est la bonne réponse à toutes ses faiblesses structurelles : il ne sait pas calculer, alors il exécute du code ; il ignore l'actualité, alors il cherche.

Le fine-tuning

On poursuit l'entraînement du modèle sur vos données propres.

C'est le levier le plus lourd, et le plus souvent choisi à tort. Il excelle pour faire adopter un format ou un style très spécifique. Il est mal adapté pour injecter des connaissances — le RAG fait cela mieux, moins cher, et se met à jour instantanément.

Règle empirique : si votre problème est « le modèle ne connaît pas nos informations », c'est du RAG. Si c'est « le modèle ne répond pas dans notre format », c'est du prompt, et du fine-tuning seulement si le prompt n'a pas suffi.

Modèles fermés, modèles à poids ouverts

Dernière distinction structurante.

Un modèle fermé est accessible uniquement via l'API de son éditeur. Vous ne voyez pas les poids, vous ne pouvez pas l'héberger. Vous louez un service.

Un modèle à poids ouverts publie les paramètres entraînés. Vous les téléchargez, vous les faites tourner sur votre infrastructure, vous les modifiez.

La différence n'est pas idéologique, elle est contractuelle et opérationnelle. Avec un modèle ouvert, vos données ne quittent jamais votre infrastructure, le fournisseur ne peut pas augmenter ses prix ni retirer le modèle du marché, et vous conservez l'usage si l'éditeur disparaît. En contrepartie, vous assumez l'exploitation : matériel, compétences, disponibilité.

Une précision importante sur le vocabulaire : « poids ouverts » n'est pas « open source ». Les poids sont publiés, mais les données d'entraînement et la recette complète ne le sont généralement pas. Et les licences varient énormément — certaines sont réellement permissives, d'autres imposent des restrictions d'usage commercial. Lisez-les avant de bâtir dessus.

Ce que ça change pour vous

Sept conséquences pratiques de tout ce qui précède.

Le contexte est votre principal levier. Le modèle ne sait de votre situation que ce que vous lui dites. La plupart des réponses décevantes viennent d'un contexte absent, pas d'une incapacité du modèle.

Ne lui faites pas confiance sur les faits vérifiables. Références, chiffres, dates, citations : vérifiez. Ce sont les catégories où la forme est prévisible et le contenu ne l'est pas.

Sortez le calcul du modèle. Tout ce qui doit être exact doit passer par du code ou un outil.

Nommez le format que vous attendez. Le modèle ne devine pas votre gabarit. Une contrainte de format explicite supprime la moitié des allers-retours.

Une nouvelle conversation efface tout. Ce qui doit persister doit être réinjecté ou stocké à l'extérieur.

Comptez vos tokens en français. La facture et la fenêtre de contexte ne se comportent pas comme sur des tests anglophones.

Testez sur vos propres cas. Les classements publics ne prédisent pas la performance sur votre tâche, avec vos données, dans votre langue.

Sept idées fausses à abandonner

« Il comprend ce qu'il écrit. » Il modélise des régularités statistiques du langage à une profondeur qui produit des comportements indiscernables de la compréhension sur de nombreuses tâches. Que cela constitue ou non une compréhension est un débat philosophique ouvert et légitime — mais opérationnellement, ne présumez ni d'une compréhension véritable, ni d'une simple récitation.

« Il recopie des phrases apprises. » Non. Il génère des séquences qui n'existent nulle part dans ses données. C'est bien de la production, pas de la restitution.

« Il apprend de nos conversations. » Ses paramètres sont figés. Vos échanges peuvent servir à entraîner une future version, selon les conditions du fournisseur — ce qui est un vrai sujet de confidentialité — mais le modèle que vous utilisez, lui, n'apprend rien.

« Plus de paramètres, plus de performance. » Chinchilla a réglé la question : un modèle quatre fois plus petit, mieux entraîné, en a battu un plus gros.

« Il est connecté à internet. » Seulement s'il dispose d'un outil de recherche. Par défaut, il travaille de mémoire.

« Ses hallucinations sont des bugs. » Ce sont des conséquences prévisibles de son mode de fonctionnement et de ses incitations d'entraînement, pas des défauts accidentels qu'un correctif ferait disparaître.

« Il donne toujours la même réponse. » La génération est stochastique. La variabilité est native.

Pour finir

Un modèle de langage n'est ni un cerveau ni un perroquet. C'est un système statistique d'une sophistication considérable, entraîné à prédire la suite d'un texte, et dont les propriétés remarquables comme les limites découlent toutes de ce mécanisme unique.

Comprendre cela ne relève pas de la curiosité intellectuelle : c'est ce qui sépare l'utilisateur qui se plaint que « l'IA raconte n'importe quoi » de celui qui sait fournir le bon contexte, contraindre le format, sortir le calcul du modèle, et vérifier ce qui doit l'être.

L'écart de résultats entre ces deux personnes, avec exactement le même outil, est considérable. Il ne tient pas au modèle. Il tient à ce qu'elles en savent.

---

Sources

• Vaswani et al., Attention Is All You Need, NeurIPS 2017 — arxiv.org/abs/1706.03762
• Hoffmann et al., Training Compute-Optimal Large Language Models (Chinchilla), 2022 — arxiv.org/abs/2203.15556
• Ouyang et al., Training language models to follow instructions with human feedback (InstructGPT / RLHF), 2022 — arxiv.org/abs/2203.02155
• Schaeffer, Miranda & Koyejo, Are Emergent Abilities of Large Language Models a Mirage?, NeurIPS 2023 (prix du meilleur article) — arxiv.org/abs/2304.15004
• Petrov et al., Language Model Tokenizers Introduce Unfairness Between Languages, NeurIPS 2023 — arxiv.org/abs/2305.15425
• Liu et al., Lost in the Middle: How Language Models Use Long Contexts, TACL 2023 — arxiv.org/abs/2307.03172
• Kalai, Nachum, Vempala & Zhang, Why Language Models Hallucinate, 2025 — arxiv.org/abs/2509.04664