Mise à niveau Solana du 9 septembre : ce que change le nouveau format de transaction

Le 9 septembre 2026, Solana active un nouveau format de transaction. Si vous détenez du SOL, la réponse la plus importante vient d'emblée, et elle est rassurante : vous n'avez rien à faire. Aucun échange, aucun changement de portefeuille, aucune échéance qui vous coûterait de l'argent. Ce qui change se situe une couche plus bas, dans le protocole, et c'est précisément là que certains portefeuilles et certaines applications pourront se comporter différemment dans les jours entourant le 9 septembre, sans que rien ne soit cassé de votre côté.

Cet article explique ce qui se produit réellement le 9 septembre, qui a annoncé la date, pourquoi elle comporte quelques heures de marge dans les deux sens, et à quoi vous reconnaîtrez vous-même que la bascule a eu lieu. En français, la couverture technique de l'événement reste mince : les recherches sur « mise à niveau Solana septembre 2026 » renvoient surtout des dépêches de cours et d'ETF plutôt qu'un exposé du changement de protocole.

Ce qui se passe sur Solana le 9 septembre, et ce qui ne se passe pas

Solana relève la taille maximale d'une transaction unique : de 1 232 à 4 096 octets, soit un peu plus du triple. Cela devient possible grâce au protocole réseau QUIC qui, contrairement à l'ancienne limite IPv6 de 1 280 octets, n'impose aucun plafond fixe à un flux de données.

La nouvelle taille ne s'applique pas à tout ce qui circule sur la chaîne. L'élément déterminant est un nouveau format de transaction appelé v1, et la limite supérieure ne vaut que pour lui. Les deux formats existants, legacy et v0, restent valables sans changement et conservent leur ancien plafond. Les développeurs doivent basculer volontairement vers la v1 ; aucune application n'y migre d'elle-même.

Cela précise du même coup ce qui n'a pas lieu le 9 septembre : pas de fork, pas de scission de la chaîne, aucune migration de vos avoirs et aucun arrêt du réseau. Vos SOL, vos jetons et vos montants délégués se trouveront après la bascule exactement là où ils étaient auparavant.

Qui a annoncé la date et pourquoi la page officielle n'en porte aucune

La date ne provient pas d'un document de la Solana Foundation, mais d'une déclaration nominative. Jacob Creech, vice-président chargé de la technologie à la Solana Foundation, a cité le 9 septembre sur X le 29 août ; le média spécialisé crypto.news a repris l'annonce le 30 août (crypto.news).

La page officielle de mise à niveau de la Solana Foundation présente en revanche le projet sans date. On y trouve les chiffres (4 096 octets au lieu de 1 232, soit 3,3 fois plus) et le statut « Pending Feature Activation », c'est-à-dire une activation en attente. Pour les trois réseaux, elle indique : testnet actif, devnet non activé, réseau principal non activé.

Cet écart entre l'annonce et le document n'est pas une contradiction, c'est la règle chez Solana. Les échéances de chaque fonctionnalité découlent du calendrier de publication de la société de développement Anza et sont communiquées par des personnes avant de figurer où que ce soit comme date arrêtée. Qui veut une preuve solide interroge la chaîne elle-même, et nous y venons plus bas.

Taille des transactions : ce qui tient dans une seule opération avec 4 096 octets

Une transaction est l'enveloppe qui contient une instruction adressée à la blockchain : émetteur, destinataire, signatures, comptes concernés, appel de programme. Jusqu'ici, 1 232 octets tenaient dans cette enveloppe. Tout ce qui dépassait devait être découpé en plusieurs transactions enchaînées les unes aux autres, avec le risque qu'une partie passe et que la suivante échoue.

Avec 4 096 octets, selon la page officielle de mise à niveau, tiennent pour la première fois dans une seule opération : les preuves à divulgation nulle de connaissance (preuves cryptographiques qui établissent un fait sans révéler les données sous-jacentes), les instructions de signature multiple complexes et les opérations groupées qui exigent aujourd'hui plusieurs transactions enchaînées. Pour les applications à cadence élevée, moteurs de liquidation, carnets d'ordres et couches de règlement de la finance décentralisée, c'est là le gain réel : moins d'étapes intermédiaires, moins d'états transitoires, moins de sources d'erreur.

