Les informations fournies dans cet article sont uniquement à titre informatif et ne constituent pas un conseil financier. Les investissements en cryptomonnaies comportent un degré de risque élevé. Effectuez toujours vos propres recherches.

Solana Alpenglow : activation à partir du 28 septembre et ce que les délégateurs doivent vérifier

Le calendrier de publication d’Agave v4.3 fixe au 28 septembre 2026 le début de l’activation de la fonctionnalité sur le réseau principal de Solana. Nous avons mesuré quelle part du stake tourne déjà sur la nouvelle version et expliquons ce que les délégateurs doivent en déduire.

Feu de départ nocturne au-dessus d’une chaussée mouillée : seule la plus haute des cinq lampes rougeoie, au premier plan une grande pièce métallique frappée du symbole Bitcoin
19 min read
Partager:

Solana n’active pas Alpenglow à une date tenue secrète : le calendrier de publication de la société de développement Anza indique le 28 septembre 2026 pour l’activation de la fonctionnalité sur le réseau principal. Si vous détenez du Solana (SOL), vous n’avez dans la plupart des cas rien à faire. Si vous stakez vous-même par délégation, vous avez en revanche une tâche précise, et l’échéance qui compte le plus n’est pas le 28 mais le 21 septembre.

Cet article répond à la question de l’activation d’Alpenglow et de sa date à partir de la source primaire, en trois temps : ce que dit réellement le calendrier, ce que signifie techniquement l’« activation », et à quelle distance le réseau se trouve, le jour de cette mesure, de l’état que le calendrier suppose. Les chiffres relatifs à la diffusion de la nouvelle version, nous les avons relevés nous-mêmes sur le réseau principal le 1er septembre 2026.

Quand Alpenglow sera activé sur Solana : le calendrier d’Agave 4.3 indique le 28 septembre

La réponse figure dans un document que presque personne ne lit : le calendrier de publication d’Agave v4.3 dans le wiki du client de validation. Agave est le logiciel entretenu par Anza avec lequel la majorité des validateurs Solana font tourner leurs nœuds. Le calendrier consigne chaque jalon de la version avec une date cible et une date de livraison, et la dernière ligne consacrée au mainnet-beta porte la mention Begin feature activation avec la date cible 2026-09-28.

La branche de la v4.3 a été créée le 11 août 2026, le réseau de test a reçu la recommandation le 17 août, et l’activation de la fonctionnalité sur le réseau de test et le devnet est achevée, selon les dates de livraison, respectivement les 19 et 24 août. C’est un détail important pour juger de la solidité du document : le tableau est tenu à jour, les lignes cochées portent de véritables dates de livraison, et certaines précèdent les échéances cibles. Un document laissé à l’abandon a une autre allure.

Pour l’espace germanophone, il s’agit d’une information inédite. Les indications qui circulent parlent de « troisième trimestre 2026 » ou d’« octobre 2026 », et aucune des deux n’est fausse. Elles décrivent simplement autre chose que le 28 septembre, et c’est précisément cette distinction qui fait le cœur de cet article.

Pourquoi le mot Alpenglow ne figure pas dans le calendrier

Qui cherche le mot Alpenglow dans le calendrier ne trouve rien. Celui-ci ne parle que de v4.3 et d’activation de fonctionnalité. C’est un second document officiel qui établit le lien : dans la présentation de la version Agave 4.2, la Fondation Solana écrit qu’Alpenglow ne sera pas encore activé dans la 4.2 et que son activation est attendue pour Agave 4.3, « targeted for October 2026 ». La même page fait figurer Alpenglow dans sa barre d’indicateurs avec la mention « 150ms Alpenglow target finality, activating in 4.3 ».

Ce n’est qu’en réunissant les deux documents que l’énoncé apparaît : la v4.3 contient Alpenglow, et l’activation de la fonctionnalité de la v4.3 commence le 28 septembre. Qui n’en lit qu’un seul trouve soit une date sans sujet, soit un sujet sans date. Cela explique aussi pourquoi aucun jour précis n’était jusqu’ici apparu dans la couverture germanophone.

