Les contrats intelligents de marketplace NFT gèrent les annonces, les offres, les enchères, le règlement, l’annulation, l’acheminement des frais, les royalties et les contrôles administratifs. Même si les standards ERC-721 ou ERC-1155 décrivent l’actif lui-même, le simple respect d’un standard de jeton ne crée pas automatiquement une marketplace sécurisée.

Les développeurs devraient comparer les contrats de marketplace avec le comportement des frais et des ordres dans la revue de la marketplace OpenSea, les couches opérationnelles du guide d’infrastructure de marketplace NFT et les déclencheurs de paiement dans les modèles de revenus passifs NFT, car les événements du contrat servent de données source pour le règlement et les flux de support.

Explication des contrats intelligents NFT

Un contrat intelligent NFT est un code déployé sur une blockchain qui crée des jetons et régit la manière dont la propriété est enregistrée et transférée. Lors du mint, le contrat attribue un token ID à une adresse propriétaire. Lorsque le jeton est vendu ou transféré, le contrat met à jour l’enregistrement de propriété uniquement après avoir vérifié l’autorité de l’expéditeur et les règles de transfert applicables.

Le contrat enregistre généralement le propriétaire du jeton, l’offre totale, les approbations, l’historique des transferts et une référence de métadonnées. Il ne stocke pas nécessairement l’œuvre elle-même. Comme l’explique Hedera sur les contrats intelligents NFT, le token ID et les métadonnées identifient l’actif, tandis que la logique du contrat intelligent gère le mint et les changements de propriété. Il est important de noter qu’un contrat intelligent est un code informatique exécutable ; il ne constitue pas automatiquement un accord juridique concernant le droit d’auteur, les remboursements ou les droits commerciaux.

Contrats NFT vs. contrats de marketplace

Le contrat NFT et le contrat de marketplace ont des rôles distincts. Le contrat NFT définit l’actif, crée les token IDs, enregistre la propriété et applique les approbations et les transferts. Le contrat de marketplace coordonne la vente : il valide l’annonce ou l’offre, collecte le paiement, transfère le NFT, achemine les frais et clôture ou annule l’ordre.

Cette séparation est importante, car posséder un NFT valide ne signifie pas qu’il est effectivement listé, et signer un ordre de marketplace ne modifie pas la propriété tant que le règlement n’est pas achevé. L’acheteur doit donc vérifier les deux adresses : le contrat de collection identifie le NFT, tandis que le contrat de marketplace ou le spender identifie le logiciel recevant l’autorisation de transfert. Pour les équipes qui intègrent des portefeuilles, des outils de support ou des indexeurs, cette distinction détermine aussi quels événements sont considérés comme source de vérité pour la disponibilité de l’objet, les remboursements et l’exécution.

Comment ERC-721 et ERC-1155 influencent la conception d’une marketplace

ERC-721 est couramment utilisé lorsque chaque token ID représente un objet unique détenu indépendamment. Il convient aux œuvres one-of-one, aux actifs de jeu uniques, aux parcelles de terrain et aux objets de collection dont la propriété est vérifiée jeton par jeton. ERC-1155 peut représenter plusieurs exemplaires du même token ID, ce qui est utile pour les consommables de jeu, les billets, les éditions ou les objets émis en quantité.

Le standard de jeton modifie le contenu d’un ordre. Une annonce ERC-721 vend normalement un seul token ID. Une annonce ERC-1155 peut proposer 20 exemplaires alors qu’un acheteur n’en achète que trois, ce qui oblige la marketplace à mettre à jour la quantité restante sans clôturer l’ordre entier. Une annulation doit invalider la quantité restante, et l’événement de règlement doit indiquer combien d’unités ont changé de mains.

Les mécanismes d’approbation diffèrent aussi. Une approbation ERC-721 spécifique à un jeton autorise un seul NFT, tandis qu’une approbation d’opérateur peut couvrir tous les jetons de cette collection. ERC-1155 utilise généralement une approbation d’opérateur pour l’ensemble du solde d’un portefeuille sous le contrat. Une marketplace peut exiger une autorisation plus large pour des raisons de commodité, mais l’invite du portefeuille doit rendre cette portée visible et l’utilisateur doit comprendre comment la révoquer.

Conceptions d’escrow et de lazy listing

