evm

README.md

@@ -0,0 +1,58 @@
+# 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)).

docs/README.md

@@ -0,0 +1,31 @@
+# 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)

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

@@ -0,0 +1,50 @@
+# 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) |

docs/pedagogie/01-apports-pedagogiques.md

@@ -0,0 +1,86 @@
+# 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)

docs/pedagogie/02-web3-comprendre.md

@@ -0,0 +1,563 @@
+# 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).*

docs/pedagogie/03-hardhat-et-alternatives.md

@@ -0,0 +1,160 @@
+# 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)

docs/pedagogie/README.md

@@ -0,0 +1,79 @@
+# 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).

docs/pedagogie/audit-rendu-tokenizer.md

@@ -0,0 +1,108 @@
+# 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)

docs/pedagogie/checklist-demo-evaluation.md

@@ -0,0 +1,68 @@
+# 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.*

docs/pedagogie/decisions-projet.md

@@ -0,0 +1,130 @@
+# 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`.

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

@@ -0,0 +1,231 @@
+# É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)

docs/pedagogie/etapes/etape-02-init-hardhat.md

@@ -0,0 +1,316 @@
+# É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-)

docs/pedagogie/etapes/etape-04-deploy-testnet.md

@@ -0,0 +1,75 @@
+# É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)

docs/pedagogie/fiche-soutenance-tokenizer.md

