Et si le prochain vrai test du XRP Ledger n’était pas un nouveau jeton, mais une manière plus propre de faire voyager plusieurs opérations ensemble ? C’est précisément ce que laisse entendre Ripple en cette mi-septembre 2026. Selon le responsable ingénierie de RippleX, des asset managers et des projets commerciaux préparent déjà des usages autour de Batch V1.1, cette fonction capable de regrouper jusqu’à huit transactions dans une seule opération. Le détail qui agace autant qu’il intrigue : les noms des maisons de gestion restent dans l’ombre.
Pourquoi Batch V1.1 Fait Bouger Les Institutions
Le marché des crypto-actifs a longtemps vendu la vitesse. Les salles de marché, elles, vendent surtout la certitude. Un transfert d’actif qui part sans le paiement correspondant, ou l’inverse, n’est pas une anecdote technique. C’est un risque de règlement. Batch s’attaque à ce point précis : lier plusieurs jambes d’une opération pour qu’elles réussissent ensemble, ou n’aient aucun effet.
Le 19 septembre, CoinDesk rapportait les propos d’Ayo Akinyele. Le 20 septembre, les données publiques de vote montraient encore 30 validateurs de confiance sur 35 en faveur de l’amendement. Le seuil requis pour poursuivre le compte à rebours est de 28 voix, soit 80 % maintenus pendant quatorze jours d’affilée. Le chronomètre a démarré le 15 septembre à 14 h 06 min 41 s UTC. S’il ne casse pas, l’activation se profile juste après la même heure le 29 septembre.
Nous partagerons davantage une fois la fonctionnalité en ligne, y compris le travail avec des asset managers clés.
Ayo Akinyele, RippleX
La phrase est courte. Elle suffit pourtant à changer le ton du débat. Tant que Batch n’est qu’un objet de spécification, on parle d’ingénierie. Dès que des gérants d’actifs « construisent autour », on parle de pipeline commercial. Ripple n’a pas publié de liste de partenaires, ni de calendrier de mise en production. L’annonce reste donc une description d’entreprise, pas encore un dossier documenté par des communiqués nominatifs.
Ce Que Change Un Lot De Huit Transactions
La spécification XLS-56 définit Batch comme une transaction enveloppe. Elle emballe entre deux et huit transactions internes. Quatre modes de traitement existent : tout ou rien, une seule, jusqu’à l’échec, et indépendant. Le mode tout ou rien est celui qui parle le plus aux institutions. Si une jambe échoue, le lot n’a pas d’effet. Plus de demi-règlement. Plus de course pour rattraper une jambe orpheline.
Imaginez une livraison contre paiement, le fameux delivery versus payment. D’un côté, un titre tokenisé. De l’autre, un règlement en cash on-chain, éventuellement via un stablecoin. Les deux mouvements peuvent entrer dans le même lot. Si le paiement ne passe pas, le titre ne bouge pas. C’est banal dans les infrastructures traditionnelles bien cadrées. Sur un registre public, c’est encore assez rare pour que les équipes produit s’y collent à l’avance.
Ce que Batch permet concrètement, sans en faire un miracle.
- Regrouper jusqu’à huit opérations liées dans une seule enveloppe.
- Exiger que toutes les jambes aboutissent, ou qu’aucune ne s’applique.
- Laisser plusieurs comptes autoriser chacun une partie du même lot.
- Servir des cas comme le swap multi-comptes, les frais de plateforme ou certaines structures de prêt flash.
Un marché ou un portefeuille peut, par exemple, coller le paiement d’un client et la commission du service dans le même lot. Plus besoin d’enchaîner deux allers-retours et d’espérer que rien ne se passe entre les deux. Différents comptes peuvent signer des jambes distinctes. C’est utile dès que l’on sort du schéma « un utilisateur, une signature, un mouvement ».
Le Compte À Rebours Du 29 Septembre N’Est Pas Un Sceau
Sur XRPL, un amendement ne s’active pas parce qu’il a dépassé 80 % une fois. Il faut tenir la supermajority pendant quatorze jours complets. Les validateurs peuvent changer d’avis pendant que l’horloge tourne. Si le soutien retombe sous le seuil, la fenêtre s’arrête. Il faudra alors reconstruire une période ininterrompue.
Au 20 septembre, XRPLDashboard affichait 30 voix favorables sur 35 validateurs suivis, soit environ 85 %. Le filet de sécurité est donc réel, mais mince. Plus tôt dans le mois, Batch V1.1 n’avait que 24 voix sur 35, soit 68,57 %. Le 15 septembre, le tally était monté à 27, juste avant que le compte à rebours ne démarre. La progression a été rapide. Elle reste réversible.
L’amendement a voyagé avec xrpld 3.3.0, publié le 6 août. Les notes officielles le présentent comme le remplaçant du Batch d’origine. Il autorise jusqu’à huit transactions internes, y compris des structures de swap atomique. Depuis, la Fondation XRP Ledger a sorti la 3.4.0, le 16 septembre. Cette version apporte d’autres amendements, notamment autour du prêt et de nettoyages protocolaires. Elle ne remplace pas Batch V1.1, qui suit son propre vote mainnet. Les opérateurs de serveurs ont simplement été invités à monter en 3.4.0 pour la continuité de service.
La Cicatrice De Février N’Est Pas Un Détail
On ne peut pas raconter Batch V1.1 comme une simple montée de version. En février, les équipes ont stoppé la première proposition. La divulgation officielle de vulnérabilité indique que le chercheur Pranamya Keshkamat et l’outil Apex de Cantina AI ont identifié, le 19 février, une faille critique de validation de signatures.
Dans certaines conditions, le code vulnérable cessait de vérifier les signataires d’un Batch après avoir rencontré un compte tout juste créé. XRPL Labs a expliqué qu’un attaquant aurait pu glisser une transaction non autorisée depuis un autre compte, sans posséder les clés privées de son propriétaire. Paiements et certains changements d’état du registre entraient dans le champ des possibles.
La faille n’est jamais devenue active sur le mainnet. L’amendement d’origine était encore en vote, et aucun fonds n’était en risque selon XRPL Labs.
Divulgation de vulnérabilité XRPL
Les validateurs ont été invités à voter contre. La version rippled 3.1.1, sortie le 23 février, a rendu Batch et fixBatchInnerSigs non supportés, afin qu’ils ne puissent pas s’activer. Puis les développeurs ont repris la logique de signature et d’autorisation. Le rapport de remédiation décrit la suppression d’une condition de succès prématurée, l’ajout de garde-fous d’autorisation et un durcissement des règles de contrôle des signatures.
Le travail n’a pas cessé là. Avant le vote actuel, onze autres problèmes ont été traités, portant sur les signatures, les contrôles d’autorisation et de possibles plantages de serveur. Akinyele a indiqué à CoinDesk que la revue avait inclus des tests adversariaux internes, de l’analyse assistée par IA, un concours de sécurité Sherlock, ainsi que des évaluations impliquant Halborn et Common Prefix. Ces éléments sont attribués à RippleX. Les rapports publics détaillant chaque brique de cette revue n’étaient pas tous dans le dossier consulté pour le papier d’origine.
L’écosystème développeur a dû suivre. En juin, un ticket du dépôt officiel xrpl.js montrait que l’ancienne logique de signature ne correspondait plus au format révisé de Batch V1.1, parce que des informations supplémentaires de compte et de séquence avaient été liées aux signatures. L’historique du codec binaire JavaScript indique que le support de signature Batch V1.1 a été ajouté en version 2.9.0, en août.
Asset Managers, Tokenisation Et Promesse De Production
Les propos de Ripple sur Batch tombent dans un climat déjà chargé. En juin, JPMorgan, Mastercard, Ondo Finance et Ripple ont participé à un test de rachat de Treasuries américains tokenisés sur le XRP Ledger. En août, Monica Long, présidente de Ripple, affirmait que certaines institutions faisaient passer une partie du travail sur actifs tokenisés du pilote vers la production.
D’autres pièces du puzzle circulaient déjà. Aviva Investors a lancé en juillet une classe de parts de fonds tokenisée sur XRPL. Ripple a présenté RLUSD comme une jambe cash possible pour un règlement DvP atomique. Côté données on-chain, un passage en revue des RWA du réseau rapportait en juillet environ 2,6 milliards de dollars de valeur d’actifs réels tokenisés ajoutés en six mois, hors stablecoins, d’après des chiffres RWA.xyz. Le même texte prenait soin de distinguer valeur représentée et actifs réellement distribués. Les deux mesures ne racontent pas la même histoire.
Batch V1.1 n’oblige personne à déplacer de l’XRP comme actif sous-jacent. La fonction vit à la couche transaction. Elle peut emballer des opérations supportées, provenant de comptes différents. L’XRP reste pertinent pour les frais du registre. Les mouvements internes peuvent porter d’autres actifs et d’autres structures de jetons.
Ce Que Les Salles De Marché Viennent Chercher Ici
Les gérants n’adoptent pas une primitive parce qu’elle est élégante. Ils l’adoptent si elle réduit un risque opérationnel, un coût de réconciliation ou un délai de dénouement. Un lot atomique sert surtout quand deux événements doivent rester inséparables : titre contre cash, commission contre paiement client, échange entre comptes qui ne se font pas confiance.
Dans un monde post-négociation classique, le DvP repose sur des chambres, des horaires, des files d’attente. Sur un registre, la tentation est de croire que « c’est instantané, donc c’est réglé ». Ce n’est vrai que si les jambes sont réellement liées. Sinon, on a seulement accéléré le moment où l’erreur apparaît.
Batch ne transforme pas XRPL en dépositaire. Il ne remplace pas un cadre juridique. Il offre une primitive d’exécution. La nuance compte. Une maison de gestion peut tester un flux de règlement tokenisé sans attendre que tout l’écosystème traditionnel bascule. Elle peut aussi rester prudente tant que les partenaires, les horaires de cut-off et les procédures d’exception ne sont pas écrits.
Trois questions que les équipes produit devraient poser avant d’annoncer un « go live ».
- Quel mode Batch correspond vraiment au risque métier, et pas seulement au scénario de démo ?
- Qui signe quelle jambe, et que se passe-t-il si un compte refuse au dernier moment ?
- Comment on explique l’échec d’un lot à un middle office qui pense encore en instructions séparées ?
Quatre Modes, Quatre Tempéraments Opérationnels
Le mode tout ou rien est le plus institutionnel. Il ressemble à une instruction irrévocable liée. Le mode une seule convient à des enchères ou à des tentatives concurrentes, quand une seule jambe doit l’emporter. Le mode jusqu’à l’échec sert des enchaînements où l’on avance tant que ça tient, puis on s’arrête net. Le mode indépendant, lui, rapproche Batch d’un simple regroupement de confort. Moins spectaculaire. Parfois plus réaliste pour des frais ou des notifications liées.
Choisir le mauvais mode, c’est créer une fausse impression de sécurité. Un lot indépendant n’est pas un DvP. Un lot tout ou rien n’est pas magiquement conforme à un prospectus. La primitive exécute. Le cadre, lui, reste hors chaîne.
Validateurs, Gouvernance Et Psychologie Du Vote
Le mécanisme d’amendement XRPL a cette particularité d’être à la fois technique et politique. Trente voix sur trente-cinq, cela sonne confortable. Quatorze jours d’affilée, cela sonne fragile. Un opérateur peut changer d’avis après une revue interne, un incident voisin, ou simplement parce que la version de nœud n’est pas alignée.
Le calendrier de septembre raconte une accélération. Sous le seuil au début du mois, puis bascule, puis fenêtre ouverte. Cette vitesse peut rassurer ceux qui voient une maturité retrouvée après février. Elle peut aussi inquiéter ceux qui estiment qu’un amendement touchant aux signatures mérite une digestion plus lente.
Il n’y a pas de contradiction nécessaire entre les deux lectures. On peut juger le correctif sérieux et rester attentif au tally jusqu’au dernier jour. C’est même la lecture la plus adulte.
Ce Que Ripple Dit, Et Ce Qu’Il Ne Dit Pas
Akinyele affirme que certains projets sont déjà construits « avec Batch en tête ». Il promet plus de détails une fois la fonction en ligne, « y compris le travail avec des asset managers clés ». La formulation est habile. Elle crée de l’anticipation sans livrer de preuve nommable.
Pour un média, c’est une source primaire utile et incomplète. Pour un investisseur, c’est un signal de pipeline. Pour un juriste de fonds, c’est encore trop peu. Sans identité de partenaire, sans date de production, sans description du flux, on reste dans le registre de l’intention.
Cette retenue n’est pas forcément un tour de passe-passe. Les institutions signent rarement un communiqué avant que les comités internes n’aient fini de ruminer. Ripple peut aussi vouloir éviter d’associer des noms à une fonction qui n’est pas encore active. Le 29 septembre, si la fenêtre tient, le discours pourra changer de nature.
Le Lien Avec RLUSD Et La Jambe Cash
Un DvP tokenisé a besoin de deux objets qui se parlent. L’actif. Le cash. Ripple a déjà indiqué voir en RLUSD une jambe de règlement possible. Batch n’impose pas ce choix. Il le rend seulement plus propre, si les deux mouvements tiennent dans le même lot.
On peut aussi imaginer d’autres cash legs, d’autres titres, d’autres fonds tokenisés. Le test de juin avec des Treasuries tokenisés montrait surtout que le registre peut servir de rail d’expérience pour des acteurs qui n’ont pas besoin de croire au récit maximaliste pour tester un dénouement.
La question n’est plus « est-ce que c’est possible ? ». Elle devient « qui accepte d’opérer ce possible au quotidien, avec des horaires, des exceptions et des rapports d’audit ? ».
Sécurité : La Confiance Se Construit Après L’Erreur
Il serait malhonnête de raconter Batch V1.1 sans février. Il serait tout aussi malhonnête de figer l’histoire à février. Une faille critique découverte avant activation, puis un retrait, puis une réécriture, puis une revue élargie : c’est le scénario que l’on souhaite voir plus souvent. Pas parce qu’il est glorieux. Parce qu’il est adulte.
Les onze correctifs supplémentaires rappellent qu’une primitive de lot touche à des zones sensibles : qui a le droit de signer, dans quel ordre on vérifie, que se passe-t-il si un compte apparaît au milieu du chemin, comment un serveur réagit à une forme maligne. Ce n’est pas de la cosmétique.
Le public n’a pas sous les yeux l’intégralité des rapports partenaires. Il a une chronologie, une divulgation, des versions de logiciel et un vote. C’est déjà plus que beaucoup d’histoires crypto où l’on active d’abord et l’on explique ensuite.
Ce Que Batch Ne Résoudra Pas
Batch ne crée pas de liquidité. Il ne donne pas un cadre prudentiel. Il ne dit pas comment valoriser une part de fonds tokenisée un mardi pluvieux. Il ne remplace pas un dépositaire, un agent de transfert, un prospectus, une convention de règlement.
Il peut toutefois réduire le nombre de fenêtres pendant lesquelles deux systèmes disent des choses différentes. Pour un middle office, cette réduction de friction vaut parfois plus qu’un discours sur le débit du réseau.
- Le registre exécute un lot, il n’écrit pas le contrat de fonds.
- L’atomicité on-chain n’efface pas le risque juridique off-chain.
- Les frais en XRP restent une contrainte opérationnelle distincte de l’actif transféré.
- Les noms des partenaires, eux, restent le vrai test de crédibilité commerciale.
Une Semaine Pour Tenir, Puis Une Saison Pour Prouver
Le prochain événement procédural est simple à dater et difficile à garantir. Si le soutien reste au-dessus de 80 % sans interruption, Batch V1.1 peut s’activer le 29 septembre vers 14 h 06 min 41 s UTC. Le tally du 20 septembre, à 30 voix sur 35, laisse la fenêtre ouverte.
Ensuite commencera le travail moins photogénique. Brancher des outils. Former des ops. Décider quel mode utiliser pour quel produit. Publier, peut-être, les fameux asset managers. Ou constater que « préparer » voulait dire prototyper, pas industrialiser.
Le marché crypto aime les dates. Les institutions aiment les procédures. Batch V1.1 se tient pile entre les deux. C’est pour cela que l’histoire capte. Ce n’est pas seulement une bascule de bits. C’est un test de langage : jusqu’où une primitive de registre peut parler le dialecte du règlement institutionnel sans tricher sur ce qu’elle sait vraiment faire.
En attendant le 29, le plus honnête est de garder les deux chronomètres sous les yeux. Celui des validateurs. Celui des partenaires encore anonymes. Le premier peut s’arrêter d’un vote. Le second, lui, n’a même pas encore commencé à parler à voix haute.
