Mise à jour Ethereum après Glamsterdam : ce qui est réellement décidé dans Hegotá

La prochaine grande mise à jour du réseau Ethereum s'appelle Glamsterdam ; celle qui la suivra porte le nom de Hegotá. Depuis le 16 août 2026, un chiffre circule dans la presse spécialisée : 66 propositions seraient en discussion pour Hegotá. Y lire que la mise à jour apportera 66 nouveautés revient à se méprendre sur ce chiffre. Dans le document de planification officiel des développeurs d'Ethereum figure ce jour-là exactement une proposition fermement programmée.

Cet article vous montre d'où vient l'écart, comment lire vous-même le document de planification et à quoi vous reconnaissez qu'une fonction annoncée atterrira effectivement dans le réseau. Cette compétence vous servira bien au-delà d'aujourd'hui. D'ici à l'activation de Hegotá, visée pour 2027, vous lirez des dizaines d'annonces sur de prétendues fonctions Ethereum, dont une part considérable ne verra jamais le jour. Tous les chiffres de ce texte proviennent d'un décompte que nous avons réalisé nous-mêmes sur les documents EIP officiels le 16 août 2026.

Ce qu'est Hegotá et où se situe cette mise à jour Ethereum dans la feuille de route

Une mise à jour Ethereum est techniquement un hard fork : une modification des règles du protocole que tous les nœuds du réseau doivent adopter au même moment. Celui qui ne suit pas se retrouve sur une chaîne que les autres ne suivent plus. C'est pourquoi chaque changement de ce type fait l'objet de mois de concertation, est éprouvé sur des réseaux de test et ne reçoit qu'ensuite une date d'activation ferme. Si vous souhaitez revoir tranquillement les fondations qui se trouvent derrière, notre explication de base sur le fonctionnement d'Ethereum vous y aidera.

Les mises à jour portent des noms dépourvus de signification, ce qui complique le suivi. Les développeurs principaux travaillent actuellement sur Glamsterdam, dont la mascotte est, selon le document de planification, un ours polaire. En parallèle se prépare la mise à jour suivante, Hegotá. Chacun des deux chantiers dispose de son propre document de pilotage, dans lequel est consigné l'état de chaque modification. Pour Glamsterdam, il s'agit de l'EIP-7773, créé le 26 septembre 2024. Pour Hegotá, c'est l'EIP-8081, créé le 11 novembre 2025. Les deux portent à ce jour la mention d'état « Draft ».

Ce que contient Glamsterdam, et pourquoi cette mise à jour est jugée particulièrement lourde de conséquences, nous l'avons détaillé dans notre article sur Glamsterdam et le cours de l'Ethereum du 5 avril 2026. Hegotá en est le successeur et se trouve aujourd'hui au point où Glamsterdam se trouvait il y a environ deux ans.

Pourquoi la phase de sélection vous concerne directement en tant que détenteur d'ETH

Il serait commode de ranger l'affaire au rayon des sujets de développeurs. Cela ne mène pas loin, car un hard fork modifie simultanément et pour tout le monde les frais de calcul, les types de transactions et les obligations des validateurs. Deux exemples tirés de la liste déjà fermement programmée pour Glamsterdam le rendent concret : les EIP-8037 et EIP-8038 augmentent le coût en gaz de l'écriture et de la lecture des données d'état, tandis que l'EIP-7981 renchérit les listes d'accès. Quiconque travaille beaucoup avec des contrats intelligents paiera ensuite d'autres frais qu'aujourd'hui.

Le staking d'ETH est également concerné. L'EIP-8061, inscrit sur la liste Glamsterdam, relève le plafond du nombre de validateurs pouvant sortir ou être regroupés par unité de temps. C'est l'un des éléments qui déterminent la durée d'attente de votre solde lorsque vous soldez une position. Si vous percevez vos récompenses par l'intermédiaire d'un prestataire et souhaitez connaître les conditions qui s'y appliquent actuellement, vous trouverez le tableau comparatif dans notre comparatif des plateformes de staking ; les délais de versement des prestataires et les règles du protocole sont deux freins distincts, qui agissent indépendamment l'un de l'autre.

Pour vous qui détenez de l'ETH et le laissez simplement dormir, le calcul est plus simple : votre plateforme d'échange doit mettre ses nœuds à jour en temps voulu, faute de quoi les dépôts et les retraits s'arrêtent aux alentours de la date d'activation. C'est précisément la raison pour laquelle les plateformes annoncent des fenêtres de maintenance avant chaque hard fork. Pour savoir avec quelle stabilité votre propre plateforme traverse ces transitions et quels frais s'y appliquent, l'aperçu figure dans le comparatif des plateformes crypto.