@@ -0,0 +1,798 @@
+# Fiche de soutenance — Tokenizer (FGC42Forge)
+
+> Fichier **perso**, hors dépôt école. Il sert à **réexpliquer le projet à voix haute** après une pause.
+> Le correcteur, lui, ne voit que `tokenizerRendu/` (README, `code/`, `deployment/`, `documentation/`).
+
+Lis les sections 1 à 4 pour le récit. La section 5 pose le vocabulaire. La section **6.5** résume **toute la stack** (définition + emboîtement). Les sections 6 à 10 détaillent choix, Solidity, outils et fabrication. La section 12 est le script de démo. La section 13 est la revue de code, fichier par fichier.
+
+---
+
+## 1. Ce que tu as fait, en une histoire
+
+Le sujet 42 *Tokenizer* (v1.1), en partenariat avec **BNB Chain**, demande de créer un **jeton numérique** sur une blockchain publique, **sans argent réel**, de le déployer, de documenter comment on l’utilise, et de pouvoir expliquer le code.
+
+Tu as créé **FGC42Forge**, symbole **FG42**. C’est un jeton **fongible** : une unité en vaut une autre, comme des pièces identiques, pas comme un NFT unique. Sur BNB Smart Chain, ce standard s’appelle **BEP-20**. Techniquement, le code est celui d’un **ERC-20** Ethereum, parce que BSC est une chaîne **EVM** (machine virtuelle Ethereum — voir section 5) : elle exécute les mêmes smart contracts Solidity qu’Ethereum. BscScan affiche « BEP-20 » à cause de la chaîne, pas parce que tu as écrit une norme différente.
+
+**1 000 000 FG42** ont été créés **une seule fois**, au moment du déploiement, et envoyés au compte qui a déployé. Ensuite, plus personne ne peut en fabriquer. On ne peut que les **transférer**. Il n’y a pas de fonction `burn` (destruction), pas de pause, pas de liste noire.
+
+Le contrat est déjà en ligne sur **BNB Smart Chain Testnet** (identifiant de chaîne **97**), à l’adresse :
+
+`0x0c76df26A1149fDc22C8f994975705271b070fF4`
+
+Le compte qui a payé le déploiement et qui est devenu `owner` s’appelle **FGC_account** :
+
+`0xB6bE1878BfaF1FFC8503E752b1D733Ad7b93603c`
+
+Transaction de création : `0xb6a0ec09d4db0e9f0686aca6ad5d8ca71cecaf8d43405eeed214736bb8574072` (bloc `137872368`, le 2026-10-20).
+
+Le code source a été **publié et vérifié** sur BscScan : l’explorateur a recompilé le source et obtenu le **même bytecode** que celui déjà enregistré à cette adresse. Ça prouve que le programme on-chain est bien celui du dépôt.
+
+Le bonus du sujet (un **multisig** : plusieurs signatures pour une action sensible) n’a **pas** été fait. Tu l’assumes : l’obligatoire est complet, le bonus n’est noté que si l’obligatoire est parfait, et tu as choisi un contrat simple à défendre.
+
+---
+
+## 2. Deux dépôts, ne pas les mélanger
+
+| | Dépôt de travail (`main`) | Dépôt école |
+|---|---|---|
+| Où | Racine `tokenizer/` | Le **contenu** de `tokenizerRendu/` doit être la **racine** Git Vogosphere |
+| Contenu | `docs/` (cette fiche, sujet traduit, notes) + `tokenizerRendu/` | `README.md`, `code/`, `deployment/`, `documentation/` |
+| À montrer | À toi, pour réviser | Au correcteur |
+
+La branche **`rendu-tokenizer`** a volontairement **retiré** `docs/` pour ne garder que le paquet école. La fiche n’y est plus : c’est normal. Elle vit sur **`main`**, dans `docs/pedagogie/`.
+
+Sur le PC école : le Git Vogosphere doit avoir **à sa racine** le README du token, pas un dossier parent `tokenizerRendu/`. Sinon la structure demandée par le sujet n’est pas respectée.
+
+---
+
+## 3. Pitch à dire (environ une minute)
+
+« J’ai créé un token BEP-20, FGC42Forge, symbole FG42, sur le testnet public de BNB Smart Chain. Le nom contient 42, comme le demande le sujet. Il n’y a pas d’argent réel : le gas se paie en tBNB, obtenu via un faucet.
+
+Le contrat est écrit en Solidity. Je n’ai pas réécrit transfer ou balanceOf : j’hérite de l’ERC-20 d’OpenZeppelin, plus Ownable pour savoir qui est l’administrateur. Au constructeur, le contrat émet une seule fois un million de jetons vers le déployeur. Il n’existe aucune fonction publique pour en créer d’autres ensuite. L’owner peut transférer le rôle d’admin, mais il ne peut pas augmenter l’offre.
+
+J’ai développé avec Hardhat 3 : compilation, deux tests automatisés, déploiement avec Ignition. L’adresse et le réseau sont dans le README et dans deployment/addresses.json. Le contrat est vérifié sur BscScan. La démo, c’est un transfer entre deux comptes MetaMask, visible sur l’explorateur. Le bonus multisig n’est pas implémenté. »
+
+---
+
+## 4. Chiffres à avoir sous les yeux
+
+| Élément | Valeur | Où le montrer |
+|---------|--------|----------------|
+| Nom / symbole | FGC42Forge / FG42 | README, BscScan, MetaMask |
+| Réseau | BSC Testnet, chainId **97** | README, MetaMask |
+| Contrat | `0x0c76df26A1149fDc22C8f994975705271b070fF4` | README, `deployment/addresses.json` |
+| Owner / deployer | `0xB6bE1878BfaF1FFC8503E752b1D733Ad7b93603c` | `addresses.json`, BscScan |
+| Supply | 1 000 000, **18 décimales** | contrat `INITIAL_SUPPLY`, page token |
+| Page contrat | https://testnet.bscscan.com/address/0x0c76df26A1149fDc22C8f994975705271b070fF4 | onglet Contract = code vérifié |
+| Page token | https://testnet.bscscan.com/token/0x0c76df26A1149fDc22C8f994975705271b070fF4 | supply, holders, transfers |
+| Tests | 2 tests Mocha, tous verts | `code/test/FGC42Forge.ts` |
+
+### Chain ID — testnet **97** vs mainnet **56** (BNB Smart Chain)
+
+Oui : pour **BNB Smart Chain** (BSC), les identifiants officiels sont :
+
+| Réseau | Chain ID | Monnaie gas | Explorateur | Projet FGC42Forge |
+|--------|----------|-------------|-------------|-------------------|
+| **BSC Testnet** | **97** | **tBNB** (sans valeur réelle) | `testnet.bscscan.com` | **Oui** — seul réseau utilisé |
+| **BSC Mainnet** | **56** | **BNB** (vraie valeur) | `bscscan.com` | **Non** — sujet = pas d’argent réel |
+
+**À retenir à l’oral :**
+
+- Ton contrat et tes FG42 existent **uniquement** sur le testnet (**97**). Rien n’est déployé sur le mainnet (**56**).
+- MetaMask doit afficher **BNB Smart Chain Testnet** et **97** avant toute démo. Si tu es sur **56**, tu ne verras pas le bon contrat ni les bons FG42 (autre chaîne, autre état).
+- Ton **adresse compte** `0xB6bE…` est la **même** sur 97 et 56 (même clé EVM), mais les soldes et les contrats ne sont **pas** les mêmes : le testnet et le mainnet sont deux registres séparés.
+- Pour comparaison (hors BSC) : Ethereum mainnet = chainId **1**. Ce n’est pas la chaîne du projet, mais le même type d’adresse `0x`.
+
+Les valeurs **97** et **56** sont dans le README, `deployment/addresses.json` (`chainId: 97`) et la config MetaMask documentée dans `documentation/README.md`.
+
+**18 décimales** : en interne la blockchain ne stocke pas « 1,5 FG42 ». Elle stocke un entier. 1 FG42 affiché = `1 * 10^18` unités. Le million du constructeur, c’est donc `1_000_000 * 10^18`. MetaMask fait la conversion pour l’affichage. Si on oublie les décimales, on croit transférer 1 jeton alors qu’on transfère une fraction infime, ou l’inverse.
+
+---
+
+## 5. Les notions, assez pour les expliquer
+
+### EVM (Ethereum Virtual Machine)
+
+**EVM** = **Ethereum Virtual Machine** (machine virtuelle Ethereum).
+
+En bref : c’est le **moteur d’exécution** qui fait tourner les **smart contracts** sur une blockchain compatible. Quand tu déploies `FGC42Forge`, ce n’est pas ton PC qui exécute le code en permanence : chaque nœud du réseau **BSC Testnet** possède une EVM qui exécute le **bytecode** du contrat quand quelqu’un appelle `transfer`, `balanceOf`, etc.
+
+| Idée | Explication simple |
+|------|-------------------|
+| **À quoi ça sert** | Exécuter du code **déterministe** et **partagé** : même entrée → même résultat pour tous les validateurs du réseau. |
+| **Lien avec Solidity** | Tu écris en **Solidity** ; le compilateur **solc** (via Hardhat) produit du **bytecode EVM** + une **ABI**. C’est ce bytecode qui est stocké on-chain à l’adresse du contrat. |
+| **Chaînes « EVM »** | Blockchains qui parlent le **même langage machine** qu’Ethereum : **Ethereum**, **BNB Smart Chain**, Polygon, etc. |
+| **Ton projet** | **BSC Testnet (chainId 97)** est une chaîne EVM → tu peux utiliser **Solidity**, **OpenZeppelin ERC20**, **MetaMask**, **adresses `0x…`**. |
+| **BEP-20 vs ERC-20** | **ERC-20** = nom de la norme côté Ethereum / Solidity. **BEP-20** = même logique sur BNB Chain ; l’explorateur BscScan affiche BEP-20 parce que la **chaîne** est BSC, pas parce que le code Solidity change. |
+| **Adresse wallet** | Sur toutes les chaînes EVM, **la même clé** donne **la même adresse** `0x…` (ex. FGC_account). En revanche, **chaque chainId** (97, 56, 1…) a son **propre registre** : soldes et contrats ne sont pas partagés entre testnet et mainnet. |
+| **Ce que l’EVM n’est pas** | Ce n’est pas Bitcoin (autre modèle, pas Solidity). Ce n’est pas Hardhat ni MetaMask : ce sont des outils **autour** de l’EVM. |
+
+**Phrase soutenance (EVM en 20 s)** : « BSC est une blockchain **compatible EVM** : on écrit en Solidity, le bytecode s’exécute comme sur Ethereum. Mon token suit l’interface ERC-20 dans le code ; sur le testnet BSC, on l’appelle un **BEP-20**. »
+
+**Où le voir dans le dépôt** : contrat `code/contracts/FGC42Forge.sol` ; réseau `chainId: 97` dans `deployment/addresses.json` et `hardhat.config.ts` (`bscTestnet`).
+
+---
+
+### Blockchain, compte, contrat
+
+Une blockchain publique est un registre partagé. Une **transaction** est un ordre signé (déployer un contrat, transférer des jetons) que le réseau exécute et enregistre.
+
+Une **adresse `0x` + 40 hex** identifie soit un **compte** (contrôlé par une clé privée, comme FGC_account), soit un **contrat** (un programme dont le bytecode est stocké à cette adresse). Les deux se ressemblent. La différence : un compte a une clé ; un contrat a du code.
+
+**Gas** : chaque écriture coûte du calcul au réseau. On le paie dans la monnaie **native** de la chaîne, pas dans FG42. Sur le testnet, cette monnaie s’appelle **tBNB**. Elle n’a pas de valeur réelle. On l’obtient par le faucet BNB Chain (site ou bot Telegram officiel). Sans tBNB, MetaMask ne peut ni déployer ni envoyer de FG42 : le jeton bouge, mais la transaction elle-même se paie en tBNB.
+
+**Testnet vs mainnet** : le testnet est une chaîne publique de répétition. Le sujet interdit d’exiger de l’argent réel. Tu n’as rien déployé sur le mainnet BSC (chainId 56). Ne branche pas MetaMask sur le mainnet pendant la démo.
+
+**RPC** : l’URL d’un nœud qui parle au réseau (`https://data-seed-prebsc-1-s1.binance.org:8545/`). MetaMask et Hardhat utilisent tous les deux un RPC pour lire les soldes et envoyer des transactions. Ce n’est pas un secret.
+
+### Token, ERC-20, BEP-20
+
+Un **token** ici n’est pas un fichier. C’est un contrat qui tient une table « adresse → solde » et des fonctions standard :
+
+- `name`, `symbol`, `decimals` : l’identité affichée
+- `totalSupply` : combien d’unités existent
+- `balanceOf(compte)` : le solde d’une adresse
+- `transfer(destinataire, montant)` : l’expéditeur envoie ses propres jetons
+- `approve` + `transferFrom` : autoriser un tiers à dépenser jusqu’à un plafond (`allowance`)
+
+**Fongible** : le solde est un nombre. 100 FG42 de A valent 100 FG42 de B. Un NFT (ERC-721) serait un objet numéroté : hors sujet.
+
+**ERC-20** est la norme Ethereum. **BEP-20** est le même contrat d’interface sur BNB Chain. Dans le code tu importes `ERC20` d’OpenZeppelin. À l’oral tu dis : « standard BEP-20, implémenté avec l’ERC-20 OpenZeppelin, déployé sur BSC ».
+
+Le **nom** `FGC42Forge` contient **42** (obligation du sujet). FGC = tes initiales, Forge = les jetons sont « forgés » une fois au déploiement. Le **symbole** (ticker) est `FG42`, celui qu’on publie sur l’explorateur.
+
+### Mint, supply fixe, owner
+
+**Mint** = créer des jetons et augmenter `totalSupply`. OpenZeppelin fournit `_mint`, une fonction **interne** : seul le contrat peut l’appeler, pas un utilisateur depuis MetaMask.
+
+Dans ton constructeur, `_mint(msg.sender, INITIAL_SUPPLY)` s’exécute **une fois**, quand la transaction de déploiement crée le contrat. `msg.sender` est le compte qui paie cette transaction, donc FGC_account. Après ça, aucune fonction publique ne rappelle `_mint`. L’offre est figée.
+
+**Ownable** ajoute un `owner`. Au départ c’est aussi le déployeur (`Ownable(msg.sender)`). Il peut `transferOwnership` (donner l’admin à une autre adresse) ou `renounceOwnership` (plus personne n’est owner). Dans **ce** contrat, être owner ne donne **aucun** pouvoir sur les jetons : il n’y a pas de `onlyOwner` sur un mint, pas de taxe, pas de gel. Si on te demande « à quoi sert l’owner alors ? », la réponse honnête est : le rôle existe parce que le modèle OpenZeppelin le pose, et pour montrer que tu as réfléchi aux privilèges ; il n’augmente pas l’offre. Un owner compromis ne peut pas imprimer des FG42 avec ce contrat. Il pourrait seulement céder le rôle vide, ou tu pourrais plus tard ajouter des fonctions `onlyOwner` — ce que tu n’as pas fait.
+
+### Clé privée, seed, .env
+
+La **seed** (12 ou 24 mots) et la **clé privée** contrôlent le compte. L’adresse `0xB6bE…` est publique, on peut la mettre dans le README. La clé ne doit jamais être dans Git, sur un slide, ni à l’écran en soutenance.
+
+Hardhat, pour déployer, a besoin de signer. La clé du compte **de test** est dans `code/.env`, fichier ignoré par Git. Le modèle commité est `code/.env.example` : il montre les noms de variables, pas le secret. `PRIVATE_KEY` est la clé (64 hex), **pas** l’adresse du wallet. Confondre les deux est l’erreur classique : Hardhat ne peut pas signer avec une adresse.
+
+MetaMask garde la même clé dans l’extension. Hardhat et MetaMask peuvent être le **même** compte (FGC_account) : l’un signe en ligne de commande, l’autre signe dans le navigateur.
+
+---
+
+## 6. Pourquoi cette stack (le « pourquoi » du README)
+
+Le sujet demande d’expliquer les choix, pas seulement de lister des outils.
+
+**BNB Smart Chain Testnet.** Le PDF est en partenariat BNB. La chaîne supporte les smart contracts, elle est publique, l’explorateur est BscScan, le gas de test est gratuit via faucet. Ethereum testnet aurait été valable avec un ERC-20, à justifier. Tu as suivi la piste du partenaire.
+
+**Solidity.** C’est le langage des contrats EVM. Le fichier évalué est `tokenizerRendu/code/contracts/FGC42Forge.sol`. Version du projet : **0.8.34** (`pragma` et `hardhat.config.ts`). Les versions 0.8.x empêchent par défaut certains overflows d’entiers.
+
+**OpenZeppelin.** Bibliothèque auditée. Réécrire `transfer` soi-même est le meilleur moyen d’introduire un bug (oubli d’événement, mauvais calcul de solde, pas de protection sur le destinataire zéro). Tu composes un contrat court par-dessus un standard connu.
+
+**Hardhat 3.** Outil Node.js qui compile Solidity, lance des tests et parle au réseau. Le sujet cite aussi Remix, Truffle, Foundry. Tu peux les nommer :
+
+- **Remix** : IDE dans le navigateur, bien pour un contrat isolé, moins pratique pour un dépôt avec tests reproductibles.
+- **Truffle** : ancien framework compile / migrate / test, peu actif face à Hardhat.
+- **Foundry** : outils en Rust (`forge`), très rapides ; tu es resté sur Node parce que le projet Hardhat couvre compile, test et deploy.
+
+Hardhat se lance **depuis `code/`**, parce que `hardhat.config.ts` est là. À la racine du dépôt, `npx hardhat` répond « No Hardhat config file found ». Ce n’est pas une panne.
+
+**Ignition.** Système de déploiement de Hardhat. Le fichier `code/ignition/modules/FGC42Forge.ts` dit : « déploie le contrat FGC42Forge ». Il n’y a pas d’argument de constructeur : le constructeur Solidity n’en prend pas. La commande :
+
+```bash
+cd code
+npx hardhat ignition deploy --network bscTestnet ignition/modules/FGC42Forge.ts
+```
+
+`--network bscTestnet` choisit l’entrée du `hardhat.config.ts` : URL RPC + compte `PRIVATE_KEY`. Sans ce flag, Hardhat ne va pas sur BSC.
+
+**Mocha + ethers.** Mocha est le lanceur de tests. ethers.js est la bibliothèque qui déploie le contrat sur une **chaîne simulée locale** pendant `npx hardhat test`. Ces tests ne coûtent pas de tBNB et ne touchent pas le contrat déjà en ligne. Ils prouvent le comportement **avant** ou **à côté** du déploiement public.
+
+**TypeScript.** La config Hardhat, le module Ignition et les tests sont en `.ts`. Le contrat, lui, reste en Solidity. Ce ne sont pas deux langages pour la même chose : Solidity = programme on-chain ; TypeScript = outillage autour.
+
+**MetaMask.** Extension navigateur. Elle n’est pas dans le dépôt. Elle sert à la **démo humaine** : importer le token par son adresse, voir le solde, cliquer Envoyer. Hardhat sert au développeur. Les deux parlent au même réseau.
+
+**BscScan.** Explorateur. Il montre l’adresse, le bytecode, les transactions, et, une fois la vérif faite, le Solidity lisible. Le sujet demande de publier le contrat sur un explorateur et de mettre l’adresse dans Git. La vérification du source n’est pas écrite mot pour mot dans le PDF ; c’est la preuve que tu montres en review.
+
+→ Détail outil par outil et **emboîtement** : section **6.5** ci-dessous (à réviser avant la soutenance).
+
+---
+
+## 6.5 Stack complète — définition, rôles, emboîtement
+
+Cette section reprend chaque brique du projet : **ce que c’est**, **son rôle pour FGC42Forge**, **où ça vit dans le dépôt**, et **comment ça s’enchaîne** avec le reste. Tu peux t’en servir comme trame si l’évaluateur demande « explique-moi ta toolchain ».
+
+### Vue d’ensemble (schéma)
+
+```
+Solidity (FGC42Forge.sol)   →  décrit le token (règles on-chain : supply, transfer…)
+        ↓ import
+OpenZeppelin (ERC20, Ownable) →  code standard audité, compilé avec ton fichier
+        ↓ compile / test / deploy
+Hardhat 3                     →  atelier sur ta machine (Node.js) : solc, tests, réseau
+        ├─ Ignition           →  sous-partie Hardhat : déploiement reproductible
+        └─ toolbox            →  Mocha (lance les tests) + ethers (parle au contrat)
+        ↓ transaction signée
+BSC Testnet (chainId 97)      →  enregistre le bytecode à l’adresse 0x0c76…0fF4
+        ↓ lecture publique
+BscScan                       →  explorateur : tx, token, source vérifié
+MetaMask                      →  wallet utilisateur : import FG42, transfer, gas en tBNB
+```
+
+**Flux en une phrase :** tu **décris** le jeton en Solidity, tu **t’appuies** sur OpenZeppelin, **Hardhat** compile et teste hors ligne puis **déploie** via Ignition ; le résultat est **public** sur le testnet ; **BscScan** le prouve ; **MetaMask** montre l’usage réel sans Hardhat.
+
+**Point clé soutenance :** après le deploy, le token **ne dépend plus** de Hardhat ni de ton PC. Hardhat a servi à **fabriquer** le contrat ; MetaMask + BscScan servent à **montrer** qu’il vit on-chain.
+
+---
+
+### Solidity — `code/contracts/FGC42Forge.sol`
+
+| | |
+|---|---|
+| **C’est quoi ?** | Langage des smart contracts **EVM**. Ton contrat est le **programme** exécuté par les nœuds de BSC. |
+| **Rôle dans le projet** | Définit **FGC42Forge** : nom, symbole, supply fixe au constructeur, héritage ERC20 + Ownable. **C’est le cœur du sujet** (code review). |
+| **Où / comment** | `pragma solidity ^0.8.34` ; une cinquantaine de lignes ; pas de `mint` public. |
+| **Ce que ce n’est pas** | Pas le langage des tests (TypeScript) ni de la config Hardhat. |
+| **Qui compile** | **Hardhat** appelle **solc** → bytecode + ABI. |
+| **Phrase soutenance** | « Le livrable on-chain est un contrat Solidity minimal : constructeur qui mint une fois un million FG42 au déployeur, le reste c’est l’ERC-20 OpenZeppelin. » |
+
+---
+
+### OpenZeppelin — `@openzeppelin/contracts`
+
+| | |
+|---|---|
+| **C’est quoi ?** | Bibliothèque Solidity **auditée**, installée via npm (`dependencies` dans `package.json`). |
+| **Rôle dans le projet** | Fournit **`ERC20`** (BEP-20 fonctionnel) et **`Ownable`** (admin sans mint dans ton design). Tu n’as pas réécrit `transfer` / `balanceOf`. |
+| **Où / comment** | `import {ERC20} from "..."` et `import {Ownable} from "..."` dans `FGC42Forge.sol`. |
+| **Ce que ce n’est pas** | Pas un outil qui tourne à part : du **code source** fusionné au tien à la compilation. |
+| **Lien suivant** | Le compilateur (via Hardhat) inclut ces fichiers ; **BscScan** voit tout via `FGC42Forge_flat.sol`. |
+| **Phrase soutenance** | « J’ai choisi OpenZeppelin pour respecter le standard sans réinventer les fonctions sensibles. » |
+
+#### Détail OpenZeppelin — paquet, ERC20, Ownable (v5)
+
+**Installation.** Paquet npm `@openzeppelin/contracts` (version **5.x**, ex. `^5.6.1` dans `package.json`). Installé avec `npm install @openzeppelin/contracts`. Les fichiers `.sol` vivent dans `node_modules/@openzeppelin/contracts/` ; tu ne les édites pas. Au **deploy**, le compilateur **fusionne** ton contrat et OpenZeppelin en **un seul bytecode** à l’adresse `0x0c76…` : il n’y a pas un « contrat OpenZeppelin » séparé sur la chaîne, seulement **FGC42Forge** qui contient ce code.
+
+**Pourquoi OpenZeppelin plutôt que tout écrire ?** L’ERC-20 est une norme avec des détails faciles à rater (soldes, `allowance`, événements `Transfer` / `Approval`, protection contre transfert vers adresse nulle, `revert` si solde insuffisant). OpenZeppelin est une implémentation **largement utilisée et auditée** ; le sujet attend un standard de chaîne (BEP-20), pas une réécriture amateur de `transfer`.
+
+**Classe `ERC20` — ce que ton contrat hérite (tu ne le réécris pas dans `FGC42Forge.sol`) :**
+
+| Fonction / donnée | Rôle | Utilisé en démo ? |
+|-------------------|------|-------------------|
+| `name()` | `FGC42Forge` | Oui — MetaMask, BscScan |
+| `symbol()` | `FG42` | Oui |
+| `decimals()` | `18` (défaut OZ) | Oui — affichage wallet |
+| `totalSupply()` | 1 000 000 × 10¹⁸ après le constructeur | Oui — page token |
+| `balanceOf(adresse)` | Solde d’un compte | Oui |
+| `transfer(dest, amount)` | Envoyer ses propres jetons | Oui — MetaMask |
+| `approve(spender, amount)` | Autoriser un tiers à dépenser | Non en démo (hérité, standard) |
+| `transferFrom(...)` | Dépense via `allowance` | Non en démo (hérité) |
+| `allowance(owner, spender)` | Plafond d’autorisation | Non en démo |
+| Événement `Transfer` | Trace from / to / value | Oui — test Hardhat + BscScan |
+| `_mint(account, amount)` | **Interne** — créer des jetons | **Une fois** dans ton constructeur |
+
+Tu appelles **`_mint` une seule fois** dans le constructeur. OpenZeppelin ne te force pas à exposer un `mint()` public : tant que tu n’ajoutes pas de fonction publique qui rappelle `_mint`, personne ne peut augmenter l’offre après le deploy.
+
+**Classe `Ownable` (OpenZeppelin v5) — administration :**
+
+| Élément | Comportement dans FGC42Forge |
+|---------|------------------------------|
+| Constructeur `Ownable(msg.sender)` | Le **déployeur** devient `owner` dès le deploy |
+| `owner()` | Lecture de l’adresse admin (souvent FGC_account) |
+| `transferOwnership(nouveau)` | L’owner peut céder le rôle (personne ne peut mint FG42 via ça) |
+| `renounceOwnership()` | L’owner peut renoncer (plus d’owner) |
+| Modificateur `onlyOwner` | Restreint une fonction à l’owner — **tu ne l’utilises sur aucune fonction custom** |
+
+**Point soutenance :** `Ownable` montre que tu as pensé à « qui administre le contrat ». Dans **ton** design, l’owner **ne crée pas** de FG42 supplémentaires et **ne vole pas** les soldes : il n’y a pas de fonction sensible protégée par `onlyOwner` dans ton fichier.
+
+**v4 vs v5 (piège classique).** En OpenZeppelin **v5**, `Ownable` exige l’owner initial dans le constructeur : `Ownable(msg.sender)`. En v4, le owner était parfois fixé différemment. Ton code est aligné **v5**.
+
+**BEP-20 vs ERC20 dans le dépôt.** Tu importes le symbole Solidity **`ERC20`**. Sur BSC, l’explorateur et la doc parlent **BEP-20** pour le même comportement. Ce n’est pas un second fichier `BEP20.sol` à écrire.
+
+**Où voir tout le code OZ en correction ?** `deployment/FGC42Forge_flat.sol` (résultat de `hardhat flatten`) contient FGC42Forge + ERC20 + Ownable + dépendances, dans l’ordre, pour BscScan.
+
+---
+
+### Hardhat 3 — dossier `code/`
+
+| | |
+|---|---|
+| **C’est quoi ?** | **Toolchain** Node.js pour smart contracts EVM : compiler, tester, connecter aux RPC, tâches CLI. |
+| **Rôle dans le projet** | Compile `FGC42Forge.sol`, lance **2 tests** locaux, configure **bscTestnet**, supporte **Ignition** et **flatten** pour BscScan. |
+| **Où / comment** | `hardhat.config.ts` ; commandes depuis **`code/`** uniquement (`npx hardhat build`, `test`, `ignition deploy`). |
+| **Ce que ce n’est pas** | Ni wallet, ni blockchain, ni explorateur. **Pas nécessaire** pour utiliser FG42 après deploy. |
+| **Alternatives (sujet)** | Remix (navigateur), Truffle (legacy), Foundry (Rust) — tu as gardé Hardhat pour tests + deploy dans un repo Git. |
+| **Phrase soutenance** | « Hardhat est mon atelier : compile, teste sur chaîne simulée, et envoie le deploy sur le testnet avec ma clé dans le .env local. » |
+
+---
+
+### Hardhat Ignition — `code/ignition/modules/FGC42Forge.ts`
+
+| | |
+|---|---|
+| **C’est quoi ?** | Sous-système **Hardhat** de déploiement **déclaratif** (module TypeScript = « quoi déployer »). |
+| **Rôle dans le projet** | Une ligne : `m.contract("FGC42Forge")`. Pas d’args → constructeur Solidity vide de paramètres. Produit la tx de **création** du contrat. |
+| **Où / comment** | `npx hardhat ignition deploy --network bscTestnet ignition/modules/FGC42Forge.ts` |
+| **Ce que ce n’est pas** | Pas le contrat lui-même ; pas l’adresse officielle dans Git (c’est **`deployment/addresses.json`**). |
+| **Piège** | Redéployer = **nouvelle** adresse. En eval, tu montres le contrat **déjà** à `0x0c76…`. |
+| **Phrase soutenance** | « Ignition automatise le deploy : le même module peut le reproduire, mais mon rendu documente l’adresse déjà en production sur le testnet. » |
+
+---
+
+### ethers.js + Mocha — `code/test/FGC42Forge.ts`
+
+| | |
+|---|---|
+| **C’est quoi ?** | **Mocha** : framework qui exécute les tests (`describe` / `it`). **ethers** : bibliothèque pour déployer et appeler des contrats (adresses, signatures, appels de fonctions). |
+| **Rôle dans le projet** | Hardhat 3 les branche via `hardhat-toolbox-mocha-ethers`. Tests : métadonnées + supply au deployer + **transfer** + événement `Transfer`. |
+| **Où / comment** | `await network.create()` puis `ethers.deployContract("FGC42Forge")` ; `npx hardhat test --grep FGC42Forge` → **2 passing**. |
+| **Ce que ce n’est pas** | Pas on-chain pendant les tests : chaîne **simulée** dans le processus Hardhat, **sans** tBNB. |
+| **Lien avec MetaMask** | Même logique d’appel (`transfer`), mais en test c’est **ethers** qui signe avec des comptes fictifs Hardhat. |
+| **Phrase soutenance** | « Les tests Mocha + ethers valident le comportement ERC-20 avant ou en parallèle du deploy réel, sans coût de gas. » |
+
+---
+
+### MetaMask — hors dépôt Git
+
+| | |
+|---|---|
+| **C’est quoi ?** | Extension **wallet** : comptes `0x…`, réseaux (chainId), signature de transactions, affichage des tokens. |
+| **Rôle dans le projet** | **Démo utilisateur** : réseau BSC Testnet (97), import FG42 par **adresse du contrat**, **transfer** entre comptes (ex. FGC_account → demo). Gas en **tBNB**, pas en FG42. |
+| **Où / comment** | Procédure dans `tokenizerRendu/documentation/README.md`. Même RPC que `BSC_TESTNET_RPC` dans `.env`. |
+| **Ce que ce n’est pas** | Pas utilisé pour compiler ni pour le premier deploy (Hardhat + `PRIVATE_KEY` dans `.env`). |
+| **Lien avec Hardhat** | Peut être le **même** compte (FGC_account) : clé dans MetaMask **et** dans `.env` pour Ignition — jamais la clé dans Git. |
+| **Phrase soutenance** | « MetaMask prouve qu’un utilisateur peut importer FG42 et transférer ; Hardhat, lui, prouve que le code est correct en amont. » |
+
+---
+
+### BscScan — explorateur testnet
+
+| | |
+|---|---|
+| **C’est quoi ?** | **Explorateur de blocs** pour BNB Chain : adresses, transactions, contrats, pages **token** BEP-20. |
+| **Rôle dans le projet** | Preuve **publique** : tx de création, supply 1M, transfers ; onglet **Contract** avec **source vérifié** (flatten + optimizer 200). |
+| **Où / comment** | URLs dans README et `deployment/addresses.json` ; fiche technique `deployment/BSCSCAN_VERIFICATION.md`. |
+| **Ce que ce n’est pas** | Pas un outil de développement : tu ne « codes » pas dessus ; tu **publies** et **montres**. |
+| **Lien avec Hardhat** | `npx hardhat flatten` → `FGC42Forge_flat.sol` pour le formulaire « Verify & Publish ». |
+| **Phrase soutenance** | « BscScan est la vitrine du sujet : adresse dans Git, contrat visible et vérifié, historique des transfers pour la démo. » |
+
+---
+
+### Tableau récap — qui fait quoi, quand ?
+
+| Étape | Outil(s) | Machine / lieu |
+|-------|----------|----------------|
+| Écrire le token | Solidity + OpenZeppelin | Fichiers dans `code/contracts/` |
+| Vérifier sans gas | Hardhat + Mocha + ethers | Local, `npx hardhat test` |
+| Mettre en ligne | Hardhat + Ignition + `.env` | Tx vers BSC Testnet |
+| Enregistrer la preuve | `addresses.json`, README | Git rendu |
+| Prouver le source | Hardhat flatten + BscScan | Web |
+| Montrer l’usage | MetaMask + BscScan | Navigateur, soutenance |
+
+---
+
+### Phrase d’ensemble (45 s) — toolchain complète
+
+« Mon token est défini en **Solidity** dans `FGC42Forge.sol`, en m’appuyant sur **OpenZeppelin** pour l’ERC-20 et Ownable. **Hardhat** compile ce code, **Mocha** et **ethers** passent deux tests sur une chaîne locale, puis **Ignition** a déployé sur **BSC Testnet**. L’adresse est dans le README et `deployment/addresses.json`. **BscScan** affiche le contrat vérifié et les transfers. Pour la démo, **MetaMask** importe FG42 et envoie des jetons ; le gas reste en tBNB. Une fois déployé, le jeton vit sur la chaîne : Hardhat n’est plus nécessaire pour l’utiliser. »
+
+---
+
+## 7. Solidity, le langage du contrat
+
+Solidity est le langage dans lequel est écrit **uniquement** le programme qui vit sur la chaîne : `code/contracts/FGC42Forge.sol`. Ce n’est pas le langage des tests ni de la config. Il a été créé pour l’Ethereum Virtual Machine. BSC exécute ce même type de bytecode, donc le même langage sert pour un BEP-20.
+
+Tu l’écris dans un fichier `.sol`. Hardhat appelle le compilateur **solc**, qui produit du **bytecode** (le binaire déployé) et une **ABI** (la liste des fonctions que MetaMask et ethers savent appeler). Une fois la transaction de déploiement incluse dans un bloc, ce bytecode est figé à une adresse. Modifier le `.sol` sur ton disque ne modifie pas le contrat déjà en ligne : il faudrait déployer un **nouveau** contrat, donc une nouvelle adresse.
+
+### À quoi ressemble le langage
+
+Un contrat ressemble à une classe. Il a un état (des variables gardées sur la chaîne) et des fonctions.
+
+Les mots que tu dois pouvoir définir devant le fichier :
+
+| Mot dans ton code | Sens |
+|-------------------|------|
+| `pragma solidity ^0.8.34` | Le fichier se compile avec un solc 0.8 à partir de 0.8.34. Le `^` interdit la branche 0.9. En 0.8, un dépassement d’entier annule la transaction au lieu de boucler silencieusement. |
+| `SPDX-License-Identifier: MIT` | Licence du source. BscScan la demande au moment de la vérif. |
+| `import {ERC20} from "..."` | Le compilateur va lire un autre fichier. Ici, la bibliothèque OpenZeppelin installée dans `node_modules`. Tu n’as pas recopié `transfer` à la main. |
+| `contract FGC42Forge is ERC20, Ownable` | Déclare le programme. `is` veut dire héritage : FGC42Forge possède les variables et les fonctions de ERC20 et de Ownable. |
+| `uint256` | Entier non signé de 256 bits. Les soldes et les montants sont toujours des entiers. Solidity n’a pas de nombres à virgule. |
+| `address` | Un compte ou un contrat, 20 octets, affiché `0x` + 40 hex. |
+| `string` | Texte. Le nom et le symbole sont des `string`, stockés par le constructeur d’ERC20. |
+| `private constant` | `constant` : valeur fixée à la compilation, pas un stockage coûteux qui change. `private` : aucune autre contrat ni aucun appel extérieur ne peut lire cette variable directement. Le million, lui, est visible via `totalSupply()`, qui est public. |
+| `constructor` | Fonction appelée **une seule fois**, dans la transaction qui crée le contrat. Après, elle n’existe plus comme fonction appelable. |
+| `msg.sender` | L’adresse qui a signé la transaction en cours. Dans le constructeur, c’est le déployeur. Dans `transfer`, c’est celui qui envoie ses jetons. |
+| `_mint(...)` | Fonction **interne** d’OpenZeppelin (le `_` est une convention). Seul ton contrat peut l’appeler. Un utilisateur MetaMask ne peut pas l’appeler de l’extérieur. |
+
+Visibilités à connaître même si tu ne les as pas toutes écrites :
+
+- `public` : appelable de l’extérieur et depuis le contrat. `name()`, `transfer()`, `owner()` sont publics.
+- `external` : appelable seulement de l’extérieur.
+- `internal` : le contrat et ses héritiers. `_mint` est internal.
+- `private` : ce fichier seulement.
+
+Une fonction qui ne fait que lire (`view`, comme `balanceOf`) ne coûte pas de gas quand on l’appelle via un nœud pour afficher un solde. Une fonction qui écrit (`transfer`, le constructeur) est une transaction : elle est signée, payée en tBNB, et enregistrée dans un bloc.
+
+Si une condition échoue, Solidity **annule toute la transaction** (`revert`). OpenZeppelin le fait quand on transfère plus que son solde. L’état d’avant est restauré. Le gas déjà consommé n’est pas rendu.
+
+Les **événements** (`event Transfer`) n’ajoutent pas de logique. Ils laissent une trace dans le reçu de la transaction. BscScan s’en sert pour l’onglet Transfers. Ton test vérifie que `transfer` émet bien cet événement.
+
+Dans ERC20, les soldes sont un `mapping(address => uint256)` : une table adresse → montant. Tu ne l’as pas écrite. Elle est dans OpenZeppelin. `balanceOf` lit cette table. `transfer` soustrait chez l’expéditeur et ajoute chez le destinataire.
+
+`1_000_000 * (10 ** 18)` : les underscores sont seulement visuels (un million). `10 ** 18` est l’exposant. Comme `decimals()` vaut 18, un wallet qui affiche « 1 FG42 » divise l’entier interne par 10^18.
+
+### Ce que tu as choisi de ne pas écrire
+
+Tu n’as pas redéfini `transfer`, `approve`, `transferFrom`. Les redéfinir est utile pour une taxe ou une liste noire ; ici ça n’apporterait qu’un risque de bug. Le fichier reste court : héritage, constante, constructeur.
+
+Tu n’as pas ajouté `function mint(address to, uint256 amount) public onlyOwner`. Cette fonction existe dans d’autres jetons (OpenZeppelin `ERC20Preset` ou un mint manuel). L’ajouter aurait rendu l’offre diluable. Le sujet demande de réfléchir aux privilèges : ton choix est « le seul privilège de création est le déploiement lui-même ».
+
+---
+
+## 8. Les outils, un par un, et comment tu t’en es servi
+
+Rien de tout cela n’est « la blockchain ». Ce sont les instruments pour écrire le contrat, le tester, le payer, et le montrer.
+
+### Node.js et npm
+
+**Node.js** exécute du JavaScript sur ta machine. **npm** installe les bibliothèques listées dans `code/package.json`.
+
+Tu t’en sers ainsi, dans `tokenizerRendu/code/` :
+
+```bash
+node -v          # doit répondre, idéalement 18 ou plus
+npm install      # lit package.json et package-lock.json, crée node_modules/
+```
+
+`node_modules/` n’est pas dans Git : trop gros, et régénérable. Sur une autre machine, `npm install` suffit. Hardhat, ethers, Mocha, TypeScript, OpenZeppelin et dotenv arrivent par là.
+
+`npx hardhat ...` lance le binaire Hardhat **de ce** `node_modules`, pas un Hardhat installé ailleurs sur l’ordinateur.
+
+### MetaMask
+
+Extension de navigateur. Elle garde la seed et les clés, affiche les réseaux, signe les transactions.
+
+Comment tu l’as utilisé :
+
+1. Créer un compte dédié, nommé **FGC_account**. Son adresse publique est `0xB6bE1878BfaF1FFC8503E752b1D733Ad7b93603c`. Cette adresse est la même sur toutes les chaînes EVM. Ce qui change, c’est le réseau sélectionné en haut de MetaMask (chainId 97 pour le testnet BSC, 56 pour le mainnet BSC, 1 pour Ethereum). Les soldes ne se mélangent pas.
+2. Ajouter le réseau à la main si besoin : nom « BNB Smart Chain Testnet », RPC `https://data-seed-prebsc-1-s1.binance.org:8545/`, chain ID `97`, symbole `tBNB`, explorateur `https://testnet.bscscan.com`.
+3. Obtenir du **tBNB** : coller l’adresse publique dans le faucet BNB (site ou bot Telegram officiel). Ce n’est pas un bouton « générer » dans MetaMask. Le faucet envoie une transaction vers toi.
+4. Pour la démo : menu Tokens → Importer, coller l’adresse **du contrat** `0x0c76…0fF4`. MetaMask interroge `symbol()` et `decimals()` et affiche FG42. Puis Envoyer vers un second compte. MetaMask demande une signature ; le gas est prélevé en tBNB.
+
+La seed et la clé privée s’affichent dans MetaMask → détails du compte. Tu les copies **une fois** dans `code/.env` pour que Hardhat puisse signer. Tu ne les mets ni dans Git, ni dans la fiche, ni à l’écran en soutenance.
+
+Bitcoin n’utilise pas cette adresse `0x`. Un wallet Bitcoin, même avec la même seed, dérive une autre clé et une adresse du type `bc1…`.
+
+### Faucet
+
+Page ou bot qui envoie du tBNB à une adresse de test. Sans ce solde, le déploiement et les transfers échouent faute de gas. Les FG42 ne paient pas le gas.
+
+### Hardhat 3
+
+Framework dans `code/`. Il ne déploie rien tant que tu ne lui demandes pas un réseau.
+
+Mise en place, une fois, dans `code/` :
+
+```bash
+npm init -y
+npm install --save-dev hardhat
+npx hardhat --init
+```
+
+Sur Hardhat 3, l’assistant s’appelle `npx hardhat --init` (avec les deux tirets). Il pose des questions (toolbox Mocha + ethers) et crée `hardhat.config.ts`, `contracts/`, `test/`, `ignition/`, plus un exemple **Counter** que tu as laissé. Le token évalué n’est pas Counter.
+
+Ensuite tu installes la bibliothèque de contrats et le lecteur de `.env` :
+
+```bash
+npm install @openzeppelin/contracts dotenv
+```
+
+OpenZeppelin est une **dépendance de production** (`dependencies` dans `package.json`) parce que le source du token l’importe. Hardhat, Mocha, TypeScript sont en `devDependencies` : ils servent à compiler et tester, ils ne sont pas déployés on-chain. Seul le bytecode compilé part sur la chaîne.
+
+Le fichier `hardhat.config.ts` dit trois choses : plugin de tests, version Solidity 0.8.34, et le réseau `bscTestnet` (URL + clé lues dans `.env`).
+
+Usage quotidien :
+
+| Action | Commande dans `code/` |
+|--------|------------------------|
+| Compiler | `npx hardhat build` |
+| Tester sans réseau | `npx hardhat test --grep FGC42Forge` |
+| Déployer pour de vrai | `npx hardhat ignition deploy --network bscTestnet ignition/modules/FGC42Forge.ts` |
+| Fusionner les sources pour BscScan | `npx hardhat flatten contracts/FGC42Forge.sol` |
+
+`--network bscTestnet` est le nom que **tu** as donné dans la config. Il ne faut pas l’inventer au moment de la commande.
+
+Les tests utilisent une chaîne simulée dans le processus Hardhat. Ils ne consomment pas le tBNB et n’écrivent pas à l’adresse `0x0c76…`.
+
+### dotenv et `.env`
+
+`import "dotenv/config"` dans la config charge `code/.env` au lancement. Deux variables :
+
+- `BSC_TESTNET_RPC` : l’URL du nœud, la même famille que dans MetaMask. Publique.
+- `PRIVATE_KEY` : la clé du compte qui signe, 64 hex, **pas** l’adresse `0xB6bE…`. Si tu colles l’adresse, Hardhat ne peut pas signer.
+
+`.env.example` est commité avec des valeurs vides ou l’URL publique. `.env` est dans `.gitignore`.
+
+### TypeScript, Mocha, Chai, ethers
+
+Les fichiers `.ts` ne sont pas déployés.
+
+- **TypeScript** : JavaScript avec types. Config, module Ignition, tests.
+- **Mocha** : lance les `describe` / `it` de `test/FGC42Forge.ts`.
+- **Chai** : `expect(...).to.equal(...)`.
+- **ethers v6** : parle à la chaîne. Dans les tests, `ethers.deployContract("FGC42Forge")` déploie sur le réseau simulé. `token.transfer(...)` appelle la fonction du contrat. Hardhat 3 expose ethers via `await network.create()`, pas via un `hre.ethers` global de Hardhat 2.
+
+### OpenZeppelin
+
+→ **Détail complet** (ERC20, Ownable, tableau des fonctions, v5) : section **6.5**, sous-partie **« Détail OpenZeppelin »**.
+
+En bref : `@openzeppelin/contracts` v5 ; imports `ERC20` + `Ownable` ; `_mint` une fois au constructeur ; pas de `mint` public.
+
+### Hardhat Ignition
+
+Fichier `ignition/modules/FGC42Forge.ts`. C’est un petit programme TypeScript qui décrit le déploiement : « crée un contrat nommé FGC42Forge ». Comme le constructeur Solidity n’a pas de paramètre, le module n’en passe pas.
+
+Ignition envoie la transaction, attend le reçu, et note l’adresse. Cette adresse de **ce** déploiement est recopiée à la main dans `deployment/addresses.json` et le README. Relancer Ignition créerait un **second** contrat, à une autre adresse, avec un nouveau million de jetons. En soutenance tu ne relances pas le deploy : le contrat à montrer est celui déjà vérifié.
+
+### BscScan
+
+Site `testnet.bscscan.com`. Tu l’utilises pour :
+
+- coller l’adresse et voir la transaction de création ;
+- ouvrir l’onglet token (supply, holders, transfers) ;
+- vérifier le source : Contract → Verify and publish → Solidity single file → coller `FGC42Forge_flat.sol`, optimizer Yes, 200 runs, licence MIT, constructeur vide.
+
+L’explorateur recompile. Si le bytecode obtenu est celui déjà stocké à l’adresse, il affiche le source. C’est la preuve que le dépôt correspond au programme on-chain.
+
+---
+
+## 9. Création du jeton, dans l’ordre
+
+C’est le chemin que tu racontes si on te demande « comment tu as procédé ». Chaque étape a un résultat visible.
+
+### Étape A — Décider avant d’écrire
+
+Tu fixes, par écrit, ce que le contrat devra respecter :
+
+- chaîne : BSC Testnet, chainId 97, gas en tBNB ;
+- nom `FGC42Forge` (contient 42), symbole `FG42` ;
+- standard BEP-20 via OpenZeppelin ERC20 ;
+- 1 000 000 jetons, 18 décimales, mint une seule fois au déployeur ;
+- pas de mint public, pas de burn, pas de multisig.
+
+Ces choix sont ceux du README. Les changer après le déploiement ne change pas le contrat déjà en ligne.
+
+### Étape B — Le compte qui paiera
+
+1. Installer MetaMask, créer **FGC_account**.
+2. Ajouter le réseau BSC Testnet (chainId 97, RPC, symbole tBNB).
+3. Copier l’adresse publique dans le faucet et attendre le tBNB.
+4. Vérifier sur BscScan que l’adresse a un solde tBNB. Sans ça, l’étape F échoue.
+
+### Étape C — L’atelier Hardhat
+
+```bash
+cd tokenizerRendu/code
+npm init -y
+npm install --save-dev hardhat
+npx hardhat --init
+npm install @openzeppelin/contracts dotenv
+```
+
+Tu copies `.env.example` vers `.env`. Dans MetaMask : détails du compte → afficher la clé privée. Tu la mets dans `PRIVATE_KEY`. Tu vérifies que `hardhat.config.ts` a bien le bloc `bscTestnet` avec `BSC_TESTNET_RPC` et `PRIVATE_KEY`.
+
+`npx hardhat build` doit passer. À ce stade le seul contrat est encore l’exemple Counter. C’est normal.
+
+### Étape D — Écrire le contrat
+
+Tu crées `contracts/FGC42Forge.sol` :
+
+1. Licence MIT et `pragma solidity ^0.8.34`.
+2. Importer `ERC20` et `Ownable`.
+3. `contract FGC42Forge is ERC20, Ownable`.
+4. Constante `INITIAL_SUPPLY = 1_000_000 * (10 ** 18)`.
+5. Constructeur : `ERC20("FGC42Forge", "FG42")`, `Ownable(msg.sender)`, puis `_mint(msg.sender, INITIAL_SUPPLY)`.
+
+Tu n’ajoutes pas d’autre fonction. `npx hardhat build` doit recompiler sans erreur. Une erreur d’import veut dire qu’OpenZeppelin n’est pas installé ou que le chemin est faux. Une erreur sur `Ownable()` sans argument voudrait dire une vieille version 4 : en v5 l’owner initial est obligatoire.
+
+### Étape E — Prouver le comportement avant de payer du gas
+
+Tu écris `test/FGC42Forge.ts` (les deux scénarios de la section 11). Puis :
+
+```bash
+npx hardhat test --grep FGC42Forge
+```
+
+Tu attends « 2 passing ». Si un test échoue, tu corriges le `.sol` **avant** le déploiement. Un contrat déjà déployé ne se corrige pas sur place.
+
+### Étape F — Déployer
+
+Le compte du `.env` doit être celui qui a le tBNB (FGC_account).
+
+```bash
+npx hardhat ignition deploy --network bscTestnet ignition/modules/FGC42Forge.ts
+```
+
+Hardhat affiche une estimation de gas et demande confirmation. La transaction part vers le RPC BSC. Le réseau l’inclut dans un bloc. Ignition affiche l’adresse du nouveau contrat.
+
+Cette adresse (`0x0c76df26A1149fDc22C8f994975705271b070fF4`) n’existait pas avant. Le constructeur s’est exécuté dans cette transaction : FGC_account a reçu 1 000 000 FG42 et est devenu `owner`. Tu retrouves la tx `0xb6a0ec09…4072` sur BscScan.
+
+Tu recopies réseau, chainId, adresse, deployer, hash et bloc dans `deployment/addresses.json` et dans le tableau du README. C’est cette copie qui est le livrable Git, pas le cache `ignition/deployments/`.
+
+### Étape G — Vérifier le source sur BscScan
+
+```bash
+npx hardhat flatten contracts/FGC42Forge.sol > ../deployment/FGC42Forge_flat.sol
+```
+
+Sur testnet.bscscan.com, page du contrat → Verify and Publish :
+
+- compilateur : single file ;
+- optimiser : oui, 200 runs ;
+- licence MIT ;
+- pas d’argument de constructeur ;
+- coller le fichier aplati ;
+- le nom du contrat à cocher est `FGC42Forge` (le fichier contient aussi les contrats OpenZeppelin).
+
+Quand le bytecode matche, l’onglet Contract devient lisible. Le `pragma` local est 0.8.34 ; l’interface BscScan peut afficher `v0.8.24+commit.89d56535`. Tu t’en tiens au fait : la vérif a réussi, le détail est dans `deployment/BSCSCAN_VERIFICATION.md`.
+
+### Étape H — Le rendre utilisable par quelqu’un d’autre
+
+1. Dans MetaMask, importer le token par l’adresse du contrat.
+2. Envoyer par exemple 100 FG42 vers un second compte de test.
+3. Montrer le transfer sur la page token BscScan. `totalSupply` reste 1 000 000.
+4. Écrire `documentation/README.md` : ce qu’est le jeton, le réseau, l’adresse, les clics MetaMask, les limites (pas de mint, pas de valeur réelle).
+
+À partir de là le sujet est couvert : code commenté, déploiement public, adresse dans le dépôt, explorateur, doc d’utilisation, démo de transfer.
+
+---
+
+## 10. Ce que font les commandes
+
+Toutes les commandes Hardhat : d’abord `cd` dans `tokenizerRendu/code` (sur le dépôt de travail) ou `code/` (si la racine Git école est déjà le rendu).
+
+| Commande | Ce qu’elle fait vraiment |
+|----------|--------------------------|
+| `npm install` | Télécharge Hardhat, OpenZeppelin, ethers, Mocha, décrits dans `package.json`. Crée `node_modules/`, qui n’est pas commité. |
+| `cp .env.example .env` | Prépare les secrets locaux. À éditer à la main. Inutile pour les tests seuls. Indispensable pour un **nouveau** deploy. |
+| `npx hardhat build` | Compile les `.sol`. Hardhat télécharge le compilateur solc si besoin. Produit des artefacts locaux (`artifacts/`, ignorés). |
+| `npx hardhat test --grep FGC42Forge` | Lance **uniquement** les 2 tests du token. Résultat attendu : 2 passing. |
+| `npx hardhat test` | Lance aussi les tests du fichier **Counter**, un exemple livré par `hardhat --init`. Ce n’est pas ton token. Si un correcteur le voit, tu dis que c’est le template, le livrable est FGC42Forge. |
+| `npx hardhat ignition deploy --network bscTestnet …` | Envoie la transaction de création sur le testnet. Coûte du tBNB. Crée une **nouvelle** adresse de contrat. Le déploiement **déjà fait** n’a pas besoin d’être rejoué en soutenance. |
+| `npx hardhat flatten contracts/FGC42Forge.sol` | Colle ton fichier et les sources OpenZeppelin importées en **un seul** fichier. C’est `deployment/FGC42Forge_flat.sol`, utilisé pour la vérif BscScan en mode « single file ». |
+
+`npx` exécute le Hardhat **du projet**, pas un Hardhat installé au hasard sur la machine.
+
+---
+
+## 11. Les deux tests, phrase par phrase
+
+Fichier : `tokenizerRendu/code/test/FGC42Forge.ts`.
+
+Hardhat 3 ouvre une chaîne locale avec `await network.create()`, puis `ethers`. Personne n’est sur Internet.
+
+**Test 1 — « expose le nom, le symbole et la supply fixe au déployeur ».**  
+Il déploie FGC42Forge avec le premier compte de test. Il vérifie `name == FGC42Forge`, `symbol == FG42`, `decimals == 18`, `totalSupply` égal au million en unités internes, ce solde entièrement chez le déployeur, et `owner()` égal à ce déployeur. Donc : identité, offre, destinataire du mint, admin.
+
+**Test 2 — « permet un transfer ERC-20 classique ».**  
+Deux comptes : déployeur et destinataire. On transfère 1000 jetons (encore fois 10^18). Le test vérifie l’événement `Transfer` (from, to, montant) et que la somme des deux soldes n’a pas changé : le destinataire a +1000, le déployeur a supply − 1000. Ça montre qu’un transfer **déplace** des jetons, il n’en crée pas.
+
+Ce que les tests ne couvrent pas, et que tu peux dire si on te le demande : `approve` / `transferFrom` (hérités, non redéfinis), l’échec d’un transfer plus gros que le solde (OpenZeppelin revert), le comportement sur le vrai testnet. La démo MetaMask couvre le transfer réel.
+
+---
+
+## 12. Déroulé oral et démo
+
+Prépare avant : MetaMask sur **BNB Smart Chain Testnet**, FGC_account avec un peu de tBNB et des FG42, un second compte (demo) avec le token importé, trois onglets (README du rendu, page contrat `#code`, page token).
+
+| Moment | Tu ouvres | Tu expliques |
+|--------|-----------|----------------|
+| 1 | `tokenizerRendu/README.md` | Le sujet, le nom avec 42, la chaîne, l’adresse, les 5 choix techniques |
+| 2 | `documentation/README.md` | Un tiers peut importer FG42 et envoyer sans lire Solidity. Sécurité : testnet, pas de mint, owner limité |
+| 3 | BscScan page **token** | Supply 1 000 000, historique de transfers |
+| 4 | BscScan page **contrat**, onglet Contract | Code vérifié, correspond au dépôt |
+| 5 | MetaMask | Transfer d’un petit montant (100 FG42) vers le second compte. Le gas est en tBNB |
+| 6 | BscScan Transfers | La tx apparaît ; le second solde a augmenté ; `totalSupply` n’a pas bougé |
+| 7 | `code/contracts/FGC42Forge.sol` | Revue ligne à ligne, section 13 |
+| 8 | Si on le demande | `cd code && npx hardhat test --grep FGC42Forge` |
+
+Phrase de fin sur ce que le projet t’a appris (le chapitre III du sujet) : écrire un contrat Solidity, le faire vivre sur une chaîne publique (adresse, gas, explorateur), et raisonner sur qui a le droit de créer des jetons.
+
+Si MetaMask ou le faucet bloque le jour J : la page token a déjà des transfers passés (démo déjà faite FGC_account → demo_account). Tu montres l’historique et tu dis que le réseau de test est parfois capricieux. Mieux vaut que le live marche ; l’historique est le filet.
+
+---
+
+## 13. Revue de code — quoi dire devant chaque fichier
+
+### `code/contracts/FGC42Forge.sol` (le seul fichier qui compte vraiment)
+
+Le fichier fait une cinquantaine de lignes. Presque tout le comportement est **hérité**.
+
+1. `SPDX-License-Identifier: MIT` et `pragma solidity ^0.8.34` : licence, et compilateur 0.8.34 minimum dans la famille 0.8.
+2. `import {ERC20}` et `import {Ownable}` : tu ne copies pas ces centaines de lignes dans ton fichier. Le compilateur les lit dans `node_modules/@openzeppelin`.
+3. `contract FGC42Forge is ERC20, Ownable` : ton contrat **est** un ERC-20 et **est** Ownable. Il reçoit leurs fonctions.
+4. `INITIAL_SUPPLY` est une constante : 1 million fois 10^18. `private` : lisible seulement dans ce contrat. Elle ne change jamais.
+5. Le constructeur appelle d’abord `ERC20("FGC42Forge", "FG42")` (nom et symbole stockés), puis `Ownable(msg.sender)` (admin = déployeur), puis `_mint(msg.sender, INITIAL_SUPPLY)`.
+6. Le bloc de commentaire en bas liste les fonctions héritées que tu n’as pas réécrites : `transfer`, `approve`, `transferFrom`, `balanceOf`, `owner`, `transferOwnership`, etc. Les dire montre que tu sais que « pas de code » ne veut pas dire « pas de fonction ».
+
+Question piège : « Où est écrit transfer ? » — Dans OpenZeppelin `ERC20.sol`, pas dans ton fichier. En revue tu peux ouvrir le fichier aplati `deployment/FGC42Forge_flat.sol` : tout y est dans l’ordre, y compris `function transfer`.
+
+Question piège : « Peut-on mint après ? » — Non. `_mint` n’est pas exposé. Chercher `function mint` dans ton contrat ne donne rien.
+
+Question piège : « Que se passe-t-il si je transfer plus que mon solde ? » — OpenZeppelin annule toute la transaction (revert). Les soldes restent comme avant. Le gas de l’échec est consommé.
+
+Question piège : « C’est un BEP-20 ou un ERC-20 ? » — Les deux formulations. Interface ERC-20, qualification BEP-20 parce que la chaîne est BSC.
+
+### `code/hardhat.config.ts`
+
+Il enregistre le plugin Mocha/ethers, fixe Solidity **0.8.34**, et décrit le réseau `bscTestnet` : type HTTP, URL lue dans `BSC_TESTNET_RPC`, compte lu dans `PRIVATE_KEY`. Il y a aussi deux réseaux simulés du template (`hardhatMainnet`, `hardhatOp`) : tu ne t’en sers pas pour le token.
+
+Deux profils de compilateur : `default` sans optimizer, `production` avec optimizer **activé, 200 runs**. L’optimizer réduit le bytecode. Le déploiement Ignition / la vérif BscScan utilisent l’optimizer 200. Si on recompile « à la main » sans optimizer, le bytecode ne matche pas : c’est normal, ce n’est pas le même réglage.
+
+### `code/ignition/modules/FGC42Forge.ts`
+
+`buildModule` + `m.contract("FGC42Forge")`. Pas de paramètre. Ignition envoie une transaction dont le data est le bytecode + l’appel du constructeur. Le retour `{ token }` permet à Ignition de retenir l’adresse produite.
+
+### `deployment/addresses.json`
+
+C’est la trace **versionnée** du déploiement réel : réseau, chainId, adresse, deployer, tx, bloc, drapeau `bscscanVerified`. Le dossier `code/ignition/deployments/` est un journal local, ignoré par Git. Si on te demande « où est l’adresse officielle ? », c’est ce JSON et le README, pas le cache Ignition.
+
+### `deployment/BSCSCAN_VERIFICATION.md` et `FGC42Forge_flat.sol`
+
+BscScan en mode single file ne sait pas aller chercher tes `import` dans `node_modules`. `flatten` produit un seul .sol. Tu l’as collé dans « Verify and publish », optimizer Yes, 200 runs, licence MIT, constructeur sans argument.
+
+Nuance à connaître pour ne pas te contredire : le projet **local** est en Solidity **0.8.34**. Après la vérif, BscScan **affiche** le compilateur `v0.8.24+commit.89d56535`. La vérif a réussi (bytecode identique) avec le fichier aplati et l’optimizer 200. Si on te pose la question, tu ne inventes pas : tu dis que le `pragma` du dépôt est 0.8.34, que l’écran BscScan indique 0.8.24, et que le critère qui compte est le **match de bytecode**, déjà obtenu. Le détail est dans `BSCSCAN_VERIFICATION.md`.
+
+### `documentation/README.md`
+
+Guide utilisateur, pas cours Hardhat. Présentation, réseau, import MetaMask (adresse du contrat, 18 décimales, symbole FG42), lecture BscScan, transfer, tableau sécurité, et un whitepaper court : rôle pédagogique, ce qui existe (transfer, approve), ce qui n’existe pas (mint, burn, pause, multisig).
+
+`documentation/STACK-GLOSSAIRE-ET-PARCOURS.md` est le même genre d’explications que cette fiche, mais **dans le rendu**, pour un correcteur qui n’a pas `docs/`.
+
+### Fichiers à ne pas défendre comme le projet
+
+`Counter.sol`, `Counter.t.sol`, `test/Counter.ts`, `ignition/modules/Counter.ts`, `scripts/send-op-tx.ts` : générés par l’init Hardhat. Tu peux dire que tu les as laissés. Le token du sujet est uniquement FGC42Forge.
+
+---
+
+## 14. Sécurité — réponses développées
+
+**Qui peut créer des FG42 après le deploy ?**  
+Personne. La seule création est dans le constructeur. Pas de `mint` public, pas de rôle « minter ».
+
+**L’owner est-il dangereux ?**  
+Il peut changer l’adresse `owner`. Il ne peut pas piocher dans les soldes des autres ni augmenter l’offre. Un transfer part toujours du signataire de la transaction (`msg.sender`), pas de l’owner.
+
+**Et si quelqu’un a la clé de FGC_account ?**  
+Cette personne possède les FG42 encore sur ce compte, le tBNB restant, et le rôle owner. Elle ne peut pas en fabriquer de nouveaux. C’est pour ça que la clé reste hors du Git et que le compte ne porte pas de vrais fonds.
+
+**Pourquoi pas de burn ?**  
+Pas demandé. L’offre reste à 1 000 000 pour que `totalSupply` soit un chiffre stable en démo.
+
+**Pourquoi pas de multisig ?**  
+Le bonus du chapitre V demande plusieurs signataires avant une action sensible. Tu ne l’as pas implémenté pour garder un obligatoire simple et explicable. Le README le dit. Le bonus n’est évalué que si l’obligatoire est sans faute ; tu ne le présentes pas comme fait.
+
+**Le token a-t-il une valeur ?**  
+Non. Testnet. Le dire évite la confusion avec un vrai actif.
+
+**Approve, c’est quoi le risque ?**  
+`approve(spender, montant)` autorise une autre adresse à appeler `transferFrom` sur tes jetons, dans la limite du montant. Tu ne t’en sers pas dans la démo. Si on te le demande : ne jamais approve un contrat inconnu pour une somme illimitée. Ici aucun contrat tiers n’est prévu.
+
+---
+
+## 15. Carte « on me demande X → j’ouvre Y »
+
+| On te demande | Fichier dans le rendu |
+|---------------|------------------------|
+| Choix et pourquoi | `README.md` section Choix techniques |
+| Adresse, réseau, deployer | `README.md` et `deployment/addresses.json` |
+| Utiliser le token sans coder | `documentation/README.md` |
+| Définition Hardhat, MetaMask, alternatives | `documentation/STACK-GLOSSAIRE-ET-PARCOURS.md` |
+| Le programme du jeton | `code/contracts/FGC42Forge.sol` |
+| Preuve automatique | `code/test/FGC42Forge.ts` |
+| Comment c’est compilé et sur quel réseau | `code/hardhat.config.ts` |
+| Comment redéployer | `code/ignition/modules/FGC42Forge.ts` et `deployment/README.md` |
+| Preuve explorateur | `deployment/BSCSCAN_VERIFICATION.md` |
+| Le source tel que BscScan l’a reçu | `deployment/FGC42Forge_flat.sol` |
+
+Grille des obligations du PDF (nom avec 42, testnet, 3 dossiers, README, code commenté, démo, doc utilisateur) : [`sujet-exigences-rendu.md`](sujet-exigences-rendu.md). Checklist clics : [`checklist-demo-evaluation.md`](checklist-demo-evaluation.md).

