Le pool est tombé : comment savoir que le problème ne vient pas de votre ASIC, et quoi faire dans la première heure

*Last updated: 09.09.2026. POOL BTC.*

TL;DR

Quand le hashrate tombe à zéro dans le panneau du pool, le pool n'est pas toujours fautif. Dans la plupart des cas la cause se trouve entre votre ASIC et le serveur stratum : le routeur, le fournisseur d'accès, l'alimentation, une carte surchauffée, un firmware installé la veille. Distinguer l'un de l'autre prend cinq minutes sans quitter son ordinateur : regarder ce qu'affiche le mineur lui-même, vérifier si le pool est tombé pour d'autres mineurs, et comparer le hashrate local au hashrate côté pool. La première heure, mieux vaut la passer non pas à paniquer ou à changer de pool, mais à diagnostiquer dans l'ordre et à activer le stratum de secours qui aurait dû figurer dans la configuration bien avant.

POOL BTC n'est pas un pool, mais un site indépendant de comparaison de pools. Nous n'attribuons ici aucune panne à un pool précis : ci-dessous une méthode, pas l'analyse de la chute de quelqu'un.

Comment distinguer une panne du pool d'un problème de votre côté ?

Le signe principal d'une panne de pool : le mineur tourne, le hashrate sur l'appareil est normal, mais la connexion au stratum se coupe ou les shares partent sans réponse. Si en revanche le hashrate a chuté dans le panneau de l'ASIC lui-même, si des puces sont tombées ou si l'appareil redémarre en boucle, le pool n'y est pour rien : le problème vient du matériel, de l'alimentation ou du réseau jusqu'au fournisseur d'accès.

Décomposons par symptômes. Il faut regarder deux endroits en même temps : le panneau du mineur (hashrate local) et les statistiques du compte dans le pool (hashrate côté pool).

Un cas à part, celui que l'on confond le plus souvent avec une chute du pool : une configuration toute neuve. Si le hashrate n'est jamais apparu dans le pool, ce n'est pas une panne, c'est une faute de frappe dans le nom du worker ou un port fermé. Une panne a une autre allure : ça tournait depuis des jours, et ça s'est arrêté d'un coup.

Qu'affiche le panneau du mineur en cas de coupure et que signifient accepted, rejected, stale ?

Le panneau de l'ASIC contient trois compteurs par pool : accepted (shares acceptés), rejected (rejetés), stale (arrivés trop tard, le travail n'est plus d'actualité). En cas de coupure avec le stratum, le statut du pool passe à dead ou disconnected, le compteur accepted se fige, et le mineur commence à tenter de se connecter au pool suivant de la liste, s'il y en a un.

Ce qui se cache derrière ces mots :

• Accepted. Le pool a accepté votre share et l'a compté dans les statistiques. C'est le seul compteur qui se transforme en argent.
• Rejected. Le pool a reçu le share mais ne l'a pas compté. Les raisons varient : travail périmé, doublon, difficulté trop basse, erreur d'autorisation.
• Stale. Cas particulier de rejet : le share a été calculé pour un travail que le pool avait déjà annulé, parce qu'un nouveau bloc a été trouvé sur le réseau. Plus la latence jusqu'au serveur est grande, plus cela arrive souvent.
• Difficulty accepted. Dans certains firmwares, une ligne à part indique la somme de difficulté des shares acceptés. Elle est plus parlante que le compteur d'unités, car avec le vardiff le nombre de shares ne dit rien en soi.

Encore une ligne à surveiller : l'heure du dernier share accepté (last share). Si elle grandit et dépasse déjà plusieurs minutes alors que le hashrate est stable, la connexion est morte de fait, même si le statut du pool est encore vert.

La mécanique des shares et le fait que leur nombre n'égale pas le revenu sont détaillés dans l'article sur les schémas de paiement FPPS et PPLNS.

Quel pourcentage de rejets est considéré comme normal, et lequel est déjà un signal ?

Il n'existe pas de chiffre universel : la part de shares rejetés dépend de la distance jusqu'au serveur stratum, de la qualité du lien, du firmware et des réglages de vardiff. Il faut se repérer non pas sur une valeur absolue, mais sur votre propre ligne de base : notez votre pourcentage habituel un jour calme et considérez comme écart tout ce qui monte nettement au-dessus et s'y maintient.

Une approche pratique plutôt qu'un chiffre magique :

1. Relevez la part de rejected sur une journée de fonctionnement normal. C'est votre zéro.
2. Suivez non pas la valeur instantanée, mais la moyenne sur une heure. Les pics isolés au changement de bloc sont normaux, pas une panne.
3. Une part qui monte alors que le hashrate local ne bouge pas signifie un problème de lien ou de pool, pas de matériel.
4. Une part qui monte en même temps que le hashrate local baisse signifie du matériel.

