Amendement Batch du XRP Ledger reporté au 9 octobre 2026 au plus tôt : ce que les opérateurs de nœuds doivent vérifier

Mis à jour le 27 septembre 2026 : la première version de cet article, publiée le 18 septembre 2026, indiquait le 29 septembre 2026, 14:06:41 UTC comme date d'activation. Cette date n'est plus valable. Entre-temps, le soutien des validateurs à BatchV1_1 est passé sous le seuil, puis une nouvelle majorité s'est formée le 25 septembre, ce qui a relancé le délai de deux semaines. L'objet Amendments du registre validé (index de registre 107269984, interrogé le 27 septembre 2026 à 12:01 UTC) enregistre la majorité depuis le 25 septembre 2026, 14:46:02 UTC. La date d'activation la plus proche est donc le 9 octobre 2026, 14:46:02 UTC, à condition que la majorité tienne. Depuis le 25 septembre 2026, 14:12:51 UTC, le registre décompte aussi le délai du correctif fixBatchV1_2, livré avec xrpld 3.4.1 (notes de version du 25 septembre 2026). Si vous exploitez votre propre nœud, il vous faut donc la version 3.4.1. Les sections ci-dessous tiennent compte de cette situation.

Au plus tôt le 9 octobre 2026 à 14:46:02 UTC, une mise à jour du protocole s'armera d'elle-même sur le XRP Ledger : l'amendement Batch, dont la désignation interne est BatchV1_1. Si vous détenez des XRP sur une plateforme d'échange ou dans un portefeuille conservé par un tiers, vous n'avez rien à faire. Si vous exploitez votre propre nœud, ou si vous faites tourner un service contre votre propre nœud, cette date est une échéance ferme : passé ce moment, votre serveur sort du réseau.

Ce texte explique ce que l'amendement modifie, d'où vient la date, comment vérifier l'état par vous-même et quelles réserves pèsent sur cette échéance. Tous les chiffres de cet article proviennent du registre validé et de la documentation du protocole, non d'annonces publiques.

Ce qu'est un amendement sur le XRP Ledger et pourquoi il se passe de date d'extinction

Un amendement est une modification des règles du protocole du XRP Ledger, sur laquelle votent les validateurs de confiance du réseau, au lieu qu'une entreprise en fixe la date. C'est précisément ce qui distingue la procédure d'un hard fork classique assorti d'une hauteur de bloc annoncée : il n'existe aucune entrée d'agenda posée par quelqu'un, seulement une condition que le réseau remplit ou non.

La règle est inscrite dans la documentation du protocole et elle tient en peu de mots. Un amendement a besoin de l'approbation de plus de 80 % des validateurs de confiance, et il doit conserver cette approbation sans interruption pendant deux semaines. Ce n'est qu'alors qu'il est activé. Si l'approbation passe sous le seuil pendant ces deux semaines, même brièvement, le décompte repart de zéro.

Pour vous, lecteur, cela signifie deux choses. D'abord, une telle échéance est vérifiable, puisqu'elle figure dans le registre et non dans un communiqué de presse. Ensuite, elle n'a rien d'irrévocable tant que les deux semaines courent. Ces deux points forment le cœur du sujet pour l'échéance dont il est question ici.

Ce que l'amendement Batch BatchV1_1 change techniquement

Batch est un nouveau type de transaction qui réunit plusieurs transactions individuelles en un paquet traité d'un seul tenant. Selon la référence du protocole, un paquet regroupe au minimum deux et au maximum huit transactions internes, qui peuvent également provenir de comptes différents. Jusqu'à présent, le XRP Ledger imposait de soumettre chaque étape séparément et d'espérer, à chaque fois, qu'elle aboutisse.

Le gain pratique tient à la garantie d'exécution. Celui qui soumet aujourd'hui deux étapes l'une après l'autre, par exemple une autorisation puis un échange, supporte le risque que la première réussisse et que la seconde échoue. Un paquet referme cette faille, parce que le réseau connaît la règle de traitement et la fait appliquer.

Dois-je agir si mes XRP sont sur une plateforme d'échange ?

