L’IA va au-delà des systèmes qui se contentent de répondre aux questions.
Nous sommes passés des chatbots aux assistants capables d’utiliser des outils, puis aux agents capables de naviguer sur le web, de travailler avec des fichiers, d’appeler des API et d’exécuter des tâches en notre nom.
Mais à mesure que les agents deviennent plus capables, une question plus large se pose :
Que se passe-t-il quand une IA peut réellement agir ?
Cela rend l’architecture des agents tout aussi importante que l’intelligence du modèle.
C’est le problème que @NEAR Protocol l’IA cherche à résoudre avec IronClaw 1.0, un framework sécurisé et open source d’agent IA, développé en Rust.
Son idée centrale est simple : séparer la partie qui décide de celle qui agit.
Le modèle raisonne sur ce qui devrait se passer. Les outils, les identifiants, les fichiers et l’accès réseau se trouvent du côté de l’exécution. Entre les deux, il y a une couche unique de coordination appelée le guard, par laquelle les actions doivent passer.
Cette séparation architecturale est le socle de tout le reste.
Les chiffres derrière IronClaw
#ironclaw La 1.0 a été lancée le 27 juillet 2026, et l’un des points forts de la version est l’ensemble de données de référence.
En utilisant le même modèle de base, deepseek-v4-flash, sur les bancs d’essai d’agents comparés, IronClaw a enregistré :
➜ PinchBench — 93,5 %
➜ ClawBench — 88,6 %
➜ OfficeQA — 76,4 %
▪︎ PinchBench teste 147 tâches réelles couvrant des domaines comme la planification, l’e-mail, le codage, la recherche et la gestion de fichiers.
▪︎ ClawBench se concentre sur l’interaction web en direct sur plus de 140 sites web de production et évalue des tâches multi-étapes comme les réservations, les demandes et les achats.
▪︎ OfficeQA se concentre sur le raisonnement basé sur des documents à travers un large corpus de documents du Trésor américain, y compris des documents numérisés, des tableaux denses et des millions de valeurs numériques.
Le point important n’est pas seulement qu’IronClaw a obtenu un score élevé.
Le modèle sous-jacent était le même.
Cela suggère que le banc d’essai lui-même ; la manière dont l’agent gère les outils, les permissions, l’état et l’exécution ; peut avoir un effet significatif sur ce que le modèle est capable d’accomplir.
Mais il y a une mise en garde importante : IronClaw ne mène pas l’ensemble de chaque benchmark. La recherche indique aussi qu’il est en retrait sur des benchmarks comme Gaia et sur une séparation SWE-lite.
Cela rend la comparaison plus crédible. La promesse n’est pas qu’IronClaw soit universellement meilleur pour tout, mais que son architecture soit performante sur les catégories de tâches spécifiques mises en avant dans la version 1.0.
Qu’est-ce qui rend IronClaw vraiment différent ?
Les plus grandes améliorations sont architecturales plutôt que cosmétiques.
1. La sécurité est intégrée au chemin d’exécution
Les actions sensibles peuvent nécessiter une approbation explicite de l’humain, tandis que les autorisations basées sur les capacités contrôlent ce qu’un agent a le droit de faire.
Les identifiants sont aussi maintenus à distance du contexte du modèle, les secrets étant gérés via une couche de sécurité plus isolée.
C’est important car un agent ayant accès à l’e-mail, aux fichiers, aux API ou aux systèmes financiers dispose d’une surface d’attaque bien plus grande qu’un chatbot.
2. Le travail survit aux interruptions
IronClaw utilise le checkpointing continu.
Si un agent est à mi-chemin d’une longue tâche et a besoin d’une approbation, est redémarré ou rencontre une interruption, son état peut être préservé afin que le travail puisse continuer au lieu de repartir de zéro.
Cela transforme l’interruption, d’une défaillance totale, en une pause.
3. Un assistant sur plusieurs canaux
IronClaw peut fonctionner via la CLI, le web, Slack et Telegram tout en conservant une mémoire partagée et les mêmes politiques de guard.
Pour les entreprises, c’est important car l’agent ne devient pas un système complètement différent à chaque fois que l’interface change.
4. Conçu pour les équipes
IronClaw prend en charge les déploiements multi-locataires, où les organisations peuvent partager des outils et des compétences tout en gardant des espaces de travail individuels privés par défaut.
Pour les équipes qui exigent une isolation plus forte, le déploiement en mono-locataire offre une séparation complète.
L’idée sous-jacente est simple :
partager des capacités sans partager inutilement l’accès.
Où NEAR AI s’insère
IronClaw n’est qu’une partie de la pile plus large #NEARAI .
NEAR AI combine une infrastructure d’agents sécurisée et le calcul confidentiel grâce aux Trusted Execution Environments (TEEs), où les charges de travail peuvent s’exécuter dans des environnements isolés par le matériel.
La pile plus large inclut NEAR AI Cloud, l’inférence confidentielle, IronClaw, l’hébergement OpenClaw et des intégrations avec l’infrastructure #crypto de NEAR, comme Intents et Chain Signatures.
Cela crée une séparation intéressante des responsabilités :
IronClaw sécurise l’exécution de l’agent.
Les TEE protègent l’environnement dans lequel se produit le calcul sensible.
NEAR fournit l’infrastructure crypto pour l’identité, les transactions et les paiements.
Et il y a ensuite la partie que je trouve particulièrement intéressante : le staking.
Le Staking, c’est plus que du rendement
NEAR AI a introduit le Staking pour NEAR AI le 30 juillet 2026.
L’idée est différente du simple fait de payer l’infrastructure d’IA avec une carte de crédit.
Les utilisateurs peuvent verrouiller du NEAR et recevoir des crédits d’IA récurrents pour des services tels que l’hébergement d’IronClaw et l’inférence confidentielle, tout en conservant la propriété du stake sous-jacent.
Pour l’hébergement d’IronClaw, la politique actuelle est :
NEAR mis en jeu ÷ 100 = budget mensuel en crédits USD
Le stake minimal pour activer un agent IronClaw est actuellement de 50 NEAR, le premier agent étant conçu pour être opérationnel en environ 30 secondes.
Ces chiffres sont des paramètres de politique issus du lancement du 30 juillet 2026 et peuvent évoluer avec le temps.
Mais il y a une distinction importante à ne pas négliger.
Le staking de NEAR AI n’est pas la même chose que le staking au niveau du protocole.
Le staking au niveau du protocole sécurise la blockchain NEAR via des validateurs et des délégateurs.
Le staking de NEAR AI relie plutôt du NEAR verrouillé à l’usage de l’IA, comme l’hébergement d’agents et l’inférence confidentielle.
Ce sont des mécanismes différents, mais ils pointent vers la même idée globale : l’actif qui sécurise le réseau peut aussi devenir une partie de l’infrastructure économique qui alimente des applications construites autour de lui.
L’image d’ensemble
C’est pourquoi je pense que l’histoire d’IronClaw est plus intéressante que de simplement lancer un autre agent IA.
Le pari principal consiste à connecter plusieurs couches :
exécution sécurisée → calcul confidentiel → propriété native de la crypto → activité agentique
Si, à terme, les agents doivent gérer des informations sensibles, interagir avec des entreprises, détenir des identités, effectuer des paiements et exécuter des transactions, alors l’infrastructure qui les entoure doit gérer plus que l’intelligence.
❍ Il lui faut de la sécurité.
❍ Il lui faut de la persistance.
❍ Il lui faut de la confidentialité.
Et, à terme, il lui faut une couche économique.
C’est ce qui rend l’approche de NEAR AI digne d’être surveillée.
La thèse à long terme peut se résumer simplement :
Le capital finance le calcul.
Le calcul fait tourner les agents.
Les agents créent une activité onchain.
Reste à prouver que cela devienne un nouveau modèle significatif pour l’infrastructure IA.
Mais le fait que l’architecture se construise autour d’IronClaw et de NEAR AI suggère que l’industrie pourrait évoluer vers un avenir où la question n’est pas seulement :
« À quel point l’agent est-il intelligent ? »
mais aussi :
« Peut-on lui faire confiance pour un vrai travail ? »