GPT-Red : un attaquant automatique au service de la défense

Le principe du « red teaming » est ancien : une équipe joue l’attaquant pour trouver les failles avant les vrais attaquants. Selon la présentation d’OpenAI rapportée par Help Net Security et The Hacker News le 16 juillet 2026, GPT-Red automatise ce travail : il envoie une requête, observe la réponse du modèle visé et recommence, en poursuivant un objectif comme l’exfiltration de données. Il est entraîné en même temps que des modèles « défenseurs », récompensés quand ils résistent tout en accomplissant leur tâche d’origine.

Les résultats publiés sont frappants. Sur un test d’injection de prompt indirecte composé de scénarios jamais vus pendant l’entraînement, GPT-Red a réussi 84 % de ses attaques contre GPT-5.1, quand les red-teamers humains n’en réussissaient qu’une petite part. Il a aussi réussi les trois objectifs fixés contre un distributeur automatique piloté par une IA, et extrait des données sensibles d’un agent en ligne de commande plus efficacement qu’une base de comparaison. OpenAI indique intégrer ses attaques à l’entraînement de ses modèles depuis GPT-5.3 : GPT-5.6 Sol échouerait six fois moins que GPT-5.5 sur un test d’injection directe, et seulement dans 0,05 % des cas face aux injections directes de GPT-Red, sans perte de capacité mesurée. GPT-Red reste interne et séparé des autres modèles, pour que ses capacités offensives ne se diffusent pas.

Un organisme de normes pour l’IA de pointe

Le 14 juillet 2026, Demis Hassabis, dirigeant de Google DeepMind, a publié un texte intitulé « A Framework for Frontier AI and the Dawning of a New Age ». Selon TechCrunch, il y propose un organisme de normes indépendant pour l’IA de pointe, sur le modèle de la FINRA, l’autorité d’autorégulation des marchés financiers américains. Les laboratoires lui soumettraient volontairement leurs modèles jusqu’à 30 jours avant leur sortie ; l’organisme les testerait et établirait des bonnes pratiques ; une fois la méthode éprouvée, l’examen pourrait devenir obligatoire pour être déployé sur le marché américain.

L’organisme serait financé par l’industrie mais fonctionnerait de manière indépendante, avec un soutien public, et réunirait des experts techniques, des représentants de l’open source et des spécialistes de la sécurité de l’IA. Hassabis justifie sa proposition par les critiques adressées aux examens gouvernementaux ponctuels menés plus tôt dans l’année sur des modèles comme Mythos d’Anthropic et Sol d’OpenAI, jugés trop peu techniques et trop opaques. À ce stade, il s’agit d’une proposition, pas d’une institution.

Ce que cela change, et ne change pas, pour une PME

Ces annonces concernent d’abord les modèles eux-mêmes. Elles sont rassurantes : les éditeurs testent davantage, et de façon plus systématique. Mais elles ne testent pas votre application. Une injection de prompt réussit rarement grâce au modèle seul ; elle réussit parce qu’une application lui donne à lire des contenus extérieurs (courriels, pages web, PDF de clients) et lui permet d’agir (envoyer, payer, supprimer). Le meilleur modèle du monde reste exposé si l’application lui accorde trop de droits.

Autrement dit, la robustesse annoncée par un éditeur est une condition nécessaire, pas suffisante. La sécurité d’un agent dépend aussi de ses permissions, de ses validations humaines et de ses journaux, comme nous l’avons vu avec Claude Tag et Gemini 3.5 Flash.

Exemple d’injection à tester

Un test simple et révélateur : une facture au format PDF, d’apparence normale, contient une ligne écrite en blanc sur blanc qui demande à l’assistant d’ignorer ses consignes et d’ajouter une adresse de virement dans sa réponse. Un outil bien conçu doit traiter ce texte comme une donnée et non comme une instruction, signaler l’anomalie et, surtout, ne déclencher aucune action financière sans validation humaine. Si votre outil reprend l’instruction cachée, le problème ne se corrige pas seulement en changeant de modèle : il faut revoir ce que l’outil a le droit de faire.

Une mini-campagne de tests à votre échelle

  1. Lister les entrées non fiables que votre outil lit : formulaires, courriels entrants, pages web, documents de clients.
  2. Écrire dix tentatives d’injection simples, par exemple une phrase cachée dans un PDF qui demande d’ignorer les consignes et d’envoyer des données ailleurs.
  3. Vérifier qu’aucune action irréversible (envoi, paiement, suppression) ne part sans validation humaine, même quand l’injection réussit à tromper le modèle.
  4. Consigner les résultats : ce qui a résisté, ce qui a cédé, ce qui a été corrigé.
  5. Recommencer à chaque changement de modèle, de prompt ou d’outil.

Audit 360 et notre audit de sécurité web couvrent ces vérifications ; Prompt OS ajoute aux missions les consignes de résistance aux injections et le niveau de preuve exigé.

Conclusion

La mi-juillet 2026 a montré deux façons de rendre l’IA plus sûre : tester automatiquement à grande échelle, et faire évaluer les modèles par un tiers avant leur sortie. Pour une petite entreprise, la leçon est plus modeste et plus immédiate : tester sa propre application, avec ses propres contenus, et ne jamais laisser une action irréversible dépendre de la seule vigilance d’un modèle.