Imaginez une entreprise où n’importe qui peut proposer un virement bancaire. Le marketing peut en demander un, l’ingénierie peut en demander un, les RH peuvent en demander un. Mais peu importe qui l’initie, l’argent ne bouge pas tant qu’il n’est pas passé par un guichet unique d’approbation qui applique les mêmes vérifications à chaque fois. Aucun service n’a de porte dérobée. C’est l’idée de base derrière IronClaw 1.0 de NEAR AI : l’agent peut raisonner sur ce qu’il veut faire, mais l’action elle-même doit passer par une couche unique de coordination avant de pouvoir s’exécuter.
Cette distinction compte, car les agents IA vont au-delà de la génération de texte et de la réponse à des questions. Ils peuvent parcourir des sites web, manipuler des fichiers, interagir avec des services externes, utiliser des identifiants, envoyer des messages et accomplir des tâches multi-étapes pour le compte d’un utilisateur. Une fois qu’un agent peut agir dans le monde réel, le défi n’est plus seulement de savoir si son modèle sous-jacent est assez intelligent. Il s’agit de savoir si l’infrastructure entourant ce modèle peut contrôler de manière fiable ce qu’il est autorisé à faire.
L’architecture : séparer la réflexion de l’action
#IronClaw 1.0 adopte une approche architecturale fondamentalement différente. Au lieu de laisser le raisonnement, l’exécution, la mémoire, les secrets et les outils fonctionner comme des composants fortement couplés, elle sépare la couche de raisonnement de la couche d’exécution et place un point de coordination unique appelé le « guard » entre les deux. Toute action, quelle que soit la capacité à l’origine de son déclenchement, doit passer par ce point de contrôle avant d’être exécutée.
L’importance de cette conception est facile à sous-estimer. Lorsque des garde-fous sont implémentés indépendamment dans différents outils et capacités, chaque nouvelle fonctionnalité crée un autre endroit où ces contrôles doivent être appliqués correctement. Un garde-fou centralisé crée plutôt un chemin d’exécution commun, permettant au même raisonnement d’autorisation et de sécurité de régir les actions dans l’ensemble du système. Concrètement, l’architecture ressemble davantage à Think ➔ Guard ➔ Act qu’au modèle conventionnel Think ➔ Act.
L’architecture répond aussi à un problème moins évident : la continuité. IronClaw utilise une sauvegarde continue par points de contrôle (checkpointing), afin qu’une tâche interrompue puisse reprendre depuis son état précédent plutôt que d’obliger l’agent à recommencer. Si un workflow se met en pause en attendant une approbation, rencontre un redémarrage ou est interrompu à mi-exécution, les progrès déjà réalisés peuvent être préservés et la tâche reprise à partir de son dernier checkpoint.
Benchmarks : performances sur différentes « surfaces d’échec »
L’architecture seule ne suffit pas. Un agent peut être extrêmement prudent et pourtant se révéler pratiquement inutile s’il ne parvient pas à accomplir les tâches qui lui sont confiées. En utilisant le même modèle de base deepseek-v4-flash pour les comparaisons, #IronClaw mène actuellement trois benchmarks d’agents différents, chacun testant une dimension différente des performances dans le monde réel.
Sur PinchBench, #IronClaw obtient 93,5 % sur 147 tâches pratiques couvrant la planification, le tri d’e-mails, le codage, la recherche et la gestion de fichiers. Sur ClawBench, qui évalue des interactions multi-étapes sur plus de 140 sites web de production en direct, il atteint 88,6 %. OfficeQA teste le raisonnement sur un grand corpus de bulletins du Trésor américain couvrant près d’un siècle, 89 000 pages et plus de 26 millions de valeurs numériques ; IronClaw obtient 76,4 %.
Ces benchmarks mettent l’accent sur des capacités différentes : PinchBench souligne la réussite pratique des tâches, ClawBench introduit l’imprévisibilité des environnements web en direct, et OfficeQA teste le raisonnement sur des documents complexes et des informations numériques. Être en tête sur les trois suggère que les performances ne dépendent pas uniquement du modèle sous-jacent ; l’agent lui-même et l’architecture qui l’entoure contribuent aussi de manière significative.
D’une démo à un système que les gens peuvent réellement utiliser
L’architecture devient plus convaincante lorsqu’elle est associée aux contrôles conçus pour un usage réel. IronClaw peut exiger une approbation explicite avant l’exécution d’actions sensibles, plutôt que de permettre à un agent d’agir d’abord puis d’expliquer après coup. Il prend aussi en charge des secrets à usage unique qui peuvent être effacés des journaux après utilisation, réduisant ainsi la quantité d’informations sensibles qui persistent dans le système.
La même philosophie s’étend à la mémoire et à la collaboration. IronClaw conserve des règles cohérentes de mémoire et de sécurité entre CLI, web, Slack et Telegram, plutôt que de traiter chaque interface comme un assistant isolé. Pour les organisations, l’isolement des équipes permet de partager des outils et des compétences tout en gardant les espaces de travail individuels privés par défaut, avec en plus une option entièrement isolée en mono-tenant pour les équipes qui exigent une séparation plus stricte. et #NEARAI font déjà tourner IronClaw en interne sur leurs équipes, offrant ainsi un terrain de test pratique pour ces choix de conception au-delà d’une simple démonstration produit.
Où NEARAI et le Staking s’intègrent
Un agent compétent a encore besoin d’inférence, de calcul et d’une infrastructure fiable pour fonctionner en continu. C’est là que #NEARAI intervient. Au lieu de considérer le calcul IA comme un service entièrement distinct, payé via des contrats d’infrastructure conventionnels, NEAR AI relie l’accès aux services d’IA à la participation à l’écosystème NEAR grâce à son modèle de staking.
Pour l’hébergement d’agents, la structure repose sur un ratio fixe : NEAR mis en jeu ÷ 100 = le budget mensuel de crédits en dollars. Mettez 500 NEAR en staking et vous recevez 5 $ de crédits chaque mois tant que les tokens restent mis en jeu. La formule Starter démarre à 50 NEAR et active le premier agent IronClaw, tandis que les paliers supérieurs débloquent des allocations de crédits plus importantes et des agents parallèles supplémentaires. Le NEAR sous-jacent n’est pas consommé : il reste l’actif de l’utilisateur.
L’inférence confidentielle fonctionne différemment. Ici, les récompenses de staking générées par la position de l’utilisateur (le réseau actuel affiche un APY d’environ 4,5–4,7 %) sont dirigées vers NEAR AI en échange de crédits de calcul, plutôt que d’être versées comme revenu. Le capital reste sous le contrôle de l’utilisateur et peut être retiré (un-staked) via le processus standard du protocole. L’infrastructure globale donne aussi accès à des modèles fournis par des acteurs tels qu’Anthropic, OpenAI et Google.
Point important : le staking sur NEAR ne sert pas uniquement aux rendements. Il sécurise l’infrastructure décentralisée sous-jacente dont ces agents IA, y compris le prochain OpenClaw, auront besoin. En liant l’accès au calcul à la participation au réseau, #NEARAI crée une relation plus étroite entre la sécurisation du réseau et l’alimentation des applications qui y tournent.
Le tableau d’ensemble
C’est finalement pour cela que #IronClaw 1.0 est plus intéressant qu’une autre annonce concernant un agent IA plus performant. Le changement important en IA autonome n’est pas simplement que les modèles apprennent à faire plus. C’est que l’infrastructure autour de ces modèles commence à traiter l’autonomie comme un problème de systèmes impliquant des permissions, l’exécution, la mémoire, la récupération, l’isolement et le calcul—plutôt que comme une question d’intelligence seule.
IronClaw résout ce problème au niveau de l’exécution en séparant le raisonnement de l’action, en faisant passer les actions par un garde-fou centralisé, en préservant l’état en cas d’interruption, en contrôlant les opérations sensibles et en maintenant des règles de sécurité cohérentes entre différentes interfaces. #NEARAI traite une autre partie de la pile en reliant l’accès au calcul IA à la participation à un réseau décentralisé et en fournissant une infrastructure sur laquelle les agents peuvent réellement s’exécuter.
Pris ensemble, ces éléments pointent vers une direction plus large pour l’infrastructure IA. L’avenir des agents autonomes ne dépend peut-être pas uniquement de la capacité d’un modèle à accomplir des choses sans intervention humaine, mais plutôt de la fiabilité avec laquelle les systèmes autour de ce modèle peuvent contraindre ses actions, récupérer en cas de problème, préserver le contexte dans le temps et fournir l’infrastructure nécessaire pour le maintenir en fonctionnement.
Les agents plus intelligents ne sont qu’une partie de l’équation. Le défi le plus déterminant pourrait être de construire l’infrastructure qui rend ces agents suffisamment dignes de confiance pour agir.
Vous pouvez lire cela sur 𝕏 : https://x.com/Cryptfancier/status/2096337705550434561
Sources
╰─➤ Présentation d’IronClaw 1.0 (blog NEAR AI) : https://near.ai/blog/introducing-ironclaw-1-0
╰─➤ Staking pour NEAR AI (blog NEAR AI) : https://near.ai/blog/staking-for-near-ai
╰─➤ Annonce officielle du protocole NEAR : https://x.com/NEARProtocol/status/2082875217995796606
╰─➤ Référentiel IronClaw GitHub : https://github.com/nearai/ironclaw
╰─➤ Documentation d’NEAR AI Private Inference : https://docs.near.ai/cloud/private-inference
╰─➤ Rewards de staking – données de rendement en direct NEAR : https://www.stakingrewards.com/asset/near-protocol