En bref

Les LLM entraînés sur du code ont progressé à une vitesse inhabituelle : en quatre ans, les meilleurs systèmes sont passés de 28 % à plus de 90 % sur les tests de référence classiques. Cette trajectoire cache une réalité plus nuancée. Les benchmarks saturent, la contamination des données fausse les scores, et des études contrôlées montrent que les développeurs utilisant des assistants IA produisent parfois plus de code vulnérable, pas moins. L’arrivée des agents autonomes de code en 2024-2025 a ouvert un nouveau front, avec des résultats à la fois impressionnants et difficiles à interpréter.

Ce que les modèles font vraiment

Un modèle de code est un LLM entraîné sur des corpus incluant du code source en grande quantité. Sa tâche initiale était la complétion : continuer un fragment de code existant. Le périmètre s’est ensuite élargi à la génération depuis une description en langage naturel, la correction de bugs, la traduction entre langages, et l’explication de code.

Le modèle fondateur du domaine est Codex (Chen et al., OpenAI, 2021) : un GPT-3 affiné sur 54 millions de fichiers GitHub publics. Il atteignait 28,8 % sur le benchmark HumanEval — la référence de l’époque — et est devenu la base technique de GitHub Copilot lors de son lancement commercial en 2022.

Depuis, l’évolution a été rapide. CodeLlama (Meta, 2023) a porté ce score à 53,7 % sur HumanEval avec sa variante Python de 34 milliards de paramètres. DeepSeek-Coder (2024) atteint 90,2 % pour sa version 236 milliards de paramètres — au niveau de GPT-4o. Ces modèles sont disponibles en open-weight, ce qui a significativement perturbé le marché des solutions propriétaires.

HumanEval : un test devenu trop simple

HumanEval est un ensemble de 164 problèmes Python avec tests unitaires, conçu par OpenAI en 2021. Sa métrique principale, pass@k, mesure la proportion de problèmes résolus quand le modèle génère k solutions différentes. C’est simple, reproductible, et c’est désormais insuffisant.

Le problème est double. D’abord, la saturation : à plus de 90 % de réussite pour les meilleurs modèles, la mesure ne discrimine plus. Ensuite, la contamination : HumanEval étant public depuis 2021, ses solutions se retrouvent vraisemblablement dans les corpus d’entraînement des modèles récents. Les scores reflètent alors en partie de la mémorisation, pas de la généralisation.

Pour tester cette hypothèse, HumanEval+ (Liu et al., NeurIPS 2023) et EvoEval (Xia et al., 2024) génèrent automatiquement des variantes mutées des problèmes originaux. Le résultat est éloquent : GPT-4 perd environ 20 % de performance sur ces variantes, suggérant qu’une fraction non négligeable de ses bons scores provient de la mémorisation.

SWE-bench : la vraie difficulté

Pour sortir des problèmes jouets, SWE-bench (Jimenez et al., Princeton/Chicago, 2023) propose 2 294 issues GitHub réelles, extraites de dépôts populaires comme Django, scikit-learn ou sympy. La tâche : corriger un vrai bug dans un vrai codebase. C’est autrement plus complexe qu’un problème Python isolé.

En 2024, la majorité des systèmes résolvaient moins de 5 % des issues. La progression depuis a été notable : les meilleurs agents approchent 50 % sur SWE-bench Verified (Chowdhury et al., 2024), un sous-ensemble de 500 issues vérifiées manuellement pour garantir la qualité du ground truth. Cela reste loin de 100 %, et les issues les plus difficiles — celles impliquant une compréhension architecturale profonde du codebase — demeurent hors de portée.

Les agents de code en 2024-2025

Le saut qualitatif de cette période n’est pas dans les modèles eux-mêmes mais dans la façon de les utiliser. Les agents de code combinent un LLM avec des outils : accès au shell, navigation dans les fichiers, exécution de tests. L’agent peut itérer sur son propre output jusqu’à ce que les tests passent.

