Files

Ladebeze66 fac0438a30 fichesoutenance

2026-11-09 10:30:11 +01:00

25 KiB

Raw Blame History

Fiche de soutenance — Tokenizer (FGC42Forge)

Fichier perso, hors dépôt école. Il sert à réexpliquer le projet à voix haute après une pause. Le correcteur, lui, ne voit que tokenizerRendu/ (README, code/, deployment/, documentation/).

Lis les sections 1 à 4 pour le récit. Les sections 5 à 8 sont le cours technique. La section 9 est le script de démo. La section 10 est la revue de code, fichier par fichier.

1. Ce que tu as fait, en une histoire

Le sujet 42 Tokenizer (v1.1), en partenariat avec BNB Chain, demande de créer un jeton numérique sur une blockchain publique, sans argent réel, de le déployer, de documenter comment on l’utilise, et de pouvoir expliquer le code.

Tu as créé FGC42Forge, symbole FG42. C’est un jeton fongible : une unité en vaut une autre, comme des pièces identiques, pas comme un NFT unique. Sur BNB Smart Chain, ce standard s’appelle BEP-20. Techniquement, le code est celui d’un ERC-20 Ethereum, parce que BSC est une chaîne EVM : elle exécute les mêmes smart contracts Solidity qu’Ethereum. BscScan affiche « BEP-20 » à cause de la chaîne, pas parce que tu as écrit une norme différente.

1 000 000 FG42 ont été créés une seule fois, au moment du déploiement, et envoyés au compte qui a déployé. Ensuite, plus personne ne peut en fabriquer. On ne peut que les transférer. Il n’y a pas de fonction burn (destruction), pas de pause, pas de liste noire.

Le contrat est déjà en ligne sur BNB Smart Chain Testnet (identifiant de chaîne 97), à l’adresse :

0x0c76df26A1149fDc22C8f994975705271b070fF4

Le compte qui a payé le déploiement et qui est devenu owner s’appelle FGC_account :

0xB6bE1878BfaF1FFC8503E752b1D733Ad7b93603c

Transaction de création : 0xb6a0ec09d4db0e9f0686aca6ad5d8ca71cecaf8d43405eeed214736bb8574072 (bloc 137872368, le 2026-10-20).

Le code source a été publié et vérifié sur BscScan : l’explorateur a recompilé le source et obtenu le même bytecode que celui déjà enregistré à cette adresse. Ça prouve que le programme on-chain est bien celui du dépôt.

Le bonus du sujet (un multisig : plusieurs signatures pour une action sensible) n’a pas été fait. Tu l’assumes : l’obligatoire est complet, le bonus n’est noté que si l’obligatoire est parfait, et tu as choisi un contrat simple à défendre.

2. Deux dépôts, ne pas les mélanger

	Dépôt de travail (`main`)	Dépôt école
Où	Racine `tokenizer/`	Le contenu de `tokenizerRendu/` doit être la racine Git Vogosphere
Contenu	`docs/` (cette fiche, sujet traduit, notes) + `tokenizerRendu/`	`README.md`, `code/`, `deployment/`, `documentation/`
À montrer	À toi, pour réviser	Au correcteur

La branche rendu-tokenizer a volontairement retiré docs/ pour ne garder que le paquet école. La fiche n’y est plus : c’est normal. Elle vit sur main, dans docs/pedagogie/.

Sur le PC école : le Git Vogosphere doit avoir à sa racine le README du token, pas un dossier parent tokenizerRendu/. Sinon la structure demandée par le sujet n’est pas respectée.

3. Pitch à dire (environ une minute)

« J’ai créé un token BEP-20, FGC42Forge, symbole FG42, sur le testnet public de BNB Smart Chain. Le nom contient 42, comme le demande le sujet. Il n’y a pas d’argent réel : le gas se paie en tBNB, obtenu via un faucet.

Le contrat est écrit en Solidity. Je n’ai pas réécrit transfer ou balanceOf : j’hérite de l’ERC-20 d’OpenZeppelin, plus Ownable pour savoir qui est l’administrateur. Au constructeur, le contrat émet une seule fois un million de jetons vers le déployeur. Il n’existe aucune fonction publique pour en créer d’autres ensuite. L’owner peut transférer le rôle d’admin, mais il ne peut pas augmenter l’offre.

