À l’extérieur, parité ; à l’intérieur, une loterie
Le fait le plus important ici est désagréablement simple : sur la même application le même jour, les modèles ont divergé de 48 points en test boîte blanche. Dans le rapport d’exécution original, cela semble brutal : Kimi K3 a obtenu 88/100, Claude Opus 4.8 70/100, GPT-5.5 40/100.
Cependant, la reconnaissance externe n’a montré presque aucune différence. Les trois modèles ont produit le même ensemble : 7 découvertes, 0 CVE, 5 adresses IP et 10 ports. En d’autres termes, la reconnaissance de base est vraiment devenue une commodité : le scanner a trouvé, le modèle a redit.
Mais une fois l’accès accordé, le chaos a éclaté. Kimi K3, selon l’auteur du test, a d’abord lu le frontend, extrait la structure de l’API et l’a parcourue comme une carte : 20 étapes, 20 découvertes, 3 exploits actifs, 0 échec.
Claude Opus 4.8 semblait plus stable dans son comportement mais plus faible en couverture : 11 étapes, 2 découvertes, 0 échec. Il a confirmé l’accès, lu une source de données et s’est simplement arrêté. C’est particulièrement frustrant en red teaming : formellement, le modèle n’a pas planté, mais en réalité il a sous-examiné la cible.
GPT-5.5, au contraire, a bougé le plus longtemps mais s’est égaré. Le rapport indique que le modèle a tôt décidé que les identifiants ne fonctionnaient pas, n’est jamais revenu sur cette décision, a dérivé vers la surface publique et a finalement donné une conclusion fausse : 18 étapes, 8 découvertes, 3 échecs.
Séparément, le coût du processus est frappant. D’après les mêmes notes, Kimi a consommé environ 23 000 tokens par découverte, Claude environ 280 000. Si ces chiffres sont corrects, ce n’est pas seulement une différence de coût, mais une différence dans la façon dont le modèle maintient une trajectoire de travail.
Pourquoi cela compte pour la pratique
La leçon clé ici n’est pas de savoir quel modèle a « gagné ». C’est que les phrases « rien trouvé » et « le modèle n’a pas pu vérifier correctement » peuvent facilement se déguiser l’une en l’autre dans un rapport.
Je regarderais donc non pas le score de sévérité final, mais la mécanique d’exécution : combien d’étapes ont été effectuées, où le modèle est resté bloqué, s’il est revenu aux hypothèses, ce qu’il a exactement couvert après la connexion. Un score bas n’équivaut pas à la sécurité. Il signifie souvent une seule chose : le chemin critique n’a pas été démontré.
Et ce n’est plus une nuance académique. Si un modèle attribue « moyen » et qu’un autre, sur la même cible, extrait un scénario critique avec des exploits actifs, le problème n’est pas l’esthétique d’un benchmark, mais un faux sentiment de risque maîtrisé.
De ce cas, je tirerais une règle très terre-à-terre : les tests authentifiés ne peuvent pas être réduits à un seul agent et à un seul verdict. À l’extérieur, les LLM sont déjà assez homogènes, mais à l’intérieur d’une application, ils ont encore trop d’aléatoire pour confondre le silence du modèle avec l’absence de vulnérabilité.