Pourquoi la calculatrice de rentabilité "ment" : analyse de l'écart entre prévision et réalité

TL;DR

La calculatrice ne ment pas, elle résout un autre problème. Elle prend la difficulté du jour, le taux de change du jour, et suppose que la machine délivre le hashrate nominal 24 heures sur 24 sans un seul share rejeté. Le paiement réel sur votre compte diffère pour cinq raisons, d'ampleurs très inégales. La plus importante et la plus sous-estimée : la difficulté est recalculée tous les 2016 blocs, environ toutes les deux semaines (article 96), alors qu'une prévision à un mois la maintient silencieusement constante. Viennent ensuite la chance du pool en PPLNS, la perte de shares et les temps d'arrêt, l'écart entre l'efficacité nominale et réelle du matériel, et enfin les frais de retrait ajoutés au spread de la plateforme d'échange.

Tableau des sources d'écart

Pourquoi la calculatrice affiche-t-elle plus que ce qui arrive sur le compte ?

La calculatrice évalue une journée parfaite avec les données d'aujourd'hui : difficulté fixe, hashrate nominal, zéro share perdu, disponibilité totale et paiement sans frais de retrait. La réalité s'écarte de chacune de ces hypothèses dans le même sens, sauf la chance du pool, qui varie dans les deux sens. C'est pourquoi le résultat réel se situe systématiquement en dessous de la prévision, et n'oscille pas au hasard autour d'elle.

Dans quelle mesure la croissance de la difficulté ronge-t-elle la prévision ?

C'est la principale source d'écart sur un horizon supérieur à deux semaines. La difficulté est recalculée tous les 2016 blocs, environ deux semaines, et augmente si le réseau a gagné du hashrate. Votre propre hashrate ne change pas, ce qui fait baisser votre part du réseau, et avec elle le revenu en BTC. La calculatrice ne sait rien des recalculs à venir.

L'ampleur du problème se voit dans le relevé que nous avons utilisé pour la comparaison des pools par revenu net : le 14.08.2026, le hashrate du réseau était de 933.99 EH/s, la difficulté de 127 479 855 693 691, la récompense de bloc de 3.125 BTC, le taux du BTC de 64 558 USD. Le temps que vous lisiez une prévision à un mois, ces quatre chiffres auront déjà changé. Les deux premiers évoluent selon le calendrier du réseau, le troisième selon celui du halving, le quatrième chaque minute.

Comment y remédier en pratique : ne multipliez pas le revenu quotidien par 30. Calculez par tranches de deux semaines et, après chaque recalcul de la difficulté, introduisez la nouvelle valeur dans la calculatrice FPPS vs PPLNS. Une prévision étalée sur un trimestre sans un seul recalcul n'est pas une prévision, c'est une brochure publicitaire.

Pourquoi le revenu saute-t-il en PPLNS et pas en FPPS ?

En PPLNS, vous êtes payé sur les blocs réellement trouvés par le pool. Si la chance a été mauvaise sur la période, le revenu est inférieur à l'attente théorique, si elle a été bonne, il est supérieur (article 96). FPPS et PPS+ paient selon l'espérance mathématique et gardent le risque de la chance du côté du pool, en prélevant une commission pour cela. Le montant attendu est presque identique dans les deux cas.

Il est important ici de ne pas confondre variance et perte. Selon notre analyse des schémas de paiement, le revenu attendu dépend à peine du schéma : votre part du réseau est la même quel que soit le pool vers lequel vous dirigez votre hashrate, et 100 TH/s face à 933.99 EH/s donnent la même espérance dans n'importe quel pool. Le schéma redistribue non pas la somme, mais sa répartition dans le temps, et décide du sort des frais de transaction.

Nous avons mesuré l'ampleur de l'effet des frais de transaction : sur le relevé du 14.08.2026, la part des frais dans la récompense sur les 4320 derniers blocs était de 0.70%. Autrement dit, la différence entre PPS pur et FPPS sur cette période était de 0.70% du revenu. Nettement moins que la variance due à la chance en PPLNS sur une semaine.

Où passent les shares stale et rejetés

