Contrats blockchain : l’IA peut coder ce qui tourne sans suivre la demande

Une IA peut aujourd’hui écrire un programme à partir d’une simple description en langage courant. Mais un programme qui se lance sans erreur n’est pas forcément un programme qui fait ce qu’on a demandé. Une étude publiée sur arXiv mesure cet écart sur les smart contracts, des programmes financiers qu’on ne peut plus corriger une fois en service.

Un code qui tourne n’est pas un code juste

Si vous confiez la rédaction d’un programme à un agent IA, votre premier réflexe sera sans doute de vérifier qu’il « marche ». C’est précisément ce réflexe que l’étude remet en question.

Les auteurs partent d’un constat qu’ils posent dès la première phrase de leur résumé, rédigé en anglais : les agents IA savent écrire du logiciel à partir d’une description en langage courant, mais un code qui s’exécute n’est pas pour autant un code qui fait ce qui a été demandé. Un agent IA, ici, est un programme d’intelligence artificielle qui enchaîne seul plusieurs étapes : comprendre la demande, écrire le code, le tester, le corriger.

Une image aide à saisir l’écart. Imaginez des plans de maison qui respectent toutes les normes électriques et de sécurité, mais où la cuisine a été oubliée. Rien n’est « en erreur », et pourtant le plan ne répond pas à la commande. En clair : l’absence de bug ne prouve pas que la demande a été respectée.

Pourquoi les smart contracts rendent l’erreur définitive

Cet écart devient dangereux quand l’erreur ne peut plus être réparée. C’est le cas des smart contracts, que l’étude choisit comme terrain d’essai.

Une blockchain est un registre numérique partagé, copié sur de nombreux ordinateurs, où les écritures sont conservées. Un smart contract, ou « contrat intelligent », est un programme inscrit sur ce registre. Il s’exécute automatiquement : il peut, par exemple, déclencher un paiement quand une condition est remplie. Les auteurs le décrivent comme le programme qui se trouve derrière les applications du Web3, c’est-à-dire les services qui déplacent de l’argent sur une blockchain.

Le point décisif figure dans le résumé : ces contrats ne peuvent pas être corrigés une fois déployés. Un logiciel classique reçoit des mises à jour. Un smart contract mis en ligne, lui, reste tel quel.

En clair : une faute de rédaction dans un contrat papier se renégocie. Ici, le code qui s’exécute est le contrat, et il ne se renégocie pas.

La question de départ reste donc ouverte : qui paie quand le contrat fait autre chose que ce qu’on voulait ? Le résumé ne traite pas la responsabilité, ni juridique ni financière. Il documente seulement l’écart technique qui rend la question légitime.

Comment les chercheurs mesurent l’écart

Pour savoir si un contrat écrit par une IA fait ce qu’il doit, encore faut-il disposer d’un bon moyen de le vérifier. Les auteurs construisent leur évaluation sur l’exécution plutôt que sur l’opinion.

Leur méthode consiste à rejouer les mêmes transactions sur deux contrats : celui écrit par l’IA et l’original qu’il devait reproduire. Une transaction est une opération envoyée au contrat, par exemple un paiement. Les chercheurs mesurent ensuite la fréquence à laquelle les deux contrats réagissent de la même façon. C’est un peu comme donner la même commande à deux machines et comparer ce qui en sort.

Ils testent aussi leurs propres outils de notation :

• chaque outil est essayé sur des erreurs volontairement plantées, pour voir s’il les détecte ;
• les résultats sont comparés à un corrigé écrit sans avoir lu la description fournie à l’IA ;
• leur propre correcteur est audité jusqu’à ce que des réponses connues comme fausses ne puissent plus passer.

Les résultats sont peu rassurants pour les méthodes courantes. Selon les auteurs, les « juges IA » (des IA chargées de noter le travail d’autres IA) et les outils d’analyse standard ratent des erreurs pourtant évidentes. Le choix de ce qu’on note compte aussi : vérifier seulement les fonctions que tous les systèmes comparés incluent a masqué environ la moitié de la différence entre les chaînes de production testées.

En clair : la façon de mesurer change le verdict. Un contrôle trop étroit peut faire croire que deux méthodes se valent alors qu’elles divergent.

Poser les questions avant d’écrire

Les chercheurs ne se contentent pas de mesurer, ils proposent une architecture dite « elicitation-first », c’est-à-dire « d’abord faire préciser le besoin ». Avant d’écrire la moindre ligne, l’agent soumet au client une courte liste de questions. Il écrit ensuite le contrat et le compare à un modèle exécutable rédigé de façon indépendante, qui joue le rôle de corrigé. Quand les deux divergent, l’agent ne réécrit pas le code en silence : il renvoie les désaccords au client.

Selon l’étude, sur trois modèles d’IA, poser des questions d’abord compte beaucoup plus que relire ou rapiécer après coup. Les correctifs de sécurité automatiques, eux, cassent souvent le comportement demandé. Un correctif censé boucher une faille peut donc faire disparaître une fonction que le client voulait.

Les auteurs avancent aussi que quelques questions bien choisies récupèrent une bonne part de ce qu’une description courte oublie, et que leur valeur peut être estimée sans disposer du contrat original. Ils affirment que c’est, à leur connaissance, la première étude du domaine à recueillir les exigences manquantes avant la génération, puis à vérifier le résultat contre un modèle exécutable indépendant.

Quelques réserves s’imposent. Il s’agit des résultats des auteurs, sur leurs 600 tâches, et le résumé ne donne pas de chiffres précis sur l’ampleur de l’écart. L’étude est aussi une proposition de méthode, pas la preuve que l’architecture protège dans tous les cas réels. L’avantage, c’est que les outils, les 600 tâches et l’ensemble des résultats sont publiés : d’autres équipes peuvent les reprendre et contester les conclusions.

Et quand on délègue autre chose que des contrats ?

L’étude porte sur les smart contracts. Les auteurs écrivent toutefois que leurs leçons s’étendent à tout cadre où des agents IA transforment des demandes en programmes. Cette généralisation est la leur, et le résumé seul ne permet pas de la vérifier. Elle invite néanmoins à poser la même question ailleurs.

Un indépendant qui fait écrire un script de facturation, une PME qui automatise un calcul de remises, un salarié qui délègue une tâche à un agent : tous reçoivent un résultat qui « tourne ». La différence avec la blockchain, c’est qu’une erreur se rattrape en général plus facilement. Mais pas toujours, surtout si personne ne sait relire le code.

Quelques questions découlent de cette étude, sans qu’elle les tranche :

• Qui a écrit le critère de réussite : vous, l’IA, ou personne ?
• Le contrôle compare-t-il le résultat à votre demande, ou seulement à ce que l’IA a elle-même compris ?
• L’agent vous a-t-il posé des questions, ou a-t-il comblé seul les trous de votre description ?
• Peut-on revenir en arrière si le résultat est faux ?

On peut le tester soi-même : avant de confier une tâche à un agent, lui demander de lister ses hypothèses, puis comparer cette liste à ce qu’on voulait. Ce n’est pas une recommandation de l’étude, juste un moyen concret de voir où votre intention risque de se perdre. Reste à savoir si les outils du marché adopteront ce réflexe de poser des questions avant d’agir.

Sources

• Measuring Where Intent Gets Lost in Agentic Smart Contract Synthesis (arXiv:2610.37830)