💻 computer science

Do Code LLMs Do Static Analysis?

Cette étude démontre que les modèles de langage pour le code (Code LLMs) affichent de faibles performances dans les tâches d'analyse statique et que la préformation à ces tâches n'améliore pas, et n'est pas améliorée par, leurs capacités dans les tâches d'intelligence logicielle comme la génération ou la synthèse de code.

Auteurs originaux : Chia-Yi Su, Collin McMillan

Publié 2026-03-27

📖 5 min de lecture🧠 Analyse approfondie

CC BY 4.0

Auteurs originaux : Chia-Yi Su, Collin McMillan

Article original sous licence CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Ceci est une explication générée par l'IA de l'article ci-dessous. Elle n'a pas été rédigée ni approuvée par les auteurs. Pour une précision technique, consultez l'article original. Lire la clause de non-responsabilité complète

🧠 Le Grand Doute : Les IA "pensent-elles" vraiment comme des humains ?

Imaginez que vous apprenez à un enfant (ou à un robot très avancé) à cuisiner.

La méthode humaine : Pour créer un nouveau plat, un chef humain ne se contente pas de mélanger des ingrédients au hasard. Il analyse la recette : il regarde comment les ingrédients interagissent, il suit le chemin de la cuisson, et il comprend la structure du plat avant de commencer. C'est ce qu'on appelle l'analyse statique dans le monde du code : comprendre la logique et les liens entre les lignes de code sans même avoir besoin de lancer le programme.
La méthode de l'IA (selon cette étude) : Les chercheurs se sont demandé : "Est-ce que les intelligences artificielles (comme ChatGPT ou Gemini) font la même chose ? Est-ce qu'elles 'pensent' comme des chefs en analysant la structure, ou sont-elles juste de superbes mimes qui imitent les gestes sans comprendre la recette ?"

🕵️‍♂️ L'Expérience : Le Test de Vérité

Les chercheurs ont mis les IA à l'épreuve avec trois types de défis, un peu comme un examen de conduite théorique et pratique :

Le défi de la "Carte Routière" (Graphes d'appels) : Demander à l'IA de dessiner le plan exact de qui appelle qui dans un bâtiment complexe.
Le défi de la "Plomberie" (Flux de données) : Demander à l'IA de tracer le chemin exact de l'eau (les données) qui circule d'un robinet à un évier à travers des tuyaux.
Le défi de l'"Arbre Généalogique" (AST) : Demander à l'IA de reconstruire l'arbre de la structure du code, mot par mot.

Ensuite, ils ont demandé à l'IA de faire des tâches créatives : écrire du code, le résumer ou le traduire.

🚫 Le Verdict : L'IA est un excellent acteur, mais un mauvais architecte

Les résultats sont surprenants et un peu décevants pour les fans de l'IA :

L'IA est nulle en "analyse statique" : Quand on lui demande de faire ces cartes routières ou de tracer la plomberie, elle se trompe énormément. C'est comme si un acteur qui joue un médecin dans un film savait réciter le nom des médicaments, mais ne savait pas vraiment comment ils agissent dans le corps humain.
L'IA excelle en "imitation" : Par contre, quand on lui demande d'écrire du code ou de le résumer, elle est brillante. Elle a vu des millions de recettes de cuisine et elle sait exactement à quoi ressemble un plat fini. Elle copie le style, les mots et la structure, mais elle ne comprend pas la logique profonde.

🔄 L'expérience de l'entraînement (Le "Cours de Rattrapage")

Les chercheurs ont eu une idée : "Et si on forçait l'IA à apprendre l'analyse statique avant de lui demander de coder ?"

Résultat : Ça n'a rien changé. Même après avoir appris à faire des cartes routières, l'IA n'est pas devenue meilleure pour cuisiner (coder).
L'inverse est aussi vrai : Même après avoir appris à cuisiner des milliers de plats, l'IA n'a pas appris à faire les cartes routières.

L'analogie : C'est comme si vous appreniez à un perroquet à réciter des phrases de physique quantique. Il peut répéter les mots parfaitement, mais si vous lui demandez de résoudre un problème de physique, il ne comprendra rien. Il a appris la forme (les mots), pas le fond (le sens).

🔍 Pourquoi est-ce important ?

Cette étude nous dit quelque chose de crucial sur la nature de ces intelligences artificielles :

Ce ne sont pas des "gens" : Elles n'ont pas de "pensée" humaine. Elles ne font pas d'analyse logique profonde comme nous. Elles font du "pattern matching" (reconnaissance de motifs) à une vitesse incroyable.
Le danger : Si l'IA ne comprend pas la logique profonde du code qu'elle écrit, elle peut créer des programmes qui semblent parfaits mais qui ont des failles de sécurité ou des bugs cachés, parce qu'elle ne "voit" pas les liens cachés entre les parties du code.
L'avenir : Pour que l'IA devienne vraiment utile et sûre, il faudra peut-être changer la façon dont on les entraîne. Il ne suffit pas de leur donner plus de livres à lire ; il faut peut-être leur apprendre à comprendre la structure, pas juste à la copier.

En résumé

Imaginez un chef cuisinier robot.

Il peut copier une recette de 100 pages mot pour mot et la servir à l'identique.
Mais si vous lui demandez : "Comment la sauce A interagit-elle avec l'ingrédient B si on change la température ?", il va probablement inventer une réponse qui sonne bien, mais qui est fausse.

Cette étude nous rappelle que les IA actuelles sont des maîtres de l'imitation, mais qu'elles ne sont pas encore des maîtres de la compréhension.

1. Problématique et Contexte

Les modèles de langage larges (LLM) spécialisés dans le code (Code LLMs) sont devenus omniprésents dans le développement logiciel, générant du code, résumant des fonctions et traduisant des langages. La culture populaire et certains discours scientifiques attribuent souvent à ces modèles des capacités de "raisonnement" ou de "créativité" anthropomorphes.

Cependant, une partie fondamentale de la cognition humaine en ingénierie logicielle est l'analyse statique : le processus d'examen du code sans l'exécuter pour comprendre sa structure (graphes d'appels, flux de données, arbres de syntaxe abstraite - AST). Les humains construisent des modèles mentaux basés sur ces analyses pour comprendre et déboguer le code.

