---
title: "Nœud RPC"
description: "Un nœud RPC fournit aux portefeuilles et applications une interface de requête-réponse pour lire les données de la blockchain et diffuser des transactions. Découvrez ce qu'un changement de point d'accès peut résoudre ou non, et comment réduire les risques de disponibilité, de confidentialité et de sécurité."
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.
# Nœud RPC
> À des fins éducatives uniquement ; ceci ne constitue pas un conseil en investissement. Un point d'accès RPC incorrect ou malveillant peut exposer l'activité, renvoyer des données trompeuses ou perturber l'envoi des transactions, et les opérations sur actifs numériques peuvent causer des pertes irréversibles.
## Réponse directe
Un nœud RPC est un nœud de blockchain, ou un service placé devant un ou plusieurs nœuds, qui accepte les appels de procédure distante des portefeuilles, explorateurs et applications. Sur les réseaux compatibles avec Ethereum, l'interface courante est JSON-RPC. Elle permet au logiciel de lire les données du nœud, simuler des appels, estimer le gas et soumettre des octets de transaction signés à diffuser sans exploiter son propre nœud.
L'URL configurée dans un portefeuille est un **point d'accès RPC**, et non la blockchain elle-même. En changer peut contourner une panne du fournisseur, un nœud obsolète, une limitation de débit, une méthode non prise en charge ou un problème de connexion. Cela ne peut ni modifier les règles d'un contrat, ni restaurer une transaction annulée, ni inverser un transfert confirmé, ni réparer un arrêt général du réseau. Le nouveau point d'accès doit desservir le réseau et l'ID de chaîne prévus.
## Fonctionnement
Le client envoie une requête par un transport pris en charge, comme HTTP ou WebSocket. Une requête JSON-RPC nomme une méthode, fournit des paramètres et contient un identifiant répété dans la réponse. Le nœud exécute la méthode sur sa vue locale de la chaîne et renvoie un résultat ou une erreur. Les connexions WebSocket peuvent aussi prendre en charge des abonnements lorsque le client et le point d'accès les proposent.
Les méthodes de lecture ont des sens et besoins en données différents. Par exemple, `eth_blockNumber` indique le dernier bloc connu du nœud, tandis que `eth_getBalance` lit le solde d'une adresse à une étiquette ou un numéro de bloc donné. Des nœuds sains peuvent temporairement diverger selon leur tête de chaîne, leur pool en attente, leur mode d'élagage ou leurs extensions. Un fournisseur hébergé peut aussi imposer authentification, quotas, limites de taille ou restrictions de méthodes qui ne sont pas des règles de consensus.
Pour une transaction de portefeuille typique, le portefeuille la construit et la signe localement, puis envoie les octets signés avec `eth_sendRawTransaction`. Le nœud RPC vérifie la requête et tente de propager la transaction à ses pairs. Le retour d'un hachage signifie que le nœud a accepté les octets pour soumission ; il ne prouve ni inclusion, ni réussite, ni finalité. Il faut vérifier indépendamment l'inclusion et l'état sur la bonne chaîne.
Le point d'accès est donc une dépendance de confiance et de disponibilité. Il peut observer les adresses interrogées, les informations IP, les horaires et les transactions soumises ; omettre ou retarder des données ; présenter une vue obsolète ou incomplète. Les signatures cryptographiques empêchent la modification discrète d'une transaction correctement signée, mais ne garantissent pas la véracité des réponses de lecture et ne protègent pas les métadonnées non signées ou la confidentialité.
## Exemple
Un portefeuille peut demander le numéro de bloc à un client d'exécution Ethereum avec cette requête :
```json
{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":1}
```
Une réponse valide peut être :
```json
{"jsonrpc":"2.0","id":1,"result":"0x12ab34"}
```
Le résultat hexadécimal est le dernier numéro de bloc connu de ce point d'accès. Si le fournisseur habituel expire mais qu'un second point d'accès réputé renvoie un bloc plus récent et l'ID de chaîne attendu, le changement peut rétablir les lectures de solde et l'envoi de transactions. Si les deux montrent le même reçu annulé, changer de RPC ne modifie pas ce résultat sur la chaîne.
## Risques et contrôles
- **Mauvais réseau :** un point d'accès copié peut desservir une autre chaîne ou bifurcation. Avant de signer, vérifiez auprès d'une source indépendante l'ID de chaîne, le nom du réseau, l'actif natif et un bloc récent.
- **Lectures fausses ou obsolètes :** un point d'accès défaillant ou malveillant peut renvoyer d'anciens soldes, omettre des journaux ou fausser une simulation. Comparez les lectures importantes avec un autre fournisseur ou votre propre nœud et fixez un bloc explicite lorsque la reproductibilité compte.
- **Fuite de confidentialité :** les requêtes peuvent relier l'activité du portefeuille aux métadonnées réseau. Évitez les adresses inutiles, examinez les politiques de conservation et envisagez un point d'accès auto-hébergé fiable si le gain de confidentialité justifie le coût d'exploitation.
- **Censure ou retard :** le point d'accès peut refuser ou retarder la diffusion. Conservez le hachage signé, consultez des explorateurs ou nœuds indépendants et utilisez une seconde voie fiable si la transaction est absente. Ne signez pas de remplacement sans vérifier le nonce et l'effet sur les frais.
- **Identifiants exposés :** les clés API dans du code public peuvent être volées et épuiser les quotas. Limitez-les par origine ou service si possible, gardez les identifiants privilégiés hors du client et remplacez les clés divulguées.
- **Exposition dangereuse du nœud :** publier une interface administrative ou trop large augmente la surface d'attaque. Liez par défaut votre RPC localement, n'exposez que les espaces de noms requis, ajoutez authentification et contrôles réseau, et n'exposez jamais de comptes déverrouillés.
- **Tromperie du portefeuille :** une URL de point d'accès n'a besoin ni de phrase de récupération ni de clé privée. Refusez tout service qui les demande, inspectez les champs de transaction dans le portefeuille et n'identifiez jamais un contrat de destination d'après la seule réponse RPC.
## Idées reçues
- **« RPC est la blockchain. »** C'est une interface vers la vue de la blockchain détenue par un nœud.
- **« Un hachage signifie confirmation. »** Il prouve généralement seulement que le point d'accès a accepté les octets signés ; exécution et finalité sont des étapes distinctes.
- **« Changer de RPC modifie les frais ou le contrat. »** Cela peut changer les estimations ou la qualité d'accès, mais l'exécution réelle dépend de la transaction et des règles du protocole.
- **« Tous les points d'accès renvoient les mêmes données. »** Synchronisation, pools en attente, historique conservé, extensions et politiques peuvent varier.
- **« HTTPS rend chaque réponse fiable. »** HTTPS protège la connexion au serveur nommé, sans prouver que ses données de blockchain sont complètes ou exactes.
## Sujets liés
- [Nœud complet](/crypto/full-node/)
- [Blockchain](/crypto/blockchain/)
- [Mempool](/crypto/mempool/)
- [RPC de transaction privée](/crypto/private-transaction-rpc/)
- [Explorateur de blocs](/crypto/block-explorer/)
## Sources
- [API JSON-RPC](https://ethereum.org/developers/docs/apis/json-rpc/) - Ethereum.org (consulté le : 2026-08-21)
- [Spécification de l'API d'exécution](https://ethereum.github.io/execution-apis/docs/quickstart/) - Ethereum Execution APIs (consulté le : 2026-08-21)
- [Serveur JSON-RPC](https://geth.ethereum.org/docs/interacting-with-geth/rpc) - go-ethereum (consulté le : 2026-08-21)
- [Exploiter son propre nœud Ethereum](https://ethereum.org/developers/docs/nodes-and-clients/run-a-node/) - Ethereum.org (consulté le : 2026-08-21)
Source: https://wiki.fcontext.com/fr/crypto/rpc-node/index.mdx