Ce qu’est Alpenglow et ce qui change pour votre staking de SOL, nous l’avons traité en détail dans un article distinct : Alpenglow et votre staking de SOL. Le présent texte se place un cran en dessous et répond à la question de la date à partir du document.

Les cinq échéances jusqu’à l’activation, une par une

Le calendrier échelonne le chemin vers le réseau principal en cinq jalons. Cet échelonnement est la vraie découverte, car il rend visible la lente montée en charge qui précède la date butoir :

  • 4 septembre : Anza désigne sur la branche v4.3 un candidat à la mise à niveau du mainnet-beta. À partir de là existe une version destinée à l’exploitation en production.
  • 8 septembre : appel aux volontaires pour porter dix pour cent du stake sur la v4.3. Le même jour débute sur le réseau de test la procédure de redémarrage ainsi que de passage d’une version à l’autre, à la hausse comme à la baisse.
  • 14 septembre : le même appel pour 25 % du stake.
  • 21 septembre : recommandation générale de passer à la v4.3. C’est le moment où un opérateur peut basculer sans pression de temps.
  • 28 septembre : début de l’activation de la fonctionnalité sur le mainnet-beta.

Entre la recommandation générale et l’activation s’écoule exactement une semaine. Cette semaine n’est pas une formalité, c’est un tampon : il doit garantir que la grande majorité du stake fasse déjà tourner la nouvelle implémentation avant que le premier interrupteur ne soit actionné. L’ordre des étapes du calendrier constitue ainsi lui-même la réponse à la question du temps dont dispose un validateur.

Barrière de fonctionnalité et frontière d’époque : pourquoi le 28 septembre est un coup d’envoi et non un jour de bascule

Une barrière de fonctionnalité est un interrupteur inscrit dans le protocole qui ne rend une modification déjà livrée effective que lorsqu’une part suffisante du stake la prend en charge. Le logiciel repose donc longtemps à l’avance sur les nœuds sans rien faire, jusqu’à ce que la barrière soit levée. C’est exactement pour cela que les deux documents officiels emploient le mot begin : le 28 septembre, l’activation commence, elle n’est pas achevée ce jour-là.

Ce qu’est une époque et pourquoi elle donne la cadence

Chez Solana, une époque est une tranche fixe de 432 000 créneaux, à la frontière de laquelle le réseau règle ses écritures : les délégations prennent effet, les récompenses sont décomptées, les interrupteurs sont armés. Une époque ne dure donc pas un nombre d’heures fixe ; elle dure le temps que prennent ces 432 000 créneaux.

Nous l’avons mesuré nous-mêmes le 1er septembre 2026 à 12h49 UTC. Le réseau se trouvait dans l’époque 1026, au créneau 195 474 sur 432 000. De l’écart entre deux horodatages de blocs sur 198 000 créneaux se déduit une durée moyenne de créneau de 0,318 seconde, et de là une durée d’époque d’environ 38 heures. Entre la fin de l’époque en cours et le 28 septembre s’intercalent ainsi quelque 16 frontières d’époque supplémentaires.

Il en découle la résolution de la contradiction apparente entre « 28 septembre » et « octobre 2026 » : le 28 septembre marque le début de l’activation, l’effet en exploitation s’installe au fil des frontières d’époque suivantes, et celles-ci tombent en octobre. Le coup d’envoi et l’effet sont deux moments distincts, non deux échéances concurrentes.

Longue barre de fer garnie de cadenas en laiton fermés et serrés les uns contre les autres, un seul d’entre eux ouvert, devant elle une pièce frappée du symbole Bitcoin
Un seul cadenas ouvert dans une longue rangée : voilà à quoi ressemble la diffusion d’Agave 4.3 sur le réseau Solana au 1er septembre.

Notre mesure sur le réseau principal : quelle part du stake tourne aujourd’hui sur Agave 4.3

