# Le moment ERC-4804 *Author: Bankless* *Published: Jan 8, 2026* *Source: https://www.bankless.com/fr/read/the-erc-4804-moment* --- [![](https://bankless.ghost.io/content/images/2026/01/Group-681--1-.png)](https://www.bankless.com/sponsor/the-defi-report-1767388444?ref=read/erc-4804-shield-broken-nfts&email=true) Le moment ERC-4804 Publié le 8 janvier 2026 [ Afficher dans le navigateur ](https://www.bankless.com/metaversal) --- [**Sponsor : The DeFi Report**](https://www.bankless.com/sponsor/the-defi-report-1767388444?ref=read/erc-4804-shield-broken-nfts&email=true) — Une étude cryptographique de premier plan, reconnue par les professionnels de la finance. [](https://bankless.ghost.io/ghost/#/editor/post/69580059dbc84d000120d568)[](https://www.bankless.com/portal/content/posts/view?id=8502) [](javascript:;) [En savoir plus](https://www.bankless.com/sponsor/the-defi-report-1767388444?ref=read/erc-4804-shield-broken-nfts&email=true) . . . INTRODUCTION ERC-4804 : un nouveau bouclier contre les NFT défectueux Bankless Auteur : [ ](https://x.com/wmpeaster) [ William Peaster ](https://x.com/wmpeaster) [![](https://bankless.ghost.io/content/images/2026/01/image---2026-01-07T221351.865-1.png)](https://www.bankless.com/read/erc-4804-shield-broken-nfts)En ce qui concerne les métadonnées NFT, les fantômes du passé continueront de nous hanter. Bien sûr, il existe différentes façons de soutenir les médias des NFT. Pour des raisons de durabilité, j'ai toujours été attiré par les projets onchain, qui se déclinent en plusieurs variantes, telles que : - **Semi-onchain** — c'est-à-dire lorsque *certaines métadonnées *sont stockées sur la chaîne, mais pas toutes - **Haché sur la chaîne** — c'est-à-dire lorsque les contrats NFT hébergent un hachage cryptographique qui fait référence de manière permanente à des données hors chaîne - **Hybride sur la chaîne** — c'est-à-dire lorsqu'un projet déploie une collection distincte sur la chaîne pour archiver une collection hors chaîne antérieure - **Entièrement sur la chaîne** — c'est-à-dire lorsque toutes les données nécessaires à l'affichage d'un NFT se trouvent dans le contrat intelligent de la collection - **Inchain** — c'est-à-dire lorsque les visuels NFT sont générés en direct par un code entièrement onchain au moment du rendu plutôt que stockés sous forme de fichiers Naturellement, chacune des méthodes ci-dessus présente des avantages et des inconvénients. Cependant, d'une manière générale, le stockage sur la chaîne est plus coûteux que le stockage hors chaîne et nécessite une plus grande expertise en matière de contrats intelligents. Ainsi, le stockage hors chaîne, où *seuls *les jetons *NFT *sont stockés sur la chaîne tandis que leurs métadonnées sont hébergées sur des plateformes externes telles que l'IPFS ou des serveurs privés, est la norme pour la plupart des collections NFT apparues au cours des cinq dernières années. Le problème ici est que l'épinglage IPFS s'estompe souvent avec le temps, et que de nombreuses start-ups font faillite et ferment leurs serveurs privés. Dans ces cas-là, seuls les jetons restent comme des vestiges sans valeur qui ne peuvent plus afficher leurs images. Je pourrais citer de nombreux exemples de NFT perdus ces dernières années, mais vous pouvez le constater par vous-même. Par exemple, la nouvelle [application NFTimeless](https://app.nftimeless.com/) permet aux utilisateurs non invités d'obtenir un rapport sur l'état de leurs collections NFT. Elle indique quels NFT sont hors chaîne et désormais inutilisables. [![](https://bankless.ghost.io/content/images/2026/01/G9bVumKXsAAO5sc--1-.jpg)](https://x.com/G4SP4RD/status/2006031261974831578)*via [G4SP4RD](https://x.com/G4SP4RD/status/2006031261974831578)* Pour les collections qui sont *déjà cassées *, il n'y a rien à faire. Mais heureusement, pour les projets avec un stockage hors chaîne qui n'ont pas encore été perdus, il existe une technique émergente pour une durabilité rétroactive qui ne nécessite pas le déploiement d'une deuxième collection : [ERC-4804](https://eips.ethereum.org/EIPS/eip-4804). Cette norme s'apparente à un système de type HTTP pour Ethereum, dans la mesure où elle introduit un nouveau type d'URI `web3://` qui permet de récupérer directement les métadonnées NFT à partir de contrats intelligents. L'URI ne pointe pas hors chaîne, mais décrit plutôt une lecture sur chaîne. En d'autres termes, lorsqu'une place de marché NFT voit un URI `web3://`, elle peut traduire le lien ENS fourni en un `eth_call`, l'exécuter sur un contrat intelligent et traiter les données renvoyées comme des métadonnées NFT. Par exemple, imaginez un contrat NFT dont `le tokenURI(123)` renvoie `web3://testcollection.eth/tokenURI/123`... voici ce qui se passe en arrière-plan : - Une place de marché résout `testcollection.eth` via ENS en une adresse Ethereum - Elle appelle `tokenURI(uint256)` sur ce contrat avec l'argument `123` - Le contrat renvoie des métadonnées JSON (par exemple, nom, description, image, attributs) - Enfin, la place de marché affiche le NFT à l'aide de ces données, comme elle le ferait avec IPFS, mais sans aucune dépendance hors chaîne Cela dit, cette approche signifie que les métadonnées peuvent être générées ou stockées entièrement sur la chaîne, soit dans le même contrat NFT, soit dans un contrat de résolution de métadonnées distinct. Le schéma `web3://` rend les appels vérifiables et indépendants de toute passerelle restant en ligne. Il s'agit d'une fonctionnalité puissante. Mais pourquoi ? Parce qu'il s'agit d'un moyen simple pour les anciennes collections NFT de conserver leurs contrats de jetons d'origine intacts, de déployer de nouveaux contrats de métadonnées sur la chaîne et de mettre à jour leurs baseURI pour pointer vers le lien `web3://` ENS pertinent. Il s'agit essentiellement d'un nouveau système de pointeurs, qui ne nécessite donc aucune migration NFT. En conséquence, après toute mise à jour, les places de marché récupéreraient les métadonnées directement depuis Ethereum lui-même, et grâce à l'URI, n'importe qui pourrait reproduire les appels nécessaires à cet effet pour toujours. Cette norme *est également importante *car même les projets qui *stockent* leurs œuvres d'art et leurs métadonnées sur la chaîne ont [toujours été contraints](https://x.com/MichaelHirsch/status/1988314722710790148) de publier des baseURI `ipfs://` ou `https://`, car les applications et les portefeuilles ne savaient pas lire autre chose. Aujourd'hui, cependant, ces projets disposent d'une alternative viable sur la chaîne. Un autre élément important à noter ici est qu'OpenSea vient d'ajouter [la prise en charge de l'ERC-4804](https://docs.opensea.io/docs/metadata-standards#erc-4804-web3-uri-support). Il s'agit d'une validation importante pour la norme et d'une indication qu'elle peut gagner en popularité à partir de là. Je sais que la plateforme de frappe [Carve](https://x.com/0xCarve/status/2009081155254178289) prévoit déjà d'ajouter cette prise en charge, et d'autres intégrations suivront. Ainsi, lorsque nous envisageons les possibilités de la nouvelle année, l'un des aspects que je vais suivre est l'adoption de l'ERC-4804. Il pourrait rapidement devenir l'un des outils les plus importants que nous ayons vus jusqu'à présent pour la durabilité des NFT dans l'écosystème Ethereum. [Ajouter aux favoris sur Bankless.com](https://www.bankless.com/read/erc-4804-shield-broken-nfts)