Le méta-document de hard fork EIP-8081 est la seule liste qui engage

Pour chaque mise à jour, les développeurs principaux créent ce que l'on appelle un méta-EIP. Il ne contient aucune technique, seulement un état des lieux : quelles propositions individuelles sont en discussion, lesquelles sont examinées, lesquelles sont fermement programmées et lesquelles ont été écartées. Sont inscrits comme auteurs de l'EIP-8081 Tim Beiko, Alex Stokes, Ansgar Dietrichs, Nixo et Parithosh Jayanthi, soit le même groupe qui a la charge des méta-documents des mises à jour précédentes.

Ce document est important parce qu'il est le seul endroit où un classement est consigné de manière contraignante. Une contribution sur un forum de discussion, un exposé lors d'une conférence ou un message sur un réseau social ne dit rien de la venue effective d'une modification. Ce n'est qu'à partir du moment où quelqu'un soumet une modification du méta-document et où celle-ci est reprise que la proposition possède un état officiel. Vous pouvez consulter le document complet à tout moment : EIP-8081, Hardfork Meta Hegotá.

Le décompte du 16 août 2026 : un EIP programmé, 37 propositions

Nous avons récupéré le document brut dans le dépôt source des développeurs d'Ethereum et compté les entrées de chaque section. La requête a renvoyé le code 200, et le décompte donne le tableau suivant.

Le chiffre le plus parlant de ce relevé est le zéro. Tant qu'aucune proposition n'a été écartée, la sélection n'a pas commencé. Cela concorde avec ce que décrit la presse spécialisée, selon laquelle les développeurs principaux entendent commencer à élaguer lors des prochaines réunions. Pour vous, cela signifie que la majeure partie des 37 propositions soumises n'atterrira pas dans cette mise à jour, et que personne aujourd'hui ne sait de manière fiable lesquelles ce seront.

Les quatre étapes définies par l'EIP-7723 et ce qu'elles promettent réellement

Les termes employés dans le méta-document ne sont pas des tournures de style, mais des états définis. Ils sont fixés dans un document distinct, l'EIP-7723 intitulé « Network Upgrade Inclusion Stages », créé en juin 2024 et parvenu depuis à l'état « Last Call ». Qui sait distinguer ces quatre termes lira toute annonce de mise à jour à venir avec plus de fiabilité que ne le font la plupart des titres de presse. Vous pouvez consulter les définitions ici : EIP-7723, Network Upgrade Inclusion Stages.

« Proposed for Inclusion » n'est qu'une demande

Pour hisser une proposition à ce niveau, il suffit de soumettre une modification du méta-document qui en ajoute l'entrée. Aucun accord des développeurs principaux n'est requis, aucune mise en œuvre achevée ni aucun test. Le document se borne à constater que quelqu'un propose la modification pour cette mise à jour et se tient disponible comme interlocuteur. Les 37 entrées qui figurent actuellement sous ce point chez Hegotá n'ont donc franchi qu'une seule étape : celle du dépôt.

« Considered for Inclusion » est une déclaration d'intention, pas un engagement

Une proposition atteint ce niveau après que les équipes de développement l'ont examinée et expriment l'intention de l'essayer sur un réseau de test. L'EIP-7723 compare expressément cet état à un « concept ACK » issu d'autres projets libres et écrit dans le même paragraphe que cet état ne suffit pas à un déploiement sur le réseau principal. Depuis ce point, une proposition peut à tout moment repasser dans le refus, si les équipes tranchent en ce sens.

« Scheduled for Inclusion » suppose une maturité mesurée

Seul ce niveau signifie qu'une proposition est en route vers le réseau principal. L'EIP-7723 énonce quatre critères de contrôle : la proposition a tourné sur un réseau de test qui a fonctionné de manière stable pendant au moins une semaine et n'a montré aucun défaut critique. La spécification ne comporte plus ni marqueur provisoire ni question de rédaction en suspens. Les interactions avec d'autres propositions sont soit faibles, soit contrôlées sur ce même réseau de test. Et la couverture de test est suffisante, sans que les logiciels des différents fournisseurs divergent entre eux. Même après cela, le classement ne vaut que « sous réserve de problèmes imprévus », et un retrait reste possible depuis ce niveau également.