Une marketplace avec escrow transfère le NFT vers le contrat de marketplace au moment où le vendeur le liste. Cette approche facilite la vérification de la disponibilité, mais le vendeur paie plus de gas et perd la possibilité d’utiliser l’actif pendant sa mise en vente. Un lazy listing conserve le NFT dans le portefeuille du vendeur et enregistre une signature hors chaîne contenant le jeton, le prix, la chaîne, l’expiration, le nonce et l’adresse de la marketplace. Cela réduit le coût de mise en vente et préserve la garde, mais le contrat doit vérifier la signature et le vendeur doit toujours disposer d’un moyen on-chain pour l’invalider.

Pour une marketplace de jeu, ce choix a des conséquences qui vont au-delà du gas. L’escrow peut empêcher un objet d’être équipé pendant qu’il est listé ; le lazy listing préserve l’actif du joueur mais oblige le jeu et la marketplace à gérer une annonce qui devient impossible à exécuter lorsque la propriété change. Cette différence opérationnelle explique aussi pourquoi les équipes doivent tester les cas limites, comme les transferts de portefeuille, les mises à niveau de collection et l’invalidation d’annonces, avant le lancement plutôt que de supposer que le modèle de listing les gérera automatiquement.

Cycle de vie des annonces et des offres

Une annonce à prix fixe devrait passer par les états create, validate, buy, settle et cancel. Les offres nécessitent une expiration, un nonce, un chain ID, des vérifications de spender et une annulation. Chaque état doit émettre des événements qu’un indexeur peut réconcilier.

Les offres doivent aussi s’appuyer sur un modèle de paiement que le contrat peut exécuter de manière fiable. Une offre en monnaie native ne peut généralement pas être retirée plus tard du portefeuille de l’acheteur sans une nouvelle transaction signée, tandis qu’un jeton ERC-20 approuvé comme WETH ou USDC peut être conservé en escrow ou transféré lorsque le vendeur accepte. L’enregistrement de l’ordre doit donc inclure la devise, le montant, l’expiration, le nonce, l’acheteur, le vendeur, le token ID et l’état d’annulation, et pas seulement un prix de référence.

Le règlement des enchères nécessite sa propre machine d’état. Une enchère anglaise doit gérer les offres supérieures, les remboursements, l’heure de clôture et l’appelant final du règlement. Une enchère hollandaise doit calculer le prix courant en fonction du temps écoulé et rejeter les achats obsolètes. Une balance de remboursement en mode pull est plus sûre qu’un envoi immédiat des fonds à chaque enchérisseur dépassé, car un callback de remboursement en échec ne doit pas bloquer toute l’enchère. Une courte extension de fin réduit aussi les attaques de sniping de dernière seconde.

Une vente NFT de 0,5 ETH, de la signature au règlement

Prenons le cas d’un NFT ERC-721 listé pour 0,5 ETH via un ordre signé. Le vendeur conserve le NFT dans son portefeuille mais autorise le contrat de marketplace à le transférer. L’annonce signée identifie le contrat de collection, le token ID, le vendeur, le prix, l’expiration, le nonce, le chain ID et l’adresse de la marketplace. Aucun changement de propriété n’a lieu au moment de la création de cette signature.

Lorsque l’acheteur soumet l’achat, le contrat de marketplace vérifie que l’ordre n’a pas expiré ni été annulé, que la signature appartient bien au vendeur, que le vendeur possède toujours le NFT et que l’approbation de transfert reste valide. Le contrat marque ensuite l’ordre comme rempli, traite le paiement, achemine le NFT vers l’acheteur et émet des événements que la marketplace peut utiliser pour mettre à jour la page de l’objet.

La répartition des frais décrite ci-dessus est illustrative et ne constitue pas une déclaration sur les frais réels d’une marketplace spécifique.

Si le transfert du NFT échoue, le paiement ne doit pas rester finalisé alors que la propriété n’a pas changé. Si le destinataire du paiement ne peut pas recevoir d’ETH, la réponse la plus sûre dépend de la conception du contrat : la transaction peut revert, ou le montant peut être crédité sur un solde retirable. C’est pourquoi l’acheminement des paiements, l’ordre des transferts, les mises à jour d’état et la protection contre la réentrance doivent être testés ensemble plutôt que comme des cases fonctionnelles isolées.

