---
id: 18
title: "Glossaire des métriques de performance : TPS, BPS, latence de confirmation, finalité et taux de conflit"
slug: performance-metrics-glossary
date: 2026/09/08
summary: TPS, BPS, latence de confirmation, finalité et taux de conflit sont régulièrement confondus. Cet article fournit des définitions réutilisables, les schémas de mauvais usage courants et la liste des informations à exiger pour tout benchmark — et non un conseil en investissement.
keywords: TPS,BPS,latence de confirmation,finalité,taux de conflit,benchmarks
heroImage: /images/community-bg.png
---

L'un des procédés les plus courants dans le récit des chaînes publiques consiste à lancer un chiffre de débit suffisamment grand. Le « TPS de pointe » d'une page d'accueil et le débit que l'on peut observer on-chain en temps réel ne sont souvent pas la même statistique. Des observateurs tiers ont publiquement comparé les pics revendiqués avec le débit mesuré ; sur certains réseaux, l'écart atteint deux ordres de grandeur ou plus. Ce n'est généralement pas une simple histoire de « qui ment », mais de « pic théorique » et de « débit dans une fenêtre d'observation » confondus par habitude.

Pour les lecteurs qui évaluent des conceptions hautes performances — en particulier un EVM parallèle — les comparaisons restent approximatives tant que TPS, BPS, latence de confirmation, finalité et taux de conflit ne partagent pas les mêmes définitions. [Qui devrait lire sur l'EVM parallèle](/fr/blog/who-should-read-parallel-evm) a réparti les parcours de lecture par rôle ; cet article fournit le vocabulaire de mesure commun. Les chiffres externes cités ci-dessous sont des exemples de divulgation publique servant à illustrer les différences de mesure ; **ce ne sont pas des notes de projets ni un conseil en investissement**.

## TPS : un sigle, au moins trois formules

TPS signifie littéralement transactions par seconde. En pratique, il existe au moins trois calculs distincts :

1. **Pic théorique / en laboratoire** : une borne supérieure sous un matériel, une version de client et un mélange de transactions spécifiés (souvent des virements simples ou une charge synthétique à faible conflit). Le nombre le plus grand ; l'extrapolation la plus faible vers le mainnet.
2. **Débit soutenable** : le rythme que le système peut tenir sous des contraintes énoncées de latence et de taux d'échec. Pour les paiements et le règlement, il est souvent plus significatif que le pic.
3. **Débit sur fenêtre d'observation** : les transactions incluses et confirmées (selon une définition de finalité choisie) dans une fenêtre de temps, divisées par le nombre de secondes. Il reflète la demande réelle et la congestion, non le plafond de capacité.

Posez trois questions en parallèle, sinon la comparaison échoue : comment les transactions sont-elles comptées (y compris les votes / tâches d'entretien) ? Les transactions échouées ou annulées sont-elles incluses ? Quelle est la durée de la fenêtre, et quel matériel et quelle version de client ont été utilisés ? L'EVM parallèle en ajoute une quatrième : quel était le taux de conflit ou la distribution des points chauds de la charge testée ? Un pic sans distribution de conflits a une valeur limitée — développé dans [Points chauds de conflit et charges de travail](/fr/blog/parallel-evm-workload-hotspots).

La même chaîne peut honnêtement publier les trois modes de TPS : le pic en laboratoire pour le plafond, le débit soutenable pour la plage produit utilisable, et le débit sur fenêtre d'observation pour savoir si la demande remplit la capacité aujourd'hui. Les imprimer comme un seul chiffre, c'est là que la tromperie commence. Quand vous voyez « jusqu'à », classez-le par défaut dans le pic et cherchez les équivalents soutenable et observé.

## BPS : ne traduisez pas directement « blocs plus rapides » par « utilisateurs plus rapides »

Dans cet article, BPS désigne les **blocs par seconde**, la fréquence de production des blocs. Augmenter le BPS peut raccourcir l'attente moyenne du prochain bloc, mais la latence perçue par l'utilisateur dépend aussi du moment où une transaction entre dans la mempool du proposeur, de la durée de l'exécution et des réessais en cas de conflit, et du nombre de blocs ou de tours de vote supplémentaires qu'exige la finalité du protocole.

Le BPS est donc une métrique de consensus et de rythme d'assemblage, et non une statistique suffisante pour l'expérience de bout en bout. Une chaîne peut augmenter son BPS et paraître lente si une exécution à fort conflit accumule une file de réexécution. À la lecture, consignez le BPS séparément de la latence de confirmation et de la finalité ; ne laissez pas des temps de bloc plus courts tenir lieu de toute l'histoire de performance. Si un document emploie BPS dans un autre sens (par exemple un débit orienté octets), suivez la définition de cette page et ne la mélangez pas avec le sens retenu ici.

## Latence de confirmation : de l'envoi à « je le vois »

La latence de confirmation désigne généralement : le temps écoulé entre la soumission d'une transaction par un utilisateur (ou un portefeuille) et sa reconnaissance par le réseau selon une règle de « confirmation acceptable ». L'essentiel est d'écrire ce que signifie « acceptable » — apparaître dans le dernier bloc proposé, survivre à k blocs suivants, ou satisfaire une condition de validation de type BFT.

Habitudes de lecture pratiques :

- Préférez les **p50 / p95 / p99** aux seules moyennes ; les queues génèrent les tickets de support et les fenêtres d'arbitrage.
- Notez la charge : la latence d'une chaîne vide et celle d'une période congestionnée sont des métriques différentes.
- Pour l'exécution parallèle, surveillez en plus si les réessais en cas de conflit élargissent une partie de la distribution de latence.
- Séparez « exécuté sur mon nœud local » de « finalisé par le réseau » : les interfaces de portefeuille montrent parfois le premier ; le règlement a souvent besoin du second.

Une divulgation complète de latence énonce la définition de confirmation, les centiles, la description de la charge et la manière dont les clients ont été échantillonnés. L'absence d'un élément rend le chiffre difficile à reproduire. Les paiements et le règlement marchand ont particulièrement besoin de bornes supérieures de latence prévisibles ; des documents qui ne donnent que des moyennes ont presque aucune valeur décisionnelle pour ces scénarios.

## Finalité : ne confondez pas finalité économique et finalité de protocole

La finalité décrit à quel point — ou si, par protocole — un résultat de transaction peut encore être renversé. Deux usages courants sont souvent mélangés :

- **Finalité de protocole (finalité déterministe)** : sous un consensus de type BFT, une fois suffisamment de votes recueillis, un bloc entre dans un état validé et les nœuds honnêtes ne le renverseront pas selon le protocole. La latence s'exprime souvent en tours de messages.
- **Finalité économique / probabiliste** : sous une règle de chaîne la plus longue ou certaines règles de confirmation glissante, la probabilité de réorganisation diminue à mesure que les blocs s'accumulent, mais une chaîne plus longue peut encore remplacer l'historique en théorie ; « final » est un seuil de risque.

Appeler « finalisées » des « N confirmations » sous finalité probabiliste fausse la comparaison entre chaînes. Pour les scénarios de règlement et de pont, précisez quel modèle de finalité s'applique et sous quelles hypothèses (puissance de hachage / fraction d'enjeu / synchronie du réseau de l'adversaire). Le récit technique de Bitroot autour du Pipeline BFT vise une finalité de protocole rapide ; voir [Pipeline BFT et découplage de l'exécution](/fr/blog/bitroot-pipeline-bft). Qu'une affirmation produit de finalité inférieure à la seconde tienne dépend encore des conditions divulguées par ce test — les objectifs de conception ne sont pas des faits vérifiés sur le mainnet.

Le temps de finalité est lié à la latence de confirmation, mais ne lui est pas identique : les utilisateurs peuvent rafraîchir une interface après une confirmation légère tandis que les ponts et les dépositaires attendent encore la finalité de protocole. Pour comparer deux chaînes, alignez d'abord le niveau de « suffisamment bon » que vous comparez.

## Taux de conflit : le « dénominateur caché » de l'EVM parallèle

Le taux de conflit décrit, sous parallélisme optimiste, la part des transactions qui doivent être annulées ou réexécutées de façon sérielle en raison de conflits d'ensembles lecture/écriture (les définitions devraient préciser : en nombre de transactions ou en gaz ; à la granularité du compte ou de l'emplacement). Il apparaît rarement sur les affiches classiques monothread, et pourtant c'est le dénominateur qui explique pourquoi les benchmarks de virements paraissent rapides et ceux d'AMM ralentissent.

