---
title: "ERC-721"
description: "ERC-721 est l’interface standard d’Ethereum pour les jetons non fongibles (NFT) : chaque jeton est identifié séparément et un contrat intelligent enregistre ses règles de propriété et de transfert."
image: "https://wiki.fcontext.com/og.png"
---
> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.
# ERC-721
> À des fins éducatives uniquement ; ne constitue ni un conseil en investissement ni une recommandation d’investissement. Les investissements peuvent entraîner des pertes.
## Réponse directe
ERC-721 est l’interface standard d’Ethereum pour les jetons non fongibles. Plutôt que d’enregistrer un solde interchangeable, un contrat ERC-721 suit chaque jeton avec `tokenId`, expose son propriétaire et définit les modalités de transfert ou d’autorisation. Le jeton est identifié par le couple adresse du contrat et `tokenId` ; la norme ne détermine pas à elle seule le prix, l’authenticité, la rareté ou les droits juridiques de l’actif.
ERC-721 diffère d’ERC-20 parce que les unités ERC-20 sont fongibles : une unité est censée être interchangeable avec une autre. Des jetons ERC-721 peuvent appartenir à la même collection tout en ayant des identifiants et des métadonnées différents. Un portefeuille ou une place de marché peut prendre en charge les deux normes, mais les appels de transfert et d’approbation diffèrent.
La question pratique n’est pas de savoir si un projet revendique « ERC-721 », mais ce que font réellement son contrat et les systèmes qui l’entourent. Avant de considérer un NFT comme un actif, vérifiez l’implémentation, les permissions, les métadonnées, l’autorisation de la place de marché, la liquidité et les droits promis aux détenteurs.
## Fonctionnement
### Identité et propriété
Le contrat enregistre un propriétaire pour chaque `tokenId` existant. `ownerOf` renvoie cette adresse et `balanceOf` compte les jetons détenus par une adresse. Le mint crée généralement un nouvel identifiant et émet un événement `Transfer` depuis l’adresse zéro ; le burn émet souvent un transfert vers l’adresse zéro. Les événements facilitent l’indexation, mais l’état du contrat fait foi.
### Transferts et approbations
Le propriétaire peut appeler directement `transferFrom` ou autoriser une adresse pour un jeton avec `approve`. `setApprovalForAll` autorise un opérateur pour tous les jetons que le propriétaire détient dans cette collection. C’est pratique pour les places de marché, mais la permission est large. Vérifiez l’opérateur par son adresse de contrat et révoquez on-chain les approbations devenues inutiles. Une offre signée est distincte d’une approbation on-chain : annuler l’une ne supprime pas nécessairement l’autre.
`safeTransferFrom` vérifie aussi qu’un destinataire contractuel implémente `IERC721Receiver`. Cela aide à éviter l’envoi d’un jeton à un contrat incapable de le recevoir ; `transferFrom` n’exécute pas ce callback. Aucune des deux fonctions ne garantit qu’une place de marché, un pont ou un portefeuille traitera correctement le jeton.
### Métadonnées et redevances
L’extension facultative de métadonnées expose `tokenURI`, qui peut pointer vers des données stockées on-chain ou ailleurs. Une URI de base modifiable, un contrat upgradeable, un administrateur ou un hébergeur centralisé peut changer l’affichage après le mint. Le stockage permanent ou décentralisé réduit certaines dépendances, mais ne prouve ni l’auteur, ni la provenance, ni la propriété intellectuelle.
ERC-721 n’oblige pas les marchés secondaires à payer des redevances au créateur. Une collection peut implémenter l’interface facultative `EIP-2981`, mais la place de marché choisit de la respecter et cette interface ne règle ni ne force le paiement. Les plafonds d’offre, le hasard, l’authenticité des œuvres, les licences de marque et les autres promesses doivent être vérifiés séparément dans le code, les règles de distribution et les documents juridiques.
## Exemple
Supposons qu’un contrat mint le jeton `#42` pour Alice. Le jeton n’est pas identifié mondialement par `42` seul : l’adresse du contrat de la collection fait aussi partie de son identité. Alice peut le proposer en accordant `approve` pour ce jeton ou `setApprovalForAll` à l’opérateur de la place de marché. Lors de la vente, la place de marché appelle une fonction de transfert et le contrat vérifie propriété et autorisation. Alice devrait ensuite révoquer l’approbation de toute la collection si elle n’en a plus besoin.
L’image affichée par la place de marché est une question de métadonnées distincte. Alice doit examiner le comportement de `tokenURI`, les permissions de mise à jour, l’hébergement et la licence, plutôt que de supposer que la possession du jeton transfère les droits d’auteur ou d’usage commercial.
## Risques
- Risque du contrat : un bug, une mise à niveau malveillante, un administrateur privilégié ou un hook de transfert incorrect peut bloquer ou déplacer des jetons.
- Risque d’autorisation : un `setApprovalForAll` pour toute la collection ou une place de marché compromise peut déplacer tous les jetons approuvés de cette collection.
- Risque lié aux métadonnées et au droit : les fichiers hors chaîne peuvent disparaître ou changer, et la propriété du jeton n’accorde pas automatiquement les droits d’auteur, de marque ou autres droits juridiques.
- Risque de marché : les prix des NFT peuvent être volatils, la liquidité faible, et le prix plancher affiché peut être inexécutable pour un jeton donné.
Les opérations on-chain sont généralement irréversibles. Avant de signer, vérifiez le contrat de la collection, l’adresse destinataire, les approbations, les contrôles de métadonnées et les détails de la transaction ; considérez les affirmations des promoteurs ou communautés comme des déclarations à vérifier, pas comme des garanties.
## Idées reçues
### Mythe 1 : ERC-721 garantit la rareté
La norme distingue seulement les jetons d’un même contrat. L’émetteur peut en minter davantage, déployer des collections similaires ou faire pointer plusieurs identifiants vers des médias équivalents. La rareté dépend des règles d’offre et des permissions qui les font respecter.
### Mythe 2 : Le NFT comprend tous les droits de propriété intellectuelle
La blockchain enregistre un transfert de jeton. Le droit d’auteur, la reproduction, l’usage commercial, l’adaptation et la marque dépendent de la licence de la collection et du droit applicable ; ils ne se déduisent pas de `ownerOf`.
### Mythe 3 : Annuler une annonce supprime toutes les autorisations
L’annonce, sa signature et son expiration, ainsi qu’un `approve` ou `setApprovalForAll` on-chain, sont des états distincts. Vérifiez et révoquez séparément l’autorisation on-chain lorsqu’elle n’est plus nécessaire.
## Sujets connexes
- [Accumulateur cryptographique](/fr/crypto/cryptographic-accumulator/)
- [ERC-20](/fr/crypto/erc20/)
- [NFT](/fr/crypto/nft/)
- [Phrase mnémotechnique](/fr/crypto/seed-phrase/)
- [Norme de jeton](/fr/crypto/token-standard/)
## Sources
- [ERC-721: Non-Fungible Token Standard](https://eips.ethereum.org/EIPS/eip-721) - Ethereum Improvement Proposals (consulté le : 2026-08-20)
- [ERC-721 Non-Fungible Token Standard](https://ethereum.org/en/developers/docs/standards/tokens/erc-721/) - Ethereum.org (consulté le : 2026-08-20)
- [ERC-2981: NFT Royalty Standard](https://eips.ethereum.org/EIPS/eip-2981) - Ethereum Improvement Proposals (consulté le : 2026-08-20)
- [Soyez prudent lors de l’achat de monnaies ou de jetons numériques](https://www.cftc.gov/LearnAndProtect/AdvisoriesAndArticles/caution_of_digital_currencies.html) - CFTC (consulté le : 2026-08-20)
Source: https://wiki.fcontext.com/fr/crypto/erc721/index.mdx