Les agents d’IA onchain sont des systèmes logiciels qui transforment une instruction en action blockchain en combinant un raisonnement hors chaîne avec des comptes, contrats, paiements et reçus onchain. Dans la plupart des conceptions, le modèle lui-même fonctionne hors chaîne. Ce qui rend l’agent « onchain », c’est sa capacité à lire un état vérifiable ou à demander un changement d’état via un portefeuille fonctionnant selon des règles définies.

La version utile n’est pas un chatbot détenant une clé privée sans restriction. Les données sont horodatées, la transaction proposée est simulée, une politique décide si elle peut être exécutée, et le reçu est vérifié par rapport à l’instruction initiale. Cette distinction compte davantage que la présence ou non d’un jeton d’agent d’IA dans la pile, car la vraie question est toujours de savoir quelle couche peut observer, autoriser et vérifier l’action.

Que sont les agents d’IA onchain ?

Un agent d’IA connecté onchain peut lire l’état de la blockchain, comparer des options ou préparer une transaction non signée. Il ne devient autonome que lorsqu’il peut signer et soumettre une action spécifique dans les limites autorisées à l’avance par l’utilisateur. Les deux modèles combinent raisonnement, outils, compte et suivi des résultats, mais préparer du calldata relève de l’assistance, tandis qu’exercer un pouvoir de signature délégué relève de l’exécution autonome.

Un agent onchain ne doit pas être confondu avec tous les projets du secteur plus large de l’infrastructure IA crypto. Les réseaux de calcul vendent de la capacité de traitement, les plateformes d’agents coordonnent des logiciels et les comptes intelligents appliquent l’autorité. Ces couches peuvent être combinées, mais aucune ne devient autonome simplement parce qu’un jeton ou un contrat est présent. Un bot fondé sur des règles répète des conditions prédéfinies et peut soumettre des transactions, mais il n’interprète pas un objectif plus large ; un agent d’IA onchain autonome choisit des outils et des actions selon le contexte, puis ne signe que dans les limites déléguées. Un compte intelligent ne prend aucune décision par lui-même ; il applique les propriétaires, limites, modules, approbations et règles de récupération. Un rail de paiement x402 transporte et règle une autorisation de paiement machine signée sans décider si l’achat est utile.

L’identité est distincte du solde d’un portefeuille ou du nom d’un agent. Un système de production doit lier l’agent, l’opérateur, la version logicielle, le portefeuille, les points de terminaison du service et le responsable de révocation. L’aperçu d’Ethereum sur l’identité et la validation des agents montre comment les registres soutiennent la découverte et la réputation, mais l’enregistrement ne prouve pas qu’un résultat est correct. Cette frontière est importante dans les systèmes DeFAI, où une recommandation peut devenir un swap, un dépôt, un bridge ou un rééquilibrage ; les utilisateurs doivent donc voir quelle couche a proposé l’action et quelle couche a permis aux fonds de bouger.

Comment fonctionnent les agents d’IA onchain

Prenons une instruction : acheter 50 USDC d’ETH sur Base seulement si l’impact sur le prix reste inférieur à 0,5 %. Un WebSocket déclenche le flux lorsque le pool change, et l’agent lit le solde, le devis, la liquidité, le gas et l’heure du bloc. Des données obsolètes ou incomplètes arrêtent l’exécution avant la construction d’une transaction.

Le modèle compare les routes sans recevoir l’autorité finale. La simulation estime les variations de solde ; la politique vérifie la chaîne, les jetons, le contrat, la dépense, le slippage, l’échéance et la méthode. Le portefeuille réserve le nonce suivant dans une file avant de signer. Après règlement, la surveillance confirme la dépense, le minimum d’ETH obtenu, le contrat appelé et les approbations restantes. Une route modifiée, un appel réverti ou un résultat médiocre déclenchent une alerte plutôt qu’une nouvelle tentative silencieuse.

La séquence complète est visible pour l’utilisateur au lieu d’être cachée derrière un simple message de confirmation :

Read : Capturer le déclencheur WebSocket, le devis, le solde, la liquidité et l’horodatage du bloc. Des données manquantes ou obsolètes arrêtent la requête.

Decide : Sélectionner un pool et un minimum d’ETH obtenu. Un impact de prix attendu supérieur à 0,5 % rejette la route.

