Date de Glamsterdam : Ethereum forke Sepolia le 28 septembre 2026

Glamsterdam a pour la première fois une date. Le 28 septembre 2026 à 14:44:48 UTC, la prochaine grande mise à jour d’Ethereum doit être activée sur le réseau de test Sepolia. Le chiffre provient du compte rendu de la réunion des développeurs du 20 août 2026, il est fixé à l’époque et au slot près, et six équipes de clients l’ont confirmé dans le chat de séance sans opposition.

Deux réserves doivent être énoncées dans le même souffle, faute de quoi un calendrier se transforme en promesse. Premièrement, la date reste sous condition : le compte rendu note expressément que la décision a été renvoyée à la réunion suivante. Deuxièmement, elle concerne un réseau de test et nullement un réseau principal. Pour le mainnet, il n’existe toujours aucune date, et les chiffres qui circulent à ce sujet ne tiennent plus au calcul depuis le 20 août.

Ce texte vous montre d’où vient la date, comment la recalculer vous-même, ce qui peut encore la faire tomber et ce qui change pour vous, détenteur d’ETH. La genèse du contenu proprement dit, c’est-à-dire quelles modifications se trouvent réellement dans Glamsterdam et comment s’organise la sélection pour la mise à jour suivante, figure dans notre article Mise à jour Ethereum après Glamsterdam : ce qui est réellement décidé dans Hegotá. Ici, il est question du calendrier.

Quand arrive Glamsterdam ? La première date figure au compte rendu des développeurs

Les développeurs du cœur d’Ethereum coordonnent leurs mises à jour lors de visioconférences publiques, les All Core Devs Calls. Un appel ACDC en est la variante consacrée à la couche de consensus, autrement dit la séance au cours de laquelle les équipes des clients de consensus s’accordent sur le calendrier, les anomalies et les réseaux de test. Ces appels font l’objet d’un compte rendu, et compte rendu comme transcription du chat sont ensuite publiés dans le dépôt de planification du projet.

La phrase dont il s’agit figure au compte rendu de l’appel ACDC #185 du 20 août 2026. Sous la rubrique consacrée à l’état des forks, on lit : Sepolia Glamsterdam fork proposed: epoch 351232, slot 11239424, Sep 28 2026 — no objections raised; decision deferred to next ACDC. La même ligne réapparaît une seconde fois dans la liste des objectifs du même document, assortie cette fois de la mention pending confirmation at next ACDC.

La transcription du chat permet de suivre le moment à la minute près. À 27:50, Parithosh Jayanthi, responsable de la coordination des réseaux de test à l’Ethereum Foundation, inscrit les valeurs complètes dans le chat : Sepolia: epoch 351232, slot 11239424, unix (1790606688), Mon 28 Sep 2026, 14:44:48. Dans les 60 secondes qui suivent, six participants accusent réception du message par un émoji de navire, signe d’approbation habituel dans ces séances : les représentants de Lodestar, ethrex, Lighthouse, Nethermind, Teku et Prysm. Peu après, Barnabas Busa consigne la manière dont il faut le lire : also no objection = agreement.

Ce chiffre se distingue ainsi des dates qui circulent d’ordinaire dans la couverture médiatique. Il ne s’agit ni de l’estimation d’un observateur, ni de la date souhaitée par une équipe isolée, mais d’une proposition émanant de la coordination, à laquelle les équipes de clients n’ont pas fait objection au compte rendu. Elle n’en est pas pour autant contraignante.

Ce que l’époque, le slot et l’horodatage Unix disent du fork Sepolia

Un slot est la fenêtre fixe de douze secondes durant laquelle un seul bloc peut être proposé sur Ethereum. Une époque est un ensemble de 32 slots de ce type, soit une fenêtre de six minutes et 24 secondes. Les mises à jour sont accrochées au début d’une époque, non à une heure du calendrier. C’est la raison pour laquelle les comptes rendus font toujours figurer trois chiffres côte à côte.

Le calcul sous-jacent se reconstitue en deux étapes. Le numéro de slot est le numéro d’époque multiplié par 32 : 351 232 fois 32 donne 11 239 424, et c’est exactement le chiffre inscrit au compte rendu. L’horodatage découle de la date de lancement de la chaîne balise Sepolia augmentée de douze secondes par slot. Le résultat est la valeur Unix 1 790 606 688, laquelle correspond au lundi 28 septembre 2026 à 14:44:48 UTC. En heure d’été allemande, il serait 16:44:48.

