Ladebeze66/tokenizer
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

netoyagebrancherendu

Browse Source
This commit is contained in:
Ladebeze66
2026-10-22 11:43:13 +02:00
parent 83f3d4c1ec
commit 2adb607109
32 changed files with 0 additions and 2893 deletions
Download Patch File Download Diff File Expand all files Collapse all files

58
README.md
View File

@@ -1,58 +0,0 @@
# Tokenizer — dépôt de travail
Espace **perso** : sujet traduit, pédagogie, guides dev. Le rendu à l’école ne contient **pas** tout ce dépôt.
## Deux dépôts Git distincts
| Rôle | Où | Contenu typique |
|------|-----|-----------------|
| **Travail** (ce repo) | Racine `tokenizer/` | `docs/`, PDF, historique, notes |
| **École** (Intra / Vogosphere) | Racine = contenu de **`tokenizerRendu/`** | `README.md`, `code/`, `deployment/`, `documentation/` |
Le dossier [`tokenizerRendu/`](tokenizerRendu/) est le **paquet de rendu** : structure et README **autonomes**, conformes au sujet v1.1.
### Pousser vers l’école (quand le projet est prêt)
**Option A — Git dans le sous-dossier** (recommandé en local) :
```bash
cd tokenizerRendu
git init
git remote add origin <url-vogosphere-tokenizer>
# premier push : uniquement les fichiers de ce dossier
```
Dans le dépôt de **travail**, ignorer le `.git` imbriqué (voir `.gitignore` racine).
**Option B — Clone Vogosphere vide** puis copier le contenu de `tokenizerRendu/` à la racine du clone.
Ne pas pousser : `docs/`, traductions, captures PDF, ce README de travail.
## Documentation (travail uniquement)
| Document | Lien |
|----------|------|
| Index doc | [docs/README.md](docs/README.md) |
| Sujet FR (v1.1) | [docs/sujets/tokenizer.md](docs/sujets/tokenizer.md) |
| PDF officiel | [docs/sujets/originaux/tokenizer_subject.pdf](docs/sujets/originaux/tokenizer_subject.pdf) |
| Plan pas à pas | [docs/pedagogie/README.md](docs/pedagogie/README.md) |
| Apports pédagogiques | [docs/pedagogie/01-apports-pedagogiques.md](docs/pedagogie/01-apports-pedagogiques.md) |
| Web3 (définitions) | [docs/pedagogie/02-web3-comprendre.md](docs/pedagogie/02-web3-comprendre.md) |
| Tutos Solidity / Hardhat | [docs/pedagogie/ressources-solidity-hardhat.md](docs/pedagogie/ressources-solidity-hardhat.md) |
## Rendu école
Correcteurs et soutenance : **[tokenizerRendu/README.md](tokenizerRendu/README.md)** (lu depuis le dépôt Intra une fois poussé).
## Reprise du projet
**État actuel :** structure doc + squelette de rendu ; smart contract et déploiement **à faire**.
→ [docs/pedagogie/00-reprise-et-etat.md](docs/pedagogie/00-reprise-et-etat.md)
## Démarrage
1. Lire le [sujet traduit](docs/sujets/tokenizer.md) (avec éclaircissements).
2. Lire [02-web3-comprendre.md](docs/pedagogie/02-web3-comprendre.md) si le terme Web3 n’est pas clair, puis [01-apports-pedagogiques.md](docs/pedagogie/01-apports-pedagogiques.md) pour le « pourquoi » du projet.
3. Suivre le [parcours pas à pas](docs/pedagogie/parcours-etape-par-etape.md) (étape 1 en cours).
4. Coder et déployer **uniquement** dans `tokenizerRendu/` ([README rendu](tokenizerRendu/README.md)).

31
docs/README.md
View File