Un effet secondaire pratique de ces règles mérite d'être retenu : dès que le méta-document passe de l'état « Draft » à l'état « Review », les listes des propositions et des refus en sont retirées. Lors du passage à l'état « Last Call », la liste des candidats examinés disparaît elle aussi. Sur le chemin de son achèvement, le document raccourcit donc au lieu de s'allonger. Si vous le rouvrez dans quelques mois et n'y trouvez soudain qu'une liste brève, c'est un signe d'avancement et non une anomalie.

FOCIL (EIP-7805) est le seul élément acquis de Hegotá

L'unique proposition déjà fermement programmée pour Hegotá porte le numéro EIP-7805 et le sigle FOCIL, pour « Fork-choice enforced Inclusion Lists ». Elle a été créée le 1er novembre 2024 et ses auteurs déclarés sont Thomas Thiery, Francesco D'Amato, Julian Ma, Barnabé Monnot, Terence Tsao, Jacob Kaufmann et Jihoon Song.

Le problème auquel s'attaque FOCIL est décrit sans détour par la spécification elle-même : le droit de construire des blocs est aujourd'hui mis aux enchères auprès de prestataires spécialisés. En conséquence, quelques-uns de ces constructeurs dominent la production de blocs, et la résistance du réseau à la censure en a souffert. Concrètement, cela signifie qu'un constructeur de blocs peut écarter une transaction, par exemple parce qu'elle touche une adresse sanctionnée, sans que vous puissiez exiger qu'un autre la reprenne.

Le mécanisme fonctionne en quatre étapes. À chaque créneau de temps, un groupe de validateurs est désigné comme comité ; chaque membre constitue, depuis sa propre vue de la réserve de transactions, une liste d'inclusion qu'il diffuse sur le réseau. Le proposant du bloc suivant et tous les attestateurs collectent ces listes et les transmettent. Le producteur du bloc doit intégrer dans son bloc les transactions issues de toutes les listes collectées. Et les attestateurs ne votent pour le bloc que s'il l'a effectivement fait. Une demande devient ainsi une condition.

Pour vous, utilisateur, c'est la différence entre « ma transaction sera probablement reprise » et « ma transaction doit être reprise ». Pour les validateurs, la liste des tâches s'allonge, car le service de comité s'ajoute à l'exploitation courante. Quiconque a mis son ETH en staking auprès d'un prestataire devrait vérifier en amont comment celui-ci gère les nouvelles obligations de protocole ; les conditions actuelles des prestataires figurent dans notre comparatif du staking.

La Frame Transaction (EIP-8141) porte le volet confidentialité

La deuxième entrée dotée d'un état propre est l'EIP-8141, nommée « Frame Transaction », créée le 29 janvier 2026. La liste des auteurs est inhabituellement longue et comprend notamment Vitalik Buterin, Felix Lange, Yoav Weiss, Alex Forshtat, Dror Tirosh, Shahaf Nacson, Derek Chiang, Stavros Vlachakis et Toni Wahrstätter. Chez Hegotá, la proposition se situe au niveau « Considered for Inclusion » et y constitue actuellement la seule entrée.

Sur le fond, elle introduit un nouveau type de transaction dont le contrôle de validité et le paiement des frais sont librement définissables. La transaction se décompose pour cela en sections distinctes, appelées frames, qui prennent successivement en charge le contrôle, la libération des frais et l'exécution proprement dite. La spécification avance plusieurs motifs : une sortie du procédé à courbes elliptiques utilisé aujourd'hui vers des procédés qui résistent aussi aux ordinateurs quantiques ; le découplage d'un compte et de sa clé, qui rend possible un changement de clé au sein même du protocole ; des comptes à contrat intelligent plus simples et donc plus sûrs, dotés d'un traitement par lots intégré ; ainsi que des modèles de frais alternatifs, sans prestataire intermédiaire.

Le point relatif au changement de clé mérite votre attention si vous conservez vos avoirs vous-même. Aujourd'hui, un compte est indissociablement lié à une paire de clés ; si la clé est perdue ou tombe entre de mauvaises mains, l'adresse est brûlée. Un changement de clé ancré dans le protocole assouplirait cette logique. D'ici là, la conservation de la clé demeure le maillon décisif, et une solution matérielle reste pour cela la voie la plus solide ; ce qui distingue les appareils entre eux, et sur quels points, figure dans notre comparatif des portefeuilles matériels.

