Amendement Batch du XRP Ledger : pourquoi le 29 septembre 2026 est une échéance ferme pour les opérateurs de nœuds

Le 29 septembre 2026 à 14:06:41 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 29 septembre. 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 29 septembre

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 29 septembre 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 le 18 septembre 2026 vers 00:35 UTC par l'intermédiaire d'un nœud public du XRP Ledger (index de registre 107058182, réponse HTTP 200). Le champ Majorities contenait exactement une entrée : l'amendement portant l'identifiant 9F287AED3CDB50A7BD1ACEC24296A30C9B5230CCD136219317AC790E3B884377 et la valeur CloseTime 842796401.

Le décompte du temps sur le XRP Ledger commence le 1^er janvier 2000. La conversion de cette valeur donne le 15 septembre 2026, 14:06:41 UTC comme point de départ du délai. Deux semaines plus tard, on obtient le 29 septembre 2026, 14:06:41 UTC. La contre-épreuve effectuée par la requête feature sur le même nœud a 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.

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.0, publiée le 17 septembre 2026 ; elle succède à la 3.3.0 du 6 août 2026 (les deux dates proviennent des dates de publication de l'archive officielle du code source, consultée le 18 septembre 2026).

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. Si false y figure, seule une mise à jour résout le problème, et elle doit intervenir avant le 29 septembre.

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 29 septembre tombe. 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 29 septembre 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 avant le 29 septembre. Si supported: false y figure, mettez le logiciel à jour. 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 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.)