Tous les articles

Blog

Meilleure IA pour coder : aucune n'écrit du code sûr sans relecture

Claude, GPT-5, Gemini : la meilleure IA pour coder laisse encore passer des failles. Le classement chiffré, et ce qui protège votre code.

  • Par Azziz ERRIME
  • 11 min de lecture
Rangée de machines à écrire anciennes identiques sans inscription, une seule feuille relevée et barrée de rouge

TL;DR

  • Côté sécurité, aucun modèle ne dispense de relire, et le choix du modèle ne remplace pas une revue orientée sécurité.
  • Selon Veracode, la meilleure IA pour coder du classement produit du code sûr sur 72 % des tâches, Claude Sonnet 4.5 sur 50 %.
  • Je choisirais le modèle pour la productivité de l’équipe, et je mettrais l’effort de sécurité sur la revue de code.

En mars 2025, un chercheur scanne 1 645 applications générées avec une IA et en trouve 170 dont la base de données répond à n’importe qui. Je n’ai trouvé nulle part quel modèle avait écrit ce code. C’est pourtant la première question que l’on pose en cherchant la meilleure IA pour coder. Pour la sécurité, sa réponse ne dit rien de ce qui arrive au code après sa génération.

Les 20 et 21 mars 2025, Matt Palmer passe au crible des projets publiés avec Lovable, un service qui génère des applications web avec une IA. Sur 1 645 projets, il compte 303 points d’accès exposés dans 170 d’entre eux. Il prévient l’éditeur le 21, puis décrit dans un billet publié ensuite ce qu’on y lisait : adresses e-mail, numéros de téléphone, informations de paiement et clés d’API de services tiers.

En avril, Lovable sort une version 2.0 équipée d’un scanner de sécurité. Le 14 avril, un ingénieur de Palantir tombe sur la même faille de son côté et la publie sur X. Le 29 mai, elle reçoit un identifiant public, CVE-2025-48757. Matt Palmer reproche au nouveau scanner de s’arrêter à la présence d’une règle de protection : il « merely checks for the existence of any RLS policy, not its correctness ».

Les applications tournaient, les écrans s’affichaient, et la faille ne se voyait que si quelqu’un allait la chercher. Avant de comparer les modèles, je garde cette scène en tête : la question utile porte aussi sur ce qu’on fait du code une fois écrit.

Une base ouverte ne se voit dans aucune démonstration

La règle qui manquait dans ces applications s’appelle RLS, pour Row Level Security. Posée dans la base de données, elle décide quelle ligne chaque utilisateur a le droit de lire. Sans elle, l’interface peut afficher à chacun ses seules données pendant que la base, derrière, répond à toutes les questions qu’on lui pose.

Concrètement, l’attaquant n’a rien à casser. Il ouvre l’application dans son navigateur et regarde les requêtes qui partent vers la base. Il repère l’adresse et la clé publique qui servent à l’interroger, puis rejoue la requête en demandant la table entière, que la base renvoie si aucune règle ne filtre.

Une faille de ce genre est une absence. Il manque une ligne de configuration, et aucun test fonctionnel ne la réclame, puisque tout fonctionne. C’est un défaut que la génération de code produit sans bruit, parce qu’il ne casse rien de visible. Reste à savoir si le modèle le mieux classé en produit moins que les autres, et sur ce point, il existe des mesures.

La meilleure IA pour coder rate encore 28 % des tâches de sécurité

Veracode, éditeur d’outils de sécurité applicative, soumet régulièrement les principaux modèles à une même batterie de tâches de programmation. Chacune expose à une faille connue, et Veracode vérifie si le code produit l’évite. Sa mise à jour publiée le 18 novembre 2025 donne le classement ci-dessous. C’est le dernier classement par modèle que j’ai pu lire. La mesure de mars 2026 ne donne qu’une moyenne.

Modèle Part des tâches où le code produit est sûr
GPT-5 Mini 72 %
GPT-5 (avec raisonnement) 70 %
Gemini 2.5 Pro 59 %
Grok 4 55 %
GPT-5-chat (sans raisonnement) 52 %
Gemini 2.5 Flash 51 %
Qwen3 Coder 50 %
Claude Sonnet 4.5 50 %
Claude Opus 4.1 49 %