La limite de 64 comptes par transaction demeure inchangée. Plus de place signifie donc davantage de données par participant, et non davantage de participants.

Ce qu'est un feature gate et pourquoi il ne bascule qu'aux limites d'époque

Un feature gate est un interrupteur dans le code des validateurs qui maintient une fonction déjà livrée à l'arrêt tant qu'une majorité de validateurs ne l'active pas conjointement. Solana place ses nouveautés derrière de tels interrupteurs depuis des années, au lieu de les lier à un fork. L'avantage tient au découplage : les modifications d'une même version sont techniquement indépendantes les unes des autres et peuvent être activées une à une, chacune après son propre test. Cette mise à niveau du réseau relève donc d'un déploiement continu et non d'un événement unique.

Le prix à payer, c'est que le réseau évolue plusieurs fois en septembre sans qu'il y ait jamais de grande annonce avec compte à rebours. Pour le format de transaction élargi, l'interrupteur porte l'adresse vérifiable sur la chaîne txv1aq4pp281K9um3tnPgkfX8UqtFT6wcVW3hNezGLL.

Un point est essentiel pour comprendre l'échéance : un feature gate tombe à une limite d'époque, non à une heure précise. Une époque est la période comptable de Solana et couvre exactement 432 000 slots ; un slot est la fenêtre temporelle pendant laquelle un validateur peut produire un bloc. Ce n'est qu'à la fin d'une époque que la chaîne reprend les fonctions nouvellement activées.

Notre propre mesure : où en était la chaîne le 2 septembre

Le 2 septembre 2026, vers 12h40 UTC, nous avons interrogé directement un nœud public du réseau principal plutôt que de nous fier à des indications de tiers. Trois valeurs sont revenues en temps réel :

• Le compte du feature gate txv1aq4pp… est vide sur mainnet-beta. L'interrupteur n'est donc pas activé à cette date ; l'annonce pour le 9 septembre reste ouverte et n'est pas déjà réalisée.
• La chaîne se trouvait dans l'époque 1027, au slot 35 113 sur 432 000, soit environ huit pour cent de l'époque.
• Les nœuds interrogés annonçaient la version client 4.2.1. La version qui livre le nouveau format tourne donc déjà.

Deux horodatages de blocs distants de 10 000 slots donnent une durée de slot mesurée d'environ 314 millisecondes. Une époque complète dure ainsi actuellement quelque 37,7 heures. En prolongeant ce calcul, l'époque 1027 s'achève le soir du 3 septembre, et il reste environ trois limites d'époque avant le 9 septembre. La dernière avant l'échéance tombe le soir du 8 septembre, la suivante le 10 septembre.

Concrètement, le 9 septembre est une date assortie de quelques heures de marge dans les deux sens, et non une heure précise. Si vous vérifiez le matin du 9 septembre sans rien constater, vous n'avez pas nécessairement manqué quoi que ce soit.

Les tables de correspondance d'adresses disparaissent dans le format v1

C'est ici que réside le véritable inconvénient, et c'est la raison pour laquelle les développeurs n'activeront pas le nouveau format partout. Une table de correspondance d'adresses (address lookup table, ALT) est un répertoire de comptes enregistré sur la chaîne : au lieu d'inscrire chaque adresse dans la transaction avec ses 32 octets complets, l'application renvoie à une entrée de cette table par un index court. C'est exactement ainsi que les applications ont économisé de la place pour passer sous la barre des 1 232 octets.

Le format v1 ne prend pas ces tables en charge. Qui utilise la v1 doit inscrire tous les comptes concernés directement dans l'instruction, sous forme d'adresses complètes de 32 octets. La place supplémentaire finance donc en partie sa propre consommation.

Pour les développeurs, cela devient un arbitrage transaction par transaction : l'enveloppe plus grande rapporte-t-elle davantage que ce qu'a coûté la liste d'adresses économisée ? Pour une preuve à divulgation nulle de connaissance, la réponse est clairement oui. Pour un échange routé à travers de nombreux pools qui s'appuie aujourd'hui sur une table bien entretenue, l'ancien format peut rester le meilleur choix.

Ce que cela signifie pour les portefeuilles et les dApps autour du 9 septembre

Comme chaque application procède elle-même à cet arbitrage, la bascule se fera de manière inégale. Certaines équipes passeront tôt à la v1, d'autres attendront des mois, d'autres encore utiliseront les deux formats en parallèle selon l'opération. Pour vous, en tant qu'utilisateur, cela peut prendre la forme suivante :

