Palo Alto Networks annonce des tests offensifs continus assistés par l’IA : ce que l’on sait et ce qu’il reste à démontrer

Un abonnement annuel pour rechercher et valider des vulnérabilités

Le 22 septembre 2026, Palo Alto Networks a annoncé Unit 42 Continuous Frontier AI Defense, un service proposé sous forme d’abonnement annuel qui, selon l’entreprise, associe des spécialistes de la sécurité à l’intelligence artificielle pour rechercher continuellement des vulnérabilités, vérifier si elles peuvent être exploitées et accélérer leur correction. L’annonce présente une offre de tests offensifs assistés par l’IA, et non une évaluation indépendante de son efficacité.

La fiche du fournisseur décrit des fonctions de découverte continue, de validation de l’exploitabilité et de recommandation de mesures correctives. Elle mentionne également des correctifs virtuels et des modifications de code. Le fait qu’un service puisse générer ou recommander une mesure ne signifie pas, à lui seul, qu’il l’applique en production : les documents disponibles ne précisent pas suffisamment quelles modifications sont exécutées automatiquement et lesquelles nécessitent une validation ou l’approbation du client.

Cette approche peut intéresser les équipes qui doivent examiner régulièrement des systèmes exposés ou complexes. Mais une décision d’achat ne devrait pas reposer uniquement sur le caractère « continu » de la recherche ou sur le recours à des modèles avancés. Le périmètre des actifs concernés, les conditions des tests, la qualité des éléments de preuve fournis et le contrôle exercé sur toute action susceptible de modifier un système ou d’avoir un impact sur celui-ci sont également déterminants.

Un dispositif multimodèle, avec une participation humaine

L’entreprise cite Claude Mythos 5, GPT-5.6-Cyber et des modèles à poids ouverts parmi les systèmes susceptibles d’intervenir. D’après son annonce, un dispositif propriétaire répartit les tâches entre plusieurs modèles ; les spécialistes de la sécurité d’Unit 42 participent également à la prestation. L’idée est de distribuer le travail plutôt que de confier l’ensemble de la recherche à un seul modèle.

L’expression « dispositif multimodèle » désigne une couche qui coordonne l’utilisation de différents modèles, mais ne suffit pas à expliquer comment les décisions sont prises. Pour évaluer le processus, un client potentiel devrait savoir quelles tâches sont attribuées à chaque modèle, comment les résultats redondants sont regroupés, qui examine les découvertes incertaines et quels éléments le service conserve pour justifier l’existence et l’exploitabilité d’une vulnérabilité.

Il faut aussi distinguer la participation humaine d’une supervision effective. La présence de spécialistes ne permet pas de savoir à quel stade ils examinent les résultats, s’ils autorisent chaque test actif ou si leur intervention se limite à certaines phases. Cette différence peut modifier aussi bien le risque opérationnel que la responsabilité des décisions.

Deux chiffres frappants qui restent attribués au fournisseur

Palo Alto Networks affirme que, lors de ses tests dans des environnements complexes, aucun modèle individuel n’a détecté plus de 40 % des vulnérabilités. L’entreprise indique également que Claude Mythos 5 et GPT-5.6-Cyber ont identifié moins de 10 % des mêmes expositions. Ces chiffres suggèrent une possible complémentarité entre les modèles, mais il s’agit de résultats communiqués par l’entreprise, et non d’une mesure indépendante du service.

Le taux inférieur à 40 % ne permet pas d’évaluer la couverture sans savoir ce qui a été comptabilisé comme une vulnérabilité, combien il y en avait au total et comment les environnements ont été sélectionnés. Il ne renseigne pas non plus, à lui seul, sur les faux positifs : un modèle peut signaler peu de problèmes et avoir raison dans chaque cas, ou produire de nombreuses découvertes qui ne seront ensuite pas confirmées. Sans dénominateur ni critères de validation, ce chiffre ne suffit pas pour comparer les modèles ou estimer leurs performances sur l’infrastructure d’une organisation donnée.

De même, un chevauchement inférieur à 10 % ne signifie pas automatiquement que les modèles ont découvert des vulnérabilités distinctes et avérées dans cette proportion. Il faudrait savoir comment une correspondance a été définie, si les doublons ont été supprimés, comment les découvertes décrivant le même défaut ont été regroupées et si les deux modèles ont reçu les mêmes tâches dans les mêmes conditions. La différence entre les « expositions identifiées » et les vulnérabilités confirmées compte également.

L’article d’Axios attribue à des tests propres à Palo Alto Networks le chiffre de couverture inférieur à 40 %, tandis que l’annonce de l’entreprise présente les chiffres de couverture et de chevauchement. Les documents publiés examinés ne fournissent pas de protocole reproductible, d’ensembles de test complets ni de résultats détaillés qui permettraient de vérifier ces pourcentages de manière indépendante. Ils doivent donc être considérés comme des affirmations du fournisseur.

