Trois jours après le reveal, votre jeton affiche encore une image d’attente. Une collection que vous détenez montre soudain des traits différents de ceux de la semaine dernière. Ni l’un ni l’autre ne concerne le jeton lui-même. Les deux concernent une seule chaîne de caractères détenue par le contrat et ce qui se trouve à son autre extrémité ; figé et rafraîchir sont les deux mots qui disent ce qui peut et ne peut pas arriver à cette chaîne.
Ce que le jeton retient et ce qu’il ne retient pas
Un NFT est un identifiant qu’un contrat intelligent inscrit au nom d’une adresse détentrice. Le nom, la description et l’image ne figurent pas dans cet enregistrement.
C’est le standard de jetons ERC-721 qui les range derrière une seule fonction. Pour un identifiant de jeton donné, tokenURI renvoie un Uniform Resource Identifier, et la spécification ajoute que cette URI peut pointer vers un fichier JSON conforme au ERC721 Metadata JSON Schema.
Ce schéma tient en trois propriétés : name désigne l’actif que représente le NFT, description le décrit, et image est une URI pointant vers une ressource dont le type MIME est une image. L’image est donc un second saut : le contrat pointe vers un document, et le document pointe vers un fichier.
Au-delà de l’identifiant et du détenteur, tout ce qu’une application vous montre est lu dans ce document et non dans la chaîne. La partie que tout le monde regarde est justement celle que la chaîne ne conserve pas.
Ce vers quoi mène le pointeur décide de ce qui peut changer
Une URI de jeton est une chaîne de caractères, et cette chaîne peut être plusieurs choses différentes. Elle peut être une adresse web sur un serveur exploité par quelqu’un. Elle peut être une adresse IPFS bâtie autour d’un identifiant de contenu. Elle peut porter le document entier en elle, si bien qu’il n’y a rien à récupérer.
La distinction compte à cause de ce que chacune peut devenir. Une adresse web nomme un emplacement, pas un contenu : celui qui exploite le serveur peut renvoyer demain d’autres octets à la même adresse, et rien ne change sur la chaîne pour autant. Un identifiant de contenu se comporte autrement. La documentation IPFS indique que les CID reposent sur le hachage cryptographique du contenu et que toute différence dans le contenu produit un CID différent. Un CID ne peut donc pas résoudre vers un contenu modifié, puisque le contenu modifié est un autre CID et réclame un autre pointeur.
Un document embarqué va un cran plus loin, car il ne reste aucune récupération à intercepter. Il coûte de la taille, puisque chacun de ses octets occupe le stockage du contrat.
| Vers quoi pointe l’URI de jeton | Le bout de la chaîne peut-il servir un autre contenu plus tard | Ce qui doit changer pour que l’image change |
|---|---|---|
| Une adresse web sur le serveur d’un tiers | Oui | Rien sur la chaîne |
| Un identifiant de contenu IPFS | Non | Le contrat doit renvoyer une autre URI |
| Le document encodé dans l’URI elle-même | Non | Le contrat doit renvoyer une autre URI |
Ce que figé veut vraiment dire pour des métadonnées
Figé est une affirmation sur deux verrous, et elle ne tient que si les deux sont fermés. Le premier est au bout de la chaîne : le contenu derrière le pointeur ne peut pas être remplacé par un autre. Le second est sur le pointeur lui-même : on ne peut pas amener le contrat à rendre une autre URI.
Une collection peut placer chaque fichier sur IPFS, publier les identifiants de contenu et conserver malgré tout une fonction permettant au déployeur de fixer une nouvelle base URI. L’adressage par contenu ferme le premier verrou et laisse le second ouvert. Une collection de 10 000 jetons peut être servie depuis une seule base URI, et une seule transaction du propriétaire change alors ce vers quoi résout chaque identifiant qu’elle contient.
Figé se lit donc comme les privilèges du propriétaire sur n’importe quel autre contrat. La question n’est pas ce que le contrat fait aujourd’hui, mais ce que le détenteur de la clé de propriétaire peut encore lui faire faire.
Pourquoi ce que vous voyez est une copie en cache
Les places de marché et les portefeuilles n’appellent pas tokenURI et ne récupèrent pas un document à chaque défilement. Ils le lisent une fois, gardent leur propre copie du JSON, téléchargent l’image et vous servent cette copie, car rendre une galerie autrement voudrait dire une requête externe par vignette vers des serveurs que le site ne contrôle pas.
Il y a donc trois copies de la réponse, et elles peuvent diverger : ce que le contrat renvoie maintenant, ce que le document à cette URI dit maintenant, et ce que l’indexeur a noté la dernière fois qu’il a regardé. Un affichage erroné est une affirmation sur la troisième copie, pas une preuve que les deux premières sont fausses.
ERC-4906 existe précisément à cause de cet écart. Intitulé EIP-721 Metadata Update Extension, il ajoute un événement MetadataUpdate afin que, selon ses propres termes, les plateformes tierces comme les places de marché NFT puissent mettre à jour à temps les images et les attributs associés du NFT ; un événement BatchMetadataUpdate couvre une plage d’identifiants en une seule émission. La motivation annoncée est que les contrats émettaient déjà leurs propres événements pour cela et que bâtir une solution particulière pour chaque collection représentait un effort supplémentaire pour les plateformes qui les lisent.
Ce que fait vraiment un rafraîchissement
Un rafraîchissement est une instruction à l’indexeur, pas à la chaîne. Il dit à la plateforme de jeter ce qu’elle a noté et de refaire toute la lecture : appeler tokenURI, récupérer ce qui revient, l’analyser et retélécharger le fichier nommé dans le champ image. Rien n’est signé, aucun frais n’est payé, et le contrat n’est pas touché.
C’est pourquoi un rafraîchissement n’aide que dans une seule situation : la copie stockée est en retard sur la réponse actuelle. Si le contrat renvoie désormais une nouvelle URI, ou si le document à l’ancienne URI contient désormais d’autres octets, le rafraîchissement remet l’affichage en accord. Si ni l’un ni l’autre n’est vrai, il remplace la copie stockée par une copie identique.
Un rafraîchissement est la version manuelle de ce qu’automatise ERC-4906 : lorsqu’une collection émet l’événement de mise à jour, un indexeur qui le guette refait la lecture sans qu’on le lui demande.
Quand un rafraîchissement ne sert à rien
La question utile n’est pas s’il faut rafraîchir, mais à quelle panne vous avez affaire, car des pannes sans lien entre elles se présentent de la même façon : l’image est fausse, ou l’image manque.
| Ce que vous voyez | Ce qui se passe en dessous | Un rafraîchissement y change-t-il quelque chose |
|---|---|---|
| Image d’attente après le reveal | Le contrat renvoie encore l’URI d’avant le reveal | Non, tant que le contrat ne renvoie pas la nouvelle |
| Image cassée, le document se charge encore | L’URI de l’image est morte ou injoignable | Non, la réparation est chez l’hébergeur |
| Rien ne se charge du tout | Le document de métadonnées lui-même est injoignable | Non |
| Les traits diffèrent du document | La copie stockée est périmée | Oui |
| Bonne image, mauvaise page de collection | Vous regardez un autre contrat | Non |
Les lignes à pointeur mort sont justement celles qu’on lit comme un bug de la plateforme. Si l’URI de jeton est une adresse web, le serveur derrière peut être éteint, et le pointeur continue de pointer vers rien. Si c’est un identifiant de contenu, le même résultat arrive par une autre route : la documentation IPFS indique que, si IPFS garantit que tout contenu du réseau est découvrable, il ne garantit pas qu’un contenu reste disponible durablement, et que les données peuvent être épinglées sur un ou plusieurs nœuds IPFS afin de ne pas être supprimées lors du ramasse-miettes. Un CID que plus aucun nœud ne détient est un nom valide et permanent pour rien.
Ce qu’il faut vérifier avant de demander un rafraîchissement
Trois lectures séparent ces cas, et aucune n’exige que la place de marché fonctionne.
Lisez d’abord le contrat. Dans un explorateur de blocs, ouvrez le contrat de la collection et appelez tokenURI avec votre identifiant de jeton. La chaîne qui revient est la réponse de la chaîne de blocs, et la seule des trois copies qu’elle atteste.
Ouvrez ensuite ce qu’il a renvoyé. Récupérez cette URI et lisez le JSON. Si name, description et image contiennent ce que vous attendez, le côté chaîne est correct et le problème se situe en aval. Si l’URI ne se charge pas, aucun rafraîchissement ne fera surgir un document qui n’existe pas.
Suivez ensuite le champ image, car un document peut être intact alors que le fichier qu’il nomme a disparu, et sur un hébergeur différent de celui qui sert les métadonnées. Quand les trois lectures sont correctes et que la place de marché montre encore autre chose, c’est le cas du rafraîchissement, et c’est le seul.
En résumé
Les métadonnées sont un document vers lequel la chaîne pointe, pas une chose que la chaîne conserve. Figé signifie que les deux verrous sont fermés : le bout de la chaîne ne peut pas servir un autre contenu, et on ne peut pas amener le contrat à pointer ailleurs. Un verrou sans l’autre n’est pas un gel, et l’adressage par contenu à lui seul ne ferme que le premier.
Un rafraîchissement ne touche à rien de tout cela. Il relit le pointeur et le document et écrase une copie en cache, il répare donc exactement une panne : un affichage resté en arrière. Lisez tokenURI, ouvrez ce qu’il renvoie, suivez le champ image. Ces trois lectures séparent un indexeur qui doit regarder à nouveau d’un pointeur au bout duquel il n’y a plus rien. Pour continuer à apprendre les fondamentaux, retrouvez d’autres articles de Bitbase Academy.
Articles associés
Autres articles Bitbase sur ce sujet :
- Propriété fractionnée d’un jeton non fongible et où se situe le risque
- La frappe a réussi mais le NFT n’apparaît pas dans le portefeuille
- Le processus de révélation d’un NFT : ce qui change et quand
- Les redevances optionnelles des NFT expliquées
- Croisements de moyennes mobiles : croix dorée et croix de la mort
Avertissement : Cet article est un contenu pédagogique de Bitbase Academy, fourni à titre d'information uniquement. Il ne constitue pas un conseil en investissement, en trading, en fiscalité ou en finance. Les cryptoactifs sont volatils ; évaluez votre propre risque. Rédigé en septembre 2026 ; référez-vous aux informations officielles les plus récentes.
Sources
[1] Ethereum Improvement Proposals, ERC-721: Non-Fungible Token Standard eips.ethereum.org
[2] Ethereum Improvement Proposals, ERC-4906: EIP-721 Metadata Update Extension eips.ethereum.org
[3] Documentation IPFS, Content Identifiers (CIDs) docs.ipfs.tech
[4] Documentation IPFS, Persistence, permanence, and pinning docs.ipfs.tech
