Des outils, pas des tutoriels

Pourquoi l’infrastructure développeur pour les agents de codage IA doit être construite différemment, et comment le MvX Agent Hub la fournit

La documentation est lue par celui qui écrit le code. Pendant la majeure partie de l’histoire des systèmes programmables, ce lecteur était un développeur. En 2026, c’est de plus en plus un agent de codage IA : qui récupère des définitions d’outils, génère du code à partir de celles-ci et soumet des transactions pour le compte du développeur.

Le lecteur a changé.

MultiversX est conçu pour les charges de travail des agents au niveau de l’exécution. Supernova apporte une finalité inférieure à la seconde dans le cycle de décision de l’agent. Les rails de paiement se débloquent à la même vitesse. L’identité et la confiance sont composables en une seule transaction. Ce substrat doit encore être construit par quelqu’un. Le public qui construit désormais lit la documentation différemment.

Chaque éditeur est livré avec un agent

Chaque environnement de développement majeur a intégré la collaboration IA comme interface par défaut. Cursor et Windsurf ont reconstruit l’éditeur autour d’un agent dans la boucle. GitHub Copilot est passé de l’autocomplétion au mode agent. Claude Code et Codex sont livrés comme des environnements agentiques autonomes, Codex étant désormais intégré comme l’agent de codage intégré de ChatGPT.

Le changement réside dans les schémas d’utilisation, pas dans les annonces. Un développeur de 2026 construisant sur un système non trivial le fait avec un agent de codage comme auteur principal et l’humain comme relecteur.

La plupart des chaînes se présentent à travers une documentation que le nouveau lecteur ne peut pas utiliser correctement. Le code généré à partir d’une documentation narrative semble plausible mais est structurellement erroné. Les appels API s’écartent des signatures réelles. Les conventions mélangent des motifs de différentes chaînes. Les cas limites se trouvent trois pages après l’exemple. La chaîne sur laquelle un agent de codage finit par construire est celle qu’il peut lire.

Là où la documentation échoue

La documentation hiérarchique suppose un lecteur qui construit le contexte à partir des pages précédentes et le conserve. Un agent de codage ne récupère que la page pertinente pour la tâche immédiate. Le contexte inter-page est perdu. Chaque page doit tenir debout toute seule, avec des conventions et des anti-patrons intégrés au point d’utilisation.

Les exemples de SDK supposent un développeur qui lit, comprend ce que l’exemple démontre et l’adapte. Un agent de codage extrait le motif et génère directement à partir de celui-ci. Les exemples qui omettent les importations ou dépendent d’un contexte établi trois pages plus tôt produisent un code qui compile en bugs. L’exemple doit être suffisamment autonome pour être retranscrit proprement.

Les guides de type tutoriel supposent que le lecteur apprend le système. Un agent de codage n’apprend pas. Il génère. Il a besoin de la règle, pas de la pédagogie. « Utilisez toujours le motif de lecture de stockage inter-contrat synchrone pour les appels sur le même fragment » est plus utile que trois paragraphes expliquant pourquoi.

Ce n’est pas un problème de qualité de documentation. Les mêmes documents qui servent bien les lecteurs humains peuvent échouer complètement pour les lecteurs agentiques. Une documentation écrite pour un public ne sert pas automatiquement un autre.

Quand la chaîne rencontre l’agent

L’Agent Hub sur multiversx.com/ai se compose de trois systèmes distincts. Chacun répond à une partie différente de ce dont un agent de codage IA a besoin d’une chaîne. Ils sont souvent confondus. Ils ne font pas la même chose.

MCP donne des mains à un agent. Le serveur MCP MultiversX expose les capacités onchain du réseau en tant qu’outils structurés via le Model Context Protocol. Un agent fonctionnant sur Claude, Cursor ou tout client compatible MCP appelle ces outils pour vérifier les soldes, transférer des EGLD, émettre des tokens, minter des NFTs ou interroger l’état du réseau, sans formation spécifique à MultiversX. Les outils suivent le schéma standard de MCP. Les agents les découvrent et les invoquent de la même manière qu’ils gèrent tout autre outil dans l’environnement. La chaîne devient une capacité de plus dans la boîte à outils de l’agent.

Les compétences (Skills) donnent des connaissances à un agent. Le dépôt mx-ai-skills installe des fichiers de compétences modulaires dans l’environnement de codage de l’agent. Chaque fichier regroupe l’expertise sur un sujet MultiversX : motifs de contrats intelligents, conventions d’audit, optimisation du gaz, analyse statique, frontend dApp, tests de scénarios. Les compétences n’exécutent pas. Elles contraignent. Un agent chargé d’écrire un contrat intelligent MultiversX charge les compétences pertinentes et écrit un code qui correspond aux conventions réelles de la chaîne plutôt qu’à des motifs importés d’un autre écosystème. Un ensemble de fichiers de workflow configure l’agent dans un rôle spécifique : développeur de contrats Rust, auditeur de sécurité, architecte dApp, chacun avec sa propre surface de contrainte.

L’Agent Kit donne un environnement d’exécution à un agent. Le mx-agent-kit est le framework pour déployer des agents autonomes qui fonctionnent en continu comme leurs propres services, au-delà de ce qu’un assistant IA écrivant du code fournit. Il est construit sur le framework d’agent Eliza et la passerelle AI de Portkey, avec une intégration native à OpenAI Swarm, LlamaIndex, LangChain, LangGraph, AutoGen, CrewAI et Phidata. Un agent déployé via le Kit est un processus qui tourne de droit propre : de longue durée, adressable sur le réseau, avec sa propre identité onchain.

