miseneplace

docs/README.md

@@ -19,6 +19,7 @@ Documentation du projet, sur le modèle de [piscine_mobile/docs](../../piscine_m
 | **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) |
 | **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)

docs/pedagogie/00-reprise-et-etat.md

@@ -1,14 +1,15 @@
 # Reprise du projet — où nous en sommes
 
-> Dernière mise à jour : initialisation documentation et squelette de rendu.
+> Dernière mise à jour : démarrage parcours guidé — **étape 1 en cours**.
 
 ## En bref
 
 | | |
 |---|---|
 | **Fait** | Dépôt de travail, sujet FR v1.1, captures PDF, plan pédagogique, paquet `tokenizerRendu/` |
-| **À faire** | Smart contract, déploiement testnet, doc utilisateur, README école complété |
-| **Prochaine action** | Lire [guide-realisation.md](guide-realisation.md) étape 1 — figer chaîne + nom du token |
+| **En cours** | **[Étape 1](etapes/etape-01-cadrage-wallet-testnet.md)** — cadrage + wallet testnet + `decisions-projet.md` |
+| **À faire** | Étapes 2→6 (code, deploy, doc rendu, démo) ; bonus 7 optionnel |
+| **Prochaine action** | Toi : compléter l’étape 1 puis demander **vérification** dans le chat |
 
 ## Arborescence actuelle
 
@@ -26,7 +27,11 @@ tokenizer/                           ← dépôt Git de TRAVAIL (perso)
 │   └── pedagogie/
 │       ├── README.md
 │       ├── 00-reprise-et-etat.md    ← ce fichier
+│       ├── parcours-etape-par-etape.md
+│       ├── decisions-projet.md      ← suivi étape 1+ (travail)
+│       ├── etapes/etape-01-…md
 │       ├── 01-apports-pedagogiques.md
+│       ├── 02-web3-comprendre.md
 │       └── guide-realisation.md
 └── tokenizerRendu/                  ← futur dépôt ÉCOLE (racine Vogosphere)
     ├── README.md
@@ -42,20 +47,23 @@ tokenizer/                           ← dépôt Git de TRAVAIL (perso)
 | Chaîne | BSC testnet, Sepolia, autre EVM | **BSC testnet** (partenariat BNB, faucet tBNB) |
 | Toolchain | Hardhat, Foundry, Remix seul | **Hardhat** pour scripts reproductibles dans `deployment/` |
 | Lib | OpenZeppelin ERC20 → BEP-20 | **OpenZeppelin** pour ownership et standard éprouvé |
-| Nom / symbole | Doit contenir `42` | Ex. nom `Token42School`, symbole `TK42` — à valider perso |
+| Nom / symbole | Doit contenir `42` | **`FGC42Forge`** / **`FG42`** — voir [decisions-projet.md](decisions-projet.md) |
 | Bonus multisig | Gnosis Safe, contrat custom | Seulement après obligatoire **parfaite** |
 
-## Avancement par étape
+## Avancement par étape (parcours guidé)
+
+→ Détail : [parcours-etape-par-etape.md](parcours-etape-par-etape.md)
 
 | Étape | Contenu | Statut |
 |-------|---------|--------|
 | **0** | Structure, traduction, séparation travail / école | ✅ **Terminé** |
-| **1** | Choix stack + init projet dans `code/` | ⏳ |
-| **2** | Contrat token + tests locaux | ⏳ |
-| **3** | Déploiement + verify + adresse dans README | ⏳ |
-| **4** | `documentation/` + démo soutenance | ⏳ |
-| **5** | Rendu Vogosphere + partage Git perso (recommandé) | ⏳ |
-| **6** | Bonus multisig | ⏳ |
+| **1** | Cadrage + wallet + tBNB + `decisions-projet.md` | 🔄 **En cours** |
+| **2** | Init Hardhat dans `tokenizerRendu/code/` | ⏳ |
+| **3** | Contrat BEP-20 + tests | ⏳ |
+| **4** | `deployment/` + deploy testnet + BscScan | ⏳ |
+| **5** | `tokenizerRendu/documentation/` + README école | ⏳ |
+| **6** | Démo + code review (préparation soutenance) | ⏳ |
+| **7** | Bonus multisig | ⏳ |
 
 ## Reprendre le travail (checklist)
 