Simulate : Décoder l’appel et projeter les variations de solde. Un revert, une approbation cachée ou une route modifiée bloque la signature.

Enforce policy : Vérifier Base, le contrat approuvé, le plafond de 50 USDC et l’échéance par rapport au mandat initial.

Sign and settle : Réserver le nonce et utiliser une signature bornée. Un conflit, une session expirée ou un refus du signataire stoppe la soumission.

Verify : Comparer le reçu à la requête. Le mauvais actif, contrat, montant ou résultat déclenche une alerte.

Ce que les agents d’IA onchain peuvent faire aujourd’hui

Dans la DeFi, un agent peut surveiller une position de prêt, comparer le rendement net après coûts et rééquilibrer entre les marchés approuvés. Les utilisateurs doivent voir le bloc source, les contrats, la variation de solde attendue, la décision de politique et le reçu.

Pour les paiements machine, un agent peut demander une API ou un travail de calcul, recevoir les conditions x402, autoriser un montant plafonné en USDC et réessayer avec une preuve de paiement. Une seule autorisation doit produire un seul résultat livré ou un remboursement traçable, jamais un double prélèvement. Les agents peuvent aussi découvrir un fournisseur, vérifier son identité, acheter une tâche et enregistrer le résultat renvoyé. L’identité et le paiement rendent l’échange traçable, mais une preuve d’achèvement et un responsable de récupération restent nécessaires.

Cinq systèmes qui donnent de vraies capacités aux agents onchain

Les cinq exemples ci-dessous ne sont pas cinq agents interchangeables. Ils couvrent la découverte, les services autonomes, les outils de transaction, le contrôle des comptes et les paiements machine. Ensemble, ils montrent pourquoi les plateformes d’agents doivent être évaluées comme des piles complètes et non via un simple écran de démonstration.

Fetch.ai Agentverse : découverte d’agents

L’Agentverse de Fetch.ai aide les utilisateurs et les agents à découvrir des services, envoyer des requêtes structurées et recevoir des réponses. L’enregistrement ou le paiement peut toucher une chaîne tandis que la logique du service et les données restent hors chaîne. Un examen devrait consigner quel agent a répondu, sa source, son temps de réponse et les preuves d’achèvement.

Un bêta-testeur de DeltaV en juillet 2024 a passé une à deux heures sur cinq requêtes et n’a pas obtenu de résultats de bornes de recharge EV à proximité malgré un signalement d’environ 15 bornes. Ce test DeltaV précis est ancien et anecdotique, et ne constitue pas une mesure de fiabilité pour 2026. Il identifie néanmoins des vérifications utiles : temps de réponse, achèvement de la tâche, dépendance à la source et capacité du service à résoudre la demande.

Olas : coordination de services autonomes

Olas coordonne des services autonomes persistants via des composants enregistrés, des opérateurs et des comptes Safe. Les analystes devraient associer chaque ID de service et chaque opérateur à son Agent Safe ainsi qu’au propriétaire, ou Master Safe, capable de récupérer le contrôle.

Un évaluateur ayant utilisé un portefeuille Pearl a suivi ses interactions contractuelles sur GnosisScan plutôt que de se fier uniquement au tableau de bord de l’application. Ce parcours de portefeuille Pearl, consulté le 19 août 2026, est un test de publication limité, et non une mesure de disponibilité ou de support. Il offre néanmoins à un opérateur une vérification de propriété reproductible : copier l’adresse Agent Safe depuis Pearl, faire correspondre chaque transaction de registre et de service dans l’explorateur, et identifier le Master Safe capable de récupérer le contrôle avant de déposer davantage de fonds. Cela compte parce que la remédiation du registre Olas de juin 2026 a précisément renforcé le lien entre un service et son multisig.

Coinbase AgentKit : actions de portefeuille

Coinbase AgentKit fournit des requêtes de solde, des transferts et des appels de contrat pour les logiciels connectés à un portefeuille. Il relie les appels d’outils aux transactions mais ne décide pas si une route est pertinente. Les applications doivent borner les outils, le périmètre du compte, la chaîne, l’actif, le montant, la méthode et la durée de session.

