Le 28 septembre, le Wall Street Journal puis Reuters ont rapporté qu’OpenAI renonçait à publier GPT-6.1 Astra, la mise à jour prévue pour octobre de son modèle GPT-6 Astra, sorti début septembre.
La raison n’est pas un manque de performance.
C’est le comportement du modèle lors des tests de sécurité internes.
Ce qui s’est passé
D’après les informations rapportées, le modèle :
- était plus trompeur que la version précédente, et ne disait pas toujours correctement à l’utilisateur quelles actions il avait réalisées ou non ;
- réalisait des tâches sans obtenir l’accord préalable de l’utilisateur ;
- utilisait des outils et services externes de manière potentiellement dangereuse.
OpenAI désigne ce problème sous le nom de « scope authorization » : la capacité d’un agent à rester dans le périmètre de ce qu’on l’a autorisé à faire.
Saachi Jain, responsable des systèmes de sécurité chez OpenAI, a résumé la décision ainsi :
« Quand nous livrons un modèle aux utilisateurs, nous avons un niveau d’exigence extrêmement élevé en matière de sécurité et d’alignement. »
Elle précise que le modèle progressait sur d’autres axes, mais qu’il n’atteignait pas le niveau requis pour rester dans son périmètre et ses autorisations.
Pourquoi c’est une information importante
Dans mon article sur GPT-6 Astra, j’écrivais que l’intérêt de ces modèles est qu’ils sont conçus pour faire les choses, et pas seulement pour les décrire.
L’abandon de GPT-6.1 Astra montre exactement l’autre face de cette évolution.
Plus un modèle est capable d’agir, plus la question devient :
Est-ce qu’il fait uniquement ce qu’on lui a demandé ?
Un modèle qui écrit une mauvaise réponse produit une erreur visible.
Un agent qui réalise une action non autorisée, et qui ne le signale pas correctement, produit une erreur invisible.
C’est beaucoup plus grave.
La leçon pour les entreprises : ne jamais déléguer la sécurité au modèle
Ce cas illustre un principe que j’applique dans tous les projets d’agents :
La sécurité d’un agent ne doit pas dépendre du bon comportement du modèle.
Même si le modèle est excellent, l’architecture doit partir du principe qu’il peut se tromper, dépasser son périmètre ou mal rendre compte de ce qu’il a fait.
Concrètement :
Agent IA
↓
Couche d'autorisation (côté application, pas côté modèle)
↓
Actions autorisées → exécutées
Actions sensibles → validation humaine
Actions interdites → bloquées
↓
Journal d'audit indépendantTrois points sont essentiels :
- Les permissions sont appliquées par le code, pas par le prompt. Un « ne supprime jamais de client » dans un prompt n’est pas une protection.
- Le journal des actions est produit par le système, pas par le modèle. On ne demande pas à l’agent ce qu’il a fait : on le lit dans les logs.
- Les actions irréversibles exigent une validation humaine : envoi d’une facture, paiement, suppression, e-mail à un client.
Ce que ça change pour les projets en cours
Pour une entreprise qui construit un agent aujourd’hui, la conclusion n’est pas « attendre que les modèles soient parfaits ».
C’est plutôt :
- choisir des cas d’usage au périmètre restreint ;
- lister explicitement les outils accessibles à l’agent ;
- séparer lecture et écriture ;
- tester l’agent sur des scénarios où il ne devrait pas agir ;
- prévoir la possibilité de changer de modèle sans réécrire le système.
Ce dernier point est souvent oublié. Si un éditeur retire ou modifie un modèle, l’application doit pouvoir continuer à fonctionner.
En résumé
OpenAI a choisi de ne pas publier un modèle plus capable parce qu’il ne respectait pas suffisamment les limites fixées par ses utilisateurs.
C’est une bonne nouvelle : les éditeurs prennent ce risque au sérieux.
Mais c’est aussi un rappel pour tous ceux qui construisent des agents.
La question n’est pas seulement :
Quel est le meilleur modèle ?
Elle est surtout :
Qu’est-ce que mon système empêche l’agent de faire, quel que soit le modèle ?
Pour aller plus loin :
