Réponse rapide : Immutable indique qu'il prévoit de faire passer Immutable Chain d'un fork personnalisé de Geth à un rollup Ethereum basé sur l'OP Stack aux alentours de la mi-2027. Le projet affirme que la chaîne conservera son état et son ID de chaîne, de sorte que les comptes, soldes, contrats et autorisations devraient être reportés sans intervention pour la quasi-totalité des utilisateurs. Les changements annoncés incluent une nouvelle conception du pont, des frais de transaction attendus plus élevés, et des retraits natifs vers Ethereum prenant environ sept jours. Il s'agit de plans arrêtés au 11 novembre 2026 ; une date de migration confirmée et des instructions finales destinées aux utilisateurs n'ont pas encore été publiées.
Qu'a annoncé Immutable ?
L'annonce technique d'Immutable datée du 6 novembre 2026 expose un changement du logiciel sous-jacent de la chaîne et de son architecture de règlement. Elle indique qu'Immutable Chain passera d'un fork personnalisé de Geth à une chaîne basée sur l'OP Stack. Le projet prévoit de conserver le même état et le même ID de chaîne, de réduire le temps de bloc de deux secondes à une seconde, et de s'appuyer sur Ethereum pour la disponibilité des données et le pontage fondé sur des preuves. L'objectif est la mi-2027, avec un préavis avant une brève période pendant laquelle la production de blocs sera suspendue.
Le calendrier compte. Il s'agit d'une feuille de route prospective, et non d'une mise à niveau que les utilisateurs peuvent vérifier comme étant déjà achevée aujourd'hui. Un portefeuille peut continuer à afficher la chaîne et le pont existants tant que le projet n'a pas annoncé de fenêtre de migration précise. Il convient d'éviter de suivre des liens tiers de « migration » demandant de déplacer immédiatement des actifs sur la seule base de cette annonce. La publication officielle indique que la quasi-totalité des utilisateurs et des développeurs n'ont aucune action à mener pour la transition elle-même.
L'annonce concerne Immutable Chain, qui est une infrastructure utilisée par les jeux et les applications. Elle n'affirme pas que chaque actif de jeu, chaque inscription de marketplace ou chaque méthode de dépôt sur une plateforme se comportera de manière identique pendant la migration. Ces services en aval pourraient publier leurs propres avis opérationnels une fois la date fixée.
Que signifie « même état et même ID de chaîne » pour un portefeuille ?
L'état comprend les soldes des comptes de la chaîne et le stockage des contrats à un instant donné. Conserver l'état signifie que la migration est conçue pour poursuivre ces registres sur la chaîne mise à niveau. Conserver l'ID de chaîne signifie que l'identifiant réseau utilisé par les portefeuilles et les applications devrait rester le même. Immutable indique que les comptes, soldes, contrats et autorisations seront reportés sans modification. C'est le fondement de son affirmation selon laquelle la quasi-totalité des utilisateurs n'ont aucune action à entreprendre.
Cela diffère d'un échange de jetons demandant aux détenteurs de convertir un actif en un autre via une page de réclamation. La publication officielle ne décrit ni un remboursement massif de jetons, ni une obligation d'envoyer de l'IMX vers une nouvelle adresse. Elle ne promet pas non plus que toutes les interfaces de portefeuille se mettront à jour à la minute exacte. Un utilisateur peut rencontrer une application obsolète, une erreur RPC ou un indexeur en retard pendant la transition, même si les soldes sous-jacents sont correctement reportés.
Pour un utilisateur, l'étape pratique consiste à noter son adresse de portefeuille actuelle et tout identifiant de transaction important avant la panne annoncée, puis d'attendre les mises à jour officielles de statut. Cela aide à distinguer un problème d'affichage d'un véritable écart d'état. Cela ne nécessite jamais de partager une phrase de récupération ni de signer une transaction non sollicitée. Tout message affirmant que la mise à niveau exige ces actions doit être considéré comme non vérifié tant qu'il n'est pas confirmé par les canaux officiels d'Immutable.
Pourquoi migrer vers l'OP Stack ?
Immutable indique que ce changement ferait de la chaîne un rollup Ethereum et lui permettrait d'adopter plus facilement les mises à niveau courantes de l'écosystème et les correctifs de sécurité. Le projet décrit également un pont dont les retraits peuvent être vérifiés par rapport aux engagements d'état publiés sur Ethereum. La justification avancée porte sur la maintenabilité et la relation entre la chaîne et Ethereum ; cela ne prouve pas que chaque application deviendra moins chère ou plus rapide pour ses utilisateurs.
Le temps de bloc est l'un des changements mesurables du plan : de deux secondes à une seconde. Une cadence de blocs d'une seconde peut mettre à jour l'état onchain plus fréquemment, mais l'expérience de bout en bout d'un utilisateur dépend aussi du portefeuille, du serveur de jeu, du fournisseur RPC, de la marketplace et du pont. Un bloc plus rapide ne rend pas un retrait vers Ethereum définitif en une seconde. Le pont dispose d'un processus de vérification distinct, et le projet s'attend à ce que le délai de retrait natif s'allonge.
L'annonce indique qu'elle débutera avec des fault proofs permissionnés avant d'introduire ultérieurement des validity proofs. Ces étapes décrivent une trajectoire technique prévue. Un article ne doit pas présenter le futur système de preuves comme déjà déployé sur Immutable Chain. Les utilisateurs et les développeurs devraient réexaminer l'architecture lorsque le projet publiera la documentation de migration et que le nouveau pont sera opérationnel.
Quels changements pour les retraits et les ponts ?
Le changement le plus directement visible pour l'utilisateur dans l'annonce concerne le délai des retraits natifs. Immutable estime qu'un retrait via la nouvelle route native du rollup prendra environ sept jours. C'est nettement plus long que l'expérience que beaucoup d'utilisateurs associent au pont actuel, et cela compte pour toute personne ayant besoin de fonds sur Ethereum à une date donnée. Une estimation de sept jours n'est pas une garantie d'un délai d'exécution précis, surtout lors d'un lancement ou d'une perturbation du réseau.
Immutable note que des ponts de liquidité plus rapides pourraient continuer à traiter une grande partie du volume de pontage. Ces services peuvent offrir une route différente, mais ils peuvent introduire des frais supplémentaires, des limites de liquidité et un risque lié au fournisseur. Un pont rapide et un retrait natif ne sont pas interchangeables en matière de modèle de sécurité ou de coût. Avant de choisir un pont, identifiez qui fournit la liquidité, comment le transfert est réalisé, ce qui se passe si le fournisseur fait une pause, et quel est l'actif final à destination.
Le projet indique également que les frais de transaction augmenteront légèrement. Aucun barème de frais stable et spécifique aux utilisateurs n'a été publié dans l'annonce. Un jeu avec des transactions sponsorisées pourrait absorber un frais qu'une autre application refacture à l'utilisateur. Un utilisateur à volume élevé ressentira peut-être davantage une petite variation du coût unitaire qu'un joueur occasionnel. La comparaison pertinente devra utiliser le gas réel et les frais d'application après la migration, une fois disponibles, et non une affirmation générale selon laquelle la nouvelle stack serait moins chère ou plus chère pour chaque activité.
Que doivent vérifier les développeurs de jeux et les fournisseurs d'infrastructure ?
Immutable indique que la plupart des développeurs n'ont aucune action à mener car les contrats et l'état sont reportés. Néanmoins, une application devrait auditer ses dépendances avant une pause programmée de la chaîne. Les points de terminaison RPC, les indexeurs, les API de pont, les écouteurs d'événements, les hypothèses de confirmation et la messagerie de retrait peuvent être sensibles au changement même si les contrats intelligents eux-mêmes restent déployés. Les développeurs devraient lire la documentation de migration liée du projet destinée aux applications et aux fournisseurs d'infrastructure, puis effectuer des tests dans l'environnement disponible.
Un jeu qui crédite un joueur après un dépôt devrait définir quel événement compte comme définitif selon sa propre tolérance au risque. Une marketplace devrait vérifier si l'affichage des soldes, l'état des inscriptions et le flux de paiement restent synchronisés après la panne. Un indexeur peut devoir gérer la pause et la reprise sans dupliquer les événements. Ce sont des questions d'implémentation, et non des preuves que la migration annoncée échouera ; ce sont les vérifications nécessaires pour rendre effective la continuité voulue dans une application de production.
La publication officielle indique également que le testnet public actuel d'Immutable destiné aux jeux devrait être déprécié d'ici la fin de l'année 2026. Ce calendrier est distinct de l'objectif de migration du mainnet. Les équipes utilisant le testnet devraient consulter les directives actuelles du projet destinées aux développeurs, plutôt que de supposer que la date du mainnet en 2027 est leur seule échéance.
Comment les utilisateurs peuvent-ils se préparer sans agir trop tôt ?
La première action utile relève de l'hygiène de l'information. Mettez en favori l'annonce officielle d'Immutable et ses canaux de statut, et distinguez une date confirmée d'un objectif de planification. Un avis fournissant un numéro de bloc, une fenêtre de maintenance et des instructions de pont est plus exploitable qu'un post sur les réseaux sociaux répétant « migration 2027 ».
Deuxièmement, examinez les activités en cours à l'approche de la fenêtre. Si un joueur doit retirer vers Ethereum pour un paiement daté, il devrait tenir compte du changement de pont annoncé et de toute interruption bien avant l'échéance. Si un jeu organise un événement sensible au temps, son exploitant devrait publier son propre plan concernant les dépôts, les retraits et les transactions en jeu pendant la panne.
Troisièmement, évitez les transactions de migration spéculatives. Puisque Immutable indique que les soldes et les autorisations seront reportés, une demande d'envoyer des actifs vers un contrat inconnu est incohérente avec les recommandations actuelles destinées aux utilisateurs. Une nouvelle instruction officielle pourrait apparaître plus tard, mais elle devrait être vérifiée auprès du projet et de l'application concernée. Ne vous fiez jamais uniquement à un message direct ou à une annonce payante sur un moteur de recherche pour une demande de signature de portefeuille.
Quatrièmement, vérifiez les autorisations après la transition. « Les autorisations sont reportées » signifie que les permissions précédemment accordées devraient rester en place. C'est utile pour la continuité des applications, mais cela signifie aussi que les anciennes permissions ne disparaissent pas simplement parce que le logiciel de la chaîne change. Examiner les allowances actives et révoquer celles qui ne sont plus nécessaires est une tâche distincte d'entretien du portefeuille.
FAQ
Les détenteurs d'IMX doivent-ils échanger leurs jetons maintenant ?
L'annonce officielle décrit la continuité de l'état et des soldes et indique que la quasi-totalité des utilisateurs n'ont aucune action à mener. Elle n'instruit pas les détenteurs d'effectuer un échange de jetons maintenant. Toute instruction future spécifique à une application devrait être vérifiée par rapport aux avis officiels.
La chaîne aura-t-elle un nouvel ID de chaîne ?
Immutable indique que la migration conservera le même ID de chaîne. Un fournisseur de portefeuille peut néanmoins mettre à jour sa configuration technique, mais le plan déclaré du projet ne prévoit pas de nouvel identifiant réseau.
Chaque retrait prendra-t-il sept jours ?
L'estimation d'Immutable concerne les retraits natifs via le futur pont de rollup prévu. Des ponts de liquidité plus rapides pourraient proposer des alternatives avec des frais et des risques différents. Les conditions exactes dépendront de la route disponible après la migration.
La date de la mi-2027 est-elle confirmée ?
Non. Le projet décrit la mi-2027 comme son objectif et indique qu'il fournira un préavis une fois la date confirmée. Un article publié actuellement doit la considérer comme un objectif, et non comme une fenêtre de maintenance réservée.