Le modèle mental est simple. MCP est la manière dont un agent fait des choses blockchain. Les compétences sont la manière dont un agent écrit du code MultiversX correct. L’Agent Kit est la manière dont un agent fonctionne comme son propre service. Mains, connaissances, environnement d’exécution.

Avant le code

Le dépôt de compétences s’ouvre par une règle comportementale qui est injectée dans le contexte de l’agent avant que tout code ne soit généré. Textuellement, telle qu’elle apparaît dans les fichiers de compétences :

Toujours demander des clarifications en cas d’incertitude.

Des contraintes spécifiques au domaine suivent. Sécurité arithmétique avec opérations vérifiées uniquement. Adhésion stricte au motif Checks-Effects-Interactions. Sécurité priorisée sur la commodité. La première règle s’applique au comportement. Les autres s’appliquent au code.

L’injection de contraintes avant la génération est ce qui réduit les taux d’hallucination. L’agent écrit dans un contexte qui interdit explicitement de deviner et exige des clarifications lorsque l’incertitude apparaît. Les compétences sont la surface de contrainte ; les fichiers de persona déterminent quelles contraintes s’appliquent pour quel rôle.

Le même principe traverse la couche MCP. Chaque outil expose des paramètres typés, des valeurs de retour structurées et des états d’erreur explicites. Un agent invoquant l’outil ne peut pas mal interpréter ce qu’il retourne. L’interface est lisible par machine sans ambiguïté, la même propriété que les compétences imposent au code généré.

Un principe de lisibilité, deux surfaces. L’interface d’invocation est contrainte. La génération de code est contrainte. La chaîne est lisible par les agents aux deux extrémités de la boucle.

Trois commandes pour un agent en direct

OpenClaw est le modèle de déploiement qui compose tout. Depuis l’Agent Hub :

Ce qui s’exécute est l’installation de la plateforme OpenClaw, le chargement des compétences MultiversX, la génération du portefeuille de l’agent, le provisionnement VPS avec SSL, pare-feu et vérifications de santé, et l’enregistrement d’identité onchain via MX-8004. Le déploiement produit une API Express, un frontend Next.js, une intégration de portefeuille et une identité onchain enregistrée. L’agent peut échanger des tokens, transférer des EGLD, staker et minter des NFTs dès son activation.

Le temps entre la décision de construire un agent et son fonctionnement onchain est de l’ordre de quelques minutes. Ce que cela consomme, c’est ce que la chaîne fournit déjà au niveau de la couche protocole : finalité inférieure à la seconde, transactions sans gaz via Relayed v3, identité MX-8004. L’Agent Hub est l’interface qui rend ces primitives utilisables pour le public qui construit désormais.

Ce que cela ouvre

Max était une preuve de concept légère. Fonctionnant sur devnet, Max a exécuté un flux Mystery Swap. Un utilisateur connectait un portefeuille et choisissait un montant. Max récupérait les données de token en direct de xExchange, décidait de l’allocation de token de manière autonome, exécutait des swaps contre la liquidité en direct et retournait les tokens achetés au portefeuille de l’utilisateur. Aucun humain dans la boucle du côté de l’agent. La pile complète composée en une seule interaction : découverte, autorisation, exécution, règlement, identité. Un second mode exposait la même identité d’agent sous forme de chatbot conversationnel.

Le schéma plus large est ce qui compte. Lorsque la chaîne est lisible par les agents de codage IA, le temps et les compétences nécessaires pour construire dessus s’effondrent. Un développeur avec une idée et un accès à un agent de codage peut produire un service onchain déployé en un après-midi. Un agent de domaine spécialisé pour un protocole spécifique devient un projet de week-end réalisable. L’ensemble des personnes capables de construire des services agentiques sur la chaîne s’élargit de plusieurs ordres de grandeur.

Un agent générant du code qui utilise l’identité MX-8004 ou les rails de paiement MPP lit à partir de la même surface de compétences qui enseigne les motifs de contrats et l’optimisation du gaz. La surface de contrainte couvre chaque primitive que la chaîne expose.

Ce que cela ouvre, ce sont plus d’agents. Le changement plus profond est une surface développeur différente, où la friction entre l’idée et le déploiement fonctionne à la vitesse de l’agent qui construit plutôt qu’à la vitesse de l’humain qui lit la documentation. Les chaînes qui existent à l’intérieur de cette surface sont celles qui voient les agents construits sur elles.

Ce qui est en ligne

L’Agent Hub est en ligne sur multiversx.com/ai. Le serveur MCP, le dépôt de compétences, l’Agent Kit et le modèle OpenClaw sont open source. L’Agent Explorer sur agents.multiversx.com montre les agents enregistrés et les travaux onchain qu’ils ont accomplis, le registre reposant sur des contrats d’identité MX-8004.

N’importe qui peut cloner le modèle OpenClaw, déployer un agent et le regarder s’enregistrer en quelques minutes. Un réseau d’agents vivant et consultable existe, sur une vraie chaîne, avec un véritable état onchain, attaché à de véritables primitives d’identité.

Une chaîne que vous pouvez lire

La chaîne doit être lisible par celui qui écrit le code. En 2026, c’est de plus en plus un agent de codage IA opérant pour le compte d’un développeur humain, et la documentation, les SDK et l’infrastructure d’exécution qu’il lit ne sont pas les mêmes artefacts qu’un lecteur humain nécessite.

Des définitions d’outils lisibles par machine pour que la chaîne puisse être invoquée. Des contraintes structurées pour que le code généré soit correct. Un framework d’exécution pour que les agents construits puissent fonctionner comme des services de droit propre.

Avec la surface construite pour les agents et le développement agentique, Supernova ajoutera l’exécution : rapidité, composabilité, évolutivité.