Trois pools annoncent leurs propres repères, et ils divergent entre eux plus que les mineurs qui se disputent dans les chats. AntPool écrit dans son centre d'aide qu'une part de rejetés inférieure à 1 pour cent est considérée comme normale, et une part de shares périmés autour de 0,5 pour cent ou moins. ViaBTC appelle plage normale des rejets dans la limite de 3 pour cent. F2Pool juge raisonnable une part de shares retardés d'environ 2 pour cent. Cet écart de 0,5 à 3 pour cent entre trois grands pools est justement la réponse à la question de la norme : il n'y a pas de norme commune, il y a les réglages d'un pool donné.

Une réserve sur la source : les pages de support de ces pools sont fermées à la vérification automatique, et nous avons relevé les formulations ci-dessus d'après leurs extraits publics de recherche, pas d'après le texte complet des pages. Avant de vous appuyer sur un chiffre précis, ouvrez le centre d'aide de votre pool et vérifiez la version en vigueur.

Le seuil à partir duquel les pertes deviennent sensibles, personne ne le publie, et il n'y a pas besoin de l'inventer : la mécanique se calcule de tête. Un share rejeté n'est pas payé, donc la part de rejets équivaut à peu près à la part de revenu non perçu. Un pour cent de rejets, c'est environ un pour cent de revenu à côté de la caisse, trois pour cent, c'est trois. Savoir s'il vaut la peine de reconfigurer la ferme pour cela dépend de sa taille, pas de la recommandation d'un tiers.

Ce qui n'est certainement pas normal et ne demande aucune statistique : une part de rejetés proche de cent pour cent. C'est presque toujours une mauvaise difficulté, un firmware corrompu ou une connexion bloquée par un intermédiaire, et non une surcharge du pool.

Où regarder pour confirmer une panne du pool ?

Confirmer une panne, c'est toujours une deuxième source indépendante. Votre seul panneau ne suffit pas : il affiche de la même façon une panne du pool et une coupure chez votre fournisseur d'accès. L'ordre de vérification, du plus rapide au plus lent, prend environ cinq minutes et donne presque toujours une réponse sans ambiguïté.

1. Les statistiques de hashrate du compte dans le pool. Si l'espace web s'ouvre et affiche zéro pour votre worker, le serveur est vivant, et ce sont précisément vos shares qui ne lui parviennent pas. Si l'espace ne charge pas du tout, le problème est plus large.
2. La page de statut du pool. Une partie des pools dispose d'une page à part sur l'état des services. Son adresse est à trouver à l'avance et à garder en favoris, pas à chercher au moment de la panne.
3. Moniteurs et explorateurs tiers. Les observatoires publics de la répartition du hashrate montrent si le pool trouve des blocs en ce moment. Une longue pause chez un gros pool est un signe indirect, mais fort.
4. Réseaux sociaux et chats du pool. Le compte officiel et le canal Telegram apprennent en général la panne plus vite que la page de statut ne se met à jour. On y voit aussi si d'autres mineurs se plaignent.
5. Vérification de la route depuis chez vous. Un simple telnet ou nc vers l'adresse et le port du stratum, depuis n'importe quel ordinateur du même réseau, sépare une chute du pool d'un blocage chez le fournisseur en dix secondes.

Si l'espace du pool s'ouvre, que les blocs sont trouvés, que le chat est calme et que vos shares ne sont pas acceptés, alors la panne est chez vous, pas chez le pool.

À quoi sert un backup pool et comment configurer correctement le stratum de secours ?

Le pool de secours, c'est une ligne dans la configuration du mineur vers laquelle l'appareil bascule tout seul quand le stratum principal ne répond plus. Sans elle, l'ASIC coupé de sa connexion se contente de faire tourner ses ventilateurs et ne gagne rien jusqu'à votre intervention. Avec elle, l'arrêt se réduit au temps de reconnexion, qui se mesure en secondes et non en heures de votre sommeil.

À quoi cela ressemble dans la configuration. Les firmwares diffèrent dans les détails, mais le principe est le même : une liste de pools par priorité, le mineur descend de haut en bas.