Un calendrier dit ce qui doit se passer. Que le réseau le suive, cela se vérifie. Le 1er septembre 2026 à 12h49 UTC, nous avons donc interrogé, via le point d’accès public de Solana, deux listes que nous avons rapprochées : celle de tous les nœuds avec la version qu’ils déclarent, et celle de tous les comptes de vote avec leur stake actif. Cela permet de calculer la part de stake par version de client au lieu de se contenter de compter des nœuds.

La base : 679 validateurs actifs totalisant environ 438,1 millions de SOL de stake actif, auxquels s’ajoutent 15 validateurs décrochés qui ne portent ensemble que 0,01 % du stake. La répartition par branche de version :

  • Agave 4.2 : 86,61 % du stake, 608 validateurs
  • Frankendancer, ancienne numérotation : 8,49 %, 40 validateurs
  • Frankendancer, numérotation calendaire : 3,88 %, 15 validateurs
  • Agave 4.3 (alpha et bêta) : 0,39 %, 6 validateurs
  • Agave 4.4 (alpha) : 0,08 %, 6 validateurs
  • autres mentions et nœuds sans indication de version : 0,56 %, 4 validateurs

Le constat en une phrase : une semaine avant le premier jalon du calendrier, 0,39 % du stake actif tourne sur une version 4.3, et il s’agit exclusivement de versions alpha et bêta. Le calendrier souhaite voir dix pour cent au 8 septembre et 25 % au 14 septembre. Ce n’est ni une contradiction ni un signal d’alarme, car le candidat à la mise à niveau du réseau principal ne sera désigné que le 4 septembre. Cela montre en revanche tout ce qui doit encore se produire d’ici l’échéance cible, et cela vous donne un chiffre à partir duquel vérifier vous-même l’avancement.

Ce que révèlent les numéros de version : Agave, Frankendancer et la diversité des clients

En dépouillant la mesure, on remarque qu’environ douze pour cent du stake déclarent des numéros de version qui ne suivent pas du tout le schéma d’Agave. Ce n’est pas une erreur, c’est l’empreinte d’un second client de validation. Frankendancer est l’étape intermédiaire exploitable en production du second client Solana, Firedancer ; selon sa documentation, il compile le validateur Agave comme dépendance tout en conservant sa propre numérotation. Dans sa forme ancienne, le dernier groupe de chiffres encode la version d’Agave sous-jacente ; dans sa forme récente figure une numérotation calendaire, telle que la documentation de Firedancer la donne dans l’exemple v26.08.2 pour la version courante de Frankendancer.

En décodant la forme ancienne, une image éclairante se dessine : les 40 nœuds de ce groupe tournent tous sur un noyau 4.2. Aucun nœud portant un numéro de version Frankendancer ne déclare un noyau 4.3. Les six validateurs en 4.3 sont tous des nœuds Agave en version alpha ou bêta.

Pour vous, détenteur, une chose surtout en découle : la question de savoir si votre validateur tourne déjà sur la nouvelle version ne se tranche pas au nom du prestataire. Seule compte la version déclarée. Et vous pouvez la consulter sans rien installer.

Devez-vous agir en tant que délégateur de SOL ? La réponse tient à votre mode de conservation

Délégateur, validateur et commission en une phrase chacun

Un validateur est une machine qui vérifie les blocs, participe au vote et perçoit des récompenses à ce titre. Vous êtes délégateur lorsque vous affectez vos SOL à un validateur sans exploiter vous-même un nœud ; vos jetons ne quittent pas votre portefeuille et ne sont pas transférés au validateur. La commission est la part des récompenses que le validateur conserve.

Trois cas de figure en découlent, et un seul appelle votre attention :

  • Des SOL sur une plateforme d’échange, stakés ou non : rien ne change pour vous. La plateforme exploite la technique et supporte le risque de la bascule. Quels prestataires proposent le staking et à quelles conditions, notre panorama des meilleures plateformes de staking le montre.
  • Des SOL en autoconservation, mais non stakés : rien à faire non plus. Une mise à niveau de protocole n’exige de vous aucune opération dans votre portefeuille, aucun échange et aucune validation.
  • Des SOL en autoconservation et délégués à un validateur : ici, un coup d’œil s’impose. Non que vos jetons soient menacés, mais un validateur qui manque la bascule ne produit aucune récompense pendant la durée de son indisponibilité et vous coûte donc du rendement.