Le haut du tableau appartient aux modèles qui raisonnent avant de répondre. Dans la même famille, GPT-5 passe de 52 % sans raisonnement à 70 % avec. Veracode l’explique par une image que je trouve juste : les étapes de raisonnement « function like an internal code review ». Le modèle compare plusieurs façons d’écrire la fonction et écarte les moins sûres avant de répondre.

Si l’on cherche la meilleure IA pour coder sur ce seul critère, le tableau donne une consigne d’achat. Lu de près, il laisse deux questions ouvertes. Que vaut le code des 28 % de tâches que même le premier rate ? Et que mesure exactement ce classement, qui ne regarde que des failles connues sur des tâches choisies d’avance ?

Un modèle meilleur au benchmark peut introduire des bugs plus graves

Sonar, éditeur d’outils d’analyse de code, a fait passer des exercices en Java à plusieurs modèles, puis analysé le code obtenu. Son rapport du 13 août 2025 relève un paradoxe. En passant de Claude 3.7 Sonnet à Claude Sonnet 4, le score au benchmark progresse. Les bugs que le nouveau modèle introduit ont pourtant une probabilité plus élevée de plus de 93 % d’être classés BLOCKER, la catégorie bloquante.

Le classement de Veracode ne voit pas non plus les dépendances. Une IA qui génère du code propose aussi des bibliothèques à installer, et certaines n’existent pas. L’étude de Spracklen et ses collègues, présentée à USENIX Security en 2025, mesure ces noms inventés. Elle en compte 3,59 % parmi les paquets recommandés par GPT-4 Turbo, le plus bas, 13,63 % pour le meilleur modèle ouvert, un DeepSeek, et 19,7 % en moyenne. Et 43 % de ces noms inventés se répètent sur dix exécutions. Un attaquant qui repère un nom inventé de façon récurrente peut publier un paquet malveillant sous ce nom et attendre qu’un développeur l’installe.

Le banc d’essai BaxBench pose enfin la question qui manque aux deux autres. Il fait écrire à onze modèles des services complets, vérifie qu’ils fonctionnent, puis les attaque : environ la moitié des programmes fonctionnellement corrects restent exploitables. La faille de Lovable appartient à cette famille, celle d’un code qui fait ce qu’on lui demande, et rien de ce qu’on a oublié de lui demander.

Reste un argument sérieux en faveur du classement : les modèles de raisonnement progressent vite, et il suffirait de suivre le premier.

Deux ponts suspendus côte à côte, le plus abouti avec un câble porteur rompu

Le plus abouti des deux a lâché le premier.

Hors raisonnement, aucun modèle n’a progressé depuis juillet 2025

Le progrès des modèles de raisonnement est réel, et je ne le minimise pas. Entre GPT-5-chat et GPT-5 avec raisonnement, l’écart atteint dix-huit points. Pour une équipe qui génère beaucoup de code, ce n’est pas rien.

Le même rapport décrit pourtant un marché à l’arrêt : « Models from Anthropic, Google, Qwen, and xAI released between July and October 2025 did not show meaningful security improvements. » Les modèles de ces éditeurs restent groupés entre 50 et 59 %, la fourchette déjà observée à l’été. Sa mesure suivante, publiée le 24 mars 2026, compte 55 % de tâches qui donnent du code sûr, des chiffres qui « have barely budged » depuis le premier rapport de 2025.

J’y lis un indice, pas une preuve : le seul gain net vient d’une étape que Veracode compare à une revue. Aucune étude que j’ai lue ne mesure ce qu’apporte une revue humaine sur du code généré.

Encore faut-il savoir qui relit, et comment on s’y prend.

Une consigne de sécurité change ce que voit le relecteur

La tentation naturelle consiste à faire relire le code d’une IA par une autre IA. Kim et ses collègues ont mesuré à quel point les modèles se trompent ensemble, dans un travail présenté à ICML en 2025. Sur un jeu de données de classement, quand deux modèles se trompent tous les deux, ils font la même erreur dans environ 60 % des cas. Ce chiffre ne vaut que pour ce jeu de données. Il suffit à me faire douter qu’un second modèle voie ce que le premier a raté.