En pratique, cela signifie une chose que les titres de presse perdent régulièrement : l’heure est une valeur dérivée et non un rendez-vous. Elle ne tient qu’aussi longtemps que le réseau produit ses blocs en cadence. Si des blocs viennent à manquer, l’activation réelle glisse vers l’arrière sans que personne n’ait modifié la date.

Sepolia, Hoodi, mainnet : pourquoi un hard fork Ethereum a lieu trois fois

Un hard fork est une modification des règles du protocole qui n’est pas rétrocompatible : un logiciel qui ne prend pas la mise à jour ne suit plus la chaîne ensuite. Parce qu’une erreur à cet endroit coûterait cher, chaque modification est déployée par paliers. D’abord sur des réseaux de test internes, ensuite sur des réseaux de test publics, en dernier lieu sur le réseau principal.

Un réseau de test est une chaîne autonome dotée du même logiciel, mais avec des jetons sans valeur. Sepolia est le réseau de test sur lequel les développeurs d’applications vérifient leurs contrats ; Hoodi est le réseau plus récent, pensé avant tout pour l’infrastructure de validation et de staking. Tous deux ont eu leur ligne dans l’appel.

Pour Hoodi, la même source a indiqué l’époque 132352, le slot 4 235 264 et la valeur Unix 1 793 036 568, soit le lundi 26 octobre 2026 à 17:42:48 UTC. Cette ligne est toutefois moins solide que celle de Sepolia : le compte rendu l’assortit de la mention contingent on stable DevNets, et dans le chat le représentant de Lighthouse, kingy_sigp, répond par cette phrase : that date is fine with us provided we get a stable devnet ofc.

Pour le mainnet, en revanche, le compte rendu ne contient pas une seule ligne. Ni dans les décisions ni dans la liste des objectifs n’apparaît de date pour le réseau principal. Qui lit aujourd’hui un chiffre concernant le mainnet lit une projection sans décision derrière elle.

La panne du DevNet 8 : une erreur de cache sur les dépôts builder a fait tomber la finalité

Un DevNet est un réseau de test éphémère que les développeurs mettent en place spécialement pour un palier de mise à jour, souvent pour quelques jours seulement. Six heures avant l’appel du 20 août, le palier Gloas a été activé sur le DevNet 8, et quelque chose a mal tourné à cette occasion.

Le compte rendu consigne le fait et sa cause en une phrase : l’activation a déclenché une non-finality, la finalisation venait tout juste de se rétablir au moment de l’appel, et la raison invoquée est une erreur de cache sur les dépôts builder lors de la transition de fork. Trois clients de consensus étaient concernés : Lighthouse, Prysm et Teku.

Un client est le logiciel au moyen duquel un nœud participe au réseau. Ethereum est délibérément mis en œuvre en parallèle par plusieurs équipes indépendantes, afin qu’une erreur dans un logiciel n’emporte pas le réseau tout entier. C’est précisément cette architecture qui a fonctionné ici : l’erreur a touché trois implémentations, le réseau est revenu, et des mesures correctives étaient déjà sur la table pendant l’appel.

Le compte rendu en nomme deux de manière concrète. Chez Lodestar, une optimisation du prétraitement des dépôts a ramené la durée de la transition de fork d’environ 20 secondes à quelque 500 millisecondes ; la modification figure déjà dans la branche principale. Chez Prysm, le cache des dépôts builder a été retiré de la branche avant le fork, et une optimisation supplémentaire réduit le rétablissement à un seul slot, même sans cache.

Ce que signifie la finalité et pourquoi sa perte freine le calendrier Glamsterdam

La finalité désigne l’état dans lequel un bloc est réputé définitif et ne pourrait plus être annulé qu’au prix de la perte de mises considérables. Si elle fait défaut, la chaîne continue certes de fonctionner et de produire des blocs, mais rien n’en est clos. Pour une bourse, un pont ou un protocole de staking, c’est l’état le plus inconfortable qui soit, parce qu’il devient impossible de dire avec certitude quelle version fait foi.

