L’essentiel
- OpenAI a classé GPT-5 à haut risque biologique en interne à l’été 2025, avant de rétrograder cette note à l’automne, selon une enquête du Wall Street Journal.
- Des centaines d’utilisateurs ont demandé à ChatGPT des méthodes de fabrication de poisons ou d’armes biologiques, et certains ont obtenu des marches à suivre pas à pas.
- Les comptes concernés ont été suspendus, sans aucun signalement aux autorités : la loi ne l’impose pas.
« Le modèle peut aider des personnes sans formation scientifique à produire des dangers biologiques. » La phrase sort d’une évaluation interne d’OpenAI, à l’été 2025, et elle vaut à GPT-5 le classement le plus élevé sur le volet biologique. Quelques mois plus tard, la même note redescend d’un cran. Entre les deux dates, d’après l’enquête du Wall Street Journal, rien n’indique que le comportement du modèle ait changé.
Une note de danger qui redescend toute seule
Le classement de l’été n’a pas retardé la sortie : GPT-5 arrive en ligne avec sa note maximale. Dans les semaines qui suivent, des employés continuent de tomber sur des réponses problématiques en usage réel.
Le déclassement d’automne n’est accompagné d’aucun document public : ni le seuil que le modèle aurait cessé de franchir, ni la mesure attestant d’une amélioration, ni le nom du signataire. Une évaluation de sûreté qui se révise à la baisse pendant que le produit se déploie tient moins de la mesure que de l’arbitrage. Quelques mois plus tôt, Anthropic avait suivi le chemin inverse sur Claude Opus 4 : faute de pouvoir écarter le risque chimique et biologique, l’entreprise avait lancé le modèle avec son palier de protection le plus strict activé par précaution.
Quand refuser devient un coût pour le produit
Le même dossier rapporte une consigne passée en interne par des dirigeants : les modèles ne devaient pas dire « non » trop souvent, au risque de bloquer des chercheurs en santé. L’argument tient debout. Un modèle qui refuse toute question de toxicologie, de virologie ou d’oncologie devient inutilisable pour les gens dont c’est le métier, et le sur-refus a un coût réel pour la recherche.
La difficulté apparaît quand cette prudence devient un objectif interne. Deux grandeurs s’opposent alors : le taux de refus et le taux de fuite. Le premier arrive tous les jours sur les bureaux, porté par les plaintes d’utilisateurs, les tickets de support et les comparatifs entre modèles publiés sur les réseaux. Le second n’apparaît que si quelqu’un le cherche activement, avec du temps et un mandat pour le faire. Une organisation finit par optimiser ce qu’elle mesure en continu.
Des centaines de demandes, aucun signalement
Depuis l’été dernier, des centaines d’utilisateurs auraient interrogé ChatGPT sur la fabrication de poisons ou d’armes biologiques. Certains ont obtenu des marches à suivre détaillées, étape par étape, d’un niveau que des employés d’OpenAI jugeaient accessible à un élève de terminale. L’entreprise a suspendu les comptes concernés et n’a rien signalé aux autorités : aucune obligation légale ne l’y contraint.
L’objection classique a du poids : ces modèles créent-ils un danger inédit, ou accélèrent-ils seulement l’accès à une information déjà disponible ? Une étude menée à Cambridge montre que les groupes terroristes utilisent déjà tous les grands chatbots, quitte à contourner leurs garde-fous par des prompts détournés, ce qu’on appelle le jailbreak. L’écart tient à la forme de la réponse. Une information dispersée dans des archives publiques ne vaut pas un plan ordonné, calibré sur votre niveau, qui répond à vos questions de suivi et corrige vos erreurs au fil de l’eau.
Votre application hérite de cet arbitrage
La décision ne reste pas confinée aux bureaux d’OpenAI : elle se propage à toute application qui appelle le modèle par son API (l’interface technique par laquelle un logiciel adresse ses requêtes au modèle). Le niveau de sûreté d’une API reflète l’état, à une date donnée, d’un choix interne que vous ne voyez pas et qui peut bouger sans rien casser visiblement chez vous.
Le refus du modèle ne peut donc pas tenir lieu de garde-fou applicatif : vos filtres d’entrée et de sortie, vos journaux et vos alertes restent votre responsabilité, pas celle de l’éditeur. Verrouillez vos versions sans y voir une garantie : à prompt identique, un snapshot (une version datée du modèle) peut changer de comportement dès que la politique de refus évolue en amont. Vos jeux de tests doivent inclure les cas sensibles que vous voulez voir bloqués. Relisez enfin les model cards (les fiches techniques publiées avec chaque version) à chaque révision, en regardant ce qui a bougé plutôt que ce qui est mis en avant.
Rien de tout cela ne relève du scandale exotique. C’est le fonctionnement ordinaire d’une industrie où la même organisation fabrique le produit, définit les critères de danger, mesure le résultat et décide seule de la note finale. Tant que ces quatre rôles resteront dans les mêmes mains, la dangerosité d’un modèle continuera de s’ajuster au calendrier de lancement, quelle que soit la rigueur des équipes qui l’évaluent.
Mon avis
La classification de risque d’un modèle devrait être opposable : publiée, datée, accompagnée du protocole qui la fonde et du motif de chaque révision. Tant qu’elle reste un document interne modifiable par ceux qui ont une date de lancement à tenir, elle vaut à peu près autant qu’une déclaration d’intention. Aucun éditeur ne fera ce pas de lui-même, et je vois mal ce qui l’y pousserait avant le premier incident dont la trace sortira des serveurs d’un laboratoire. D’ici là, chaque équipe qui met ces modèles en production signe pour un niveau de sûreté qu’elle ne contrôle pas et qu’on peut réviser sans la prévenir.
