Claude Opus 5.5 et l’injection de prompts : ce que démontre le test de sécurité et ce qu’il reste à savoir

L’affirmation et les éléments disponibles

Anthropic présente Claude Opus 5.5 comme un modèle qui, dans un benchmark de Gray Swan, est à égalité avec Fable 5.1 pour le taux de réussite le plus faible face aux injections de prompts parmi les modèles testés. Cette affirmation intéresse les équipes qui connectent des modèles à des documents, à des outils ou à d’autres sources susceptibles de contenir des instructions malveillantes. Elle doit toutefois être comprise comme la déclaration du fabricant au sujet d’une évaluation précise, et non comme la preuve que le modèle est sûr dans tous les environnements.

Les sources vérifiées fournies permettent de retrouver cette affirmation sur la page de présentation d’Opus 5.5, mais elles ne comprennent ni le rapport méthodologique de Gray Swan ni les résultats détaillés. Elles ne précisent pas le taux numérique, le nombre total de modèles, leurs versions, l’ensemble des attaques, les consignes d’évaluation ou les critères permettant de considérer qu’une attaque a réussi. Elles ne permettent pas non plus de déterminer si tous les modèles ont été comparés dans des conditions identiques.

Il est donc possible de rapporter ce qu’affirme Anthropic, mais pas de reproduire le test ni d’en évaluer indépendamment la solidité à partir de ces seuls documents. Le fait que ces détails ne figurent pas dans les éléments disponibles ne prouve pas que Gray Swan ne les a pas publiés ailleurs : cela signifie simplement qu’ils ne peuvent pas être confirmés à partir des sources vérifiées ici.

Cette distinction est importante : une bonne position dans un benchmark peut constituer un signal utile pour orienter une évaluation, mais elle ne remplace pas les tests portant sur l’application concrète. Le risque dépend du modèle, mais aussi de la manière dont le système obtient les informations, interprète les instructions et exécute des actions.

Que signifie un taux de réussite face aux injections ?

L’injection de prompts est une catégorie d’attaques dans laquelle un texte malveillant cherche à modifier le comportement attendu du modèle. Elle peut apparaître dans une consigne rédigée par l’utilisateur ou dans un contenu récupéré par le système, par exemple une page Web, un fichier ou un message. Dans le cas d’une injection indirecte, l’utilisateur n’a parfois pas écrit l’attaque : le modèle la découvre dans le contenu qu’il doit traiter.

Un taux de réussite résume généralement le nombre de tentatives d’attaque qui atteignent l’objectif défini par l’évaluation, rapporté à l’ensemble des tentatives prises en compte. Sans connaître la définition opérationnelle, cette description générale ne suffit pas à interpréter un résultat précis. Un protocole pourrait considérer comme une réussite le fait que le modèle répète une instruction interdite, révèle une donnée de test, utilise un outil de manière non autorisée ou cesse simplement d’effectuer la tâche initiale. Ces comportements ne sont pas équivalents et il ne faut pas supposer qu’ils faisaient partie du benchmark de Gray Swan sans documentation.

Il faut également connaître le dénominateur : quelles attaques ont été incluses, combien de fois chacune a été exécutée, avec quelle configuration et selon quelle méthode les résultats ont été agrégés. Un taux faible obtenu sur un ensemble restreint peut décrire correctement cet ensemble sans pour autant représenter d’autres attaques, des applications équipées d’outils ou des langues qui n’ont pas été testées. Les sources fournies ne permettent pas de confirmer ces paramètres pour la comparaison mentionnée.

Il faut aussi savoir comment les échecs ordinaires sont comptabilisés. Un modèle peut résister à une instruction malveillante tout en refusant une demande légitime ou en échouant à accomplir la tâche. Pour évaluer un produit, il est utile de mesurer séparément la résistance à l’attaque, le taux de faux positifs et la qualité d’exécution de la tâche. Les informations disponibles ne précisent pas si le benchmark de Gray Swan publie ces indicateurs séparément.

Quels modèles et quelles conditions sont inclus dans la comparaison ?

La formulation attribuée à Anthropic désigne Opus 5.5 et Fable 5.1 comme ex æquo en tête parmi les modèles testés. Les éléments disponibles n’indiquent pas combien de modèles composaient le groupe et ne donnent pas la liste des autres versions. Ils ne précisent pas non plus si les modèles ont été évalués sans défenses supplémentaires, avec des instructions système particulières ou au sein de systèmes complets intégrant des filtres et des outils.

