V4rgas - Classic Nerd et tech-voodoo practitioner
Carnets Tags Categories
V4rgas - Classic Nerd et tech-voodoo practitioner

Syntaxe vs Sémantique : le LLM comprend vraiment le code ?

Les LLMs sont des parseurs AST géniaux, mais des interpréteurs à la ramasse

  inclus dans
     1992 mots   10 minutes 
/posts/syntaxe-vs-semantique/images/banner.png

J’ai passé les six derniers mois à regarder des LLM générer du code. Du code qui compile. Du code qui passe les tests. Du code qui fait exactement ce qu’on lui demande, jusqu’au moment où il chie dans la colle.

Et là, je me suis posé la question qui fâche :

Est-ce que ces putains de modèles comprennent vraiment ce qu’ils écrivent ? Ou est-ce qu’ils sont juste très, très bons pour singer la syntaxe ?

Spoiler : c’est la deuxième option. Et c’est un problème bien plus gros que ce qu’on veut bien admettre.

Schéma conceptuel du gap syntaxe/sémantique
  • AST (Abstract Syntax Tree): représentation arborescente de la structure syntaxique du code.
  • CFG (Control Flow Graph): graphe des chemins d’exécution possibles.
  • Gap sémantique: écart entre ce que le code dit (syntaxe) et ce qu’il fait (sémantique).
  • Hallucination: quand le LLM invente des informations, des fonctions, ou du comportement qui n’existent pas.
  • Semantic Recall: capacité à retrouver la signification opérationnelle du code, pas juste son pattern lexical.

  1. PyLang — “Syntax Without Semantics: Teaching Large Language Models to Code in an Unseen Language” (2026)
    https://arxiv.org/abs/2605.15607

  2. Mader et al. — “An Empirical Study of LLM for Code Analysis: Understanding Syntax and Semantics” (2026)
    https://arxiv.org/abs/2305.12138

  3. Sobania et al. / Emprika — “An Empirical Study on Capability of Large Language Models in Understanding Code Semantics” (2024)
    https://arxiv.org/abs/2407.03611

  4. Anand et al. — “A Critical Study of What Code-LLMs (Do Not) Learn” (2024)
    https://arxiv.org/abs/2406.11930

  5. How Accurately Do Large Language Models Understand Code? — 600K debugging tasks study (2025)
    https://arxiv.org/abs/2504.04372

  6. SemTrace — “Sense and Sensitivity: Examining the Influence of Semantic Recall on Long Context Code Understanding” (ACL 2026)
    https://aclanthology.org/2026.acl-long.19

  7. CodeRabbit — “AI-generated code in production: CVE trends and security impacts” (2025-2026)
    https://coderabbit.ai/blog/ai-generated-code-vulnerabilities

  8. North et al. — “Beyond Syntax: How Do LLMs Understand Code?” (2025)
    https://doi.org/10.1109/icse-nier66352.2025.00023

En 2026, 92% des développeurs utilisent des assistants IA dans leur quotidien. 27% du nouveau code est écrit par IA sans intervention humaine significative.

Sauf que les études récentes commencent à sortir, et c’est pas ouf.

L’étude PyLang (arxiv 2605.15607, 2026) a mis au point un langage minimal appelé PyLang — absent de tous les corpus d’entraînement — et a demandé à des LLMs de résoudre des problèmes dedans en leur donnant toutes les contraintes et comportements souhaités.

Résultat : les modèles apprennent la syntaxe en quelques exemples de fine-tuning. La grammaire, les mots-clés, la structure, tout ça, nickel.

Mais le gap avec Python ? Jusqu’à 19%.

Pas un gap de syntaxe. Un gap de sémantique. Les modèles savent quel algorithme choisir (80% de bonnes décisions algorithmiques), mais ils sont incapables de le traduire en code qui marche, il leur manque entre autres des patterns d’implémentation.

C’est comme un mec qui connaît toutes les règles aux échecs mais qui déplace ses pièces au hasard en les appelant par leur bon nom.

Parlons de leurs forces, parce que c’est pas du tout ou rien.

Plusieurs études convergent (Empica, NSF 2026, Mader et al. 2026) : les LLMs sont excellents pour comprendre la syntaxe. Ils génèrent des AST valides, produisent des CFG corrects, et analysent les structures lexicales comme des parseurs pros.

C’est pas rien. C’est même impressionnant.