Une partie des shares envoyés n'est pas comptabilisée par le pool : ils sont arrivés après que le réseau soit passé au bloc suivant, ou n'ont pas passé la validation. La calculatrice suppose que ces shares n'existent pas du tout. S'y ajoutent de brèves coupures de connexion et des redémarrages qui, cumulés sur une journée, représentent une perte notable, même si le worker paraît en bonne santé à l'instant (article 96).

Nous ne donnons volontairement pas de pourcentages précis : ils dépendent de la qualité de la liaison, de la distance géographique jusqu'au serveur du pool, de la version du firmware et des réglages. Il n'existe pas de chiffre universel ici, et tout auteur qui en cite un sans décrire son banc d'essai l'a inventé.

En revanche, vous pouvez mesurer votre propre part, cela prend quelques minutes. Dans le tableau de bord du pool, ouvrez les statistiques du worker et comparez accepted et rejected sur les dernières 24 heures, le pool affiche les deux valeurs séparément. La part de stale se consulte dans l'interface web du mineur lui-même, elle se trouve en général dans la section des statistiques de pools, à côté du compteur de shares acceptés. Comparez les chiffres obtenus non pas à des captures d'écran d'autrui, mais au seuil des article 94 et article 97 : un écart jusqu'à 5% entre le hashrate côté pool et côté mineur est considéré comme normal, tout ce qui dépasse indique un problème de matériel, de firmware ou de liaison.

Le repère pratique de l'article 96 reste le même : comparez le hashrate réel du worker dans le tableau de bord du pool à celui annoncé par le fabricant. Un écart supérieur à 5% indique un problème de matériel ou de connexion, pas un mauvais pool.

Pourquoi l'efficacité réelle du matériel est inférieure à l'efficacité nominale

Le chiffre nominal est mesuré dans les conditions du fabricant : température d'entrée spécifiée, puces neuves, tension nominale. Dans un atelier ou un garage, l'air est plus chaud, les puces se dégradent, l'alimentation et les ventilateurs consomment aussi. Le résultat est double : le hashrate baisse légèrement, la consommation augmente légèrement, et ces deux corrections rognent la marge.

Dans le calcul de l'article 97, nous avons pris l'Antminer S21 XP Hyd : 473 TH/s, 5676 W, efficacité de 12 J/TH selon le guide utilisateur officiel Bitmain V4.0.2. C'est un modèle hydro, l'un des plus économes du marché. Les ASIC refroidis par air ont une moins bonne efficacité, donc pour la plupart des lecteurs les dépenses d'électricité seront plus élevées que celles indiquées, pas plus basses. Si vous entrez dans la calculatrice le chiffre de la fiche technique d'une machine refroidie par air vieille de trois ans, votre prévision est déjà surévaluée avant même les autres corrections.

L'importance de ce point apparaît dans l'analyse du seuil d'arrêt : le shutdown price, c'est-à-dire le taux de BTC en dessous duquel la machine fonctionne à perte, est déterminé par l'efficacité en J/TH, le tarif de l'électricité et la commission du pool. La même machine donne un seuil différent à deux mineurs ayant un tarif différent, c'est pourquoi les 46 787 $ de cette analyse ne sont pas un chiffre universel, mais un exemple de calcul pour un ensemble concret de données d'entrée.

Ce que prennent le retrait et le change

La dernière couche est la plus petite en pourcentage, mais c'est précisément elle qui transforme le "crédité" en "reçu". Le seuil de paiement retient l'argent, la commission réseau pour le transfert réduit le montant, et le spread de la plateforme le réduit encore une fois lors de la conversion en fiat. La calculatrice ne compte aucun des trois.

Sur le seuil, nous avons l'arithmétique dans l'article 98 : à 100 TH/s, un seuil de 0.005 BTC est atteint en environ 107 jours, et un seuil de 0.001 BTC en environ 21 jours. Ce n'est pas de l'argent perdu, mais c'est la différence entre un revenu qui est chez vous et un revenu qui reste chez le pool.

