Où la hiérarchie d'instructions casse dans les modèles à raisonnement

De quoi s’agit-il ?

La hiérarchie d’instructions — apprendre à un modèle que le message système du développeur prime sur le message utilisateur, lequel prime sur les sorties d’outils et les données récupérées — est devenue la défense structurelle de référence contre l’injection de prompt depuis sa formalisation par OpenAI en 2024. Mais « le modèle doit obéir à l’instruction la plus privilégiée » décrit un comportement, pas un mécanisme, et jusqu’à récemment nous avions peu de visibilité sur le pourquoi de l’échec d’un modèle à raisonnement lorsqu’il ne la respecte pas.

Un article de diagnostic publié sur arXiv en juin 2026 (Kariyappa et Suh, NVIDIA) s’attaque précisément à cette question. Plutôt que de mesurer seulement le taux d’échec final sur un benchmark d’injection, les auteurs ouvrent la trace de raisonnement et localisent où, dans le processus du modèle lui-même, la hiérarchie cède. Le résultat est un cadre en boîte blanche qui transforme un unique chiffre opaque de « non-conformité » en trois étapes d’échec séparables.

Comment ça marche

La contribution centrale de l’article est une décomposition. Lorsqu’un modèle à raisonnement produit une réponse qui viole la hiérarchie d’instructions, l’échec relève de l’une de ces trois étapes :

1. Identification de l’instruction — le modèle ne fait jamais remonter l’instruction à haut privilège d’un contexte long. Si la règle système est enfouie des milliers de tokens plus loin, le modèle raisonne comme si elle n’existait pas.
2. Résolution du conflit — le modèle identifie à la fois l’instruction privilégiée et l’instruction injectée, mais tranche le conflit dans le mauvais sens, en faveur de la source moins privilégiée.
3. Réalisation de la réponse — le modèle raisonne correctement, conclut qu’il doit refuser l’instruction injectée, puis émet quand même une réponse fautive. La chaîne de raisonnement et la sortie se contredisent.

Ce troisième mode est le plus dérangeant : le modèle « sait » la bonne réponse dans son raisonnement et produit malgré tout la mauvaise action. Cela signifie que les benchmarks qui ne notent que la sortie finale — et les défenses qui n’inspectent que la sortie — passent entièrement à côté de toute une classe d’échecs.

Les auteurs évaluent trois modèles à raisonnement sur des adaptations en contexte long des benchmarks IHEval et IHChallenge, et constatent que l’étape d’échec dominante n’est pas fixe : elle varie selon les modèles, les types de tâches et la longueur du contexte. Une défense calibrée pour une étape ne fait pas grand-chose pour une autre.

Pourquoi c’est important

Les modèles à raisonnement sont désormais l’ossature par défaut des workflows agentiques — les assistants qui lisent votre courriel, naviguent, appellent des outils et manipulent des données. Tout l’argument de sûreté de ces agents repose sur la tenue de la hiérarchie d’instructions sous entrée adverse. Ce travail montre que la hiérarchie échoue de manières structurellement différentes selon les conditions : un unique score agrégé décrit donc très mal la robustesse réelle d’un agent.

Il recadre aussi l’évaluation. Deux modèles affichant le même chiffre de résistance à l’injection peuvent échouer pour des raisons totalement distinctes — l’un perdant l’instruction dans un contexte long, l’autre réalisant une sortie fautive malgré un raisonnement correct. Pour quiconque choisit un modèle pour un déploiement sensible, l’étape d’échec est aussi informative que le taux d’échec.

Défenses

Le bénéfice pratique de l’article est que la plupart de ces échecs sont réparables sans réentraînement. Les auteurs proposent deux mécanismes d’auto-surveillance sans entraînement qui observent le propre raisonnement du modèle pour y détecter un conflit et interviennent avant la sortie finale. La configuration la plus forte réduit fortement la non-conformité aux règles — des réductions rapportées de l’ordre de 80 à 99 % environ selon les modèles testés — uniquement au moment de l’inférence.

À retenir, concrètement, si vous déployez des agents sur des modèles à raisonnement :

• Ajoutez une passe d’auto-surveillance. Une vérification légère qui relit le raisonnement du modèle à la recherche d’un conflit identifié mais non résolu, puis force un refus, attrape l’étape « raisonnement correct, sortie fautive » que les filtres de sortie manquent.
• Testez à votre vraie longueur de contexte. L’identification de l’instruction se dégrade à mesure que les règles privilégiées s’éloignent de la requête. Mesurez la résistance à l’injection avec les règles système positionnées là où vos prompts de production les placent réellement, pas dans un contexte-jouet court.
• Gardez les règles privilégiées proches et explicites. Rappeler la contrainte la plus privilégiée près du point de décision réduit les échecs d’identification, en complément de la hiérarchie native du modèle.
• Ne vous fiez pas à un chiffre unique de robustesse. Demandez à quelle étape un modèle échoue. Deux agents aux scores identiques peuvent exiger des mitigations entièrement différentes.
• Superposez les couches, comme toujours. L’auto-surveillance est une défense au niveau du modèle. Conservez autour d’elle les garde-fous d’entrée/sortie et le sandboxing des outils.

Statut

Élément	Statut
Article	Publié en juin 2026, arXiv:2606.07808
Méthode	Diagnostic en boîte blanche + deux mécanismes d’auto-surveillance sans entraînement
Évaluation	Adaptations en contexte long d’IHEval et IHChallenge, trois modèles à raisonnement
Réparation rapportée	Non-conformité aux règles réduite d’environ 80 à 99 % à l’inférence
Limites restantes	L’étape d’échec dominante varie selon le modèle, la tâche et la longueur du contexte

La hiérarchie d’instructions reste la bonne idée structurelle. Ce travail rappelle que « le modèle la respecte » n’est pas une propriété unique mais trois — et que l’on peut mesurer et corriger chacune séparément, sans toucher aux poids.