Le problème central de cet article est de déterminer si les Code LLMs utilisent réellement l'analyse statique comme processus de pensée interne (comme le font les humains) ou s'ils se contentent d'un appariement de motifs (pattern matching) superficiel. Si les LLMs "raisonnaient" comme des humains, on s'attendrait à ce que :

Ils excellent dans les tâches d'analyse statique.
L'entraînement sur des tâches d'analyse statique améliore leurs performances sur les tâches de développement de code (et vice-versa).

2. Méthodologie Expérimentale

Les auteurs ont conçu une série d'expériences rigoureuses impliquant deux types de modèles (Open Source et Fermé) et deux langages de programmation (Java et C/C++).

Modèles Utilisés

Open Source : JAM (350M paramètres, Java uniquement) et CodeLlama-Instruct (13B paramètres). Ces modèles ont permis un contrôle total des variables et du fine-tuning.
Fermé (Propriétaires) : GPT-4o mini et Gemini. Ces modèles représentent l'état de l'art commercial mais ne permettent pas de fine-tuning.

Tâches Évaluées

L'étude compare trois tâches d'intelligence de code (développement) et trois tâches d'analyse statique :

Tâches de Développement : Résumé de code, Traduction de code, Génération de code.
Tâches d'Analyse Statique :
- Génération d'AST (Abstract Syntax Tree).
- Génération de graphes d'appels (Call Graphs).
- Génération de graphes de flux de données (Dataflow Graphs).

Protocole Expérimental (Réponses aux Questions de Recherche - RQ)

Les auteurs ont testé cinq questions de recherche (RQ) :

RQ1 : Performance des modèles fermés sur l'analyse statique (sans fine-tuning).
RQ2 : Performance des modèles ouverts sur l'analyse statique après fine-tuning spécifique.
RQ3 : Impact du fine-tuning en analyse statique sur les performances ultérieures en développement de code (transfert de compétences).
RQ4 : Capacité des modèles à effectuer de l'analyse statique après avoir été fine-tunés uniquement sur des tâches de développement (effet secondaire).
RQ5 : Analyse des types d'erreurs commises dans l'analyse statique.

Les métriques utilisées incluent la distance de Levenshtein, la similarité Jaccard, la précision des paires et des chaînes (pour les graphes), ainsi que METEOR, USE, BLEU et CodeBERTScore pour les tâches de texte/code.

3. Résultats Clés