• Une dApp indique après la bascule des frais légèrement différents pour une même opération, parce que la taille de la transaction a changé.
• Un portefeuille présente une transaction autrement qu'auparavant dans son aperçu.
• Une application conserve pour l'instant son comportement habituel tandis qu'une autre change de façon visible.

Aucune de ces observations ne traduit un défaut sur votre compte. Si vous détenez vous-même vos clés, la mise à niveau ne change rien à votre conservation ; un coup d'œil au comparatif des portefeuilles matériels se justifie pour d'autres raisons, mais pas en raison de cette échéance. À l'inverse : si un message, un courriel ou un appel vous explique ces jours-ci que vous devez « migrer » votre portefeuille ou saisir une phrase de récupération à cause de la mise à niveau de Solana, il s'agit d'une tentative d'escroquerie. Les mises à niveau de ce type n'exigent jamais la moindre action des utilisateurs finaux.

Dois-je faire quelque chose en tant que détenteur de SOL ?

Non. La réponse est solide et repose sur trois raisons :

1. Les formats existants restent valables. Les transactions legacy et v0 fonctionneront après le 9 septembre comme auparavant.
2. La bascule est facultative et relève de l'équipe technique de chaque application. Ni les utilisateurs de portefeuilles ni les détenteurs ne tranchent quoi que ce soit ici.
3. Aucune échéance n'entraîne de péremption. Contrairement à un échange de jetons ou au retrait d'une cotation sur une plateforme, aucune perte n'attend au terme de cette date.

Qui souhaite tout de même agir fera le plus utile : dans les jours entourant le 9 septembre, ne pas repousser à la dernière minute ses transactions les plus importantes et, en cas de message d'erreur inhabituel, consulter d'abord la page d'état de l'application concernée avant de renouveler l'opération plusieurs fois.

Le calendrier de septembre : trois changements, trois échéances

Le format de transaction élargi est le deuxième de trois changements que Solana active successivement en quelques semaines. Le calendrier, tel que Jacob Creech l'a esquissé fin août :

1. La baisse des frais de stockage (après le vote de gouvernance sur la proposition SIMD-0437), première de cinq étapes prévues dans la semaine du 31 août. Il s'agit du loyer que les comptes doivent déposer sur Solana pour leur espace de stockage ; à mesure qu'il baisse, l'ouverture de nouveaux comptes devient moins chère.
2. Le format de transaction v1 avec 4 096 octets, fixé au 9 septembre.
3. Alpenglow, la grande mise à niveau du consensus, qui arrive avec la version Agave 4.3 et vise le mois d'octobre selon la Fondation.

Sur ce dernier point, deux dates se contredisent à première vue et nous les plaçons donc côte à côte. Le calendrier de publication d'Agave 4.3 cite le 28 septembre comme début de l'activation des fonctionnalités sur le réseau principal, tandis que la Fondation donne octobre comme objectif pour Alpenglow lui-même. Les deux s'accordent dès lors que l'on sépare la version et l'interrupteur : la version apporte le code, l'interrupteur décide du moment, et cette feuille de route n'est pas un calendrier rigide. Ce qu'Alpenglow signifie pour ceux qui délèguent, nous l'avons exposé en détail dans notre article sur la mise à niveau Alpenglow et le staking.

À quelle vitesse la chaîne fonctionne réellement et ce qu'Alpenglow doit y changer

Les chiffres publiés sur la durée d'un slot divergent. La page officielle de mise à niveau annonce pour la version Agave 4.2 un objectif de 200 millisecondes contre 400 auparavant ; crypto.news faisait état le 30 août de 350 millisecondes, avec les paliers intermédiaires de 300, 250 et 200. Notre propre mesure du 2 septembre a donné 314 millisecondes. La réduction du temps de production des blocs progresse donc par paliers qui reposent eux aussi sur des interrupteurs distincts.

