FONDAMENTAUX · GUIDE 01 · LECTURE ~8 MIN · WILLIAM LEEMANS
Ce qu'est un LLM
Vous n’avez pas besoin de comprendre un transformer pour travailler avec un agent. Ce qu’il vous faut, c’est un modèle mental juste : assez fidèle pour prédire les comportements de l’outil, assez simple pour être mobilisé en pleine session de travail.
C’est le modèle mental que je vous propose ici.
Une machine à continuer du texte
Un LLM fait une seule chose : étant donné une séquence de tokens, produire une distribution de probabilité sur le token suivant. Le modèle « écrit » en répétant cette opération, un token à la fois, chaque token produit devenant une partie de l’entrée du suivant.
Tout le reste, du simple chat aux agents, est de l’ingénierie construite autour de cette boucle. Quand un agent « décide » d’appeler un outil, il continue du texte dont le format ressemble à un appel d’outil. Quand il « s’excuse » d’une erreur, il continue du texte qui ressemble à ce qui suit habituellement une erreur dans ses données d’entraînement.
Ne me croyez pas sur parole : regardez la machine le faire. Voici deux traces réelles d’un vrai modèle. À chaque étape, vous voyez les cinq tokens candidats les plus probables et leur probabilité réelle ; la machine prend le plus probable. Déroulez les deux.
La trace A, c’est le cas idéal : fibonacci apparaît des centaines de
milliers de fois dans le corpus, donc la continuation probable est la bonne, 26
fois de suite. La trace B, c’est la même machine, le même aplomb, qui enchaîne
droit sur .dict(), l’API Pydantic v1, supprimée en v2, dans un prompt qui
dit explicitement v2. La bonne continuation (.model_dump()) était là, dans le
top-5, à cinq contre un. Rien dans la fluidité de la sortie ne distingue les
deux traces.
Ce modèle mental explique tout de suite deux comportements qui déroutent :
- La sortie est plausible avant d’être vraie. Le modèle optimise la vraisemblance de la continuation, pas sa véracité. Quand les deux coïncident (souvent), tout va bien. Quand elles divergent, vous obtenez une hallucination parfaitement formulée.
- La sortie est sensible à la formulation de l’entrée. Changez le ton, le format ou l’ordre de votre demande, et vous changez la continuation la plus probable. C’est la définition même de l’opération, pas un bug.
Entraînement et inférence : deux moments qui ne communiquent pas
L’entraînement, c’est le moment où les poids du modèle sont ajustés sur des téraoctets de texte et de code. Il a eu lieu une fois, chez le fournisseur du modèle, et il est terminé. L’inférence, c’est ce qui se passe quand vous utilisez le modèle : les poids sont figés, rien n’est appris, rien n’est retenu.
Les conséquences pratiques :
- Le modèle a une date de coupure (son « cutoff »). Il ne connaît ni la dernière version de votre framework, ni la bibliothèque sortie le mois dernier. Tout ce qui est plus récent doit lui être fourni dans le contexte.
- Le modèle n’apprend pas de vos sessions. Corriger trois fois la même erreur ne « l’éduque » pas : à la session suivante, tout recommence à zéro. La seule mémoire qui existe est celle que votre outillage reconstruit dans le contexte (fichiers d’instructions, historique, mémoire applicative).
- Le modèle ne sait rien de votre projet. Il n’a jamais vu votre repo, vos conventions, votre dette. Tout ce qu’il en sait au moment de répondre tient dans sa fenêtre de contexte. Et cette fenêtre, c’est la seule réalité du modèle.
Le tips Craftomancer
« Le modèle connaît ce framework » est toujours une approximation. Il a vu des milliers d’exemples d’un framework à des versions mélangées. Le code qu’il produit est un amalgame statistique de ces versions. C’est de là que viennent les API inventées qui ressemblent à deux versions à la fois. Fournissez la version et la documentation pertinente dans le contexte au lieu de présumer.
Ce que « savoir » veut dire pour un modèle
Un LLM ne stocke pas des faits dans une base qu’il consulterait. Ses poids compressent des régularités statistiques extraites du corpus d’entraînement. Quand la régularité est massive et cohérente (la syntaxe d’un langage, les idiomes d’une stdlib), cette compression est si fiable qu’on ne la distingue pas d’un savoir exact. Quand la régularité est rare, contradictoire ou récente, le modèle interpole : il produit ce qui ressemblerait à la bonne réponse.
C’est pour ça que la frontière entre ce que le modèle sait et ce qu’il invente ne se voit pas dans la sortie : la syntaxe est aussi assurée dans les deux cas. L’aplomb du texte ne dit rien de sa fiabilité. La bonne question n’est donc pas « est-ce que ça a l’air juste ? » mais « est-ce le genre de chose qu’un corpus public a pu voir massivement, et est-ce que je peux le vérifier mécaniquement ? »
Pourquoi ça marche si bien pour le code
Une machine à continuer du texte, ça devrait être médiocre en programmation, non ? C’est l’inverse. Trois facteurs l’expliquent :
- Le code est un langage formel et massivement redondant. Les mêmes motifs (CRUD, parsing, tests, plomberie HTTP) apparaissent des millions de fois dans le corpus. La continuation probable est très souvent la bonne.
- Le code est vérifiable mécaniquement : compilation, typage, tests. C’est l’asymétrie qui rend le développement assisté viable. La sortie du modèle n’a pas besoin d’être digne de confiance, elle a besoin d’être vérifiable à bas coût. Votre outillage de vérification devient la pièce maîtresse.
- Les modèles récents sont post-entraînés pour l’agentique : suivre des instructions, utiliser des outils, travailler en boucle d’essai-erreur. C’est ce qui transforme une machine à continuer du texte en agent capable de mener une tâche.
En pratique
- Remplacez « il sait / il ne sait pas » par « c’est massivement représenté dans un corpus public / ça ne l’est pas ». Votre intuition des hallucinations s’améliore immédiatement.
- Tout ce qui est postérieur à la date de coupure ou propre à votre projet doit être fourni dans le contexte. Sinon, ça n’existe pas.
- Ne « rééduquez » pas le modèle en le corrigeant dans le chat : capitalisez la correction dans vos fichiers d’instructions, la seule mémoire qui persiste.
- L’aplomb de la réponse n’est pas un signal de fiabilité. La vérification mécanique (types, tests, exécution) en est un.
Vérifiez votre modèle
Quatre questions pour voir si le modèle mental tient. Cliquez une réponse : le verdict s’affiche.
01 La seule opération qu’effectue un LLM, c’est…
02 Pourquoi une réponse assurée ne dit-elle rien de sa fiabilité ?
03 Vous avez corrigé trois fois la même erreur de l’agent cette semaine. À la prochaine session, il…
04 La meilleure question pour prédire le risque d’hallucination, c’est…