docs/pedagogie/02-web3-comprendre.md

@@ -43,7 +43,7 @@ Plusieurs machines (nœuds) maintiennent une **copie** (ou une vue) du même reg
 
 ### 3.2 Blockchain
 
-Chaîne de **blocs** liés par empreintes cryptographiques ; chaque bloc contient des **transactions** (ou des exécutions de contrats). Consensus (PoS, PoA, etc.) définit qui peut proposer le bloc suivant.
+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.
 
@@ -55,9 +55,19 @@ Programme déployé à une **adresse** sur la chaîne. Une fois publié, son cod
 
 ### 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**.
+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)
 
@@ -82,6 +92,31 @@ Frais payés dans la **monnaie native** de la chaîne (BNB sur BSC, ETH sur Ethe
 
 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
@@ -109,10 +144,7 @@ flowchart LR
     RPC[Réseau RPC]
     Chain[Blockchain publique]
     SC[Smart contract Token BEP-20]
-    Explorer[Explorateur BscScan]
-  end
-  User --> Browser
-  User --> Wallet
+    Explorer[Explorateur BscScan]source ~/.bashrc 
   Wallet --> RPC
   RPC --> Chain
   Chain --> SC
@@ -125,13 +157,128 @@ flowchart LR
 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 : pourquoi BEP-20 / ERC-20 ?
+## 6. Standards : ERC-20 et BEP-20
 
-Les blockchains compatibles **EVM** (Ethereum, BSC, etc.) partagent souvent le même modèle de contrat. **ERC-20** (Ethereum) et **BEP-20** (BSC) décrivent les mêmes idées : `balanceOf`, `transfer`, `approve`, `allowance`, événements `Transfer`, etc.
+### 6.1 C’est quoi, en une phrase ?
 
-Les wallets et explorateurs savent afficher un token **s’il respecte** ce standard. C’est pour cela que le sujet exige de respecter le standard de ta chaîne.
+**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) |
 
 ---
 
@@ -148,6 +295,180 @@ Le Web3 déplace une partie des risques vers **le code** et **les clés** :
 
 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é)

docs/pedagogie/README.md

@@ -4,13 +4,17 @@ Parcours pour construire le projet **étape par étape** et le défendre en sout
 
 ## Reprise rapide
 
-→ **[00-reprise-et-etat.md](00-reprise-et-etat.md)** — état du projet, décisions, prochaine action.
+→ **[parcours-etape-par-etape.md](parcours-etape-par-etape.md)** — **parcours guidé** (une étape → vérification → suivante).
 