Une précision utile : vos SOL restent vos SOL dans chacun de ces cas. Une barrière de fonctionnalité modifie le comportement du réseau, pas le solde de votre compte. Cette mise à niveau ne comporte rien à réclamer, rien à échanger et aucune échéance au terme de laquelle quelque chose expirerait.

Comment savoir en cinq minutes quelle version de client fait tourner votre validateur

La voie que nous avons empruntée pour la mesure ci-dessus est ouverte à tous. Il vous faut l’adresse de votre compte de vote, que tout portefeuille doté d’une fonction de staking vous affiche :

  1. Consultez votre délégation. Ouvrez la rubrique de staking de votre portefeuille et relevez le nom ou l’adresse du validateur auquel vous avez délégué.
  2. Vérifiez la version. Les tableaux de bord publics de validateurs indiquent pour chaque nœud la version logicielle déclarée. Si une 4.2 y figure encore à partir de la mi-septembre, alors que la recommandation générale porte depuis longtemps sur la 4.3, c’est votre signal.
  3. Vérifiez le statut. Ces mêmes tableaux indiquent si un validateur est considéré comme décroché et quel est son taux de blocs manqués. Ces deux valeurs en disent plus sur la qualité de votre délégation que n’importe quelle annonce de rendement.
  4. Redéléguez au besoin. Vous pouvez à tout moment porter votre délégation sur un autre validateur. Le changement prend effet à la frontière d’époque suivante, soit, à la cadence que nous avons mesurée, sous quelque 38 heures.

Un moment judicieux pour cette vérification est le 22 ou le 23 septembre, juste après la recommandation générale. Avant cela, une 4.2 n’est pas un manquement, c’est l’état recommandé.

Pourquoi le 21 septembre est pour vous l’échéance la plus importante

Le 28 septembre est le jour dont on parle. Le jour où vous pouvez discerner quelque chose est le 21 septembre. Jusque-là, un validateur resté sur l’ancienne version respecte les règles, puisque la recommandation dit expressément le contraire. À partir du 21 septembre, la situation s’inverse : celui qui ne bascule pas alors a laissé passer une semaine que le calendrier prévoit délibérément comme tampon.

Ce renversement est la véritable raison pour laquelle il vaut la peine de retenir cette date : une indication technique devient un critère de qualité de votre validateur. Un opérateur qui suit l’échelonnement et se porte volontaire tôt en dit davantage sur son sérieux que n’importe quelle présentation de soi.

Prêtez attention au deuxième jalon, le 8 septembre : l’appel s’adresse aux volontaires pour dix pour cent du stake. Un validateur qui y participe fait sciemment tourner une version récente en production. C’est un signe d’engagement dans la communauté et, en même temps, un risque un peu plus élevé. Les deux vont de pair, et aucun des deux n’est en soi une faute.

Ce qu’Alpenglow change techniquement : Votor, 150 millisecondes et le seuil de 40 %

Alpenglow remplace le procédé de vote actuel, Tower BFT, par Votor, un mécanisme à deux étages. Si un bloc réunit par la voie rapide les voix de 80 % du stake, il est aussitôt réputé définitif ; à défaut d’une telle majorité, deux tours de 60 % chacun tranchent. C’est ce qu’énonce la proposition SIMD-0326, qui a passé le vote des validateurs et figure depuis au registre officiel des Solana Improvement Documents. La Fondation Solana avance environ 150 millisecondes comme cible pour la finalité. La finalité est le moment à partir duquel une transaction ne peut plus être annulée, et elle se distingue du délai de confirmation qu’affiche un portefeuille.

La seconde modification concerne la résistance du réseau. Sous le procédé actuel, la finalité s’arrête dès que plus d’un tiers du stake fait défaut. Alpenglow porte cette limite à 40 %. Le caractère concret de cette question est apparu le jour même de la publication du calendrier : une panne chez l’hébergeur Teraswitch a retiré du réseau 28,83 % des SOL stakés selon Solana Compass, soit 4,5 points de pourcentage sous le seuil en vigueur aujourd’hui.

