Anthropic vient de lancer Claude Code Security. Voici pourquoi c’est une excellente nouvelle pour le secteur
Écrit par
0 minutes de lecture
En bref : pas de panique. Le nouveau produit Claude Code Security confirme clairement la direction que prend le secteur. C’est un signal fort qui souligne l’importance de la sécurité des applications. Pour une vue d’ensemble, consultez l’article de mon collègue. Cet article va un peu plus loin dans l’analyse.
Anthropic a annoncé Claude Code Security, une nouvelle fonctionnalité intégrée à Claude Code qui utilise l’IA pour analyser les bases de code, détecter les vulnérabilités et suggérer des correctifs. Si vous suivez de près le secteur de la sécurité, vous avez sans doute déjà vu les réactions. Les actions des entreprises de cybersécurité dégringolent. Des commentateurs annoncent le début de la fin pour les fournisseurs de solutions de sécurité. Un tweet particulièrement viral affirmait qu’Anthropic venait de rafler toute la mise dans le secteur de la sécurité des applications.
Et franchement, je comprends l’enthousiasme. La démo est impressionnante. Opus 4.6 a trouvé plus de 500 vulnérabilités zero-day jusque-là inconnues dans des bases de code open source, y compris des bugs passés inaperçus pendant des décennies, malgré des examens réalisés par des experts. Dans la seule bibliothèque CGIF, Claude a découvert un dépassement de tampon sur le tas en raisonnant sur l’algorithme de compression LZW, un problème que le fuzzing traditionnel guidé par la couverture n’a pas détecté, même avec une couverture de code de 100 %. C’est une avancée majeure.
Mais voilà : les réactions à chaud ne voient pas la forêt derrière les arbres. La réalité est bien plus nuancée et intéressante que « l’IA remplace les outils de sécurité ».
Ce que les réactions ont oublié et ce que l’architecture confirme
Le discours dominant semble être : « Anthropic a créé une IA qui trouve les vulnérabilités, donc les outils de sécurité traditionnels sont obsolètes. » C’est un peu comme dire : « Nous avons créé un excellent détecteur de fumée, donc les pompiers sont obsolètes. »
Détecter les vulnérabilités est important. Mais ce n’est pas le plus difficile.
Je le répète pour ceux qui sont au fond de la salle : détecter les vulnérabilités n’a jamais été le plus difficile.
La vraie difficulté, celle qui empêche les équipes AppSec de dormir, qui génère des retards de plusieurs années et des conversations du type « on s’en occupera au prochain sprint », c’est de les corriger. À grande échelle. Dans des centaines de dépôts. Sans rien casser. Alors que les développeurs livrent de nouvelles fonctionnalités à un rythme effréné. Dans du code qu’ils n’ont pas écrit, avec des bibliothèques qu’ils n’ont pas choisies, dans des langages qu’ils ne maîtrisent pas forcément.
Si vous avez déjà travaillé au sein d’une équipe de sécurité, vous voyez exactement de quoi je parle. Le processus ressemble à ceci :
Un outil de sécurité détecte une vulnérabilité
L’équipe de sécurité analyse le problème et établit ses priorités
L’équipe de sécurité crée un ticket et l’assigne à… un développeur
Le développeur consulte le ticket trois sprints plus tard
Le développeur cherche à comprendre la vulnérabilité et son contexte
Le développeur tente un correctif et introduit peut-être un nouveau problème au passage
L’équipe de sécurité relance une analyse, et le cycle recommence
C’est ce cycle qui épuise les professionnels AppSec et frustre les développeurs. Et améliorer le scan, avec ou sans IA, ne résout pas cette boucle fondamentale. Vous créez toujours du travail qui finit sur le bureau d’un développeur.
Claude Code Security semble être une technologie très prometteuse. Mais c’est un outil d’analyse et de détection : il repère les problèmes et suggère des correctifs. C’est assurément utile, mais la question que devraient se poser tous les ingénieurs seniors et les professionnels AppSec est la suivante : que se passe-t-il après l’analyse ?
L’ironie dont personne ne parle
Voici l’aspect de la discussion qui manque cruellement aux réactions à chaud : les mêmes modèles d’IA qui détectent les vulnérabilités en créent aussi.
Les données à ce sujet sont préoccupantes. BaxBench, un benchmark créé par l’ETH Zurich, UC Berkeley et INSAIT pour évaluer les LLM sur des tâches de programmation backend critiques en matière de sécurité, a révélé que 62 % des solutions générées par les meilleurs modèles sont incorrectes ou contiennent des vulnérabilités. Claude Opus 4.5, le modèle d’Anthropic le plus performant, n’a produit du code à la fois sûr et correct que dans 56 % des cas, sans consignes de sécurité spécifiques.
L’analyse de CodeRabbit révèle une tendance similaire : le code généré par l’IA est 2,74 fois plus susceptible d’introduire des vulnérabilités XSS, 1,91 fois plus susceptible d’introduire des références d’objet non sécurisées et 1,57 fois plus susceptible de présenter des problèmes de sécurité dans l’ensemble, par rapport au code écrit par des humains.
Prenons un instant pour y réfléchir. Les modèles d’IA peuvent détecter 500 vulnérabilités zero-day dans du code open source. Mais ils introduisent aussi des vulnérabilités dans près de la moitié du code qu’ils génèrent. Cette même technologie est à la fois le problème et (en partie) la solution. Ce n’est pas contradictoire : c’est simplement la réalité actuelle. Toute stratégie de sécurité sérieuse doit donc prendre en compte les deux aspects de cette équation.
Vous ne pouvez pas résoudre un problème en vous contentant d’analyser le code si vos outils le créent en même temps. Il vous faut un système qui empêche les vulnérabilités dès leur apparition, détecte celles qui passent entre les mailles du filet, les corrige automatiquement et encadre l’ensemble du processus à l’échelle de l’entreprise. Ce n’est pas un outil d’analyse. C’est une plateforme.
À quoi doit réellement ressembler l’architecture
Voyons comment les outils de sécurité s’intègrent concrètement à un processus de développement moderne : c’est la question de l’architecture qui révèle les enseignements les plus intéressants.
Dans une entreprise type aujourd’hui, votre infrastructure de sécurité ressemble à peu près à ceci :
Le goulot d’étranglement se situe depuis toujours à partir de l’étape 6. C’est là que la vélocité s’effondre. C’est là que le délai moyen de correction (MTTR) passe de quelques heures à plusieurs semaines, puis plusieurs mois. Et avec le développement assisté par l’IA qui entraîne une hausse de 20 % du nombre de PR par auteur (selon le benchmark d’ingénierie 2026 de Cortex), le backlog ne cesse de grossir. Plus de code, c’est plus de bugs. Plus de bugs avec autant (ou moins) d’ingénieurs en sécurité, c’est une file d’attente toujours plus longue.
Mais voici ce que l’annonce d’Anthropic a bien compris, même si les réactions du marché passent à côté : l’IA doit participer au processus de correction, et pas seulement à celui de détection. La percée ne réside pas dans le fait que « l’IA peut détecter les vulnérabilités » : les bons outils d’analyse le font depuis des années. Elle réside dans le fait que « l’IA peut raisonner sur le code suffisamment bien pour corriger les vulnérabilités ». C’est précisément la thèse sur laquelle nous travaillons chez Snyk.
La meilleure sécurité associe l’IA à l’analyse déterministe
Avant de présenter ce que nous avons créé, je tiens à clarifier un point : il ne s’agit pas d’opposer « déterminisme et IA ». Ce cadrage passe complètement à côté du sujet.
Le raisonnement approfondi de l’IA est remarquable dans certains domaines. Les découvertes de vulnérabilités zero-day avec Opus 4.6 en sont la preuve. Détecter un dépassement de tampon sur le tas en comprenant les principes de la compression LZW ? Cela exige une compréhension globale du code qu’aucun outil d’analyse traditionnel ne peut atteindre. C’est aussi le cas des failles complexes dans la logique métier, des contrôles d’accès défaillants et des contournements d’authentification impliquant plusieurs fichiers. L’IA excelle véritablement dans ces domaines.
Mais le raisonnement de l’IA a aussi des limites bien documentées. Elle peut halluciner et signaler avec aplomb une « injection SQL critique » dans une requête paramétrée parfaitement sûre, parce que le modèle a mal interprété le flux de données. Elle peut passer à côté de problèmes évidents parce que son attention se disperse dans une grande base de code ou parce qu’elle a épuisé sa fenêtre de contexte au cours de l’analyse. En sécurité, les deux types d’erreurs coûtent cher : les faux positifs érodent la confiance des développeurs, qui finissent par ignorer les résultats, tandis que les faux négatifs laissent de vraies vulnérabilités en production.
L’analyse déterministe — analyse du flux de données, suivi des flux taintés, exécution symbolique et mise en correspondance avec des bases de vulnérabilités sélectionnées — présente le profil inverse. Elle ne découvrira pas de nouvelles vulnérabilités zero-day. Mais si elle vous signale une injection SQL à la ligne 47 de votre UserController.java, ce résultat repose sur une trace concrète du flux de données, de la source à la destination. Il est reproductible, explicable et vérifiable. Son degré de confiance est élevé, car l’analyse est mécanique plutôt que probabiliste.
Et voici ce que beaucoup ignorent : chez Snyk, ces deux approches ne sont pas cloisonnées. Nos équipes de recherche en sécurité utilisent activement l’IA générative pour découvrir de nouveaux modèles de vulnérabilité. Lorsqu’elles en trouvent un bien réel, elles transforment cette découverte en règle de détection déterministe, déployée sur toute la plateforme. Ainsi, la capacité de découverte créative et novatrice de l’IA est convertie en détections rapides, fiables et peu coûteuses à exécuter, dont tous les clients Snyk bénéficient automatiquement. Vous profitez de l’intelligence de la recherche par IA sans payer le coût de calcul ni prendre le risque d’hallucination à chaque analyse. Le meilleur des deux mondes : l’IA effectue une fois le difficile travail de découverte, puis l’analyse déterministe détecte efficacement le même modèle à grande échelle dans toutes les bases de code que nous protégeons.
La bonne réponse n’est pas de choisir une approche. La bonne réponse consiste à les combiner. Utilisez le raisonnement de l’IA là où il excelle : découverte de nouvelles vulnérabilités, bugs logiques complexes et analyse de plusieurs fichiers. Utilisez l’analyse déterministe là où elle excelle : modèles de vulnérabilité connus, risques liés à la chaîne d’approvisionnement et problèmes de conformité qui exigent une traçabilité vérifiable. Puis faites à nouveau appel à l’IA pour corriger les problèmes, car générer un correctif à partir d’une vulnérabilité bien comprise et hautement fiable est exactement le type de tâche pour lequel les LLM excellent.
Et voici ce qui relie vraiment tous ces éléments : cette approche à plusieurs niveaux n’est pas seulement importante pour la détection. Elle est tout aussi essentielle pour la correction. Lorsque Claude Code Security génère un correctif, il s’agit de code produit par l’IA. Or, nous avons déjà vu ce que cela implique : BaxBench estime le taux de code non sécurisé à 62 %, et Veracode à 45 %. Une IA détecte donc une vulnérabilité, puis génère un correctif qui a lui-même une chance sur deux d’introduire une nouvelle vulnérabilité. Sans validation déterministe qui réanalyse le correctif proposé avant sa fusion, vous jouez à la taupe avec votre propre processus de correction. L’approche à plusieurs niveaux — raisonnement de l’IA, validation déterministe, correction assistée par l’IA, puis nouvelle validation déterministe — n’est pas qu’un joli schéma d’architecture. C’est la seule approche qui tient réellement la route.
Cette architecture fonctionne à l’échelle de l’entreprise. Et c’est ce que nous construisons.
C’est exactement ce que fait Snyk (le meilleur des deux mondes)
Si vous suivez notre travail sur Snyk Studio, vous remarquerez une chose : la vision architecturale qui sous-tend Claude Code Security est remarquablement proche de ce que nous déployons. La différence, c’est que nous nous concentrons sur l’ensemble du processus, pas seulement sur l’analyse, et que nous nous appuyons sur une plateforme qui couvre un périmètre bien plus vaste que la seule analyse du code.
Snyk Studio : la sécurité sans interruption
Snyk Studio intègre directement l’intelligence de sécurité aux outils de programmation par IA que les développeurs utilisent déjà, comme Claude Code, Cursor, Gemini CLI, Cline et bien d’autres. La solution donne vie à deux cas d’usage essentiels :
Sécuriser dès la conception – Lorsqu’un développeur écrit du code avec un assistant de programmation par IA, les directives de garde-fou de Snyk Studio interceptent automatiquement le code non sécurisé avant même que le développeur n’accepte la suggestion. L’assistant IA exécute snyk_code_scan sur le nouveau code et corrige immédiatement tout problème de sécurité détecté. Pas de ticket. Pas de changement de contexte. Pas d’attente de trois sprints. Au vu des données de BaxBench sur la sécurité du code généré par l’IA, ce n’est pas facultatif : c’est indispensable.
Remédiation à grande échelle – Pour traiter le backlog de vulnérabilités existantes, Snyk Studio propose des directives de remédiation telles que /snyk-fix. Elles condensent tout le cycle analyse-triage-correction-vérification en une seule commande :
La couche de détection repose ici sur le moteur d’analyse déterministe de Snyk : il fournit des résultats fiables, sur lesquels la couche de remédiation par IA peut agir sans hésitation. Les correctifs sont générés par le LLM. Vous bénéficiez ainsi des atouts des deux approches.
Au-delà du code : la plateforme complète
La comparaison avec Claude Code Security met clairement en évidence que l’analyse du code source n’est qu’une pièce d’un puzzle bien plus vaste. Tenter de gérer un programme de sécurité d’entreprise avec un scanner à signal unique, aussi intelligent soit-il, revient à essayer de diagnostiquer un patient avec un simple thermomètre.
Imaginez que vous obteniez des résultats issus de plusieurs types d’analyses sur la même plateforme. Votre moteur SAST signale une possible injection SQL dans une méthode de contrôleur. Votre moteur DAST confirme indépendamment que le même point de terminaison est exploitable à l’exécution. Votre moteur SCA détecte que la bibliothèque ORM que vous utilisez présente une CVE connue permettant de contourner son paramétrage dans certains cas limites. Pris individuellement, chacun de ces résultats vous apprend quelque chose. Corrélés sur une même plateforme, ils vous indiquent exactement ce qui se passe, pourquoi et ce qu’il faut corriger en priorité.
C’est ce que nous entendons par AI Security Fabric : il ne s’agit ni d’un outil unique ni d’un seul type d’analyse, mais d’un système adaptatif qui tisse tous les signaux de sécurité à travers l’ensemble de votre chaîne d’approvisionnement logicielle. Snyk corrèle automatiquement les résultats SAST et DAST, en reliant un problème au niveau du code détecté par Snyk Code à une vulnérabilité à l’exécution découverte par Snyk API & Web, afin de localiser précisément la ligne de code responsable d’une faille exploitable. Vous ne pouvez pas obtenir cela en assemblant des outils ponctuels. C’est un avantage architectural qui découle du regroupement, au sein d’une même structure, de l’analyse SAST, SCA, des conteneurs, de l’Infrastructure as Code, du DAST et de la sécurité des API, avec un moteur commun de priorisation et de remédiation.
Vient ensuite la couche entreprise sur laquelle les équipes de sécurité s’appuient réellement pour gérer leurs programmes : des tableaux de bord centralisés qui agrègent les risques de milliers de dépôts, une gouvernance fondée sur des règles définies sous forme de code, l’intégration aux pipelines CI/CD et des rapports qui permettent à votre RSSI de répondre à « Quel est notre niveau d’exposition aux risques ? » et à votre VP Engineering de répondre à « Notre MTTR évolue-t-il dans le bon sens ? », sans devoir assembler les tableaux de bord de six fournisseurs différents. Un scanner de code, même brillant, ne répond pas à ces questions. Une structure de sécurité, oui.
Evo : sécuriser la pile IA elle-même
Il existe aussi une dimension de la sécurité que Claude Code Security n’aborde pas du tout : la sécurisation de votre infrastructure IA.
Evo by Snyk est notre système d’orchestration de la sécurité agentique, conçu spécialement pour le développement natif de l’IA. Il comprend la modélisation des menaces IA, qui génère automatiquement des modèles de menaces dynamiques à partir de votre code et signale les risques tels que l’injection de prompt. Il comprend également le red teaming IA, qui effectue des tests adverses continus sur vos modèles et agents, simule des attaquants adaptatifs et produit des preuves vérifiables d’exploitation. La fonctionnalité AI-SPM (gestion de la posture logicielle) vous indique précisément quels modèles d’IA, jeux de données, frameworks et outils sont utilisés dans votre organisation, y compris l’« IA fantôme » que les équipes de sécurité ne connaissent même pas. Enfin, l’analyse des agents offre une visibilité sur toutes les chaînes d’outils, notamment les serveurs MCP et les Skills dans les environnements de développement, avec des garde-fous en temps réel.
En janvier 2026, notre équipe de recherche a découvert des centaines de Skills malveillants sur ClawHub, lors de la première attaque majeure de la chaîne d’approvisionnement ciblant les écosystèmes d’agents IA. Voilà le type de menace qu’un scanner au niveau du code, aussi sophistiqué soit-il, ne peut tout simplement pas traiter. Il s’agit d’une surface d’attaque entièrement différente, qui nécessite des outils conçus à cet effet.
Une validation, pas une perturbation
Voici franchement ce que signifie, à mes yeux, l’annonce d’aujourd’hui pour le secteur de la sécurité : une validation.
Anthropic, l’une des entreprises d’IA les mieux financées et les plus avancées sur le plan technique au monde, a examiné ce qu’elle pouvait créer avec ses modèles de pointe et a décidé de développer un outil d’analyse de sécurité et de remédiation. Ce n’est pas un hasard. C’est le signe que le secteur s’oriente dans la bonne direction : des workflows de sécurité agentiques, natifs de l’IA et intégrés directement aux outils des développeurs.
C’est la même conviction qui sous-tend Snyk Studio et l’ensemble de la plateforme Snyk. L’objectif n’est pas de créer un meilleur tableau de bord pour trier les vulnérabilités. Il ne s’agit pas non plus de générer des rapports plus élégants ou des scores de gravité plus détaillés. L’objectif est de corriger automatiquement autant de vulnérabilités que possible, le plus près possible de leur apparition, sans interrompre le travail des développeurs.
Tous les bugs ne peuvent pas être corrigés automatiquement : certains nécessitent des changements architecturaux, d’autres exigent un jugement humain sur les compromis liés à la logique métier. Mais la grande majorité des vulnérabilités courantes auxquelles votre équipe est confrontée chaque jour ? Elles ne devraient jamais nécessiter un ticket Jira et trois sprints d’attente.
Voilà toute la vision.
Le fait qu’Anthropic investisse dans ce domaine me confirme que nous avons développé la bonne solution. Ces outils sont complémentaires : Claude Code Security pour la découverte approfondie de nouvelles vulnérabilités zero-day, et la plateforme Snyk pour couvrir l’ensemble du pipeline, de la prévention à la remédiation, grâce à une approche déterministe et à l’IA, dont les entreprises ont besoin pour gérer un programme de sécurité à grande échelle.
La question n’a jamais été « L’IA doit-elle intervenir dans la sécurité ? » La question a toujours été « Comment la mettre en œuvre de manière fiable, complète et adaptée aux entreprises ? » La réponse associe le raisonnement de l’IA et l’analyse déterministe, combinés par couches et intégrés aux outils des développeurs, sur une plateforme qui couvre l’ensemble de la chaîne d’approvisionnement logicielle, y compris la chaîne d’approvisionnement de l’IA elle-même.
Ce que cela signifie pour vous
Si vous êtes ingénieur senior ou spécialiste AppSec, voici mes conseils pratiques :
La chute des valeurs boursières de la cybersécurité est exagérée. Le marché réagit aux gros titres, pas à l’architecture. Détecter les vulnérabilités est nécessaire, mais ne suffit pas à assurer la sécurité. La véritable valeur réside dans la boucle de remédiation, qui exige une intégration poussée à vos outils existants, une détection multicouche digne de confiance et une capacité à fonctionner à l’échelle de l’entreprise.
Essayez Claude Code Security. Vraiment. Si vous maintenez du code open source ou travaillez sur un projet où la découverte de nouvelles vulnérabilités zero-day est importante, la version de recherche est à découvrir. Les résultats obtenus par Opus 4.6 avec GhostScript et CGIF sont véritablement novateurs.
Mais bâtissez votre programme de sécurité sur une plateforme, pas sur un outil ponctuel. Pour vos opérations AppSec quotidiennes, vous avez besoin d’une solution complète qui traite les centaines de vulnérabilités connues, les risques liés à la chaîne d’approvisionnement, les erreurs de configuration des conteneurs, les écarts IaC et la gouvernance des modèles d’IA. Il vous faut une détection déterministe et le raisonnement de l’IA. Il vous faut prévenir dès la conception et automatiser la remédiation à grande échelle. Il vous faut une surveillance de la sécurité, des tableaux de bord et une gouvernance d’entreprise. Et, de plus en plus, vous devez sécuriser les outils d’IA eux-mêmes.
C’est ce que fait Snyk. La plateforme s’appuie sur les assistants de codage IA que vos développeurs utilisent déjà, notamment Claude Code, et les transforme en agents capables de prendre en compte la sécurité, de prévenir les vulnérabilités dès leur apparition et de corriger celles qui existent déjà à grande échelle. Le tout repose sur une plateforme qui couvre le code, les dépendances, les conteneurs, l’infrastructure, les API et la pile IA.
Essayez par vous-même
Le plus simple pour évaluer cette approche est de l’essayer. Snyk Studio est gratuit et sa configuration ne prend que quelques minutes. Voici par où commencer :
Si vous utilisez déjà Claude Code (et vu ce qu’Anthropic vient de lancer, c’est probablement le cas), le guide d’intégration de Claude Code vous explique comment connecter Snyk Studio à votre workflow existant. En cinq minutes environ, vous disposerez de l’analyse déterministe et de la commande de remédiation /snyk-fix dans votre terminal.
Pour comprendre le fonctionnement du système de directives, notamment les garde-fous Secure at Inception et les directives de remédiation, consultez la documentation sur les directives. Elles sont personnalisables : vous pouvez donc les adapter à la pile technologique et à la tolérance au risque propres à votre équipe.
Pour découvrir la plateforme dans son ensemble, consultez la page produit de Snyk Studio, ainsi qu’Evo pour le volet sécurité de l’IA.
L’avenir de l’AppSec ne consiste pas à créer de meilleurs scanners. Il s’agit d’automatiser la boucle entre détection et remédiation, à grande échelle, sans ralentir les développeurs et sur l’ensemble de la surface d’attaque, y compris la pile IA. Le fait qu’Anthropic investisse désormais massivement dans cette voie précise montre que le secteur a compris où se trouve le véritable levier. Avec Snyk, vous pouvez commencer à l’actionner dès aujourd’hui.
E-book
Du shift left à la sécurité dès la conception : l’évolution de l’AppSec à l’ère de l’IA
Découvrez pourquoi la sécurité doit intervenir dès la création du code. Voyez comment Snyk Studio fournit l’intelligence, l’automatisation et les garde-fous nécessaires pour encadrer le développement assisté par l’IA et faire de la protection une composante intrinsèque de l’innovation.