Non. C'est la situation la plus fréquente, et la moins spectaculaire. Si vos XRP se trouvent chez une plateforme de négociation ou dans un portefeuille conservé par un tiers, c'est le prestataire qui exploite l'infrastructure, et l'obligation de mise à jour lui revient. Vous n'avez ni à déplacer vos avoirs, ni à vendre, ni à changer d'adresse. Déplacer des soldes dans la précipitation à cause d'une échéance de protocole produit surtout des frais et, le cas échéant, une opération fiscalement imposable dont personne n'avait besoin.

L'occasion reste utile pour un état des lieux tranquille, sans rapport avec l'échéance. Savez-vous chez quel prestataire se trouve quelle part de vos avoirs, quel y est le montant des frais de retrait et si ce prestataire est supervisé dans l'Union européenne ? Indépendamment de l'échéance du protocole, ces questions-là comptent davantage.

Ce qu'il faut vérifier si vous conservez vos XRP vous-même

Même en conservation personnelle, le cas reste en général simple. Un portefeuille matériel stocke votre clé privée et signe les transactions avec elle ; il s'adresse en règle générale au réseau par les serveurs du fournisseur du portefeuille. Les clés elles-mêmes ne sont jamais concernées par un amendement, car un amendement modifie les règles de la chaîne, pas votre adresse ni votre accès.

Ce que vous pouvez faire, c'est maintenir à jour le logiciel avec lequel vous accédez au portefeuille, et vérifier une fois avant l'échéance que vos mots de récupération se trouvent bien là où vous le croyez. Il s'agit d'hygiène élémentaire, valable indépendamment du 9 octobre. Si vous hésitez encore sur le choix d'un appareil, notre comparatif des portefeuilles matériels vous aidera.

Amendment-blocked : ce qui arrive à un nœud xrpld obsolète le 9 octobre

Amendment-blocked désigne l'état dans lequel tombe un serveur qui ignore une règle de protocole activée. La documentation du protocole en décrit les conséquences sans ambiguïté : un serveur bloqué ne peut plus valider de registres, ne peut plus soumettre ni traiter de transactions, ne participe plus au consensus et ne peut plus voter sur les amendements à venir.

La phrase décisive figure juste à côté : la configuration de vote d'un serveur n'a aucune influence sur ce point. Celui qui a réglé son xrpld pour voter contre l'amendement se retrouve après l'activation aussi bloqué que celui qui a voté pour. Est bloqué celui à qui manque le code capable de comprendre la nouvelle règle. On ne continue pas de fonctionner contre une décision majoritaire activée.

Le serveur ne se bloque pas brutalement et n'affiche aucun message d'erreur voyant. Il continue de répondre, simplement plus avec des données valides issues de la chaîne en cours. C'est exactement ce qui rend cet état dangereux pour les services qui interrogent en arrière-plan leur propre nœud : l'application paraît en bonne santé et sert un état de données qui s'est figé.

D'où vient la date du 9 octobre 2026 et comment elle est établie

L'échéance est calculée, ni déduite ni estimée. Le registre validé contient un objet qui tient l'état de tous les amendements. On y trouve un champ Majorities, où figure, pour chaque amendement ayant atteint le seuil, le moment à partir duquel court le délai de deux semaines.

Notre rédaction a interrogé cet objet une première fois le 18 septembre 2026 (index de registre 107058182). Le champ Majorities contenait alors exactement une entrée : l'amendement portant l'identifiant 9F287AED3CDB50A7BD1ACEC24296A30C9B5230CCD136219317AC790E3B884377 et la valeur CloseTime 842796401. Lors d'une nouvelle interrogation le 27 septembre 2026 vers 12:01 UTC (index de registre 107269984), le même identifiant portait la valeur 843662762. La majorité était donc tombée entre-temps, puis s'était reformée.

Le décompte du temps sur le XRP Ledger commence le 1^er janvier 2000. L'ancienne valeur correspond au 15 septembre 2026, 14:06:41 UTC, et aurait conduit à une activation le 29 septembre. La nouvelle valeur donne le 25 septembre 2026, 14:46:02 UTC comme point de départ du délai. Deux semaines plus tard, on obtient le 9 octobre 2026, 14:46:02 UTC. Le 27 septembre, la contre-épreuve effectuée par la requête feature a toujours renvoyé pour cet identifiant le nom BatchV1_1 ainsi que les valeurs enabled: false et supported: true. L'amendement est donc connu du réseau et pris en charge, mais pas encore actif. Depuis le 25 septembre 2026, 14:12:51 UTC, le même objet recense aussi le correctif fixBatchV1_2 (identifiant commençant par 14A2B45E48A4), activable au plus tôt le 9 octobre 2026, 14:12:51 UTC.