@@ -1,31 +0,0 @@
# Documentation — Tokenizer
Documentation du projet, sur le modèle de [piscine_mobile/docs](../../piscine_mobile/docs/README.md) et [swifty_companion/docs](../../swifty_companion/docs/README.md).
## Sujet officiel
→ [sujets/README.md](sujets/README.md)
| Document | Lien |
|----------|------|
| Traduction française (v1.1) + visuels | [sujets/tokenizer.md](sujets/tokenizer.md) |
| PDF Intra | [sujets/originaux/tokenizer_subject.pdf](sujets/originaux/tokenizer_subject.pdf) |
## Pédagogie (dev)
| Document | Lien |
|----------|------|
| **Reprise / état du projet** | [pedagogie/00-reprise-et-etat.md](pedagogie/00-reprise-et-etat.md) |
| **Ce que le projet t’apporte** | [pedagogie/01-apports-pedagogiques.md](pedagogie/01-apports-pedagogiques.md) |
| **Web3 — définition détaillée** | [pedagogie/02-web3-comprendre.md](pedagogie/02-web3-comprendre.md) |
| **Hardhat & alternatives** | [pedagogie/03-hardhat-et-alternatives.md](pedagogie/03-hardhat-et-alternatives.md) |
| **Tutos Solidity / Hardhat** | [pedagogie/ressources-solidity-hardhat.md](pedagogie/ressources-solidity-hardhat.md) |
| **Guide de réalisation** | [pedagogie/guide-realisation.md](pedagogie/guide-realisation.md) |
| **Parcours pas à pas** | [pedagogie/parcours-etape-par-etape.md](pedagogie/parcours-etape-par-etape.md) |
| Plan des étapes | [pedagogie/README.md](pedagogie/README.md) |
## Dépôt de rendu 42 (hors dépôt de travail)
Le code, le déploiement et la doc « utilisateur token » vivent dans **`tokenizerRendu/`** — racine du futur dépôt Intra.
→ [../tokenizerRendu/README.md](../tokenizerRendu/README.md) · workflow : [../README.md](../README.md#deux-dépôts-git-distincts)

50
docs/pedagogie/00-reprise-et-etat.md
View File

@@ -1,50 +0,0 @@
# Reprise du projet — où nous en sommes
> Dernière mise à jour : **2026-10-22** — partie obligatoire **terminée** ; audit rendu + fiche soutenance ; bonus multisig **non retenu**.
## En bref
| | |
|---|---|
| **Fait** | Token **FGC42Forge** / **FG42**, BSC Testnet, deploy + BscScan vérifié |
| **Fait** | `code/` (contrat commenté, tests, Hardhat), `deployment/`, `documentation/` |
| **Fait** | Démo transfer MetaMask (FGC_account → demo_account) |
| **Non retenu** | Bonus multisig (manque de temps) |
| **Avant Vogosphere** | [audit-rendu-tokenizer.md](audit-rendu-tokenizer.md) (Git + `.gitignore`), checklist [demo](checklist-demo-evaluation.md), pas de `.env` |
## Contrat (référence rapide)
| Champ | Valeur |
|-------|--------|
| Adresse | `0x0c76df26A1149fDc22C8f994975705271b070fF4` |
| Réseau | BSC Testnet, chainId `97` |
| Code commenté | `tokenizerRendu/code/contracts/FGC42Forge.sol` |
## Avancement par étape
→ Détail : [parcours-etape-par-etape.md](parcours-etape-par-etape.md)
| Étape | Contenu | Statut |
|-------|---------|--------|
| **0–1** | Structure, wallet, tBNB | ✅ |
| **2** | Hardhat 3 dans `code/` | ✅ |
| **3** | Contrat + tests | ✅ |
| **4** | Deploy + `deployment/` + BscScan verify | ✅ |
| **5** | `documentation/` + README choix techniques | ✅ |
| **6** | Démo + commentaires code (revue) | ✅ |
| **7** | Bonus multisig | ❌ Non retenu |
## Reprendre avant correction
1. `cd tokenizerRendu/code && npx hardhat test mocha --grep FGC42Forge`
2. Parcourir [checklist-demo-evaluation.md](checklist-demo-evaluation.md)
3. Ouvrir `FGC42Forge.sol` + README racine rendu pour la soutenance
## Fichiers clés
| Fichier | Rôle |
|---------|------|
| `tokenizerRendu/README.md` | Vue école + choix techniques |
| `tokenizerRendu/code/README.md` | Index code commenté pour correcteur |
| `tokenizerRendu/deployment/BSCSCAN_VERIFICATION.md` | Vérif explorateur |
| `docs/pedagogie/decisions-projet.md` | Suivi perso (hors rendu) |

86
docs/pedagogie/01-apports-pedagogiques.md
View File

@@ -1,86 +0,0 @@
# Ce que le projet Tokenizer t’apporte
> Lecture **pédagogique** — hors rendu école. Le correcteur évalue le dépôt Vogosphere (`tokenizerRendu/`), pas ce dossier.
## En une phrase
Tu passes de « j’ai entendu parler de la blockchain » à « j’ai **déployé**, **documenté** et **défendu** un actif numérique sur une chaîne publique, en maîtrisant au minimum la **sécurité d’ownership** et les **standards de tokens** ».
## Compétences techniques
### 1. Smart contracts et langage de chaîne
- Écrire ou adapter un contrat (**Solidity** si tu suis BSC/ETH) qui respecte une **interface standard** (BEP-20 / ERC-20).
- Comprendre ce que fait chaque fonction publique : `transfer`, `approve`, `allowance`, éventuellement `mint` / `burn`.
- Lire une **revue de code** en soutenance : noms explicites, commentaires sur les choix de sécurité, pas de « magie » copiée sans comprendre.
**Pourquoi c’est utile :** l’écosystème Web3 recrute sur la capacité à livrer du code **auditable** ; ce projet reproduit une mini-livraison réelle (code + deploy + doc).
### 2. Toolchain et reproductibilité
- Utiliser **Hardhat**, **Truffle** ou **Remix** de façon cohérente : compilation, réseaux, scripts de déploiement.
- Séparer **`code/`** (source) et **`deployment/`** (procédure) comme demandé — même logique qu’en entreprise (CI/CD, infra).
**Pourquoi c’est utile :** un token déployé « à la main une fois » sans script est difficile à maintenir ; le sujet t’entraîne à penser **reproductibilité**.
### 3. Réseaux publics et explorateurs
- Différence **mainnet** / **testnet**, **gas**, **adresse de contrat**, **vérification** sur BscScan ou équivalent.
- Obtenir des fonds de test via un **faucet** — flux standard pour tout développeur blockchain.
**Pourquoi c’est utile :** tu sais **prouver** on-chain que ton contrat existe et correspond au code (verify + lecture explorer).
### 4. Sécurité appliquée (obligatoire au sujet)
- **Ownership** : qui peut changer les règles du jeu ?
- **Privilèges** : mint illimité, pause, blacklist — chaque pouvoir doit être **justifié** dans le README et la doc.
- Préparer une **démo minimale** qui montre les cas normaux **et** ce qui est interdit (ex. un compte non-owner ne peut pas mint).
**Pourquoi c’est utile :** la majorité des incidents Web3 viennent de contrats mal conçus ; ce projet t’oblige à en parler à l’oral.
### 5. Documentation produit
- Deux niveaux distincts :
- **README école** : choix d’architecture et métadonnées de déploiement ;
- **`documentation/`** : comment **utiliser** le token (wallet, ajout du token, transfert, rôle du token dans ton « produit »).
- Option whitepaper : formaliser **à quoi sert** le token (même fictif).
**Pourquoi c’est utile :** un développeur blockchain est aussi **rédacteur** pour utilisateurs et auditeurs.
## Compétences transverses 42
| Compétence | Comment le projet la travaille |
|------------|--------------------------------|
| **Autonomie** | Peu de garde-fous : tu choisis la stack (dans les contraintes) |
| **Rigueur** | Arborescence imposée, eval = code review |
| **Communication** | README argumenté, soutenance avec démo |
| **Éthique** | Pas d’argent réel ; nom du token sans insultes ; honnêteté sur les limites du testnet |
## Lien avec le partenariat BNB Chain
Le sujet n’impose pas BSC en toutes lettres, mais le **préambule BNB** et le **faucet tBNB** orientent vers cet écosystème :
- Volume et adoption réels (contexte donné dans le PDF).
- Standard **BEP-20** aligné sur l’industrie (compatible mental model ERC-20).
- Passerelle vers d’autres projets Web3 42 ou perso (DApp, ponts, etc.).
## Bonus multisig — apports supplémentaires
Si la partie obligatoire est **parfaite**, le multisig ajoute :
- Modèle **seuil de confiance** (m-of-n signatures).
- Réflexion sur **gouvernance** et **opérations** (qui détient les clés en test ?).
## Ce que ce projet n’est pas
- Ce n’est **pas** un cours de trading ni une incitation à investir.
- Ce n’est **pas** une validation de « crypto » en général — c’est un exercice **d’ingénierie** sur registre distribué.
- Une vidéo démo **ne remplace pas** une doc écrite ni une démo live en soutenance.
## Suite naturelle après Tokenizer
- Auditer un contrat existant (lecture seule sur explorer).
- Front minimal (Web3.js / ethers) qui appelle ton token.
- Modules 42 ou projets perso : NFT (ERC-721), gouvernance, indexation (The Graph).
→ Retour au plan : [README.md](README.md) · Guide technique : [guide-realisation.md](guide-realisation.md)

563
docs/pedagogie/02-web3-comprendre.md
View File

@@ -1,563 +0,0 @@
# Web3 — définition et concepts (pour le projet Tokenizer)
> Document **pédagogique** (dépôt de travail). Le sujet Tokenizer indique seulement : *« This document is a Web3 related exercise »* — ce texte complète cette mention avant de coder.
---
## 1. Qu’est-ce que le Web3 ?
**Web3** (ou **Web 3.0**) désigne une **vision** d’Internet où les utilisateurs interagissent avec des **services numériques** en s’appuyant sur des **réseaux décentralisés** (souvent des **blockchains**), plutôt que sur des **plateformes centralisées** seules (serveurs d’une entreprise, comptes verrouillés chez un opérateur).
En pratique, quand on dit « projet Web3 » à l’école ou en entreprise, on parle souvent de :
- des **smart contracts** (programmes exécutés sur une chaîne) ;
- des **tokens** (actifs numériques définis par ces contrats) ;
- des **portefeuilles** (*wallets*) qui signent des transactions avec des **clés cryptographiques** ;
- des **applications décentralisées** (**DApps**) qui lisent/écrivent l’état on-chain via des bibliothèques (ethers.js, web3.js, etc.).
Le Web3 n’est **pas** un protocole unique ni un fichier de norme ISO : c’est un **ensemble d’idées et de technologies** dont l’emballage marketing varie. Pour Tokenizer, l’angle utile est **technique** : tu crées un **token sur une blockchain publique** — c’est un brique classique de l’écosystème Web3.
---
## 2. Web1, Web2, Web3 — repères historiques (simplifiés)
| Génération | Image courante | Qui « possède » les données / la logique ? | Exemples |
|------------|----------------|--------------------------------------------|----------|
| **Web1** (~1990–2000) | Pages **lecture seule** | Éditeurs de sites, hébergeurs | Pages HTML statiques, premiers forums |
| **Web2** (~2000–aujourd’hui) | **Lecture + écriture** sociale, apps riches | **Plateformes** (GAFAM, SaaS) : tes données et règles chez elles | Réseaux sociaux, Google Docs, API 42 hébergée par 42 |
| **Web3** (depuis ~2017, terme popularisé) | **Lecture + écriture + propriété** d’actifs / règles on-chain | **Réseau** + contrats : l’état partagé est sur la chaîne ; l’utilisateur garde souvent sa **clé** | Tokens, DeFi, NFT, DApps |
Ces frontières sont **floues** : le Web2 n’a pas disparu ; la plupart des DApps ont encore un **site web classique** (Web2) qui parle à la blockchain (Web3).
**Lien Tokenizer :** tu ne construis pas tout un site décentralisé ; tu fabriques l’**actif** (token BEP-20) que d’autres apps Web3 pourraient utiliser plus tard.
---
## 3. Idées centrales du Web3 (vocabulaire)
### 3.1 Décentralisation
Plusieurs machines (nœuds) maintiennent une **copie** (ou une vue) du même registre. Personne ne peut, à lui seul, « effacer » une transaction validée selon les règles du protocole — contrairement à une base SQL sur un serveur unique.
- **Nuance :** « décentralisé » ≠ « parfaitement égalitaire ». Miners/validateurs, fondations, bridges peuvent concentrer du pouvoir. Il faut rester **critique**.
### 3.2 Blockchain
Chaîne de **blocs** liés par empreintes cryptographiques ; chaque bloc contient des **transactions** (ou des exécutions de contrats). **Consensus** (PoW, PoS, PoA, PoSA…) définit qui peut proposer le bloc suivant — voir [§ 6.6](#66-consensus-de-la-chaîne-pow-pos-poa-et-variantes).
- **BNB Chain** (sujet Tokenizer) est une de ces chaînes, orientée **smart contracts** et volume d’usage.
### 3.3 Smart contract
Programme déployé à une **adresse** sur la chaîne. Une fois publié, son code est (en principe) **immuable** sauf si le contrat prévoit une mise à jour ou un proxy. Les utilisateurs l’appellent en envoyant des **transactions**.
- **Ton projet :** le token est un smart contract (souvent basé sur le standard **BEP-20**).
### 3.4 Token
Actif numérique défini par un contrat : soldes par adresse, transferts, parfois **mint** / **burn**. Un token peut représenter une **unité de compte** (style monnaie), des **parts**, ou un rôle dans un protocole — selon ce que **tu documentes**.
| Action | Effet sur la supply |
|--------|---------------------|
| **Mint** | **Crée** des tokens et les crédite à une adresse → `totalSupply` **augmente** |
| **Burn** | **Détruit** des tokens → `totalSupply` **diminue** |
| **Transfer** | Déplace des tokens existants → la supply **ne change pas** |
Au **déploiement**, beaucoup de contrats créent toute la supply dans le constructeur (**supply fixe**, pas de `mint` après). D’autres gardent une fonction `mint()` — souvent réservée au **`owner`** (`onlyOwner`).
- **Contrainte 42 :** le **nom** doit contenir `42` ; le ticker et l’usage sont à toi (dans le cadre du sujet).
- **Mint « illimité »** : voir [§ 7.1](#71-mint-et-mint-illimité).
- **Supply, owner, Ownable, onlyOwner** : voir [§ 7.2](#72-glossaire-anglais--supply-owner-ownable-onlyowner).
### 3.5 Wallet (portefeuille)
Logiciel ou matériel qui gère une **paire de clés** :
- **Adresse publique** (ex. `0xabc…`) — identifiant pour recevoir ;
- **Clé privée** — secret qui **signe** les transactions (ne jamais la committer dans Git).
Sur testnet, le wallet contient des **tBNB** (gas) et tes tokens après déploiement / transfer.
### 3.6 DApp (Decentralized Application)
Application dont une partie critique repose sur des contrats on-chain (échanges, votes, tokens). Souvent : front web ou mobile + bibliothèque Web3 + RPC vers un nœud.
- Tokenizer **n’exige pas** une DApp complète ; le token est la brique de base.
### 3.7 Gas
Frais payés dans la **monnaie native** de la chaîne (BNB sur BSC, ETH sur Ethereum) pour exécuter une transaction. Sur **testnet**, cette monnaie n’a **pas de valeur réelle** — le sujet insiste : pas d’argent réel pour le projet.
### 3.8 Explorateur de blocs (BscScan, etc.)
Site qui indexe chaîne : adresses, transactions, code vérifié du contrat. Obligatoire pour **prouver** le déploiement et le ticker en soutenance.
### 3.9 Réseau RPC
**RPC** (*Remote Procedure Call*) = façon pour un programme (wallet, Hardhat, Remix) de **parler à un nœud** de la blockchain via une **URL HTTP(S)**.
La blockchain ne tourne pas sur ton PC : des **nœuds** répartis sur Internet maintiennent le registre. Ton outil doit pourtant :
- **lire** l’état (solde, `name()` du token, code d’un contrat) ;
- **envoyer** des transactions déjà **signées** par ta clé privée (déploiement, `transfer`, etc.).
Le **point d’accès RPC** est la « ligne téléphonique » vers ce réseau. Ce n’est **pas** une blockchain séparée : c’est la **porte d’entrée** vers la chaîne que tu as choisie (testnet ou mainnet).
| Élément | Rôle |
|---------|------|
| **URL RPC** | Adresse du service/nœud (ex. endpoint BSC Testnet dans MetaMask ou `hardhat.config.js`) |
| **Wallet / script** | Construit la tx, la signe localement, l’envoie **via** le RPC |
| **Chaîne** | Reçoit la tx, l’exécute, met à jour l’état on-chain |
**Exemple (BSC Testnet, indicatif)** — une URL publique souvent utilisée :
`https://data-seed-prebsc-1-s1.binance.org:8545/`
**Erreur fréquente :** RPC pointant sur le **mainnet** alors que tu crois être sur le **testnet** → tu dépenses du vrai BNB ou tu ne vois pas ton contrat de test. Vérifie **réseau + chainId** (BSC Testnet = `97`) dans le wallet et dans Hardhat.
Dans le schéma ci-dessous, la boîte **« Réseau RPC »** est cette couche entre ton wallet et la **blockchain publique**.
---
## 4. Web3 et « crypto » — ne pas confondre
| Terme | Sens |
|-------|------|
| **Cryptographie** | Mathématiques (signatures, hash) — **fondation** technique de la blockchain |
| **Crypto-actif / « crypto »** (langage courant) | Tokens échangeables, souvent spéculatifs — **contexte économique** |
| **Web3** | Mouvement produit / dev autour d’apps et actifs on-chain |
Le projet Tokenizer est un exercice **d’ingénierie** (contrat, déploiement, sécurité, documentation), pas une recommandation d’investissement. Le partenariat **BNB Chain** situe l’exercice dans un **écosystème** réel, tout en utilisant le **testnet** pour éviter le risque financier.
---
## 5. Architecture mentale : où se place ton token ?
```mermaid
flowchart LR
subgraph web2 [Couche familière Web2]
User[Utilisateur]
Browser[Navigateur / IDE / Git]
end
subgraph web3 [Couche Web3]
Wallet[Wallet]
RPC[Réseau RPC]
Chain[Blockchain publique]
SC[Smart contract Token BEP-20]
Explorer[Explorateur BscScan]source ~/.bashrc
Wallet --> RPC
RPC --> Chain
Chain --> SC
SC --> Explorer
Browser --> Explorer
```
1. Tu **écris** le contrat en local (`code/`).
2. Tu **déploies** via un script (`deployment/`) — transaction signée par ton wallet test.
3. Le contrat vit à une **adresse** sur la chaîne.
4. Tout le monde peut **lire** l’état via l’explorateur ; les détenteurs de tokens **transfèrent** via leurs wallets.
**Lecture du schéma :** `Wallet → RPC → Chain` = ton MetaMask ou Hardhat envoie des requêtes à l’**URL RPC** du testnet, qui relaie vers les nœuds BSC Testnet. Détail : [§ 3.9](#39-réseau-rpc).
---
## 6. Standards : ERC-20 et BEP-20
### 6.1 C’est quoi, en une phrase ?
**ERC-20** et **BEP-20** sont des **normes** (des « contrats types ») pour des **tokens fongibles** : chaque unité est interchangeable (comme des pièces identiques), contrairement aux NFT (ERC-721, etc.).
| Norme | Chaîne concernée (exemples) |
|-------|------------------------------|
| **ERC-20** | **Ethereum** et la plupart des L2 EVM (Sepolia testnet, etc.) |
| **BEP-20** | **BNB Chain** / **BSC** (*BNB Smart Chain*) — partenaire du sujet Tokenizer |
Le **BEP** signifie *BNB Evolution Proposal* (propositions d’évolution de l’écosystème BNB), sur le même principe que **EIP** (*Ethereum Improvement Proposal*) pour ERC-20.
### 6.2 Que impose le standard ?
Ce n’est pas un fichier que tu télécharges : c’est une **interface** — ton contrat doit exposer au minimum des fonctions et événements reconnus par les wallets et explorateurs.
| Fonction / événement | Rôle |
|----------------------|------|
| `name()`, `symbol()`, `decimals()` | Affichage dans MetaMask, BscScan, etc. |
| `totalSupply()` | Offre totale de tokens existants |
| `balanceOf(adresse)` | Solde d’un compte |
| `transfer(dest, montant)` | Envoyer des tokens |
| `approve(spender, montant)` | Autoriser un autre compte/contrat à dépenser pour toi |
| `allowance(owner, spender)` | Combien il reste à dépenser via `approve` |
| `transferFrom(from, to, montant)` | Dépenser pour quelqu’un qui t’a `approve` |
| `event Transfer` | Historique on-chain des mouvements |
En projet 42, on utilise presque toujours **OpenZeppelin `ERC20`** : le code respecte ERC-20 ; déployé sur **BSC**, l’explorateur le qualifie de token **BEP-20**.
### 6.3 ERC-20 vs BEP-20 : même logique, nom selon la chaîne
Les deux chaînes sont **compatibles EVM** (même machine virtuelle, même langage **Solidity**). Pour un token « classique », le **code est souvent identique** ; ce qui change :
| | ERC-20 | BEP-20 |
|---|--------|--------|
| **Réseau typique Tokenizer** | Possible (ex. Sepolia) | **Recommandé** (BSC Testnet, tBNB, BscScan) |
| **Gas** | ETH (ou ETH test) | BNB / **tBNB** |
| **Explorateur** | Etherscan | BscScan |
| **Standard token fongible** | ERC-20 | BEP-20 (interface équivalente) |
**BEP-2** (autre norme BNB, ancienne Binance Chain) n’est **pas** le standard de ton exercice type « token ERC-20-like » sur BSC.
### 6.4 Le sujet t’oblige-t-il à choisir BEP-20 ?
**Non au sens « BEP-20 pour tout le monde ».** Le sujet dit :
- tu **choisis** une blockchain ;
- tu respectes **le standard de cette chaîne** (exemples : ERC-20 sur ETH, **BEP-20 sur BSC**).
Donc :
- **Si tu déploies sur BNB Smart Chain** → tu dois livrer un token **BEP-20** (en pratique : contrat ERC-20-compatible sur BSC).
- **Si tu déploies sur Ethereum testnet** → **ERC-20**, avec justification dans le README.
Le partenariat **42 × BNB Chain**, le faucet **tBNB** et les exemples **BscScan** orientent fortement vers **BSC testnet + BEP-20**, sans interdire formellement une autre chaîne EVM bien documentée.
**Phrase utile en soutenance :**
> « Mon token suit le standard **BEP-20** de BNB Chain, l’équivalent de l’**ERC-20** sur Ethereum ; j’ai utilisé OpenZeppelin ERC20 déployé sur le testnet. »
### 6.5 Pourquoi le sujet insiste sur un standard ?
Sans norme commune, chaque contrat aurait des noms de fonctions différents : les wallets ne pourraient pas afficher ton token ni proposer `transfer`. Le standard rend le token **lisible** par tout l’écosystème — c’est ce que l’évaluateur vérifie (comportement + code review), pas un label marketing.
### 6.6 Consensus de la chaîne : PoW, PoS, PoA (et variantes)
Quand le § 3.2 parle de **consensus**, il s’agit de la règle du réseau pour répondre à une question simple :
> **Qui a le droit de proposer le bloc suivant**, et comment les autres nœuds **acceptent** qu’il est valide ?
Tu **n’implémentes pas** ce mécanisme dans Tokenizer : tu **déploies sur une chaîne** qui l’a déjà. Comprendre PoS / PoA aide en soutenance (« sur quelle infra tourne mon token ? ») et évite de confondre **consensus réseau** et **multisig** (voir [§ 7.3](#73-multisig--types-et-lien-avec-le-bonus)).
#### PoW — *Proof of Work* (preuve de travail)
| | |
|---|---|
| **Idée** | Des **mineurs** rivalisent pour résoudre un puzzle cryptographique coûteux ; le gagnant publie le bloc et reçoit une récompense. |
| **Forces** | Très étudié (Bitcoin) ; sécurité liée à la **puissance de calcul** globale. |
| **Faiblesses** | **Consommation énergétique** élevée ; temps de bloc et frais variables. |
| **Exemples** | Bitcoin ; Ethereum **avant** « The Merge » (2022). |
#### PoS — *Proof of Stake* (preuve d’enjeu)
| | |
|---|---|
| **Idée** | Des **validateurs** bloquent une **mise** (*stake*) en tokens natifs ; le protocole **désigne** qui propose le bloc ; triche possible → **pénalités** (*slashing*). |
| **Forces** | Beaucoup moins énergivore que PoW ; modèle dominant sur les chaînes récentes. |
| **Faiblesses** | Débats sur concentration du stake, gouvernance, MEV — hors scope Tokenizer. |
| **Exemples** | Ethereum **depuis** The Merge ; Cardano, Polkadot, etc. |
#### PoA — *Proof of Authority* (preuve d’autorité)
| | |
|---|---|
| **Idée** | Seules des **entités identifiées** (liste fermée de validateurs / *sealers*) peuvent créer des blocs — pas de mining ni de stake ouvert comme en PoS grand public. |
| **Forces** | Blocs **rapides**, prévisibles ; idéal pour **réseaux privés** ou **testnets d’entreprise**. |
| **Faiblesses** | **Centralisation** assumée : il faut **faire confiance** aux autorités listées. |
| **Exemples** | Nombreux **testnets locaux** Hardhat ; chaînes consortium (Hyperledger Besu en mode PoA, etc.). |
#### Autres noms que tu peux croiser
| Sigle | Signification | Lien utile |
|-------|---------------|------------|
| **DPoS** | *Delegated Proof of Stake* — les détenteurs **élisent** un petit nombre de délégués validateurs | Certaines chaînes grand public |
| **PoSA** | *Proof of Staked Authority* — **mélange** : validateurs limités + mise en jeu | **BNB Smart Chain** utilise ce modèle (petit ensemble de validateurs actifs, historiquement ~21) |
| **IBFT / QBFT** | Variantes PoA pour réseaux privés | Plutôt entreprise, pas ton deploy BSC testnet |
**Pour BNB Chain (sujet Tokenizer) :** ce n’est pas du PoW ; ce n’est pas exactement le PoS « ouvert » d’Ethereum. C’est plutôt un modèle **PoSA** : validateurs connus + stake — assez pour dire en oral : « chaîne EVM avec validateurs, je suis utilisateur via testnet, pas validateur ».
#### Tableau comparatif (révision)
| | PoW | PoS (typique) | PoA |
|---|-----|---------------|-----|
| **Qui produit les blocs ?** | Mineurs (calcul) | Validateurs (stake) | Autorités désignées |
| **Barrière à l’entrée** | Matériel + électricité | Capital en stake | Invitation / liste |
| **Décentralisation** | Variable | Variable | Souvent **faible** (volontaire) |
| **Ton projet** | Tu ne le choisis pas | Tu **utilises** la chaîne telle quelle | Idem (sauf réseau local perso) |
---
## 7. Sécurité — angle Web3 (rappel sujet)
Le Web3 déplace une partie des risques vers **le code** et **les clés** :
| Risque | Exemple |
|--------|---------|
| Clé privée exposée | Drain du wallet |
| `owner` trop puissant | Mint illimité, vol de confiance |
| Bug de contrat | Fonds ou tokens bloqués / volés |
| Mauvaise doc | Utilisateurs qui ne comprennent pas les privilèges |
Tokenizer te demande explicitement de réfléchir à **ownership** et **privilèges** et de le montrer en **démo minimale** + **revue de code**.
### 7.1 Mint et mint illimité
Ce n’est **pas** le nom d’une fonction dans le code. On parle d’une **situation de gouvernance** :
> Tant que le **`owner`** peut appeler `mint` **sans plafond** ni règle stricte dans le contrat, il peut **créer autant de tokens qu’il veut**, quand il veut.
**Pourquoi c’est sensible (même sur testnet, pour la soutenance) :**
- Si le token représente des parts ou une « monnaie » fictive, un mint massif **dilue** tous les détenteurs (comme une impression monétaire sans limite).
- Si la **clé privée du owner** est compromise, un attaquant peut abuser de `mint`.
- Le sujet demande d’expliquer **ownership** et **privilèges** : un `mint()` `onlyOwner` **sans** `MAX_SUPPLY` est le cas classique à **documenter** et à **assumer** dans le README école.
**Pistes de design (à justifier dans ton README) :**
| Approche | Idée |
|----------|------|
| **Supply fixe** | Toute la supply créée au deploy, **pas** de `mint` ensuite |
| **Plafond** | `require(totalSupply() + amount <= MAX_SUPPLY)` |
| **Mint one-shot** | Mint initial puis fonction désactivée |
| **Bonus multisig** | Plusieurs signatures avant un mint ou avant une action owner critique |
**Exemple courant (OpenZeppelin) :** `ERC20` + `Ownable` + une fonction `mint(address, uint256)` en `onlyOwner` = mint illimité **tant que** tu n’ajoutes pas de limite explicite. Ce n’est pas « faux » pour l’exercice, mais tu dois le dire à l’oral : qui peut mint, quel risque, pourquoi tu as choisi ainsi.
**Démo eval utile :** montrer qu’un compte **non-owner** ne peut pas `mint` (transaction qui **revert** ou test Hardhat).
### 7.2 Glossaire anglais — supply, owner, Ownable, onlyOwner
La doc Solidity et OpenZeppelin est en anglais. Ces quatre termes reviennent partout dans Tokenizer et en soutenance.
#### Supply (*offre*, *quantité en circulation*)
| Terme | Signification |
|-------|----------------|
| **supply** | **Quantité totale** de tokens qui **existent** pour ce contrat (à un instant donné). |
| **total supply** | Même idée ; en code ERC-20 : fonction **`totalSupply()`** qui renvoie un nombre (souvent en plus petite unité, avec **décimales**). |
| **fixed supply** | Toute la supply est créée **une fois** (souvent au déploiement) ; il n’y a plus de création après. |
| **max supply** | **Plafond** : on ne peut pas dépasser ce total (souvent constante `MAX_SUPPLY` dans le contrat). |
**Exemple mental :** si tu crées 1 000 000 tokens au deploy et qu’il n’y a pas de `mint`, la supply est **fixe** à 1 000 000. Chaque `transfer` ne change pas `totalSupply` ; seul un **mint** l’augmente et un **burn** la diminue.
**À l’oral en français :** tu peux dire « **offre totale** » ou « **quantité totale de tokens émis** » plutôt que laisser *supply* sans traduction.
---
#### Owner (*propriétaire du contrat*)
| Précision | Détail |
|-----------|--------|
| **Ce que c’est** | Une **adresse** (compte wallet) désignée comme **administrateur** du smart contract — pas « propriétaire de tous les tokens ». |
| **Ce que ce n’est pas** | Ce n’est pas automatiquement la personne qui détient le plus de tokens ; c’est celui qui a les **droits d’administration** définis dans le code (mint, changer le owner, etc.). |
| **Qui devient owner au deploy ?** | Souvent **`msg.sender`** : l’adresse qui a **déployé** le contrat (ta transaction de déploiement). |
Le sujet parle d’**ownership** (*propriété* / *gouvernance*) au sens : **qui a le pouvoir** sur les fonctions sensibles du contrat.
---
#### Ownable (bibliothèque OpenZeppelin)
**Ownable** n’est pas un mot du standard BEP-20 : c’est un **module** fourni par [OpenZeppelin](https://docs.openzeppelin.com/contracts/5.x/access-control#ownership-and-ownable) que tu **hérites** dans ton contrat, par exemple :
```solidity
contract MonToken42 is ERC20, Ownable {
// ...
}
```
Ce module ajoute notamment :
| Élément | Rôle |
|---------|------|
| Variable interne `_owner` | Stocke l’adresse du **owner** actuel |
| `owner()` | Fonction **lecture** : qui est owner ? |
| `transferOwnership(nouvelleAdresse)` | Transfère le rôle admin à une autre adresse (**onlyOwner**) |
| `renounceOwnership()` | Owner renonce à son rôle (plus personne n’est owner — à utiliser en connaissance de cause) |
**Pourquoi l’utiliser :** pattern éprouvé, lisible en **code review**, moins de bugs qu’un `address boss` écrit à la main.
---
#### onlyOwner (modificateur Solidity)
En Solidity, un **modifier** (*modificateur*) est une règle placée **avant** une fonction. **`onlyOwner`** (fourni par `Ownable`) signifie :
> Seule l’adresse retournée par `owner()` peut appeler cette fonction ; **toute autre adresse** voit la transaction **échouer** (*revert*).
Exemple typique :
```solidity
function mint(address to, uint256 amount) public onlyOwner {
_mint(to, amount);
}
```
| Lecteur du code | Comportement |
|-----------------|--------------|
| Appel depuis le **wallet owner** | `mint` s’exécute, supply augmente |
| Appel depuis **un autre compte** | Échec : pas le droit d’appeler |
**Lien avec le sujet :** c’est un **privilège** explicite à expliquer en README : « seul le owner peut mint ; en eval je montre qu’un autre compte ne peut pas ».
---
#### Tableau récapitulatif
| Anglais | Français (soutenance) | Où tu le vois |
|---------|----------------------|---------------|
| **supply** | offre / quantité totale émise | `totalSupply()`, doc, whitepaper |
| **owner** | propriétaire (admin du contrat) | `owner()`, sujet « ownership » |
| **Ownable** | contrat / module « propriété unique » | `import` OpenZeppelin, héritage |
| **onlyOwner** | « réservé au propriétaire » | modifier sur `mint`, `pause`, etc. |
### 7.3 Multisig — types et lien avec le bonus
**Multisig** (*multisignature*) = une action (souvent une **transaction** ou un appel de contrat) n’est **valide** que si **plusieurs clés** ont approuvé, selon un seuil **m sur n** :
> Exemple **2-of-3** : trois signataires possibles, **au moins 2** signatures requises pour exécuter.
Ce n’est **pas** un mécanisme de consensus de **chaîne** (PoS/PoA) : c’est une règle de **gouvernance** sur un **wallet** ou un **contrat** — souvent proposé en **bonus** Tokenizer.
#### Multisig ≠ onlyOwner
| | **onlyOwner** (obligatoire courante) | **Multisig** (bonus sujet) |
|---|--------------------------------------|----------------------------|
| **Qui décide ?** | **Une** adresse | **Plusieurs** adresses selon seuil |
| **Risque** | Une clé volée = tout perdu | Une clé volée ne suffit en général **pas** |
| **Complexité** | Faible (`Ownable`) | Plus élevée (contrat dédié ou wallet multisig) |
#### Types / formes de multisig (les plus utiles à connaître)
**1. Wallet multisig on-chain (contrat portefeuille)**
- Un **smart contract** détient les fonds (BNB, tokens).
- Flux typique : `proposeTransaction` → chaque signataire `confirm` → `execute` quand le seuil **m** est atteint.
- Exemples connus : **Safe** (ex-Gnosis Safe), contrats multisig « maison » pour le bonus.
- **Usage Tokenizer :** le **owner** du token peut être ce contrat multisig au lieu d’un seul MetaMask.
**2. Multisig sur une fonction précise (contrat custom)**
- Ton token reste `ERC20`, mais `mint` ou `transferOwnership` exige que **k adresses** aient signé ou validé (pattern plus rare en débutant ; souvent on passe par un wallet multisig qui **est** l’owner).
**3. Seuils différents (m-of-n)**
| Notation | Signification |
|----------|----------------|
| **1-of-n** | Une seule signature parmi n suffit (peu protecteur) |
| **2-of-3** | Classique pour petites équipes / testnet |
| **n-of-n** | **Tous** doivent signer (très strict, risque de blocage si une clé est perdue) |
| **m-of-n** | Cas général du sujet (« plusieurs parties » + nombre requis) |
**4. Multisig « hors chaîne » / institutionnel**
- Clés réparties entre coffres HSM, procédures bancaires — tu n’en fais pas pour 42 ; utile seulement pour situer le paysage.
**5. Ce qu’on ne confond pas**
| Terme | Ce que ce n’est pas |
|-------|---------------------|
| **Multisig** | Pas « plusieurs owners » indépendants sur le même `Ownable` OpenZeppelin standard |
| **Multi-sig Bitcoin (P2SH)** | Même **idée** (m-of-n), autre blockchain — pas ton stack BEP-20 |
| **RPC / plusieurs nœuds** | Infrastructure réseau, pas gouvernance de clés |
#### Bonus sujet Tokenizer — ce qu’on attend (esprit)
Le PDF demande un contrat où **plusieurs signatures** sont nécessaires **avant** d’exécuter une transaction sensible. En pratique, les approches acceptables en soutenance :
1. **Wallet multisig** qui possède l’ownership du token + démo d’un `mint` ou transfert validé à 2-of-n.
2. **Contrat multisig minimal** + documentation : qui signe, quel seuil, comment tester sur testnet.
Adapter le bonus à **ta** partie obligatoire (même token, même réseau) — voir [guide-realisation.md](guide-realisation.md) étape 8.
#### Phrase oral utile
> « Le **consensus PoSA** de BNB Chain fait tourner le réseau ; mon **multisig**, c’est au niveau **application** : plusieurs clés doivent valider avant qu’on puisse agir en tant qu’admin du token. »
---
## 8. Ce que le Web3 t’apporte dans *ce* projet (résumé)
| Concept Web3 | Dans Tokenizer |
|--------------|----------------|
| Blockchain publique | Déploiement testnet + adresse dans README |
| Smart contract | `code/` — token |
| Token standard | BEP-20 (recommandé) |
| Wallet + gas | tBNB via faucet |
| Transparence | Explorer + verify |
| Gouvernance minimale | Owner, éventuel bonus multisig |
Pour aller plus loin sur les **compétences** visées : [01-apports-pedagogiques.md](01-apports-pedagogiques.md).
Pour passer à l’action : [guide-realisation.md](guide-realisation.md).
---
## 9. Lectures utiles (hors 42)
- [Ethereum.org — Introduction](https://ethereum.org/fr/developers/docs/intro-to-ethereum/) (concepts transférables à BSC)
- [BNB Chain — documentation développeurs](https://www.bnbchain.org/en/developers)
- [OpenZeppelin — ERC20](https://docs.openzeppelin.com/contracts/5.x/erc20)
---
## 10. BNB, BNB Chain et Binance (partenaire du sujet)
Le chapitre I du sujet parle de **BNB Chain** et du faucet **tBNB**. Le sigle **BNB** prête souvent à confusion avec **Binance** : voici une cartographie claire pour Tokenizer.
### 10.1 Trois sens différents de « BNB »
| Sens | Explication |
|------|-------------|
| **BNB Chain** | Le **réseau blockchain** (smart contracts, tokens, DApps). Nom marketing actuel : *Build N Build* — c’est ce que le PDF cite en partenariat avec 42. |
| **BNB (l’actif)** | La **monnaie native** de cette chaîne : tu la dépenses en **gas** pour déployer un contrat ou envoyer une transaction. |
| **tBNB** | Même rôle sur le **testnet** : BNB de **test**, **sans valeur réelle** — obtenu via le [faucet](https://www.bnbchain.org/en/testnet-faucet) du sujet. |
Ton token du projet (BEP-20) est un **autre** contrat : ce n’est pas le BNB natif, mais il vit sur la **même chaîne** et les transferts de ton token consomment aussi du gas payé en (t)BNB.
### 10.2 Rapport avec Binance
**Oui, il y a un lien historique et économique**, mais **BNB Chain n’est pas « l’application Binance »** au sens du site d’échange.
| Élément | Rôle |
|---------|------|
| **Binance** | Entreprise fondée en 2017, connue surtout comme **plateforme d’échange** centralisée (ordres, carnets, comptes utilisateurs). |
| **Origine du token BNB** | Lancé par l’écosystème Binance ; le nom venait souvent de **Binance Coin** à l’époque. |
| **Binance Smart Chain (BSC)** | Lancée en 2020 : chaîne **compatible EVM** (proche d’Ethereum) pour des contrats moins chers / rapides que le mainnet ETH de l’époque. |
| **Rebranding BNB Chain** | La chaîne et la marque ont été regroupées sous **BNB Chain** (*Build N Build*) : communication orientée **réseau pour développeurs**, pas seulement exchange. |
En soutenance, une formulation honnête et suffisante :
> « Le sujet est en partenariat avec **BNB Chain**. BNB est la monnaie native de ce réseau ; l’écosystème est lié historiquement à **Binance**, mais mon projet tourne sur le **testnet public** avec **tBNB** — je n’utilise pas de fonds réels ni le compte trading Binance. »
### 10.3 Noms que tu peux croiser (glossaire)
| Abréviation | Signification | Utile pour Tokenizer |
|-------------|---------------|----------------------|
| **BSC** | *Binance Smart Chain* — ancien nom courant de la chaîne | Encore utilisé dans les tutos (MetaMask « BSC Testnet ») |
| **BNB Smart Chain** | Formulation intermédiaire | Même famille que BSC / BNB Chain |
| **BEP-20** | Standard des **tokens** sur BNB Chain | **Obligatoire** à respecter (équivalent ERC-20) |
| **BEP-2** | Ancien format sur une autre brique (Binance Chain legacy) | **Pas** le standard de ton exercice type ERC-20/BEP-20 |
| **BscScan** | Explorateur de blocs pour BSC / BNB Chain | Où publier l’adresse du contrat après déploiement |
| **chainId 97** | Identifiant du **BSC Testnet** | À mentionner dans le README école avec l’adresse |
### 10.4 Ce dont tu as besoin (et ce dont tu n’as pas besoin)
| Besoin | Pourquoi |
|--------|----------|
| **Wallet** (MetaMask, Rabby, etc.) | Adresse + signature des transactions de déploiement |
| **RPC testnet** | Connexion Hardhat / Remix à la chaîne de test |
| **tBNB** (faucet) | Payer le gas du deploy et des démos |
| **Compte Binance / KYC** | **Non requis** pour le projet tel que décrit dans le sujet |
Le **mainnet** BNB (vrai BNB avec valeur marché) n’est **pas** demandé ; le sujet insiste sur les **test chains**.
### 10.5 Lien avec le chapitre I du PDF
Le partenariat **42 × BNB Chain** explique :
- les statistiques d’usage (volume, DApps) dans le préambule ;
- le lien vers [bnbchain.org](https://www.bnbchain.org/) (Figure I.1) ;
- le **faucet** pour développer sans argent réel.
Ce n’impose pas juridiquement BSC en une phrase « tu dois utiliser BSC », mais c’est la piste **la plus alignée** avec le sujet (BEP-20, tBNB, BscScan). Une autre chaîne EVM reste possible si tu **justifies** tes choix dans le README école.
→ Rappel dans le sujet traduit : [Chapitre I — BNB, Binance et BNB Chain](../sujets/tokenizer.md#bnb-binance-et-bnb-chain).
---
*Dernière révision : ajout section BNB / Binance — à compléter si tu choisis une chaîne non-EVM (peu courant pour ce sujet).*

160
docs/pedagogie/03-hardhat-et-alternatives.md
View File

@@ -1,160 +0,0 @@
# Hardhat et alternatives (Remix, Truffle, Foundry…)
> **Contexte :** projet Tokenizer — dossier `code/` + `deployment/` ([sujet ch. IV](../sujets/tokenizer.md#chapitre-iv--partie-obligatoire)).
> **Choix projet :** [decisions-projet.md](decisions-projet.md) → **Hardhat** + OpenZeppelin.
---
## 1. Le problème que résout une « toolchain »
Écrire un fichier `.sol` ne suffit pas. Il faut :
| Besoin | Sans outil | Avec toolchain |
|--------|------------|----------------|
| Traduire Solidity en bytecode | Impossible à la main | **Compilation** |
| Vérifier que `transfer` marche | Deploy à chaque essai sur testnet (gas) | **Tests** locaux |
| Envoyer le contrat sur BSC testnet | Tx manuelle complexe | **Scripts de déploiement** |
| Reproduire le deploy pour l’éval | Oublis, « ça marche sur ma machine » | Scripts + config **versionnés** dans Git |
Le sujet cite explicitement : **IDE**, **Remix**, **Truffle** ou **Hardhat** — ce sont des **outils** pour compiler, tester et déployer, pas le standard BEP-20 lui-même.
---
## 2. C’est quoi Hardhat ?
**Hardhat** est un **environnement de développement** pour smart contracts sur chaînes **EVM** (Ethereum, BSC, etc.).
- Écrit en **JavaScript / TypeScript** (Node.js).
- Projet typique : `hardhat.config.js`, dossier `contracts/`, `scripts/`, `test/`.
- Commandes courantes :
- `npx hardhat compile` — compile Solidity → artefacts dans `artifacts/`
- `npx hardhat test` — lance les tests (souvent avec **ethers.js**)
- `npx hardhat run scripts/deploy.js --network bscTestnet` — déploie sur le testnet
- `npx hardhat node` — blockchain **locale** temporaire (0 tBNB réel, pour dev)
**Rôle dans Tokenizer :**
| Dossier sujet | Rôle Hardhat |
|---------------|--------------|
| **`code/`** | Sources `.sol`, config Hardhat, tests, `package.json` |
| **`deployment/`** | Scripts / notes de deploy (souvent `scripts/deploy.js` appelé depuis `code/`, ou copie documentée — l’important est que l’évaluateur retrouve **comment** redéployer) |
Hardhat ne remplace pas **MetaMask** : MetaMask **signe** ; Hardhat utilise ta **clé privée** (via `.env`) pour envoyer la transaction de deploy depuis le terminal.
---
## 3. Les briques autour de Hardhat (vocabulaire)
| Terme | Rôle |
|-------|------|
| **Solidity** | Langage du contrat (FGC42Forge.sol) |
| **OpenZeppelin** | Bibliothèque de contrats éprouvés (`ERC20`, `Ownable`) |
| **ethers.js** | Bibliothèque JS pour parler à la chaîne (lire balances, envoyer txs) |
| **RPC** | URL dans `hardhat.config` → même idée que MetaMask ([02-web3 § 3.9](02-web3-comprendre.md#39-réseau-rpc)) |
| **@nomicfoundation/hardhat-toolbox** | Pack plugins (tests, verify, etc.) recommandé par Hardhat |
| **artifacts/** | Sortie compilée (bytecode) — souvent **gitignoré**, régénéré par `compile` |
| **BscScan verify** | Publier le code source sur l’explorer (étape deploy, hors Hardhat strict mais complémentaire) |
---
## 4. Alternatives citées par le sujet (et autres)
### Remix (IDE navigateur)
| | |
|---|---|
| **C’est quoi** | Site [remix.ethereum.org](https://remix.ethereum.org) : éditeur + compile + deploy **dans le navigateur**. |
| **Pour** | Prototyper vite, premier contrat, démo visuelle, cours. |
| **Contre** | Moins pratique pour un **dépôt 42** structuré (`code/`, tests, CI, scripts reproductibles). |
| **Tokenizer** | Autorisé par le sujet ; beaucoup d’étudiants font un **premier test** sur Remix puis migrent vers Hardhat/Truffle pour le rendu. |
### Truffle
| | |
|---|---|
| **C’est quoi** | Framework Node.js **plus ancien** que Hardhat : Truffle Compile, Migrate, Ganache. |
| **Pour** | Cycle complet migrations + tests ; encore vu en entreprise / anciens tutos. |
| **Contre** | Écosystème moins « par défaut » qu’Hardhat aujourd’hui ; config parfois plus lourde. |
| **Exemple 42** | [BdClement/Tokenizer](https://github.com/BdClement/Tokenizer) a choisi **Truffle** + Alchemy RPC — **valide** si README explique les choix. |
### Foundry (forge / cast)
| | |
|---|---|
| **C’est quoi** | Toolchain en **Rust** : `forge` (compile/test), `cast` (CLI), très rapide, tests souvent **en Solidity**. |
| **Pour** | Perf, culture « smart contract pur », projets DeFi avancés. |
| **Contre** | Courbe d’apprentissage différente (moins JS) ; moins cité dans le PDF Tokenizer. |
| **Tokenizer** | Possible si BEP-20 + deploy testnet + doc — à **justifier** dans le README école. |
### Autres (hors PDF mais utiles à situer)
| Outil | Note |
|-------|------|
| **Ganache / `hardhat node`** | Blockchain locale pour tests |
| **Brownie** | Python — plutôt écosystème Ethereum historique |
| **Thirdweb, etc.** | Abstractions / SDK — le sujet demande de **comprendre** ce que tu déploies ; éviter le « tout no-code » en soutenance |
---
## 5. Tableau comparatif (révision soutenance)
| Critère | Hardhat | Remix | Truffle | Foundry |
|---------|---------|-------|---------|---------|
| Où ça tourne | Terminal + VS Code | Navigateur | Terminal | Terminal |
| Langage orchestration | JS/TS | GUI | JS | Rust + Solidity tests |
| Tests automatisés | ✅ (Mocha/Chai) | Limité | ✅ | ✅ (forge) |
| Scripts deploy reproductibles | ✅ | Manuel | ✅ (migrations) | ✅ |
| Cité sujet Tokenizer | ✅ | ✅ | ✅ | ❌ (mais EVM OK) |
| Fit dossiers `code/` + `deployment/` | ✅ très bon | Moyen seul | ✅ bon | ✅ bon |
Le sujet **n’impose pas** Hardhat : il impose de **maîtriser un outil** et de livrer du **code commenté** + deploy documenté.
---
## 6. Pourquoi Hardhat pour *ton* parcours FGC ?
| Raison | Détail |
|--------|--------|
| Alignement doc 42 / tutoriels BEP-20 | Beaucoup d’exemples OpenZeppelin + Hardhat |
| Un seul écosystème **Node** | `npm install`, proche d’autres stacks JS |
| Tests avant testnet | Économise tes **0,1 tBNB** |
| `hardhat.config.js` | Réseau **bscTestnet** chainId **97** = même logique que MetaMask |
| Séparation claire | `contracts/` + `scripts/` → facile à expliquer en **code review** |
Tu pourrais dire en soutenance :
> « J’ai choisi **Hardhat** pour compiler et tester **FGC42Forge** en local, puis déployer sur **BSC Testnet** avec un script reproductible dans le dépôt, comme le sujet le prévoit pour la partie deployment. »
---
## 7. Flux mental : de Hardhat à la chaîne
```mermaid
flowchart LR
subgraph local [Machine dev]
SOL[FGC42Forge.sol]
HH[Hardhat compile / test]
SCRIPT[script deploy.js]
end
subgraph chain [BSC Testnet 97]
RPC[RPC URL]
SC[Adresse contrat]
end
SOL --> HH
HH --> SCRIPT
SCRIPT -->|tx signée PRIVATE_KEY| RPC
RPC --> SC
SC --> BSCScan[testnet.bscscan.com]
```
MetaMask reste utile pour **démos manuelles** (`transfer` FG42) ; Hardhat sert surtout au **deploy** et aux **tests**.
---
## 8. Liens
- **Index complet tutos & docs :** [ressources-solidity-hardhat.md](ressources-solidity-hardhat.md)
- [Hardhat — Getting started](https://hardhat.org/hardhat-runner/docs/getting-started)
- [OpenZeppelin Contracts](https://docs.openzeppelin.com/contracts/)
- Étape suivante : [etape-02-init-hardhat.md](etapes/etape-02-init-hardhat.md)
- [guide-realisation.md](guide-realisation.md)

79
docs/pedagogie/README.md
View File

@@ -1,79 +0,0 @@
# Pédagogie — Tokenizer
Parcours pour construire le projet **étape par étape** et le défendre en soutenance.
## Reprise rapide
→ **[parcours-etape-par-etape.md](parcours-etape-par-etape.md)** — **parcours guidé** (une étape → vérification → suivante).
→ **[00-reprise-et-etat.md](00-reprise-et-etat.md)** — état du projet.
→ **[guide-realisation.md](guide-realisation.md)** — référence technique complète (toutes les étapes).
→ **[decisions-projet.md](decisions-projet.md)** — choix token / chaîne / wallet (**travail**, pas rendu école).
→ **[checklist-demo-evaluation.md](checklist-demo-evaluation.md)** — **checklist démo / correction** (hors dépôt Vogosphere).
→ **[sujet-exigences-rendu.md](sujet-exigences-rendu.md)** — grille obligatoire / bonus (PDF v1.1).
→ **[fiche-soutenance-tokenizer.md](fiche-soutenance-tokenizer.md)** — déroulé oral + code review.
→ **[audit-rendu-tokenizer.md](audit-rendu-tokenizer.md)** — audit `tokenizerRendu/` + procédure Git Vogosphere.
→ **[03-hardhat-et-alternatives.md](03-hardhat-et-alternatives.md)** — **Hardhat**, Remix, Truffle, Foundry (sujet ch. IV).
→ **[ressources-solidity-hardhat.md](ressources-solidity-hardhat.md)** — **tutos & docs officiels** Solidity, Hardhat, OpenZeppelin, BSC (parcours d’apprentissage).
## Apprentissage Solidity / Hardhat
| Priorité | Document / lien |
|----------|-----------------|
| Index ressources | [ressources-solidity-hardhat.md](ressources-solidity-hardhat.md) |
| Concepts Web3 | [02-web3-comprendre.md](02-web3-comprendre.md) |
| Pourquoi Hardhat | [03-hardhat-et-alternatives.md](03-hardhat-et-alternatives.md) |
| Plan lecture minimum (avant étape 3) | [ressources-solidity-hardhat.md § 8](ressources-solidity-hardhat.md#8-plan-de-lecture-minimum-avant-létape-3) |
→ **[01-apports-pedagogiques.md](01-apports-pedagogiques.md)** — **ce que ce projet t’apporte** (compétences, concepts).
→ **[02-web3-comprendre.md](02-web3-comprendre.md)** — **Web3 : définition détaillée** (RPC, ERC-20/BEP-20, **PoW/PoS/PoA**, **multisig**, owner, BNB / Binance).
## Prérequis suggérés
| Domaine | Niveau attendu |
|---------|----------------|
| Git | Dépôt structuré, README, pas de secrets commités |
| Ligne de commande | npm ou équivalent, variables d’environnement |
| Programmation | Au moins un langage ; Solidity s’apprend pendant le projet |
| 42 | Aucun prérequis Web3 obligatoire — le sujet assume l’apprentissage |
Ressources externes utiles : [docs Solidity](https://docs.soliditylang.org/), [OpenZeppelin Contracts](https://docs.openzeppelin.com/contracts/), [BscScan Testnet](https://testnet.bscscan.com/).
## Étapes du projet
| Étape | Objectif | Statut |
|-------|----------|--------|
| **0** | Dépôt travail + `docs/`, sujet FR, paquet `tokenizerRendu/` | ✅ **Fait** |
| **1** | [Cadrage + wallet testnet](etapes/etape-01-cadrage-wallet-testnet.md) | ✅ **Validée** |
| **2** | [Init Hardhat](etapes/etape-02-init-hardhat.md) | 🔄 **En cours** |
| **3** | Contrat **FGC42Forge** BEP-20 + tests | ⏳ |
| **4** | `deployment/` + deploy testnet + BscScan | ⏳ |
| **5** | `documentation/` + README école | ⏳ |
| **6** | Démo + code review | ⏳ |
| **7** | Bonus multisig (optionnel) | ⏳ |
README correcteurs (dépôt école) : [tokenizerRendu/README.md](../../tokenizerRendu/README.md)
## Sujet de référence
→ [Traduction FR v1.1](../sujets/tokenizer.md) · PDF : [originaux/tokenizer_subject.pdf](../sujets/originaux/tokenizer_subject.pdf)
## Guides détaillés
| Fichier | Rôle |
|---------|------|
| [00-reprise-et-etat.md](00-reprise-et-etat.md) | État, arborescence, reprise |
| [01-apports-pedagogiques.md](01-apports-pedagogiques.md) | Valeur pédagogique du projet |
| [02-web3-comprendre.md](02-web3-comprendre.md) | Web3 — définitions et vocabulaire |
| [guide-realisation.md](guide-realisation.md) | Réalisation technique pas à pas |
Demande dans le chat l’étape à approfondir : le guide pourra être mis à jour au fil du code (fichiers réels, adresses, scripts).

108
docs/pedagogie/audit-rendu-tokenizer.md
View File

@@ -1,108 +0,0 @@
# Audit rendu — `tokenizerRendu/` (avant Vogosphere)
> Date : 2026-10-22 · Grille : [`sujet-exigences-rendu.md`](sujet-exigences-rendu.md)
## Verdict global
| Statut | Commentaire |
|--------|-------------|
| **Prêt pour push école** | Partie obligatoire couverte ; nettoyage doc + `.gitignore` effectués |
| **À faire sur machine école** | `npm install` + `npx hardhat test` ; démo MetaMask ; `git init` ou clone dédié |
---
## Conformité sujet (T1–T19)
Tous les critères obligatoires du tableau **sujet-exigences-rendu.md** sont **OK** pour FGC42Forge (nom `42`, BEP-20 testnet, 3 dossiers, README choix, deploy + adresse, doc utilisateur, code commenté, bonus documenté comme non retenu).
---
## Fichiers à **inclure** dans le dépôt Vogosphere
| Zone | Fichiers clés |
|------|----------------|
| Racine | `README.md`, `.gitignore` |
| `code/` | `contracts/FGC42Forge.sol`, tests, ignition module, `hardhat.config.ts`, `package.json`, `package-lock.json`, `.env.example`, `.gitignore`, `README.md` |
| `deployment/` | `addresses.json`, `README.md`, `BSCSCAN_VERIFICATION.md`, `FGC42Forge_flat.sol`, `addresses.json.example` |
| `documentation/` | `README.md`, `STACK-GLOSSAIRE-ET-PARCOURS.md` |
**Template Hardhat (Counter)** : présent mais documenté comme hors périmètre dans `code/README.md` — acceptable ; ne pas présenter Counter en code review.
---
## Fichiers à **ne pas** committer
| Chemin | Raison |
|--------|--------|
| `code/.env` | Clé privée |
| `code/node_modules/`, `cache/`, `artifacts/` | Générés |
| `code/ignition/deployments/` | État local Ignition (gros `build-info`) — adresses dans `deployment/addresses.json` |
| `code/.agents/`, `code/AGENTS.md` | Assistants locaux, hors sujet |
| Tout `docs/` ou `pedagogie/` | Dépôt de travail perso uniquement |
`.gitignore` racine + `code/.gitignore` mis à jour en conséquence.
---
## Écarts mineurs (non bloquants)
| Point | Action |
|-------|--------|
| `code/scripts/send-op-tx.ts` | Script template Hardhat ; ignoré à l’oral ou supprimable si tu veux un tree plus minimal |
| Tests non relancés dans cet audit (lock compilateur sandbox) | Sur ta machine : `cd code && npx hardhat test` |
| Vidéo démo | Section vide dans README — conforme (optionnel) |
---
## Liens internes rendu
Aucun lien vers `docs/pedagogie` ou dépôt parent. Liens `../deployment`, `../code` : **OK** (dans le même repo école).
## Autonomie fonctionnelle (vérification doc)
| Parcours | Suffisant dans `tokenizerRendu/` seul ? |
|----------|----------------------------------------|
| Utiliser FG42 (MetaMask + BscScan) | ✅ `documentation/README.md` |
| Comprendre stack / commandes / alternatives | ✅ `documentation/STACK-GLOSSAIRE-ET-PARCOURS.md` |
| Tests Hardhat | ✅ README racine + `code/README.md` → `cd code` + `npm install` + test |
| Token on-chain sans redeploy | ✅ adresse dans README + `deployment/addresses.json` |
| Redeploy optionnel | ✅ `deployment/README.md` + `.env.example` |
---
## Procédure Git — Vogosphere
### Option A — Dépôt **uniquement** rendu (recommandé)
Sur le PC où tu pousses vers l’intranet 42 :
```bash
cd /chemin/vers/tokenizerRendu
git init
git add README.md .gitignore code deployment documentation
git status # vérifier : pas de .env, pas de node_modules
git commit -m "Tokenizer: FGC42Forge BSC testnet"
# remote Vogosphere fourni par l’école
git remote add origin <URL_VOGOSPHERE>
git push -u origin main
```
### Option B — Même machine, dépôt perso `tokenizer/` + sous-dossier rendu
- Ne **pas** pousser la racine `tokenizer/` si elle contient `docs/`.
- Soit **Option A** dans `tokenizerRendu/`, soit branche `rendu` qui ne contient que le contenu de `tokenizerRendu/` (subtree / copie propre).
### Avant chaque push
```bash
cd code
grep -r "PRIVATE_KEY" .env 2>/dev/null && echo "STOP: .env présent" || true
git status
```
---
## Après push
1. [checklist-demo-evaluation.md](checklist-demo-evaluation.md)
2. [fiche-soutenance-tokenizer.md](fiche-soutenance-tokenizer.md) §10 (démo + oral ch. III)

68
docs/pedagogie/checklist-demo-evaluation.md
View File

@@ -1,68 +0,0 @@
# Checklist — démo et correction Tokenizer
> **Dépôt de travail** (`docs/`) — ne pas confondre avec `tokenizerRendu/` (Vogosphere).
> À utiliser **avant** la soutenance : tout doit fonctionner sans improviser.
**Références rendu :** adresse et vérif → [`tokenizerRendu/deployment/addresses.json`](../../tokenizerRendu/deployment/addresses.json) · [`BSCSCAN_VERIFICATION.md`](../../tokenizerRendu/deployment/BSCSCAN_VERIFICATION.md) · doc utilisateur → [`tokenizerRendu/documentation/README.md`](../../tokenizerRendu/documentation/README.md)
---
## A. Matériel prêt (la veille)
| # | Action | Fait |
|---|--------|------|
| A1 | MetaMask : réseau **BNB Smart Chain Testnet** (chainId **97**) | ☐ |
| A2 | Compte **FGC_account** : tBNB (gas) + solde **FG42** (token importé) | ☐ |
| A3 | Compte **demo_account** (ou 2ᵉ compte) : token FG42 importé (`0x0c76…0fF4`) | ☐ |
| A4 | Onglets navigateur : [contrat #code](https://testnet.bscscan.com/address/0x0c76df26A1149fDc22C8f994975705271b070fF4#code) · [token](https://testnet.bscscan.com/token/0x0c76df26A1149fDc22C8f994975705271b070fF4) · README rendu local | ☐ |
| A5 | `cd tokenizerRendu/code && npx hardhat test mocha --grep FGC42Forge` → **2 passing** | ☐ |
| A6 | Aucune clé privée à l’écran / dans le dépôt Git | ☐ |
---
## B. Déroulé suggéré (5–10 min)
| Étape | Tu montres | Tu dis (idée) |
|-------|------------|----------------|
| **B1** | `tokenizerRendu/README.md` | Token **FGC42Forge / FG42**, BSC testnet, adresse, lien doc utilisateur |
| **B2** | BscScan **token** : supply **1M**, transfers | Jeton **BEP-20** ; supply fixe au deploy |
| **B3** | BscScan **Contract** (vérifié) | Source = dépôt ; fiche [`BSCSCAN_VERIFICATION.md`](../../tokenizerRendu/deployment/BSCSCAN_VERIFICATION.md) si questions compilateur |
| **B4** | MetaMask **FGC_account** → transfer **100 FG42** → **demo_account** | `transfer` ERC-20 ; gas en **tBNB** |
| **B5** | BscScan transfers + solde **demo_account** | Preuve on-chain |
| **B6** | `documentation/README.md` | Un évaluateur peut importer le token et transférer sans ton aide |
| **B7** | `code/contracts/FGC42Forge.sol` (commenté) | OpenZeppelin **ERC20 + Ownable** ; supply fixe ; index : `code/README.md` § relecture |
| **B8** | (Optionnel) `npx hardhat test` | Tests automatisés avant deploy |
---
## C. Questions fréquentes — réponses courtes
| Question | Réponse |
|----------|---------|
| ERC-20 ou BEP-20 ? | **BEP-20** sur BSC ; code **OpenZeppelin ERC20** (même interface EVM). |
| Peut-on mint encore des FG42 ? | **Non** : pas de fonction `mint` publique ; supply **1 000 000** au deploy. |
| Rôle de `owner` ? | Admin **Ownable** ; pas de création de jetons dans ce contrat. |
| Pourquoi BSC testnet ? | Partenaire sujet, tBNB, BscScan ; pas d’argent réel. |
| Pourquoi Hardhat ? | Compile, tests, deploy reproductible (`deployment/`, Ignition). |
---
## D. Bonus multisig
| # | Action | Fait |
|---|--------|------|
| D1 | Partie **obligatoire** parfaite avant de présenter le bonus | ☐ |
| D2 | Savoir **où** est le code bonus et **comment** le tester (à remplir si implémenté) | ☐ |
---
## E. Après la session
| # | Action |
|---|--------|
| E1 | Noter questions de l’éval pour améliorer README / doc si besoin |
| E2 | Vérifier que le dépôt Vogosphere (`tokenizerRendu/`) est à jour avant push final |
---
*Dernière mise à jour : 2026-10-20 — adresse contrat FGC42Forge testnet.*

130
docs/pedagogie/decisions-projet.md
View File

@@ -1,130 +0,0 @@
# Décisions projet — suivi (dépôt de travail)
> Fichier **pédagogique** (`docs/`) — pas le rendu Vogosphere. Le README école (`tokenizerRendu/README.md`) reprendra une version **validée** à l’étape 5.
> **Identité choisie :** token autour des initiales **FGC** + contrainte sujet **`42`**.
## Identité du token (FGC)
| Élément | Choix | Pourquoi c’est « original » |
|---------|--------|-----------------------------|
| **Initiales** | **F · G · C** | Signature personnelle du projet (auteur / porteur du dépôt) |
| **42** | Dans le **nom on-chain** | Exigence obligatoire du sujet ([ch. IV](../sujets/tokenizer.md#contraintes-sur-le-token)) |
| **Métaphore** | **Forge** (*forge*) | Évoquer la **création** du jeton sur la chaîne (comme forger une pièce) — lien avec l’intro du sujet (« create your own token ») |
| **Nom affiché** | **FGC42Forge** | Lecture : *FGC* + *42* + *Forge* — unique, mémorable en soutenance |
| **Ticker** | **FG42** | **F**GC + **42** en 4 caractères (lisible sur BscScan et dans MetaMask) |
*Variantes si tu veux ajuster avant étape 2 :* `ForgeFGC42` / symbole `F42G` — dis-moi dans le chat.
---
## Métadonnées
| Champ | Valeur | Concept | Référence |
|-------|--------|---------|-----------|
| **Date** | 2026-10-19 | Date de gel des décisions de cadrage (reprise projet). | [00-reprise-et-etat.md](00-reprise-et-etat.md) |
| **Étape** | **Obligatoire terminée** (2026-10-20) | Deploy `0x0c76…0fF4` · doc · vérif BscScan · bonus non retenu | [parcours](parcours-etape-par-etape.md) |
| **Auteur / initiales** | FGC | Contexte perso du nom du token (pas une exigence du PDF). | — |
---
## Chaîne et standard
| Champ | Valeur | Concept | Référence |
|-------|--------|---------|-----------|
| **Réseau** | BNB Smart Chain **Testnet** | Blockchain **publique** de test : même logique que la prod BSC, **sans valeur réelle** pour le gas. | Sujet ch. I (faucet tBNB) · ch. IV (« test chains », pas d’argent réel) |
| **Chain ID** | `97` | Identifiant numérique unique du réseau ; MetaMask et Hardhat l’utilisent pour ne pas envoyer une tx sur le mauvais réseau. | [02-web3 § 10.3](02-web3-comprendre.md#103-noms-que-tu-peux-croiser-glossaire) |
| **Standard token** | **BEP-20** | Norme des tokens **fongibles** sur BNB Chain (équivalent **ERC-20** sur Ethereum). | [Sujet ERC-20 / BEP-20](../sujets/tokenizer.md#erc-20-et-bep-20-éclaircissement) · [02-web3 § 6](02-web3-comprendre.md#6-standards-erc-20-et-bep-20) |
| **Consensus (info)** | **PoSA** (réseau) | Tu ne le configures pas ; BSC valide les blocs via validateurs + stake. Distinct du **multisig** (bonus). | [02-web3 § 6.6](02-web3-comprendre.md#66-consensus-de-la-chaîne-pow-pos-poa-et-variantes) |
| **Explorateur** | https://testnet.bscscan.com | Preuve du déploiement : adresse contrat, **ticker**, transfers. | Sujet ch. IV (explorer, adresse + réseau dans Git) |
| **RPC** | `https://data-seed-prebsc-1-s1.binance.org:8545/` | URL d’accès à un nœud : Hardhat / MetaMask envoient les transactions **via** ce point. | [02-web3 § 3.9](02-web3-comprendre.md#39-réseau-rpc) |
| **Monnaie gas** | **tBNB** | Frais de transaction sur testnet ; obtenu via **faucet**, pas d’achat. | Sujet ch. I · [BNB / Binance](../sujets/tokenizer.md#bnb-binance-et-bnb-chain) |
---
## Token — FGC42Forge (sujet : `42` dans le nom)
| Champ | Valeur | Concept | Référence |
|-------|--------|---------|-----------|
| **Nom** (`name`) | `FGC42Forge` | Chaîne de caractères **longue** affichée dans les wallets (ex. « FGC42Forge »). Doit contenir **`42`**. | Sujet ch. IV (nom libre + `42`, pas d’insultes) |
| **Symbole** (`symbol`) | `FG42` | **Ticker** court (symbole boursier du jeton) ; lié **FGC** + **42**. | Sujet ch. IV (ticker sur explorer après deploy) |
| **Décimales** (`decimals`) | `18` | Nombre de chiffres après la virgule **en interne** ; `1 FG42` = `1 × 10^18` unités minimales. Convention quasi universelle ERC-20. | [02-web3 § 6.2](02-web3-comprendre.md#62-que-impose-le-standard-) |
| **Supply initiale** | `1 000 000` **FG42** | **Offre totale** créée au lancement (`totalSupply`). Montant rond pour démos (`transfer` de 100, 1000…). | [02-web3 § 7.2 supply](02-web3-comprendre.md#supply-offre-quantité-en-circulation) |
| **Supply en contrat** | `1000000 * 10^18` wei | Solidity stocke les montants en **plus petite unité** (comme les « wei » pour l’ETH). | Implémentation ERC-20 (étape 3) |
| **Mint après deploy** | **Non** | Pas de fonction `mint` publique : **personne** ne peut créer de nouveaux FG42 après le deploy → pas de **mint illimité**. | [02-web3 § 7.1](02-web3-comprendre.md#71-mint-et-mint-illimité) |
| **Création initiale** | `_mint(déployeur, supply)` au **constructeur** | Toute la supply est forgée **une fois** à l’adresse qui déploie le contrat. | Pattern ERC-20 OpenZeppelin |
| **Owner** | `Ownable` (OpenZeppelin) | Une adresse **admin** du contrat (`owner()`), distincte du symbole FG42. | Sujet ch. IV (ownership, privilèges) · [02-web3 § 7.2 owner](02-web3-comprendre.md#owner-propriétaire-du-contrat) |
| **Privilèges owner** | `transferOwnership` / `renounceOwnership` | **Pas de mint** : en soutenance tu expliques que l’admin ne peut pas diluer la supply, seulement transférer le rôle admin. | Sujet ch. IV (sécurité, démo minimale) |
| **Fichier contrat prévu** | `FGC42Forge.sol` | Nom de fichier explicite pour la **code review**. | Sujet ch. IV (`code/`, noms lisibles) |
### ERC-20 dans le code, BEP-20 à l’évaluation (mémo soutenance)
| Question | Réponse courte |
|----------|----------------|
| Le sujet cite **ERC-20** ? | Oui, comme norme **générique** EVM ; sur **BSC** le sujet attend le standard de la chaîne : **BEP-20**. |
| Pourquoi `import ERC20` et pas `BEP20` ? | OpenZeppelin (et la quasi-totalité des projets BSC) utilisent le contrat **`ERC20`** ; l’interface est la même. |
| Qu’est-ce qui fait « BEP-20 » ? | Le **déploiement sur BNB Chain** (testnet 97) + respect de l’interface (`transfer`, `balanceOf`, etc.) ; **BscScan** qualifie le contrat en **BEP-20**. |
| Phrase à dire le jour J | *« Mon token est **BEP-20** sur BSC Testnet ; le Solidity hérite d’**OpenZeppelin ERC20**, l’équivalent ERC-20 sur cette chaîne. »* |
Réf. : [sujet § ERC-20 / BEP-20](../sujets/tokenizer.md#erc-20-et-bep-20-éclaircissement) · [02-web3 § 6](02-web3-comprendre.md#6-standards-erc-20-et-bep-20)
### Lore / justification (pour `documentation/` et whitepaper léger)
| Aspect | Texte proposé |
|--------|----------------|
| **Univers** | *FGC42Forge* est un jeton **fictif** de test : chaque **FG42** représente une « étincelle » de participation à un atelier Web3 42 — forgée une seule fois sur BSC Testnet. |
| **FGC** | Initiales du créateur ; ancrage personnel du projet (comme une signature). |
| **42** | Rappel de l’école et contrainte du sujet. |
| **Forge** | Métaphore de la **création on-chain** (deploy = acte de forge). |
| **Valeur** | **Aucune** valeur monétaire réelle ; testnet uniquement. |
| **Public cible** | Évaluateur / pairs : comprendre BEP-20, transfers, explorer. |
---
## Stack technique (prévue)
| Outil | Choix | Concept | Référence |
|-------|--------|---------|-----------|
| **Langage** | Solidity | Langage des smart contracts **EVM** (BSC). | Sujet ch. IV (langage de la plateforme) |
| **Toolchain** | Hardhat | Compile, tests locaux, scripts de deploy → dossiers **`code/`** et **`deployment/`**. | Sujet ch. IV (Truffle, Remix, **Hardhat** cités) |
| **OpenZeppelin** | `ERC20` + `Ownable` | Bibliothèque auditée ; **BEP-20** en pratique via ERC20 sur BSC. | [02-web3 § 6](02-web3-comprendre.md#6-standards-erc-20-et-bep-20) |
| **Tests** | Hardhat + (chai/ethers) | Vérifier `transfer`, supply, droits **avant** testnet public. | Bonne pratique + soutenance |
| **Secrets** | `.env` + `PRIVATE_KEY` | Clé du compte **test** pour signer le deploy ; **jamais** dans Git. | `.gitignore` rendu · sujet (sécurité implicite) |
| **IDE** | Cursor / VS Code | Édition + doc ; Remix optionnel pour un test rapide. | Sujet ch. IV (IDE) |
---
## Wallet de test (public uniquement)
| Champ | Valeur | Concept | Référence |
|-------|--------|---------|-----------|
| **Compte MetaMask** | `FGC_account` | Compte Chrome dédié au projet (même adresse `0x…` sur tous réseaux EVM). | [Marche à suivre étape 1](etapes/etape-01-cadrage-wallet-testnet.md#marche-à-suivre-metamask-chrome--faucet-tbnb) |
| **Adresse publique** | `0xB6bE1878BfaF1FFC8503E752b1D733Ad7b93603c` | Compte **FGC_account** — adresse **publique** (OK en doc ; ne jamais y associer seed / clé privée). | [02-web3 § 3.5 wallet](02-web3-comprendre.md#35-wallet-portefeuille) |
| **tBNB (faucet)** | **Oui** — **0,1 tBNB** (2026-10-20, Telegram @bnbchain_official_bot) | Suffisant pour deploy + démos (sujet testnet). Tx : [testnet.bscscan.com/tx/0x7ca577…bb2ee](https://testnet.bscscan.com/tx/0x7ca57757494000b98b83e82563cb59932fad2fb329c7948974825e9312cbb2ee) | [faucets doc](https://docs.bnbchain.org/bnb-smart-chain/developers/faucet/) |
| **Compte dédié** | `FGC_account` | Pas de fonds mainnet sur ce compte si possible. | Sujet ch. IV (pas d’argent réel) |
**Procédure complète (MetaMask + réseau 97 + faucet)** → [etape-01 — section détaillée](etapes/etape-01-cadrage-wallet-testnet.md#marche-à-suivre-metamask-chrome--faucet-tbnb).
### Paramètres MetaMask — BSC Testnet (config validée FGC)
| Paramètre | Valeur | Concept |
|-----------|--------|---------|
| Nom | **`BNB Smart Chain Testnet`** (sans faute / sans espaces en trop) | Un nom ou RPC mal saisi peut déclencher l’avertissement « arnaque » même avec de vrais tBNB. |
| RPC URL | `https://data-seed-prebsc-1-s1.binance.org:8545/` ou `https://bsc-testnet-dataseed.bnbchain.org` | Les deux sont utilisés par la doc BNB / bot Telegram. |
| Chain ID | `97` | Doit correspondre à Hardhat `networks.bscTestnet` |
| Symbole | **`tBNB`** | OK une fois le réseau corrigé — solde **0,1 tBNB**, **sans** avertissement MetaMask (oct. 2026). |
| Explorer | https://testnet.bscscan.com | Tx faucet : `0x7ca577…bb2ee` |
| Compte | **FGC_account** | `0xB6bE1878BfaF1FFC8503E752b1D733Ad7b93603c` |
---
## Prochaines étapes (rappel parcours)
| # | Action |
|---|--------|
| 1 | Compléter **adresse** + **tBNB** ci-dessus → demander vérification étape 1 |
| 2 | Init Hardhat dans `tokenizerRendu/code/` (nom package aligné sur FGC42Forge) |
| 3 | Écrire `FGC42Forge.sol` selon ce tableau |
---
**Ne pas écrire ici :** clé privée, seed phrase, contenu complet de `.env`.

231
docs/pedagogie/etapes/etape-01-cadrage-wallet-testnet.md
View File

@@ -1,231 +0,0 @@
# Étape 1 — Cadrage + wallet testnet (tBNB)
> **Sujet (chapitre IV) :** choisir une blockchain ; nom du token avec **`42`** ; **pas d’argent réel** — test chains + faucet (chapitre I).
> **Pas encore de code** dans `tokenizerRendu/code/` — uniquement des **décisions** documentées côté travail.
---
## Ce que le sujet exige à ce stade
| Exigence PDF | Action étape 1 |
|--------------|----------------|
| Plateforme blockchain | Choisir et noter : **BNB Smart Chain Testnet** (recommandé partenariat BNB) |
| Nom avec `42`, pas d’insultes | Choisir **nom** + **symbole** (ticker) |
| Standard de la chaîne | Noter : **BEP-20** (équivalent ERC-20 sur BSC) |
| Pas de vrai argent | Wallet **dédié test** + **tBNB** via faucet uniquement |
| README choix (plus tard) | Préparer les décisions ici ; README école à l’étape 5 |
---
## À faire (checklist)
### A. Décisions produit (à écrire dans [decisions-projet.md](../decisions-projet.md))
- [x] **Nom** / **symbole** validés : **`FGC42Forge`** / **`FG42`** (voir [decisions-projet.md](../decisions-projet.md))
- [ ] Compléter le reste des tableaux si pas déjà fait
- [ ] **Décimales** (souvent `18` — standard ERC-20)
- [ ] **Supply** : fixe au deploy **ou** mint réservé au owner (justifier en une phrase)
- [ ] **Chaîne** : BSC Testnet, **chainId `97`**
- [ ] **Stack prévue** : Solidity + Hardhat + OpenZeppelin (pour étape 2+)
### B. Wallet de test — voir [marche à suivre détaillée](#marche-à-suivre-metamask-chrome--faucet-tbnb) ci-dessous
### C. Faucet tBNB — idem section détaillée
### D. Sécurité (dès maintenant)
- [ ] Ne **pas** committer `.env` ni clé privée (`.gitignore` rendu déjà prévu)
- [ ] Ne pas partager la **seed phrase** dans le chat 42 / Discord / Git
---
## Pourquoi on ne « crée » pas le tBNB soi-même
| Question | Réponse |
|----------|---------|
| Peut-on **générer** du tBNB comme on écrira **FGC42Forge** plus tard ? | **Non** sur le **testnet public** : le **tBNB** est la **monnaie native** de la chaîne (gas). Seuls le **réseau** (validateurs) et les **faucets** officiels / communautaires en **envoient** à ton adresse `0x…`. |
| Et en local (Hardhat) ? | Sur une chaîne **locale** (`npx hardhat node`), Hardhat te donne des ETH de test **fictifs** — utile pour coder (étape 2–3), mais le **sujet 42** exige aussi un déploiement sur une **blockchain publique** + explorer ([ch. IV](../../sujets/tokenizer.md#déploiement-2ᵉ-dossier)). Il faudra donc du **vrai testnet** tBNB à un moment. |
| Pourquoi Discord / Telegram ? | Ce ne sont pas des « contournements » : la [doc officielle BNB](https://docs.bnbchain.org/bnb-smart-chain/developers/faucet/) liste **faucet web**, **Discord**, **Telegram** et faucets tiers. Quand le site [bnbchain.org testnet-faucet](https://www.bnbchain.org/en/testnet-faucet) demande **0,002 BNB mainnet**, les autres canaux restent la voie normale. |
| Exemple projet 42 | [BdClement/Tokenizer](https://github.com/BdClement/Tokenizer) (BEP-20, BSC Testnet 97) : *« I obtained tBNB via a faucet available on the **BNB Discord server** »* + deploy Truffle / Alchemy RPC. |
Le sujet PDF (ch. I) renvoie au **BNB Chain Faucet** : en 2025–2026 l’écosystème a **resserré** les faucets web (mainnet ou réserves vides). **Demander des tBNB** = étape d’intégration Web3 réaliste, pas une erreur de parcours.
---
## Marche à suivre MetaMask (Chrome) + faucet tBNB
> Retour d’expérience projet FGC — compte **`FGC_account`**, réseau **testnet 97**, faucet **BNB 0,3**.
### 1. Installer et créer le compte
| Étape | Action |
|-------|--------|
| 1 | Installer l’extension [MetaMask](https://metamask.io) depuis le **Chrome Web Store** (site officiel uniquement). |
| 2 | **Créer un wallet** avec un **mot de passe** (déverrouille l’extension sur ce PC). |
| 3 | **Sauvegarder la seed phrase** (12 mots) : Paramètres → Sécurité → **Révéler la phrase secrète de récupération** — noter sur papier, **jamais** Git / chat / `.env`. |
| 4 | Renommer le compte (optionnel) : ex. **`FGC_account`** — un compte dédié au projet Tokenizer. |
### 2. Comprendre réseau vs adresse
| Idée | Détail |
|------|--------|
| Menu du haut MetaMask | Liste de **réseaux** (Ethereum, BNB Chain, …), pas une « adresse BNB » différente par chaîne. |
| Même compte EVM | **`FGC_account`** a **une** adresse publique `0x…` sur Ethereum, BSC testnet, etc. |
| **BNB Chain** (sans « Testnet ») | Souvent le **mainnet** (chainId **56**) → **ne pas** utiliser pour ce projet. |
| **BNB Smart Chain Testnet** | chainId **97** → réseau du sujet + **tBNB**. |
### 3. Ajouter BNB Smart Chain Testnet (souvent absent par défaut)
**Méthode manuelle**
1. MetaMask → clic sur le **nom du réseau** en haut.
2. **Ajouter un réseau** → si besoin **Ajouter un réseau manuellement**.
3. Remplir :
| Champ | Valeur |
|-------|--------|
| Nom du réseau | `BNB Smart Chain Testnet` |
| URL RPC | `https://data-seed-prebsc-1-s1.binance.org:8545/` |
| ID de chaîne | `97` |
| Symbole | **`BNB`** (évite l’avertissement MetaMask) ou `tBNB` |
| Explorateur | `https://testnet.bscscan.com` |
4. Enregistrer → **basculer** sur ce réseau.
**Alternative :** [chainlist.org](https://chainlist.org) → activer **Include Testnets** → chercher BSC Testnet (97) → Add to MetaMask.
### 4. Copier l’adresse dans MetaMask (étape A)
1. Réseau sélectionné : **BNB Smart Chain Testnet** (en haut de l’extension).
2. Compte : **FGC_account**.
3. Sous le nom du compte tu vois une ligne du type **`0x1a2b…9f0c`** (tronquée).
4. Clique cette ligne **ou** les **trois points** → **Détails du compte** → bouton **Copier** / icône copier à côté de l’adresse.
5. Tu dois obtenir **une seule chaîne** : `0x` + **40** caractères (0–9, a–f) — **pas** d’espaces, **pas** de retour à la ligne.
**Ce n’est pas :** la seed (12 mots), la clé privée, le mot de passe MetaMask, l’URL RPC, le chainId `97`.
### 4 bis. Où coller l’adresse — et où **ne pas** la coller
```
MetaMask (FGC_account) ──copier 0x…──► SITE WEB du faucet ──► ton compte reçoit tBNB
│
└── PAS dans MetaMask "Ajouter réseau" (sauf URL RPC officielle, pas ton 0x)
```
| Endroit | Coller ton `0x…` ? | Pourquoi |
|---------|-------------------|----------|
| **Site faucet** — champ « Wallet address » / « Enter your address » | ✅ **OUI** | C’est **ici** que le site envoie les tBNB. |
| **Site faucet** — bouton « Connect wallet » | ✅ **OUI** (alternative) | MetaMask remplit l’adresse tout seul — souvent plus simple. |
| MetaMask → Ajouter réseau → **URL RPC** | ❌ **NON** | On met l’URL `https://data-seed-prebsc-1-s1…`, **pas** ton adresse. |
| MetaMask → Ajouter réseau → **Chain ID** | ❌ **NON** | On met `97`, pas `0x…`. |
| Fichier `.env` à l’étape 1 | ❌ **pas obligatoire** | Plus tard : **clé privée** (autre format), pas l’adresse seule pour Hardhat. |
| [decisions-projet.md](../decisions-projet.md) | ✅ **OUI** (suivi perso) | Pour documenter ton étape 1. |
| Barre de recherche **testnet.bscscan.com** | ✅ (pour **vérifier**) | Pas pour recevoir des tBNB — seulement pour voir ton solde. |
### 5. Faucet — QuickNode (recommandé si erreur mainnet)
1. Ouvre **dans Chrome** (pas dans MetaMask) : https://faucet.quicknode.com/binance-smart-chain/bnb-testnet
2. Vérifie que la page indique **Binance Smart Chain** + **Testnet** (pas Mainnet).
3. **Option 1 — la plus simple :** bouton **Connect wallet** → choisis **MetaMask** → compte **FGC_account** → autorise.
4. **Option 2 :** champ du type **« Drop in your wallet details »** / adresse → **colle** le `0x…` copié à l’étape 4.
5. Passe captcha / Continue → confirme la demande.
6. **Ne colle pas** l’adresse dans un menu déroulant « Token » (BNB/BTC) : le token **BNB** est ce qu’on **reçoit**, pas un champ d’adresse.
### 5 bis. Faucet officiel BNB (si tu l’utilises malgré tout)
1. Ouvrir [BNB Chain Testnet Faucet](https://www.bnbchain.org/en/testnet-faucet).
2. Grand champ **adresse du wallet** (souvent au centre) → **colle `0x…`**.
3. Ensuite seulement : choisir token **BNB** et montant **0,3** → bouton **Request** / **Send**.
- **Token : BNB** (sur testnet = **tBNB**, pas de valeur réelle).
- **Montant : 0,3 BNB** — suffisant pour deploy + démos.
- **Ne pas** choisir BTC / autres tokens pour ce projet (inutiles sur BSC testnet).
4. Valider (captcha / connexion si demandé).
5. Attendre 1–5 min → MetaMask sur réseau **Testnet** : solde **tBNB** ≈ 0,3.
6. Noter dans `decisions-projet.md` : **tBNB reçu : oui** + date.
### 6. Dépannage rapide
| Problème | Piste |
|----------|--------|
| Pas de « Testnet » dans la liste | Ajout **manuel** (§ 3), pas seulement « BNB Chain ». |
| Faucet OK mais solde 0 | Mauvais réseau sélectionné dans MetaMask (revenir à **97**). |
| Adresse invalide sur BscScan | Re-copier l’adresse sans espace. |
| Limite faucet | Réessayer plus tard (souvent 1× / 24 h). |
| **« less than 0.002 BNB on BSC Mainnet »** | Le [faucet BNB officiel](https://www.bnbchain.org/en/testnet-faucet) exige parfois un peu de **BNB mainnet** sur la même adresse — **inutile d’acheter** pour le sujet 42 (pas d’argent réel). Utiliser un **faucet alternatif** (§ 7). |
| **QuickNode : « Low balance for this chain and network »** + **Continue** grisé | Souvent le **faucet QuickNode est à sec** (plus de tBNB côté serveur), **pas** que tu as mal connecté MetaMask. Réessayer plus tard ou utiliser **Discord / Telegram** (§ 7 bis). |
### 7. Faucets alternatifs (sans BNB mainnet)
Aligné sujet : **testnet uniquement**, pas d’achat de BNB réel.
| Faucet | URL | Remarque |
|--------|-----|----------|
| **QuickNode** (recommandé) | https://faucet.quicknode.com/binance-smart-chain/bnb-testnet | Réseau **Testnet**, coller `0x…` ou connecter MetaMask ; pas de solde mainnet requis (cooldown ~12 h). |
| **Bot Telegram BNB Chain** | [@bnbchain_official_bot](https://t.me/bnbchain_official_bot) | Message du type : `I would like to get tBNB to my wallet 0x…` — voir [doc officielle](https://docs.bnbchain.org/bnb-smart-chain/developers/faucet/). |
| **Discord BNB Chain** | Serveur officiel (ticket support) | Même idée que Telegram — doc ci-dessus. |
| Chainstack | https://faucet.chainstack.com/bnb-testnet-faucet | **Évite** si tu n’as pas **0,002 ETH mainnet** (même type de blocage). |
Après toute source : vérifier le solde **tBNB** sur MetaMask (réseau **97**) et sur https://testnet.bscscan.com.
### 7 bis. Discord BNB Chain (si QuickNode + officiel bloqués)
Souvent le moyen le plus fiable quand les faucets web sont vides ou demandent du mainnet :
1. Rejoindre le **Discord officiel** BNB Chain (lien depuis [bnbchain.org](https://www.bnbchain.org/) ou [doc faucet](https://docs.bnbchain.org/bnb-smart-chain/developers/faucet/)).
2. Canal **#roles** → prendre le rôle **Developer** (ou les rôles proposés) pour voir **#testnet-faucet**.
3. Dans **#testnet-faucet** : commande **`/faucet`** → coller ton adresse `0x…` (compte **FGC_account**).
4. Limite typique : ~0,3 tBNB / jour.
**Telegram :** [@bnbchain_official_bot](https://t.me/bnbchain_official_bot) — message : `I would like to get tBNB to my wallet 0x…`
### 8 bis. Avertissement MetaMask « symbole du jeton natif » (tBNB vs BNB)
**Symptôme :** icône ⚠️ *« Il pourrait s’agir d’une arnaque »* — *vous avez saisi **tBNB** alors que le symbole attendu…*
| Cause | Ce n’est en général **pas** une arnaque si : |
|-------|---------------------------------------------|
| Tu as ajouté le réseau **manuellement** avec symbole **tBNB** | MetaMask compare au **registre** des chaînes (chainId **97** = symbole officiel souvent **BNB**, pas `tBNB`). |
| Ta tx BscScan est **Success** sur **Bsc Testnet** | Comme ta capture : 0,1 **BNB** reçu de `0xF2D4…` → `0xB6bE…` — c’est le **bon** testnet. |
**Correction (retour d’expérience FGC) :**
1. Vérifier le **nom exact** du réseau : **`BNB Smart Chain Testnet`** (pas de faute, pas d’espaces parasites dans RPC / chainId).
2. Chain ID **`97`**, explorer **testnet.bscscan.com**.
3. Symbole **`tBNB`** ou **`BNB`** selon ce que MetaMask accepte sans ⚠️ — les deux désignent le gas testnet.
4. Le solde (ex. **0,1 tBNB**) ne change pas après correction du réseau.
**À ne pas faire :** supprimer le réseau en paniquant ; **ne pas** « ignorer » des tx inconnues — ici tu as **vérifié** le hash sur testnet.bscscan.com.
### 9. BNB ou tBNB sur l’écran du faucet ?
Sur le **testnet**, quand le faucet affiche **« BNB »**, tu reçois bien du **tBNB** (gas de test). MetaMask peut l’afficher en **tBNB** une fois le réseau **Testnet (97)** sélectionné. Pas besoin d’une ligne « tBNB » séparée sur le site.
### 10. Fichier `.env` (pas à l’étape 1 obligatoire)
| Emplacement | Usage |
|-------------|--------|
| `tokenizer/.env` à la racine | Éviter d’y mettre la **seed** ; racine déjà dans `.gitignore`. |
| `tokenizerRendu/code/.env` | **Étape 2+** : `PRIVATE_KEY` du compte **test** pour Hardhat uniquement. |
**Ne jamais committer** `.env`. La clé privée (MetaMask → Détails du compte → Afficher la clé privée) = compte test seulement, plus tard pour deploy.
---
## Livrable pour demander la vérification
Quand tout est fait, envoie dans le chat :
1. « Étape 1 terminée »
2. Le **nom** et **symbole** du token
3. Confirmation : **tBNB** visible (sans donner ta clé privée)
4. *(Optionnel)* les 4 premiers caractères de ton adresse publique pour qu’on vérifie que `decisions-projet.md` est cohérent
L’assistant lira [decisions-projet.md](../decisions-projet.md) et validera avant l’**étape 2** (projet Hardhat dans `tokenizerRendu/code/`).
---
## Références
- [Sujet — partie obligatoire](../../sujets/tokenizer.md#chapitre-iv--partie-obligatoire)
- [BNB / faucet](../../sujets/tokenizer.md#faucet-testnet)
- [BEP-20 / ERC-20](../../sujets/tokenizer.md#erc-20-et-bep-20-éclaircissement)

316
docs/pedagogie/etapes/etape-02-init-hardhat.md
View File

@@ -1,316 +0,0 @@
# Étape 2 — Initialiser Hardhat dans `tokenizerRendu/code/`
> **Sujet (ch. IV) :** dossier **`code/`** à la racine du dépôt école ; maîtriser la toolchain (Hardhat cité) ; code commenté plus tard (étape 3).
> **Prérequis :** étape 1 ✅ (réseau BSC Testnet 97, tBNB sur **FGC_account**).
> **Lire d’abord (recommandé) :** [Hardhat et alternatives](../03-hardhat-et-alternatives.md) · [Ressources Solidity / Hardhat](../ressources-solidity-hardhat.md) (§ 2 + § 8 plan minimum).
---
## Objectif (en une phrase)
Tu installes sur ta machine une **chaîne d’outils** (Node + Hardhat) qui va **compiler** du Solidity, **lancer des tests** et **déployer** sur BSC Testnet — sans écrire encore ton token **FGC42Forge** (étape 3).
### Rappel pédagogique : qui fait quoi ?
| Élément | Rôle |
|--------|------|
| **Solidity** | Langage des contrats (`FGC42Forge.sol`, plus tard). |
| **Hardhat** | Programme Node.js : compile, tests, scripts de déploiement. |
| **OpenZeppelin** | Bibliothèque de contrats éprouvés (`ERC20`, `Ownable`) — installée maintenant, utilisée à l’étape 3. |
| **`.env`** | Fichier local avec RPC + clé privée — lu par `hardhat.config.js`, **jamais** dans Git. |
---
## Vue d’ensemble des sous-étapes
1. **A** — Vérifier Node.js et se placer dans `tokenizerRendu/code/`
2. **B** — Créer `package.json` et installer Hardhat
3. **C** — Lancer `npx hardhat init` (assistant interactif)
4. **D** — Installer OpenZeppelin + `dotenv`
5. **E** — Configurer `hardhat.config.js` pour **BSC Testnet (chainId 97)**
6. **F** — Créer `.env` (secret) et `.env.example` (modèle pour le rendu)
7. **G** — `npx hardhat compile` (preuve que tout fonctionne)
8. **H** — Compléter `code/README.md`
Durée indicative : **30–45 min** la première fois (surtout la lecture des menus `hardhat init`).
---
## A. Environnement
### Où travailler ?
Le sujet demande le code dans **`tokenizerRendu/code/`** (dépôt de rendu), pas à la racine `tokenizer/` du dépôt de travail.
```bash
cd /home/fgras-ca/projets/42School/tokenizer/tokenizerRendu/code
pwd # doit finir par .../tokenizerRendu/code
```
### Node.js
```bash
node -v # idéalement ≥ 18 (ex. v20, v22)
npm -v
```
Si `node` est introuvable : installer [Node.js LTS](https://nodejs.org/) ou utiliser `nvm`.
**Checklist :**
- [ ] `node -v` OK
- [ ] Tu es dans `tokenizerRendu/code/`
---
## B. Créer le projet npm
`npm init -y` crée un **`package.json`** minimal : nom du projet, scripts, liste des dépendances.
```bash
npm init -y
```
Tu dois voir un fichier `package.json` apparaître dans `code/`.
Puis installer Hardhat et le **toolbox** (plugins officiels : tests, Ethers, etc.) :
```bash
npm install --save-dev hardhat @nomicfoundation/hardhat-toolbox
```
- `--save-dev` = outils de développement uniquement (pas besoin sur la blockchain).
- Première install : **téléchargement** depuis le registre npm → connexion Internet requise.
**Checklist :**
- [ ] `package.json` présent
- [ ] Dossier `node_modules/` créé (ignoré par Git via `.gitignore` parent)
---
## C. Assistant d’initialisation Hardhat
Tu as installé **Hardhat 3** (ex. `3.20.x` via `npm install hardhat`). À partir de la v3, la commande a changé :
```bash
npx hardhat --init
```
> **Erreur HHE3** avec `npx hardhat init` ? C’est normal : l’ancienne sous-commande `init` n’existe plus. Le message te dit d’utiliser **`--init`** (avec deux tirets).
Lance **`npx hardhat --init` dans ton terminal** (pas dans un environnement non interactif) : Hardhat affiche le logo et te pose des questions.
`npx` exécute le binaire Hardhat **sans** l’installer globalement.
### Variante (tutos Hardhat 2 uniquement)
Si tu veux coller aux vieux tutos (`hardhat init` + `hardhat.config.js` + `npx hardhat compile`), tu peux **épingler Hardhat 2** avant d’initialiser :
```bash
npm uninstall hardhat @nomicfoundation/hardhat-toolbox
npm install --save-dev hardhat@2.22.19 @nomicfoundation/hardhat-toolbox@5
npx hardhat init
```
Pour ce projet 42, **Hardhat 3 + `--init`** convient très bien ; on adaptera la config réseau BSC après l’assistant (souvent `hardhat.config.ts` + `npx hardhat build` au lieu de `compile`).
### Choix recommandés (JavaScript, plus simple pour ce projet)
Les libellés peuvent varier légèrement selon la version de Hardhat ; l’idée :
| Question | Choix conseillé | Pourquoi |
|----------|-----------------|----------|
| Type de projet | **Create a JavaScript project** | Moins de config TypeScript pour commencer |
| Emplacement du config | **Oui** / racine de `code/` | `hardhat.config.js` à côté de `package.json` |
| Projet vide ou exemple ? | **Oui, exemple** (Lock) | Tu vérifies compile + tests ; Lock supprimé à l’étape 3 |
| `.gitignore` dans `code/` ? | **Non** si déjà couvert par `tokenizerRendu/.gitignore` | Évite les doublons ; le parent ignore déjà `node_modules`, `cache`, `artifacts` |
### Arborescence typique après init
```
tokenizerRendu/code/
├── contracts/
│ └── Lock.sol # exemple — temporaire
├── test/
│ └── Lock.js # tests de l’exemple
├── scripts/
│ └── (deploy Lock, etc.)
├── hardhat.config.js
├── package.json
└── package-lock.json
```
**Checklist :**
- [ ] `hardhat.config.js` existe
- [ ] `contracts/Lock.sol` existe (pour l’instant)
---
## D. OpenZeppelin et dotenv
```bash
npm install @openzeppelin/contracts
npm install dotenv
```
- **OpenZeppelin** : tu n’importes rien encore ; c’est pour l’étape 3 (`import "@openzeppelin/contracts/..."`).
- **dotenv** : charge les variables du fichier `.env` dans `process.env` au lancement de Hardhat.
**Checklist :**
- [ ] Les deux paquets listés dans `package.json` → `dependencies` ou `devDependencies`
---
## E. Configurer BSC Testnet dans `hardhat.config.js`
Ouvre `hardhat.config.js` et remplace son contenu par (ou fusionne proprement si tu préfères) :
```javascript
require("@nomicfoundation/hardhat-toolbox");
require("dotenv").config();
/** @type import('hardhat/config').HardhatUserConfig */
module.exports = {
solidity: "0.8.24",
networks: {
bscTestnet: {
url: process.env.BSC_TESTNET_RPC || "https://data-seed-prebsc-1-s1.binance.org:8545/",
chainId: 97,
accounts: process.env.PRIVATE_KEY ? [process.env.PRIVATE_KEY] : [],
},
},
};
```
### Ce que signifient les lignes importantes
- **`solidity: "0.8.24"`** : version du compilateur pour tous les contrats (alignée avec OpenZeppelin récent).
- **`bscTestnet`** : nom **local** du réseau ; tu l’utiliseras plus tard avec `--network bscTestnet`.
- **`chainId: 97`** : identifiant officiel BNB Smart Chain **Testnet** (doit correspondre à MetaMask).
- **`accounts`** : si `PRIVATE_KEY` est vide, tableau vide → compile/tests locaux OK ; **déploiement** testnet nécessitera la clé (étape déploiement).
Tu ne déploies **pas** sur le testnet dans cette étape : tu prépares seulement la config.
**Checklist :**
- [ ] `require("dotenv").config();` présent
- [ ] `chainId: 97` présent
---
## F. Fichiers `.env` et `.env.example`
### Sécurité (à lire une fois pour toute la suite)
- La **clé privée** = contrôle total du compte → **compte de test uniquement** (FGC_account).
- **Ne jamais** : commit Git, capture d’écran publique, message Discord/chat avec la clé.
- Si tu as un `.env` à la racine `tokenizer/` (dépôt travail), le secret pour Hardhat doit vivre dans **`tokenizerRendu/code/.env`** (celui que lit `hardhat.config.js`).
### `tokenizerRendu/code/.env` (local, ignoré par Git)
Crée le fichier à la main :
```env
BSC_TESTNET_RPC=https://data-seed-prebsc-1-s1.binance.org:8545/
PRIVATE_KEY=0x................................................................
```
**Obtenir la clé (MetaMask)** : compte **FGC_account** → ⋮ → **Détails du compte** → **Afficher la clé privée** (mot de passe MetaMask) → copier **avec** le préfixe `0x`.
### `tokenizerRendu/code/.env.example` (à committer)
Même structure, **sans** vraie clé :
```env
BSC_TESTNET_RPC=https://data-seed-prebsc-1-s1.binance.org:8545/
PRIVATE_KEY=
```
Le `.gitignore` du rendu (`tokenizerRendu/.gitignore`) contient déjà `.env` et autorise `.env.example` via `!.env.example`.
**Checklist :**
- [ ] `.env` créé dans **`code/`** (pas seulement à la racine tokenizer)
- [ ] `.env.example` créé
- [ ] `git status` ne liste **pas** `.env` comme fichier à committer
---
## G. Vérifier la compilation
```bash
npx hardhat compile
```
### Sortie attendue (succès)
Quelque chose comme :
```
Compiled 1 Solidity file successfully (evm target: paris).
```
Des dossiers **`cache/`** et **`artifacts/`** apparaissent (déjà ignorés par Git).
### Tests optionnels (exemple Lock)
```bash
npx hardhat test
```
Si les tests passent, Hardhat + toolbox sont bien branchés. Ce n’est pas obligatoire pour valider l’étape 2, mais c’est rassurant.
### Dépannage rapide
| Problème | Piste |
|----------|--------|
| **HHE3** — `No Hardhat config` + « run with **--init** » | Utiliser `npx hardhat --init` (Hardhat 3), pas `npx hardhat init` |
| **HHE11** — pas de shell interactif | Lancer `--init` dans **ton** terminal Cursor / système |
| `Cannot find module '@nomicfoundation/hardhat-toolbox'` | Relancer `npm install` dans `code/` |
| Erreur Solidity / version | Vérifier `solidity` dans `hardhat.config.js` et la version en tête de `Lock.sol` |
| `PRIVATE_KEY` / invalid account | Normal si clé mal formatée ; **compile** ne nécessite pas la clé. Corriger avant déploiement. |
| Permission réseau npm | Vérifier proxy / réseau ; réessayer `npm install` |
**Checklist :**
- [ ] `npx hardhat compile` **sans erreur**
---
## H. Mettre à jour `code/README.md`
Ajoute une section courte (en français pour ton suivi ; README école final plus tard si besoin) :
- Prérequis : Node ≥ 18
- `cd code && npm install`
- Copier `.env.example` → `.env` et remplir `PRIVATE_KEY`
- `npx hardhat compile`
- Prochaine étape : contrat **FGC42Forge** (étape 3)
---
## Livrable pour vérification (dans le chat)
1. « Étape 2 terminée »
2. Copier **uniquement** la dernière ligne de succès de `npx hardhat compile` (pas de `.env`)
3. Confirmer : `.env.example` présent, `.env` **non** commité
**Ne pas envoyer** la clé privée.
---
## Après cette étape
- **Étape 3** : supprimer `Lock.sol`, ajouter `FGC42Forge.sol` (supply 1 000 000, pas de mint, `Ownable`), tests.
- **Déploiement testnet** : plus tard, avec `npx hardhat run scripts/... --network bscTestnet`.
---
## Références
- [decisions-projet.md](../decisions-projet.md) — FGC42Forge / FG42
- [guide-realisation.md](../guide-realisation.md) — étape 2
- Sujet : dossier `code/` — [tokenizer.md](../../sujets/tokenizer.md#code-)

75
docs/pedagogie/etapes/etape-04-deploy-testnet.md
View File

@@ -1,75 +0,0 @@
# Étape 4 — Déployer sur BSC Testnet + dossier `deployment/`
> **Prérequis :** étapes 1–3 ✅ (`FGC42Forge.sol`, tests Mocha OK, `bscTestnet` dans `hardhat.config.ts`, `.env` local).
> **Sujet :** déploiement sur **chaîne publique de test**, adresse + réseau dans le dépôt Git, explorer (BscScan).
---
## Objectif
Avoir le contrat **FGC42Forge** déployé sur **BNB Smart Chain Testnet** (chainId **97**), avec l’adresse documentée dans `tokenizerRendu/deployment/` et le README école.
---
## 4.1 — Module Ignition (déjà dans le repo)
Fichier : `tokenizerRendu/code/ignition/modules/FGC42Forge.ts`
Il déclare uniquement `m.contract("FGC42Forge")` : pas d’arguments, le constructeur Solidity fait le mint.
Vérifier la compile :
```bash
cd tokenizerRendu/code
npx hardhat build
```
---
## 4.2 — Lancer le déploiement (à faire **toi-même**)
```bash
cd tokenizerRendu/code
npx hardhat ignition deploy --network bscTestnet ignition/modules/FGC42Forge.ts
```
| Problème possible | Piste |
|-------------------|--------|
| `ENV_VAR_NOT_FOUND` / clé manquante | `code/.env` avec `PRIVATE_KEY` et `BSC_TESTNET_RPC` |
| `insufficient funds` | Recharger **tBNB** sur le compte deployer |
| Mauvais réseau | MetaMask pas requis ici ; Hardhat signe avec `PRIVATE_KEY` |
**Ne pas** coller la clé privée dans le chat.
---
## 4.3 — Enregistrer l’adresse
1. `cp deployment/addresses.json.example deployment/addresses.json`
2. Remplir `address`, `deployer`, `deployedAt`, `explorer` (URL BscScan).
3. Mettre à jour `tokenizerRendu/README.md` (table Token).
---
## 4.4 — Vérifier sur BscScan (sujet)
- Ouvrir l’adresse sur https://testnet.bscscan.com/
- Vérifier **nom / symbole** du token si l’explorer les affiche.
- Option **Verify and Publish** : publier le **code source** (fichier aplati ou standard JSON).
---
## Livrable pour vérification (chat)
1. « Étape 4 deploy OK »
2. Adresse du contrat `0x...` (publique)
3. Lien BscScan
4. Confirmation : `deployment/addresses.json` rempli, pas de secret commité
---
## Références
- [deployment/README.md](../../../tokenizerRendu/deployment/README.md)
- [decisions-projet.md](../decisions-projet.md)
- [sujet ch. IV](../../sujets/tokenizer.md)

127
docs/pedagogie/fiche-soutenance-tokenizer.md
View File

@@ -1,127 +0,0 @@
# Fiche de soutenance — Tokenizer (FGC42Forge)
> **Usage :** préparation orale + code review. Fichier **hors rendu** (`docs/pedagogie/`).
> **Grille sujet :** [`sujet-exigences-rendu.md`](sujet-exigences-rendu.md) (PDF v1.1, ch. IV–VI).
---
## 1. Pitch (30–45 s)
- Projet **Tokenizer** : token **BEP-20** sur **BSC Testnet**, nom **FGC42Forge**, symbole **FG42**, supply **1 000 000** mintée une fois au déploiement.
- Stack : **Solidity** + **OpenZeppelin** (`ERC20`, `Ownable`) + **Hardhat 3** + **Ignition**.
- Déployé et vérifié sur **BscScan** ; démo **transfer** entre deux wallets test.
- Bonus **multisig** non retenu (priorité obligatoire + simplicité ownership).
---
## 2. Carte du dépôt école (`tokenizerRendu/`)
| Chemin | Rôle (sujet) |
|--------|----------------|
| `README.md` | Choix techniques + **pourquoi** + adresse + réseau + explorer |
| `code/` | Source commenté, tests, Hardhat |
| `code/contracts/FGC42Forge.sol` | Contrat token — **cœur code review** |
| `deployment/` | Adresses, flatten, guide vérif BscScan |
| `documentation/README.md` | **Utilisateur** : qu’est-ce que FG42, comment l’utiliser |
**Ne pas montrer** au correcteur comme partie du rendu : `docs/`, `tokenizerRendu/../docs/pedagogie`.
---
## 3. Chiffres à avoir en tête (sans lire l’écran)
| Élément | Valeur |
|---------|--------|
| Réseau | BSC Testnet, **chainId 97** |
| Contrat | `0x0c76df26A1149fDc22C8f994975705271b070fF4` |
| Wallet déploiement / owner | `0xB6bE…603c` (FGC_account — avoir l’adresse complète sous les yeux) |
| Supply | 1 000 000 × 10¹⁸ unités (18 décimales OZ) |
| Tests | `npx hardhat test` — 2 tests FGC42Forge |
---
## 4. Déroulé oral suggéré (~10–15 min selon école)
| Étape | Contenu | Lien exigence sujet |
|-------|---------|---------------------|
| 1 | Contexte Web3 + BNB Chain testnet, pas d’argent réel | T4, T6 |
| 2 | README : pourquoi BSC, OZ, supply fixe, pas de mint public | T5, T12 |
| 3 | `documentation/` : cas d’usage, limites, import MetaMask | T17–T19 |
| 4 | BscScan : contrat vérifié, token, une tx `transfer` | T11, T15–T16 |
| 5 | Démo live ou replay : transfer 100 FG42 | T11 |
| 6 | **Code review** `FGC42Forge.sol` | T9–T10 |
| 7 | `deployment/` : comment reproduire le deploy (sans exposer clé) | T13–T14 |
| 8 | Bonus : pourquoi pas multisig | Ch. V (choix assumé) |
---
## 5. Code review — points à expliquer ligne par ligne (conceptuel)
1. **`import ERC20, Ownable`** — standard BEP-20 / ERC-20, pas de réinvention.
2. **Constructeur** : `_mint(msg.sender, …)` une fois → supply initiale ; `msg.sender` = deployer = owner.
3. **Pas de `mint()` public** — seul le design « supply fixe » ; owner ne mint pas après (à confirmer dans le fichier).
4. **`Ownable`** — qui peut `transferOwnership` ; pas de pause si non implémentée.
5. **Tests** : supply, transfer, éventuellement owner — preuve locale avant deploy.
*(Relire le contrat la veille ; adapter cette liste au code exact.)*
---
## 6. Sécurité (obligatoire sujet — réponses courtes)
| Question évaluateur | Réponse type |
|---------------------|--------------|
| Qui peut créer des tokens après deploy ? | Personne ; supply fixée au constructeur. |
| Risque si clé owner compromise ? | Ownership OZ : transfert de propriété possible ; pas de mint dans notre design. |
| Pourquoi testnet ? | Sujet : pas d’argent réel ; faucet tBNB. |
| Pourquoi OpenZeppelin ? | Bibliothèque auditée, conformité ERC-20. |
---
## 7. Stack, outils, alternatives (README « pourquoi »)
| Choix | Pourquoi | Alternative citée au sujet |
|-------|----------|----------------------------|
| BSC Testnet | Partenaire BNB, BEP-20, faucet | Ethereum testnet + ERC-20 |
| Hardhat 3 | Tests, compile, Ignition | Remix, Truffle |
| Ignition | Deploy reproductible | Script deploy manuel |
| `.env` + `.env.example` | Clé hors Git | — |
| Flatten + BscScan | Lisibilité évaluateur | Optionnel mais fait |
---
## 8. Commandes utiles (machine école)
```bash
cd tokenizerRendu/code # Hardhat n’est pas à la racine tokenizerRendu/
npm ci # ou npm install
cp .env.example .env # renseigner PRIVATE_KEY 64 hex — jamais commit
npx hardhat test --grep FGC42Forge
npx hardhat ignition deploy ignition/modules/FGC42Forge.ts --network bscTestnet
```
---
## 9. Git / Vogosphere (rappel)
- **Racine du repo école** = contenu de `tokenizerRendu/` (souvent `git init` dans ce dossier ou branche dédiée).
- `.gitignore` : `.env`, `node_modules`, `cache`, `artifacts`.
- **Seul le dépôt poussé** compte (ch. VI).
---
## 10. Auto-contrôle avant soutenance
Repasser la colonne « Projet » dans [`sujet-exigences-rendu.md`](sujet-exigences-rendu.md) (T1–T19).
- [x] README rendu **autonome** (pas de lien vers `docs/pedagogie`)
- [x] `documentation/README.md` sans référence au dépôt perso `docs/`
- [x] Adresse + réseau visibles sans chercher
- [ ] Démo transfer reproductible (FGC_account → 2ᵉ compte ; voir checklist demo)
- [ ] 2 phrases sur ch. III (compétences acquises)
---
## 11. Si on te demande « qu’est-ce qui manquerait pour le bonus ? »
Multisig (ex. Gnosis Safe ou contrat custom) sur actions sensibles ; **m** signatures sur **n** signataires ; extension cohérente avec le token — **seulement** si obligatoire jugée parfaite.

211
docs/pedagogie/guide-realisation.md
View File

@@ -1,211 +0,0 @@
# 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](../sujets/tokenizer.md)
> **Apprentissage :** [ressources-solidity-hardhat.md](ressources-solidity-hardhat.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](https://www.bnbchain.org/en/testnet-faucet)
3. Fichier `.env` dans `deployment/` ou racine `code/` :
```env
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)
```bash
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) :
```bash
npx hardhat run scripts/deploy.js --network bscTestnet
```
Enregistrer dans `addresses.json` :
```json
{
"network": "bscTestnet",
"chainId": 97,
"contract": "Token42",
"address": "0x...",
"explorer": "https://testnet.bscscan.com/address/0x..."
}
```
### Vérification sur l’explorer
- [BscScan Testnet](https://testnet.bscscan.com/) → **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](00-reprise-et-etat.md)

33
docs/pedagogie/parcours-etape-par-etape.md
View File

@@ -1,33 +0,0 @@
# Parcours guidé — Tokenizer (pas à pas)
> **Mode de travail :** une **étape** à la fois → tu réalises → tu demandes **vérification** dans le chat → étape suivante.
> **Référence obligatoire :** [sujet traduit](../sujets/tokenizer.md) · PDF [tokenizer_subject.pdf](../sujets/originaux/tokenizer_subject.pdf).
> **Doc travail** = `docs/` (ce fichier, étapes, décisions). **Doc rendu** = `tokenizerRendu/documentation/` (évaluateurs, plus tard).
## Règles
| Règle | Détail |
|-------|--------|
| Sujet | Chaque étape cite les exigences du chapitre IV (et bonus seulement après obligatoire parfaite) |
| Secrets | Jamais de clé privée dans Git — `.env` local uniquement |
| Rendu école | On ne remplit `tokenizerRendu/README.md` (choix finaux) qu’aux étapes prévues ; la doc **pédagogique** vit ici |
## Plan des étapes
| # | Fichier guide | Objectif | Statut |
|---|---------------|----------|--------|
| **1** | [etapes/etape-01-cadrage-wallet-testnet.md](etapes/etape-01-cadrage-wallet-testnet.md) | Décisions token + BSC testnet + tBNB | ✅ **Validée** (0,1 tBNB Telegram) |
| **2** | [etapes/etape-02-init-hardhat.md](etapes/etape-02-init-hardhat.md) | Init Hardhat dans `tokenizerRendu/code/` | ✅ |
| **3** | *(contrat + tests)* | `FGC42Forge.sol` + tests Mocha | ✅ |
| **4** | [etapes/etape-04-deploy-testnet.md](etapes/etape-04-deploy-testnet.md) | Dossier `deployment/` + deploy + BscScan | ✅ |
| **5** | `tokenizerRendu/documentation/README.md` | Doc utilisateur + choix techniques README | ✅ |
| **6** | [checklist-demo-evaluation.md](checklist-demo-evaluation.md) | Démo + code commenté (`FGC42Forge.sol`, config, tests) | ✅ |
| **7** | — | Bonus multisig (optionnel) | ❌ Non retenu |
## Fichier de suivi (travail)
→ [decisions-projet.md](decisions-projet.md) — **tu le remplis** à l’étape 1 ; l’assistant s’en sert pour vérifier.
## État global
→ [00-reprise-et-etat.md](00-reprise-et-etat.md)

163
docs/pedagogie/ressources-solidity-hardhat.md
View File

@@ -1,163 +0,0 @@
# Ressources — apprendre Solidity & Hardhat (Tokenizer)
> Liens **officiels** et parcours suggérés pour le projet **FGC42Forge** (BEP-20, BSC Testnet, Hardhat).
> Priorité : comprendre ce que tu déploies, pas tout lire d’un coup.
---
## Parcours suggéré (ordre)
| Phase | Quand | Objectif | Section ci-dessous |
|-------|--------|----------|-------------------|
| **A** | Avant / pendant étape 2 | Solidity : types, fonctions, `constructor` | § 1 |
| **B** | Étapes 2–3 | Hardhat : compile, test, config réseau | § 2 |
| **C** | Étape 3 | ERC-20 / OpenZeppelin, `Ownable` | § 3 |
| **D** | Étape 4+ | Deploy, verify BscScan, gas | § 4 |
| **E** | Optionnel | Approfondir Web3 / BNB | § 5 |
Croiser avec : [02-web3-comprendre.md](02-web3-comprendre.md) · [03-hardhat-et-alternatives.md](03-hardhat-et-alternatives.md) · [decisions-projet.md](decisions-projet.md).
---
## 1. Solidity — bases
### Documentation officielle (référence)
| Ressource | URL | À utiliser pour |
|-----------|-----|-----------------|
| **Solidity docs** (EN, référence) | https://docs.soliditylang.org/ | Syntaxe, types, visibilité, modifiers, erreurs |
| **By example** (courts extraits) | https://docs.soliditylang.org/en/latest/by-example.html | `mapping`, `modifier`, `events` |
| **Structure d’un contrat** | https://docs.soliditylang.org/en/latest/structure-of-a-contract.html | `state variables`, `functions`, `constructor` |
| **Sécurité (patterns)** | https://docs.soliditylang.org/en/latest/security-considerations.html | Bonnes pratiques (soutenance) |
### Chapitres utiles pour Tokenizer (lecture ciblée)
| Chapitre / thème | Pourquoi pour FGC42Forge |
|------------------|---------------------------|
| **Types** (`uint256`, `address`) | Soldes, adresses owner / holders |
| **Fonctions** (`public`, `view`, `pure`) | `balanceOf`, `transfer` (via ERC20) |
| **`constructor`** | Mint initial de la supply au deploy |
| **`modifier`** | Comprendre `onlyOwner` (OpenZeppelin) |
| **`require` / revert** | Tests « non-owner ne peut pas mint » |
| **Héritage** | `contract FGC42Forge is ERC20, Ownable` |
### Tutoriels / cours (gratuits)
| Ressource | URL | Note |
|-----------|-----|------|
| **Ethereum.org — Solidity** | https://ethereum.org/fr/developers/docs/programming-languages/solidity/ | Point d’entrée FR, liens vers la doc |
| **Ethereum.org — smart contracts** | https://ethereum.org/fr/developers/docs/smart-contracts/ | Concepts avant le code |
| **CryptoZombies** (jeu, EN) | https://cryptozombies.io/ | Solidity ludique — chapitres 1–3 suffisent pour démarrer |
| **OpenZeppelin — Learn** | https://docs.openzeppelin.com/learn/ | Articles ERC-20, access control (EN) |
### Vidéos (optionnel, EN souvent)
Chercher sur YouTube : *「Solidity tutorial 2024」* + *「ERC20 OpenZeppelin」* — privilégier chaînes qui montrent **testnet**, pas mainnet avec argent réel.
---
## 2. Hardhat — bases
### Documentation officielle
| Ressource | URL | À utiliser pour |
|-----------|-----|-----------------|
| **Hardhat — Getting started** | https://hardhat.org/hardhat-runner/docs/getting-started | Install, premier `compile` |
| **Configuration** | https://hardhat.org/hardhat-runner/docs/config | `networks.bscTestnet`, `solidity` version |
| **Testing contracts** | https://hardhat.org/hardhat-runner/docs/guides/test-contracts | Écrire tests étape 3 |
| **Deploying** | https://hardhat.org/hardhat-runner/docs/guides/deploying | Scripts → dossier `deployment/` |
| **Hardhat Network** | https://hardhat.org/hardhat-network/docs | `hardhat node` — tests sans tBNB |
| **Hardhat Toolbox** | https://hardhat.org/hardhat-runner/plugins/nomicfoundation-hardhat-toolbox | Plugins inclus (`ethers`, verify, etc.) |
### Tutoriels alignés BSC / testnet
| Ressource | URL | Note |
|-----------|-----|------|
| **BNB Chain — dev docs** | https://docs.bnbchain.org/bnb-smart-chain/developers/ | Faucet, réseau, outils |
| **How to Create a BEP20 Token** (QuickNode) | https://www.quicknode.com/guides/smart-contract-development/how-to-create-and-deploy-a-bep-20-token | Proche du sujet Tokenizer (vérifie dates / versions) |
| **OpenZeppelin — ERC20 guide** | https://docs.openzeppelin.com/contracts/5.x/erc20 | Utilisation `ERC20` + `_mint` |
### Commandes à connaître (fiche mémo)
```bash
cd tokenizerRendu/code
npm install
npx hardhat compile # compile contracts/
npx hardhat test # tests/
npx hardhat node # chaîne locale (optionnel)
npx hardhat run scripts/deploy.js --network bscTestnet
```
---
## 3. ERC-20 / BEP-20 & OpenZeppelin (cœur du projet)
| Ressource | URL | Contenu |
|-----------|-----|---------|
| **OpenZeppelin ERC20** | https://docs.openzeppelin.com/contracts/5.x/erc20 | API : `transfer`, `approve`, `_mint`, `_burn` |
| **OpenZeppelin Ownable** | https://docs.openzeppelin.com/contracts/5.x/access-control#ownership-and-ownable | `owner()`, `onlyOwner` |
| **EIP-20 (standard)** | https://eips.ethereum.org/EIPS/eip-20 | Spec originale (= logique BEP-20) |
| **Doc projet — BEP-20** | [02-web3 § 6](02-web3-comprendre.md#6-standards-erc-20-et-bep-20) | Lien sujet 42 + BSC |
**Exercice mental :** lire la doc `ERC20` et lister quelles fonctions tu **exposes** dans FGC42Forge et lesquelles viennent **uniquement** du parent OpenZeppelin.
---
## 4. Déploiement, explorer, verify
| Ressource | URL | Contenu |
|-----------|-----|---------|
| **BscScan — verify** | https://testnet.bscscan.com/verifyContract | Publier le **code source** après deploy |
| **Hardhat — verify plugin** | https://hardhat.org/hardhat-runner/plugins/nomicfoundation-hardhat-verify | `npx hardhat verify --network bscTestnet <adresse>` |
| **BNB — faucet** | https://docs.bnbchain.org/bnb-smart-chain/developers/faucet/ | tBNB (tu as déjà utilisé Telegram) |
| **Guide réalisation** | [guide-realisation.md](guide-realisation.md) | Étapes deploy du dépôt perso |
---
## 5. ethers.js (utilisé par Hardhat)
| Ressource | URL | Contenu |
|-----------|-----|---------|
| **ethers v6 docs** | https://docs.ethers.org/v6/ | `Wallet`, `Contract`, `parseEther` |
| **Hardhat + ethers** | https://hardhat.org/hardhat-runner/docs/advanced/using-ethers | Dans tests et scripts deploy |
Tu n’as pas besoin de tout maîtriser : savoir lire un script `deploy.js` qui fait `const Token = await ethers.getContractFactory("FGC42Forge")` suffit au début.
---
## 6. Outils complémentaires (sujet les cite)
| Outil | URL | Usage |
|-------|-----|--------|
| **Remix IDE** | https://remix.ethereum.org/ | Test rapide d’un `.sol` sans Hardhat |
| **Truffle docs** | https://archive.truffleframework.com/docs | Comparaison — [03-hardhat](03-hardhat-et-alternatives.md) |
| **Solidity VS Code** | Extension « Solidity » (Nomic Foundation) | Coloration, compilation locale |
---
## 7. Fiches projet Tokenizer (doc interne)
| Document | Lien |
|----------|------|
| Sujet traduit | [../sujets/tokenizer.md](../sujets/tokenizer.md) |
| Web3, RPC, mint, multisig | [02-web3-comprendre.md](02-web3-comprendre.md) |
| Hardhat vs alternatives | [03-hardhat-et-alternatives.md](03-hardhat-et-alternatives.md) |
| Étapes pas à pas | [parcours-etape-par-etape.md](parcours-etape-par-etape.md) |
| Étape 2 Hardhat | [etapes/etape-02-init-hardhat.md](etapes/etape-02-init-hardhat.md) |
---
## 8. Plan de lecture « minimum » avant l’étape 3
Si tu manques de temps, lire au moins :
1. [Solidity — Simple Storage](https://docs.soliditylang.org/en/latest/introduction-to-smart-contracts.html) (intro officielle)
2. [OpenZeppelin ERC20 — Usage](https://docs.openzeppelin.com/contracts/5.x/erc20#usage)
3. [Hardhat — Getting started](https://hardhat.org/hardhat-runner/docs/getting-started) jusqu’au premier `compile`
4. [02-web3 § 7.2](02-web3-comprendre.md#72-glossaire-anglais--supply-owner-ownable-onlyowner) (supply, owner, onlyOwner)
Ensuite : coder `FGC42Forge.sol` avec le guide étape 3 (à venir après validation étape 2).
---
*Dernière mise à jour : liens vérifiés oct. 2026 — signaler dans le chat si un lien est mort pour mise à jour.*

122
docs/pedagogie/sujet-exigences-rendu.md
View File

@@ -1,122 +0,0 @@
# Exigences du sujet Tokenizer (v1.1) — grille de conformité rendu
> Source officielle : [`docs/sujets/originaux/tokenizer_subject.pdf`](../sujets/originaux/tokenizer_subject.pdf)
> Traduction structurée : [`docs/sujets/tokenizer.md`](../sujets/tokenizer.md)
> **Dépôt évalué** : racine Vogosphere = contenu de **`tokenizerRendu/`** (pas le dépôt de travail `tokenizer/` avec `docs/`).
---
## Chapitre VI — Règle d’or
| Règle | Implication |
|-------|-------------|
| Dépôt Git habituel | Push sur Vogosphere ; **seul le contenu du dépôt** est noté |
| Noms dossiers / fichiers | Respecter l’exemple ou un nom **explicite** justifiable à l’oral |
| Git perso `#web3` | **Recommandé en plus**, pas en remplacement du rendu école |
---
## Arborescence obligatoire (PDF p.7)
```
README.md ← racine du dépôt ÉCOLE
code/
deployment/ ← nom d’exemple ; autre nom OK si clair en soutenance
documentation/
```
**Hors sujet dans le rendu :** dossier `docs/` perso, PDF sujet traduit, checklist perso — à garder dans le dépôt de **travail** uniquement.
---
## Tableau des exigences — partie obligatoire (ch. IV)
| # | Exigence (sujet) | Critère de validation | Projet FGC42Forge |
|---|------------------|----------------------|-------------------|
| **T1** | Nom du token contient **`42`** | `name()` on-chain ou nom documenté | ✅ `FGC42Forge` |
| **T2** | Pas d’insultes dans le nom | — | ✅ |
| **T3** | Standard de la chaîne | BEP-20 si BSC | ✅ OpenZeppelin ERC20 sur BSC Testnet |
| **T4** | **Pas d’argent réel** | Testnet + doc | ✅ tBNB, pas de mainnet requis |
| **T5** | **`README.md` racine** : choix + **pourquoi** | Section explicite technologies / chaîne / modèle | ✅ `tokenizerRendu/README.md` (choix techniques) |
| **T6** | Blockchain qui supporte les tokens | EVM / smart contracts | ✅ BNB Smart Chain |
| **T7** | Maîtrise langage + toolchain | Solidity + Hardhat (ou équivalent cité) | ✅ Solidity 0.8.34 + Hardhat 3 |
| **T8** | Dossier **`code/`** à la racine | Présent | ✅ |
| **T9** | Code **commenté**, noms **lisibles** | Revue en eval | ✅ `FGC42Forge.sol` + index `code/README.md` |
| **T10** | **Code review** en soutenance | Savoir expliquer le contrat | À préparer (fiche soutenance) |
| **T11** | **Démo minimale** : token fonctionne | `name`, `symbol`, `totalSupply`, `transfer` ; explorer | ✅ tests + MetaMask + BscScan |
| **T12** | **Sécurité** : ownership, privilèges | Expliquer owner, mint, pause, etc. | ✅ Ownable, pas de mint public ; à verbaliser |
| **T13** | Dossier **`deployment/`** (ou équivalent) | Scripts / infos deploy | ✅ |
| **T14** | Deploy **blockchain publique** | Testnet public OK | ✅ BSC Testnet |
| **T15** | **Ticker** + contrat sur **explorateur** | Symbole + adresse visible | ✅ FG42 + BscScan |
| **T16** | Git : **adresse contrat** + **réseau** | README ou deployment | ✅ README + `addresses.json` |
| **T17** | Dossier **`documentation/`** | Comprendre + **utiliser** le token | ✅ |
| **T18** | Doc **claire**, relue en eval | Guide utilisateur autonome | ✅ `documentation/README.md` + stack |
| **T19** | Whitepaper léger (envisagé) | Rôle, limites — pas toujours fichier séparé | ✅ `documentation/README.md` § 5 |
---
## Ce qui n’est **pas** obligatoire (éviter de sur-investir)
| Élément | Sujet |
|---------|--------|
| **Vidéo démo** | Optionnelle ; **ne change pas la note** ; lien seulement si faite |
| **Bonus multisig** | Ch. V ; **non noté** si obligatoire imparfaite ; tu as **abandonné** → OK |
| **Mint public en démo** | « Éventuellement mint **si prévu** » — pas requis si supply fixe documentée |
| **Vérification BscScan** | Non écrit mot pour mot ; **fortement recommandé** (preuve + code review) — ✅ fait |
| **NFT / ERC-721** | Hors token fongible type 20 |
| **Compte Binance** | Non requis ; wallet + faucet suffisent |
---
## Chapitre V — Bonus (référence)
| Règle | Conséquence |
|-------|-------------|
| Multisig (contrat ou extension) | Seuils m-of-n, qui signe |
| Obligatoire **PARFAITE** | Sinon bonus ignoré |
**Ton choix :** bonus non implémenté — indiqué dans `tokenizerRendu/README.md`.
---
## Objectifs pédagogiques (ch. III) — à mentionner à l’oral
- Maîtrise d’**au moins un langage** chaîne (Solidity).
- Familiarité **blockchain publique** (réseau, explorer, adresses, txs).
- Capacité d’**adaptation** (apprentissage Web3).
---
## Erreurs fréquentes à éviter (checklist anti-échec)
| Erreur | Risque |
|--------|--------|
| Dépôt racine = `tokenizer/` avec `docs/` au lieu de `tokenizerRendu/` seul | Structure hors sujet |
| Pas d’adresse / réseau dans Git | T16 manquant |
| `documentation/` = copie de la doc dev ou liens vers `docs/pedagogie` | Évaluateur perdu ; fuite hors rendu |
| Clé privée / `.env` commité | Sécurité + disqualification possible |
| Nom sans `42` | T1 |
| Mainnet / vrai BNB obligatoire | T4 |
| Token non déployé sur chaîne publique | T14 |
| Code non commenté / illisible en review | T9–T10 |
| README sans **pourquoi** (liste d’outils seule) | T5 |
| Compter sur la vidéo pour la note | Inutile pour la note |
| Présenter le bonus sans obligatoire parfaite | Règle ch. V |
---
## Démo minimale — script aligné sujet (ch. IV + éclaircissements)
1. **Explorer** : adresse contrat + page **token** (symbole, supply).
2. **Lecture** : `name`, `symbol`, `totalSupply` (BscScan ou wallet).
3. **`transfer`** entre deux comptes test (MetaMask).
4. **Sécurité** : qui est `owner` ; **pas** de mint après deploy ; pas de privilèges cachés.
5. **`documentation/`** : montrer qu’un tiers peut importer FG42 et transférer.
6. **`code/`** : ouvrir `FGC42Forge.sol` (revue de code courte).
---
## Prochaine étape doc perso
→ Fiche de soutenance : [`fiche-soutenance-tokenizer.md`](fiche-soutenance-tokenizer.md)
→ Audit rendu avant push : [`audit-rendu-tokenizer.md`](audit-rendu-tokenizer.md)

9
docs/sujets/README.md
View File

@@ -1,9 +0,0 @@
# Sujets — Tokenizer
| Document | Description |
|----------|-------------|
| [tokenizer.md](tokenizer.md) | Traduction FR complète (v1.1) + interprétation des visuels |
| [originaux/tokenizer_subject.pdf](originaux/tokenizer_subject.pdf) | PDF officiel Intra |
| [captures/](captures/) | Pages extraites du PDF (`page-01.png` … `page-10.png`) |
Copie locale à la racine du dépôt de travail : `tokenizer.pdf` (optionnel, doublon du PDF dans `originaux/`).

BIN
docs/sujets/captures/page-01.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 199 KiB

BIN
docs/sujets/captures/page-02.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 126 KiB

BIN
docs/sujets/captures/page-03.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 268 KiB

BIN
docs/sujets/captures/page-04.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 609 KiB

BIN
docs/sujets/captures/page-05.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 224 KiB

BIN
docs/sujets/captures/page-06.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 297 KiB

BIN
docs/sujets/captures/page-07.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 322 KiB

BIN
docs/sujets/captures/page-08.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 150 KiB

BIN
docs/sujets/captures/page-09.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 233 KiB

BIN
docs/sujets/captures/page-10.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 172 KiB

BIN
docs/sujets/originaux/tokenizer_subject.pdf
View File

Binary file not shown.

273
docs/sujets/tokenizer.md
View File

@@ -1,273 +0,0 @@
# Tokenizer — Build your own token
> **Version :** 1.1
> **Résumé :** Exercice lié au **Web3**.
> **Traduction française** — source : [tokenizer_subject.pdf](originaux/tokenizer_subject.pdf)
---
## Table des matières
1. [Chapitre I — Avant-propos](#chapitre-i--avant-propos)
2. [Chapitre II — Introduction](#chapitre-ii--introduction)
3. [Chapitre III — Objectifs](#chapitre-iii--objectifs)
4. [Chapitre IV — Partie obligatoire](#chapitre-iv--partie-obligatoire)
5. [Chapitre V — Bonus](#chapitre-v--bonus)
6. [Chapitre VI — Rendu et évaluation par les pairs](#chapitre-vi--rendu-et-évaluation-par-les-pairs)
7. [Éléments visuels du PDF](#éléments-visuels-du-pdf)
8. [Éclaircissements (lecture facilitée)](#éclaircissements-lecture-facilitée)
---
## Page de garde (PDF page 1)
| Champ | Texte officiel (EN) | Traduction |
|-------|---------------------|------------|
| Titre | Tokenizer | Tokenizer |
| Sous-titre | Build your own token | Construis ton propre token |
| Résumé | This document is a Web3 related exercise. | Ce document est un exercice lié au **Web3** → voir [définition détaillée](../pedagogie/02-web3-comprendre.md). |
| Version | 1.1 | 1.1 |
### Référence visuelle — couverture
![Page de garde](captures/page-01.png)
| Zone | Description |
|------|-------------|
| Illustration centrale | Motif vertical en facettes (style low-poly), tons gris/noir — **élément graphique 42**, pas une maquette de smart contract |
| Fond | Motif géométrique léger (triangles) sur toutes les pages |
| En-têtes | « Tokenizer » à gauche, « Build your own token » à droite |
---
## Chapitre I — Avant-propos
Ce sujet est réalisé en **partenariat entre 42 et BNB Chain**.
**BNB Chain** (*Build N Build*) est un réseau blockchain distribué sur lequel développeurs et innovateurs peuvent construire des **applications décentralisées (DApps)** dans la mouvance **Web3**.
En octobre 2022 (chiffres du sujet), BNB Chain était parmi les plus grands réseaux de smart contracts au monde en volume de transactions et utilisateurs actifs quotidiens : plus de 3 milliards de transactions, 232 millions d’adresses uniques, plus de 1 500 DApps actives. La nature **décentralisée** du réseau permet de déployer un produit **sans permission** centrale et d’atteindre un large public.
### Faucet (testnet)
Tu peux obtenir des **tBNB** (BNB de **test**, sans argent réel) via le faucet officiel :
- [BNB Chain Faucet](https://www.bnbchain.org/en/testnet-faucet) (lien cité dans le sujet : *BNB Chain Faucet*)
### BNB, Binance et BNB Chain
Le sigle **BNB** désigne à la fois l’**écosystème blockchain** du sujet (**BNB Chain**, *Build N Build*) et la **monnaie native** utilisée pour payer le **gas**. Sur testnet, on utilise **tBNB** (sans valeur réelle).
**Rapport avec Binance :** oui, **historiquement** — Binance a lancé et porté cet écosystème (l’actif s’appelait souvent *Binance Coin* ; la chaîne s’appelait **Binance Smart Chain**, **BSC**). Aujourd’hui la communication officielle parle surtout de **BNB Chain** comme réseau pour développeurs et DApps. Ce n’est **pas** le même produit que l’application d’**échange** Binance : pour Tokenizer, tu n’as en principe **pas besoin** d’un compte Binance — wallet + **testnet** + faucet suffisent.
| Terme | En bref |
|-------|---------|
| **Binance** | Exchange centralisé (entreprise) |
| **BNB Chain / BSC** | Blockchain smart contracts (ton déploiement) |
| **BEP-20** | Standard de **ton** token sur cette chaîne |
| **BscScan (testnet)** | Explorateur pour prouver le contrat déployé |
→ Développement détaillé : [section 10 — BNB, BNB Chain et Binance](../pedagogie/02-web3-comprendre.md#10-bnb-bnb-chain-et-binance-partenaire-du-sujet).
### Référence visuelle — Figure I.1 (PDF page 2)
![Chapitre I — BNB Chain](captures/page-03.png)
| Zone | Description |
|------|-------------|
| Logo | Hexagone jaune + mention **BNB CHAIN** |
| Légende | *Figure I.1: https://www.bnbchain.org/* — site officiel de l’écosystème |
| Message implicite | Le partenaire du sujet pousse vers l’écosystème **BSC / BNB** ; le standard token y est **BEP-20** (équivalent fonctionnel d’**ERC-20** sur Ethereum) |
---
## Chapitre II — Introduction
Bienvenue dans le monde de la **technologie blockchain**.
Tu vas pouvoir **créer ton propre token numérique**. La blockchain permet de créer et distribuer des actifs numériques uniques (**tokens**) : monnaie, parts, représentation d’œuvres, ou lien avec un actif du monde réel (selon le design que tu documentes).
Ce n’est pas trivial : il faut comprendre ce que tu déploies. Avec les bonnes ressources (testnet, faucet, outils), c’est un projet formateur et concret.
### Référence visuelle (PDF page 3)
![Introduction — illustration token / puce](captures/page-04.png)
| Zone | Description |
|------|-------------|
| Illustration | Style « peinture numérique » : **jeton doré** sur une base type **puce / circuit** |
| Sens | Métaphore **hardware + actif numérique** — le token est un programme (smart contract) exécuté par le réseau, pas un simple fichier |
---
## Chapitre III — Objectifs
En participant à ce projet, tu contribues à la création d’un **actif numérique on-chain**. Le sujet te challenge sur :
- la maîtrise d’**au moins un langage** lié à ta chaîne (ex. **Solidity** pour BSC/ETH) ;
- la familiarité avec une **blockchain publique** (réseau, explorer, adresses, transactions) ;
- l’**adaptation** : pas besoin d’être cryptographe expert au départ, mais tu dois apprendre en chemin.
Objectif final : compétences utiles + participation à un écosystème innovant (Web3).
### Référence visuelle (PDF page 4)
![Objectifs](captures/page-05.png)
| Zone | Description |
|------|-------------|
| Illustration | Jetons / pièces stylisées — rappel que le livrable est un **token** avec règles économiques et techniques définies par **toi** (dans les contraintes du sujet) |
---
## Chapitre IV — Partie obligatoire
Pour créer un token, plusieurs exigences techniques et organisationnelles s’appliquent.
### Contraintes sur le token
| Règle | Détail |
|-------|--------|
| **Nom** | Libre, mais le nom doit contenir **`42`** |
| **Insultes** | Interdites — sanctions école |
| **README racine** | Fichier **`README.md`** à la racine du dépôt **école** : expliquer tes **choix** et **pourquoi** |
| **Standard** | Respecter le standard de la chaîne (**ERC-20** sur Ethereum, **BEP-20** sur BSC, etc.) — voir [§ ERC-20 / BEP-20](#erc-20-et-bep-20-éclaircissement) |
| **Argent réel** | **Jamais** demandé — utiliser des **chaînes de test** |
### ERC-20 et BEP-20 (éclaircissement)
**ERC-20** (Ethereum) et **BEP-20** (BNB Chain / BSC) définissent la même famille de **tokens fongibles** : `balanceOf`, `transfer`, `approve`, `totalSupply`, etc. Sur BSC, le code Solidity est en pratique le même qu’un ERC-20 (souvent bibliothèque **OpenZeppelin `ERC20`**) ; l’explorateur (**BscScan**) parle de **BEP-20** parce que la chaîne est BNB, pas parce que tu réécris une norme différente.
| Question | Réponse |
|----------|---------|
| BEP-20 obligatoire pour tout le monde ? | **Non** — obligatoire **si** tu choisis **BSC / BNB Chain**. Sur Ethereum testnet → **ERC-20**. |
| Piste la plus alignée avec le PDF ? | **BSC Testnet** + **BEP-20** (tBNB, partenariat BNB). |
| NFT / autre standard ? | Hors sujet type « token classique » ; rester sur le **20** fongible. |
→ Détail : [Standards ERC-20 et BEP-20](../pedagogie/02-web3-comprendre.md#6-standards-erc-20-et-bep-20).
### Plateforme et outils
1. Choisir une blockchain qui supporte la création de tokens.
2. Maîtriser le langage et la toolchain de cette chaîne : **IDE**, **Remix**, **Hardhat**, **Truffle**, etc.
### Code (`code/`)
- Dossier **`code/`** à la **racine** du dépôt école.
- Code **commenté**, noms de variables et fonctions **lisibles**.
- En soutenance : **revue de code** (*code review*).
### Démonstration et sécurité
Tu dois pouvoir faire des **actions minimales** qui prouvent que le token fonctionne.
Réfléchir explicitement à la **sécurité** : **propriété** (*ownership*), **privilèges** (qui peut mint, pause, transférer des rôles, etc.).
### Déploiement (2ᵉ dossier)
- Tout le nécessaire au **déploiement** dans un **second dossier** à la racine — le sujet donne l’exemple **`deployment/`** (nom libre mais structure claire attendue).
- Déployer sur une **blockchain publique** (en pratique : **testnet public** pour ne pas dépenser de vrai argent).
- Définir le **ticker** (symbole, ex. `TK42`) et **publier** le contrat sur un **explorateur** (ex. **BscScan**, **Blockscan** selon la chaîne).
- Dans le dépôt Git : indiquer l’**adresse du smart contract** et le **réseau** utilisé.
### Documentation (`documentation/`)
- Dossier **`documentation/`** à la racine du dépôt école.
- On doit comprendre **comment ça marche** et **comment utiliser** le token.
- Envisager un contenu type **whitepaper** léger : rôle du token, fonctionnalités, limites.
- La doc sera **relue en évaluation** — claire et explicite.
### Vidéo démo (optionnelle)
- Pas obligatoire ; **ne améliore pas la note**.
- Si tu en fais une : **lien** dans le README suffit (pas besoin de pousser la vidéo dans Git).
### Encadrés d’avertissement (PDF pages 5–7)
![Partie obligatoire — extraits](captures/page-06.png)
| Encadré | Message |
|---------|---------|
| Rose / ⚠️ | **Revue de code** pendant l’évaluation |
| Rose / ⚠️ | Documentation **claire** — relue en eval |
| Bleu / ℹ️ | Vidéo : **lien** seulement, pas le fichier dans le repo |
| Rose / ⚠️ | Vidéo **non requise**, pas de bonus de note |
### Arborescence attendue (exemple officiel, PDF page 7)
![Structure du dépôt](captures/page-08.png)
```
README.md
code/
deployment/ # nom d’exemple ; un autre nom explicite est possible si le sujet l’accepte en soutenance
documentation/
```
→ Dans ce dépôt perso, le paquet école est préparé dans [`../../tokenizerRendu/`](../../tokenizerRendu/).
---
## Chapitre V — Bonus
Pour renforcer la sécurité (ex. transactions sensibles), tu peux implémenter un **multisig** (*multisignature*) : plusieurs signataires doivent approuver une action avant exécution.
- Smart contract dédié ou extension adaptée à **ta** partie obligatoire.
- Définir le **nombre de signatures** et **qui** peut signer.
### ⚠️ Règle bonus
Le bonus n’est évalué **que si la partie obligatoire est PARFAITE** (intégrale, sans dysfonctionnement). Une seule exigence obligatoire manquante → **bonus non évalué**.
![Bonus multisig](captures/page-09.png)
---
## Chapitre VI — Rendu et évaluation par les pairs
Dépôt Git habituel. **Seul le contenu du dépôt** est évalué. Vérifier **noms de dossiers et fichiers**.
Exception : le sujet **recommande** de partager le projet sur un **compte Git personnel** une fois valide (hashtags `#web3`, langage, etc.) — **en plus** du rendu Vogosphere, pas en remplacement.
![Rendu](captures/page-10.png)
---
## Éléments visuels du PDF
| Page PDF | Fichier | Contenu visuel |
|----------|---------|----------------|
| 1 | [page-01.png](captures/page-01.png) | Couverture |
| 2 | [page-03.png](captures/page-03.png) | Texte BNB + logo Figure I.1 |
| 3 | [page-04.png](captures/page-04.png) | Introduction + illustration token |
| 4 | [page-05.png](captures/page-05.png) | Objectifs + illustration |
| 5–6 | [page-06.png](captures/page-06.png), [page-07.png](captures/page-07.png) | Partie obligatoire, encadrés |
| 7 | [page-08.png](captures/page-08.png) | Exemple `ls -al` |
| 8 | [page-09.png](captures/page-09.png) | Bonus |
| 9 | [page-10.png](captures/page-10.png) | Soumission |
*(La page PDF « Contents » / table des matières correspond visuellement à [page-02.png](captures/page-02.png).)*
---
## Éclaircissements (lecture facilitée)
Ces points ne sont pas toujours explicites dans le PDF ; ils servent de fil conducteur pour le [guide de réalisation](../pedagogie/guide-realisation.md).
| Terme | En bref |
|-------|---------|
| **Token** | Contrat intelligent qui suit une norme (souvent **20** : solde, `transfer`, `approve`, etc.) |
| **BEP-20 / ERC-20** | Normes tokens fongibles (BSC vs Ethereum) — [§ détaillé](#erc-20-et-bep-20-éclaircissement) · [doc Web3 §6](../pedagogie/02-web3-comprendre.md#6-standards-erc-20-et-bep-20) |
| **Déploiement** | Transaction qui enregistre le bytecode du contrat sur la chaîne → **adresse** unique |
| **tBNB** | Monnaie native de **test** pour payer le gas sur BNB Smart Chain testnet |
| **Ownership** | Souvent `Ownable` (OpenZeppelin) : qui peut `mint`, changer des paramètres, etc. |
| **Démo minimale** | Ex. : lire `name`, `symbol`, `totalSupply` ; `transfer` ; éventuellement `mint` si prévu — montrable sur explorer + script ou Remix |
| **3 dossiers** | `code` = source ; `deployment` = scripts, config réseau, adresses déployées ; `documentation` = guide **utilisateur** du token (distinct de `docs/` du dépôt perso) |
**Chaîne recommandée (alignée partenaire sujet)** : **BNB Smart Chain Testnet** + Solidity + BEP-20. Autre chaîne EVM possible si tu justifies en README et respectes le standard équivalent.
---
## Prochaine étape
→ [Plan de réalisation](../pedagogie/README.md) · [Apports pédagogiques](../pedagogie/01-apports-pedagogiques.md)

BIN
tokenizer.pdf
View File

Binary file not shown.