Royalties et acheminement des frais

Les informations de royalties peuvent suivre EIP-2981, tandis que des bibliothèques de contrat comme OpenZeppelin ERC-721 et OpenZeppelin ERC-1155 aident à mettre en œuvre le comportement standard des actifs. Toutefois, l’application par la marketplace nécessite toujours une politique produit explicite.

EIP-2981 rend les informations de royalties lisibles, mais pas universellement applicables. Une marketplace peut interroger l’adresse du créateur et le montant de la royalty, mais un autre service peut choisir une politique différente ou ignorer totalement le résultat. Si les revenus des créateurs sont essentiels, les développeurs doivent tester le chemin de transfert réel, la marketplace sélectionnée, le comportement des agrégateurs et la logique d’application de la collection, plutôt que de traiter un champ de royalty comme un paiement garanti.

Tests de sécurité

Les tests critiques incluent la réentrance, les attaques par rejeu, les ordres expirés, les signatures sur la mauvaise chaîne, la compromission de clés d’administration, le comportement de pause et les exécutions partielles. L’objectif n’est pas de produire une longue checklist d’audit, mais de démontrer que la marketplace échoue de manière fermée lorsqu’un ordre est dangereux.

Les tests les plus utiles doivent modéliser les échecs qu’un acheteur ou un vendeur peut réellement rencontrer. Un achat doit rejeter un changement de prix au lieu d’exécuter une bait-and-switch. Un ordre signé doit être lié au chain ID et à l’adresse de la marketplace. Un nonce annulé ou déjà consommé ne doit pas pouvoir être exécuté à nouveau. Pour le code de règlement, mettez à jour l’état de l’ordre avant les appels externes et appliquez un garde de réentrance autour des chemins de paiement et de transfert.

Un utilisateur Polygon ayant évalué Rarible a signalé que l’expérience réseau manquait de support des contrats personnalisés et du gel des métadonnées dans une revue de contrat spécifique au réseau, collectée le 11 août 2026. Cela ne prouve pas qu’un contrat de marketplace est dangereux, et les constats peuvent dépendre du réseau et de la version du produit. Cela reste toutefois une limite d’implémentation utile : testez la couverture des contrats, l’invariabilité des métadonnées et le comportement de mise à niveau sur la chaîne exacte choisie pour le lancement.

Conclusion

Un contrat de marketplace doit être évalué à partir du cycle de vie de ses ordres et de son comportement en cas d’échec. Un parcours contractuel sûr gère la création, l’expiration, l’annulation, le règlement, les royalties, l’indexation et la mise en pause sans s’appuyer sur des hypothèses. La prochaine étape d’ingénierie consiste à tester le cycle de vie des ordres.

Foire aux questions

Quelles informations sont stockées dans un contrat intelligent NFT ?

Le contrat enregistre généralement les token IDs, la propriété, les soldes, les approbations, les règles de transfert, l’offre totale et une URI de métadonnées. L’image ou la vidéo est souvent stockée séparément et référencée via les métadonnées.

Le contrat NFT gère-t-il aussi les annonces de marketplace ?

Pas nécessairement. Le contrat NFT gère le jeton, tandis qu’un contrat de marketplace distinct gère généralement les annonces, les offres, les enchères, les paiements, les frais et le règlement.

Une marketplace peut-elle transférer un NFT sans autorisation ?

Elle a besoin d’une autorisation via la propriété, une approbation spécifique au jeton ou une approbation d’opérateur reconnue par le contrat NFT. Acheteurs et vendeurs doivent vérifier le spender approuvé avant de signer.

Un champ de royalties NFT garantit-il le paiement ?

Non. Un standard de royalties peut communiquer le bénéficiaire et le montant, mais le paiement réel dépend de la politique de la marketplace et du chemin de règlement.

Avertissement : cet article est fourni uniquement à des fins de recherche et de comparaison éditoriale. Il ne constitue pas un conseil financier, d’investissement, juridique ou fiscal. Les outils NFT, les marketplaces, les frais, la prise en charge des chaînes et la disponibilité en direct peuvent évoluer rapidement ; vérifiez donc les conditions actuelles sur la plateforme officielle avant toute décision impliquant des fonds, des actifs ou des clés privées.