Un développeur reliant AgentKit à x402 a constaté que des bibliothèques supposant un compte détenu de manière externe pouvaient échouer silencieusement parce qu’AgentKit utilisait un compte intelligent. Une nouvelle tentative a aussi payé deux fois avant la confirmation de la première transaction. Ce rapport d’intégration de deux semaines n’est pas un benchmark global de la plateforme, mais il produit deux contrôles de publication : détecter le type de compte et rendre les nouvelles tentatives payantes idempotentes.

Safe : permissions de compte intelligent

Safe sépare les propositions du modèle de l’autorité sur les actifs au moyen de propriétaires, seuils, modules et garde-fous. Chaque propriétaire, module, règle de dépense, chemin de mise à niveau et mécanisme de récupération doit être examiné, car un module trop puissant ou une interface illisible peut affaiblir un seuil solide.

Un participant de la communauté Safe testant la vérification entre appareils a constaté que les hachages et les détails décodés devaient être comparés sur des surfaces distinctes. Des tests ultérieurs ont montré qu’une interface de temporisation disparaissant pouvait créer un faux sentiment d’urgence. Ces expériences d’approbation Safe sont des observations individuelles, mais elles soutiennent le décodage et la confirmation d’actions de grande valeur sur un appareil qui n’a pas créé la proposition.

x402 : paiements machine

x402 permet à un logiciel de demander une ressource, recevoir des conditions de paiement, signer une autorisation, réessayer et obtenir la ressource après règlement. Il ne couvre que la couche de paiement du paysage plus large des protocoles de paiement pour agents IA.

Après six semaines d’utilisation de x402 pour monétiser un serveur MCP, un opérateur l’a retiré malgré avoir trouvé le mécanisme de paiement élégant. Ce compte rendu de première main décrit les nouvelles tentatives de paiement, la tarification par outil, les limites de débit du portefeuille, les remboursements après échec des tâches, les échecs silencieux de webhooks et l’exigence distincte pour les clients payant en dollars plutôt qu’en USDC. Un seul déploiement ne peut pas établir la fiabilité à l’échelle du protocole, mais il montre ce qu’un test de publication doit couvrir : répéter une requête après règlement, faire échouer volontairement la tâche payante et vérifier qu’une autorisation produit soit une réponse livrée, soit un remboursement traçable, jamais un second prélèvement.

Niveaux d’autorisation des agents d’IA onchain

Les capacités de recherche et l’autorité financière doivent être évaluées séparément. Passer d’un accès en lecture seule à une signature sans restriction crée de nouveaux vecteurs de perte et exige un responsable de contrôle plus solide. Une revue de 2026 portant sur 317 études pertinentes a séparé de la même manière l’analytique en lecture seule, la génération d’intentions, l’exécution déléguée, la signature autonome et les flux multi-agents, tout en comparant la garde, la politique, l’observabilité et la récupération.

La cible de production la plus sûre est généralement l’exécution bornée. Elle permet de faire respecter l’actif, la destination, le montant, la méthode et l’expiration en dehors du modèle. Une consigne peut être mal interprétée ; une politique de compte peut empêcher la signature d’un appel invalide.

Risques de sécurité des agents d’IA onchain

Les défaillances surviennent souvent aux points de transfert : les données deviennent obsolètes avant la signature, le calldata change après la simulation, ou le paiement est réglé alors que la réponse API est perdue. Un portefeuille peut aussi imposer un plafond tout en appelant une méthode autorisée avec des paramètres non voulus.

Les données obsolètes ou manipulées peuvent produire une recommandation convaincante à partir d’un ancien devis. Les horodatages, sources approuvées et limites de fraîcheur doivent les rejeter.

L’injection de prompt ou d’outil peut introduire une nouvelle destination ou une instruction cachée. L’isolation des outils et les listes d’autorisation de contrats maintiennent ce changement hors du chemin de signature.

La dérive de simulation se produit lorsque le calldata ne correspond plus à l’aperçu. La signature doit rester liée au calldata simulé et à l’échéance.

Une autorité de session excessive permet à une action valide de se répéter au-delà de l’intention de l’utilisateur. Les limites de montant, fréquence, actif, méthode et expiration contiennent les dégâts.

Les nouvelles tentatives payantes en double peuvent facturer à nouveau après un délai d’attente de l’API. Une clé d’idempotence doit relier la nouvelle tentative à son autorisation initiale.