Ces différences changent le sens d’une comparaison. Évaluer un modèle isolément n’est pas la même chose que tester une application comprenant la récupération de documents, le routage, la modération et des appels à des outils. Si chaque participant est exécuté avec des défenses ou des réglages différents, le résultat pourrait refléter l’ensemble des configurations plutôt que le modèle seul. Les sources fournies ne permettent pas de dire laquelle de ces méthodes Gray Swan a employée.

La source d’Anthropic permet de lui attribuer précisément l’affirmation. La fiche système officielle d’Opus 5.5 est identifiée comme un document consacré au modèle et à ses évaluations de sécurité, mais l’extrait disponible ne présente aucun résultat spécifique de Gray Swan et ne décrit pas le protocole d’injection. La page générale consacrée aux fiches système explique que ces documents portent sur les capacités, les évaluations de sécurité et les décisions de déploiement ; ce cadre institutionnel ne remplace pas les données propres au test.

Ce que l’on peut conclure — et ce que l’on ne peut pas conclure

La conclusion la plus limitée et la plus défendable est qu’Anthropic attribue à Opus 5.5 une égalité avec Fable 5.1 pour le taux de réussite le plus faible face aux injections dans l’évaluation de Gray Swan qu’elle mentionne. Si ce résultat est confirmé par le rapport primaire et si les conditions sont pertinentes, il constituera un élément sur le comportement observé dans ce benchmark. À lui seul, il ne permet pas d’affirmer qu’Opus 5.5 est immunisé contre les injections de prompts, plus sûr que tous les modèles ou adapté à toutes les applications.

Il ne permet pas non plus d’extrapoler directement à des attaques menées dans d’autres langues ou au moyen d’autres formats de fichiers, de chaînes d’outils ou de sources de données. Un test peut être utile pour une catégorie de tentatives sans en couvrir d’autres. En l’absence de méthodologie, il est impossible de savoir si des instructions indirectes intégrées à des documents ont été incluses, si le modèle devait utiliser des outils ou si une action externe était considérée comme une réussite. Ce sont des questions ouvertes, et non des lacunes que l’on peut attribuer avec certitude au benchmark.

Un classement relatif ne renseigne pas automatiquement sur le niveau absolu de risque. Le fait que deux modèles partagent le meilleur taux parmi les participants ne révèle ni le taux lui-même, ni l’écart avec les autres, ni la significativité statistique des différences. Dans le cas présent, aucun chiffre n’est fourni pour effectuer ces calculs.

Le benchmark ne remplace pas non plus l’évaluation du système dans son ensemble. L’application peut limiter les autorisations, valider les sorties et demander une confirmation avant d’exécuter des actions. Elle peut aussi accorder au modèle un accès étendu aux données et aux outils. Cette architecture peut modifier considérablement les conséquences d’une instruction malveillante, même si le modèle sous-jacent reste le même.

Capacités et limites documentées du modèle exact

La source officielle fournie identifie une fiche système pour Claude Opus 5.5 et la décrit comme un document consacré au modèle, à ses évaluations de sécurité et à des aspects du déploiement responsable. Faute d’informations plus détaillées dans les éléments fournis, il serait imprudent de lui attribuer des résultats précis en matière de sécurité, des capacités techniques particulières ou des limites quantifiées qui ne figurent pas dans l’extrait.

Anthropic présente également Opus 5.5 comme performant en programmation agentique et dans le travail de connaissance, et affirme qu’il coûte 40 % moins cher à faire fonctionner qu’Opus 5 pour des charges de travail typiques. Cette comparaison est une affirmation du fabricant et concerne des charges typiques ; elle ne constitue ni un tarif universel ni une économie garantie pour tout usage. Les informations disponibles ne définissent pas les charges considérées comme typiques, la méthode de calcul du coût d’exploitation, ni si ce chiffre correspond au prix par jeton, au coût total d’une tâche ou à une autre mesure.

Il ne faut pas transformer une description de la famille Claude en propriété vérifiée d’Opus 5.5. Une décision technique nécessite la fiche exacte, les paramètres pertinents et des essais portant sur les tâches et les limites propres au projet. En particulier, l’affirmation au sujet de Gray Swan ne démontre pas, à elle seule, comment le modèle réagit à des instructions intégrées à un document, à des demandes ambiguës, à des erreurs d’outil ou à des tentatives d’extraction d’informations sensibles.

Accès et prix : que peut-on confirmer ?