Devin (Cognition AI, mars 2024) a été présenté comme le premier “ingénieur logiciel IA” capable de travailler de façon autonome dans un environnement sandboxé. Son score initial de 13,86 % sur SWE-bench a été contesté et revu. SWE-agent (Yang et al., Princeton, 2024) est l’alternative académique open-source, atteignant 12,5 % sur SWE-bench lite.

Du côté des outils, Cursor (Anysphere), Windsurf (Codeium) et Claude Code (Anthropic, 2025) ont renouvelé le marché des environnements de développement augmentés. La combinaison SWE-agent + Claude 3.5 Sonnet figure parmi les meilleures configurations documentées sur SWE-bench Verified en configuration agentique.

Le problème de la sécurité

C’est le point le plus critique pour un usage professionnel. Pearce et al. (2022, IEEE S&P) ont testé Codex sur 89 scénarios impliquant des failles connues — injection SQL, dépassement de tampon, traversée de chemin. Résultat : 40 % du code généré dans les contextes sensibles présentait des vulnérabilités.

L’étude la plus contre-intuitive vient de Perry et al. (2023, ACM CCS) : dans une expérience contrôlée, les participants ayant accès à GitHub Copilot produisaient significativement plus de code vulnérable que le groupe sans assistant, et exprimaient une confiance plus élevée dans leur code incorrect. L’assistant rendait les développeurs plus rapides et plus confiants — pas nécessairement plus sûrs.

Sandoval et al. (2023, USENIX Security) nuancent ce résultat : dans leur protocole, les utilisateurs de Copilot ne produisaient pas plus de vulnérabilités que le groupe contrôle. Mais le groupe contrôle était composé d’experts en sécurité — un biais de sélection qui limite la portée de la conclusion.

La question n’est pas tranchée. Ce qui est certain : les assistants de code ne détectent pas activement les vulnérabilités dans le code qu’ils génèrent, et la confiance accrue qu’ils induisent peut être un facteur de risque.

La question des licences

Codex et GitHub Copilot reproduisent parfois du code sous licence GPL verbatim. La plainte Doe v. GitHub (déposée en 2022) allègue une violation des conditions de licence open-source par reproduction sans attribution. La question légale reste ouverte : un modèle entraîné sur du code GPL est-il lui-même soumis au copyleft ?

Le BigCode Project (Hugging Face + ServiceNow) a répondu en construisant The Stack v2 avec un mécanisme d’opt-out permettant aux développeurs de retirer leur code du corpus d’entraînement. Cela ne résout pas le problème des modèles déjà entraînés sur les versions antérieures.

Compréhension ou mémorisation ?

La question sous-jacente à tous ces débats : les modèles de code comprennent-ils réellement les programmes, ou reconnaissent-ils des patterns syntaxiques mémorisés ?

CRUXEval (Gu et al., 2024) teste une capacité différente : prédire l’output d’un programme donné, ce qui nécessite de raisonner sur son exécution plutôt que d’en générer un similaire. Les scores sont nettement inférieurs aux scores HumanEval correspondants, suggérant que la génération de code exploite davantage la mémorisation syntaxique que la compréhension sémantique des programmes.

C’est une limite importante pour les usages complexes : un modèle peut compléter une fonction avec une syntaxe correcte sans avoir modélisé ce que fait réellement le programme.

Ce qu’il faut retenir

  • Les meilleurs modèles dépassent 90 % sur HumanEval, mais ce score est en partie biaisé par la contamination des données d’entraînement ; les variantes mutées révèlent une dégradation significative des performances.
  • SWE-bench, qui mesure la résolution d’issues GitHub réelles, reste bien plus difficile : les meilleurs agents approchent 50 % sur le sous-ensemble vérifié, mais les tâches complexes restent hors de portée.
  • Des études contrôlées montrent que les assistants de code peuvent augmenter le taux de vulnérabilités produites et la confiance des développeurs dans du code incorrect — un risque documenté, pas hypothétique.
  • La question juridique des licences open-source reste non résolue : aucune jurisprudence établie sur la reproduction de code GPL par les modèles.
  • La différence entre génération syntaxique et compréhension sémantique est mesurable (CRUXEval) : les modèles raisonnent moins bien sur l’exécution des programmes qu’ils n’en génèrent.

Sources