- ▸ Ce qui change concrètement pour les RSSI
- ▸ Les faits : ce que publie Anthropic
- ▸ Décryptage : trois questions de droit
- ▸ Qui est concerné par le harness Anthropic
Publié sur GitHub le 22 mai 2026, le dépôt « defending-code-reference-harness » d’Anthropic propose un cadre agentique de découverte de vulnérabilités logicielles. Pour les directions sécurité européennes, l’outil arrive dans un calendrier réglementaire chargé : Cyber Resilience Act en montée en charge, NIS2 transposé depuis la loi du 30 octobre 2024, AI Act en application progressive. Reste à qualifier juridiquement le rapport produit par un agent autonome.
Points clés – Anthropic a publié le 22 mai 2026 sur GitHub un cadre open source intitulé « defending-code-reference-harness ». – Le dépôt couvre quatre fonctions distinctes : modélisation de menaces, scan, triage et patch, plus un harness autonome paramétrable. – La documentation officielle conseille de découper le périmètre en « N distinct input-parsing subsystems worth attacking separately ». – Un rapport produit par un agent autonome ne vaut pas, en l’état du droit français, audit qualifiant PASSI au sens de l’ANSSI. – Le Cyber Resilience Act, applicable au 11 décembre 2027, exige une documentation traçable que l’outil seul ne satisfait pas.
Ce qui change concrètement pour les RSSI
L’arrivée d’un cadre open source de découverte de vulnérabilités assistée par IA modifie le paysage outillage accessible aux entreprises européennes. Dans un contexte où le Cyber Resilience Act impose aux éditeurs de logiciels la documentation continue de leurs failles, l’arrivée d’un harness agentique gratuit abaisse la barrière technique. Les responsables sécurité doivent désormais arbitrer entre adoption rapide pour rattraper leurs obligations, et qualification juridique du résultat produit par un agent autonome. La question opérationnelle n’est plus « pouvons-nous scanner ? », mais « qui répond du diagnostic généré ? ».
Ce qui nous amène à examiner précisément ce que contient le dépôt.
Les faits : ce que publie Anthropic
Le 22 mai 2026, Anthropic a mis en ligne le dépôt public defending-code-reference-harness sur GitHub. Selon la description officielle, le projet regroupe des « Skills for threat modeling, scanning, triage, patching, plus an autonomous scanning harness you can customize ». Quatre fonctions distinctes sont donc proposées : la modélisation de menaces, le scan, le triage et le patching, complétées d’un harness autonome paramétrable.
La documentation guide l’utilisateur dans la découpe du périmètre d’analyse. Un extrait conseille de raisonner par sous-systèmes :
« here are N distinct input-parsing subsystems worth attacking separately » — Documentation officielle defending-code-reference-harness
Cette approche modulaire reflète une logique de revue par surface d’attaque, classique dans l’audit applicatif. Elle laisse à l’utilisateur la responsabilité de définir N — donc d’identifier en amont ses propres surfaces d’exposition.
Pour comprendre — Un harness désigne en sécurité applicative un cadre exécutable qui pilote un programme cible en lui injectant des entrées variées (fuzzing) afin de provoquer des comportements anormaux. Le qualificatif autonomous indique ici que l’enchaînement des décisions — choix des entrées, hiérarchisation des résultats, génération de correctifs — est délégué à un modèle d’IA.
Aucun chiffre de performance n’est communiqué publiquement à ce jour. Anthropic ne précise ni taux de détection, ni taux de faux positifs, ni périmètre des CVE couvertes. Aucune référence à une certification CSPN, à un label ETSI, ou à une conformité OWASP ASVS n’apparaît dans le dépôt à la date de publication. La nature « reference harness » suggère un usage pédagogique et d’amorçage, plutôt qu’un produit prêt pour la production.
Le statut juridique est celui d’un dépôt open source classique, sans engagement contractuel de l’éditeur. Anthropic ne se positionne pas comme prestataire de service de sécurité au sens de la directive NIS2. La responsabilité du résultat reste, en l’état, du côté de l’utilisateur final qui exécute le harness.
Ce qui nous amène au cœur du décryptage juridique.
Décryptage : trois questions de droit
Pour les juristes spécialisés en cybersécurité, le lancement de cet outil pose trois questions distinctes : la qualification du logiciel, la nature du résultat produit, et la chaîne de responsabilité.
Premier point : la qualification du logiciel. Le defending-code-reference-harness combine du code traditionnel et des appels à un modèle de langage. Au sens du Cyber Resilience Act — règlement (UE) 2024/2847 publié au JOUE le 20 novembre 2024 — un « produit comportant des éléments numériques » mis sur le marché ouvre des obligations de documentation, de gestion des vulnérabilités, et de divulgation. Un dépôt GitHub gratuit n’est pas, en première lecture, « mis sur le marché » au sens commercial. Mais le considérant 15 du CRA inclut les composants logiciels distribués via plateformes ouvertes lorsqu’ils sont intégrés à un produit commercial. Une entreprise qui empaquette le harness dans une offre payante en hérite donc les obligations.
Deuxième point : la nature du résultat. Un rapport de vulnérabilités généré par un agent autonome n’a pas la même valeur probante qu’un audit signé par un PASSI — Prestataire d’Audit de la Sécurité des Systèmes d’Information qualifié par l’ANSSI. La référentialité du PASSI repose sur une qualification publique, des procédures auditées, et un auditeur humain identifié. Un livrable agentique ne coche aucune de ces cases. Il reste utile en pratique — mais ne saurait, en l’état, satisfaire à une obligation réglementaire de type audit qualifiant, par exemple celle prévue par le référentiel SecNumCloud.
Troisième point : la chaîne de responsabilité. L’AI Act — règlement (UE) 2024/1689 — classe les systèmes d’IA selon leur usage. Un agent de découverte de vulnérabilités n’est pas listé comme « haut risque » à l’annexe III, qui couvre principalement les usages affectant directement des personnes physiques. La conformité AI Act se concentre donc sur les obligations de transparence applicables aux modèles à usage général : l’utilisateur du harness doit savoir qu’il interagit avec une IA, et le fournisseur du modèle sous-jacent doit publier une documentation technique conforme à l’article 53.
Le point sensible se déplace alors vers la responsabilité civile. Si le harness omet une vulnérabilité critique, qui répond du préjudice ? La directive (UE) 2024/2853 du 23 octobre 2024 sur la responsabilité du fait des produits défectueux étend explicitement la notion de produit aux logiciels. Mais la jurisprudence française sur l’imputation d’un défaut à un agent autonome reste embryonnaire. La doctrine majoritaire — voir les analyses publiées par l’AFDIT au premier trimestre 2026 — converge vers une responsabilité partagée entre l’exploitant et le fournisseur du modèle, sans ligne directrice consolidée.
Ce qui nous amène à identifier les acteurs concrètement concernés.
Qui est concerné par le harness Anthropic
Trois catégories d’acteurs sont directement touchées par l’arrivée du framework.
Les éditeurs de logiciels soumis au CRA. Toute entreprise mettant un produit numérique sur le marché européen doit, d’ici l’application pleine prévue au 11 décembre 2027, documenter ses vulnérabilités et notifier celles activement exploitées sous 24 heures à l’ENISA. L’outil d’Anthropic peut alimenter cette documentation, à condition d’être intégré dans un processus tracé. L’usage brut, sans journalisation des décisions humaines en aval, n’apporte pas de preuve de conformité opposable à un régulateur.
Les entités essentielles et importantes au sens de NIS2. La directive (UE) 2022/2555, transposée en France par la loi du 30 octobre 2024 dite « loi de résilience », couvre environ 15 000 entités françaises selon l’estimation ANSSI publiée à l’automne 2024. Ces structures doivent gérer leurs risques cyber selon un référentiel formalisé. Un outil de découverte automatisée peut compléter le plan de traitement. Mais la responsabilité personnelle des dirigeants prévue à l’article 20 de NIS2 implique que la décision d’exécuter — ou de ne pas exécuter — les recommandations du harness soit prise par une personne identifiée, traçable dans la documentation.
Les prestataires de sécurité offensive. Les sociétés de pentest et les bug bounty hunters opèrent dans un cadre déjà régulé par les articles 323-1 et suivants du Code pénal, relatifs aux atteintes aux systèmes de traitement automatisé de données. L’utilisation d’un agent autonome pour scanner des actifs sans autorisation explicite expose au délit d’accès frauduleux. La doctrine majoritaire considère que l’autorisation contractuelle reste un préalable, que l’outil soit manuel ou agentique. Aucune décision de justice française n’a, à la date de publication, tranché spécifiquement le cas d’un agent IA opérant en autonomie sur le périmètre cyber.
Ce qui nous amène à examiner les arguments contradictoires.
Analyse contradictoire
Deux lectures s’opposent sur l’opportunité réglementaire de tels outils.
Pour. Les défenseurs du framework soulignent que la pénurie d’experts cyber — estimée à plus de 15 000 postes vacants en France selon l’observatoire des métiers de la cybersécurité, édition 2024 — justifie l’industrialisation. Un harness open source démocratise l’accès à des techniques d’audit jusqu’ici réservées aux grands comptes. Pour les TPE/PME désormais ciblées par NIS2 via leur chaîne d’approvisionnement, c’est un levier de mise à niveau rapide. La même logique a accompagné, sans drame, la diffusion d’outils comme nmap ou OpenVAS.
Contre. Les critiques pointent un effet pervers. Un outil de découverte de vulnérabilités est, par construction, à double usage. Mis à disposition publiquement, il abaisse aussi la barrière pour des acteurs offensifs. Le débat n’est pas nouveau — il a rythmé les publications de Metasploit, Burp Suite ou Frida. Mais l’agentivité change l’échelle : un modèle peut désormais enchaîner les phases reconnaissance, exploitation et persistance sans supervision humaine continue. Le CERT-FR n’a, à la date de publication, diffusé aucune position officielle sur les agents autonomes de sécurité. L’ENISA et l’EDPB n’ont pas non plus formalisé de doctrine consolidée.
Ce qui nous amène aux questions juridiques les plus fréquentes.
FAQ
L’utilisation du harness exige-t-elle une déclaration CNIL ?
Non, en tant que tel. La CNIL n’intervient que si le traitement implique des données personnelles. Un scan de code source n’en traite généralement aucune. En revanche, l’usage du modèle d’IA via API peut soulever des questions de transfert si le code analysé contient incidemment des éléments personnels — référence article 28 du RGPD sur la sous-traitance et chapitre V sur les transferts hors UE.
Le harness peut-il valoir audit de conformité CRA ?
Non. Le CRA exige une documentation traçable, reproductible et signée. Un rapport agentique seul ne satisfait pas ce standard : il doit être contre-vérifié par un expert humain identifié, intégré dans un système de management de la sécurité de l’information conforme à ISO/IEC 27001 ou équivalent. Le harness est un outil dans la chaîne, pas un livrable d’audit.
Faut-il signer un contrat spécifique avec Anthropic pour utiliser le harness ?
Pour un usage interne sur des dépôts privés via l’API du modèle, les conditions standard de service du fournisseur s’appliquent. Aucun contrat additionnel n’est requis pour le harness lui-même, distribué sous licence open source. Les entreprises soumises à DORA ou à des exigences contractuelles renforcées doivent toutefois examiner la clause de sous-traitance applicable à l’API.
Calendrier
- 22 mai 2026 — Publication du dépôt defending-code-reference-harness.
- 2 août 2026 — Application des obligations AI Act applicables aux modèles d’IA à usage général.
- 30 octobre 2024 — Loi de résilience transposant NIS2 en droit français.
- 9 décembre 2026 — Application de la directive révisée sur la responsabilité du fait des produits défectueux.
- 11 décembre 2027 — Application pleine et entière du Cyber Resilience Act.
En résumé – Anthropic a publié un cadre open source agentique de découverte de vulnérabilités le 22 mai 2026. – L’outil n’est pas un audit qualifiant : il ne remplace pas un PASSI ni une certification CSPN. – Le CRA, NIS2 et l’AI Act s’articulent autour de la traçabilité de la décision humaine, que le harness doit alimenter sans s’y substituer. – Les éditeurs intégrant le harness à une offre commerciale héritent des obligations du CRA via le considérant 15. – La jurisprudence française sur la responsabilité d’un agent autonome de sécurité reste à construire — aucune décision n’est encore intervenue.
Reste une question ouverte : à mesure que ces harness agentiques se diffusent, le législateur européen choisira-t-il de les requalifier en « systèmes d’IA à haut risque » via une mise à jour de l’annexe III de l’AI Act, ou laissera-t-il la responsabilité civile et le droit pénal commun arbitrer ? La réponse conditionnera l’industrialisation — ou la prudence — des prochaines directions sécurité françaises.
Voir aussi nos analyses régulation : AI Act phase 2 : le calendrier détaillé, Cyber Resilience Act : ce que change le considérant 15 pour l’open source, NIS2 transposée : ce que la loi du 30 octobre 2024 impose aux dirigeants.