La finalité (transaction finality) est à distinguer de cette durée et désigne le moment à partir duquel une transaction ne peut pratiquement plus être annulée. C'est précisément là qu'intervient Alpenglow. La mise à niveau remplace l'architecture de consensus TowerBFT par deux nouveaux composants, Votor pour le vote des validateurs et Rotor pour la diffusion des blocs, et vise une finalité d'environ 100 à 150 millisecondes au lieu des 12,8 secondes habituelles jusqu'ici. Une partie du gain provient du traitement hors chaîne des transactions de vote des validateurs, au lieu de les faire passer normalement par la chaîne, ce qui abaisse en même temps les coûts des validateurs. Proof of History, la source de temps de la chaîne, n'est pas touchée.

Au quotidien, une finalité inférieure à la seconde signifie surtout que les plateformes d'échange et les prestataires de paiement peuvent créditer les dépôts plus tôt, car la sécurité du règlement est acquise plus tôt. Solana en devient plus intéressante comme couche de règlement pour les applications qui dépendent d'une finalité rapide. Pour le cours, rien de tout cela n'est automatique.

Ce que les validateurs et les délégants doivent surveiller

Qui exploite lui-même un validateur a de toute façon la date en tête. Qui se contente de déléguer, c'est-à-dire de confier ses SOL au validateur d'un tiers, n'a rien à préparer, mais devrait savoir ce qui compte dans les semaines à venir.

L'élément déterminant est la diversité des clients : Solana fonctionne aujourd'hui avec plusieurs programmes de validation indépendants. Si une fonction n'est prête que dans l'un d'eux, l'interrupteur est retardé pour tout le monde ; de telles modifications sont éprouvées au préalable sur les réseaux de test et dans la pratique des validateurs. Pour vous qui déléguez, l'échéance elle-même compte donc moins que la question de savoir si votre validateur installe rapidement les versions courantes et avec quelle fiabilité il produit des blocs. Si vous vouliez de toute façon revoir votre délégation, examinez les temps d'indisponibilité de votre validateur, sa commission et sa capacité à suivre les versions récentes.

Un point souvent négligé : le niveau de votre rendement de staking dépend du taux d'inflation du protocole et des recettes de frais des validateurs, non du format de transaction. Si ce rendement a baissé ces derniers temps, les causes sont ailleurs.

Comment savoir que le feature gate est tombé

Vous n'avez pas besoin de votre propre nœud pour cela. Il existe trois voies, de la plus simple à la plus précise :

1. La page officielle de mise à niveau. Elle indique le statut pour chaque réseau. Dès que l'entrée du réseau principal passe de « non activé » à actif, l'affaire est faite.
2. Le compteur d'époques. Les explorateurs publics de Solana affichent l'époque en cours et sa progression. Un feature gate tombe toujours au passage à l'époque suivante.
3. Le compte de la fonctionnalité lui-même. Si le cœur vous en dit, interrogez un nœud public sur le compte txv1aq4pp281K9um3tnPgkfX8UqtFT6wcVW3hNezGLL. Tant que rien n'y figure, la fonction est désactivée ; dès que le compte porte des données, elle est active. C'est exactement la voie que nous avons empruntée pour cet article.

Et si le 9 septembre passait sans que rien ne se produise ? Ce ne serait pas un signal d'alarme. Les feature gates glissent régulièrement d'une ou deux époques lorsqu'un test est encore en cours ou qu'un client est à la traîne. La date est une intention, pas un contrat.

Mise à niveau Solana : ce qu'il faut retenir

1. Rester calme et ne rien changer. Pour les détenteurs et les utilisateurs, cette échéance n'appelle aucune action, ne fixe aucun délai et ne comporte aucun risque. Si vous conservez vos SOL sur le long terme, rien ne change pour vous ; le lieu d'achat reste une décision de frais et de paires de négociation, que le comparatif des plateformes d'échange aide à trancher.
2. En cas d'anomalie, vérifier d'abord l'application, pas le réseau. Si une dApp s'écarte ces jours-ci de son comportement habituel, cela tient très probablement à sa propre bascule vers le nouveau format. Toute invitation à saisir des clés ou à déplacer des avoirs pour cette raison relève de l'escroquerie ; le comparatif des portefeuilles logiciels montre comment chacun conserve vos clés.
3. Garder l'échéance d'octobre en vue. Alpenglow est le changement aux conséquences réelles pour ceux qui délèguent et pour la vitesse de la chaîne. Si vous déléguez, vérifiez auparavant la fiabilité de votre validateur ; les critères de comparaison figurent dans le panorama des plateformes de staking.

(Au 2 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.)