87 lines
4.6 KiB
Markdown
87 lines
4.6 KiB
Markdown
# 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)
|