Dans les 24 heures précédant 9 h 41 UTC le 11 novembre 2026, le réseau Bitcoin a validé 647 898 transactions, soit environ 7,5 par seconde, selon les données de blocs de mempool.space. La chaîne principale d’Ethereum en a traité à peu près 23 par seconde ce matin-là. Solana, environ 1 265 par seconde sur l’heure close à 9 h 45 UTC. Visa affirme de son côté que son réseau de cartes peut traiter jusqu’à 83 000 messages de transaction par seconde. Cet écart, c’est tout le sujet de la scalabilité blockchain, et smart contract holding reserves of two or more tokens, supplied by users, that a decentralized exchange uses to execute trades automatically at a price set by a formula.">pool diverge, compared with simply holding the same tokens in a wallet. It becomes permanent when the provider withdraws.">il n’est pas tout à fait celui qu’on imagine.
Aucun de ces chiffres n’est un accident d’ingénierie. Chacun reflète un choix : qui doit pouvoir encore vérifier la chaîne ? Un nœud Bitcoin tourne sur un ordinateur ordinaire avec 2 Go de mémoire et, en mode élagué, environ 7 Go d’espace disque libre. Ethereum demande 16 Go de mémoire et un SSD de 4 To. Pour un validateur Solana, Anza liste un serveur de 12 cœurs, plusieurs SSD rapides et une connexion d’au moins 2 gigabits par seconde, et suggère une carte mère capable d’accueillir 512 Go de mémoire.
Pourquoi ce compromis existe, voilà ce que cette leçon explique. La querelle de 2015 à 2017 sur la taille des blocs de Bitcoin tournait autour, et chacune des grandes réponses données depuis aussi : blocs plus gros, sharding, layers 2, disponibilité des données. Elle suppose que vous savez ce qu’est une blockchain et prolonge notre présentation d’Ethereum, de ses comptes et de ses validateurs.
La scalabilité d’une blockchain : plus de transactions sans moins de vérificateurs
Faire passer une blockchain à l’échelle, c’est lui permettre de traiter davantage de transactions, à moindre coût, sans réduire le cercle de ceux qui peuvent la vérifier par eux-mêmes. Cette dernière condition la distingue de la montée en charge d’un site web.
Une boutique en ligne absorbe le pic des soldes en louant des serveurs supplémentaires. Personne en dehors de l’entreprise ne contrôle ses commandes : les machines ajoutées n’ont qu’à être rapides. Une blockchain publique fait une autre promesse : n’importe qui, n’importe où, peut vérifier chaque solde et chaque règle sans faire confiance à l’entreprise, au mineur ou au validateur qui a produit un bloc. Cette promesse est le produit lui-même. C’est aussi ce qui coûte cher quand l’usage grandit, car chaque transaction de plus est du travail de plus pour tous ceux qui font vivre la promesse.
Vitalik Buterin, cofondateur d’Ethereum, a chiffré le problème dans son essai de mai 2021, The Limits to Blockchain Scalability (en anglais). Son raisonnement : une chaîne reste décentralisée tant que des utilisateurs ordinaires peuvent faire tourner un nœud, et un tel nœud ne peut consacrer à la chaîne qu’une partie de sa machine. Il estimait qu’environ 5 à 10 % de la puissance de calcul devraient aller à la vérification des blocs, et situait le bon budget de stockage autour de 512 gigaoctets plutôt que de 10 téraoctets. Dans ces limites, écrit-il, des blocs de 1 à 5 Mo toutes les 12 secondes pourraient être atteignables, et même cela serait difficile.
Un nombre de transactions par seconde est donc une mesure, pas un objectif. Les bonnes questions concernent la personne située au bord du réseau : de quelle machine a-t-elle besoin, de quelle bande passante, de quel disque, et que lui demande-t-on de croire si elle ne peut pas se les offrir ?
Le vrai goulot d’étranglement : chaque nœud complet vérifie tout
Réexécuter, stocker, relayer : le travail derrière chaque bloc
Un nœud complet ne prend pas un bloc sur parole. Quand il en reçoit un, il contrôle les signatures, rejoue chaque transaction sur l’état courant, vérifie que le bloc respecte toutes les règles du protocole, le stocke et le transmet à ses pairs. Notre guide sur le rôle d’un nœud et les différents types de nœuds détaille ce cycle ; ici, c’est la facture qu’il génère qui compte.
Sur Bitcoin, Blockchair situait la chaîne complète à environ 782 Go le 11 novembre 2026. La page de bitcoin.org sur le nœud complet (en anglais, non datée) indique qu’un premier démarrage télécharge environ 740 Go, exige au moins 2 Go de mémoire et un débit montant d’au moins 400 kilobits par seconde, et précise que l’élagage peut ramener l’usage du disque à environ 7 Go. L’élagage ne saute pas la vérification : le nœud télécharge et contrôle chaque bloc depuis 2009, puis jette les plus anciens.
Sur Ethereum, la charge est plus lourde, car chaque transaction peut lancer un programme. Le guide d’ethereum.org pour faire tourner un nœud (en anglais), mis à jour le 29 octobre 2026, donne comme minimum 2 cœurs ou plus, 16 Go de mémoire, un SSD NVMe de 4 To et 25 Mbit/s. La configuration recommandée, tirée de l’EIP-7870, est de 4 cœurs rapides ou plus, 32 Go de mémoire et 50 Mbit/s en réception, davantage pour qui fait tourner un validateur.
Chaque transaction par seconde en plus alourdit tous ces chiffres, sur chaque nœud, pour toujours. Chaque machine doit la contrôler une fois, la stocker sauf si elle élague, l’envoyer à ses pairs, puis la rejouer pour chaque nouveau nœud qui rejoint le réseau dans les années suivantes.
Pourquoi un réseau plus gros n’est pas un réseau plus rapide
Dans la plupart des systèmes informatiques, ajouter des machines ajoute de la capacité. Dans une blockchain, ajouter des nœuds ajoute des copies. Dix mille nœuds qui font le même travail traitent exactement autant de transactions qu’un seul. Cette redondance est le prix de l’absence de confiance, et c’est pour cela que la machine la plus lente que le réseau veut garder dans la partie fixe le rythme.
Le temps compte autant que la taille. Un nouveau bloc doit atteindre l’essentiel du réseau avant que le suivant n’apparaisse. Quand les blocs grossissent ou se succèdent plus vite, davantage de nœuds téléchargent encore le précédent lorsqu’un concurrent surgit, et deux blocs valides à la même hauteur finissent par n’en laisser survivre qu’un. Les mineurs et validateurs les mieux connectés perdent moins de blocs de cette façon : repousser les limites trop vite avantage donc les gros opérateurs bien reliés au détriment des petits.
Le trilemme blockchain : le « deux sur trois » de Buterin
Buterin a donné son nom le plus connu au problème dans un billet du 7 avril 2021, Why sharding is great (en anglais). Il y décrit trois propriétés qu’une chaîne voudrait réunir. La scalabilité, selon sa définition, signifie que la chaîne peut traiter plus de transactions qu’un nœud ordinaire, un ordinateur portable grand public par exemple, n’est capable d’en vérifier. La décentralisation signifie que la chaîne fonctionne sans dépendre de la confiance accordée à un petit groupe d’acteurs centralisés et puissants. La sécurité signifie qu’elle peut résister à une attaque menée par une large part de ses propres participants.
Il a ensuite rangé les conceptions existantes en trois familles, chacune réunissant deux propriétés sur trois. Les blockchains traditionnelles, comme Bitcoin, Ethereum avant la preuve d’enjeu et le sharding, ou Litecoin, demandent à chaque participant de faire tourner un nœud complet qui vérifie toutes les transactions : décentralisées et sûres, mais pas scalables. Les chaînes à haut débit s’appuient sur un petit ensemble de nœuds, souvent de 10 à 100 selon lui, pour s’accorder entre eux : scalables et sûres, mais moins décentralisées. Les écosystèmes multichaînes répartissent les applications sur de nombreuses chaînes séparées qui communiquent : scalables et décentralisés, mais chaque chaîne ne porte qu’une partie de la sécurité, de sorte qu’un attaquant qui prend le contrôle du consensus de l’une peut la briser et peut-être nuire aux applications qui lui sont liées.
Deux réserves. Le trilemme est un cadre de lecture, pas un théorème : personne n’a prouvé que les trois propriétés ne peuvent pas coexister. Et les conceptions qu’Ethereum a adoptées ensuite, le sharding d’abord, les rollups depuis, sont des tentatives pour y échapper en laissant un nœud ordinaire confirmer qu’un travail a été fait correctement sans le refaire entièrement. Leur réussite complète fait encore débat ; les prochaines leçons de ce parcours examinent chacune de ces pistes.
Des blocs plus gros : la guerre de la taille des blocs de Bitcoin
La façon la plus évidente de caser plus de transactions consiste à agrandir les blocs. Bitcoin s’est déchiré sur ce sujet pendant l’essentiel de 2015 à 2017, et cette querelle illustre le trilemme mieux que n’importe quel schéma.
Une limite de 1 Mo ajoutée en 2010
À ses débuts, Bitcoin n’avait pas de limite explicite à la taille des blocs. En 2010, Satoshi Nakamoto a ajouté un plafond de 1 000 000 d’octets en deux modifications du code qu’il n’a pas annoncées, d’après l’historique de la controverse sur le wiki Bitcoin (en anglais). Satoshi n’a jamais publié de justification ; on y voit généralement une mesure antispam, destinée à protéger un jeune réseau, presque sans frais, d’une inondation de blocs inutiles.
Plus tard dans l’année, un utilisateur a proposé un correctif relevant la limite. Le 3 octobre 2010, Satoshi a répondu sur le forum BitcoinTalk (en anglais) que l’appliquer rendrait l’utilisateur incompatible avec le reste du réseau, en ajoutant : « We can phase in a change later if we get closer to needing it », soit « on pourra introduire un changement plus tard si l’on approche du besoin ». Les deux camps citeront cette phrase pendant des années. Les uns y lisaient la promesse de relever la limite ; les autres, l’avertissement que tout changement devait garder le réseau uni.
Ce que défendait le camp des gros blocs
Pour les partisans des gros blocs, la raison d’être de Bitcoin tenait dans le titre de son livre blanc : une monnaie électronique de pair à pair. Si les blocs restaient à 1 Mo pendant que l’usage grandissait, les frais monteraient jusqu’à rendre les petits paiements absurdes sur la chaîne, et les utilisateurs se tourneraient vers des services de garde, l’inverse de l’idée d’origine. Le matériel et la bande passante deviennent moins chers chaque année, soutenaient-ils : une hausse modérée n’écarterait pas les utilisateurs ordinaires du réseau, alors que les systèmes hors chaîne capables de porter les paiements du quotidien n’étaient pas prêts.
Leurs propositions étaient concrètes. Bitcoin XT a embarqué le BIP 101, qui aurait porté la limite à 8 Mo une fois 75 % des mineurs favorables, avant de la doubler tous les deux ans ; il ne s’est jamais activé. Bitcoin Classic a proposé le BIP 109, un hard fork vers 2 Mo en 2016, avec une limite qui s’ajusterait ensuite d’elle-même. Aucun des deux n’a réuni le soutien nécessaire.
Ce que défendait le camp des petits blocs
Le camp des petits blocs partait du nœud, pas du paiement. Des blocs plus gros demandent plus de bande passante, plus de disque et des synchronisations initiales plus longues, et chaque hausse écarte une partie des utilisateurs de la vérification autonome de la chaîne. Les blocs plus lourds circulent aussi plus lentement, ce qui, on l’a vu, avantage les gros mineurs aux connexions rapides et pousse le réseau vers quelques grands acteurs.
Ils redoutaient aussi la méthode. Relever la limite exigeait un hard fork, un changement de règles que les anciens logiciels rejettent, et un hard fork contesté pouvait couper le réseau et sa monnaie en deux. Ils doutaient aussi qu’une taille fixe suffise jamais : la demande d’espace de bloc bon marché et permanent est presque illimitée, un bloc plus gros se remplirait donc aussi, simplement plus tard. Leur réponse : garder une couche de base petite et facile à vérifier, et déplacer les paiements courants vers des couches construites par-dessus.
Une fois les personnalités mises de côté, les deux camps acceptaient le trilemme. Ils divergeaient sur le coin à sacrifier et sur le droit de trancher.
Le dénouement : SegWit, Bitcoin Cash et le hard fork à 2 Mo annulé
La fin de partie s’est jouée sur six mois en 2017, et notre guide sur la gouvernance de Bitcoin et le processus des BIP la raconte pas à pas. En bref : l’accord de New York du 23 mai 2017 associait SegWit à un hard fork ultérieur vers 2 Mo (le plan SegWit2x) ; un groupe de partisans des gros blocs a fait scission le 1er août 2017 et créé Bitcoin Cash, une chaîne distincte aux blocs plus grands ; SegWit s’est activé sur Bitcoin le 24 août 2017 au bloc 481 824 ; et la partie à 2 Mo de SegWit2x a été annulée le 8 novembre 2017. La façon dont une chaîne se scinde en deux est décrite dans notre guide sur les hard forks, soft forks et scissions de chaîne.
SegWit a bien augmenté la capacité, de façon détournée. Il a remplacé le plafond de 1 Mo par une limite de 4 millions d’unités de poids, définie dans le BIP 141, où les données de signature pèsent moins ; notre guide sur SegWit et Taproot explique ce système de poids. Sur les 144 blocs précédant 9 h 41 UTC le 11 novembre 2026, le bloc moyen mesurait 1,62 Mo et 3 943 565 unités de poids, soit environ 99 % de la limite, d’après les données de mempool.space.
Pourquoi Bitcoin est lent : l’origine des 7 transactions par seconde
Ces chiffres montrent aussi d’où vient le fameux « 7 transactions par seconde ». Un bloc plein contient environ 1 million d’octets virtuels. La transaction moyenne de ces 144 blocs en occupait environ 219, soit près de 4 500 transactions par bloc, et à un bloc toutes les dix minutes cela fait environ 7,5 par seconde. Des transactions plus petites font monter le rythme : sur les 15 derniers blocs du même échantillon, des blocs allant jusqu’à 7 600 petites transactions l’ont porté à environ 14 par seconde. La formulation honnête est donc : environ 7 par seconde en moyenne, davantage quand les transactions sont petites, et non un plafond fixe de 7.
Quand la demande dépasse la place, les frais montent
L’espace de bloc est fixe à court terme : quand plus de monde veut entrer qu’il n’y a de place, on enchérit. Sur Bitcoin, les utilisateurs proposent des frais par octet virtuel et les mineurs retiennent les meilleures offres. Sur Ethereum, des frais de base montent automatiquement quand les blocs dépassent leur cible et baissent quand ils restent dessous. Ces deux mécanismes sont détaillés dans nos guides sur la mempool de Bitcoin et les frais de transaction et sur le gas d’Ethereum et l’EIP-1559.
Le 20 avril 2024, jour du quatrième halving de Bitcoin et du lancement du protocole de jetons Runes, les frais ont atteint en moyenne 9,67 BTC par bloc, et le bloc 840 000 à lui seul a rapporté 37,63 BTC de frais contre 3,125 BTC de récompense. Sur Ethereum, le 1er mai 2022, pendant la vente de terrains Otherside, un simple transfert d’ether coûtait environ 28,16 dollars au prix moyen du gas de la journée relevé par Etherscan.
Les frais sont calmes en novembre 2026. Le même transfert sur Ethereum coûtait environ 0,033 dollar le 9 novembre 2026, et Blockchair situait les frais moyens de Bitcoin sur les 24 heures jusqu’au 11 novembre 2026 à environ 0,32 dollar. Des frais calmes ne veulent pas dire que le problème est résolu. Ils signifient que, pour l’instant, la demande tient dans l’espace disponible, un espace qu’Ethereum a élargi à plusieurs reprises depuis 2022.
Plus rapide, plus gros ou en couches : le menu des solutions
Toute solution de passage à l’échelle déplace une partie du travail, des données ou de la confiance loin du nœud ordinaire. Les lire sous cet angle aide à les comparer.
Des blocs plus gros et plus rapides sur la couche 1
Solana est le cas le plus net d’une chaîne qui a misé sur le débit brut de sa couche 1. Ses slots visent désormais 200 millisecondes, contre 400 auparavant, et le 21 octobre 2026 elle a basculé vers un nouveau système de consensus avec la mise à jour Alpenglow, entrée en service sur le mainnet de Solana ; les horodatages des blocs montrent le dernier bloc de l’ancien système à 13 h 54 min 00 s UTC ce jour-là. Le RPC public de Solana affichait un slot moyen d’environ 215 ms et environ 1 265 transactions par seconde sur l’heure close à 9 h 45 UTC le 11 novembre 2026. Depuis Alpenglow, les votes des validateurs n’apparaissent plus comme des transactions on-chain : ce chiffre ne compte donc que l’activité des utilisateurs, et les anciens chiffres de référence, qui incluaient les votes, ne lui sont pas comparables.
Le coût se lit dans les exigences pour les validateurs publiées par Anza (en anglais), qui maintient le principal client de Solana : un processeur d’au moins 12 cœurs et 24 threads à 2,8 GHz ou plus, des disques NVMe distincts de 1 To ou plus pour les comptes et pour le registre, plus 500 Go pour les instantanés, une carte mère pouvant accueillir 512 Go de mémoire (suggérée) et une connexion symétrique d’au moins 2 Gbit/s, 10 Gbit/s étant recommandé. C’est du matériel de centre de données. Le design de Solana admet que ceux qui vérifient l’intégralité de la chaîne seront des professionnels, et travaille à garder ce groupe large et dispersé.
Ethereum a lui aussi élargi ses blocs, par petits pas. Les validateurs peuvent relever ou abaisser la limite de gas par un réglage de leur client, sans hard fork, et ils l’ont fait passer de 30 millions de gas (en place depuis août 2021) à environ 36 millions en février 2025, 45 millions en juillet 2025 et 60 millions fin novembre 2025. Un bloc lu le 11 novembre 2026 affichait toujours une limite de 60 000 000, et un échantillon de 60 blocs récents consommait en moyenne 28,7 millions de gas, juste sous la cible de 30 millions. Plus de place par bloc, c’est aussi plus de travail par nœud : la configuration que recommande ethereum.org compte désormais 32 Go de mémoire, le double du minimum.
Le sharding, et pourquoi Ethereum a changé de plan
Le sharding découpe une chaîne en nombreux morceaux parallèles, de sorte que chaque nœud n’en vérifie qu’une partie tandis que l’ensemble porte bien davantage. Pendant des années, ce fut le grand plan d’Ethereum. Le 2 octobre 2020, Buterin a publié A rollup-centric Ethereum roadmap (en anglais), où il estimait que l’écosystème serait « likely to be all-in on rollups », autrement dit probablement tout entier tourné vers les rollups. À long terme, écrivait-il, la couche de base offrirait un seul shard d’exécution très sûr que tout le monde traite, plus une couche de disponibilité des données évolutive.
Les pages d’ethereum.org consacrées au passage à l’échelle (en anglais) décrivent aujourd’hui ce changement : au lieu de répartir l’exécution entre des shards, Ethereum répartit les données, au moyen des blobs et du plan à plus long terme appelé danksharding, et laisse l’essentiel de l’exécution aux rollups. La chaîne a cessé de chercher à tout exécuter plus vite pour devenir l’endroit où d’autres systèmes publient leurs données et se règlent.
Les layers 2 : canaux, rollups et sidechains
Un layer 2 exécute les transactions loin de la chaîne principale et s’appuie sur elle pour son règlement final. Notre guide layer 1 contre layer 2 couvre déjà les bases, des séquenceurs aux délais de retrait en passant par les niveaux de maturité suivis par ETHBEAT, ex-L2BEAT. Trois familles de layers 2 se distinguent par ce qu’elles empruntent à la chaîne principale.
Les canaux de paiement bloquent des fonds sur la chaîne principale avec une transaction, laissent deux parties échanger entre elles des mises à jour signées aussi souvent qu’elles le veulent, puis règlent le solde final avec une autre transaction. Le Lightning Network sur Bitcoin en est l’exemple le plus connu, et c’est la réponse qu’avait en tête le camp des petits blocs.
Les rollups exécutent des lots de transactions hors chaîne et publient sur Ethereum les données, compressées, avec un engagement sur le résultat. Les deux grandes familles, optimistic et à connaissance nulle (ZK), diffèrent par la manière de prouver que le résultat est juste ; les prochaines leçons de ce parcours, sur les rollups de layer 2, les rollups optimistic et les rollups ZK, les prennent une par une. Base et Arbitrum One étaient les plus importants par valeur sécurisée au 11 novembre 2026, selon ETHBEAT.
Les sidechains sont des blockchains distinctes, avec leurs propres validateurs, reliées à une chaîne principale par un pont. Elles peuvent être rapides et peu chères, mais leur sécurité leur appartient, pas à la chaîne principale : si leurs validateurs se comportent mal, la chaîne principale ne peut pas intervenir. Une leçon ultérieure compare en détail sidechains et rollups.
La disponibilité des données, ce que la plupart des explications oublient
Un rollup ne vaut que par ses données. Si chacun peut télécharger les transactions qu’il a publiées, chacun peut reconstruire son état, contrôler son opérateur et, au besoin, prouver son propre solde pour retirer ses fonds. Si l’opérateur retient ces données, les utilisateurs en sont réduits à croire sur parole. La question devient alors : où les données sont-elles publiées, et les nœuds ordinaires peuvent-ils confirmer qu’elles y sont vraiment ?
La réponse d’Ethereum, ce sont les blobs. Depuis la mise à jour Dencun du 13 mars 2024, les rollups publient leurs données dans ces paquets distincts, moins chers que les données de transaction ordinaires parce que les nœuds ne les conservent que pour une durée limitée et non pour toujours. La mise à jour Fusaka, entrée en service le 3 décembre 2025, a ajouté PeerDAS : au lieu que chaque nœud télécharge chaque blob en entier, les nœuds en téléchargent des parties et échantillonnent le reste, si bien que le nombre de blobs peut croître sans que la bande passante de chaque nœud suive au même rythme. C’est l’échappatoire au trilemme en pratique : vérifier que le travail a été fait sans le refaire.
Les étapes du passage à l’échelle d’Ethereum, datées
Le tableau ci-dessous recense les principales hausses de capacité de la chaîne principale d’Ethereum depuis l’arrivée des blobs. Les chiffres de blobs sont la cible et le maximum par bloc ; leurs effets sur les frais sont traités dans notre guide sur le gas.
| Date | Changement | Ce qu’il a apporté |
|---|---|---|
| 13 mars 2024 | Mise à jour Dencun (EIP-4844) | Les blobs pour les données des rollups, cible de 3 et maximum de 6 par bloc |
| 4 février 2025 | Limite de gas relevée par les validateurs | Environ 36 millions de gas par bloc, contre 30 millions |
| 7 mai 2025 | Mise à jour Pectra | Cible de blobs à 6, maximum à 9 |
| 24 juillet 2025 | Limite de gas relevée par les validateurs | 45 millions de gas |
| 30 novembre 2025 | Limite de gas relevée par les validateurs | Environ 60 millions de gas |
| 3 décembre 2025, 21 h 49 UTC | Mise à jour Fusaka | Échantillonnage des données PeerDAS ; 60 millions de gas par défaut dans les clients ; plafond de 16 777 216 gas par transaction (EIP-7825) |
| 9 décembre 2025, 14 h 21 UTC | Fork BPO1 (paramètres de blobs seulement) | Cible de blobs à 10, maximum à 15 |
| 7 janvier 2026, 1 h 01 UTC | Fork BPO2 (paramètres de blobs seulement) | Cible de blobs à 14, maximum à 21 |
| 6 octobre 2026 | Glamsterdam sur le testnet Sepolia | Pas de date sur le mainnet au 11 novembre 2026 |
Les dates de Fusaka et des BPO et les nombres de blobs proviennent de l’annonce de Fusaka sur le mainnet par l’Ethereum Foundation (en anglais) du 6 novembre 2025 ; BPO signifie « blob-parameter-only », de petits forks qui ne changent que les paramètres des blobs. Sur les 60 blocs échantillonnés le 11 novembre 2026, la chaîne portait environ 6,5 blobs par bloc, bien sous la cible de 14 : la place de données ajoutée en 2025 et 2026 n’était donc pas pleine ce matin-là.
Les chaînes comparées : débit et coût d’un nœud
Le comparatif ci-dessous met l’activité mesurée à côté du coût de la vérification, c’est-à-dire le compromis au cœur de cette leçon. La colonne du débit se lit avec prudence : un paiement Bitcoin, un échange de jetons sur Ethereum et une transaction Solana représentent des quantités de travail différentes, et les transactions par seconde ne sont donc pas une unité comparable d’une chaîne à l’autre.
| Réseau | Temps de bloc ou de slot | Débit mesuré | Ce dont un nœud a besoin | Source |
|---|---|---|---|---|
| Bitcoin | Environ 10 minutes (cible) | Environ 7,5 tx/s sur les 24 h à 9 h 41 UTC le 11 nov. 2026 (647 898 transactions en 144 blocs) | Bitcoin Core : 2 Go de mémoire, environ 7 Go de disque en mode élagué ; chaîne complète d’environ 782 Go (11 nov. 2026) | mempool.space, bitcoin.org, Blockchair |
| Ethereum (couche 1) | 12 secondes | Environ 23 tx/s (échantillon de 60 blocs, 11 nov. 2026) ; 2 064 096 transactions le 10 nov. 2026 | 2 cœurs ou plus, 16 Go de mémoire (32 Go recommandés), SSD NVMe de 4 To, 25 Mbit/s ou plus | RPC public d’Ethereum, growthepie, ethereum.org |
| Solana | Environ 215 ms en moyenne (cible de 200 ms) | Environ 1 265 tx/s sur l’heure à 9 h 45 UTC le 11 nov. 2026 | Processeur à 2,8 GHz ou plus, plusieurs disques NVMe de 0,5 à 1 To ou plus, 512 Go de mémoire suggérés, 2 à 10 Gbit/s | RPC public de Solana, documentation d’Anza |
| Base (layer 2 d’Ethereum) | 200 ms depuis le 5 nov. 2026 | 8 468 276 transactions le 10 nov. 2026 (environ 98 tx/s) | Se règle sur Ethereum ; les utilisateurs peuvent s’appuyer sur les nœuds Ethereum pour ses données | growthepie, Base |
| Visa (réseau de cartes, pas une blockchain) | Sans objet | Capacité de 83 000 messages/s ; environ 10 200 par seconde en moyenne à partir de plus de 322 milliards par an | Centres de données privés | Visa, 29 oct. 2025 |
Bitcoin et Ethereum gardent la vérification à la portée d’une machine domestique et acceptent en échange un faible débit. Solana porte bien plus d’activité sur sa couche de base et demande aux vérificateurs du matériel professionnel. Base, passée à des blocs de 200 ms avec sa mise à jour Denim le 5 novembre 2026, illustre la voie en couches : beaucoup d’activité au-dessus, avec Ethereum qui garde les données et le dernier mot.
Visa est un étalon utile mais approximatif. Sa propre description de son réseau (en anglais), publiée le 29 octobre 2025, parle de « up to 83,000 transaction messages per second worldwide » (jusqu’à 83 000 messages de transaction par seconde dans le monde) et de plus de 322 milliards de transactions par an. Le premier chiffre est une capacité, pas un rythme mesuré ; le second, divisé par le nombre de secondes d’une année, donne environ 10 200 par seconde en moyenne. Et une autorisation Visa n’est pas un règlement définitif : les banques règlent entre elles plus tard, par lots, dans un système que personne d’extérieur ne peut auditer.
Ce que le passage à l’échelle change pour vous
Pour la plupart des utilisateurs, la scalabilité crypto se voit dans les frais. Un transfert qui coûtait des dizaines de dollars sur Ethereum en 2021 et 2022 coûte quelques centimes en novembre 2026, et la même opération sur un layer 2 coûte une fraction de centime. Une partie vient de la capacité ajoutée depuis 2024, une autre de marchés plus calmes ; une ruée de la demande peut encore faire grimper les frais très vite, comme sur Bitcoin en avril 2024.
Le passage à l’échelle change aussi la personne à qui vous faites confiance. Sur une chaîne dont vous pouvez faire tourner un nœud sur un ordinateur portable, vous pouvez tout vérifier vous-même. Sur une chaîne à haut débit ou un layer 2, vous vous en remettez au matériel d’un autre ou à un système de preuves, et les détails décident de l’ampleur de cette confiance. Trois questions aident face à toute annonce de dizaines de milliers de transactions par seconde :
- Le chiffre est-il mesuré sur le réseau réel, avec une date, ou s’agit-il d’un pic théorique issu d’un test ?
- Quelle machine et quelle connexion faut-il pour vérifier cette chaîne en entier, et combien d’opérateurs indépendants le font réellement ?
- Si vous ne pouvez pas vérifier vous-même, à quoi vous fiez-vous exactement : un ensemble de validateurs, un séquenceur, un pont ou une preuve cryptographique ?
Côté fiscalité française, rien dans cette leçon ne crée d’obligation propre : c’est la cession d’actifs numériques qui compte. Selon la page de l’administration fiscale sur la déclaration des plus ou moins-values sur cessions d’actifs numériques, modifiée le 17 juillet 2026, les plus-values réalisées en 2026 sont soumises au prélèvement forfaitaire unique de 31,4 %. Le traitement fiscal des opérations de DeFi, et donc des passages de pont entre réseaux, reste non tranché. Notre guide sur la fiscalité des cryptomonnaies en France détaille les règles de la cession. Les frais ne changent rien à l’argument de la scalabilité, mais ils font partie de ce que coûte réellement une transaction.
La prochaine leçon de ce parcours reprend là où celle-ci s’arrête : comment fonctionnent les rollups de layer 2, pourquoi ils coûtent moins cher et ce qu’ils demandent encore aux utilisateurs de croire.