Détecter, exploiter, hiérarchiser et corriger sont des étapes distinctes

Dans un test offensif, rechercher un indice de vulnérabilité et vérifier qu’il peut être exploité sont deux étapes différentes. Un scanner peut signaler une configuration ou un composant suspect ; une validation active vise à déterminer si la faiblesse a des conséquences pratiques. Cette seconde étape peut apporter des éléments plus concrets, mais elle exige des limites claires : certains tests peuvent modifier des données, dégrader un service ou interagir avec des systèmes tiers si le périmètre n’est pas bien défini.

La priorisation n’équivaut pas non plus à la remédiation. Classer les découvertes aide à décider lesquelles examiner en premier, mais ne réduit pas le risque à lui seul. Une recommandation, un correctif virtuel ou une proposition de modification du code sont des réponses possibles ; leur présence dans la fiche du service ne prouve pas qu’ils ont été installés ni qu’ils conviennent à chaque environnement. L’application effective d’une correction exige des tests de compatibilité, une gestion du changement et la confirmation que le problème est résolu sans en introduire d’autres.

Il est utile de distinguer ces activités de la classification et de la réponse aux alertes. Les opérations de détection et de réponse analysent généralement des signaux d’activité et prennent en charge les incidents potentiels ; les tests offensifs autorisés recherchent des faiblesses au moyen d’actions convenues à l’avance. Ces domaines peuvent être liés, mais leurs objectifs, leurs autorisations et leurs risques ne sont pas interchangeables.

Questions pratiques avant d’évaluer le service

Avant de souscrire à un service de tests continus, les responsables de la sécurité devraient demander un périmètre contractuel et opérationnel aussi précis que celui qu’ils exigeraient pour un test d’intrusion. La fréquence d’exécution ne remplace pas l’autorisation : les actifs concernés, les horaires, les systèmes exclus, les dépendances vis-à-vis de tiers et les contacts à joindre pour interrompre un test doivent être clairement définis.

Il est également raisonnable de demander des exemples de rapports expurgés de leurs données sensibles, les critères de confirmation des découvertes, les taux de faux positifs et un moyen de reproduire les tests dans un environnement contrôlé. Si le fournisseur ne peut pas communiquer toutes ces informations, il devrait expliquer quelles données il peut fournir, sous quelles conditions et quelles limites empêchent un audit externe.

Concernant l’usage des modèles, il faut demander quelles données du client sont transmises, où elles sont traitées, combien de temps elles sont conservées et si elles servent à entraîner ou à ajuster des modèles. Les documents consultés décrivent les modèles et les fonctions annoncés, mais ne répondent pas ici à toutes ces questions. Connaître le nom des modèles ne suffit pas non plus : leur configuration, les outils auxquels ils sont connectés et les règles d’autorisation influent sur ce que le système peut faire.

Les correctifs appellent leurs propres questions : s’agit-il d’une recommandation, d’un correctif virtuel ou d’une modification du code ? Qui vérifie la compatibilité et les régressions ? Quelle approbation est nécessaire pour l’appliquer ? Comment revenir en arrière si la modification provoque des problèmes ? Des réponses concrètes permettent de distinguer l’analyse automatisée de la gestion réelle des changements.

Ce qu’il est possible de conclure à ce stade

L’annonce établit que Palo Alto Networks propose un service annuel d’Unit 42 associant des spécialistes, un dispositif multimodèle et des fonctions de découverte, de validation et de recommandation de corrections. Elle indique également les modèles cités par l’entreprise et les chiffres de performance qu’elle attribue à ses tests. La couverture médiatique apporte des éléments de contexte sur l’annonce, mais ne transforme pas ces résultats en évaluation indépendante.

Un article de recherche disponible sur arXiv étudie l’évaluation de modèles de langage pour la cybersécurité au moyen de tests portant sur les vulnérabilités. Il est pertinent pour comprendre l’importance de concevoir des benchmarks, mais il n’évalue pas ce service et ne confirme pas les chiffres communiqués par Palo Alto Networks. Il ne faut donc pas le présenter comme une validation du produit.

La conclusion prudente n’est pas que le service est inutile ni que ses affirmations sont fausses : c’est que les informations publiques examinées ne permettent pas de mesurer de façon indépendante sa couverture, sa précision ou sa sécurité opérationnelle. Pour prendre une décision, chaque organisation a besoin d’éléments adaptés à son environnement, de limites d’autorisation explicites et d’explications claires sur l’intervention humaine et l’application des changements. Tant que des résultats auditables ou des évaluations externes portant spécifiquement sur le service ne seront pas publiés, les chiffres doivent rester attribués à l’entreprise.

Poursuivre l’exploration

Corrections et transparence

Si vous repérez une information incorrecte ou obsolète, envoyez-nous la page et la source à vérifier.