Les résultats contredisent l'hypothèse selon laquelle les LLMs raisonnent comme des humains en utilisant l'analyse statique.

A. Performance sur l'Analyse Statique (RQ1 & RQ2)

Performance Globale Faible : Les modèles fermés (GPT-4o, Gemini) obtiennent de très mauvais résultats sur les tâches de graphes d'appels et de flux de données, même avec des techniques de in-context learning (ex: "Let's think step by step").
Amélioration Limitée par le Fine-tuning : Bien que le fine-tuning améliore légèrement la génération d'AST (syntaxe), il n'apporte qu'une amélioration partielle pour les graphes d'appels et de flux de données. La précision des chaînes (chain accuracy) reste extrêmement faible, indiquant que les modèles ne comprennent pas la structure globale ou les relations complexes.
Différence Syntaxe vs Sémantique : Les modèles apprennent bien les "formes" (tags XML pour l'AST) mais échouent à capturer la "sémantique" (qui appelle qui, comment les données circulent).

B. Transfert de Compétences (RQ3 & RQ4)

Pas de Transfert Statique $\rightarrow$ Développement : Entraîner un modèle sur des tâches d'analyse statique n'améliore pas significativement ses performances sur les tâches de développement (résumé, génération, traduction). Les modèles pré-entraînés sur l'analyse statique commettent les mêmes erreurs logiques que les modèles de base.
Pas de Transfert Développement $\rightarrow$ Statique : Inversement, entraîner un modèle sur des tâches de développement de code ne lui permet pas d'acquérir la capacité de faire de l'analyse statique. Les modèles fine-tunés pour le code échouent lamentablement lorsqu'on leur demande de générer des graphes d'appels ou de flux.

C. Analyse des Erreurs (RQ5)

Types d'erreurs dominants :
- Pour les graphes d'appels : Les modèles génèrent trop d'appels directs ("extra direct calls") et créent des cycles inexistants (hallucinations de cycles).
- Pour les flux de données : Ils ajoutent des arêtes directes et indirectes qui n'existent pas.
- Pour les AST : Erreurs de balises (tag mismatch) et structures incomplètes.
Conclusion sur les erreurs : Les modèles semblent "deviner" des relations basées sur la proximité textuelle plutôt que sur une compréhension réelle du flux de contrôle ou de données.

4. Contributions et Signification

Contributions Principales

Preuve Empirique de l'Absence de Raisonnement Statique : L'article démontre que les Code LLMs actuels ne possèdent pas de mécanisme interne d'analyse statique comparable à celui des humains. Ils ne "pensent" pas en termes de graphes d'appels ou de flux de données.
Découplage des Compétences : Il est prouvé que les compétences en analyse statique et en génération de code sont découplées chez les LLMs. L'un ne nourrit pas l'autre, ce qui suggère que les modèles apprennent des corrélations superficielles plutôt que des principes fondamentaux du logiciel.
Limites du "Raisonnement" Anthropomorphique : L'étude remet en question l'usage de termes comme "raisonnement" pour décrire le comportement des LLMs. Les modèles semblent mémoriser la "forme" du code (syntaxe, structure locale) sans en comprendre la "sémantique" (comportement global).

Implications et Signification

Pour la Recherche en IA : Il est nécessaire de développer de nouvelles architectures ou des procédures d'entraînement qui intègrent véritablement la sémantique du code, et non seulement la forme. Les approches actuelles basées sur l'apprentissage par renforcement ou le prompting ne suffisent pas à créer un véritable "raisonnement" statique.
Pour l'Ingénierie Logicielle : Les développeurs ne doivent pas supposer que les LLMs comprennent la structure profonde du code. L'utilisation de LLMs pour des tâches critiques (sécurité, refactoring complexe) nécessite une validation humaine rigoureuse, car les modèles peuvent générer du code syntaxiquement correct mais sémantiquement erroné ou dangereux.
Pour la Formation : L'idée que l'entraînement sur l'analyse statique rendrait un LLM meilleur programmeur est infondée selon cette étude.

Conclusion

En résumé, l'article conclut que les LLMs de code ne font pas d'analyse statique au sens où le font les humains. Ils excellent dans la génération de formes syntaxiques mais échouent dans la compréhension des relations sémantiques complexes (flux de données, appels de fonctions). Ils agissent comme des moteurs de prédiction de tokens sophistiqués plutôt que comme des agents de raisonnement logique sur le code.