docs/pedagogie/guide-realisation.md

@@ -0,0 +1,211 @@
+# 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)

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 | ✅ **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)

docs/pedagogie/ressources-solidity-hardhat.md

@@ -0,0 +1,163 @@
+# 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.*

docs/pedagogie/sujet-exigences-rendu.md

@@ -0,0 +1,122 @@
+# 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)

docs/sujets/README.md

@@ -0,0 +1,9 @@
+# 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/`).

docs/sujets/tokenizer.md

@@ -0,0 +1,273 @@
+# 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)

tokenizerRendu/code/.agents/skills/hardhat-toolbox-mocha-ethers/SKILL.md

@@ -0,0 +1,119 @@
+---
+name: hardhat-toolbox-mocha-ethers
+description: Use alongside the `hardhat` skill when the project depends on `@nomicfoundation/hardhat-toolbox-mocha-ethers`. Covers the ethers helpers exposed on `network.create()`, contract interaction (`ethers.deployContract`, calling functions, `connect`), TypeChain-typed contract instances, and the chai matchers from `@nomicfoundation/hardhat-ethers-chai-matchers` (`.to.emit`, `.to.be.revertedWith*`, `.to.changeEtherBalance(s)`).
+metadata:
+  package: "@nomicfoundation/hardhat-toolbox-mocha-ethers"
+---
+
+# Hardhat toolbox: ethers + Mocha
+
+This skill builds on the core **`hardhat`** skill. Load that first for test organization, the `network.create()` shape, `networkHelpers`, fixtures, and the typechecking workflow. Everything below hangs off the connection returned by `network.create()`.
+
+This stack runs tests under **Mocha** (global `describe` / `it`) and asserts with **chai**. Mocha doesn't await `describe` callbacks, so the connection is set up at the top of the file with top-level `await`:
+
+```ts
+import { expect } from "chai";
+import { network } from "hardhat";
+
+const { ethers, networkHelpers } = await network.create();
+
+describe("Counter", function () {
+  // ...
+});
+```
+
+One connection per file is the norm. State isolation between tests comes from `loadFixture` (see the `hardhat` skill), not from creating a fresh connection per `describe`.
+
+## `ethers`: signers and contract interaction
+
+Contract types are generated by **TypeChain** from the compiled ABI. Run `hardhat build` before typechecking so the types reflect the latest contracts.
+
+```ts
+// Provider (read-only chain data)
+const blockNumber = await ethers.provider.getBlockNumber();
+const balance = await ethers.provider.getBalance("0xabc...");
+
+// Signers (for sending transactions)
+const [owner, alice, bob] = await ethers.getSigners(); // default funded accounts
+
+// Utilities
+const oneEth = ethers.parseEther("1.0");
+
+// Deploy a contract, returns a fully typed instance.
+// Pass constructor args as the second argument, and (optionally) a signer
+// other than the default as the third.
+const counter = await ethers.deployContract("Counter");
+const counterWithArgs = await ethers.deployContract("Counter", [42n]);
+const counterFromAlice = await ethers.deployContract("Counter", [], alice);
+
+// Read state and call functions. Args and return types are type-checked
+// against the ABI at compile time; passing wrong types or wrong argument
+// counts is a TypeScript error.
+const value = await counter.x();
+await counter.inc();
+await counter.incBy(3n);
+
+// Send from a different signer
+await counter.connect(alice).inc();
+
+// Send ETH along with a payable call
+await counter.deposit({ value: oneEth });
+
+// Attach to an already-deployed contract
+const existing = await ethers.getContractAt("Counter", "0xabc...");
+```
+
+Inside a `loadFixture` setup function (see the `hardhat` skill for the surrounding pattern), `ethers.deployContract` is the canonical deploy step:
+
+```ts
+async function deployCounterFixture() {
+  const counter = await ethers.deployContract("Counter");
+  return { counter };
+}
+
+const { counter } = await networkHelpers.loadFixture(deployCounterFixture);
+```
+
+To send a transaction from an arbitrary address (not one of the default-funded accounts), fund it for gas and pull an impersonating signer with `ethers.getImpersonatedSigner` — it handles the impersonation internally, no separate `networkHelpers.impersonateAccount` call needed:
+
+```ts
+const addr = "0xaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa";
+await networkHelpers.setBalance(addr, ethers.parseEther("1.0"));
+const signer = await ethers.getImpersonatedSigner(addr);
+await counter.connect(signer).inc();
+```
+
+## Chai matchers: Ethereum-specific assertions
+
+The `hardhat-ethers-chai-matchers` plugin extends chai's `expect` with matchers for transactions, events, and balance changes. Pass the **transaction promise** (the result of a write call, unawaited) into `expect`:
+
+```ts
+import { expect } from "chai";
+
+// Reverts
+await expect(counter.connect(banned).inc()).to.revert(ethers);
+await expect(counter.connect(banned).inc()).to.be.revertedWith(
+  "only the owner can increment the counter",
+);
+await expect(counter.connect(banned).inc()).to.be.revertedWithCustomError(
+  counter,
+  "Unauthorized",
+);
+await expect(counter.connect(banned).inc())
+  .to.be.revertedWithCustomError(counter, "Unauthorized")
+  .withArgs(banned.address);
+
+// Events
+await expect(counter.inc()).to.emit(counter, "Increment");
+await expect(counter.inc()).to.emit(counter, "Increment").withArgs(1n);
+
+// ETH balance changes (positive = received, negative = spent, before gas)
+await expect(game.claim()).to.changeEtherBalance(ethers, winner, PRIZE);
+await expect(game.claim()).to.changeEtherBalances(
+  ethers,
+  [winner, loser],
+  [PRIZE, -STAKE],
+);
+```
+
+For plain assertions (equality, arrays, types), use `expect` from chai directly without the Ethereum matchers.

