Sécurité du code généré par IA : 56 % de réussite, et ce que vous pouvez vérifier

Un logiciel qui se lance et qui rend le service demandé peut avoir une porte ouverte. Veracode mesure la sécurité du code généré par les grands modèles depuis deux ans, et le taux n'a pas bougé. Ce que le chiffre recouvre, et les quatre exigences à poser avant la mise en ligne.

La sécurité du code généré par IA plafonne à 56 % de réussite aux tests, contre 55 % un an plus tôt, selon le rapport 2026 GenAI Code Security publié par Veracode le 28 juillet 2026. Le même rapport indique que 44 % des tâches de génération produisent une vulnérabilité.

Ce que le chiffre recouvre

La correction de la syntaxe est, elle, un problème résolu : les modèles écrivent du code qui compile. Veracode soumet des tâches de génération à des modèles, puis fait passer au résultat des tests de sécurité. Un code peut compiler, s'exécuter, rendre le service demandé, et échouer à ce test. Les taux par catégorie de modèle se tiennent dans un mouchoir de poche : 51 % pour les modèles spécialisés dans le code, 52 % pour les polyvalents, 56 % pour ceux qui raisonnent, 53 % pour les grands modèles contre 51 % pour les moyens et les petits. Choisir un modèle plus gros ne règle donc pas la question, et le meilleur modèle testé s'arrête à 68 %. La stagnation d'un point en un an est le fait marquant du rapport : les modèles ont progressé sur presque tout, sauf sur ce point.

Les failles où le taux s'effondre

La moyenne cache un écart brutal selon la classe de faille. Sur l'injection SQL, cette attaque qui détourne une requête pour lire toute une base, le code généré passe le test dans 83 % des cas, et sur les algorithmes de cryptographie dans 87 %. Sur le cross-site scripting, cette faille qui laisse un visiteur injecter du contenu exécuté chez les autres visiteurs, le taux tombe à 15 %. Sur l'injection dans les journaux d'événements, à 12 %. Ce sont les failles les plus banales du web, celles qu'un attaquant essaie en premier, et ce sont celles que la génération rate le plus souvent.

Ce qu'un concurrent fait mieux que nous ici

Lovable a annoncé le 5 août 2026 que chaque application publiée sur sa plateforme reçoit une page de sécurité dédiée, hébergée à l'adresse de l'application, qui affiche les contrôles de sécurité actifs. La question « mon application est-elle sûre » devient consultable au lieu de rester une intuition. C'est un aveu utile : la sécurité était jusque-là invisible pour celui qui commande le logiciel. Maestro ne propose pas d'équivalent aujourd'hui, et c'est une exigence à poser à tout outil, le nôtre compris.

Ce que la vérification automatique attrape, et ce qu'elle rate

Chez Maestro, l'agent Félix vérifie chaque étape construite, et les tests s'écrivent avant le code. Ces tests portent sur le comportement attendu : le devis se crée, le total s'arrondit comme prévu, l'utilisateur sans droit ne voit pas la page. Ils ne remplacent pas une analyse de sécurité, et nous n'écrirons pas le contraire. Un logiciel dont tous les tests passent peut encore laisser passer un contenu injecté dans un champ de commentaire, parce qu'aucun test fonctionnel ne pense à coller du code dans une zone de texte. Le contrôle fonctionnel et le contrôle de sécurité sont deux métiers, et l'un ne dispense pas de l'autre.

Les quatre exigences à poser

Une tribune de Yves Wattel (Delinea) publiée par le Journal du Net le 12 août 2026 liste quatre parades contre les usages offensifs de la génération de code : le moindre privilège, la rotation des identifiants, les accès temporaires et la surveillance des comportements. Traduites pour un dirigeant, elles donnent quatre phrases à poser à qui construit votre logiciel. Chaque compte n'accède qu'à ce dont il a besoin, y compris le vôtre. Les clés et les mots de passe se changent, et ce changement est prévu quelque part plutôt que laissé à la mémoire d'une personne. Les accès accordés à un prestataire expirent d'eux-mêmes. Une trace existe de ce qui a été consulté et par qui. Demander ces quatre choses au départ ne coûte rien, les rajouter après la mise en ligne coûte un chantier.

En pratique, avant de mettre en ligne

Commencez par le contrôle le plus court : votre base de données est-elle atteignable depuis l'extérieur, et l'a-t-elle été depuis le premier jour. Puis relisez la liste des champs où un visiteur écrit du texte libre, commentaires, noms, messages, et demandez ce qui se passe si quelqu'un y colle autre chose que du texte. Ces deux vérifications tiennent dans une soirée et couvrent les deux catégories où le taux mesuré par Veracode est le plus bas. Le reste appartient au chapitre des pièges du développement par IA, et à celui, désormais daté, des comptes que votre logiciel doit rendre.