IBM montre que poser des questions au client avant de générer le code porte la précision des smart contracts par transaction à 72,9 %

Les systèmes d'agents qui transforment une description en anglais en code sont devenus courants, et le code compile en général. Mais savoir si le comportement du programme correspond à l'intention de son auteur, presque personne ne le mesure avec des outils validés. Des chercheurs de l'IBM T.

J. Watson Research Center ont étudié la question sur des smart contracts Solidity : une fois déployés, ils ne peuvent plus être corrigés et ils manipulent de l'argent, si bien qu'une erreur coûte cher. La principale métrique de l'étude est la précision par transaction, c'est-à-dire la part des transactions rejouées sur lesquelles le contrat généré se comporte comme l'original.

Le pipeline qui commence par poser des questions au client atteint 72,9 % sur 500 contrats mis de côté pour le test. La génération en une seule requête obtient 53,9 %, et l'ancien pipeline à sept étapes des auteurs, 39,3 %. L'essentiel de l'intention se perd avant la génération, et ce qui aide le plus, c'est de clarifier les exigences, pas d'empiler des étapes de vérification.

Comment la précision a été mesurée

Les auteurs ont retenu 600 contrats réels issus du jeu de données FSM-SCG. Pour chacun, Gemini 2.5 Flash a rédigé une description courte d'environ 140 mots et un document d'exigences complet d'environ 1700 mots. La métrique principale est l'implementation fidelity, c'est-à-dire la fidélité de reproduction du comportement de l'original. Pour chaque contrat, 60 séquences aléatoires de 8 étapes ont été exécutées dans une machine virtuelle EVM locale. Une étape n'est validée que si le résultat de l'appel et toutes les valeurs observables coïncident. Les auteurs précisent que la métrique ne reflète l'intention de l'auteur que dans la mesure où le contrat d'origine l'incarne.

Les outils d'évaluation eux-mêmes ont d'abord été testés sur des erreurs injectées. L'analyseur statique Slither n'a repéré le nouveau problème que dans 3 cas sur 200 suppressions de contrôles d'accès. Un LLM utilisé comme juge et lisant le code signale 80 % des contrats intacts comme problématiques, et l'exigence d'une preuve exécutable ramène la part d'erreurs détectées à 30 %. Un modèle de référence en Python, écrit à partir de la description, détecte 94,3 % des erreurs typiques, comme des modificateurs supprimés. Mais un modèle équivalent, écrit uniquement à partir des noms de fonctions, en détecte 87,5 %. Autrement dit, une bonne part des évaluations classiques récompense la connaissance des conventions générales plutôt que la compréhension de la description.

Où l'intention se perd

Sur 100 contrats récents et 279 erreurs propres à chaque contrat, le modèle de référence a trouvé 65,9 % des erreurs avec la description courte et 87,5 % avec le document complet. L'écart est de 21,6 points. L'agent extracteur et l'agent critique n'ont rien changé. Une liste de dix questions fixes posées au client a comblé presque entièrement l'écart : 89,4 %, contre 88,9 % pour le document complet.

Avec le générateur GPT-5.4-mini, la précision par transaction est de 55,6 % avec la description courte, 76,0 % avec les réponses à la liste de questions, 79,4 % avec les réponses de l'intervieweur et 91,0 % avec le document complet. La liste fixe a une faiblesse : elle décrit le comportement, mais pas les types des arguments ni les valeurs stockées, si bien que 88,7 % des signatures nécessaires sont implémentées, contre 94,8 % avec l'intervieweur.

Le gain s'observe aussi sur d'autres familles de modèles : avec Claude Sonnet 5, la précision passe de 56,1 % à 75,1 %, et avec Gemini 3.5 Flash, de 51,8 % à 74,5 %. Pour les trois familles de modèles, les auteurs estiment le gain apporté par les réponses du client simulé entre 19 et 23 points.

Les descriptions ne sont pas fiables non plus. Le modèle auditeur a trouvé au moins une contradiction avec l'original dans 76 descriptions sur 100, par exemple une règle d'accès inexistante. La clarification corrige donc souvent des affirmations fausses, et ne se contente pas de combler des manques. Parmi les 24 descriptions sans contradiction, le gain de la liste de questions se maintient, mais l'échantillon est trop petit pour une comparaison rigoureuse.

Combien de questions faut-il, et ce qui ne marche pas

Trois à cinq questions soigneusement choisies permettent de retrouver 60 à 75 % de l'ensemble du gain. Les étapes postérieures à la génération n'ajoutent pas plus d'un point, et la boucle automatique de correction de sécurité en retire 12,8 : elle supprime le comportement voulu en même temps que les vulnérabilités. Le pipeline final commence par interroger le client, confronte ensuite le contrat à un modèle de référence indépendant, puis présente les écarts au client sous forme de choix à l'aveugle. Pour la sécurité, il se contente de signaler les problèmes, sans réécrire le code.

Les limites sont importantes. Le client est simulé par GPT-5.4, qui lit le contrat d'origine : le gain constitue donc une estimation optimiste de ce qu'apporteraient de vrais auteurs. De vraies personnes répondront de façon moins complète et moins précise. Les intervalles ne tiennent pas compte de la variabilité d'une exécution à l'autre, et 36 critères ont été testés sans correction pour comparaisons multiples. Les auteurs publient le banc de test, les 600 tâches et toutes les évaluations.

Conclusion pratique pour ceux qui conçoivent des agents de génération de code : investir dans la clarification des exigences avant la génération, et ne pas se fier aux LLM utilisés comme juges ni aux « réparations » automatiques de sécurité sans les avoir validés sur des erreurs injectées.