Rapports
À l’intérieur des personnalités de codage des principaux LLM – Constats du rapport Sonar State of Code
Ajouter Unite.AI à vos sources préférées sur Google
En août 2025, Sonar a publié son dernier État du code étude, Les personnalités de codage des principaux LLM – Un rapport sur l’état du code. Cette recherche va au-delà des scores de précision, en examinant comment les grands modèles de langage écrivent réellement du code et en révélant des « personnalités de codage » uniques pour chacun.
L’étude a évalué Claude Sonnet 4, Claude 3.7 Sonnet, GPT-4o, Llama 3.2 90B et OpenCoder-8B sur plus de 4 400 affectations Java en utilisant le moteur d’analyse statique de Sonar – une technologie affinée pendant 16 ans grâce à sa plate-forme SonarQube Enterprise.
Points forts partagés
Les cinq modèles ont démontré une fiabilité syntaxique solide, ce qui signifie que leur code généré a été compilé et exécuté avec succès dans la plupart des cas. Cela ressort clairement de leurs scores HumanEval, un test de référence où les modèles sont invités à résoudre des problèmes de codage et leurs solutions sont automatiquement vérifiées pour leur exactitude. Claude Sonnet 4 a obtenu le score le plus élevé avec un score HumanEval de 95,57 % et un taux de réussite pondéré de 77,04 %, ce qui signifie que sa première tentative était correcte dans plus de trois quarts des cas. Claude 3.7 Sonnet a obtenu un score de 72,46 %, GPT-4o 69,67 %, Llama 3.2 61,47 % et OpenCoder-8B 60,43 %.
Cette performance s’est maintenue à travers différents langages de programmation, montrant que ces modèles raisonnent à travers les problèmes plutôt que de s’appuyer uniquement sur une syntaxe mémorisée.
Faiblesses communes
La faille partagée la plus alarmante était une mauvaise hygiène de sécurité. Sonar a mesuré les vulnérabilités de niveau bloquant, qui constituent la catégorie la plus grave de failles – des problèmes de sécurité qui peuvent conduire directement à de graves violations ou à une compromission du système si elles sont exploitées. Des exemples incluent du code qui permet l’accès à des fichiers arbitraires, des injections SQL ou de commande, des mots de passe codés en dur, une encryption mal configurée ou l’acceptation de certificats non fiables. Ceux-ci étaient beaucoup trop courants : Claude Sonnet 4 avait 59,57 % de ses vulnérabilités à ce niveau de gravité, GPT-4o en avait 62,5 % et Llama 3.2 un pourcentage inquiétant de 70,73 %.
Le rapport a également noté des fuites de ressources répétées, un type de bogue où le code ouvre une ressource – telle qu’un handle de fichier, une socket de réseau ou une connexion de base de données – mais ne parvient pas à la fermer correctement. Au fil du temps, ces fuites peuvent épuiser les ressources système disponibles, conduisant à des problèmes de performance ou à des plantages. Claude Sonnet 4 a présenté 54 telles violations, Llama 3.2 en a présenté 50 et GPT-4o 25.
En termes de maintenabilité, la majorité des problèmes étaient des odeurs de code – des modèles qui ne cassent pas le programme immédiatement mais le rendent plus difficile à maintenir et plus enclin aux bogues à l’avenir. Plus de 90 % de tous les problèmes identifiés sont tombés dans cette catégorie, impliquant souvent du code non utilisé, une mauvaise dénomination, une complexité excessive ou des violations des meilleures pratiques de conception.
Personnalités distinctes
De ce mélange de forces et de faiblesses, Sonar a identifié des profils de « personnalité » clairs.
Claude Sonnet 4 a mérité le titre de « l’Architecte senior ». Il écrit le code le plus verbeux – 370 816 lignes à travers l’ensemble de test – avec une complexité cognitive élevée, ce qui signifie que ses chemins logiques sont plus difficiles à suivre. Il se comporte bien mais est enclin à des bogues sophistiqués comme les fuites de ressources et les erreurs de concurrence, qui peuvent survenir lorsque plusieurs threads ou processus interagissent de manière non intentionnelle.
OpenCoder-8B était « le prototypiste rapide », produisant un code court et ciblé – 120 288 lignes au total – mais avec la plus forte densité de problèmes. Sa rapidité et sa concision le rendent bien adapté aux preuves de concept, mais dangereux pour la production sans examen attentif.
Llama 3.2 90B était « la promesse non tenue ». Il a obtenu des résultats modérés mais a présenté la pire posture de sécurité, avec plus de 70 % de vulnérabilités classées comme de niveau bloquant.
GPT-4o était « le généraliste efficace », équilibrant la fonctionnalité et la complexité mais trébuchant souvent sur des erreurs de contrôle de flux – des erreurs dans la séquence logique des opérations qui peuvent conduire à des résultats incorrects ou à du code sauté.
Claude 3.7 Sonnet était « le prédécesseur équilibré », produisant un code moins verbeux que son successeur mais avec la plus forte densité de commentaires à 16,4 %, ce qui signifie qu’il expliquait sa logique plus que tout autre modèle. Même s’il était meilleur en matière de documentation, il a toujours présenté des vulnérabilités de haute gravité importantes.
L’une des constatations les plus frappantes est venue de la comparaison de Claude Sonnet 4 avec Claude 3.7. Bien que Sonnet 4 ait amélioré son taux de réussite de 6,3 %, le pourcentage de ses bogues classés comme de niveau bloquant a presque doublé, passant de 7,10 % à 13,71 %. Les vulnérabilités de niveau bloquant ont également augmenté de 56,03 % à 59,57 %. La leçon : les améliorations de performances peuvent se faire au détriment de la sécurité.
Conclusion
Le rapport de Sonar Les personnalités de codage des principaux LLM – Un rapport sur l’état du code montre clairement que la précision des benchmarks ne raconte qu’une partie de l’histoire. Comprendre les risques de sécurité, la maintenabilité et le style de codage est tout aussi important que de savoir combien de fois un modèle « obtient raison ».
Chaque personnalité – qu’il s’agisse d’un architecte, d’un prototypiste, d’un généraliste ou d’un prédécesseur équilibré – a des forces et des compromis. La conclusion pour les développeurs et les organisations est de « faire confiance mais vérifier », en associant l’assistance de codage basée sur l’IA à une surveillance humaine, à un examen de code approfondi et à des contrôles de sécurité rigoureux pour s’assurer que la rapidité et la commodité ne compromettent pas la sécurité ou la stabilité à long terme.
