Les prompts sont-ils morts ?

Il n'y a pas si longtemps, le prompt engineering représentait la moitié du travail. On amadouait un modèle avec du chain-of-thought, on l'amorçait avec quelques exemples, on écrivait un system prompt soigné, rempli de règles et de listes de contrôle, et cet échafaudage faisait la différence entre un agent utile et un agent inutile. Alors, quand nous avons construit SwarmAttacker, nous avons fait tout cela aussi.

Puis nous avons tout désactivé, pour voir ce que cela valait réellement. La réponse, sur un modèle frontière actuel, a été : presque rien.

L'expérience : chaque technique de prompting désactivée

SwarmAttacker résout des défis de sécurité : pointez-le sur une application web vulnérable et il doit trouver le flag. Nous le faisons tourner sur une suite de 104 d'entre elles. Le système complet, sur GPT-5.5, en résout 94 %.

Pour mesurer ce que chaque partie apporte, nous avons désactivé les composants un par un et relancé toute la suite. L'un de ces composants était l'ensemble des techniques de prompting écrites à la main dans l'agent : les règles qui lui disent d'essayer des approches variées au lieu de s'enfermer dans une seule, la liste de contrôle qui l'empêche de sauter aux conclusions, les notes d'état d'exécution qui le relancent quand il est bloqué. Tout cela, désactivé.

Retirer toutes les techniques de prompting a coûté trois benchmarks. Trois, sur 104. C'était la plus petite baisse de tout ce que nous avons testé, sept fois plus petite que celle de la gestion des refus, et cela n'a même pas fait économiser d'argent : l'exécution a consommé pratiquement le même nombre de tokens sans l'échafaudage.

Sans techniques de prompting, l'exécution était en tête pendant vingt minutes

Voici la partie qui a piqué. Pendant les vingt premières minutes de chaque exécution, la version sans techniques de prompting résolvait plus de benchmarks que le système complet, 76 contre 71. L'échafaudage soigné n'a pas seulement échoué à aider au début ; il a ralenti l'agent. Les trois benchmarks qu'il a fini par sauver ne sont apparus que tard, sur les cibles les plus difficiles.

La raison n'a rien de mystérieux. Les standards que nous avions écrits dans le prompt, essayer plus d'une chose, ne pas se fier à un signal unique, vérifier ses hypothèses, sont des choses qu'un modèle solide fait désormais surtout de lui-même. Nous écrivions des règles pour imposer un comportement que le modèle avait déjà appris.

Une capacité que les anciens agents devaient construire dans le prompt a été discrètement absorbée par le modèle de base.

Alors, les prompts sont-ils morts ?

Non. Mais le centre de gravité s'est déplacé. Trois benchmarks, ce n'est pas zéro, et sur les cibles les plus difficiles, les plus liées aux conventions, l'échafaudage a encore mérité sa place. Si vous faites tourner un modèle plus petit ou plus ancien, la discipline de prompting compte bien plus que cela, parce que le modèle ne comble pas encore les lacunes à votre place.

Ce qui est mort, c'est l'idée que le levier se trouve dans le prompting astucieux. Sur un modèle frontière, c'est l'une des choses les moins importantes sur lesquelles dépenser de l'effort. Les gains viennent maintenant de ce qui entoure le modèle : lui donner les bons outils, lui renvoyer proprement la sortie des outils, lui éviter les refus, et le laisser réessayer. Ce sont ces parties-là qui, quand nous les avons retirées, ont vraiment fait mal.

Si vous passez encore vos après-midi à ajuster à la main un system prompt sur des modèles de classe GPT-5, les données suggèrent que vous polissez le seul levier qui bouge à peine. Le plus gros, curieusement, consiste simplement à laisser le modèle réessayer.