Le chat contient une controverse portant précisément sur cette appréciation, et elle mérite d’être lue parce qu’elle sépare proprement deux perspectives. Barnabas Busa raisonne du point de vue du protocole : we might have unfinality on mainnet too. Why would this be an issue? We had no consensus issues. Dima Gusakov, du prestataire de staking Lido, répond du point de vue de l’opérateur : c’est justement à cause de la perte de finalité que son équipe n’a pas pu vérifier comment ses oracles et ses outils traversent un hard fork.

Le sérieux avec lequel cet état est pris par principe ressort d’une remarque du même Barnabas Busa plus tard dans l’appel : I think its also safe to say if we have 4-5 months non finality its game over. Le propos visait une tout autre proposition relative à la conservation des données, mais il donne l’ordre de grandeur dans lequel on raisonne ici.

Lido et Optimism réclament une fenêtre de test, seule réserve inscrite au compte rendu

La date tient sans objection formelle, mais non sans réserves. Deux opérateurs ont expressément posé des conditions au cours de l’appel, et tous deux sont nommément consignés.

Lido, selon Dima Gusakov, a besoin d’au moins un jour, de préférence deux, sur un DevNet stable afin de vérifier ses oracles et ses outils avant l’activation de Glamsterdam. Optimism, par la voix de Chris Berry, a demandé une fenêtre comparable et l’a précisé dans le chat : We can do 1-2 days if we know. S’y est ajoutée la demande d’annoncer le fork sur le DevNet une semaine à l’avance, afin que les validateurs soient en ligne à temps.

Gusakov se fait plus net sur la date elle-même. Peu après la ligne consacrée à Hoodi, il écrit dans le chat : I would rather have both dates a bit later. Like a week or so to have more room for the pending devnets testing. Deux autres participants, Miguel Tenorio et Chris Berry, ont assorti ce message d’un signe d’approbation. Ce n’est pas un veto et cela n’a pas arrêté la proposition, mais c’est l’unique voix documentée à juger le 28 septembre trop précoce.

Qui veut situer la date dispose désormais des deux versants. En sa faveur, six approbations des équipes de clients et la constatation, au compte rendu, qu’aucune objection n’a été soulevée. En sa défaveur, le fait que le plus grand opérateur de staking du réseau souhaite davantage de marge et que la ligne consacrée à Hoodi est expressément subordonnée à des DevNets stables.

Le 3 septembre est la date derrière la date : l’appel ACDC #186 tranche

La formulation décisive du compte rendu est le membre de phrase decision deferred to next ACDC. Le 28 septembre est donc un objectif qui doit encore être soumis au vote. La véritable question est par conséquent : quand cet objectif devient-il une décision ?

Ces appels se tiennent toutes les deux semaines. L’appel #184 a eu lieu le 6 août, l’appel #185 le 20 août. Le prochain est donc celui du 3 septembre 2026. D’ici là, la date reste une proposition largement approuvée ; ensuite, elle sera soit confirmée, soit repoussée, soit scindée.

Pour vous, lecteur, cela présente une utilité pratique. Si vous lisez quelque part entre le 3 et le 5 septembre que Glamsterdam a désormais une date, il s’agit de la confirmation de cette proposition et non d’une nouveauté. Si en revanche une autre date que le 28 septembre y figure, c’est que quelque chose a été déplacé lors de l’appel, et il vaut alors la peine d’aller consulter le compte rendu.

Pourquoi les dates de mainnet en circulation, comme le 4 novembre, ne tiennent plus au calcul

Les agrégateurs de calendriers anglophones affichent depuis des semaines trois chiffres pour Glamsterdam : Sepolia le 21 septembre, Hoodi le 5 octobre et le mainnet le 4 novembre 2026. Sur les pages concernées, ces indications sont le plus souvent signalées comme des projections issues d’objectifs antérieurs et ne s’appuient sur aucune décision.

Au 20 août, les trois sont dépassées. Le chiffre de Sepolia a reculé d’une semaine, celui de Hoodi de trois semaines. Et un fork du mainnet le 4 novembre tomberait seulement neuf jours après le fork de Hoodi du 26 octobre. Chez Ethereum, plusieurs semaines séparent habituellement le deuxième réseau de test public du réseau principal, semaines pendant lesquelles l’activation est observée et évaluée. Neuf jours seraient inhabituellement courts pour cette étape.

