Comparer six LLM pour des corrections de code réelles – GPT‑5, Claude Sonnet, Grok et plus.

Introduction

Un benchmark récent du blog Kilo Code a soumis six grands modèles de langage (LLM) à trois défis de codage réalistes. L’objectif était simple : voir quels modèles pouvaient repérer des bugs critiques pour la sécurité, proposer des correctifs prêts pour la production, et le faire de manière rentable. Les modèles évalués étaient GPT‑5, OpenAI o1, Claude Opus 4.1, Claude Sonnet 4.5, Grok 4 et Gemini 2.5 Pro.

Les résultats mettent en évidence un compromis clair entre profondeur technique brute et maintenabilité pratique. Si chaque modèle a identifié les vulnérabilités, la qualité, la complétude et le coût des correctifs ont varié de façon spectaculaire. Vous trouverez ci‑dessous une analyse détaillée de la méthodologie, des trois cas de test et des recommandations concrètes pour les ingénieurs qui souhaitent choisir un LLM pour la revue de code ou les contrôles automatisés de PR.

---

Test Methodology

Kilo Code a construit un banc d’essai cohérent afin d’assurer une comparaison équitable :

• Entrée : de petits extraits de code à risque (10‑50 lignes) ont été soumis à chaque modèle avec le même prompt : « Fix this. No hints, no leading questions. »
• Phase 1 – Jugement IA : un ruban automatisé a noté chaque réponse selon la correction, la qualité du code, la complétude, les pratiques orientées sécurité et les performances.
• Phase 2 – Validation humaine : des ingénieurs ont revu les correctifs classés par l’IA et ont sélectionné les versions qu’ils auraient réellement fusionnées.

Cette approche en deux étapes combine des métriques objectives avec le jugement réel des développeurs, offrant une vision pragmatique de l’utilité de chaque modèle dans les pipelines de production.

---

Scenario 1 – Node.js Config Merge Vulnerability

Problème : une fonction de deep‑merge propage involontairement un drapeau admin malveillant provenant d’une charge utile forgée à travers les chaînes de prototypes, reproduisant les schémas classiques d’OASP.

Résultats des modèles :

• GPT‑5 : a implémenté des garde‑fous en couches — objets de base à prototype nul, blocage explicite des clés à risque, vérifications hasOwnProperty et gel des objets sensibles. Le correctif était complet et prêt pour la production.
• OpenAI o1 : a fourni des fonctions d’aide propres, une liste concise de clés interdites et des commentaires lisibles. La solution était facile à auditer en quelques minutes.
• Claude Sonnet 4.5 : a utilisé Object.create(null) et le blocage des clés, offrant une protection solide mais légèrement moins approfondie que GPT‑5.
• Gemini 2.5 Pro : a appliqué leage des clés et les prototypes nuls, mais a manqué certains cas limites récursifs.
• Claude Opus 4.1 : s’est appuyé sur des schémas et des vérifications de type — efficace mais ajoutant une charge de maintenance.
• Grok 4 : s’est concentré sur un filtrage simple et a omis la validation hasOwnProperty, aboutissant à un correctif plus faible.

Enseignement : tous les modèles ont détecté la faille, mais seuls GPT‑5 et OpenAI o1 ont produit des correctifs qui semblaient prêts pour la production sans complexité excessive.

---

Scenario 2 – Modern Agent Workflow (2025 Style)

Problème : un agent piloté par IA récupère une page web, en interprète le contenu et propose des appels d’outils à une API de gestion cloud. Sans limites strictes, l’agent peut exécuter des instructions malveillantes, entraînant une fuite de jetons entre locataires et des modifications non autorisées.

Résultats des modèles :

• GPT‑5 : a introduit des portées d’outil étroites, des règles de confirmation en deux étapes, des frontières de confiance strictes (les identifiants n’apparaissent jamais dans le texte du modèle), des contrôles de provenance sur le HTML récupéré et des jetons à durée de vie courte basés sur les rôles.
• OpenAI o1 : a égalé la profondeur de GPT‑5, ajoutant une analyse RBAC « shadow‑tenant », la validation du schéma de réponse et une configuration qui supprime complètement l’accès au système de fichiers.
• Claude Sonnet 4.5 : a couvert les frontières de confiance et le suivi de provenance, mais sans le niveau de détail granulaire de GPT‑5.
• Gemini 2.5 Pro : a limité les outils et utilisé des vérifications de schéma ; le contrôle était présent mais plus léger que chez les meilleurs.
• Claude Opus 4.1 : a employé la validation Zod et DOM purify, offrant des diagrammes clairs mais moins de défenses en couches.
• Grok 4 : a référencé le top‑10 OASP et les directives NIST avec des listes blanches ; la logique de garde était simple.

