--- title: "Attaque des 51%" description: "Une attaque des 51% se produit lorsqu'une partie contrôle suffisamment de pouvoir de consensus pour dépasser de façon fiable le réseau honnête et réorganiser l'historique récent de la blockchain." image: "https://wiki.fcontext.com/og.png" --- > Documentation Index > Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt > Use this file to discover all available pages before exploring further. # Attaque des 51% > À des fins éducatives uniquement ; ceci ne constitue pas un conseil en investissement. Investir peut entraîner des pertes. ## Réponse directe Une attaque des 51% se produit lorsqu'une partie contrôle suffisamment de pouvoir de consensus pour dépasser de façon fiable le réseau honnête et réorganiser l'historique récent de la blockchain. Sur une blockchain fondée sur la preuve de travail (PoW), le terme désigne généralement le contrôle d'une majorité du taux de hachage actif. L'attaquant peut construire une branche concurrente ayant accumulé davantage de travail que la branche honnête et amener les nœuds à l'adopter. « 51% » est un raccourci désignant un avantage durable, et non un interrupteur universel : un attaquant disposant d'un taux de hachage inférieur peut parfois réorganiser par hasard un bloc peu profond, tandis qu'un pouvoir majoritaire temporaire ne garantit pas une attaque rentable. Cette désignation ne doit pas être transposée mécaniquement à la preuve d'enjeu (PoS). Les seuils de vote, la règle de choix de branche, la finalité, les pénalités d'inactivité et le slashing sont propres à chaque protocole. Par exemple, Ethereum documente des conséquences différentes autour de 33%, 34%, 51% et 66% des enjeux. La question pertinente est toujours de savoir quelle règle de consensus et quel objectif d'attaque sont examinés. ## Fonctionnement Les nœuds PoW n'acceptent que les blocs valides et suivent la branche valide ayant accumulé le plus de travail. Un attaquant majoritaire ne peut ni rendre valide une signature invalide ni créer des monnaies en dehors des règles du protocole. Il peut toutefois miner en privé une branche valide qui entre en conflit avec la branche publique et la révéler après l'avoir dépassée. Un scénario classique de double dépense se déroule comme suit : 1. L'attaquant paie un commerçant ou une plateforme d'échange sur la chaîne publique tout en minant en privé une branche qui dépense les mêmes monnaies ailleurs. 2. Le destinataire attend les confirmations, puis remet les biens ou autorise un retrait. 3. Si la branche privée accumule davantage de travail, l'attaquant la publie. Les nœuds se réorganisent sur cette branche et le paiement initial disparaît de l'historique accepté. Chaque confirmation supplémentaire donne une avance plus importante à la branche honnête. Lorsque l'attaquant dispose d'un taux de hachage inférieur à celui du réseau honnête, la probabilité de rattraper ce dernier diminue à mesure que cette avance augmente ; avec une majorité durable, il peut dépasser de façon fiable la branche honnête au fil du temps. Les confirmations réduisent le risque, mais ne créent pas de finalité absolue. Le même contrôle peut servir à censurer ou retarder certaines transactions, à réordonner des transactions récentes et à perturber les confirmations. Il ne permet pas de voler des monnaies protégées par la clé privée d'une autre personne, de dépenser des monnaies qui n'appartiennent pas à l'attaquant ni de forcer les nœuds complets à accepter des blocs contraires aux règles de consensus. ## Exemple Supposons, à titre d'exemple, qu'un petit réseau PoW possède 1 TH/s de taux de hachage honnête. Un attaquant peut louer 1.2 TH/s pour $20,000 par heure, ce qui lui confère environ 54.5% des 2.2 TH/s combinés pendant la location. Il dépose des jetons d'une valeur de $200,000 sur une plateforme d'échange et mine simultanément une branche privée contenant une dépense conflictuelle. Si la plateforme crédite le dépôt après 10 blocs, soit environ 20 minutes sur cette chaîne hypothétique, l'attaquant peut retirer un autre actif avant de publier la branche privée. Une location de deux heures coûte $40,000, mais ce montant ne constitue pas le bénéfice de l'attaquant. Les frais de négociation, le glissement, l'échec de l'exécution, le gel des retraits, la détection et la baisse du prix de l'actif attaqué peuvent rendre la tentative non rentable. Si la plateforme porte son exigence à 200 blocs, l'attaquant doit maintenir la branche concurrente beaucoup plus longtemps. Avec l'intervalle supposé de deux minutes entre les blocs, cela représente environ 6 heures et 40 minutes de temps de confirmation. L'attaque devient plus coûteuse et plus facile à détecter, tandis que les clients légitimes attendent eux aussi plus longtemps. Une politique de confirmation arbitre donc entre la vitesse de règlement et le risque de réorganisation. ## Risques et mesures de contrôle Les cibles les plus exposées sont les paiements récents de grande valeur qui peuvent être convertis ou retirés avant la réaction d'un opérateur. Réécrire un historique datant de plusieurs milliers de blocs exigerait de reconstruire tout le travail ultérieur et de dépasser la chaîne active ; en pratique, les attaques visent donc généralement une fenêtre courte et précieuse. La sécurité économique dépend de bien plus que de la capitalisation boursière d'un jeton. Les facteurs pertinents comprennent le taux de hachage disponible à la location, l'offre de matériel spécialisé, les coûts d'électricité et de coordination, la concentration des pools de minage, les récompenses de bloc, la liquidité du marché et la valeur que le destinataire libère après confirmation. La concentration des pools constitue un signal d'alerte, mais leurs opérateurs ne possèdent pas nécessairement le matériel des mineurs ; ceux-ci peuvent réorienter leur taux de hachage. Les destinataires et les opérateurs d'infrastructure peuvent réduire leur exposition en prenant les mesures suivantes : - fixer les exigences de confirmation en fonction de la valeur de la transaction et des conditions actuelles du réseau ; - surveiller les branches concurrentes, les variations inhabituelles du taux de hachage et les réorganisations profondes ; - suspendre les dépôts ou les retraits lorsque le risque de réorganisation augmente ; et - limiter la quantité de valeur irréversible qui peut sortir pendant une fenêtre de confirmation. Ces mesures réduisent la perte attendue ; aucune ne rend mathématiquement irréversible un règlement PoW probabiliste. ## Idées reçues courantes ### Mythe 1 : un attaquant a besoin d'exactement 51.0% Non. En dessous de 50%, un attaquant peut encore rattraper son retard par hasard, surtout s'il est faible, mais la probabilité diminue à mesure que les confirmations s'accumulent. Au-dessus de 50%, le contrôle durable du taux de hachage lui confère un avantage attendu à long terme. La durée, les conditions du réseau, le coût et l'objectif choisi restent déterminants. ### Mythe 2 : une majorité du taux de hachage peut voler toutes les monnaies Non. Le pouvoir de consensus influe sur le choix de l'historique valide ; il ne révèle pas les clés privées et n'autorise pas les dépenses invalides. Un attaquant majoritaire acquiert principalement la capacité d'annuler ses propres paiements récents, de censurer des transactions et de réordonner des blocs récents. ### Mythe 3 : un nombre fixe de confirmations est toujours sûr Aucun nombre fixe ne convient à toutes les chaînes ni à tous les paiements. Le risque dépend du taux de hachage dont dispose l'attaquant, du budget de sécurité du réseau honnête, de la valeur de la transaction, du délai de détection et de réaction, ainsi que de la rapidité avec laquelle l'actif reçu peut être retiré ou converti. ## Sujets connexes - [Réorganisation de la chaîne (reorg)](/fr/crypto/chain-reorg/) - [La signature d'une délégation de gouvernance est-elle sûre ?](/fr/crypto/governance-delegation-signature-risk/) - [Taux de hachage](/fr/crypto/hashrate/) - [Staking liquide](/fr/crypto/liquid-staking/) - [Preuve de travail (PoW)](/fr/crypto/proof-of-work/) ## Sources - [Bitcoin: A Peer-to-Peer Electronic Cash System](https://bitcoin.org/bitcoin.pdf) - Bitcoin.org (consulté : 2026-08-20) - [Block Chain](https://developer.bitcoin.org/devguide/block_chain.html) - Bitcoin Developer Guide (consulté : 2026-08-20) - [Proof-of-stake attack and defense](https://ethereum.org/developers/docs/consensus-mechanisms/pos/attack-and-defense/) - Ethereum.org (consulté : 2026-08-20) Source: https://wiki.fcontext.com/fr/crypto/fifty-one-percent-attack/index.mdx