Ce que « confidentialité native » signifie réellement dans le document

Les articles parus le 16 août 2026 citent trois propositions censées permettre ensemble des applications de confidentialité sans intermédiaire : la Frame Transaction ainsi que l'EIP-8250 (« Keyed Nonces for Frame Transactions ») et l'EIP-8272 (« Recent Roots for Frame Transactions »). Cette indication remonte à une publication du développeur Toni Wahrstätter.

Dans le méta-document lui-même, la situation apparaît plus sobre. De ces trois propositions, une seule porte l'état « Considered for Inclusion » ; les deux autres figurent sous « Proposed for Inclusion » et n'ont donc subi aucun examen. Une quatrième entrée en lien direct avec le sujet, l'EIP-8182 « Private ETH and ERC-20 Transfers », ne figure elle aussi que parmi les propositions. Le paquet qui apparaît dans les titres comme une offensive en faveur de la confidentialité se compose, dans le document officiel, d'une entrée examinée et de trois entrées non examinées.

Cette distinction n'est pas une querelle de mots. C'est d'elle que dépend votre capacité à compter sur une fonction dans deux ans. Et elle se vérifie en trente secondes, puisque le document est public.

66 propositions dans les médias, 39 entrées dans le document

Reste la question de savoir d'où vient le chiffre de 66 lorsque le document comporte 39 entrées. Deux médias spécialisés en ont rendu compte le 16 août 2026, Cointelegraph et crypto.news, et tous deux renvoient à la même publication du développeur cité plus haut sur un réseau social. Nous n'avons pas pu consulter nous-mêmes cette publication et restituons donc ce chiffre expressément comme une indication de presse. Seules les valeurs issues du méta-document ont été vérifiées et comptées par nos soins.

La raison la plus probable de l'écart tient à ce qui est compté de part et d'autre. Le méta-document ne recense que ce que quelqu'un a formellement soumis. Dans les réunions de développeurs et sur le forum de discussion circulent en outre des propositions qui n'ont pas encore franchi ce pas. Les deux chiffres peuvent donc être exacts tout en mesurant des choses différentes. Pour vous, lecteur, il en découle une règle de contrôle simple : un chiffre privé du niveau qui lui correspond ne dit rien. Devant chaque annonce de mise à jour, demandez-vous d'abord combien de propositions sont fermement programmées, et ne lisez la suite qu'ensuite.

Glamsterdam comme référence : 19 EIP programmés et 41 refusés

L'ampleur de l'élagage final apparaît lorsque l'on regarde la mise à jour qui précède Hegotá. Le même décompte, appliqué au document Glamsterdam EIP-7773 le 16 août 2026, donne 19 propositions fermement programmées, sept autres entrées dans des catégories annexes consacrées aux protocoles réseau et aux analyses, ainsi que 41 propositions expressément refusées. Chez Glamsterdam, on a donc écarté davantage que retenu.

Parmi les propositions Glamsterdam fermement programmées figurent des modifications aux effets sensibles, par exemple l'EIP-7732 sur l'ancrage définitif de la séparation entre proposants et constructeurs de blocs, l'EIP-7928 sur les listes d'accès au niveau du bloc et l'EIP-7954, qui relève la taille admise d'un contrat intelligent. Ce qui sera réellement activé au bout du compte ne sera là encore établi qu'au moment de l'activation.

Un détail en marge est particulièrement instructif. Trois propositions refusées pour Glamsterdam réapparaissent dans le document Hegotá au rang de propositions : l'EIP-7668 sur la suppression des filtres de Bloom, l'EIP-7819 sur l'instruction SETDELEGATE et l'EIP-7979 sur de nouvelles instructions d'appel et de retour de la machine virtuelle. Cela est expressément prévu. L'EIP-7723 retient qu'un refus ne vaut jamais que pour une seule mise à jour et n'empêche pas une nouvelle tentative à la suivante. Un refus ne constitue donc aucun jugement définitif sur une idée, seulement une décision portant sur une échéance.

Le calendrier : Glamsterdam 2026, Hegotá 2027, sans date ferme

Sur les échéances, les documents se montrent remarquablement réservés, et c'est l'information la plus honnête de tout le processus. Les deux méta-EIP contiennent un tableau des dates d'activation pour les réseaux de test et pour le réseau principal. Dans les deux documents, toutes les cases de ce tableau sont vides. En dessous figure la mention selon laquelle les lignes seront remplies dès que les équipes de développement auront arrêté les dates.