Quand tu donnes un problème classique à un LLM — un truc qu’il a vu 50 000 fois dans ses données d’entraînement — il va te sortir une solution qui a l’air juste. Parce qu’il a mémorisé le pattern.

Le problème ? C’est du pattern matching, pas de la compréhension.

Le résultat le plus frappant de l’étude PyLang : les modèles fine-tunés font moins de 5% d’erreurs de syntaxe. Moins de 5% !

Mais le taux d’échec sémantique ? Jusqu’à 19% de plus que sur Python.

Le modèle choisit le bon algorithme dans 80% des cas. Il sait QUOI faire. Mais il ne peut pas l’écrire dans un langage qu’il n’a pas vu en pré-training.

C’est ça, le gap de fidélité d’implémentation. Le modèle comprend les contraintes et le comportement à implémenter mais ne peut pas produire les tokens qui les réalisent.

Tu sais, comme quand tu baragouines une langue étrangère : tu sais ce que tu veux dire, mais ta bouche arrive pas à dire les mots.

On a testé les LLMs sur la compréhension de comportement dynamique : exécution de boucles, invariants, mutations d’état.

Résultat ? Catastrophe.

L’étude de Mader et al. (2026) a évalué GPT4, GPT3.5, StarCoder et CodeLlama sur 9 tâches, 2560 échantillons, 4 langages.

Verbatim : “Les LLMs sont limités dans leur capacité à approximer les comportements dynamiques du code.”

Traduction : ils savent lire le code comme une partition, mais ils entendent pas la musique.

Un des résultats les plus flippants. Une étude sur 600 000 tâches de débogage (arXiv 2504.04372, 2025) a montré que :

Si tu renommes une variable, reformates le code, ou ajoutes un commentaire — des changements qui ne modifient en RIEN le comportement du programme — la précision de débogage des LLMs chute de 78%.

78% !

C’est pas une marge d’erreur. C’est un effondrement.

Le modèle ne comprend pas le code. Il reconnaît des motifs lexicaux. Si tu changes le motif, il est perdu.

L’étude d’Anand et al. (2024) a regardé sous le capot des couches d’attention. Et là, le constat est encore plus violent :

Les LLMs encodent bien les relations entre mots-clés (if, for, while). Ils encodent bien les relations entre identifiants (noms de variables, de fonctions). Mais ils ne savent PAS encoder la relation entre un if et l’expression qu’il est censé évaluer.

En clair : ils voient qu’il y a une condition. Ils voient qu’il y a un bloc. Mais ils font pas le lien entre les deux.

C’est comme lire une phrase en comprenant chaque mot individuellement, mais pas la phrase entière.

Dernière trouvaille, et pas des moindres : le benchmark SemTrace (ACL 2026) a mesuré la capacité des LLMs à comprendre le code quand la partie pertinente est au milieu d’un long contexte.

La chute médiane de précision ? 92.73% sur SemTrace, contre 53.36% sur CRUXEval.

Les modèles frontières (GPT-4, Claude, Gemini) ont un rappel lexical quasi-parfait — ils retrouvent le code textuellement. Mais le rappel sémantique — comprendre ce que le code fait réellement — se dégrade de façon catastrophique quand le code pertinent est au milieu du contexte.

Tu vois le problème ? Si t’as une codebase de 10 000 lignes et que le bug est planqué dans un bloc au milieu, le LLM va te sortir des conneries avec une confiance absolue.

Et alors, on fait quoi ?

C’est pas pour autant qu’il faut tout jeter. Les LLMs sont des outils incroyables. Mais faut connaître leurs limites.

Martin Fowler (2026) propose une piste intéressante : les Domain-Specific Languages. L’idée c’est de contraindre l’espace de génération du LLM avec un DSL qui a un validateur déterministe.

Le LLM génère un candidat. Le validateur le rejette ou l’accepte. Boucle génération-vérification. Pas d’humain dans la boucle.

Pourquoi ça marche ? Parce qu’un DSL enlève la variation. Un langage généraliste comme Java ou Python offre des milliers de façons d’exprimer la même intention. Un DSL les réduit à une poignée. Et les LLMs sont très bons avec quelques exemples in-context.

Une autre piste : intégrer des CFG, DFG (Data Flow Graphs) ou CPG (Code Property Graphs) dans le prompt ou l’architecture du modèle. Normaliser la sémantique avant que le LLM touche au code.

Les compilateurs font ça depuis 50 ans. Peut-être qu’on devrait s’en inspirer.

Au lieu de faire confiance au LLM, on vérifie. Formellement. On génère des candidats, on les passe dans un verifieur formel, on recommence si ça passe pas.

