Les assistants de codage basés sur l'IA génèrent désormais du code syntaxiquement correct dans plus de 95 % des cas. Pourtant, seulement 55 % du code produit est réellement sécurisé. Cette statistique met en lumière une préoccupation croissante pour les entreprises : si l'IA transforme rapidement le développement logiciel, elle accélère aussi l'apparition d'erreurs et de risques de sécurité. Le vrai défi pour les organisations n'est pas de trouver le meilleur modèle d'IA, mais de déterminer comment utiliser ces modèles de manière efficace et sûre à grande échelle, sans augmenter significativement les risques de vulnérabilités. La solution réside dans ce qu'on appelle un « delivery harness » — un cadre qui combine supervision humaine, gouvernance basée sur les risques et contrôles qualité automatisés à chaque étape du développement. L'avantage concurrentiel ne viendra pas simplement du choix du meilleur modèle, mais de la compréhension de la manière d'encadrer son utilisation au sein d'une organisation. Depuis 2025, Veracode mesure la sécurité du code généré par les grands modèles de langage à l'aide d'un benchmark constant de 80 tâches de programmation. La mise à jour de mars 2026, qui a évalué plus de 150 modèles, a révélé que seulement 55 % du code généré était sécurisé. Dans les 45 % de cas restants, les modèles ont introduit des vulnérabilités issues des 10 risques principaux de l'OWASP, une liste des risques de sécurité les plus critiques pour les applications web. Si la correction syntaxique a progressé pour dépasser les 95 %, les performances en matière de sécurité sont restées largement inchangées au cours des deux dernières années. Même les derniers modèles, comme GPT-5.1, GPT-5.2, Gemini 3, Claude 4.5 et 4.6, se situent dans une fourchette de 55 % à 60 % de code sécurisé. Seuls les modèles de raisonnement d'OpenAI, comme GPT-5.1 et GPT-5.2, obtiennent des résultats significativement meilleurs, atteignant 70 à 72 %. Cependant, ces modèles laissent encore environ un tiers du code vulnérable. La principale conclusion est que, même si les modèles d'IA s'améliorent, les organisations ne peuvent pas supposer que les avancées futures rendront les mesures de sécurité superflues. Les résultats du benchmark deviennent encore plus parlants lorsqu'on examine des types spécifiques de vulnérabilités. Les modèles performent bien contre les injections SQL et les problèmes de cryptographie, avec des taux de réussite de 82 % et 86 % respectivement, car ces risques sont généralement plus faciles à sécuriser. En revanche, leurs performances chutent considérablement face aux attaques par cross-site scripting (15 %) et aux injections de logs (13 %). Ces types de vulnérabilités nécessitent une compréhension approfondie de la manière dont les données contrôlées par l'utilisateur circulent dans une application, un contexte que les modèles d'IA ne maîtrisent pas. Les performances varient également selon le langage de programmation, avec Python à 62 % de code sécurisé, JavaScript à 57 %, et Java seulement à 29 %. Cette faible performance en Java s'explique en partie par la grande quantité de code vulnérable existant dans ses données d'entraînement. Les frameworks modernes, comme Doctrine pour Symfony, Twig pour l'échappement automatique des sorties, et Angular pour la sanitisation des templates, réduisent les risques, mais ces protections disparaissent lorsque le code généré par l'IA utilise du SQL brut ou contourne les mesures de sécurité intégrées. Le problème sous-jacent est que les modèles d'IA sont entraînés sur du code public qui contient souvent des vulnérabilités non corrigées, qu'ils reproduisent ensuite. Le défi pour les organisations n'est plus simplement de trouver le modèle d'IA le plus sûr. Il s'agit plutôt de mettre en place un « delivery harness » — un cadre complet qui inclut des règles de gouvernance, une supervision humaine et des contrôles automatisés tout au long du processus de développement logiciel. Une règle clé est que, même si l'IA génère 100 % du code, 100 % de ce code doit être compris et validé par un humain. Les développeurs restent pleinement responsables de chaque partie du code qu'ils livrent. Des experts techniques seniors effectuent des revues systématiques, et l'acceptation contractuelle n'est jamais déléguée à un agent d'IA. En cas d'incertitude, le problème est escaladé plutôt que résolu par des interactions non vérifiées avec l'IA. Cette approche complète, plutôt que remplace, l'expertise des ingénieurs expérimentés. Identifier une concaténation SQL non sécurisée ou l'absence d'échappement des sorties reste une compétence cruciale, comme le montrent les benchmarks actuels. Les droits d'accès, les données sensibles de l'entreprise, les modèles de données et les composants architecturaux essentiels sont classés comme des « zones rouges », où le code généré par l'IA est soit interdit, soit soumis à une validation renforcée avant son implémentation. Les domaines à moindre risque peuvent bénéficier de la rapidité du développement assisté par l'IA. Cet équilibre délibéré permet une vélocité de développement élevée sans compromettre la sécurité. Les contrôles qualité sont intégrés tout au long du cycle de livraison, et non pas seulement à la fin. Les spécifications et critères d'acceptation sont revus avant que la génération ne commence, et les informations sensibles sont filtrées avant l'envoi des requêtes. La couverture des tests doit atteindre au moins 80 %, et chaque artefact généré est entièrement traçable, y compris le modèle qui l'a produit. La gouvernance doit également être mise en œuvre techniquement. Les équipes de développement sont équipées d'agents spécialisés dans la génération de code, les tests unitaires, les tests de bout en bout et l'examen des pull requests. Avant qu'un humain ne prenne la décision finale, l'agent d'examen des merge requests évalue chaque proposition en fonction de la sécurité, des performances, de la maintenabilité et des bonnes pratiques d'ingénierie. Les compétences et règles sont intégrées directement dans le contexte de génération, garantissant que le modèle produit par défaut du code sécurisé et accessible. Des hooks exécutés avant l'envoi des requêtes et après la génération bloquent automatiquement les résultats qui ne répondent pas aux contrôles requis. Ces capacités créent une boucle d'ingénierie déterministe : générer le code, exécuter les tests, effectuer une analyse statique, appliquer des linters, corriger les erreurs et répéter jusqu'à ce que la conformité soit atteinte. La protection finale automatisée est le pipeline CI/CD. Bien que les hooks locaux puissent être contournés, le pipeline, lui, ne l'est pas. En intégrant des tests de sécurité des applications statiques (Static Application Security Testing ou SAST), des analyses de dépendances, des tests automatisés et des seuils de couverture minimale comme conditions obligatoires pour les merge requests et les déploiements, aucun code ne peut atteindre la production sans passer tous les contrôles requis, quel que soit l'agent ou le modèle qui l'a généré. Cette approche en couches garantit que les contrôles de sécurité sont appliqués tout au long du processus de livraison et restent irremplaçables. Les experts humains conservent la responsabilité ultime. L'IA accélère tout, y compris les échecs. Si la vitesse de développement est multipliée par trois, une vulnérabilité non maîtrisée peut aussi se propager trois fois plus vite. Adopter le développement assisté par l'IA de manière sûre et à grande échelle exige des personnes responsables, des zones de risque clairement définies, des contrôles qualité déterministes, un pipeline CI/CD sécurisé et une traçabilité complète. En d'autres termes, cela nécessite un « delivery harness ». C'est cette approche disciplinée qui transforme le développement piloté par l'IA — passant simplement d'une livraison logicielle plus rapide — en une source durable de valeur pour l'entreprise.