Code généré par IA et sécurité : le vrai signal derrière les chiffres de Checkmarx

Le risque du code généré par IA ne se résume pas à une sortie qui contiendrait une faille. Le problème décrit par Checkmarx est aussi organisationnel : l’IA s’est installée dans les environnements de développement, tandis que la sécurité reste souvent vérifiée plus tard. Pour les équipes, le signal utile est donc moins « l’IA produit-elle du code vulnérable ? » que « à quel moment et avec quelles preuves une équipe détecte-t-elle puis traite une faiblesse ? ».

Le communiqué de Checkmarx sur son rapport 2026 rapporte que 96 % des développeurs interrogés disposent d’outils d’IA dans leur IDE, mais que 18 % seulement disent appliquer la sécurité en continu pendant l’écriture du code. Ces chiffres décrivent des réponses à une enquête, pas une inspection indépendante des dépôts ni une mesure directe du taux de vulnérabilités produites par un modèle.

Le point de friction apparaît après la génération

L’enquête a été menée par Censuswide pour Checkmarx du 10 au 30 mars 2026 auprès de 2 350 développeurs, responsables AppSec et CISOs dans 14 pays. Le communiqué indique que plus de 80 % des développeurs ne mettent pas en œuvre la sécurité de façon continue pendant l’écriture : les contrôles interviennent à des étapes définies, ou après l’apparition d’un incident. Cela ne signifie pas que chaque équipe suit le même parcours, mais cela rend visible une question de séquencement : une vérification tardive doit examiner un changement déjà produit, intégré et parfois combiné à d’autres.

Le rapport associe aussi le niveau d’usage de l’IA à des réponses différentes sur la livraison de vulnérabilités connues. Dans les organisations où 81 à 100 % du code de production est généré par IA, 47 % déclarent livrer des vulnérabilités connues, contre 14 % dans celles où cette part est de 1 à 20 %. Checkmarx présente l’écart comme une probabilité presque trois fois plus élevée. Il faut toutefois garder la portée exacte du résultat : l’enquête rapporte une association entre groupes, elle ne démontre pas que l’IA, à elle seule, a causé ces vulnérabilités.

Un autre chiffre déplace l’attention de la seule génération vers les arbitrages de livraison : 75 % des organisations interrogées déclarent déployer sciemment du code vulnérable à un moment donné. Le communiqué cite les échéances, la complexité et l’espoir que les failles ne soient pas découvertes parmi les facteurs évoqués. Ce constat ne permet pas de savoir quelle part de ces déploiements concerne du code généré par IA. Il rappelle plutôt qu’un outil de détection ne suffit pas si une équipe n’a pas de règle claire pour bloquer, corriger ou accepter un risque.

Lire les résultats sans leur faire dire trop

Ces données proviennent d’un rapport commandé par un éditeur de sécurité applicative. Elles sont utiles pour formuler des questions opérationnelles, mais elles ne remplacent pas une mesure locale. Pour situer cette question parmi les contrôles d’un changement assisté par IA, voir aussi notre guide sur les preuves à réunir avant le merge : il traite la validation d’un correctif, plutôt que la prévalence des risques dans l’enquête de Checkmarx.

Une vérification après coup ne transforme pas automatiquement le code

Un second communiqué de Checkmarx, daté du 14 juillet 2026, rapporte une étude commandée par l’entreprise à The Weather Report. Selon cette étude, les modèles évalués produisaient du code fonctionnel dans 83 à 95 % des cas, mais du code à la fois sécurisé et fonctionnel dans 24 à 36 % des cas. Après une revue de sécurité a posteriori, la proportion indiquée atteignait 47 à 56 %. Ces résultats sont attribués à cette étude commandée par Checkmarx ; le communiqué ne donne pas, dans les éléments présentés ici, le détail du jeu de tâches ou du protocole nécessaire pour transposer ces pourcentages à un dépôt particulier.