C’est plus lent. C’est plus cher. C’est aussi plus fiable.

Pendant la génération, on force la conformité syntaxique en échantillonnant uniquement des tokens valides selon la grammaire du langage. Ça réduit les erreurs de compilation. Ça résout pas le problème sémantique, mais ça enlève le bruit syntaxique qui masque le vrai problème.

Tu vois, le truc qui me fait chier dans tout ça, c’est pas que les LLMs soient limités. C’est qu’on nous les vend comme des remplaçants de développeurs.

Rappel : le code généré par IA produit ~1.7x plus de bugs que le code humain. 2.74x pour les XSS (CodeRabbit 2025). Les CVE attribués au code IA sont passés de 6 en janvier 2026 à 35 en mars 2026.

Et on veut mettre ça en production sans filet ?

Le problème fondamental, c’est que l’architecture Transformer traite le code comme du texte. Pas comme une structure exécutable avec un comportement observable, des invariants, des effets de bord, et une sémantique opérationnelle.

C’est pas une limitation qu’on va régler avec plus de données ou plus de paramètres. Les études le montrent : le gap ne se ferme pas avec l’échelle. Plus le modèle est gros, mieux il fait de la syntaxe, mais le gap sémantique reste.

C’est pas une question de quantité. C’est une question de nature.

  1. Si les LLMs ne comprennent pas la sémantique, peut-on leur confier des tâches de debugging et refactoring ? Réponse courte : non, pas sans supervision humaine.

  2. Les DSLs sont-ils la solution ou un palliatif ? Les deux. Ils marchent, mais ils déplacent le problème : au lieu de faire confiance au LLM, on fait confiance au validateur. C’est mieux, mais c’est pas une solution magique.

  3. Le gap sémantique est-il une limite fondamentale de l’architecture Transformer ? Les études d’interprétabilité (Anand 2024, “A Critical Study of What Code-LLMs (Do Not) Learn”) suggèrent que oui. L’attention ne capture pas les relations syntaxe-identifiants nécessaires à la compréhension du flot de programme. C’est peut-être pas rattrapable avec l’architecture actuelle.

  4. Faut-il repenser le métier de développeur ? L’écriture de code devient un commodity. La spécification et la vérification deviennent le vrai boulot. C’est pas un glissement mineur. C’est une réinvention complète du métier.

  5. Pourquoi les benchmarks nous mentent ? Parce qu’ils mesurent du pattern matching, pas de la compréhension. Les modèles cartonnent sur HumanEval parce que les solutions ressemblent à ce qu’ils ont vu en entraînement. Mets-les sur du code jamais vu, dans un langage jamais vu, avec une logique jamais vue — et regarde-les s’écrouler.

Les LLMs sont des parseurs AST extraordinaires. Ils génèrent du code qui compile, qui a l’air juste, et qui convainc les managers qui savent pas coder.

Mais ils comprennent pas ce qu’ils écrivent.

Ils reconnaissent des patterns lexicaux, pas des comportements. Ils manipulent des tokens, pas des sémantiques. Ils produisent des programmes, pas des solutions.

Et tant qu’on traitera le code comme du texte au lieu d’une structure exécutable avec des invariants, une sémantique opérationnelle, et des effets de bord — tant qu’on confondra la capacité à générer du texte qui ressemble à du code avec la capacité à comprendre ce que ce code fait — on continuera à mettre en production du code syntaxiquement parfait et sémantiquement pourri.

L’IA va pas remplacer les développeurs. Elle va remplacer ceux qui confondent syntaxe et sémantique.

See ya space-cowboy.

Create a split-diagram banner image for a tech blog article titled "Syntaxe vs Sémantique".
Left side (SYNTAXE): a perfectly structured, clean, minimalistic abstract syntax tree
made of glowing green nodes and connections, precise geometric branches. Text overlay:
"SYNTAXE ✓" in clean font.
Right side (SÉMANTIQUE): the same tree structure but warped, distorted, with nodes
mismatched and branches that don't connect properly, in chaotic red/orange glitch
effect. Text overlay: "SÉMANTIQUE ✗" in distressed font.
In the center gap between them: a glowing question mark, half green half red.
Background: dark tech style (#0a0a0f). No logos, no text other than the labels.
16:9 ratio, suitable for blog header/social media card.
Mis à jour le 2026-05-17
 LLM, IA, Code Generation, Génie Logiciel
Retour | Accueil