Les dépêches germanophones de la mi-août en sont, pour leur part, restées à l’état antérieur à l’appel. Glamsterdam y est une mise à jour repoussée au quatrième trimestre 2026 et accusant du retard. C’était exact jusqu’au 19 août et c’est incomplet depuis, faute des lignes relatives aux réseaux de test. Si, dans cette situation, vous calez vos décisions sur une date trouvée dans un titre de presse, la contre-vérification à la source en vaut la peine. Qui compare de toute façon des prestataires trouvera les conditions actuelles dans notre comparatif des meilleures bourses de cryptomonnaies.

L’EIP-7610 est annulée de Glamsterdam, pas reportée

Un EIP est une Ethereum Improvement Proposal, c’est-à-dire la proposition formelle d’une modification technique isolée. Les EIP qui entrent dans une mise à jour sont retenues par les développeurs du cœur lors de ces appels précisément, et la liste demeure mouvante jusqu’à peu avant l’activation.

Lors de l’appel du 20 août, un participant s’est enquis du statut de l’EIP-7610, sortie du périmètre de Glamsterdam : était-elle reportée ou purement et simplement annulée ? La réponse de l’éditeur d’EIP Jochem Brouwer dans le chat est sans ambiguïté : To answer explicitly, cancelled. I will also ask authors to formally withdraw this EIP. Le compte rendu reprend le même point parmi les décisions et en donne la raison : l’EIP-7610 est remplacée par l’EIP-8253, laquelle vise Hegotá, soit la mise à jour postérieure à Glamsterdam.

La différence entre reportée et annulée paraît académique, mais elle a des conséquences sur le calendrier. Une EIP reportée réapparaît sur la même liste au tour suivant. Une EIP annulée est close, et une autre proposition, de contenu différent, prend sa place.

Hegotá entame sa première sélection : EIP-833 et EIP-8379

Tandis que Glamsterdam se dirige vers les réseaux de test, la sélection pour la mise à jour suivante a commencé lors du même appel. Selon le compte rendu, deux propositions sont considérées comme provisoirement retenues : l’EIP-833, qui corrige une erreur de décalage d’une unité dans le calcul des racines de points de contrôle et améliore la précision des votes de cible, ainsi que l’EIP-8379, qui doit faire du client de consensus l’unique source de synchronisation et réduire ainsi la diffusion redondante de blocs.

Une troisième proposition, l’EIP-12188 relative au raccourcissement de la fenêtre de conservation des blocs de consensus, n’a atterri ni sur la liste ni à la corbeille : elle est retournée à la discussion de recherche. Le compte rendu note à ce sujet qu’un participant a mis en cause la motivation et qu’un autre s’est montré prudemment ouvert.

Plus intéressante pour le calendrier est la décision d’organisation qui l’accompagne. Toutes les équipes de clients doivent publier d’ici la mi-septembre une première évaluation des propositions Hegotá, en quatre niveaux de S à D. Barnabas Busa a défini ces niveaux dans le chat : S vaut pour une recommandation appuyée d’inclusion, A pour une recommandation dès que les points ouverts sont réglés, B pour un objectif ambitieux et D pour un rejet. D’ici la DevCon, il doit en sortir un consensus approximatif sur le périmètre.

Ce qui change pour vous, détenteur d’ETH, le 28 septembre

La réponse courte : rien. Le 28 septembre concerne Sepolia, et Sepolia est un réseau de test. L’ETH qui y est utilisé n’a aucune valeur de marché, il est distribué gratuitement par des robinets et ne peut être échangé contre de l’ETH réel. Un fork sur Sepolia ne touche ni votre solde, ni vos adresses, ni votre situation fiscale.

Cette mise à jour ne comporte pas davantage de capture d’état, d’échange ou de nouveau jeton. Glamsterdam est une mise à jour de protocole de la chaîne existante, ni une scission de chaîne ni une migration. Quiconque vous raconte autre chose cherche à vous vendre quelque chose.

C’est précisément là que vise l’escroquerie la plus fréquente autour des dates de fork. Après chaque annonce de date apparaissent des messages appelant à agir : une prétendue migration de portefeuille, un formulaire de déblocage, un délai. La règle qui s’y oppose est simple et ne souffre aucune exception : une mise à jour d’Ethereum ne vous demandera jamais de saisir votre phrase de récupération, de déplacer des fonds ou de vérifier un compte.