Une précision importante pour l’appréciation du cours du SOL : une mise à niveau du consensus relève de l’infrastructure. Elle ne comporte aucune distribution, aucun nouveau jeton et aucun droit que vous pourriez faire valoir. Tirer d’une date d’activation une conclusion sur le cours revient à confondre deux plans distincts.

Validator Admission Ticket : ce que la mise à niveau change aux coûts de votre validateur

Un volet de cette refonte n’est pratiquement jamais mentionné dans la couverture germanophone, alors qu’il touche à la rentabilité de chaque nœud. Aujourd’hui, un validateur doit inscrire son vote sur la blockchain pour chaque créneau et acquitte à ce titre, selon SIMD-0326, environ un SOL de frais par jour. Sous Alpenglow, les votes ne transitent plus par la chaîne, et ce poste de coûts disparaîtrait purement et simplement.

Pour préserver l’équilibre économique, la proposition instaure le Validator Admission Ticket, en abrégé VAT. Il s’agit d’une redevance prélevée sur le compte d’un validateur avant son admission à une époque ; qui ne peut l’acquitter sort de l’ensemble actif. Son montant est fixé à 80 % des frais de vote actuels, soit d’abord environ 0,8 SOL par jour ou 1,6 SOL par époque. À la différence d’aujourd’hui, cet argent est intégralement brûlé, ce qui freine l’inflation.

La proposition limite en outre l’ensemble actif aux 2 000 validateurs disposant du stake le plus élevé, l’implémentation s’en trouvant nettement simplifiée. Sur la base des chiffres actuels, cette limite est lointaine : notre mesure a recensé 679 validateurs actifs. Pour vous, délégateur, cela signifie que votre validateur ne sortira pas de l’ensemble du fait de cette règle dans un avenir prévisible, pour peu qu’il honore la redevance.

Macrophotographie d’une croix de Malte en laiton et acier, le doigt d’entraînement juste avant la rainure suivante, à côté une pièce dressée sur la tranche frappée du symbole Bitcoin
Un mécanisme à croix de Malte n’avance que par crans fixes : les frontières d’époque de Solana se comportent exactement ainsi.

Ce que la mise à niveau Alpenglow accélère et ce qui reste identique

Comme les mises à niveau d’une blockchain suscitent régulièrement des attentes auxquelles elles ne répondent pas, voici la distinction, faite sobrement. Le délai de transaction qu’un portefeuille vous affiche comme confirmation est déjà court aujourd’hui ; ce qui se raccourcit, c’est le délai jusqu’à l’irréversibilité. L’accélération visée, autour de 150 millisecondes, porte donc sur le moment à partir duquel un paiement ne peut réellement plus être repris.

Une telle rapidité se ressent surtout là où des montants sont réacheminés en cascade rapprochée : dans les applications de négociation, dans les paiements en caisse et dans les ponts entre chaînes qui attendent la confirmation définitive avant de libérer des actifs. Pour vous, détenteur qui effectue un virement une fois par mois, la différence reste invisible au quotidien.

Ce qui reste expressément identique : le nombre de vos jetons, vos adresses, vos mots de récupération et votre manière de conserver vos cryptomonnaies. Un procédé de consensus est la règle par laquelle le réseau s’accorde sur un ordre, et cette règle laisse les avoirs intacts. Dans la concurrence entre les grandes blockchains de couche 1, la refonte n’en reste pas moins notable, car elle concerne tout l’écosystème : chaque application tournant sur Solana hérite d’une finalité plus courte sans avoir elle-même à changer quoi que ce soit.

Ce qu’une mise à niveau manquée signifie pour votre rendement de staking

Un validateur gagne des récompenses en participant au vote sur la chaîne et en produisant lui-même des blocs. S’il tombe, il ne gagne rien, et comme votre récompense dépend de la sienne, vous ne gagnez rien non plus pendant ce temps. Rien ne vous est pour autant retiré : votre avoir reste intact, seul le produit de la période d’indisponibilité vous échappe.