tokenizerRendu/code/.agents/skills/hardhat/SKILL.md

@@ -0,0 +1,152 @@
+---
+name: hardhat
+description: Use when working with Hardhat 3 projects — writing or modifying Solidity tests, TypeScript tests, or any code touching hardhat.config.ts, the `hardhat` import, or `network.create()`. Covers test-layer choice, forge-std cheatcodes, the network connection API, `networkHelpers`, and the compile-then-typecheck workflow. For toolbox-specific guidance (clients, contract calls, assertions), also load the matching `hardhat-toolbox-*` skill.
+metadata:
+  package: "hardhat"
+---
+
+# Hardhat 3
+
+This skill covers Hardhat 3 itself. The toolbox layer (clients, contract interaction, ecosystem-specific assertions) lives in companion skills — load whichever matches the project:
+
+- `@nomicfoundation/hardhat-toolbox-viem` → also load the **`hardhat-toolbox-viem`** skill.
+- `@nomicfoundation/hardhat-toolbox-mocha-ethers` → also load the **`hardhat-toolbox-mocha-ethers`** skill.
+
+## Test organization
+
+Hardhat 3 supports two distinct test layers:
+
+**Solidity tests** (`.t.sol` files in `contracts/`, or any `.sol` file in `test/`) are the default choice for unit tests on individual contracts. They run directly in the EVM, compile-check against the real ABI, and have access to cheatcodes for EVM state manipulation. Any public function whose name starts with `test` is executed as a test case.
+
+**TypeScript tests** (`.ts` files in `test/`) are the right choice when a test requires off-chain orchestration: multi-contract interactions, fixture reuse across a large suite, assertions about gas or ETH balances from the outside, or integration scenarios driven by external state.
+
+Reach for TypeScript only when Solidity isn't enough. Solidity tests cover all contract logic; TypeScript tests cover the end-to-end flow as a user or script would experience it.
+
+```bash
+hardhat test            # run all tests (Solidity + TypeScript)
+hardhat test solidity   # Solidity tests only
+```
+
+TypeScript tests are run either with `hardhat test nodejs` or with `hardhat test mocha`, depending on the toolbox or plugins being used: the viem-based toolbox uses `nodejs` while the ethers+mocha toolbox uses `mocha`.
+
+Pass `--coverage` to collect Solidity coverage while running tests. It works on the main `hardhat test` task as well as the `solidity` and TypeScript subtasks (`nodejs` / `mocha`), so you can scope coverage to a single test layer when needed.
+
+## Solidity tests
+
+Any contract that contains at least one `test*` function is treated as a test contract. Use `forge-std` (if present in `package.json`) for assertions and cheatcodes:
+
+```solidity
+// SPDX-License-Identifier: UNLICENSED
+pragma solidity ^0.8.28;
+
+import { Test } from "forge-std/Test.sol";
+import { Counter } from "./Counter.sol";
+
+contract CounterTest is Test {
+  Counter counter;
+
+  function setUp() public {
+    counter = new Counter();
+  }
+
+  function test_InitialValueIsZero() public view {
+    assertEq(counter.x(), 0);
+  }
+
+  function test_IncByIncreasesByAmount() public {
+    counter.incBy(3);
+    assertEq(counter.x(), 3);
+  }
+
+  // Fuzz test: Hardhat runs this with many random inputs automatically
+  function testFuzz_Inc(uint8 x) public {
+    for (uint8 i = 0; i < x; i++) {
+      counter.inc();
+    }
+    require(counter.x() == x, "Value after calling inc x times should be x");
+  }
+}
+```
+
+The `vm` object (from `forge-std/Test.sol`) exposes cheatcodes for EVM state manipulation. Commonly used ones:
+
+| Cheatcode | Effect |
+| --- | --- |
+| `vm.prank(addr)` | Sets `msg.sender` for the next call only |
+| `vm.startPrank(addr)` / `vm.stopPrank()` | Sets `msg.sender` for a range of calls |
+| `vm.deal(addr, amount)` | Sets an account's ETH balance |
+| `vm.warp(timestamp)` | Sets `block.timestamp` |
+| `vm.roll(blockNum)` | Sets `block.number` |
+| `vm.expectRevert(...)` | Asserts the next call reverts |
+| `vm.expectEmit(...)` | Asserts the next call emits a specific event |
+
+## TypeScript tests and the network connection
+
+The central object in a TypeScript test is the **network connection**, created by `network.create()`. Toolbox plugins extend it with helper objects (e.g. `viem` or `ethers`, plus `networkHelpers`):
+
+```ts
+import { network } from "hardhat";
+
+const { networkHelpers } = await network.create();
+// Toolbox plugins also expose viem / ethers on this object;
+// see the matching hardhat-toolbox-* skill.
+```
+
+Hardhat 3 only works with ESM, so top-level `await` is available. Each call to `network.create()` produces an **isolated blockchain state**. A top-level network connection can be used when the same connection and its associated state can be shared across all tests in the file. For more isolation, you can create a new connection for each test suite or even each test case.
+
+### `networkHelpers`: EVM state manipulation
+
+`networkHelpers` wraps all of Hardhat's development-only helpers behind a typed, ergonomic API. Prefer it over raw JSON-RPC calls:
+
+```ts
+// Time
+await networkHelpers.time.increase(60); // mine a block 60 s ahead
+await networkHelpers.time.increaseTo(target); // mine to a specific timestamp
+const now = await networkHelpers.time.latest(); // latest block timestamp
+await networkHelpers.time.setNextBlockTimestamp(ts); // set without mining
+
+// Blocks
+await networkHelpers.mine(); // mine one block
+await networkHelpers.mine(5); // mine several blocks
+
+// Accounts
+await networkHelpers.impersonateAccount(addr);
+await networkHelpers.setBalance(addr, 10n ** 18n);
+
+// Block parameters
+await networkHelpers.setPrevRandao(value); // set block.prevrandao for the next block
+await networkHelpers.setNextBlockBaseFeePerGas(baseFee);
+
+// Fixtures
+//
+// loadFixture runs the setup once and snapshots the state. Subsequent calls
+// restore the snapshot instead of re-deploying, much faster for large suites.
+// The deploy step inside the fixture is toolbox-specific (e.g.
+// viem.deployContract, an ethers ContractFactory) — see the matching
+// hardhat-toolbox-* skill.
+async function deployCounter() {
+  // ... toolbox-specific deploy ...
+  return { counter };
+}
+
+const { counter } = await networkHelpers.loadFixture(deployCounter);
+// loadFixture requires a named function for caching to work (not an
+// arrow/anonymous function)
+
+// Snapshots (manual)
+const snap = await networkHelpers.takeSnapshot();
+// ... do things ...
+await snap.restore();
+```
+
+For plain TypeScript assertions (equality, arrays, types), use `node:assert/strict`. For ecosystem-specific assertions (reverts, events, balance changes), see the matching `hardhat-toolbox-*` skill.
+
+## Typechecking
+
+Generated contract types are derived from the compiled ABI (viem in the viem toolbox, TypeChain in the ethers toolbox), so recompile first, then typecheck. The example below uses npm; swap `npx` for whichever package manager runner this project uses:
+
+```bash
+npx hardhat build && npx tsc --noEmit
+```
+
+The compiler will catch wrong argument types, missing arguments, and invalid options (e.g. `value` on a non-payable function) before you even start the test runner. Make this a habit: it surfaces many mistakes faster than running the full test suite.

tokenizerRendu/code/.claude

@@ -0,0 +1 @@
+.agents

tokenizerRendu/code/AGENTS.md

@@ -0,0 +1,20 @@
+# Hardhat + ethers project
+
+## Project layout
+
+```
+contracts/        Solidity source files (*.sol) and unit tests (*.t.sol)
+test/             TypeScript integration tests and Solidity unit tests (*.sol)
+ignition/         Hardhat Ignition deployment modules
+scripts/          Standalone scripts run with `hardhat run`
+hardhat.config.ts
+```
+
+## Working in this project
+
+When writing or modifying tests, configuring `hardhat.config.ts`, or interacting with the network from TypeScript, invoke the **`hardhat`** skill. It covers Solidity and TypeScript testing, how to choose between them, `forge-std` cheatcodes, the `network.create()` API, `networkHelpers`, and the compile-then-typecheck workflow. The skill itself points to the matching `hardhat-toolbox-*` skill for toolbox-specific guidance (signers, contract interaction, assertions).
+
+## Docs
+
+- Hardhat 3 — https://hardhat.org/llms.txt
+- ethers.js — https://docs.ethers.org/v6/

tokenizerRendu/code/CLAUDE.md

@@ -0,0 +1 @@
+AGENTS.md