Étude : 81 % des entreprises livrent volontairement du code vulnérable

L’accélération fulgurante du développement logiciel bouleverse les pratiques de sécurité. Une étude internationale menée entre 2023 et 2025 auprès de plus de 4 500 professionnels de la tech – développeurs, responsables de la sécurité applicative (AppSec managers) et directeurs de la sécurité (CISO, pour Chief Information Security Officers) -, dresse un constat inquiétant. En effet, malgré une meilleure conscience des risques, les entreprises continuent de livrer volontairement du code vulnérable.

Réalisée par l’institut Censuswide dans neuf pays, et publiée par Checkmarx, l’enquête met en évidence un fossé grandissant entre l’adoption de nouvelles technologies (IA générative, architectures cloud, chaînes logicielles distribuées) et la capacité réelle des organisations à sécuriser leurs applications.

L’étude identifie ainsi plusieurs tendances majeures : la montée du Shadow AI, la normalisation du « patch later » (corriger après coup plutôt que sécuriser avant la mise en production), l’usage encore limité des outils de sécurité pourtant disponibles et une fracture persistante entre équipes de développement et de sécurité. Plus largement, elle questionne la manière dont l’IA, aujourd’hui génératrice de code, pourrait devenir, demain, un acteur clé de la défense applicative.

L’IA, nouveau moteur du développement… et du risque

L’étude de Censuswide montre à quel point l’intelligence artificielle est déjà au cœur du cycle de développement logiciel. Un tiers des développeurs interrogés reconnaissent que plus de 60 % de leur code est généré par IA. Dans certains cas, cette proportion grimpe même au-delà de 80 % ! L’IA est donc un véritable moteur de production, au-delà d’un simple assistant ponctuel.

Le problème est que cette adoption fulgurante s’est faite sans garde-fous solides, analysent les chercheurs. Moins d’une entreprise sur cinq a défini une liste officielle d’outils autorisés, avec des règles claires sur leur usage. Ainsi, de nombreux développeurs et développeuses se tournent vers des assistants non validés par leur organisation, un phénomène baptisé Shadow AI.

Cette absence de gouvernance crée un angle mort. Les outils d’IA peuvent générer du code fonctionnel, mais bourré de failles de sécurité invisibles à première vue. Faute de traçabilité claire sur la provenance du code, les équipes de sécurité perdent en visibilité et les vulnérabilités s’accumulent dans les projets. Et ce, de manière parfois industrielle, de par la rapidité d’exécution des outils génératifs.

« On livrera quand même » : la culture du patch later

Le constat le plus frappant de l’étude est sans doute celui-ci : 81 % des organisations admettent livrer volontairement du code vulnérable en production. Autrement dit, bon nombre des failles de sécurité ne résultent pas d’accidents, mais des compromis assumés.

La pression business explique largement cette tendance. Les équipes doivent livrer toujours plus vite, répondre aux exigences de nouvelles fonctionnalités et tenir des délais serrés. Dans ce contexte, la sécurité devient une variable d’ajustement. Beaucoup adoptent alors une logique de patch later, qui consiste à mettre le produit en ligne d’abord et à corriger les failles ensuite. Le problème est évident, car les attaquants, eux, n’attendent pas. Aujourd’hui, les outils d’automatisation utilisés par les cybercriminels leur permettent de repérer et d’exploiter certaines failles presque immédiatement après la mise en production.

Un autre chiffre illustre cette dérive. Près d’un tiers des développeurs reconnait avoir déjà espéré que des vulnérabilités passeraient inaperçues une fois le code en production. Pour les chercheurs, il ne s’agit plus seulement d’une stratégie dictée par la vitesse, mais le signe d’une culture de résignation où la sécurité passe après l’urgence de livrer.

Les conséquences sont nombreuses. Les failles exploitées se multiplient, les coûts de correction explosent après incident et, surtout, les utilisateurs et utilisatrices perdent confiance. Au final, les équipes tech se retrouvent piégées dans un dilemme permanent, estime l’étude. D’un côté, la pression pour rester compétitives en livrant vite. De l’autre, une dette technique et sécuritaire qui finit toujours par rattraper l’entreprise.

Les outils de sécurité existent, mais restent sous-utilisés