Ce qui existe comme indications provient des articles de presse et de la feuille de route publique du projet : Glamsterdam devrait arriver sur le réseau principal au second semestre 2026, et les développeurs principaux visent l'année suivante pour Hegotá. Comme prochaine date de réunion de développeurs, Cointelegraph cite lundi, 14 h 00 UTC. Nous n'avons pas pu vérifier cette date à la source primaire et la présentons donc comme une indication de presse.

Pour vos projets, cela signifie qu'il n'existe actuellement aucune date sur laquelle vous pourriez vous appuyer, et que toute annonce en citant une devrait vous inciter à vérifier. La façon dont la discussion sur le cours de l'Ethereum a évolué indépendamment de tout cela fait l'objet d'une analyse distincte de notre rédaction ; le présent texte ne contient délibérément aucune affirmation sur les cours à venir.

Comment suivre vous-même la sélection d'une mise à jour Ethereum, sans attendre les titres

La bonne nouvelle, sur ce sujet, est que vous n'avez à vous fier à personne. Le document est public, court et vérifié en quelques minutes. Un passage se déroule ainsi :

1. Ouvrez l'EIP-8081 et ignorez d'abord le texte courant. Seuls comptent les intitulés de section et le nombre d'entrées qui figurent en dessous.
2. Comptez les entrées sous « Scheduled for Inclusion ». Ce chiffre est le noyau solide de toute annonce de mise à jour.
3. Regardez si quelque chose figure sous « Declined for Inclusion ». Si cette liste s'allonge, la sélection a commencé. Si elle reste vide, tout demeure ouvert.
4. Jetez un œil à l'EIP-7773 pour voir ce qui précède Hegotá dans le temps et dans quel état cela se trouve.
5. Vérifiez l'état d'avancement du document, en haut dans son en-tête. Un passage de « Draft » à « Review » signifie que la liste des propositions a été retirée et que l'affaire se précise.
6. Consultez le tableau d'activation. Tant que des cases y restent vides, aucune date arrêtée n'existe, quoi qu'il soit écrit ailleurs.

Qui a effectué ce passage deux fois n'a plus guère besoin de cinq minutes la troisième. Le gain est considérable : vous pouvez situer en peu de temps toute annonce concernant une future fonction Ethereum, au lieu d'avoir à la croire sur parole.

Les limites de ce décompte : ce à quoi le méta-document ne répond pas

Pour que vous sachiez jusqu'où portent les chiffres de ce texte, voici les réserves en clair. Le décompte est un instantané du 16 août 2026. Chaque modification acceptée du document déplace les valeurs, et en phase de sélection active cela se produit plusieurs fois par semaine.

Le document ne dit par ailleurs rien de l'avancement de la mise en œuvre dans les différents logiciels. Cette information se trouve dans les rapports des réseaux de test et dans les comptes rendus des réunions de développeurs, pas dans le méta-EIP. Il ne dit pas davantage laquelle des 37 propositions soumises a la moindre chance ; qui l'affirme interprète au lieu de rapporter.

Le chiffre de 66, comme exposé plus haut, n'a pas été vérifié par nos soins à sa source d'origine. Enfin, une mise à jour du réseau n'est pas un événement de cours. Ni le nombre de propositions ni leur état ne disent quoi que ce soit sur la valeur de l'ETH, et le présent article n'en tire expressément aucune attente.

Situer une mise à jour Ethereum : ce qu'il faut retenir

1. Comptez les propositions fermement programmées, non celles qui sont discutées. Chez Hegotá, ce chiffre s'établit aujourd'hui à un, chez Glamsterdam à 19. Tout ce qui va au-delà relève de l'intention et ne tranche rien. Si vous prenez l'évolution technique comme occasion de constituer ou de réorganiser vos avoirs, comparez auparavant les frais et les paires de négociation des prestataires dans notre comparatif des plateformes.
2. Avant chaque hard fork, vérifiez ce qu'en fait votre prestataire. Fenêtres de maintenance, retraits suspendus et délais de sortie modifiés vous touchent en pratique plus tôt que toute modification du protocole. Cela devient particulièrement pertinent si vous percevez des récompenses ; vous trouverez les conditions des prestataires dans le comparatif du staking.
3. Gardez la conservation entre vos mains. Tant qu'un changement de clé n'existe pas dans le protocole, tout tient à la mise en sécurité de votre clé. Ce qui distingue les appareils, et comment, figure dans le comparatif des portefeuilles matériels.

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