Intuition approximative :

- Taux de conflit proche de 0 : l'accélération parallèle peut approcher le nombre de moteurs d'exécution (toujours bornée par la surcharge d'ordonnancement et d'accès à l'état).
- Taux de conflit croissant : le débit effectif glisse vers « exécution sérielle plus coût de retour en arrière » — les CPU restent occupés pendant que les utilisateurs attendent toujours.

Un benchmark honnête d'EVM parallèle rapporte donc au moins deux chiffres : une charge à faible conflit et une charge à fort conflit (ou un mélange réaliste de contrats), avec la définition du conflit énoncée. Ne publier qu'un pic de virements masque le dénominateur. Comparez aussi un taux de conflit pondéré par le gaz : quelques transactions chaudes lourdes peuvent percer le débit plus que de nombreux conflits légers.

## Liste minimale des informations à exiger pour lire un benchmark

Quand vous voyez un tableau de performance, cochez les cases :

| Information | Pourquoi elle compte |
|------|------------|
| Matériel (CPU / RAM / disque / réseau) et nombre de nœuds | Sinon, impossible de savoir si le pic a été empilé sur des machines extrêmes |
| Version et configuration du client | Même protocole, implémentations différentes, chiffres différents |
| Mélange de transactions et définition du taux de conflit | Décide si les chiffres parallèles sont extrapolables |
| Mode de TPS (pic / soutenable / observé) | Empêche de comparer trois formules comme une seule |
| Définition de confirmation et centiles | Empêche de dissimuler un « rapide en moyenne, lent en queue » |
| Type de finalité (protocole / économique) | Empêche les fausses comparaisons entre modèles |
| Mainnet, testnet ou laboratoire | Les chiffres de testnet ne sont pas des performances stables de production |

Plus il manque d'éléments, moins le chiffre est citable. Cela va à l'encontre de la logique de page d'accueil du « plus grand, c'est mieux », mais c'est la seule lecture reproductible pour l'ingénierie et la recherche. Lisez-la avec les dimensions de décentralisation de l'article suivant : le même pic mesuré sur quelques machines haut de gamme d'une seule métropole se réduit encore une fois extrapolé.

## En guise de conclusion

Les métriques de performance ne sont pas des adjectifs pour une page d'accueil ; ce sont des mesures qui exigent des pièces jointes. Le TPS n'a pas de valeur vraie unique, le BPS ne remplace pas la latence utilisateur, confirmation et finalité doivent être définies avant toute comparaison, et le taux de conflit ne devrait plus être absent de la lecture d'un EVM parallèle. Une fois ce glossaire aligné, les discussions sur la décentralisation face aux seuils matériels — et sur l'effondrement du débit sous charges chaudes — sont moins susceptibles d'être détournées par un seul pic.

## Pour aller plus loin

- Précédent : [Qui devrait lire sur l'EVM parallèle : trois parcours pour les développeurs de contrats, les ingénieurs clients et les chercheurs](/fr/blog/who-should-read-parallel-evm)
- Suivant : [La tension entre décentralisation et performance : exigences des validateurs, matériel et répartition géographique](/fr/blog/decentralization-performance-tradeoff)
- Associés : [Points chauds de conflit et charges de travail : quand l'EVM parallèle aide vraiment](/fr/blog/parallel-evm-workload-hotspots)