Malgré la disponibilité d’outils matures, l’étude montre que les entreprises peinent encore à les intégrer efficacement dans leurs pratiques. Moins de la moitié des organisations utilisent réellement des technologies éprouvées comme le DAST (Dynamic Application Security Testing), l’Infrastructure-as-Code scanning ou les tests de sécurité API. Beaucoup disposent donc déjà des « armes » nécessaires, mais ne s’en servent pas pleinement, observent les chercheurs.

Ce décalage crée un faux sentiment de sécurité. Les solutions sont là, mais elles ne sont pas déployées de manière cohérente ni intégrées dans les environnements où travaillent les développeurs au quotidien. Ce manque d’intégration se traduit aussi par une fragmentation des pratiques. Chaque outil remonte ses alertes de son côté, sans donner une vision unifiée des risques. Les équipes croulent alors sous les notifications, incapables de hiérarchiser correctement ce qui doit être corrigé en priorité. Plutôt qu’une aide, la sécurité devient une source de fatigue opérationnelle. On est donc là face à un paradoxe, avec des technologies matures et disponibles, mais une adoption et une orchestration qui font défaut.

Fracture persistante entre développeurs et sécurité

Le rapport met aussi en lumière une tension durable entre les développeurs, chargés de livrer vite, et les équipes sécurité, garantes de la fiabilité des applications. Sur le papier, les développeurs prennent davantage de responsabilités en corrigeant plus de vulnérabilités que les années précédentes. Mais dans la pratique, la collaboration reste inégale.

Les chiffres le montrent bien, avec près d’un cinquième des responsables sécurité (CISO) qui pense que les développeurs corrigent presque toutes les failles. Pourtant, seulement 7 % des managers spécialisés en sécurité applicative (AppSec managers) partagent cet avis. Ce décalage de perception révèle un vrai problème de visibilité. Les dirigeants voient passer moins d’incidents critiques, mais les équipes terrain constatent l’accumulation de failles secondaires, qui finissent par créer une dette technique lourde.

Côté développeurs, la situation n’est pas plus simple. Comme évoqué, la pression des délais les pousse parfois à livrer du code imparfait, en espérant que certaines vulnérabilités passent inaperçues. Ce manque d’alignement se traduit par des problèmes de communication et des priorités mal définies. Faute de tableaux de bord communs et d’outils partagés, les uns et les autres travaillent avec des données différentes. L’étude constate que les dirigeants surestiment ainsi le niveau de sécurité atteint, tandis que les développeurs et AppSec managers doivent composer avec une réalité plus chaotique.

Vers une sécurité applicative pilotée par l’IA

Si l’intelligence artificielle est aujourd’hui vue comme un facteur de risque en générant du code difficile à contrôler, elle pourrait aussi devenir l’une des meilleures armes pour renforcer la sécurité logicielle. Le rapport souligne que la vitesse de production induite par l’IA dépasse les capacités humaines de contrôle. Les revues manuelles de code ne suffisent plus à suivre le rythme.

C’est là qu’une nouvelle étape se dessine, avec l’IA comme défenseur. Déjà, la moitié des organisations utilisent des assistants de sécurité basés sur l’IA, et 40 % prévoient d’y investir dans les prochaines années. Ces outils ne remplacent pas les développeurs et développeuses, mais ils peuvent analyser le code en temps réel, suggérer des corrections ou encore former les équipes directement dans leur environnement de travail.

L’étude révèle que les professionnels se montrent aussi prêts à déléguer certaines missions critiques à l’IA, comme fournir des recommandations de sécurité (39 %), proposer des correctifs que les développeurs valident ensuite (37 %) ou offrir des sessions de formation lorsque des failles sont détectées (39 %), ce qui fluidifierait les processus de sécurité, selon l’étude.

Mais pour que cette promesse devienne réalité, encore faut-il un cadre clair. Tant que l’usage des assistants IA reste anarchique, les risques créés côté développement ne pourront pas être compensés, conclut l’étude. Le véritable enjeu est donc d’encadrer strictement les pratiques d’IA générative, tout en déployant en parallèle des agents automatisés capables de sécuriser la chaîne de production à la même vitesse que les machines qui la nourrissent.