La relecture humaine a son propre point faible, et il se corrige facilement. Demander explicitement à un relecteur de regarder la sécurité multiplie par huit ses chances de trouver la faille, selon Braz et ses collègues, sur du code écrit par des humains.

Concrètement, une revue orientée sécurité du code généré par IA cherche d’abord ce qui manque, avant ce qui est écrit. Une règle d’accès sur chaque table, une validation sur chaque entrée, une dépendance qui existe vraiment et qui est bien celle qu’on croit. J’ai expliqué dans un précédent article pourquoi la revue de code ne suit plus le rythme de l’IA.

Porte de coffre-fort entrouverte, serrure présente mais pêne rentré

La serrure est bien là. Personne n’a vérifié qu’elle était fermée.

Choisir la meilleure IA pour coder sur un classement revient à vérifier qu’une règle existe

Selon Matt Palmer, le scanner de Lovable vérifiait qu’une règle de protection existait, sans vérifier qu’elle protégeait. Choisir la meilleure IA pour coder sur un classement, puis s’en remettre à ce choix, procède du même raccourci. On contrôle la présence d’une garantie, sans mesurer son effet sur votre code.

Je choisirais le modèle sur la productivité de l’équipe, ses langages et l’endroit où partent vos données, et je mettrais l’effort sur la sécurité du code ailleurs :

  • une ligne dans le modèle de pull request qui demande explicitement de relire la sécurité, puisque la seule consigne multiplie la détection ;
  • une vérification de chaque dépendance ajoutée par un modèle : le paquet existe-t-il, et est-ce le bon ;
  • une relecture qui commence par ce qui manque, règles d’accès et validations, avant ce qui est écrit ;
  • un nouveau regard sur le classement chaque trimestre, sans en faire une politique.

C’est aussi ce que je mesure en ce moment : ce que les développeurs repèrent, ou laissent passer, quand ils relisent du code écrit par une IA. Les modèles changent plus vite que les habitudes de relecture.

Je garde une réserve. Les modèles de raisonnement ont gagné dix-huit points chez Veracode, et rien n’interdit que la génération suivante rende la relecture moins nécessaire. Je changerai d’avis quand une mesure indépendante le montrera. D’ici là, je relis.

Questions fréquentes sur la meilleure IA pour coder

Quelle est la meilleure IA pour coder ?

Pour la sécurité, aucune ne se détache assez pour dispenser de relire. Dans la mesure publiée par Veracode le 18 novembre 2025, GPT-5 Mini produit du code sûr sur 72 % des tâches et GPT-5 sur 70 %. Claude Sonnet 4.5 et Qwen3 Coder sont à 50 %. Pour la productivité, la meilleure IA pour coder dépend de vos langages et de vos outils : testez-la sur votre propre code.

Claude ou ChatGPT pour coder ?

Dans le duel Claude vs ChatGPT, la mesure de Veracode donne 70 % de tâches sûres à GPT-5 avec raisonnement et 50 % à Claude Sonnet 4.5. Sans raisonnement, GPT-5-chat tombe à 52 %, si bien que l’écart tient au mode plus qu’à la marque. Les deux familles demandent une relecture orientée sécurité.

Le code généré par une IA est-il sécurisé ?

Pas par défaut. Selon la mesure de Veracode publiée le 24 mars 2026, 55 % seulement des tâches de génération donnent du code sûr, un taux qui a très peu bougé depuis 2025. Le banc d’essai BaxBench trouve qu’environ la moitié des programmes fonctionnellement corrects restent exploitables. Le code généré par IA doit passer une revue de code orientée sécurité, comme le code humain.

Copilot est-il sécurisé ?

L’étude de Pearce et ses collègues, publiée en 2021, trouvait environ 40 % de programmes vulnérables parmi 1 689 programmes générés par Copilot sur 89 scénarios. Une réplication plus récente, menée avec des versions plus récentes de l’outil, mesure 27,25 %. Le progrès est réel, et plus d’un programme sur quatre reste vulnérable dans ces scénarios.

Sources