\`\`\`

pool1: stratum+tcp://[ADRESSE DU POOL PRINCIPAL]:[PORT] worker: compte.worker

pool2: stratum+tcp://[ADRESSE DU POOL DE SECOURS]:[PORT] worker: compte2.worker

pool3: stratum+tcp://[ADRESSE DU TROISIÈME POOL]:[PORT] worker: compte3.worker

\`\`\`

Les règles sans lesquelles le secours ne fonctionnera pas :

1. Le deuxième pool est un autre pool, pas un autre port du même. Une adresse de secours à l'intérieur de la même infrastructure ne sauvera pas de la chute de cette infrastructure. Le port de rechange du pool principal, mettez-le en troisième ligne, pas en deuxième.
2. Le compte sur le pool de secours doit être créé et vérifié à l'avance. S'inscrire au moment de la panne dévore justement cette première heure.
3. L'adresse de paiement sur le pool de secours doit être renseignée. Sinon le miné restera suspendu sur un solde auquel vous reviendrez dans un mois.
4. Testez la bascule à la main. Désactivez le pool principal dans l'interface pendant deux minutes et assurez-vous que les shares sont partis vers le secours, et qu'après le retour le mineur est bien revenu au principal.
5. Tenez compte du schéma de paiement. Un aller-retour entre pools PPLNS remet l'accumulation dans la fenêtre à zéro deux fois, donc il est plus raisonnable de mettre en secours un pool au schéma plus simple. La différence des mécaniques est expliquée dans la comparaison de FPPS et PPLNS.

Le nombre de points d'entrée disponibles varie selon les pools, et il se voit dans leur propre documentation. Nous avons compté les hôtes stratum uniques pour BTC sur les pages de connexion de six pools.

Ici, l'important n'est pas qu'un pool ait huit hôtes et un autre un seul. L'important est que toutes ces adresses mènent à une seule et même infrastructure : elles protègent de la chute d'une région, mais pas de la chute du pool. C'est exactement pour cela que la deuxième ligne de la configuration doit pointer vers l'extérieur.

Combien d'argent un mineur perd-il vraiment par heure d'arrêt et comment le calculer soi-même ?

La perte pour une heure d'arrêt se calcule en une ligne : le revenu journalier de votre matériel, divisé par 24, multiplié par la part d'arrêt. Aucun modèle compliqué n'est nécessaire ici, car le revenu dans un pool est linéaire par rapport au hashrate. La seule chose importante est de prendre le hashprice actuel, et non un chiffre d'un article d'il y a six mois, sinon l'erreur sera d'un facteur, pas de quelques pour cent.

La formule :

\`\`\`

perte = (hashrate en TH/s × hashprice en USD par TH/s et par jour) / 24 × heures d'arrêt

\`\`\`

Le hashprice, c'est le revenu par térahash et par jour avant déduction de l'électricité. Il change chaque jour avec le cours et la difficulté, alors mettez-y une valeur fraîche.

Nous ne figeons volontairement pas le hashprice dans le texte sous forme de chiffre. Il change chaque jour avec le cours et la difficulté, et une valeur tirée d'un article vieux d'un mois donne une erreur d'un facteur, pas de quelques pour cent. Mettez la valeur fraîche du jour du calcul : les indices publics de hashprice et notre calculateur l'affichent.

Ce qu'il est important de ne pas oublier dans le calcul :

• L'électricité est en partie consommée pendant l'arrêt. Si le mineur est allumé mais ne peut pas envoyer de shares, il consomme quand même. La perte réelle par heure dépasse le manque à gagner net du coût de cette consommation.
• Le PPLNS punit l'arrêt deux fois. Dans les schémas cumulatifs, non seulement vous n'avez rien gagné pendant cette heure, mais vous avez aussi perdu votre position dans la fenêtre, qui ne se rétablit pas instantanément. Dans les schémas de type PPS, la perte est exactement égale à la formule.
• Calculez sur toute la ferme, pas sur une seule machine. Une heure d'arrêt de dix appareils coûte dix fois plus cher, et devant ce chiffre la décision sur le pool de secours se prend toute seule.

Calculer le revenu pour votre hashrate et les paramètres actuels du réseau est plus commode dans le calculateur que de tête.

Quoi faire dans la première heure : la checklist pas à pas

1. Minutes 0-2. Regardez le hashrate local dans le panneau du mineur. S'il a baissé en même temps que celui du pool, c'est le matériel, et il est inutile de continuer cette liste.
2. Minutes 2-5. Vérifiez le statut des pools et l'heure du dernier share accepté. Un statut dead et un temps qui grandit confirment la coupure.
3. Minutes 5-10. Ouvrez l'espace du pool et la page de statut. Si rien ne s'ouvre, y compris les autres sites, l'affaire est dans votre lien.
4. Minutes 10-15. Vérifiez l'accessibilité du stratum depuis un autre appareil du même réseau, puis depuis l'internet mobile. La différence de résultat désigne le fournisseur d'accès ou le routeur.
5. Minutes 15-20. Jetez un œil au chat et aux réseaux sociaux du pool. Des plaintes massives dans les dernières minutes closent la question.
6. Minutes 20-30. Assurez-vous que le secours a pris le relais. S'il n'y a pas de pool de secours dans la configuration, inscrivez-le maintenant : c'est la seule action qui ramène du revenu tout de suite.
7. Minutes 30-45. Ne touchez plus à rien. Un redémarrage massif de la ferme, un reflashage et un changement de difficulté pendant la panne d'un autre vous ajoutent une deuxième panne par-dessus la première.
8. Minutes 45-60. Consignez les faits. Heure de début, capture d'écran du panneau, heure du dernier share, réponse du pool. Sans cela, la discussion sur une compensation se transforme en dispute sur les souvenirs.

Quand un arrêt est-il une raison de changer de pool, et quand ne l'est-il pas ?

Une panne unique n'est pas une raison de déménager. L'infrastructure tombe chez tout le monde, et le coût d'un changement de pool dépasse souvent la perte de quelques heures d'arrêt. La raison apparaît quand les arrêts se répètent, durent longtemps et ne s'accompagnent d'aucune communication claire : le silence du pool pendant une panne coûte plus cher que la panne elle-même.

Avant de déménager, calculez le prix du déménagement lui-même : la remise à zéro de la fenêtre en PPLNS, l'attente du nouveau seuil de paiement, le temps de reconfiguration. Si vous penchez vers le minage SOLO comme moyen d'échapper à la dépendance à l'infrastructure d'autrui, regardez d'abord la comparaison du SOLO et du pool : là-bas cette même dépendance change simplement de forme.

Pourquoi presque aucun pool ne publie son uptime et comment évaluer la fiabilité indirectement ?

Une page publique d'uptime est un engagement qu'il n'est pas avantageux de prendre : n'importe quel chiffre deviendra un prétexte à réclamations et à comparaisons, et pour le mesurer honnêtement il faut le faire de l'extérieur. C'est pourquoi la plupart des pools se limitent aux statistiques de blocs trouvés et de hashrate. Il faut évaluer la fiabilité indirectement, d'après des signes observables et non d'après des pourcentages déclarés.

Que regarder quand le chiffre d'uptime n'existe pas :

• La régularité des blocs trouvés. Chez un gros pool, les pauses sont prévisibles d'après sa part du réseau. Un silence anormalement long se voit dans n'importe quel explorateur public.
• La présence d'une page de statut et d'un historique d'incidents. Le simple fait qu'un pool tienne un journal public des pannes en dit plus qu'un joli chiffre de 99,9.
• La rapidité et la substance de la communication. Un message dans le chat dans les premières minutes de la panne vaut plus qu'un billet d'excuses le lendemain.
• Le nombre de points d'entrée indépendants. Des régions différentes, des adresses stratum différentes, la prise en charge de plusieurs ports. Cela réduit le risque que vous perdiez la connexion entièrement.
• Les retours des mineurs sur les pannes passées. Non pas sur l'existence de pannes, mais sur le fait que les statistiques soient tombées juste après.

Nous avons vérifié les documents publics de huit pools le 09.09.2026. Une véritable page d'état avec historique d'incidents et chiffres d'uptime n'a été trouvée que chez un seul : Luxor la publie sur uptime.luxor.tech, avec un détail par service (interface du pool 99,766 pour cent, traitement des statistiques 99,956 pour cent, une partie des services 100 pour cent) et un journal sur trois mois. Foundry a status.foundry.ac, mais c'est le statut des services d'entreprise de Foundry Digital, et non une page distincte du pool de minage. F2Pool tient une rubrique d'annonces avec des messages sur les incidents, mais ce n'est pas une page d'état. Chez ViaBTC, le chiffre de 99,99 pour cent se rencontre dans les documents marketing, et la page où le vérifier, nous ne l'avons pas trouvée. Chez AntPool, Braiins Pool, Binance Pool et Ocean, aucune page publique d'état n'a été décelée par la recherche. Ce dernier point signifie précisément « non trouvé dans le cadre de cette vérification », et non une absence garantie.

Vérification des pages publiques des pools, 09.09.2026.

Les paramètres consolidés des pools, y compris les schémas de paiement, les commissions et les seuils, sont rassemblés dans les fiches de pools. Il n'y a pas de données d'uptime là-bas, exactement pour la raison ci-dessus : il n'y a rien à comparer tant que les pools ne le publient pas.

En bref

Le pool tombe moins souvent qu'il n'y paraît dans la première minute. L'ordre des actions est toujours le même : d'abord séparer votre matériel du serveur d'autrui, puis confirmer l'arrêt par une deuxième source, puis s'assurer que le stratum de secours a repris la charge. Un pool de secours dans la configuration coûte zéro et économise des heures de revenu, et il faut l'inscrire un jour calme, pas un jour de panne.