Staking, nœud personnel et solde en bourse : qui doit vraiment agir lors d’un fork

Un hard fork ne crée d’obligation d’agir qu’en un seul endroit, à savoir chez ceux qui exploitent eux-mêmes un logiciel. Le cercle est restreint.

Si vous exploitez votre propre nœud ou validateur

Vous devez alors mettre à jour votre logiciel client, avant l’activation, vers une version qui connaît les nouvelles règles. Pour les réseaux de test, cela vaut à compter de la date correspondante ; pour le mainnet, plus tard. Qui l’omet ne suit plus la chaîne après le fork. L’expérience du DevNet du 20 août montre en outre qu’il vaut mieux retenir non pas la toute première version, mais celle dans laquelle les erreurs de transition ont déjà été corrigées.

Si vous stakez via un prestataire

C’est alors le prestataire qui prend la mise à jour en charge, et c’est précisément pour cela que Lido a réclamé une fenêtre de test lors de l’appel. Il vous reste à savoir en amont qui est votre prestataire et comment il communique. Un prestataire qui garde le silence sur les mises à jour ne sera pas plus disert lors du prochain incident.

Si vos ETH sont sur une bourse ou dans un portefeuille

Alors rien ne vous incombe. La bourse met elle-même ses nœuds à jour, et les portefeuilles dépourvus de nœud propre suivent automatiquement. L’expérience montre que certaines bourses suspendent dépôts et retraits pendant quelques heures autour des grands forks de mainnet. C’est une routine, elle est annoncée à l’avance, et elle ne concerne de toute façon pas les forks de réseaux de test.

Comment vérifier vous-même la date de Glamsterdam en cinq minutes

Vous ne dépendez d’aucun titre de presse. Les documents des développeurs du cœur sont publics, et le chemin qui y mène est celui qu’a emprunté ce texte.

Dans le dépôt de planification du projet, les pièces de séance sont classées par date. Pour l’appel du 20 août 2026, il s’agit de deux fichiers : le résumé des décisions et des objectifs et la transcription intégrale du chat. Dans le premier, vous trouverez les lignes relatives à l’état des forks, aux décisions et aux objectifs ; dans la seconde, les horodatages, les chiffres dans leur formulation d’origine et les réactions des équipes.

La conversion, vous la faites vous-même. Multipliez le numéro d’époque par 32, vous obtenez le slot. Multipliez le slot par douze secondes et ajoutez la date de lancement de la chaîne concernée, vous obtenez l’horodatage Unix. Si votre résultat concorde avec l’heure annoncée, le chiffre est cohérent en lui-même. S’il s’en écarte, quelqu’un a recopié sans refaire le calcul.

Pour une vue d’ensemble de l’évaluation des différentes propositions, le projet exploite en outre un outil de classement public, auquel l’appel a expressément renvoyé. Vous pourrez y lire, à partir de la mi-septembre, comment les équipes de clients classent les propositions Hegotá.

Lire les dates de mise à jour d’Ethereum : ce qu’il faut retenir

Le 28 septembre 2026 est la première date solide dont dispose Glamsterdam. Elle vaut pour un réseau de test, elle est subordonnée à une confirmation le 3 septembre, et elle ne dit encore rien du réseau principal. Qui garde cela en tête lira les semaines à venir bien plus sereinement que le marché.

1. Notez le 3 septembre dans votre agenda, pas le 28 septembre. C’est ce jour-là que l’appel suivant décidera si la date tient. D’ici là, toute dépêche employant le mot « décidé » manque de précision. Si vous vérifiez de toute façon des conditions, notre comparatif des bourses est l’entrée la plus rapide.
2. Réglez à l’avance la question de savoir qui fait la mise à jour chez vous. Avec un nœud personnel, c’est vous ; avec un prestataire de staking, c’est le prestataire. Qui choisit encore son prestataire devrait prêter attention à sa communication autour des mises à jour ; les différences figurent dans notre comparatif du staking.
3. Traitez tout appel à agir comme une tentative d’escroquerie. Une mise à jour de protocole n’exige jamais la migration de vos fonds. Détenir soi-même ses clés est la meilleure protection contre ce procédé ; les appareils prévus pour cela figurent dans notre comparatif des portefeuilles matériels.

(Au 21 août 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.)