Le poids de ce manque à gagner dépend de la durée. Un validateur qui met une demi-époque à se remettre en marche après une bascule vous coûte environ une journée de produit. Aux ordres de grandeur actuels, c’est un montant qui disparaît dans les décimales. Un validateur qui reste décroché des semaines durant constitue en revanche un vrai problème, et ce indépendamment de toute mise à niveau.

S’y ajoute une seconde évolution, à l’œuvre sur la même période et sans rapport avec Alpenglow : la courbe d’émission de Solana a fait l’objet d’une décision distincte, qui abaissera le rendement du staking dans les années à venir. Nous en avons détaillé les ressorts dans le rendement du staking Solana baisse. Pour votre appréciation, cela signifie que le rendement évolue actuellement sous plusieurs effets, et que la part qu’y prend une seule mise à niveau du consensus est la plus faible d’entre elles.

Provisoire veut dire provisoire : la solidité de l’échéance et les signes d’un report

Le calendrier inscrit sa propre réserve dès sa première ligne : il s’agit d’un échéancier provisoire, toutes les dates peuvent changer, et avant chaque mise à niveau il convient d’attendre les annonces sur Discord. Ce n’est pas une clause de style, c’est la pratique habituelle pour un réseau dont la bascule s’opère sans instance centrale. Le 28 septembre est une date cible, pas une échéance assortie d’un effet juridique.

Il existe toutefois un bon indice du sérieux de ce tableau : les lignes déjà traitées portent des dates de livraison, et deux d’entre elles se situent avant leur date cible. Cela plaide pour un plan tenu et non pour un document de vœux.

Un report se repère à deux endroits précis, sans dépendre de la couverture médiatique. D’abord dans le calendrier lui-même : si la ligne du candidat pour le réseau principal du 4 septembre reste sans date de livraison, toute la chaîne qui suit se décalera très probablement. Ensuite dans la diffusion : si la part de stake sur la 4.3 se situe encore le 15 septembre au niveau de notre mesure actuelle, 0,39 %, au lieu des 25 % visés, le 28 septembre ne sera pratiquement plus tenable. Ces deux vérifications vous coûtent deux minutes et valent mieux que n’importe quelle prévision.

Vérifier l’échéance Alpenglow de Solana : ce qu’il faut retenir

La question de la date admet une réponse, et cette réponse est peu spectaculaire : une date cible au 28 septembre, un effet qui s’étend sur les frontières d’époque suivantes jusqu’en octobre, et, pour l’immense majorité des détenteurs, aucune démarche à entreprendre. Trois étapes pour clore le sujet :

  1. Déterminez en une minute si cela vous concerne. Si vos SOL sont chez une plateforme d’échange ou non stakés dans votre portefeuille, vous en avez terminé. Si vous déléguez vous-même, notez le 22 septembre pour la vérification de version. Et si vous comparez de toute façon où le staking est possible et à quelles conditions, le panorama des meilleures plateformes de staking vous aidera à y voir clair.
  2. Jugez votre validateur sur des critères durs plutôt que sur le rendement affiché. Version déclarée, statut et taux de blocs manqués vous en disent plus que n’importe quel pourcentage sur une page d’accueil. Qui préfère confier entièrement le sujet trouvera chez les prestataires de notre comparatif des meilleures plateformes d’échange de cryptomonnaies la formule la plus commode, et la moins autonome.
  3. Continuez de documenter vos revenus de staking comme auparavant. Une mise à niveau du consensus ne change rien au traitement fiscal des récompenses ; les entrées restent à évaluer au moment où elles surviennent. Si vous ne tenez pas encore de relevé propre, le comparatif des logiciels fiscaux et suiveurs de portefeuille pour cryptomonnaies est le bon point de départ.

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

Note de transparence : Cet article a été rédigé avec l’aide d’une intelligence artificielle et relu par notre rédaction avant publication. Tous les chiffres et affirmations ont été vérifiés à partir des sources primaires liées dans le texte. L’image d’illustration a été générée par IA.

Vous pourriez aussi aimer