miseneplace

docs/pedagogie/02-web3-comprendre.md

@@ -43,7 +43,7 @@ Plusieurs machines (nœuds) maintiennent une **copie** (ou une vue) du même reg
 
 ### 3.2 Blockchain
 
-Chaîne de **blocs** liés par empreintes cryptographiques ; chaque bloc contient des **transactions** (ou des exécutions de contrats). Consensus (PoS, PoA, etc.) définit qui peut proposer le bloc suivant.
+Chaîne de **blocs** liés par empreintes cryptographiques ; chaque bloc contient des **transactions** (ou des exécutions de contrats). **Consensus** (PoW, PoS, PoA, PoSA…) définit qui peut proposer le bloc suivant — voir [§ 6.6](#66-consensus-de-la-chaîne-pow-pos-poa-et-variantes).
 
 - **BNB Chain** (sujet Tokenizer) est une de ces chaînes, orientée **smart contracts** et volume d’usage.
 
@@ -55,9 +55,19 @@ Programme déployé à une **adresse** sur la chaîne. Une fois publié, son cod
 
 ### 3.4 Token
 
-Actif numérique défini par un contrat : soldes par adresse, transferts, parfois mint/burn. Un token peut représenter une **unité de compte** (style monnaie), des **parts**, ou un rôle dans un protocole — selon ce que **tu documentes**.
+Actif numérique défini par un contrat : soldes par adresse, transferts, parfois **mint** / **burn**. Un token peut représenter une **unité de compte** (style monnaie), des **parts**, ou un rôle dans un protocole — selon ce que **tu documentes**.
+
+| Action | Effet sur la supply |
+|--------|---------------------|
+| **Mint** | **Crée** des tokens et les crédite à une adresse → `totalSupply` **augmente** |
+| **Burn** | **Détruit** des tokens → `totalSupply` **diminue** |
+| **Transfer** | Déplace des tokens existants → la supply **ne change pas** |
+
+Au **déploiement**, beaucoup de contrats créent toute la supply dans le constructeur (**supply fixe**, pas de `mint` après). D’autres gardent une fonction `mint()` — souvent réservée au **`owner`** (`onlyOwner`).
 
 - **Contrainte 42 :** le **nom** doit contenir `42` ; le ticker et l’usage sont à toi (dans le cadre du sujet).
+- **Mint « illimité »** : voir [§ 7.1](#71-mint-et-mint-illimité).
+- **Supply, owner, Ownable, onlyOwner** : voir [§ 7.2](#72-glossaire-anglais--supply-owner-ownable-onlyowner).
 
 ### 3.5 Wallet (portefeuille)
 
@@ -82,6 +92,31 @@ Frais payés dans la **monnaie native** de la chaîne (BNB sur BSC, ETH sur Ethe
 
 Site qui indexe chaîne : adresses, transactions, code vérifié du contrat. Obligatoire pour **prouver** le déploiement et le ticker en soutenance.
 
+### 3.9 Réseau RPC
+
+**RPC** (*Remote Procedure Call*) = façon pour un programme (wallet, Hardhat, Remix) de **parler à un nœud** de la blockchain via une **URL HTTP(S)**.
+
+La blockchain ne tourne pas sur ton PC : des **nœuds** répartis sur Internet maintiennent le registre. Ton outil doit pourtant :
+
+- **lire** l’état (solde, `name()` du token, code d’un contrat) ;
+- **envoyer** des transactions déjà **signées** par ta clé privée (déploiement, `transfer`, etc.).
+
+Le **point d’accès RPC** est la « ligne téléphonique » vers ce réseau. Ce n’est **pas** une blockchain séparée : c’est la **porte d’entrée** vers la chaîne que tu as choisie (testnet ou mainnet).
+
+| Élément | Rôle |
+|---------|------|
+| **URL RPC** | Adresse du service/nœud (ex. endpoint BSC Testnet dans MetaMask ou `hardhat.config.js`) |
+| **Wallet / script** | Construit la tx, la signe localement, l’envoie **via** le RPC |
+| **Chaîne** | Reçoit la tx, l’exécute, met à jour l’état on-chain |
+
+**Exemple (BSC Testnet, indicatif)** — une URL publique souvent utilisée :
+
+`https://data-seed-prebsc-1-s1.binance.org:8545/`
+
+**Erreur fréquente :** RPC pointant sur le **mainnet** alors que tu crois être sur le **testnet** → tu dépenses du vrai BNB ou tu ne vois pas ton contrat de test. Vérifie **réseau + chainId** (BSC Testnet = `97`) dans le wallet et dans Hardhat.
+
+Dans le schéma ci-dessous, la boîte **« Réseau RPC »** est cette couche entre ton wallet et la **blockchain publique**.
+
 ---
 
 ## 4. Web3 et « crypto » — ne pas confondre
@@ -109,10 +144,7 @@ flowchart LR
     RPC[Réseau RPC]
     Chain[Blockchain publique]
     SC[Smart contract Token BEP-20]
-    Explorer[Explorateur BscScan]
-  end
-  User --> Browser
-  User --> Wallet
+    Explorer[Explorateur BscScan]source ~/.bashrc 
   Wallet --> RPC
   RPC --> Chain
   Chain --> SC
@@ -125,13 +157,128 @@ flowchart LR
 3. Le contrat vit à une **adresse** sur la chaîne.
 4. Tout le monde peut **lire** l’état via l’explorateur ; les détenteurs de tokens **transfèrent** via leurs wallets.
 
+**Lecture du schéma :** `Wallet → RPC → Chain` = ton MetaMask ou Hardhat envoie des requêtes à l’**URL RPC** du testnet, qui relaie vers les nœuds BSC Testnet. Détail : [§ 3.9](#39-réseau-rpc).
+
 ---
 
-## 6. Standards : pourquoi BEP-20 / ERC-20 ?
+## 6. Standards : ERC-20 et BEP-20
 
-Les blockchains compatibles **EVM** (Ethereum, BSC, etc.) partagent souvent le même modèle de contrat. **ERC-20** (Ethereum) et **BEP-20** (BSC) décrivent les mêmes idées : `balanceOf`, `transfer`, `approve`, `allowance`, événements `Transfer`, etc.
+### 6.1 C’est quoi, en une phrase ?
 
-Les wallets et explorateurs savent afficher un token **s’il respecte** ce standard. C’est pour cela que le sujet exige de respecter le standard de ta chaîne.
+**ERC-20** et **BEP-20** sont des **normes** (des « contrats types ») pour des **tokens fongibles** : chaque unité est interchangeable (comme des pièces identiques), contrairement aux NFT (ERC-721, etc.).
+
+| Norme | Chaîne concernée (exemples) |
+|-------|------------------------------|
+| **ERC-20** | **Ethereum** et la plupart des L2 EVM (Sepolia testnet, etc.) |
+| **BEP-20** | **BNB Chain** / **BSC** (*BNB Smart Chain*) — partenaire du sujet Tokenizer |
+
+Le **BEP** signifie *BNB Evolution Proposal* (propositions d’évolution de l’écosystème BNB), sur le même principe que **EIP** (*Ethereum Improvement Proposal*) pour ERC-20.
+
+### 6.2 Que impose le standard ?
+
+Ce n’est pas un fichier que tu télécharges : c’est une **interface** — ton contrat doit exposer au minimum des fonctions et événements reconnus par les wallets et explorateurs.
+
+| Fonction / événement | Rôle |
+|----------------------|------|
+| `name()`, `symbol()`, `decimals()` | Affichage dans MetaMask, BscScan, etc. |
+| `totalSupply()` | Offre totale de tokens existants |
+| `balanceOf(adresse)` | Solde d’un compte |
+| `transfer(dest, montant)` | Envoyer des tokens |
+| `approve(spender, montant)` | Autoriser un autre compte/contrat à dépenser pour toi |
+| `allowance(owner, spender)` | Combien il reste à dépenser via `approve` |
+| `transferFrom(from, to, montant)` | Dépenser pour quelqu’un qui t’a `approve` |
+| `event Transfer` | Historique on-chain des mouvements |
+
+En projet 42, on utilise presque toujours **OpenZeppelin `ERC20`** : le code respecte ERC-20 ; déployé sur **BSC**, l’explorateur le qualifie de token **BEP-20**.
+
+### 6.3 ERC-20 vs BEP-20 : même logique, nom selon la chaîne
+
+Les deux chaînes sont **compatibles EVM** (même machine virtuelle, même langage **Solidity**). Pour un token « classique », le **code est souvent identique** ; ce qui change :
+
+| | ERC-20 | BEP-20 |
+|---|--------|--------|
+| **Réseau typique Tokenizer** | Possible (ex. Sepolia) | **Recommandé** (BSC Testnet, tBNB, BscScan) |
+| **Gas** | ETH (ou ETH test) | BNB / **tBNB** |
+| **Explorateur** | Etherscan | BscScan |
+| **Standard token fongible** | ERC-20 | BEP-20 (interface équivalente) |
+
+**BEP-2** (autre norme BNB, ancienne Binance Chain) n’est **pas** le standard de ton exercice type « token ERC-20-like » sur BSC.
+
+### 6.4 Le sujet t’oblige-t-il à choisir BEP-20 ?
+
+**Non au sens « BEP-20 pour tout le monde ».** Le sujet dit :
+
+- tu **choisis** une blockchain ;
+- tu respectes **le standard de cette chaîne** (exemples : ERC-20 sur ETH, **BEP-20 sur BSC**).
+
+Donc :
+
+- **Si tu déploies sur BNB Smart Chain** → tu dois livrer un token **BEP-20** (en pratique : contrat ERC-20-compatible sur BSC).
+- **Si tu déploies sur Ethereum testnet** → **ERC-20**, avec justification dans le README.
+
+Le partenariat **42 × BNB Chain**, le faucet **tBNB** et les exemples **BscScan** orientent fortement vers **BSC testnet + BEP-20**, sans interdire formellement une autre chaîne EVM bien documentée.
+
+**Phrase utile en soutenance :**
+
+> « Mon token suit le standard **BEP-20** de BNB Chain, l’équivalent de l’**ERC-20** sur Ethereum ; j’ai utilisé OpenZeppelin ERC20 déployé sur le testnet. »
+
+### 6.5 Pourquoi le sujet insiste sur un standard ?
+
+Sans norme commune, chaque contrat aurait des noms de fonctions différents : les wallets ne pourraient pas afficher ton token ni proposer `transfer`. Le standard rend le token **lisible** par tout l’écosystème — c’est ce que l’évaluateur vérifie (comportement + code review), pas un label marketing.
+
+### 6.6 Consensus de la chaîne : PoW, PoS, PoA (et variantes)
+
+Quand le § 3.2 parle de **consensus**, il s’agit de la règle du réseau pour répondre à une question simple :
+
+> **Qui a le droit de proposer le bloc suivant**, et comment les autres nœuds **acceptent** qu’il est valide ?
+
+Tu **n’implémentes pas** ce mécanisme dans Tokenizer : tu **déploies sur une chaîne** qui l’a déjà. Comprendre PoS / PoA aide en soutenance (« sur quelle infra tourne mon token ? ») et évite de confondre **consensus réseau** et **multisig** (voir [§ 7.3](#73-multisig--types-et-lien-avec-le-bonus)).
+
+#### PoW — *Proof of Work* (preuve de travail)
+
+| | |
+|---|---|
+| **Idée** | Des **mineurs** rivalisent pour résoudre un puzzle cryptographique coûteux ; le gagnant publie le bloc et reçoit une récompense. |
+| **Forces** | Très étudié (Bitcoin) ; sécurité liée à la **puissance de calcul** globale. |
+| **Faiblesses** | **Consommation énergétique** élevée ; temps de bloc et frais variables. |
+| **Exemples** | Bitcoin ; Ethereum **avant** « The Merge » (2022). |
+
+#### PoS — *Proof of Stake* (preuve d’enjeu)
+
+| | |
+|---|---|
+| **Idée** | Des **validateurs** bloquent une **mise** (*stake*) en tokens natifs ; le protocole **désigne** qui propose le bloc ; triche possible → **pénalités** (*slashing*). |
+| **Forces** | Beaucoup moins énergivore que PoW ; modèle dominant sur les chaînes récentes. |
+| **Faiblesses** | Débats sur concentration du stake, gouvernance, MEV — hors scope Tokenizer. |
+| **Exemples** | Ethereum **depuis** The Merge ; Cardano, Polkadot, etc. |
+
+#### PoA — *Proof of Authority* (preuve d’autorité)
+
+| | |
+|---|---|
+| **Idée** | Seules des **entités identifiées** (liste fermée de validateurs / *sealers*) peuvent créer des blocs — pas de mining ni de stake ouvert comme en PoS grand public. |
+| **Forces** | Blocs **rapides**, prévisibles ; idéal pour **réseaux privés** ou **testnets d’entreprise**. |
+| **Faiblesses** | **Centralisation** assumée : il faut **faire confiance** aux autorités listées. |
+| **Exemples** | Nombreux **testnets locaux** Hardhat ; chaînes consortium (Hyperledger Besu en mode PoA, etc.). |
+
+#### Autres noms que tu peux croiser
+
+| Sigle | Signification | Lien utile |
+|-------|---------------|------------|
+| **DPoS** | *Delegated Proof of Stake* — les détenteurs **élisent** un petit nombre de délégués validateurs | Certaines chaînes grand public |
+| **PoSA** | *Proof of Staked Authority* — **mélange** : validateurs limités + mise en jeu | **BNB Smart Chain** utilise ce modèle (petit ensemble de validateurs actifs, historiquement ~21) |
+| **IBFT / QBFT** | Variantes PoA pour réseaux privés | Plutôt entreprise, pas ton deploy BSC testnet |
+
+**Pour BNB Chain (sujet Tokenizer) :** ce n’est pas du PoW ; ce n’est pas exactement le PoS « ouvert » d’Ethereum. C’est plutôt un modèle **PoSA** : validateurs connus + stake — assez pour dire en oral : « chaîne EVM avec validateurs, je suis utilisateur via testnet, pas validateur ».
+
+#### Tableau comparatif (révision)
+
+| | PoW | PoS (typique) | PoA |
+|---|-----|---------------|-----|
+| **Qui produit les blocs ?** | Mineurs (calcul) | Validateurs (stake) | Autorités désignées |
+| **Barrière à l’entrée** | Matériel + électricité | Capital en stake | Invitation / liste |
+| **Décentralisation** | Variable | Variable | Souvent **faible** (volontaire) |
+| **Ton projet** | Tu ne le choisis pas | Tu **utilises** la chaîne telle quelle | Idem (sauf réseau local perso) |
 
 ---
 
@@ -148,6 +295,180 @@ Le Web3 déplace une partie des risques vers **le code** et **les clés** :
 
 Tokenizer te demande explicitement de réfléchir à **ownership** et **privilèges** et de le montrer en **démo minimale** + **revue de code**.
 
+### 7.1 Mint et mint illimité
+
+Ce n’est **pas** le nom d’une fonction dans le code. On parle d’une **situation de gouvernance** :
+
+> Tant que le **`owner`** peut appeler `mint` **sans plafond** ni règle stricte dans le contrat, il peut **créer autant de tokens qu’il veut**, quand il veut.
+
+**Pourquoi c’est sensible (même sur testnet, pour la soutenance) :**
+
+- Si le token représente des parts ou une « monnaie » fictive, un mint massif **dilue** tous les détenteurs (comme une impression monétaire sans limite).
+- Si la **clé privée du owner** est compromise, un attaquant peut abuser de `mint`.
+- Le sujet demande d’expliquer **ownership** et **privilèges** : un `mint()` `onlyOwner` **sans** `MAX_SUPPLY` est le cas classique à **documenter** et à **assumer** dans le README école.
+
+**Pistes de design (à justifier dans ton README) :**
+
+| Approche | Idée |
+|----------|------|
+| **Supply fixe** | Toute la supply créée au deploy, **pas** de `mint` ensuite |
+| **Plafond** | `require(totalSupply() + amount <= MAX_SUPPLY)` |
+| **Mint one-shot** | Mint initial puis fonction désactivée |
+| **Bonus multisig** | Plusieurs signatures avant un mint ou avant une action owner critique |
+
+**Exemple courant (OpenZeppelin) :** `ERC20` + `Ownable` + une fonction `mint(address, uint256)` en `onlyOwner` = mint illimité **tant que** tu n’ajoutes pas de limite explicite. Ce n’est pas « faux » pour l’exercice, mais tu dois le dire à l’oral : qui peut mint, quel risque, pourquoi tu as choisi ainsi.
+
+**Démo eval utile :** montrer qu’un compte **non-owner** ne peut pas `mint` (transaction qui **revert** ou test Hardhat).
+
+### 7.2 Glossaire anglais — supply, owner, Ownable, onlyOwner
+
+La doc Solidity et OpenZeppelin est en anglais. Ces quatre termes reviennent partout dans Tokenizer et en soutenance.
+
+#### Supply (*offre*, *quantité en circulation*)
+
+| Terme | Signification |
+|-------|----------------|
+| **supply** | **Quantité totale** de tokens qui **existent** pour ce contrat (à un instant donné). |
+| **total supply** | Même idée ; en code ERC-20 : fonction **`totalSupply()`** qui renvoie un nombre (souvent en plus petite unité, avec **décimales**). |
+| **fixed supply** | Toute la supply est créée **une fois** (souvent au déploiement) ; il n’y a plus de création après. |
+| **max supply** | **Plafond** : on ne peut pas dépasser ce total (souvent constante `MAX_SUPPLY` dans le contrat). |
+
+**Exemple mental :** si tu crées 1 000 000 tokens au deploy et qu’il n’y a pas de `mint`, la supply est **fixe** à 1 000 000. Chaque `transfer` ne change pas `totalSupply` ; seul un **mint** l’augmente et un **burn** la diminue.
+
+**À l’oral en français :** tu peux dire « **offre totale** » ou « **quantité totale de tokens émis** » plutôt que laisser *supply* sans traduction.
+
+---
+
+#### Owner (*propriétaire du contrat*)
+
+| Précision | Détail |
+|-----------|--------|
+| **Ce que c’est** | Une **adresse** (compte wallet) désignée comme **administrateur** du smart contract — pas « propriétaire de tous les tokens ». |
+| **Ce que ce n’est pas** | Ce n’est pas automatiquement la personne qui détient le plus de tokens ; c’est celui qui a les **droits d’administration** définis dans le code (mint, changer le owner, etc.). |
+| **Qui devient owner au deploy ?** | Souvent **`msg.sender`** : l’adresse qui a **déployé** le contrat (ta transaction de déploiement). |
+
+Le sujet parle d’**ownership** (*propriété* / *gouvernance*) au sens : **qui a le pouvoir** sur les fonctions sensibles du contrat.
+
+---
+
+#### Ownable (bibliothèque OpenZeppelin)
+
+**Ownable** n’est pas un mot du standard BEP-20 : c’est un **module** fourni par [OpenZeppelin](https://docs.openzeppelin.com/contracts/5.x/access-control#ownership-and-ownable) que tu **hérites** dans ton contrat, par exemple :
+
+```solidity
+contract MonToken42 is ERC20, Ownable {
+    // ...
+}
+```
+
+Ce module ajoute notamment :
+
+| Élément | Rôle |
+|---------|------|
+| Variable interne `_owner` | Stocke l’adresse du **owner** actuel |
+| `owner()` | Fonction **lecture** : qui est owner ? |
+| `transferOwnership(nouvelleAdresse)` | Transfère le rôle admin à une autre adresse (**onlyOwner**) |
+| `renounceOwnership()` | Owner renonce à son rôle (plus personne n’est owner — à utiliser en connaissance de cause) |
+
+**Pourquoi l’utiliser :** pattern éprouvé, lisible en **code review**, moins de bugs qu’un `address boss` écrit à la main.
+
+---
+
+#### onlyOwner (modificateur Solidity)
+
+En Solidity, un **modifier** (*modificateur*) est une règle placée **avant** une fonction. **`onlyOwner`** (fourni par `Ownable`) signifie :
+
+> Seule l’adresse retournée par `owner()` peut appeler cette fonction ; **toute autre adresse** voit la transaction **échouer** (*revert*).
+
+Exemple typique :
+
+```solidity
+function mint(address to, uint256 amount) public onlyOwner {
+    _mint(to, amount);
+}
+```
+
+| Lecteur du code | Comportement |
+|-----------------|--------------|
+| Appel depuis le **wallet owner** | `mint` s’exécute, supply augmente |
+| Appel depuis **un autre compte** | Échec : pas le droit d’appeler |
+
+**Lien avec le sujet :** c’est un **privilège** explicite à expliquer en README : « seul le owner peut mint ; en eval je montre qu’un autre compte ne peut pas ».
+
+---
+
+#### Tableau récapitulatif
+
+| Anglais | Français (soutenance) | Où tu le vois |
+|---------|----------------------|---------------|
+| **supply** | offre / quantité totale émise | `totalSupply()`, doc, whitepaper |
+| **owner** | propriétaire (admin du contrat) | `owner()`, sujet « ownership » |
+| **Ownable** | contrat / module « propriété unique » | `import` OpenZeppelin, héritage |
+| **onlyOwner** | « réservé au propriétaire » | modifier sur `mint`, `pause`, etc. |
+
+### 7.3 Multisig — types et lien avec le bonus
+
+**Multisig** (*multisignature*) = une action (souvent une **transaction** ou un appel de contrat) n’est **valide** que si **plusieurs clés** ont approuvé, selon un seuil **m sur n** :
+
+> Exemple **2-of-3** : trois signataires possibles, **au moins 2** signatures requises pour exécuter.
+
+Ce n’est **pas** un mécanisme de consensus de **chaîne** (PoS/PoA) : c’est une règle de **gouvernance** sur un **wallet** ou un **contrat** — souvent proposé en **bonus** Tokenizer.
+
+#### Multisig ≠ onlyOwner
+
+| | **onlyOwner** (obligatoire courante) | **Multisig** (bonus sujet) |
+|---|--------------------------------------|----------------------------|
+| **Qui décide ?** | **Une** adresse | **Plusieurs** adresses selon seuil |
+| **Risque** | Une clé volée = tout perdu | Une clé volée ne suffit en général **pas** |
+| **Complexité** | Faible (`Ownable`) | Plus élevée (contrat dédié ou wallet multisig) |
+
+#### Types / formes de multisig (les plus utiles à connaître)
+
+**1. Wallet multisig on-chain (contrat portefeuille)**
+
+- Un **smart contract** détient les fonds (BNB, tokens).
+- Flux typique : `proposeTransaction` → chaque signataire `confirm` → `execute` quand le seuil **m** est atteint.
+- Exemples connus : **Safe** (ex-Gnosis Safe), contrats multisig « maison » pour le bonus.
+- **Usage Tokenizer :** le **owner** du token peut être ce contrat multisig au lieu d’un seul MetaMask.
+
+**2. Multisig sur une fonction précise (contrat custom)**
+
+- Ton token reste `ERC20`, mais `mint` ou `transferOwnership` exige que **k adresses** aient signé ou validé (pattern plus rare en débutant ; souvent on passe par un wallet multisig qui **est** l’owner).
+
+**3. Seuils différents (m-of-n)**
+
+| Notation | Signification |
+|----------|----------------|
+| **1-of-n** | Une seule signature parmi n suffit (peu protecteur) |
+| **2-of-3** | Classique pour petites équipes / testnet |
+| **n-of-n** | **Tous** doivent signer (très strict, risque de blocage si une clé est perdue) |
+| **m-of-n** | Cas général du sujet (« plusieurs parties » + nombre requis) |
+
+**4. Multisig « hors chaîne » / institutionnel**
+
+- Clés réparties entre coffres HSM, procédures bancaires — tu n’en fais pas pour 42 ; utile seulement pour situer le paysage.
+
+**5. Ce qu’on ne confond pas**
+
+| Terme | Ce que ce n’est pas |
+|-------|---------------------|
+| **Multisig** | Pas « plusieurs owners » indépendants sur le même `Ownable` OpenZeppelin standard |
+| **Multi-sig Bitcoin (P2SH)** | Même **idée** (m-of-n), autre blockchain — pas ton stack BEP-20 |
+| **RPC / plusieurs nœuds** | Infrastructure réseau, pas gouvernance de clés |
+
+#### Bonus sujet Tokenizer — ce qu’on attend (esprit)
+
+Le PDF demande un contrat où **plusieurs signatures** sont nécessaires **avant** d’exécuter une transaction sensible. En pratique, les approches acceptables en soutenance :
+
+1. **Wallet multisig** qui possède l’ownership du token + démo d’un `mint` ou transfert validé à 2-of-n.
+2. **Contrat multisig minimal** + documentation : qui signe, quel seuil, comment tester sur testnet.
+
+Adapter le bonus à **ta** partie obligatoire (même token, même réseau) — voir [guide-realisation.md](guide-realisation.md) étape 8.
+
+#### Phrase oral utile
+
+> « Le **consensus PoSA** de BNB Chain fait tourner le réseau ; mon **multisig**, c’est au niveau **application** : plusieurs clés doivent valider avant qu’on puisse agir en tant qu’admin du token. »
+
 ---
 
 ## 8. Ce que le Web3 t’apporte dans *ce* projet (résumé)