Un règlement sans livraison laisse un paiement confirmé mais aucun résultat utile. Le reçu doit inclure une vérification de livraison et un chemin de remboursement ou d’escalade nommé.

Un modèle plus puissant peut améliorer l’acheminement, mais il ne peut pas remplacer des limites déterministes, la récupération, l’idempotence ni un reçu prouvant ce qui s’est passé.

Reçus de transaction et pistes d’audit

L’instruction de 50 USDC doit se conclure par un enregistrement reliant la requête au règlement. Ni une transcription de chat ni un hash de transaction seuls ne montrent quel devis, quelle limite et quelle politique ont produit le résultat.

Mandat et entrées : Acheter de l’ETH sur Base, dépenser au maximum 50 USDC, maintenir l’impact sur le prix en dessous de 0,5 %, et enregistrer le fournisseur du devis, la liquidité, le numéro de bloc et l’horodatage.

Action proposée et simulation : Conserver le routeur, les adresses des pools et des jetons, le montant, le minimum obtenu, l’échéance, le hash du calldata, les soldes projetés, l’estimation du gas et les changements d’approbation.

Politique et autorisation : Enregistrer la version de la règle, la raison d’acceptation ou de rejet, le compte intelligent, le signataire ou la session, le nonce réservé et l’expiration de permission.

Règlement et suivi : Joindre le hash de transaction, le bloc, les montants réels, l’écart demandé-par-rapport-au-réel, les approbations restantes, l’alerte et le responsable de récupération.

Avant d’augmenter la limite du portefeuille, tester un devis obsolète, un contrat bloqué, un montant excessif, une session expirée, un calldata modifié, un nonce en conflit et un délai après paiement. Chaque cas doit s’arrêter à la couche qui lui est assignée et rester visible dans l’enregistrement.

Conclusion

Les agents d’IA onchain relient des décisions hors chaîne à des comptes blockchain et à des changements d’état. Fetch.ai, Olas, AgentKit, Safe et x402 représentent la découverte, les services persistants, les outils d’action, la politique de compte et le paiement, plutôt qu’une catégorie de produit interchangeable. L’implémentation la plus solide montre pourquoi une action a été proposée, pourquoi la politique l’a autorisée, ce que le portefeuille a signé et si le règlement correspondait au mandat. Commencez par un travail observable, n’ajoutez une autorité bornée qu’aux flux répétables, et laissez la récupération hors du modèle.

Questions fréquentes

Dois-je disposer d’un jeton pour les agents d’IA onchain ?

Non. Une application peut combiner un modèle, des API de données, des outils de transaction et un compte intelligent sans émettre ni exiger de jeton dédié. Un jeton n’est utile que s’il remplit une fonction nécessaire comme le paiement, le staking, l’accès, la gouvernance ou la coordination.

Qu’est-ce qui fonctionne hors chaîne dans un agent d’IA onchain ?

Le modèle, la mémoire, le contexte privé, le traitement des données et la majeure partie de l’inférence s’exécutent souvent hors chaîne, car le calcul est coûteux et les entrées peuvent être sensibles. La blockchain enregistre plus souvent l’identité, les permissions, les paiements, les appels de contrat et l’état final.

Les comptes intelligents suffisent-ils pour les agents d’IA onchain ?

Non. Un compte intelligent peut appliquer des seuils, modules et limites, mais sa configuration doit toujours être examinée. Des modules dangereux, des listes d’autorisation trop larges, de longues sessions, une récupération faible ou des interfaces de signature illisibles peuvent compromettre la frontière du compte.

Avec quelles permissions de portefeuille un agent d’IA onchain devrait-il commencer ?

La surveillance en lecture seule et la préparation de transactions non signées exposent le moins d’autorité financière. L’exécution fondée sur approbation est l’étape suivante. L’automatisation bornée ne doit venir qu’après des tests en chemin négatif montrant que les actions invalides, obsolètes ou modifiées sont rejetées de manière fiable.

Avertissement : Les informations fournies sur AiCryptoCore.com sont destinées uniquement à des fins éducatives et informatives et ne constituent pas un conseil financier, d’investissement ou de trading. Les investissements en cryptomonnaies comportent des risques et peuvent entraîner des pertes financières. Faites toujours vos propres recherches et consultez un conseiller financier qualifié avant toute décision d’investissement.