J’ai développé avec Hardhat 3 : compilation, deux tests automatisés, déploiement avec Ignition. L’adresse et le réseau sont dans le README et dans deployment/addresses.json. Le contrat est vérifié sur BscScan. La démo, c’est un transfer entre deux comptes MetaMask, visible sur l’explorateur. Le bonus multisig n’est pas implémenté. »

4. Chiffres à avoir sous les yeux

Élément	Valeur	Où le montrer
Nom / symbole	FGC42Forge / FG42	README, BscScan, MetaMask
Réseau	BSC Testnet, chainId 97	README, MetaMask
Contrat	`0x0c76df26A1149fDc22C8f994975705271b070fF4`	README, `deployment/addresses.json`
Owner / deployer	`0xB6bE1878BfaF1FFC8503E752b1D733Ad7b93603c`	`addresses.json`, BscScan
Supply	1 000 000, 18 décimales	contrat `INITIAL_SUPPLY`, page token
Page contrat	https://testnet.bscscan.com/address/0x0c76df26A1149fDc22C8f994975705271b070fF4	onglet Contract = code vérifié
Page token	https://testnet.bscscan.com/token/0x0c76df26A1149fDc22C8f994975705271b070fF4	supply, holders, transfers
Tests	2 tests Mocha, tous verts	`code/test/FGC42Forge.ts`

18 décimales : en interne la blockchain ne stocke pas « 1,5 FG42 ». Elle stocke un entier. 1 FG42 affiché = 1 * 10^18 unités. Le million du constructeur, c’est donc 1_000_000 * 10^18. MetaMask fait la conversion pour l’affichage. Si on oublie les décimales, on croit transférer 1 jeton alors qu’on transfère une fraction infime, ou l’inverse.

5. Les notions, assez pour les expliquer

Blockchain, compte, contrat

Une blockchain publique est un registre partagé. Une transaction est un ordre signé (déployer un contrat, transférer des jetons) que le réseau exécute et enregistre.

Une adresse 0x + 40 hex identifie soit un compte (contrôlé par une clé privée, comme FGC_account), soit un contrat (un programme dont le bytecode est stocké à cette adresse). Les deux se ressemblent. La différence : un compte a une clé ; un contrat a du code.

Gas : chaque écriture coûte du calcul au réseau. On le paie dans la monnaie native de la chaîne, pas dans FG42. Sur le testnet, cette monnaie s’appelle tBNB. Elle n’a pas de valeur réelle. On l’obtient par le faucet BNB Chain (site ou bot Telegram officiel). Sans tBNB, MetaMask ne peut ni déployer ni envoyer de FG42 : le jeton bouge, mais la transaction elle-même se paie en tBNB.

Testnet vs mainnet : le testnet est une chaîne publique de répétition. Le sujet interdit d’exiger de l’argent réel. Tu n’as rien déployé sur le mainnet BSC (chainId 56). Ne branche pas MetaMask sur le mainnet pendant la démo.

