Tester en local, c’est rassurant ; déployer sur un vrai réseau, c’est la preuve que votre contrat existe pour de bon. Mais on ne se jette pas directement sur Ethereum « mainnet », où chaque transaction coûte de l’argent réel. On répète d’abord sur un réseau de test : une copie publique d’Ethereum dont la monnaie n’a aucune valeur, faite exactement pour cet usage. Le réseau de test recommandé par défaut pour le développement d’applications, au moment d’écrire ces lignes, est Sepolia.
Nous reprenons le contrat RegistreFidelite écrit précédemment et nous le mettons en ligne sur Sepolia : déploiement, interaction depuis le terminal, puis publication du code source sur l’explorateur Etherscan pour qu’il soit lisible par tous.
🎯 Ce que vous allez apprendre
- Créer une clé de déploiement dédiée et la stocker chiffrée, sans jamais l’exposer.
- Obtenir un point d’accès RPC et des ETH de test gratuits.
- Déployer un contrat sur Sepolia avec
forge create. - Lire et écrire sur le contrat déployé avec
cast. - Vérifier le code source sur Etherscan pour le rendre public et auditable.
🛠️ Ce que vous allez construire
Votre contrat de fidélité, vivant à une adresse publique sur Sepolia, avec son code source vérifié et consultable sur l’explorateur. À la fin, n’importe qui pourra voir le contrat, lire les soldes, et vous pourrez créditer des points par une transaction réelle.
Prérequis
- Le projet Foundry du contrat
RegistreFidelite(voir le tutoriel précédent). - Foundry installé et fonctionnel (
forgeetcastdisponibles). - Une adresse e-mail pour créer un compte gratuit chez un fournisseur RPC.
- ⏱️ Temps estimé : 45 à 75 minutes.
Comprendre le réseau de test
Un réseau de test reproduit le fonctionnement d’Ethereum — mêmes outils, même machine virtuelle, mêmes adresses — mais sa monnaie est distribuée gratuitement et ne vaut rien. Cela permet de répéter un déploiement autant de fois qu’on veut sans risque financier. Sepolia est privilégié pour les applications car il est rapide, stable, pris en charge par tous les outils, et alimenté par des distributeurs gratuits appelés faucets. Les anciens réseaux comme Goerli ne sont plus maintenus, et Holesky, déprécié depuis septembre 2025, vise désormais les tests de validateurs plutôt que d’applications.
Étape 1 — Créer une clé de déploiement dédiée
Déployer exige de signer une transaction, donc une clé privée. Règle absolue : n’utilisez jamais la clé d’un portefeuille contenant des fonds réels dans un outil en ligne de commande. On crée une clé neuve, réservée au développement, et on la stocke chiffrée. Foundry fournit pour cela un coffre de clés (keystore).
cast wallet import deployeur --interactive
La commande demande la clé privée puis un mot de passe de chiffrement. Si vous partez de zéro, générez d’abord une nouvelle paire avec cast wallet new, qui affiche une adresse et sa clé privée — collez cette clé dans la commande d’import. Le résultat est un fichier chiffré rangé dans ~/.foundry/keystores : la clé en clair ne traîne nulle part. Récupérez l’adresse publique associée, vous en aurez besoin pour le faucet :
cast wallet address --account deployeur
Le terminal demande votre mot de passe puis affiche l’adresse, de la forme 0x.... C’est cette adresse que vous allez approvisionner en ETH de test.
Étape 2 — Obtenir un accès RPC
Pour parler à Sepolia, votre machine a besoin d’un point d’entrée vers un nœud du réseau : une URL RPC. Plutôt que d’héberger un nœud, on passe par un fournisseur d’infrastructure. Créez un compte gratuit chez Alchemy ou Infura, créez une application ciblant le réseau Sepolia, et copiez l’URL HTTPS fournie. Stockez-la dans une variable d’environnement pour ne pas la coller partout :
export SEPOLIA_RPC_URL="https://eth-sepolia.g.alchemy.com/v2/VOTRE_CLE"
Cette URL est votre canal vers le réseau ; gardez-la privée car elle est liée à votre quota gratuit. Vérifiez qu’elle répond en demandant le dernier numéro de bloc :
cast block-number --rpc-url $SEPOLIA_RPC_URL
Un nombre qui s’affiche — et qui augmente si vous relancez la commande quelques secondes plus tard — confirme que la connexion fonctionne. Une erreur d’authentification signale une URL mal copiée.
Étape 3 — Réclamer des ETH de test
Le déploiement consomme du gaz, payé en ETH de test. On l’obtient gratuitement via un faucet. Le faucet Sepolia d’Alchemy distribue une fraction d’ETH par jour à toute adresse, après connexion à un compte. Rendez-vous sur le faucet, collez l’adresse obtenue à l’étape 1, et validez. Quelques secondes plus tard, vérifiez le solde :
cast balance --rpc-url $SEPOLIA_RPC_URL $(cast wallet address --account deployeur)
La commande affiche le solde en wei (la plus petite unité). Ajoutez --ether pour le lire en ETH. Tant que le solde est à zéro, la transaction de déploiement échouera faute de gaz : attendez la réception avant de continuer. Si un faucet refuse votre demande, essayez-en un autre — plusieurs fournisseurs proposent un faucet Sepolia.
✅ Point d’étape — Vous devez avoir trois choses : une clé
deployeurdans le keystore, une URL RPC qui répond, et un solde de test non nul. Vérifiez le solde une dernière fois : s’il est positif, vous êtes prêt à déployer.
Étape 4 — Déployer le contrat
Tout est en place. La commande forge create compile, envoie la transaction de création et renvoie l’adresse du contrat. Notez la présence de --broadcast : sans ce drapeau, Foundry ne fait qu’une simulation à blanc et n’envoie rien — c’est une sécurité voulue.
forge create src/RegistreFidelite.sol:RegistreFidelite --rpc-url $SEPOLIA_RPC_URL --account deployeur --broadcast
Foundry demande le mot de passe du keystore, puis affiche trois informations : Deployer (votre adresse), Deployed to (l’adresse du contrat) et Transaction hash. Copiez l’adresse Deployed to : c’est l’identité publique de votre contrat sur Sepolia. Si la commande échoue avec un message d’insuffisance de fonds, c’est que le faucet n’a pas encore crédité l’adresse.
Étape 5 — Interagir avec le contrat déployé
Le contrat est en ligne ; manipulons-le depuis le terminal avec cast. Une lecture est gratuite et ne nécessite pas de clé. Remplacez 0xCONTRAT par votre adresse Deployed to et 0xCLIENT par une adresse quelconque :
cast call 0xCONTRAT "soldeDe(address)(uint256)" 0xCLIENT --rpc-url $SEPOLIA_RPC_URL
La réponse est 0 : personne n’a encore de points. Créditons-en. Une écriture est une transaction : elle exige la clé et du gaz.
cast send 0xCONTRAT "crediter(address,uint256)" 0xCLIENT 100 --account deployeur --rpc-url $SEPOLIA_RPC_URL
Après confirmation, cast affiche le reçu de transaction. Relancez la commande cast call précédente : le solde affiche désormais 100. Vous venez d’écrire dans l’état d’un contrat vivant sur un réseau public — et l’opération est traçable par quiconque.
Étape 6 — Vérifier le code source sur Etherscan
Par défaut, un explorateur ne montre que le bytecode, illisible. Vérifier le contrat consiste à recompiler votre code source côté Etherscan et à confirmer qu’il produit ce bytecode : le code Solidity devient alors public et l’interface de lecture/écriture s’active sur la page du contrat. Il faut une clé API Etherscan gratuite (un seul jeton fonctionne désormais sur toutes les chaînes via l’API v2).
export ETHERSCAN_API_KEY="VOTRE_CLE_ETHERSCAN"
forge verify-contract 0xCONTRAT src/RegistreFidelite.sol:RegistreFidelite --chain sepolia --etherscan-api-key $ETHERSCAN_API_KEY --watch
Le drapeau --watch attend le résultat de la vérification et affiche Contract successfully verified en cas de succès. Ouvrez ensuite la page du contrat sur l’explorateur Sepolia : vous y verrez le code Solidity et des onglets Read Contract / Write Contract permettant d’appeler les fonctions depuis le navigateur. Pour gagner du temps, on peut aussi ajouter --verify directement à la commande forge create afin de déployer et vérifier en une seule passe.
✅ Point d’étape — Sur la page Sepolia de votre contrat, le code source doit être visible et le solde du client doit refléter votre crédit. Si la vérification échoue, assurez-vous que la version du compilateur utilisée localement correspond bien et relancez avec
--watch.
Anatomie d’une transaction sur un réseau public
Quand vous lancez un cast send ou un déploiement, plusieurs choses se mettent en place automatiquement, et il est utile de les nommer. Votre clé signe la transaction : c’est la preuve cryptographique que l’ordre vient bien de vous, sans jamais révéler la clé elle-même. Chaque transaction porte un nonce, un compteur croissant propre à votre adresse, qui garantit l’ordre des opérations et empêche qu’une transaction soit rejouée. Elle porte aussi un budget de gaz et un prix du gaz : le réseau facture le calcul réellement effectué, et la transaction échoue si le budget est trop bas. Une fois signée, elle est envoyée à un nœud via votre URL RPC, diffusée aux autres nœuds, puis incluse dans un bloc par un validateur.
Tant que la transaction n’est pas dans un bloc, elle est « en attente ». Une fois incluse, elle est confirmée, mais la finalité — l’assurance qu’elle ne sera jamais annulée — n’arrive qu’après quelques blocs supplémentaires. Sur un réseau de test, ces délais se comptent en secondes. Comprendre ce cycle explique pourquoi un cast call (simple lecture) est instantané et gratuit, alors qu’un cast send (écriture) prend un instant et coûte du gaz : le premier interroge l’état déjà connu du nœud, le second demande au réseau entier de modifier cet état et de l’inscrire durablement.
Le rôle exact du fournisseur RPC
Un nœud Ethereum est un programme qui détient une copie de la chaîne et participe au réseau ; le faire tourner soi-même demande beaucoup d’espace disque et de bande passante. Le fournisseur RPC (Alchemy, Infura et d’autres) héberge ces nœuds pour vous et expose une interface standard à laquelle forge et cast envoient leurs requêtes. Votre URL contient une clé qui identifie votre projet et compte vos appels : c’est pourquoi on la garde privée et on évite de la coller dans un dépôt public. Pour un usage d’apprentissage, les paliers gratuits sont largement suffisants ; on ne passe à un plan supérieur que lorsqu’une application réelle génère un volume d’appels important.
🐞 Pièges fréquents
| Symptôme / erreur | Cause probable | Correctif |
|---|---|---|
insufficient funds for gas |
Adresse non créditée par le faucet | Attendre le crédit, vérifier avec cast balance |
| La transaction « passe » mais rien ne change | Oubli de --broadcast sur forge create |
Ajouter --broadcast pour envoyer réellement |
error sending request / timeout |
URL RPC erronée ou quota dépassé | Recopier l’URL, vérifier le tableau de bord du fournisseur |
| Vérification Etherscan échoue | Version de compilateur ou paramètres divergents | Aligner la version solc et relancer verify-contract |
| Mot de passe keystore refusé | Mauvais mot de passe ou mauvais nom de compte | Vérifier le nom (deployeur) et ressaisir le mot de passe |
✅ Récapitulatif
Votre contrat n’est plus un objet local : il vit à une adresse publique sur Sepolia, son code source est vérifié et lisible, et vous savez le manipuler avec cast. Vous avez créé une clé de déploiement sécurisée, branché un accès RPC, financé une adresse via un faucet, déployé avec --broadcast et vérifié sur Etherscan. C’est le cycle complet qui mène d’un fichier .sol à un contrat opérationnel sur un réseau.
🧾 Aide-mémoire
| Commande | Rôle |
|---|---|
cast wallet new |
Générer une nouvelle paire de clés |
cast wallet import <nom> --interactive |
Importer une clé dans le keystore chiffré |
cast balance --ether ADDR |
Lire le solde d’une adresse |
forge create ... --broadcast |
Déployer réellement un contrat |
cast call ADDR "fn(types)(retour)" args |
Lecture gratuite d’une fonction |
cast send ADDR "fn(types)" args --account |
Transaction d’écriture |
forge verify-contract ... --chain sepolia |
Vérifier le source sur Etherscan |
💪 À vous de jouer
Déployez une seconde fois le même contrat, puis utilisez cast send pour créditer trois adresses différentes de montants distincts. Vérifiez chaque solde avec cast call, puis observez les transactions et les événements émis sur la page Etherscan du contrat.
Voir une piste
Chaque cast send renvoie un transaction hash ; collez-le dans la barre de recherche d’Etherscan Sepolia pour inspecter l’appel, le gaz consommé et le journal PointsCredites. L’onglet Read Contract permet d’appeler soldeDe sans toucher au terminal.
Tutoriels frères
- Écrire et tester un premier smart contract Solidity avec Foundry — le contrat déployé ici.
- Connecter un front-end React à un smart contract — donner une interface web à ce contrat.
Pour aller plus loin
- 🔝 Retour au guide principal : Développer des smart contracts sur Ethereum
- Réseaux Ethereum (officiel) : ethereum.org/developers/docs/networks
- Déploiement avec Foundry : getfoundry.sh/forge/deploying
FAQ
Les ETH de test ont-ils une valeur ?
Non. Ils sont distribués gratuitement et ne servent qu’à payer le gaz sur le réseau de test. Ils ne sont ni échangeables ni convertibles.
Pourquoi créer une clé dédiée plutôt que réutiliser un portefeuille existant ?
Parce qu’une clé manipulée en ligne de commande peut fuiter (historique shell, fichiers, sauvegardes). Une clé dédiée au développement, jamais financée en monnaie réelle, élimine tout risque de perte.
Mon contrat déployé est-il modifiable ?
Non. Une fois déployé, le code est immuable. Pour corriger un bug, on déploie une nouvelle version à une nouvelle adresse — d’où l’importance des tests et de la revue avant déploiement.