Comment vérifier vous-même l'état de l'amendement

Nul besoin d'un nœud personnel pour cela. Un point d'accès public du XRP Ledger répond à la question en une seule requête. Qui sait manier la ligne de commande envoie une requête feature portant l'identifiant cité plus haut à un nœud public et lit trois champs dans la réponse :

• enabled : si la valeur est false, l'amendement n'est pas encore actif. Dès qu'elle bascule sur true, l'activation a eu lieu.
• supported : si la valeur est true, le logiciel du nœud interrogé connaît déjà la règle. Si elle est false, c'est précisément ce nœud qui sera bloqué lors de l'activation.
• majority : l'horodatage à partir duquel court le délai de deux semaines. Si ce champ venait à disparaître, c'est que la majorité est retombée et que le compte à rebours a été remis à zéro.

Ce troisième point est justement la raison pour laquelle il vaut mieux regarder l'état une nouvelle fois peu avant l'échéance, plutôt que de recopier la date et de la cocher. Pour votre propre nœud, la démarche est la même, avec une différence importante : adressez la requête feature à votre serveur, pas à celui d'un tiers. Seule la réponse de votre propre nœud vous renseigne sur votre propre nœud.

Quelle version du logiciel apporte la nouvelle règle

Le logiciel serveur du XRP Ledger s'appelle xrpld et est publié en logiciel ouvert. La version actuelle est la 3.4.1, publiée le 25 septembre 2026 avec le correctif fixBatchV1_2, qui rejette les transactions internes d'un Batch portant une mauvaise enveloppe. Elle succède à la 3.4.0 du 17 septembre et à la 3.3.0 du 6 août 2026 (dates tirées des notes de version de la 3.4.1 et de l'archive officielle du code source). Selon les notes de version, un nœud sans la 3.4.1 sera bloqué par amendement dès l'activation de fixBatchV1_2.

Recopier un numéro de version depuis un article reste malgré tout la moins bonne méthode. Le renseignement solide, c'est votre propre serveur qui vous le donne par le champ supported : il répond à la question de savoir si le logiciel en fonctionnement connaît réellement la règle. La version que vous croyez faire tourner n'entre pas en ligne de compte. Interrogez-le pour BatchV1_1 et pour fixBatchV1_2. Si false figure pour l'un des deux, seule une mise à jour vers la 3.4.1 résout le problème, et elle doit intervenir avant le 9 octobre.

Pourquoi la date reste soumise à réserve

Le délai de deux semaines court tant que l'approbation demeure au-dessus de 80 %. Si elle repasse en dessous, le compteur est remis à zéro et le 9 octobre tombe, comme cela s'est produit pour le 29 septembre calculé à l'origine. Cette clause n'a rien d'un ornement théorique ; c'est le mécanisme de sécurité intégré à la procédure. Elle laisse aux validateurs la possibilité, jusqu'au dernier moment, d'arrêter une modification si un problème se manifeste entre-temps.

Pour votre planification, il en découle une position simple. Considérez le 9 octobre comme l'échéance à laquelle vous vous préparez, et tenez sa survenue pour incertaine. Celui qui met un nœud à jour ne perd rien si le compte à rebours est remis à zéro. Celui qui repousse la mise à jour au motif que l'échéance pourrait encore sauter se retrouve, dans le cas inverse, avec un système coupé de la chaîne.

Les quatre modes d'un paquet Batch et ce qu'ils signifient au quotidien

Un paquet reçoit au moment de sa soumission un mode qui détermine la manière dont le réseau traite les échecs. La référence du protocole en cite quatre :

• AllOrNothing : chaque transaction du paquet doit aboutir. Si l'une échoue, le paquet entier échoue. C'est le mode réservé aux enchaînements qui n'ont de sens que complets.
• OnlyOne : dès que la première transaction a réussi, les suivantes sont ignorées. Cela permet de soumettre des solutions de rechange dont une seule doit s'appliquer.
• UntilFailure : les transactions s'exécutent dans l'ordre jusqu'à ce que l'une échoue ; tout ce qui suit est abandonné. Ce mode convient aux enchaînements qui reposent les uns sur les autres.
• Independent : toutes les transactions sont traitées indépendamment les unes des autres, que certaines échouent ou non. C'est le regroupement pur, sans chaînage.

En tant que détenteur, vous aurez rarement à choisir ces modes vous-même. La différence devient visible là où les applications s'en servent : dans les interfaces de portefeuille qui réunissent plusieurs étapes en une seule confirmation, et dans les applications de négociation, où un enchaînement à moitié exécuté constituait jusqu'ici le cas le plus désagréable.

Ce que les services, fournisseurs de portefeuilles et prestataires de paiement doivent clarifier

Est concerné quiconque accède au XRP Ledger par sa propre infrastructure plutôt que par un prestataire extérieur. Cela comprend les services de paiement, les applications de négociation, les outils de comptabilité dotés de leur propre collecte de données et tout portefeuille dont le fournisseur exploite un nœud. Pour ce groupe, trois questions demandent une réponse avant l'échéance.

1. La collecte s'effectue-t-elle contre votre propre nœud ou contre un point d'accès extérieur ? Dans le second cas, l'obligation incombe à l'exploitant, et mieux vaut l'interroger que d'agir soi-même.
2. Votre propre nœud annonce-t-il la valeur supported: true pour BatchV1_1 ? Dans le cas contraire, une mise à jour s'impose, avec le délai habituel pour les tests et la fenêtre de maintenance.
3. Un état de données figé se remarquerait-il seulement dans votre supervision ? Un nœud bloqué continue de répondre. Une supervision qui ne contrôle que la disponibilité n'en voit rien. Celui qui surveille l'écart entre le dernier registre validé et l'heure courante s'en aperçoit immédiatement.

L'expérience montre que tout se joue sur la troisième question. Une panne déguisée en fonctionnement normal se découvre tard, et pendant ce temps les écritures et les affichages continuent de travailler avec des données périmées.

Comment cette échéance s'inscrit dans la série des amendements précédents

La procédure relève de la routine sur le XRP Ledger et se déroule plusieurs fois par an. Nous avons décrit en dernier lieu, le 9 septembre 2026, l'activation de l'amendement précédent ; qui souhaite relire le déroulement depuis le début le trouvera dans notre article consacré aux points à vérifier sur le portefeuille, le nœud et la position. La mécanique est identique, à ceci près que s'y ajoutent cette fois une date précise et une condition ouverte.

Pour situer le réseau dans son ensemble, le regard porté sur ce qui se construit dessus reste plus parlant que n'importe quelle étape de protocole prise isolément. Un exemple de février 2026 est le stablecoin en euros de la Société Générale, émis sur le XRP Ledger. De telles applications sont la raison même pour laquelle des paquets de transactions à exécution garantie sont recherchés : qui automatise des flux de paiement ne veut pas de chaînes à moitié exécutées.

Amendement Batch du XRP Ledger : ce qu'il faut en retenir

1. Si vos XRP sont chez un prestataire, vous n'avez rien à faire. Profitez tout au plus de l'échéance pour vérifier calmement si ce prestataire vous convient encore : le panorama des meilleures plateformes crypto met côte à côte les frais et les voies de retrait.
2. Si vous conservez vous-même, vérifiez l'accès et la récupération, pas le protocole. Vos clés ne sont pas concernées par un amendement. Quel appareil convient à cet usage, le comparatif des portefeuilles matériels le montre.
3. Si vous exploitez votre propre nœud, lancez la requête feature pour BatchV1_1 et fixBatchV1_2 avant le 9 octobre. Si supported: false figure pour l'un des deux, passez à xrpld 3.4.1. Qui a par ailleurs besoin d'une vue d'ensemble de ses avoirs et de leur traitement fiscal trouvera les outils adaptés parmi les logiciels fiscaux et suivis de portefeuille crypto.

Les sources primaires de cet article : la description de la procédure d'amendement et la référence de protocole relative à la transaction Batch, toutes deux dans la documentation officielle du XRP Ledger.

(Au 27 septembre 2026, première version du 18 septembre 2026. Cet article ne constitue pas un conseil en investissement. Les cours et les grilles tarifaires évoluent ; vérifiez les conditions auprès du prestataire avant tout achat.)