RPC : l’URL d’un nœud qui parle au réseau (https://data-seed-prebsc-1-s1.binance.org:8545/). MetaMask et Hardhat utilisent tous les deux un RPC pour lire les soldes et envoyer des transactions. Ce n’est pas un secret.

Token, ERC-20, BEP-20

Un token ici n’est pas un fichier. C’est un contrat qui tient une table « adresse → solde » et des fonctions standard :

name, symbol, decimals : l’identité affichée
totalSupply : combien d’unités existent
balanceOf(compte) : le solde d’une adresse
transfer(destinataire, montant) : l’expéditeur envoie ses propres jetons
approve + transferFrom : autoriser un tiers à dépenser jusqu’à un plafond (allowance)

Fongible : le solde est un nombre. 100 FG42 de A valent 100 FG42 de B. Un NFT (ERC-721) serait un objet numéroté : hors sujet.

ERC-20 est la norme Ethereum. BEP-20 est le même contrat d’interface sur BNB Chain. Dans le code tu importes ERC20 d’OpenZeppelin. À l’oral tu dis : « standard BEP-20, implémenté avec l’ERC-20 OpenZeppelin, déployé sur BSC ».

Le nom FGC42Forge contient 42 (obligation du sujet). FGC = tes initiales, Forge = les jetons sont « forgés » une fois au déploiement. Le symbole (ticker) est FG42, celui qu’on publie sur l’explorateur.

Mint, supply fixe, owner

Mint = créer des jetons et augmenter totalSupply. OpenZeppelin fournit _mint, une fonction interne : seul le contrat peut l’appeler, pas un utilisateur depuis MetaMask.

Dans ton constructeur, _mint(msg.sender, INITIAL_SUPPLY) s’exécute une fois, quand la transaction de déploiement crée le contrat. msg.sender est le compte qui paie cette transaction, donc FGC_account. Après ça, aucune fonction publique ne rappelle _mint. L’offre est figée.

Ownable ajoute un owner. Au départ c’est aussi le déployeur (Ownable(msg.sender)). Il peut transferOwnership (donner l’admin à une autre adresse) ou renounceOwnership (plus personne n’est owner). Dans ce contrat, être owner ne donne aucun pouvoir sur les jetons : il n’y a pas de onlyOwner sur un mint, pas de taxe, pas de gel. Si on te demande « à quoi sert l’owner alors ? », la réponse honnête est : le rôle existe parce que le modèle OpenZeppelin le pose, et pour montrer que tu as réfléchi aux privilèges ; il n’augmente pas l’offre. Un owner compromis ne peut pas imprimer des FG42 avec ce contrat. Il pourrait seulement céder le rôle vide, ou tu pourrais plus tard ajouter des fonctions onlyOwner — ce que tu n’as pas fait.

Clé privée, seed, .env

La seed (12 ou 24 mots) et la clé privée contrôlent le compte. L’adresse 0xB6bE… est publique, on peut la mettre dans le README. La clé ne doit jamais être dans Git, sur un slide, ni à l’écran en soutenance.

Hardhat, pour déployer, a besoin de signer. La clé du compte de test est dans code/.env, fichier ignoré par Git. Le modèle commité est code/.env.example : il montre les noms de variables, pas le secret. PRIVATE_KEY est la clé (64 hex), pas l’adresse du wallet. Confondre les deux est l’erreur classique : Hardhat ne peut pas signer avec une adresse.

MetaMask garde la même clé dans l’extension. Hardhat et MetaMask peuvent être le même compte (FGC_account) : l’un signe en ligne de commande, l’autre signe dans le navigateur.

6. Pourquoi cette stack (le « pourquoi » du README)

Le sujet demande d’expliquer les choix, pas seulement de lister des outils.

BNB Smart Chain Testnet. Le PDF est en partenariat BNB. La chaîne supporte les smart contracts, elle est publique, l’explorateur est BscScan, le gas de test est gratuit via faucet. Ethereum testnet aurait été valable avec un ERC-20, à justifier. Tu as suivi la piste du partenaire.

Solidity. C’est le langage des contrats EVM. Le fichier évalué est tokenizerRendu/code/contracts/FGC42Forge.sol. Version du projet : 0.8.34 (pragma et hardhat.config.ts). Les versions 0.8.x empêchent par défaut certains overflows d’entiers.

OpenZeppelin. Bibliothèque auditée. Réécrire transfer soi-même est le meilleur moyen d’introduire un bug (oubli d’événement, mauvais calcul de solde, pas de protection sur le destinataire zéro). Tu composes un contrat court par-dessus un standard connu.

Hardhat 3. Outil Node.js qui compile Solidity, lance des tests et parle au réseau. Le sujet cite aussi Remix, Truffle, Foundry. Tu peux les nommer :

Remix : IDE dans le navigateur, bien pour un contrat isolé, moins pratique pour un dépôt avec tests reproductibles.
Truffle : ancien framework compile / migrate / test, peu actif face à Hardhat.
Foundry : outils en Rust (forge), très rapides ; tu es resté sur Node parce que le projet Hardhat couvre compile, test et deploy.

Hardhat se lance depuis code/, parce que hardhat.config.ts est là. À la racine du dépôt, npx hardhat répond « No Hardhat config file found ». Ce n’est pas une panne.

Ignition. Système de déploiement de Hardhat. Le fichier code/ignition/modules/FGC42Forge.ts dit : « déploie le contrat FGC42Forge ». Il n’y a pas d’argument de constructeur : le constructeur Solidity n’en prend pas. La commande :

cd code
npx hardhat ignition deploy --network bscTestnet ignition/modules/FGC42Forge.ts

--network bscTestnet choisit l’entrée du hardhat.config.ts : URL RPC + compte PRIVATE_KEY. Sans ce flag, Hardhat ne va pas sur BSC.

Mocha + ethers. Mocha est le lanceur de tests. ethers.js est la bibliothèque qui déploie le contrat sur une chaîne simulée locale pendant npx hardhat test. Ces tests ne coûtent pas de tBNB et ne touchent pas le contrat déjà en ligne. Ils prouvent le comportement avant ou à côté du déploiement public.

TypeScript. La config Hardhat, le module Ignition et les tests sont en .ts. Le contrat, lui, reste en Solidity. Ce ne sont pas deux langages pour la même chose : Solidity = programme on-chain ; TypeScript = outillage autour.

MetaMask. Extension navigateur. Elle n’est pas dans le dépôt. Elle sert à la démo humaine : importer le token par son adresse, voir le solde, cliquer Envoyer. Hardhat sert au développeur. Les deux parlent au même réseau.

BscScan. Explorateur. Il montre l’adresse, le bytecode, les transactions, et, une fois la vérif faite, le Solidity lisible. Le sujet demande de publier le contrat sur un explorateur et de mettre l’adresse dans Git. La vérification du source n’est pas écrite mot pour mot dans le PDF ; c’est la preuve que tu montres en review.

7. Ce que font les commandes

Toutes les commandes Hardhat : d’abord cd dans tokenizerRendu/code (sur le dépôt de travail) ou code/ (si la racine Git école est déjà le rendu).

Commande	Ce qu’elle fait vraiment
`npm install`	Télécharge Hardhat, OpenZeppelin, ethers, Mocha, décrits dans `package.json`. Crée `node_modules/`, qui n’est pas commité.
`cp .env.example .env`	Prépare les secrets locaux. À éditer à la main. Inutile pour les tests seuls. Indispensable pour un nouveau deploy.
`npx hardhat build`	Compile les `.sol`. Hardhat télécharge le compilateur solc si besoin. Produit des artefacts locaux (`artifacts/`, ignorés).
`npx hardhat test --grep FGC42Forge`	Lance uniquement les 2 tests du token. Résultat attendu : 2 passing.
`npx hardhat test`	Lance aussi les tests du fichier Counter, un exemple livré par `hardhat --init`. Ce n’est pas ton token. Si un correcteur le voit, tu dis que c’est le template, le livrable est FGC42Forge.
`npx hardhat ignition deploy --network bscTestnet …`	Envoie la transaction de création sur le testnet. Coûte du tBNB. Crée une nouvelle adresse de contrat. Le déploiement déjà fait n’a pas besoin d’être rejoué en soutenance.
`npx hardhat flatten contracts/FGC42Forge.sol`	Colle ton fichier et les sources OpenZeppelin importées en un seul fichier. C’est `deployment/FGC42Forge_flat.sol`, utilisé pour la vérif BscScan en mode « single file ».

npx exécute le Hardhat du projet, pas un Hardhat installé au hasard sur la machine.

8. Les deux tests, phrase par phrase

Fichier : tokenizerRendu/code/test/FGC42Forge.ts.

Hardhat 3 ouvre une chaîne locale avec await network.create(), puis ethers. Personne n’est sur Internet.

Test 1 — « expose le nom, le symbole et la supply fixe au déployeur ».
Il déploie FGC42Forge avec le premier compte de test. Il vérifie name == FGC42Forge, symbol == FG42, decimals == 18, totalSupply égal au million en unités internes, ce solde entièrement chez le déployeur, et owner() égal à ce déployeur. Donc : identité, offre, destinataire du mint, admin.

Test 2 — « permet un transfer ERC-20 classique ».
Deux comptes : déployeur et destinataire. On transfère 1000 jetons (encore fois 10^18). Le test vérifie l’événement Transfer (from, to, montant) et que la somme des deux soldes n’a pas changé : le destinataire a +1000, le déployeur a supply − 1000. Ça montre qu’un transfer déplace des jetons, il n’en crée pas.

Ce que les tests ne couvrent pas, et que tu peux dire si on te le demande : approve / transferFrom (hérités, non redéfinis), l’échec d’un transfer plus gros que le solde (OpenZeppelin revert), le comportement sur le vrai testnet. La démo MetaMask couvre le transfer réel.

9. Déroulé oral et démo

Prépare avant : MetaMask sur BNB Smart Chain Testnet, FGC_account avec un peu de tBNB et des FG42, un second compte (demo) avec le token importé, trois onglets (README du rendu, page contrat #code, page token).

Moment	Tu ouvres	Tu expliques
1	`tokenizerRendu/README.md`	Le sujet, le nom avec 42, la chaîne, l’adresse, les 5 choix techniques
2	`documentation/README.md`	Un tiers peut importer FG42 et envoyer sans lire Solidity. Sécurité : testnet, pas de mint, owner limité
3	BscScan page token	Supply 1 000 000, historique de transfers
4	BscScan page contrat, onglet Contract	Code vérifié, correspond au dépôt
5	MetaMask	Transfer d’un petit montant (100 FG42) vers le second compte. Le gas est en tBNB
6	BscScan Transfers	La tx apparaît ; le second solde a augmenté ; `totalSupply` n’a pas bougé
7	`code/contracts/FGC42Forge.sol`	Revue ligne à ligne, section 10
8	Si on le demande	`cd code && npx hardhat test --grep FGC42Forge`

Phrase de fin sur ce que le projet t’a appris (le chapitre III du sujet) : écrire un contrat Solidity, le faire vivre sur une chaîne publique (adresse, gas, explorateur), et raisonner sur qui a le droit de créer des jetons.

Si MetaMask ou le faucet bloque le jour J : la page token a déjà des transfers passés (démo déjà faite FGC_account → demo_account). Tu montres l’historique et tu dis que le réseau de test est parfois capricieux. Mieux vaut que le live marche ; l’historique est le filet.

10. Revue de code — quoi dire devant chaque fichier

`code/contracts/FGC42Forge.sol` (le seul fichier qui compte vraiment)

Le fichier fait une cinquantaine de lignes. Presque tout le comportement est hérité.

SPDX-License-Identifier: MIT et pragma solidity ^0.8.34 : licence, et compilateur 0.8.34 minimum dans la famille 0.8.
import {ERC20} et import {Ownable} : tu ne copies pas ces centaines de lignes dans ton fichier. Le compilateur les lit dans node_modules/@openzeppelin.
contract FGC42Forge is ERC20, Ownable : ton contrat est un ERC-20 et est Ownable. Il reçoit leurs fonctions.
INITIAL_SUPPLY est une constante : 1 million fois 10^18. private : lisible seulement dans ce contrat. Elle ne change jamais.
Le constructeur appelle d’abord ERC20("FGC42Forge", "FG42") (nom et symbole stockés), puis Ownable(msg.sender) (admin = déployeur), puis _mint(msg.sender, INITIAL_SUPPLY).
Le bloc de commentaire en bas liste les fonctions héritées que tu n’as pas réécrites : transfer, approve, transferFrom, balanceOf, owner, transferOwnership, etc. Les dire montre que tu sais que « pas de code » ne veut pas dire « pas de fonction ».

Question piège : « Où est écrit transfer ? » — Dans OpenZeppelin ERC20.sol, pas dans ton fichier. En revue tu peux ouvrir le fichier aplati deployment/FGC42Forge_flat.sol : tout y est dans l’ordre, y compris function transfer.

Question piège : « Peut-on mint après ? » — Non. _mint n’est pas exposé. Chercher function mint dans ton contrat ne donne rien.

Question piège : « Que se passe-t-il si je transfer plus que mon solde ? » — OpenZeppelin annule toute la transaction (revert). Les soldes restent comme avant. Le gas de l’échec est consommé.

Question piège : « C’est un BEP-20 ou un ERC-20 ? » — Les deux formulations. Interface ERC-20, qualification BEP-20 parce que la chaîne est BSC.

`code/hardhat.config.ts`

Il enregistre le plugin Mocha/ethers, fixe Solidity 0.8.34, et décrit le réseau bscTestnet : type HTTP, URL lue dans BSC_TESTNET_RPC, compte lu dans PRIVATE_KEY. Il y a aussi deux réseaux simulés du template (hardhatMainnet, hardhatOp) : tu ne t’en sers pas pour le token.

Deux profils de compilateur : default sans optimizer, production avec optimizer activé, 200 runs. L’optimizer réduit le bytecode. Le déploiement Ignition / la vérif BscScan utilisent l’optimizer 200. Si on recompile « à la main » sans optimizer, le bytecode ne matche pas : c’est normal, ce n’est pas le même réglage.

`code/ignition/modules/FGC42Forge.ts`

buildModule + m.contract("FGC42Forge"). Pas de paramètre. Ignition envoie une transaction dont le data est le bytecode + l’appel du constructeur. Le retour { token } permet à Ignition de retenir l’adresse produite.

`deployment/addresses.json`

C’est la trace versionnée du déploiement réel : réseau, chainId, adresse, deployer, tx, bloc, drapeau bscscanVerified. Le dossier code/ignition/deployments/ est un journal local, ignoré par Git. Si on te demande « où est l’adresse officielle ? », c’est ce JSON et le README, pas le cache Ignition.

`deployment/BSCSCAN_VERIFICATION.md` et `FGC42Forge_flat.sol`

BscScan en mode single file ne sait pas aller chercher tes import dans node_modules. flatten produit un seul .sol. Tu l’as collé dans « Verify and publish », optimizer Yes, 200 runs, licence MIT, constructeur sans argument.

Nuance à connaître pour ne pas te contredire : le projet local est en Solidity 0.8.34. Après la vérif, BscScan affiche le compilateur v0.8.24+commit.89d56535. La vérif a réussi (bytecode identique) avec le fichier aplati et l’optimizer 200. Si on te pose la question, tu ne inventes pas : tu dis que le pragma du dépôt est 0.8.34, que l’écran BscScan indique 0.8.24, et que le critère qui compte est le match de bytecode, déjà obtenu. Le détail est dans BSCSCAN_VERIFICATION.md.

`documentation/README.md`

Guide utilisateur, pas cours Hardhat. Présentation, réseau, import MetaMask (adresse du contrat, 18 décimales, symbole FG42), lecture BscScan, transfer, tableau sécurité, et un whitepaper court : rôle pédagogique, ce qui existe (transfer, approve), ce qui n’existe pas (mint, burn, pause, multisig).

documentation/STACK-GLOSSAIRE-ET-PARCOURS.md est le même genre d’explications que cette fiche, mais dans le rendu, pour un correcteur qui n’a pas docs/.

Fichiers à ne pas défendre comme le projet

Counter.sol, Counter.t.sol, test/Counter.ts, ignition/modules/Counter.ts, scripts/send-op-tx.ts : générés par l’init Hardhat. Tu peux dire que tu les as laissés. Le token du sujet est uniquement FGC42Forge.

11. Sécurité — réponses développées

Qui peut créer des FG42 après le deploy ?
Personne. La seule création est dans le constructeur. Pas de mint public, pas de rôle « minter ».

L’owner est-il dangereux ?
Il peut changer l’adresse owner. Il ne peut pas piocher dans les soldes des autres ni augmenter l’offre. Un transfer part toujours du signataire de la transaction (msg.sender), pas de l’owner.

Et si quelqu’un a la clé de FGC_account ?
Cette personne possède les FG42 encore sur ce compte, le tBNB restant, et le rôle owner. Elle ne peut pas en fabriquer de nouveaux. C’est pour ça que la clé reste hors du Git et que le compte ne porte pas de vrais fonds.

Pourquoi pas de burn ?
Pas demandé. L’offre reste à 1 000 000 pour que totalSupply soit un chiffre stable en démo.

Pourquoi pas de multisig ?
Le bonus du chapitre V demande plusieurs signataires avant une action sensible. Tu ne l’as pas implémenté pour garder un obligatoire simple et explicable. Le README le dit. Le bonus n’est évalué que si l’obligatoire est sans faute ; tu ne le présentes pas comme fait.

Le token a-t-il une valeur ?
Non. Testnet. Le dire évite la confusion avec un vrai actif.

Approve, c’est quoi le risque ?
approve(spender, montant) autorise une autre adresse à appeler transferFrom sur tes jetons, dans la limite du montant. Tu ne t’en sers pas dans la démo. Si on te le demande : ne jamais approve un contrat inconnu pour une somme illimitée. Ici aucun contrat tiers n’est prévu.

12. Carte « on me demande X → j’ouvre Y »

On te demande	Fichier dans le rendu
Choix et pourquoi	`README.md` section Choix techniques
Adresse, réseau, deployer	`README.md` et `deployment/addresses.json`
Utiliser le token sans coder	`documentation/README.md`
Définition Hardhat, MetaMask, alternatives	`documentation/STACK-GLOSSAIRE-ET-PARCOURS.md`
Le programme du jeton	`code/contracts/FGC42Forge.sol`
Preuve automatique	`code/test/FGC42Forge.ts`
Comment c’est compilé et sur quel réseau	`code/hardhat.config.ts`
Comment redéployer	`code/ignition/modules/FGC42Forge.ts` et `deployment/README.md`
Preuve explorateur	`deployment/BSCSCAN_VERIFICATION.md`
Le source tel que BscScan l’a reçu	`deployment/FGC42Forge_flat.sol`

Grille des obligations du PDF (nom avec 42, testnet, 3 dossiers, README, code commenté, démo, doc utilisateur) : sujet-exigences-rendu.md. Checklist clics : checklist-demo-evaluation.md.

25 KiB Raw Blame History Unescape Escape