Parmi les sources fournies figurent la documentation de Google Cloud sur Claude Opus 5.5 et une page AWS Bedrock consacrée au modèle. Cela permet de confirmer que ces deux plateformes disposent de pages documentaires qui l’identifient. Les extraits disponibles ne suffisent toutefois pas à garantir sa disponibilité dans toutes les régions, un accès immédiat pour n’importe quel compte, les conditions contractuelles ou un identifiant de modèle valable pour chaque déploiement.

La documentation générale des modèles Claude est présentée comme un guide permettant de consulter les modèles et de comparer les options, mais l’extrait fourni ne contient pas de prix précis pour Opus 5.5. Il n’est donc pas possible de publier ici un tarif pour les entrées ou les sorties, ni d’affirmer des dates de validité, des minimums, des modalités ou des frais associés. Ces informations doivent être vérifiées sur la page de tarification correspondant au canal retenu, à la date de souscription.

La baisse de 40 % par rapport à Opus 5 se limite à l’affirmation d’Anthropic concernant le coût d’exploitation pour des charges typiques. Elle ne correspond pas à un tarif officiel et ne peut pas être convertie en coût par requête sans connaître le volume, la taille des entrées et des sorties, le recours aux outils et la définition de ces charges typiques. Pour établir un budget, il est préférable de mesurer un échantillon représentatif sur le canal choisi.

Mesures de protection pour un flux de travail réel

Aucun chiffre de benchmark ne devrait remplacer les contrôles de l’application. Si le modèle lit des contenus externes, il est préférable de les traiter comme des données potentiellement non fiables et de séparer clairement les informations analysées des instructions qui régissent le système. Cette séparation réduit les ambiguïtés, mais ne garantit pas à elle seule que le modèle interprétera toujours correctement la hiérarchie des consignes.

Pour les actions ayant des conséquences, il est prudent de limiter la portée des outils, d’appliquer le principe du moindre privilège et d’exiger une validation indépendante avant toute opération sensible. Une réponse du modèle peut servir de proposition, et non d’autorisation. Il est également utile d’enregistrer les entrées pertinentes, les décisions et les appels aux outils, dans le respect des exigences de confidentialité et de conservation du produit.

Les tests devraient reproduire l’architecture réelle : mêmes types de documents, mêmes mécanismes de récupération, mêmes instructions, mêmes outils et mêmes contrôles que ceux prévus en production. Les équipes peuvent mesurer séparément si le modèle suit les consignes valides, rejette les tentatives de détournement, évite de révéler des données et accomplit la tâche légitime. Cette évaluation locale complète un benchmark externe ; elle ne permet pas d’attribuer à Opus 5.5 des propriétés qui n’ont pas été observées lors des tests.

Dans un flux agentique, une instruction malveillante n’a pas besoin de convaincre le modèle de révéler du texte pour causer un dommage. Elle peut chercher à déclencher une requête non autorisée, à modifier une action ou à influencer une décision ultérieure. Les défenses ne devraient donc pas reposer uniquement sur la capacité du modèle à détecter l’attaque : des limites d’autorisation et des vérifications effectuées hors du modèle peuvent contenir les conséquences d’un échec.

Bilan des éléments disponibles

Il convient de distinguer trois niveaux. Premièrement, l’affirmation attribuable à Anthropic : Opus 5.5 est à égalité avec Fable 5.1 pour le taux de réussite le plus faible face aux injections parmi les modèles inclus dans l’évaluation de Gray Swan mentionnée par l’entreprise. Deuxièmement, les informations institutionnelles vérifiables dans les sources fournies : il existe une fiche système pour Opus 5.5 ainsi que des pages documentaires de plateformes qui identifient le modèle. Troisièmement, les questions laissées sans réponse par les extraits disponibles : chiffres, protocole, ensemble des modèles, équivalence des conditions, prix précis et disponibilité effective.

Rien ne permet de transformer le résultat annoncé en une certification générale de sécurité, ni de décrire le protocole de Gray Swan comme si nous l’avions examiné. Ces sources ne permettent pas non plus d’affirmer quel taux Opus 5.5 a obtenu, si son écart avec les autres modèles est significatif ou quelles mesures de protection précises empêcheraient une injection dans chaque application.

Pour les responsables de la sécurité et les développeurs, la conclusion pratique reste limitée : la comparaison peut justifier d’inclure Opus 5.5 dans une évaluation, mais pas de renoncer aux contrôles ou aux tests propres au projet. Avant le déploiement, il faut confirmer la version et le canal, consulter les conditions et les prix en vigueur, examiner la fiche système complète et évaluer des attaques représentatives de l’application. Le benchmark apporte du contexte ; les éléments nécessaires à la décision dépendent du risque, des autorisations et des données de chaque flux.

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.