IBM : des questions posées au client avant la génération font passer la fidélité des smart contracts de 54% à 73%

Les agents fondés sur de grands modèles de langage savent transformer une description en anglais courant en code qui compile et s'exécute. Mais personne ne mesure vraiment si ce code fait ce que voulait son auteur. Pour les smart contracts, la question est critique : ces programmes vivent sur une blockchain, stockent et transfèrent eux-mêmes de l'argent, et ne peuvent plus être corrigés une fois lancés.

Des chercheurs d'IBM T.J. Watson Research Center ont pris 600 contrats Solidity existants, fait décrire chacun en mots par un modèle, puis demandé à des agents IA de réécrire le contrat.

La fidélité est calculée comme la part de transactions sur lesquelles le nouveau contrat se comporte comme l'original. Le meilleur pipeline atteint 72,9% sur 500 contrats mis de côté. La génération « en une passe » donne 53,9%, l'ancien pipeline des auteurs 39,3%.

Ce sont les questions posées au client avant l'écriture du code qui aident le plus.

Ce que mesurait réellement la « compréhension »

La première partie du travail porte sur les instruments de mesure eux-mêmes, et ses conclusions sont peu flatteuses. Les chercheurs ont introduit à la main une unique règle erronée dans des contrats réels, puis observé si le vérificateur la repérait.

• L'analyseur statique Slither, conçu pour les classes de vulnérabilités connues, n'a émis un nouvel avertissement que pour 3 des 200 contrôles d'accès supprimés. • Un modèle de langage jouant le rôle de juge, qui lit le code, trouve beaucoup d'erreurs, mais signale 80% des contrats intacts. Si on lui impose de fournir une preuve exécutable, il y a moins de fausses alertes, mais il n'attrape plus que 30% des erreurs. • Un modèle de référence en Python, écrit à partir de la description, détecte 94,3% des erreurs typiques, comme un modificateur retiré ou une comparaison inversée. Mais le même modèle, écrit uniquement à partir des noms de fonctions, en détecte 87,5%.

Ce dernier chiffre est important. Il signifie que l'essentiel de ce que les tests ordinaires prennent pour de la compréhension de la tâche relève de la connaissance de schémas usuels, que possède n'importe quel modèle performant. C'est pourquoi les auteurs n'ont ensuite évalué que les règles propres à chaque contrat.

La fidélité de reproduction a été mesurée de façon stricte. Pour chaque contrat, les chercheurs ont généré 60 séquences aléatoires de 8 appels. Les mêmes appels ont été rejoués sur l'original et sur la copie, et une étape n'était validée que si le résultat était identique et si les mêmes valeurs observables changeaient. Une fonction manquante ou une signature différente fait échouer l'étape.

Où l'intention se perd

La description courte, de 140 mots, omet beaucoup de détails. La vérification a montré que 76 descriptions de ce type sur 100 contiennent au moins une contradiction directe avec le contrat, par exemple « l'administrateur peut ouvrir les enchères », alors qu'en réalité n'importe qui peut le faire. Il manque en moyenne 14,9 règles. La description complète, de 1700 mots, élimine ce problème.

Dans l'expérience, le modèle de référence a détecté 65,9% des erreurs propres au contrat avec la description courte, contre 87,5% avec la description complète. L'écart est de 21,6 points. Les contrats écrits par le générateur (GPT-5.4-mini, 92 contrats) montrent le même tableau :

• description courte : 55,6% ; • plus réponses aux questions d'un agent intervieweur : 79,4% ; • plus réponses à dix questions fixes : 76,0% ; • description complète : 91,0%.

Avec Claude Sonnet 5, le résultat passe de 56,1% à 75,1%, avec Gemini 3.5 Flash de 51,8% à 74,5%. Un exemple tiré de l'étude : la description d'un contrat de gestion de liquidité énumère les états et les opérations, mais ne dit pas qui peut les appeler. Le modèle a ajouté un rôle de propriétaire, et le contrat n'a coïncidé qu'avec 25% des transactions. Une seule réponse du client, « toutes les opérations sont ouvertes à n'importe quel compte », a fait monter la concordance à 100%.

Les vérifications après génération n'aident presque pas : toutes les étapes testées réunies ajoutent environ un point. La boucle automatique qui réécrit le code selon les remarques d'un auditeur de sécurité retire 12,8 points, parce qu'elle supprime le comportement nécessaire en même temps que le comportement risqué.

Combien de questions faut-il, et quelles réserves

Le pipeline avec questions interroge d'abord le client à l'aide d'une liste de contrôle. Il compare ensuite le contrat à un modèle de référence écrit indépendamment, et présente chaque divergence au client comme un choix à l'aveugle entre deux variantes. Il se contente de signaler les remarques de sécurité, sans réécrire le code. Trois à cinq questions bien choisies suffisent pour récupérer 60 à 75% du gain.

Principale réserve : le client était simulé par GPT-5.4, qui avait sous les yeux le contrat original. Le gain de 19 à 23 points, pour trois familles de générateurs, est donc une estimation optimiste de ce que donnerait un auteur réel. Par ailleurs, les originaux eux-mêmes sont imparfaits : dans le jeu de données initial, 35,1% des 21 976 contrats contiennent des fonctions vides (stubs) et 27,8% ont un corps de fonction composé uniquement de commentaires ; ils ont été filtrés. Le gain se maintient aussi sur 24 descriptions sans contradiction, même si un échantillon de cette taille ne permet pas de distinguer les sous-groupes.

Pour les ingénieurs, la conclusion est simple. Si un agent écrit du code qui déplace de l'argent, mieux vaut d'abord investir dans la clarification des exigences plutôt que dans des étapes de vérification supplémentaires. La « réparation » automatique à partir de rapports de sécurité doit être mesurée séparément : elle peut casser le comportement attendu. Les auteurs ont publié le banc d'essai, les tâches et toutes les évaluations.