Nous ne donnons volontairement pas de tarifs précis ici : la commission de retrait diffère d'un pool à l'autre et évolue avec la charge du réseau, et chaque plateforme a son propre spread. La règle fonctionne mieux qu'un tableau. Avant de choisir le seuil de paiement, ouvrez la page de retrait de votre pool et regardez ce qu'il retient pour un transfert on-chain. Le spread de la plateforme se calcule tout aussi simplement : comparez son taux au prix spot du BTC sur une bourse au même instant, la différence est le spread. Comparez ensuite les deux chiffres à l'échelle des autres postes de dépense. L'écart entre une commission de 1% et 4% à 100 TH/s représente environ 9 centimes par jour selon le calcul de l'article 97. Si des frais de retrait ponctuels dévorent plus que ces 9 centimes sur toute la période d'accumulation jusqu'au seuil, vous économisez au mauvais endroit.

Ce qui influence réellement votre résultat

Nous avons déjà calculé l'ordre d'importance dans l'article 98, et il est contre-intuitif. La première place revient au tarif de l'électricité : la différence entre 0.05 $ et 0.12 $ par kWh à 100 TH/s représentait 2.02 $ par jour dans le calcul du 14.08.2026. La deuxième place revient à la commission du pool : l'écart entre 1% et 4% représente exactement 3% du revenu, environ 9 centimes par jour sur les mêmes 100 TH/s. La troisième place revient à la part des frais de transaction, PPS contre FPPS, ces mêmes 0.70% du relevé.

L'écart entre la première et la deuxième place dépasse vingt fois. C'est pourquoi débattre pour savoir quel pool est moins cher d'un demi pour cent est presque toujours vain, alors qu'un tarif d'électricité mal saisi ruine toute la prévision.

Checklist : comment calculer honnêtement

1. Saisissez votre tarif réel par kWh, en incluant tout ce qui figure sur la facture, pas le tarif préférentiel de jour.
2. Prenez la consommation d'un wattmètre sur la prise, pas de la fiche technique.
3. Prenez le hashrate réel du tableau de bord du pool sur les dernières 24 heures, pas le nominal. Un écart supérieur à 5% se corrige d'abord, se calcule ensuite (article 96).
4. Saisissez la commission réelle du pool et son schéma de paiement. Les commissions et seuils de douze pools sont réunis dans l'article 97.
5. Calculez par horizon de deux semaines, jusqu'au prochain recalcul de la difficulté. Puis recalculez de nouveau.
6. Ajoutez sur une ligne séparée la commission de retrait et le spread de change si l'objectif est mesuré en fiat.
7. Regardez le revenu en BTC, pas en USD. Si le BTC est stable et l'USD baisse, la cause est le taux de change, pas le minage (article 96).
8. Une fois tout cela fait, vérifiez le résultat dans la calculatrice FPPS vs PPLNS et dans la comparaison des pools.

FAQ

Mon revenu a baissé de quelques pour cent en une semaine. Le pool me vole-t-il ?

Probablement pas. Vérifiez dans l'ordre : le recalcul de la difficulté du réseau sur cette période, le hashrate réel du worker face au nominal, l'historique des temps d'arrêt, et seulement ensuite le schéma de paiement. Sur les cinq causes de baisse de récompense analysées dans l'article 96, quatre n'ont rien à voir avec l'honnêteté du pool.

Quelle calculatrice est la plus précise ?

La précision de la calculatrice dépend de vos données d'entrée, pas de son algorithme : la formule est la même partout. La différence tient à ce qu'elle utilise ou non la difficulté actuelle et vous laisse choisir le schéma de paiement. Notre calculatrice de rentabilité permet de comparer FPPS et PPLNS sur les mêmes données d'entrée.

Vaut-il la peine de quitter le PPLNS pour la stabilité ?

Si les variations quotidiennes gênent votre planification, oui. L'espérance mathématique change à peine, ce qui change c'est la répartition dans le temps : FPPS et PPS+ donnent des résultats plus réguliers (article 98). Vous payez cette stabilité par la commission que le pool prélève pour porter le risque de la chance.

Pourquoi une prévision à un an est-elle toujours surévaluée ?

Parce qu'elle maintient la difficulté et le taux de change constants sur 26 recalculs à venir. La difficulté suit la croissance du hashrate du réseau, et avec une puissance inchangée, votre part du réseau ne cesse de diminuer. Une prévision annuelle n'a de sens que comme scénario avec une hypothèse explicite sur la croissance de la difficulté, jamais comme une promesse.