Le contraste entre « fonctionnel » et « sécurisé et fonctionnel » est important pour une revue de code : le fait qu’un changement passe un test fonctionnel ne répond pas, à lui seul, à la question de sa sécurité. Inversement, la hausse rapportée après revue ne dit pas que toute vérification a le même effet, ni que le code est alors exempt de vulnérabilités. Il faut traiter ces nombres comme un résultat limité au cadre de l’étude, et non comme une promesse de correction automatique.

Traduire le signal en points de contrôle d’équipe

La conséquence pratique n’est pas d’ajouter une étape de validation indifférenciée à chaque changement. Une équipe peut plutôt expliciter où se trouvent ses contrôles, qui traite un résultat et ce qui se passe lorsqu’une échéance entre en conflit avec une alerte. La séquence ci-dessous est une proposition de cadrage à adapter au dépôt ; ce n’est pas un protocole testé par Checkmarx ni un résultat mesuré par l’enquête.

1. Avant la modification : repérer les composants sensibles concernés et décider quels types de changements nécessitent une revue de sécurité renforcée.
2. Pendant l’écriture : vérifier si les contrôles disponibles peuvent intervenir au plus près du changement, plutôt que de supposer qu’une revue finale absorbera tout le risque.
3. Avant le merge : examiner les résultats pertinents, distinguer une alerte à investiguer d’un défaut confirmé et documenter la décision prise.
4. À la livraison : rendre explicite l’autorité qui peut accepter, reporter ou bloquer un risque, surtout lorsque la pression de délai est forte.
5. Après coup : utiliser les incidents et les faux positifs observés pour ajuster les règles, sans confondre l’absence d’alerte et la preuve d’absence de vulnérabilité.

Imaginez, à titre hypothétique, une équipe qui reçoit une proposition de modification produite avec une aide IA juste avant une échéance. Une analyse signale un problème potentiel, mais le changement passe les tests fonctionnels. Sans règle préalable, la discussion risque de porter surtout sur le calendrier. Avec un circuit défini, l’équipe peut identifier la personne responsable de l’arbitrage, demander une vérification adaptée et consigner pourquoi elle bloque ou accepte le changement. Ce scénario n’est pas un témoignage réel : il illustre le type de décision organisationnelle que les chiffres sur les déploiements connus invitent à rendre visible.

La priorité : fermer l’écart entre détection et décision

Le rapport 2026 indique également que 22 % des organisations disposent d’une politique formelle de gouvernance de l’IA, contre 18 % un an auparavant ; Checkmarx rapporte donc que la majorité n’en déclare pas. Ce chiffre ne mesure pas à lui seul la qualité d’une politique. Pour une équipe de développement, l’important est qu’un cadre utile réponde à des questions concrètes : quels outils sont autorisés, quelles données peuvent leur être transmises, quels contrôles s’appliquent au code proposé et qui tranche lorsqu’un risque demeure.

Checkmarx présente par ailleurs, dans son annonce du 14 juillet, Developer Assist comme une boucle de détection, de correction et de vérification avant soumission, et indique que ses offres Developer Assist, Triage Assist et Remediation Assist sont alors généralement disponibles avec Checkmarx One. C’est une description de produit par son éditeur, pas une validation indépendante de son efficacité. L’annonce précise aussi que les développeurs examinent et fusionnent les corrections proposées. Pour une équipe qui évalue ce type d’automatisation, la question demeure donc : quelles preuves permettent de vérifier le correctif, et quelle décision reste sous contrôle humain ?

Les chiffres de Checkmarx ne permettent pas de conclure que l’IA rend nécessairement un dépôt moins sûr. Ils montrent plutôt, dans les réponses recueillies, que l’adoption des outils et l’intégration continue de la sécurité ne progressent pas au même rythme, tandis que des organisations disent parfois livrer des vulnérabilités connues. La décision technique consiste alors à rapprocher détection, correction et arbitrage du flux de développement, puis à vérifier si ce dispositif fonctionne réellement dans son propre contexte.

Sources : Checkmarx Unveils Self-Healing Application Security in Assist Agent Family.