Pourquoi un LLM écrit du code plausible, pas du code garanti
Ce que la littérature scientifique mesure vraiment quand un modèle de langage écrit du code : une probabilité de réussite sur un échantillon, jamais une garantie sur la sortie livrée. Article 1 de la série « La recherche sur le déterminisme ».
Un modèle de langage optimise la vraisemblance, pas la correction
Un modèle de langage produit du code token par token, en choisissant à chaque pas la suite la plus probable au vu de son entraînement. Cette mécanique explique sa force — le code produit ressemble à du code que des humains ont écrit — et sa limite structurelle : rien, dans l'objectif d'entraînement, n'exige que le programme soit correct. La correction est une propriété espérée du résultat, pas une contrainte du procédé.
La conséquence se lit dans la métrique que le champ s'est donnée : pass@k, la probabilité qu'au moins UNE solution parmi k tentatives passe les tests. C'est une métrique d'échantillon — elle dit combien de fois il faut tirer pour obtenir un programme qui marche, pas si LE programme qu'on vous a livré marche.
Les chiffres fondateurs : une réussite statistique, pas une garantie
L'article fondateur du domaine — celui qui a introduit Codex (le moteur initial de GitHub Copilot) et le banc d'essai HumanEval — donne l'ordre de grandeur : le modèle résout 28,8 % des problèmes du premier coup, et 70,2 % si on l'autorise à produire 100 candidats par problème et à garder le bon. L'écart entre ces deux chiffres EST le sujet : la qualité vient du tirage répété plus que de la fiabilité de chaque sortie.
Or un produit qui génère une application ne livre pas 100 candidats : il en livre un. Tout ce qui sépare 28,8 % de 100 % doit alors être comblé par autre chose que le modèle — des tests, des validateurs, ou une architecture qui retire au modèle ce qu'il ne sait pas garantir.
- Chen et al., Evaluating Large Language Models Trained on Code (2021) : arxiv.org/abs/2107.03374
L'hallucination n'est pas anecdotique : le cas mesuré des dépendances
L'exemple le plus proprement quantifié d'invention plausible est celui des paquets logiciels. Une étude à grande échelle a fait générer 576 000 échantillons de code Python et JavaScript par 16 modèles : en moyenne, environ un cinquième des paquets recommandés n'existaient pas, soit plus de 200 000 noms de paquets inventés — des noms crédibles, bien formés, et pourtant sans existence.
Le phénomène a même engendré une classe d'attaque documentée, le « slopsquatting » : enregistrer un paquet malveillant sous un nom fréquemment halluciné, en pariant qu'un développeur assisté par IA l'installera sans vérifier. L'hallucination de code n'est donc pas seulement un problème de qualité — c'est un vecteur de sécurité.
- Spracklen et al., We Have a Package for You! A Comprehensive Analysis of Package Hallucinations by Code Generating LLMs (Univ. of Texas at San Antonio, Virginia Tech, Univ. of Oklahoma) — 16 modèles, 576 000 échantillons, ≈ 20 % de paquets inexistants
Et le même prompt ne donne pas deux fois le même code
À la variabilité de qualité s'ajoute la variabilité tout court : l'étude de référence sur le non-déterminisme (ACM TOSEM, 829 problèmes, cinq générations chacun) documente une dispersion significative du code produit pour un prompt identique — et des travaux plus récents montrent que des sources numériques de hasard subsistent même à température nulle. Le détail et les références sont sur la page d'entrée de cette série.
Ce que Blueprint Maker en tire
La réponse d'architecture est de ne jamais mettre le modèle en position d'inventer ce qui doit être garanti. Chez Blueprint Maker, le LLM ne rédige pas le code livré : il conçoit un schéma métier (l'AppSpec), et un moteur déterministe écrit le code. Les propriétés des composants sont posées par le moteur selon des règles fixes — jamais devinées. Les dépendances de l'application générée viennent d'un gabarit figé et testé : un paquet halluciné est impossible par construction, puisque le modèle ne choisit pas les paquets.
Là où le tirage statistique subsiste — la conception du schéma — il est encadré par des validateurs et des portes de correction, puis la sortie complète est prouvée en conditions réelles avant livraison. Ces deux étages font l'objet des deux articles suivants de la série.