Aujourd’hui, si 34 % des organisations affirment que plus de 60 % de leur code provient de l’IA, et près de 50 % utilisent déjà des assistants de codage dans leurs workflows, seuls 18 % disposent d’une gouvernance formalisée autour de ces usages. Dans le même temps, 81 % des entreprises livrent du code vulnérable, et 98 % ont subi au moins une brèche liée à du code non sécurisé l’an dernier. La production explose, les risques se multiplient, et l’exposition dépasse largement la capacité de remédiation. Claude Code Security répond à ce besoin. Il analyse flux de données, interactions entre composants et logique applicative pour détecter des vulnérabilités subtiles, souvent invisibles aux outils classiques. Sa démarche « reasoning-first » marque un vrai pas vers la sécurité AI-native. Mais il reste limité : supply chain, dépendances IA, environnements d’exécution ne sont pas couverts. Et le risque ne se limite pas au code : packages open-source, conteneurs, configurations d’infrastructure, secrets exposés et modèles de machine learning constituent un écosystème vaste et fragile.
Le biais structurel : on ne peut être juge et partie
La limite la plus profonde de Claude Code Security n'est pas technique mais structurelle. Un modèle qui génère du code et analyse sa propre production partage les mêmes biais, les mêmes angles morts, les mêmes lacunes de contexte. Il ne verra pas ce qu'il n'a pas vu en écrivant. Ce n'est pas une question de capacité, c'est une question de nature. En sécurité, ce principe est fondamental : aucune organisation sérieuse ne s'appuie uniquement sur une auto-vérification. Les audits externes, les pentests, les revues tierces existent précisément pour briser ce biais. Intégrer Claude Code Security dans Claude Code ferme la boucle détection-remédiation au sein du même flux de développement, ce qui est une vraie avancée opérationnelle. Mais cette boucle reste aveugle à ce que le modèle ne sait pas qu'il ne sait pas.À cela s'ajoute un enjeu de conformité : dans les secteurs régulés comme la finance, la santé, les infrastructures critiques, une chaîne d'audit indépendante n'est pas un choix, c'est souvent une exigence légale. Pour les organisations déployant massivement du code IA, un contrôle externe devient une exigence de fiabilité.
Les limites pratiques : contexte, bruit et scalabilité
L'efficacité des LLM en analyse de sécurité dépend fortement du contexte fourni. Lorsqu'un modèle examine un dépôt de code complet sans instructions ciblées, deux problèmes se cumulent : la qualité des résultats se dégrade, et le budget de tokens s'épuise rapidement. C'est un enjeu de scalabilité réel.Les expérimentations menées sur des projets open source illustrent ces limites concrètement. Sur le dépôt n8n, une analyse LLM a identifié huit vulnérabilités potentielles en consommant près de 90 % du contexte disponible : seules deux étaient de vrais positifs. Dans un test distinct, le modèle a redécouvert une faille déjà connue dans FreeRDP et l'a présentée comme un zero-day, sans reconnaître ni mentionner le rapport d'origine. Ces deux cas illustrent le même problème : sans contexte suffisant et sans expertise pour cadrer l'analyse, le ratio signal/bruit devient rapidement un enjeu de coût et de fiabilité et ce, avant même d'envisager le passage à l'échelle dans une entreprise avec des milliers de dépôts.
Ce que ça implique pour les grandes organisations
L’ère du codage IA n’est plus une projection : elle dorénavant tangible et accélérée. Cela exige une sécurité intégrée, continue couvrant tout le cycle de vie logiciel, de l’IDE à la production, avec prévention proactive, remédiation instantanée, visibilité sur la supply chain et suivi centralisé. Cependant, les outils seuls ne suffisent pas : la vraie force réside dans la capacité à orchestrer ces technologies avec des processus clairs, une gouvernance solide et une vision stratégique.Par Frédéric Malo, Ingénieur Solutions, Checkmarx
