Un résultat remarquable, dans un cadre précis
OpenAI rapporte que les versions d’octobre de GPT-6 Sol et GPT-6 Luna atteignent respectivement 99,99 % et 99,79 % de robustesse dans ses évaluations de hiérarchie des consignes. Ces tests couvrent les attaques directes, où une personne tente de faire oublier une règle supérieure, et les attaques indirectes, où une consigne malveillante est cachée dans un courriel, une page Web ou un document consulté par l’agent. L’entreprise dit avoir renforcé les modèles avec GPT-Red, un agent automatisé qui produit des attaques pour l’entraînement et l’évaluation. Le fait est donc clair : les modèles résistent beaucoup mieux à une famille d’attaques définie par OpenAI. L’interprétation doit rester plus étroite que le chiffre. Un pourcentage obtenu dans un banc d’essai ne décrit ni toutes les applications, ni toutes les combinaisons d’outils, ni la probabilité qu’une organisation subisse un incident. OpenAI précise d’ailleurs que les jeux de tests, les correcteurs et les politiques évoluent. Le score permet de comparer des versions dans un cadre donné; il ne transforme pas un modèle en composant de sécurité infaillible.
Une moyenne élevée peut cacher un risque à grande échelle
Il est tentant de lire 99,99 % comme une garantie. Par simple illustration mathématique, un taux d’échec de 0,01 % correspondrait à un cas sur 10 000 si les essais étaient indépendants et comparables. Une plateforme qui traite un million de documents pourrait alors rencontrer environ 100 cas problématiques. Ce calcul n’est pas une prévision réelle : les attaques ne sont pas distribuées au hasard, un adversaire peut répéter ses essais et le pourcentage du laboratoire ne constitue pas un taux d’incident en production. Il montre toutefois pourquoi plusieurs décimales ne remplacent pas une analyse du volume et des conséquences. Les données du NIST renforcent cette prudence. Dans une compétition publique analysée en 2026, plus de 400 participants ont lancé plus de 250 000 tentatives contre 13 modèles de pointe utilisés comme agents. Au moins une attaque réussie a été trouvée contre chacun des modèles ciblés. Ces résultats ne contredisent pas ceux d’OpenAI : les modèles, scénarios et méthodes diffèrent. Ils montrent plutôt que des humains qui adaptent leurs attaques finissent souvent par découvrir des chemins absents d’un test fixe.
Le danger vient du pouvoir accordé après la lecture
Une injection devient grave lorsqu’un contenu non fiable rencontre un outil puissant. Imaginons un agent qui ouvre les pièces jointes reçues par une PME québécoise, vérifie les factures dans le système comptable et prépare les paiements. Une fausse facture peut contenir une consigne invisible ou déguisée demandant de changer les coordonnées bancaires, d’exporter la liste des fournisseurs ou de contourner une étape. Si l’agent peut seulement résumer le document, l’erreur reste limitée. S’il peut modifier un bénéficiaire et autoriser une transaction, le même échec change d’échelle. On peut résumer le risque avec trois questions : quelles données extérieures l’agent lit-il, à quels renseignements sensibles a-t-il accès et quelles actions peut-il exécuter? Le modèle compte, mais l’architecture détermine l’effet maximal d’une erreur. OpenAI compare maintenant les injections avancées à de l’ingénierie sociale : il devient difficile de distinguer automatiquement une instruction malveillante d’une demande crédible. L’objectif réaliste consiste alors à limiter les dégâts même si le modèle se laisse convaincre.
Les contrôles utiles sont concrets et mesurables
La première défense est le moindre privilège. Un agent chargé de classer des factures n’a pas besoin du droit de payer, d’effacer un fournisseur ou d’ouvrir tout le répertoire partagé. Les clés d’accès doivent être séparées par fonction, les montants plafonnés et les opérations sensibles confirmées par une personne. Un mode lecture seule constitue souvent le meilleur point de départ. Il faut aussi empêcher le texte libre provenant d’un document de devenir directement une commande : l’agent peut extraire un numéro, une date et un montant dans des champs structurés, puis un logiciel ordinaire vérifie leur format et applique les règles d’affaires. Viennent ensuite l’isolation et la visibilité. Les fichiers inconnus peuvent être traités dans un environnement sans secrets et avec un accès réseau limité. Chaque appel d’outil doit laisser une trace indiquant la source consultée, l’action demandée et le résultat. Une confirmation utile affiche exactement ce qui sera transmis ou modifié; un bouton vague marqué Continuer ne suffit pas. Enfin, les essais doivent reprendre de vrais processus : document piégé, fournisseur inhabituel, instruction contradictoire, plusieurs tentatives successives et retour à une étape précédente.
Le bon indicateur est la perte maximale, pas seulement le score
Pour décider si un agent peut passer en production, une organisation devrait mesurer quatre choses : le taux de réussite de la tâche légitime, la proportion d’attaques qui modifient son comportement, le nombre d’actions bloquées par les contrôles externes et la perte maximale possible lorsqu’ils échouent. Un modèle plus robuste peut réduire la fréquence des incidents. Une bonne architecture réduit aussi leur portée. Les deux améliorations se complètent, mais elles ne se remplacent pas. Les limites des données publiques restent importantes. OpenAI ne publie pas dans la fiche consultée tous les scénarios, le nombre complet d’essais ni un intervalle d’incertitude autour des scores de 99,99 % et 99,79 %. La compétition étudiée par le NIST portait sur d’autres modèles et récompensait activement la découverte d’attaques; elle ne mesure pas un trafic d’entreprise ordinaire. Il serait donc trompeur d’établir un classement commun avec ces chiffres. La conclusion pratique est plus sobre : choisir un modèle résistant, puis concevoir chaque permission comme si une consigne cachée pouvait un jour franchir cette première barrière.
