Les skills n'aident plus quand le modèle s'améliore

SwarmAttacker est livré avec plus de 60 skills experts écrits à la main, un par classe de vulnérabilité. Injection SQL, XSS, SSRF, IDOR et les autres reçoivent chacun un playbook en texte brut : voici comment cette classe fonctionne, voici comment la transformer en une vraie découverte. À l'exécution, nous injectons le skill correspondant directement dans le worker qui poursuit cette piste. C'est le genre de chose que tout le monde vous dit de construire. La connaissance experte soigneusement sélectionnée, dit la sagesse conventionnelle, est le grand gain.

Nous l'avons donc mesuré de la seule manière honnête : nous avons désactivé tous les skills et relancé toute la suite de 104 applications. Le résultat était plus intéressant que « les skills, c'est bien ».

Qu'a réellement coûté la désactivation de tous les skills ?

Avec tous les skills désactivés, le taux de résolution est passé de 94 % (98 sur 104) à 87 % (90 sur 104). Huit benchmarks perdus. Réel, mais pas l'effondrement qu'on pourrait attendre après avoir arraché 60 playbooks experts.

Et le coût est parti dans l'autre sens, fortement. Le worker sans skills a utilisé moins de la moitié des tokens : de 2.14M par application à 0.91M. C'était le plus grand changement de coût de tous les composants que nous avons testés. Toute cette expertise injectée n'était pas gratuite ; c'était l'élément le plus cher du prompt, et le retirer a rendu l'agent radicalement plus léger.

Pendant les 20 premières minutes, l'agent sans skills était devant

Voici le plus surprenant. À la vingtième minute, la configuration sans skills avait résolu plus que le système complet : 79 contre 71. Pendant tout le premier acte de chaque exécution, les skills étaient un poids mort. Le worker générique et léger était, s'il y a une différence, plus rapide au départ. Les skills n'ont repris l'avantage que dans la seconde moitié, pour finir à 90 contre 98.

Quand nous avons regardé où les huit benchmarks perdus avaient disparu, le schéma était net. La découverte survivait très bien sans skills. Le worker trouvait toujours le point d'injection, obtenait toujours sa prise. Ce qui manquait, c'était la dernière étape, spécifique à la classe : transformer une prise fonctionnelle en flag réel sur les cibles plus difficiles, liées à des conventions, où il faut connaître l'unique astuce exacte que cette classe particulière exige. Les skills sont désormais un outil pour la queue difficile, pas un multiplicateur de base.

Pourquoi les skills rapportent moins sur un modèle plus intelligent

Prenez du recul et cela a du sens. Un modèle de base moderne connaît déjà les choses courantes. Vous n'avez pas besoin d'expliquer à GPT-5.5 ce qu'est le XSS, ni comment fonctionne une injection SQL à base de UNION. Il a lu tout Internet, y compris chaque tutoriel, chaque writeup, chaque post-mortem de CTF que nous aurions paraphrasé dans un skill. L'échafaudage expert qui apportait énormément sur les anciens modèles a été discrètement absorbé dans les poids.

Nous ne pouvons pas faire d'A/B entre deux générations de modèles ici, nous ne prétendrons donc pas avoir mesuré « les skills ont aidé GPT-4 de X et GPT-5.5 de Y ». Nous ne l'avons pas fait. Mais la forme du résultat, le modèle de base traversant sans aucune aide les cas faciles et moyens, est exactement ce à quoi on s'attendrait si le modèle avait déjà absorbé l'essentiel de ce que les skills apportaient. Sur un modèle frontière, les skills ne se justifient qu'aux marges.

La connaissance experte que vous auriez écrite à la main dans un skill il y a deux ans est déjà dans le modèle. Sur les cas courants, vous payez des tokens pour lui dire des choses qu'il sait.

Ce que cela signifie si vous construisez

Ne passez pas des mois sur une gigantesque bibliothèque de skills ou de RAG pour un modèle frontière. Le réflexe de charger d'avance chaque parcelle d'expertise métier avait du sens quand le modèle de base était plus faible ; aujourd'hui, il vous achète surtout une facture de tokens plus lourde et un premier acte plus lent. À la place :

• Laissez le modèle de base gérer les cas courants. Il le fera, et il le fera plus vite sans votre échafaudage dans les pattes.
• Gardez des skills légers, visant la longue traîne, les cas limites liés à des conventions où l'astuce exacte compte et où le modèle calerait sinon à une étape du but.
• Surveillez le coût en tokens de votre expertise. La connaissance injectée est l'élément le plus cher d'un prompt. Si elle ne fait pas bouger le taux de résolution, c'est du pur surcoût.

C'est la même histoire que nous voyons se répéter ailleurs : le modèle continue d'absorber l'échafaudage que nous construisons autour de lui. Nous l'avons vu aussi avec le prompt engineering, où les règles soigneusement écrites se sont révélées être des choses qu'un modèle solide fait déjà tout seul. Les skills sont la prochaine couche à s'amincir. Construisez pour les marges, pas pour le milieu.