Enseignement : pour des schémas récents et complexes, un raisonnement plus profond (comme celui de GPT‑5 et OpenAI o1) l’emporte sur le simple appariement de motifs.

---

Scenario 3 – ImageMagick Command Injection

Problème : une API Express construit une commande shell pour ImageMagick en utilisant la police et le texte fournis par l’utilisateur. Une charge utile malveillante peut injecter des opérateurs shell (par ex. ; rm -rf /), entraînant une exécution de code arbitraire.

Résultats des modèles :

• GPT‑5 : a mis en place une défense exhaustive — listes blanches strictes, chemins de police absolus, évitement des préfixes spéciaux, exécution via des vecteurs d’arguments (pas de shell), entrée via stdin, plafonds de taille/taux, et nettoyage automatique des fichiers temporaires.
• Claude Opus 4.1 : a proposé une approche similaire avec spawn, listes blanches, validation de taille, filtrage des caractères de contrôle et des démonstrations détaillées pour les réviseurs.
• Claude Sonnet 4.5 : a utilisé execFile avec des listes blanches fortes et une limitation du débit.
• OpenAI o1 : est passé à execFile avec une validation concise des polices et une désinfection du texte.
• Gemini 2.5 Pro : a adopté spawn avec listes blanches et validation propre.
• Grok 4 : a expliqué les pièges de l’analyse shell (point‑virgule, pipe, esperluette, backticks) et est passé à spawn avec une validation de plage.

Enseignement : les meilleures solutions superposaient une exécution sécurisée du processus avec des listes blanches strictes et des limites de débit, éliminant ainsi les vecteurs d’injection shell.

---

Cost Analysis

Exécuter les trois scénarios sur les six modèles a coûté environ 181 $ au total. Le cas ImageMagick était le plus cher en raison de la longueur des sorties du modèle. Le scénario de fusion Node.js était le moins coûteux, avec une moyenne de 0,60 $ par évaluation (environ 0,10 $ par exécution de modèle).

Recommandations budgétaires :

• Pour des analyses en masse où le coût compte, Gemini 2.5 Pro ou OpenAI o1 offrent 90‑95 % de la qualité de GPT‑5 à un coût environ 72 % inférieur.
• Pour les domaines à haut risque (finance, santé, API privilégiées), le surcoût de GPT‑5 se justifie par ses garde‑fous maximalistes.
• Pour les revues de type OASP classiques, Claude Sonnet 4.5 propose un bon équilibre entre couverture et accessibilité financière.

---

Pragmatic Recommendations

• Systèmes critiques : déployer GPT‑5. Ses défenses en couches et ses correctifs exhaustifs justifient le prix premium.
• Scans à haut volume, faible risque : choisir Gemini 2.5 Pro ou OpenAI o1 pour obtenir des performances quasi‑optimales à une fraction du coût.
• Milieu de gamme : Claude Sonnet 4.5 offre une protection solide sur les motifs familiers tout en restant économique.
• Maintenabilité : les réviseurs humains ont préféré OpenAI o1 parce que ses correctifs étaient concis, lisibles en 15 minutes, et couvraient néanmoins les scénarios les plus complexes.

L’idée clé est que la solution parfaite n’est pas toujours la meilleure à long terme. Un correctif légèrement moins complet mais facile à comprendre et à entretenir peut être plus précieux dans un environnement de développement rapide.

---

Conclusion

Le benchmark Kilo Code montre que les LLM modernes ont atteint un niveau où les six modèles détectent de façon fiable les bugs critiques pour la sécurité. Les différenciateurs résident désormais dans la profondeur des correctifs, le nombre de garde‑fous en couches et le coût total d’exécution.

• GPT‑5 domine en profondeur technique et sécurité, idéal pour le code mission‑critical.
• OpenAI o1 trouve un équilibre pragmatique entre lisibilité, robustesse et coût.
• Gemini 2.5 Pro et Claude Sonnet 4.5 se positionnent comme des chevaux de bataille capables pour l’hygiène quotidienne du code.

Lors de l’intégration des LLM dans votre flux de travail de pull‑request, alignez le modèle sur la mission : privilégiez la sécurité maximale pour les services à fort impact, et optez pour des modèles économiques lorsque la rapidité et le volume priment.

En traitant les LLM comme des revueurs assistés plutôt que comme des oracles remplaçants, les équipes d’ingénierie peuvent exploiter leurs forces tout en limitant la charge de maintenance — livrant ainsi du code plus sûr à grande échelle.