Files
tokenizer/docs/pedagogie/guide-realisation.md
2026-09-30 09:08:25 +02:00

7.0 KiB
Raw Blame History

Guide de réalisation — Tokenizer

Objectif : document de travail pour coder, déployer et défendre le projet. À mettre à jour quand le code existe (chemins, commandes, adresses).
Référence sujet : tokenizer.md


Vue d’ensemble du livrable école

Élément Emplacement Contenu attendu
README tokenizerRendu/README.md Choix + adresse contrat + réseau
Source tokenizerRendu/code/ Contrat(s) commentés
Déploiement tokenizerRendu/deployment/ Scripts, config réseaux, sorties
Doc utilisateur tokenizerRendu/documentation/ Usage du token, rôle, limites
Hors dépôt école docs/ (ici) Traduction, pédagogie, ce guide

Étape 1 — Cadrage (avant d’écrire du Solidity)

Checklist décisions

  • Chaîne : BNB Smart Chain Testnet (chainId 97) — ou autre EVM justifié dans README
  • Nom du token contenant 42 (ex. FortyTwoToken, School42Coin)
  • Symbole ticker (ex. FT42) — affiché sur l’explorer après déploiement
  • Supply initiale, décimales (souvent 18), droit de mint ou supply fixe
  • Modèle de ownership : Ownable OpenZeppelin recommandé pour la soutenance

Comptes et secrets

  1. Wallet de test (MetaMask ou autre) — jamais la clé privée du mainnet avec de vrais fonds.
  2. Faucet : BNB Chain Testnet Faucet
  3. Fichier .env dans deployment/ ou racine code/ :
PRIVATE_KEY=0x...   # compte TEST uniquement
BSC_TESTNET_RPC=https://data-seed-prebsc-1-s1.binance.org:8545/

Ajouter .env au .gitignore (déjà prévu dans le paquet rendu).


Étape 2 — Projet code/

Structure suggérée (Hardhat)

tokenizerRendu/code/
├── package.json
├── hardhat.config.js
├── contracts/
│   └── Token42.sol          # nom à adapter
├── test/
│   └── Token42.test.js
└── README.md                # comment compiler / tester localement

Contrat minimal (logique, pas le code final)

  1. Hériter ERC20 + Ownable (OpenZeppelin).
  2. Constructeur : name, symbol, supply initiale au déployeur ou mint réservé à owner.
  3. Si mint : fonction onlyOwner — à expliquer en README (risque si owner compromis).
  4. Commentaires en tête de fichier : rôle du token, réseau cible, standard BEP-20.

Tests locaux (fortement recommandés avant deploy)

cd tokenizerRendu/code
npm install
npx hardhat test

Points à couvrir : transfer, solde, onlyOwner sur fonctions sensibles.


Étape 3 — Dossier deployment/

Contenu type

tokenizerRendu/deployment/
├── README.md           # ordre des commandes
├── deploy.js           # ou scripts Hardhat dans code/ référencés ici
└── addresses.json      # adresse + chainId + date (après deploy)

Déploiement (exemple Hardhat)

Depuis code/ (selon ton organisation) :

npx hardhat run scripts/deploy.js --network bscTestnet

Enregistrer dans addresses.json :

{
  "network": "bscTestnet",
  "chainId": 97,
  "contract": "Token42",
  "address": "0x...",
  "explorer": "https://testnet.bscscan.com/address/0x..."
}

Vérification sur l’explorer

  • BscScan Testnet → Verify and Publish (flatten ou standard JSON input selon toolchain).
  • Copier l’URL du contrat dans tokenizerRendu/README.md.

Étape 4 — documentation/ (utilisateur)

Sections recommandées (documentation/README.md ou plusieurs fichiers) :

  1. Qu’est-ce que ce token ? (cas d’usage fictif ou pédagogique)
  2. Réseau et adresse (lien explorer)
  3. Ajouter le token dans un wallet (contract address, decimals, symbol)
  4. Actions supportées : transfer, approve, etc.
  5. Sécurité : qui est owner, ce qu’il peut faire, ce que les utilisateurs ne peuvent pas faire
  6. Limites testnet : pas de valeur réelle, reset possible des faucets

Option : documentation/WHITEPAPER.md court (1–2 pages).


Étape 5 — README école (tokenizerRendu/README.md)

Le sujet exige d’y expliquer les choix et raisons. Modèle :

Section Contenu
Présentation Nom, symbole, standard BEP-20
Chaîne BSC Testnet, chainId, pourquoi pas mainnet
Stack Hardhat, OpenZeppelin, versions
Sécurité Ownable, mint ou non, pas de backdoor cachée
Déploiement Adresse + lien BscScan
Démo soutenance 3–5 actions à montrer (voir ci-dessous)
Bonus Si multisig : où est le code, comment tester

Mettre à jour le fichier réel dans tokenizerRendu/ au fil du projet (le squelette actuel liste les sections à compléter).


Étape 6 — Scénario de soutenance (démo minimale)

Préparer un fil narratif de 5–10 minutes :

# Action Preuve
1 Montrer le repo : code/, deployment/, documentation/ ls ou IDE
2 Expliquer ownership / privilèges sur le contrat Code ouvert Token42.sol
3 Lire name, symbol, totalSupply sur l’explorer BscScan
4 transfer entre deux comptes test Explorer « Token transfers » ou wallet
5 Montrer qu’un non-owner ne peut pas mint (si applicable) Transaction revert ou test Hardhat
6 Bonus multisig Seulement si obligatoire parfaite

Pas de vidéo obligatoire ; si lien vidéo : une ligne dans README.


Étape 7 — Code review (ce que l’évaluateur peut demander)

  • Pourquoi OpenZeppelin plutôt qu’un ERC20 from scratch ?
  • Où est le risque principal de ton design (owner, mint) ?
  • Comment quelqu’un utilise ton token sans ton aide ?
  • Différence entre ton documentation/ et le README racine ?
  • Confirmation : aucune clé privée dans Git ?

Étape 8 — Bonus multisig (après obligatoire parfaite)

Pistes :

  • Contrat wallet multisig simple (m-of-n) qui détient l’ownership du token.
  • Ou contrat qui exige N signatures pour mint / transfert sortant d’un trésor.

Documenter dans documentation/ et README : nombre de signataires, adresses de test, procédure de signature.


Dépannage (à enrichir pendant le dev)

Problème Piste
Faucet vide / rate limit Réessayer plus tard, autre compte test
Transaction underpriced Ajuster gas sur BSC testnet
Verify échoue Vérifier version compilateur et settings Hardhat
Token invisible dans wallet Ajouter manuellement par adresse de contrat

Cartographie sujet ↔ dossiers (rappel)

Exigence sujet Dossier / fichier
Code commenté code/
Déploiement deployment/
Doc projet token documentation/
Choix + adresse + réseau README.md racine rendu
Revue de code code/
Démo sécurité soutenance + éventuellement tests

→ État du projet : 00-reprise-et-etat.md