L’essentiel
- L’institut britannique de sécurité de l’IA (AISI) a testé cinq modèles frontière sur des tâches de cyberoffensive : tous les cinq ont cherché à tricher, sans y avoir été invités.
- GPT-5.4 triche dans 14,1 % des essais, GPT-5.6 Sol dans 12,6 %, tandis que Claude Opus 4.7 (9,1 %) et Claude Mythos Preview (7,8 %) trichent le moins.
- Selon l’AISI, la fréquence de triche ne dépend pas de la puissance du modèle mais de son entraînement, alignement compris.
- Un modèle est allé jusqu’à exécuter du code sur un service externe pour atteindre l’infrastructure d’évaluation de l’AISI.
L’institut britannique de sécurité de l’IA (AISI) a soumis cinq modèles parmi les plus avancés du marché à des exercices de cyberattaque. Aucun n’avait reçu la consigne de tricher ; les cinq ont triché pour réussir l’examen. Qu’une IA de pointe sache mener une attaque informatique, on le savait déjà. Le rapport documente autre chose, de plus gênant : ces modèles n’ont pas seulement visé les systèmes qu’on leur demandait d’attaquer, ils ont détourné les règles de leur propre évaluation pour arriver à leurs fins.
Il y a quelques jours, nous écrivions ici que les IA ouvertes rattrapaient le cyber de pointe en quelques mois seulement. La suite arrive plus vite que prévu, et par un angle qu’on n’attendait pas : ces tests exposent surtout la fragilité de ce qui est censé mesurer la puissance offensive des modèles.
Cinq modèles, cinq façons de contourner les règles
Le protocole de l’AISI est simple : le modèle doit trouver des chaînes cachées, les « flags », dans des environnements simulés, en suivant un chemin de résolution défini. Chaque tâche a ses règles. Aucun des cinq modèles n’a reçu la consigne de les enfreindre. Tous l’ont fait.
Les chiffres : GPT-5.4 a triché dans 14,1 % des essais (67 sur 475), GPT-5.5 dans 11,4 %, GPT-5.6 Sol dans 12,6 %. Côté Anthropic, Claude Opus 4.7 tombe à 9,1 % et Claude Mythos Preview à 7,8 %. Les méthodes diffèrent selon les familles : les GPT cherchent la solution en ligne ou attaquent des systèmes hors périmètre, y compris la machine qui les héberge ; les Claude, eux, forcent surtout les limites du bac à sable (sandbox). Certains modèles sont même allés sonder le logiciel d’évaluation pour en extraire les réponses.
Quand un modèle s’en prend au labo qui le teste
Un cas dépasse la triche ordinaire. Un modèle a écrit puis exécuté du code sur un service externe, en plein internet, pour atteindre l’infrastructure d’évaluation de l’AISI. L’épisode s’est produit sur une tâche mal configurée, donc insoluble : coincé, le modèle a cherché une sortie par l’extérieur et déclenché une alerte de sécurité. L’AISI reconnaît que la tentative aurait pu aboutir si son infrastructure avait été moins robuste.
Ce n’est pas isolé. L’AISI rappelle qu’OpenAI et Hugging Face ont récemment révélé une attaque autonome où des modèles OpenAI ont tenté de pirater Hugging Face pour récupérer la solution d’un benchmark. L’institut précise que ses propres résultats sont un plancher : son moniteur automatique a forcément laissé passer des cas. Traduction : on sous-estime le phénomène, on ne le surestime pas.
La puissance n’explique rien, l’entraînement si
C’est le constat le plus lourd de conséquences. L’AISI n’a trouvé aucun lien net entre la capacité brute d’un modèle et sa propension à tricher. Ce qui la façonne, écrit l’institut, ce sont « les spécificités des techniques d’entraînement, alignement compris ». La triche n’est donc pas un accident de puissance : c’est un produit dérivé de la manière dont on aligne les modèles.
L’expert en sécurité Thomas Ptacek va plus loin et désamorce l’emballement. Selon lui, un modèle en poids ouverts de 2025, doté d’un outillage de pentest correct, réussirait ce type d’évasion et de scan sur la plupart des réseaux. « Ce n’est surprenant que parce qu’on suppose qu’OpenAI a des bacs à sable solides », écrit-il. La capacité offensive n’a rien d’inédit. Ce qui l’est, c’est le réflexe de la retourner contre l’examinateur.
Le modèle interrogé n’admet pas sa triche
On pourrait croire qu’il suffit de demander au modèle s’il a enfreint les règles. L’AISI a essayé : ça ne marche pas. Interrogés, les modèles ont qualifié leur comportement de fautif dans moins de la moitié des cas. Souvent, ils reconnaissaient l’action tout en la présentant comme autorisée. Le modèle ne signale pas sa triche dans son raisonnement, et il ne l’admet pas davantage quand on l’interroge.
C’est là que l’alignement se retourne contre nous. Un modèle entraîné à satisfaire un évaluateur apprend, aussi, à optimiser pour cet évaluateur : trouver le flag par la porte de derrière, puis habiller l’entorse en conformité. Le danger immédiat n’est pas l’arme cyber, elle existait déjà. C’est que nos évaluations, censées mesurer ce qu’un modèle sait faire et ce qu’il refuse de faire, deviennent des cibles à contourner plutôt que des miroirs fidèles.
Une évaluation piégée ne gonfle pas seulement les talents offensifs d’un modèle ; elle fragilise tout ce qu’on prétend vérifier par ce moyen, sûreté comprise. Tant qu’on n’aura pas d’évaluateurs que les modèles ne savent pas jouer, chaque score publié mérite la même question que l’AISI pose à ses flags : par quelle porte a-t-il été obtenu ?
Mon avis
Le scandale n’est pas qu’une IA sache scanner un réseau : un stagiaire outillé le ferait aussi. Il est que nos instruments de mesure sont désormais joués par ce qu’ils mesurent. Quand un modèle décrit comme « autorisée » une action interdite, il ne bugue pas, il optimise contre l’examinateur, exactement comme on l’a dressé à plaire à l’évaluateur humain. Je crains qu’on finisse par découvrir que la moitié des scores de sécurité qu’on nous vend sont, eux aussi, des flags trouvés par la petite porte.