-→ **[guide-realisation.md](guide-realisation.md)** — **guide dev** détaillé (choix techniques, sécurité, déploiement, démo).
+→ **[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).
 
 → **[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** (Web1/2/3, blockchain, token, wallet, **BNB / Binance**, lien avec Tokenizer).
+→ **[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
 
@@ -27,8 +31,8 @@ Ressources externes utiles : [docs Solidity](https://docs.soliditylang.org/), [O
 
 | Étape | Objectif | Statut |
 |-------|----------|--------|
-| **0** | Dépôt travail + `docs/`, sujet FR, paquet `tokenizerRendu/` | ✅ **Fait** — [00-reprise-et-etat.md](00-reprise-et-etat.md) |
-| **1** | Choix chaîne + stack (ex. BSC testnet + Hardhat) + nom token avec `42` | ⏳ À faire |
+| **0** | Dépôt travail + `docs/`, sujet FR, paquet `tokenizerRendu/` | ✅ **Fait** |
+| **1** | [Cadrage + wallet testnet](etapes/etape-01-cadrage-wallet-testnet.md) | 🔄 **En cours** |
 | **2** | Smart contract BEP-20 dans `tokenizerRendu/code/` (ownership, commentaires) | ⏳ À faire |
 | **3** | Scripts `tokenizerRendu/deployment/` + déploiement testnet + verify explorer | ⏳ À faire |
 | **4** | `documentation/` utilisateur + README école (adresse, réseau, choix) | ⏳ À faire |

docs/pedagogie/decisions-projet.md

@@ -0,0 +1,115 @@
+# 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** | 1 — en cours | Wallet + faucet à finaliser par toi avant validation. | [etape-01](etapes/etape-01-cadrage-wallet-testnet.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) |
+
+### 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 |
+|-------|--------|---------|-----------|
+| **Adresse publique** | `À COMPLÉTER` (`0x…`) | Identifiant **public** de ton compte ; reçoit **tBNB** et, après deploy, les **FG42**. | [02-web3 § 3.5 wallet](02-web3-comprendre.md#35-wallet-portefeuille) |
+| **tBNB (faucet)** | `À COMPLÉTER` (oui/non + date) | Gas pour déployer **FGC42Forge** et envoyer des txs de démo. | Sujet ch. I · [faucet](https://www.bnbchain.org/en/testnet-faucet) |
+| **Compte dédié** | Recommandé | Ne pas réutiliser un wallet mainnet avec de vrais fonds. | Sujet ch. IV (pas d’argent réel) |
+
+### Paramètres MetaMask — BSC Testnet
+
+| Paramètre | Valeur | Concept |
+|-----------|--------|---------|
+| Nom | BNB Smart Chain Testnet | Libellé dans l’UI wallet |
+| RPC URL | `https://data-seed-prebsc-1-s1.binance.org:8545/` | Voir colonne RPC ci-dessus |
+| Chain ID | `97` | Doit correspondre à Hardhat `networks.bscTestnet` |
+| Symbole | tBNB | Monnaie native pour le **gas** (pas FG42) |
+| Explorer | https://testnet.bscscan.com | Vérifier balance tBNB et futur contrat FG42 |
+
+---
+
+## 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`.

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

@@ -0,0 +1,73 @@
+# É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))
+
+- [ ] **Nom du token** (contient `42`, ex. `School42Token`)
+- [ ] **Symbole** (ex. `S42`) — court, style ticker
+- [ ] **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
+
+- [ ] Installer **MetaMask** (ou Rabby, etc.) — navigateur ou mobile
+- [ ] Créer ou utiliser un compte **uniquement pour le testnet** (pas de gros soldes mainnet)
+- [ ] Ajouter le réseau **BNB Smart Chain Testnet** si absent :
+  - Nom : `BNB Smart Chain Testnet`
+  - RPC : `https://data-seed-prebsc-1-s1.binance.org:8545/`
+  - Chain ID : `97`
+  - Symbole : `tBNB`
+  - Explorer : `https://testnet.bscscan.com`
+- [ ] Copier ton **adresse publique** (0x…) dans `decisions-projet.md` — **jamais** la phrase secrète / clé privée
+
+### C. Faucet tBNB
+
+- [ ] Aller sur [BNB Chain Testnet Faucet](https://www.bnbchain.org/en/testnet-faucet)
+- [ ] Demander des **tBNB** sur ton adresse (parfois file d’attente ou limite — réessayer si besoin)
+- [ ] Vérifier dans MetaMask : solde **tBNB** > 0 sur **BSC Testnet**
+
+### 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
+
+---
+
+## 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)

docs/pedagogie/parcours-etape-par-etape.md

@@ -0,0 +1,33 @@
+# 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 | 🔄 **En cours** |
+| **2** | *(à publier après validation étape 1)* | Init Hardhat dans `tokenizerRendu/code/` | ⏳ |
+| **3** | *(à venir)* | Contrat BEP-20 + tests | ⏳ |
+| **4** | *(à venir)* | Dossier `deployment/` + deploy + BscScan | ⏳ |
+| **5** | *(à venir)* | `documentation/` utilisateur + README école (choix, adresse) | ⏳ |
+| **6** | *(à venir)* | Démo minimale + préparation code review | ⏳ |
+| **7** | *(à venir)* | Bonus multisig (optionnel) | ⏳ |
+
+## 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)

docs/sujets/tokenizer.md

@@ -131,9 +131,21 @@ Pour créer un token, plusieurs exigences techniques et organisationnelles s’a
 | **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.) |
+| **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.
@@ -245,7 +257,7 @@ Ces points ne sont pas toujours explicites dans le PDF ; ils servent de fil cond
 | Terme | En bref |
 |-------|---------|
 | **Token** | Contrat intelligent qui suit une norme (souvent **20** : solde, `transfer`, `approve`, etc.) |
-| **BEP-20 / ERC-20** | Interface standard ; sur BSC testnet, BscScan reconnaît les tokens BEP-20 |
+| **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. |