Comment configurer un nœud Ethereum (guide 2026)

Un nœud Ethereum vous donne un accès direct au réseau : votre propre endpoint JSON-RPC, sans rate limit, sans tiers qui lit vos requêtes. Ce guide vous emmène d’un serveur Ubuntu vierge à un nœud synchronisé avec des commandes prêtes à copier-coller — Geth comme client d’exécution, Lighthouse comme client de consensus, tous deux gérés par systemd. Il couvre aussi ce que la plupart des tutoriels omettent : le matériel en 2026, la durée de synchronisation, le coût mensuel, et quand vous êtes mieux servi par une API.

Qu’est-ce qu’un nœud Ethereum ?

Un nœud Ethereum est un ordinateur qui exécute un logiciel client Ethereum, stocke une copie de la blockchain, vérifie chaque bloc entrant selon les règles du protocole, et expose une interface JSON-RPC que les wallets et applications utilisent pour lire la chaîne et envoyer des transactions.

Depuis le Merge de septembre 2022, « le client » est en réalité deux programmes qui doivent fonctionner côte à côte. Le client d’exécution (Geth, Nethermind, Besu, Erigon ou Reth) détient le state, exécute les transactions et répond aux appels JSON-RPC. Le client de consensus (Lighthouse, Prysm, Teku, Nimbus ou Lodestar) gère le proof of stake : il suit la beacon chain et indique au client d’exécution quel bloc est la tête actuelle. Les deux communiquent via un port local authentifié (8551) et s’identifient mutuellement avec un secret JWT partagé. L’un sans l’autre n’est pas un nœud fonctionnel. Ce détail piège la plupart des opérateurs débutants.

Il existe trois profils de stockage. Un nœud complet conserve le state récent et élague les anciennes données ; Geth nécessite environ 1,2 à 1,4 To mi-2026. Un nœud archive conserve tout le state historique — bien plus de 10 To sur la disposition classique de Geth basée sur le hachage, ou environ 2 à 3 To sur des clients conçus pour cela comme Erigon et Reth. Un nœud léger ne télécharge que les headers ; cela semble attractif, mais presque aucun peer ne sert les clients légers sur le mainnet, ce n’est donc pas une voie d’accès praticable.

Prérequis pour un nœud Ethereum

Les chiffres ci-dessous décrivent un nœud complet en 2026. Un nœud archive est un projet à part, et un validateur n’ajoute aucun matériel supplémentaire à un nœud complet solide.

Deux lignes méritent une explication.

Le stockage doit être du NVMe. La synchronisation écrit de petits blocs de données aléatoires à un débit élevé. Les SSD SATA restent régulièrement bloqués des jours durant dans la phase de state heal de Geth, et les volumes cloud avec des IOPS par défaut ne se terminent souvent jamais. Un disque NVMe TLC avec cache DRAM est le choix sûr. Côté capacité : la base de données de Geth se situe autour de 1,2 To et Lighthouse ajoute environ 200 à 250 Go, donc 2 To fonctionnent aujourd’hui mais laissent peu de marge — 4 To vous achètent des années.

Le trafic s’accumule aussi. Un nœud déplace de l’ordre de 1 To par mois. Les connexions domestiques gèrent cela sans problème ; les offres VPS avec des limites de trafic serrées, non.

Linux, macOS et Windows fonctionnent tous. Chaque commande ci-dessous suppose Ubuntu 24.04, un standard serveur courant.

Façons de faire tourner un nœud

Vous n’avez pas à tout assembler à la main. Des boîtiers plug-and-play comme DappNode et Avado sont des machines préconfigurées avec un tableau de bord : achetez, connectez, suivez l’assistant. Les cartes ARM fonctionnent aussi — Ethereum on ARM publie des images prêtes à l’emploi pour des cartes de la classe Raspberry Pi 5 avec stockage NVMe, peu coûteuses à faire tourner mais plus lentes à synchroniser. Des launchers automatisent la voie manuelle : eth-docker (basé sur Docker, connaissances du terminal requises), Stereum (installe les clients sur un serveur distant via SSH avec une interface graphique), NiceNode (choisissez un client, démarrez en quelques clics) et Sedge (un assistant CLI de Nethermind qui génère une configuration Docker).

Cloud ou local ? Un VPS convient pour le développement. Si la résistance à la censure fait partie de votre motivation, faites tourner le nœud sur du matériel que vous possédez — un nœud dans une grande région cloud hérite de la juridiction et des conditions d’utilisation de ce fournisseur.

Le reste de ce guide traite de la configuration manuelle. C’est ce qui vous apprend le plus, et tout ce que vous apprenez se transfère aux launchers.

Étape par étape : Geth + Lighthouse sur Ubuntu

1. Préparer le serveur

sudo apt update && sudo apt upgrade -y
sudo useradd --no-create-home --shell /usr/sbin/nologin geth
sudo useradd --no-create-home --shell /usr/sbin/nologin lighthouse
sudo mkdir -p /var/lib/geth /var/lib/lighthouse
sudo chown geth:geth /var/lib/geth
sudo chown lighthouse:lighthouse /var/lib/lighthouse

Ouvrez les ports peer-to-peer et rien d’autre :

sudo ufw allow 30303 comment 'geth p2p'
sudo ufw allow 9000 comment 'lighthouse p2p'
sudo ufw allow 9001/udp comment 'lighthouse quic'

Les ports 8545 (JSON-RPC) et 8551 (engine API) restent fermés vers l’extérieur ; les deux se lient à localhost dans les units ci-dessous.

2. Installer Geth

sudo add-apt-repository -y ppa:ethereum/ethereum
sudo apt update
sudo apt install -y ethereum
geth version

3. Installer Lighthouse

Lighthouse est distribué sous forme de binaire statique. Ce snippet récupère toujours la dernière release :

LH=$(curl -s https://api.github.com/repos/sigp/lighthouse/releases/latest | grep -m1 '"tag_name"' | cut -d '"' -f 4)
curl -LO "https://github.com/sigp/lighthouse/releases/download/${LH}/lighthouse-${LH}-x86_64-unknown-linux-gnu.tar.gz"
tar xzf "lighthouse-${LH}-x86_64-unknown-linux-gnu.tar.gz"
sudo mv lighthouse /usr/local/bin/
lighthouse --version

Vérifiez le téléchargement : chaque page de release liste des sommes de contrôle SHA-256 et une signature PGP ; exécutez sha256sum et comparez, ou importez la clé de Sigma Prime et utilisez gpg --verify. Les binaires échangés sont un vecteur d’attaque réel, et la vérification prend une minute.

4. Créer le secret JWT

sudo mkdir -p /var/lib/jwt
openssl rand -hex 32 | sudo tee /var/lib/jwt/jwt.hex > /dev/null

Les deux clients lisent ce fichier. S’ils voient des secrets différents, ils refusent de communiquer entre eux (voir dépannage).

5. Unit systemd pour Geth

Créez /etc/systemd/system/geth.service :

[Unit]
Description=Geth execution client (mainnet)
After=network-online.target
Wants=network-online.target

[Service]
User=geth
Group=geth
Type=simple
Restart=always
RestartSec=5
TimeoutStopSec=600
ExecStart=/usr/bin/geth \
  --mainnet \
  --syncmode snap \
  --datadir /var/lib/geth \
  --http --http.addr 127.0.0.1 --http.port 8545 \
  --http.api eth,net,web3,txpool \
  --authrpc.addr 127.0.0.1 --authrpc.port 8551 \
  --authrpc.vhosts localhost \
  --authrpc.jwtsecret /var/lib/jwt/jwt.hex

[Install]
WantedBy=multi-user.target

TimeoutStopSec=600 est important : Geth écrit le state sur disque à l’arrêt, et le tuer trop tôt est le moyen classique de corrompre la base de données.

6. Unit systemd pour Lighthouse

Créez /etc/systemd/system/lighthouse.service :

[Unit]
Description=Lighthouse consensus client (mainnet)
After=network-online.target geth.service
Wants=network-online.target

[Service]
User=lighthouse
Group=lighthouse
Type=simple
Restart=always
RestartSec=5
ExecStart=/usr/local/bin/lighthouse bn \
  --network mainnet \
  --datadir /var/lib/lighthouse \
  --execution-endpoint http://127.0.0.1:8551 \
  --execution-jwt /var/lib/jwt/jwt.hex \
  --checkpoint-sync-url https://mainnet.checkpoint.sigp.io \
  --http

[Install]
WantedBy=multi-user.target

L’URL de checkpoint sync permet à Lighthouse de démarrer depuis un state finalisé récent au lieu de rejouer la beacon chain depuis la genèse : des secondes au lieu de jours. Vous faites confiance à cet endpoint pour votre point de départ ; vérifiez le state root par rapport à une seconde source comme beaconstate.info si cela vous préoccupe.

7. Démarrer et observer

sudo systemctl daemon-reload
sudo systemctl enable --now geth lighthouse
journalctl -fu geth

Geth journalise d’abord des téléchargements de headers, puis un flux sans fin de lignes « Imported new chain segment » ; Lighthouse rapporte des slots synchronisés en quelques minutes. Vérifier la progression de la synchronisation :

curl -s -X POST -H 'Content-Type: application/json' \
  -d '{"jsonrpc":"2.0","method":"eth_syncing","params":[],"id":1}' \
  http://127.0.0.1:8545

{"result":false} signifie entièrement synchronisé. Pendant la synchronisation, vous obtenez un objet de progression à la place.

Combien de temps dure la synchronisation ?

Ethereum n’a pas de snapshots de base de données officiels à télécharger, et n’en a pas besoin — les chemins rapides sont intégrés aux clients.

Lighthouse avec checkpoint sync atteint la tête de chaîne en moins d’une minute et rattrape les blocs historiques en arrière-plan. Geth en mode snap sync (le défaut) récupère environ 800 Go à 1 To depuis le réseau, puis reconstruit le state trie localement. Sur le matériel recommandé, prévoyez un à deux jours ; sur du matériel minimum avec un disque médiocre, trois à cinq. La fin du parcours est la phase de « state heal », et si elle tourne pendant des jours sans se terminer, votre disque est trop lent — voir dépannage.

Après la synchronisation initiale, les choses se calment. Depuis la version 1.13, Geth élague le state à la volée (state storage basé sur les chemins), donc la base de données ne grossit plus indéfiniment comme le préviennent les anciens guides. Geth 1.16 et versions ultérieures peuvent aussi supprimer l’historique pré-Merge (--history.chain postmerge), ce qui libère quelques centaines de Go si l’espace se resserre.

Modes de synchronisation : snap, full et archive

Le flag --syncmode dans l’unit Geth détermine quelle part de la chaîne vous vérifiez vous-même et combien d’espace disque vous payez pour cela. Trois modes existent, et le bon découle des questions auxquelles le nœud doit répondre.

Le snap sync est le défaut et ce que ce guide utilise. Geth télécharge le state actuel directement depuis les peers, vérifie les headers de bloc jusqu’à la genèse, puis répare le state trie. Résultat : un nœud complet opérationnel en un à deux jours et une base de données d’environ 1,2 à 1,4 To mi-2026, qui grandit à partir de là.

Le full sync (--syncmode full) réexécute chaque transaction depuis 2015 au lieu de télécharger le state. Le résultat final sur disque est la même base de données élaguée, mais la synchronisation tourne pendant des semaines même sur du matériel puissant. Vous le choisissez pour une raison : vous refusez de faire confiance au téléchargement du state et voulez recalculer tout l’historique sur votre propre machine. C’est une posture de recherche, pas une nécessité opérationnelle.

Le mode archive se situe sur un autre axe : --gcmode archive par-dessus un full sync conserve chaque state intermédiaire au lieu de l’élaguer. Seul un nœud archive répond à « quel était ce solde au bloc 15 000 000 » ou exécute des traces profondes sans recalcul, dont ont besoin les indexeurs, les outils fiscaux et les plateformes d’analyse. Sur la disposition classique de Geth basée sur le hachage, cela coûte bien plus de 10 To. Erigon et Reth stockent l’historique différemment et placent les nœuds archive dans la fourchette de 2 à 3 To mi-2026, donc presque tout nouveau déploiement archive démarre avec l’un des deux ; le mode archive plus récent de Geth basé sur les chemins joue dans la même catégorie de taille mais a moins de recul en production.

Pour un backend de paiement, le snap sync répond à tout : soldes actuels, nouveaux blocs, reçus de transaction. L’archive est pour le jour où vous devez reconstruire le passé.

Choix de client et diversité

Geth plus Lighthouse est un choix par défaut solide, et sa popularité est justement le piège. Le modèle de sécurité d’Ethereum suppose qu’aucun client ne contrôle trop du réseau : un bug de consensus dans un client possédant plus des deux tiers des validateurs pourrait finaliser une chaîne cassée, l’une des seules défaillances que le protocole ne peut pas annuler proprement. Même une part d’un tiers est inconfortable, car la défaillance de ce seul client arrêterait la finalité.

Où en est le réseau mi-2026 : Geth reste en tête de la couche d’exécution avec une part que les mesures situent entre un tiers et environ 40 %, Nethermind suit dans les vingt à trente pourcents, Besu et Reth se maintiennent en bas de la fourchette à deux chiffres, Erigon quelques pourcents. Côté consensus, Lighthouse a dépassé la ligne de confort d’un tiers selon la plupart des décomptes, Prysm suit en deuxième position, puis Teku et Nimbus. Le réseau devient plus sûr à chaque fois qu’un opérateur choisit un client minoritaire, et l’opérateur y perd peu — tous les clients d’exécution parlent le même JSON-RPC, tous les clients de consensus la même API beacon.

Fin 2025 a rendu l’argument concret. Peu après la mise à niveau Fusaka, un bug dans un client de consensus largement utilisé a forcé des correctifs d’urgence, tandis que les nœuds sur les autres clients continuaient à valider sans interruption. Les opérateurs sur des combinaisons minoritaires ont lu à propos de cet incident au lieu d’avoir à le gérer.

Pour un premier nœud, la combinaison de ce guide convient. Pour un second nœud, ou tout usage professionnel, choisissez une combinaison minoritaire comme Nethermind avec Teku, ou Reth avec Nimbus. La configuration ci-dessus se transpose presque à l’identique — chaque combinaison a besoin du même secret JWT et du même câblage d’engine API ; seuls les binaires, les flags et les répertoires de données changent.

Ce que coûte l’exploitation d’un nœud Ethereum

Pas de prix exacts ici ; ils changent chaque mois et varient selon le pays. À la place, le calcul pour le faire vous-même.

Matériel personnel : un mini-PC dans la catégorie des prérequis (8 cœurs, 32 Go de RAM, 2 à 4 To NVMe) est un achat unique dans la centaine d’euros moyenne. La consommation électrique se situe autour de 30 à 60 W. Le calcul : 0,03–0,06 kW × 720 h ≈ 20–45 kWh par mois ; multipliez par votre tarif d’électricité. À 0,30 €/kWh, cela fait 6 à 13 € par mois en plus de la connexion internet que vous payez déjà.

Serveur loué : les offres VPS avec de véritables 2 To de NVMe sont rares, donc en pratique vous atterrissez sur un serveur dédié d’entrée de gamme. Cela vous place dans la fourchette basse des centaines d’euros par mois — un ordre de grandeur, pas un devis. Les instances cloud avec des IOPS provisionnées coûtent nettement plus que la boîte dédiée équivalente.

Votre temps : la première configuration prend un après-midi avec ce guide ; ensuite, les mises à jour des clients et un coup d’œil occasionnel aux logs, comptez une heure par mois. Si vous facturez votre temps, cette ligne appartient aussi au total.

Monitoring et vérifications de santé

Trois questions couvrent la santé du nœud : le processus tourne-t-il, est-il synchronisé, a-t-il des peers. systemd répond à la première avec systemctl is-active geth lighthouse. Les deux autres ont des endpoints sur les deux couches :

# execution: peer count as hex; eth_syncing from step 7 covers sync state
curl -s -X POST -H 'Content-Type: application/json' \
  -d '{"jsonrpc":"2.0","method":"net_peerCount","params":[],"id":1}' \
  http://127.0.0.1:8545

# consensus: HTTP 200 = synced, 206 = still syncing
curl -s -o /dev/null -w '%{http_code}\n' \
  http://127.0.0.1:5052/eth/v1/node/health

L’API REST de Lighthouse écoute sur le port 5052 grâce au flag --http déjà présent dans l’unit. L’endpoint /eth/v1/node/health encode l’état de synchronisation dans le code de statut HTTP, ce qui en fait une sonde naturelle pour les scripts et les load balancers ; /eth/v1/node/syncing renvoie la distance en slots si vous voulez le chiffre. Un cron job exécutant ces vérifications plus df -h /var/lib/geth, envoyant un mail en cas d’anomalie, constitue un monitoring complet pour un nœud personnel.

Pour des tableaux de bord, ajoutez --metrics à Geth (endpoint Prometheus sur le port 6060) et --metrics à Lighthouse (port 5054), gardez les deux sur localhost, et importez les tableaux de bord Grafana que les deux projets publient. Quoi que vous construisiez, définissez deux alertes avant toutes les autres : utilisation disque au-dessus de 85 %, et hauteur de bloc stable pendant dix minutes. Ces deux-là attrapent presque toutes les vraies pannes avant vos utilisateurs.

Maintenance et mises à niveau

Les mises à jour des clients ne sont pas optionnelles. Les hard forks nécessitent un nouveau logiciel, et un nœud sur une ancienne version arrête simplement de suivre la chaîne au bloc du fork. Abonnez-vous aux flux de release de Geth et Lighthouse sur GitHub et au blog de l’Ethereum Foundation — le réseau livre actuellement environ une mise à niveau majeure par an, avec des releases de clients entre les deux.

La procédure reste courte. Geth depuis le PPA se met à jour avec sudo apt upgrade et sudo systemctl restart geth ; confirmez avec geth version. Lighthouse est un binaire unique : répétez le téléchargement de l’étape 3, remplacez /usr/local/bin/lighthouse, redémarrez l’unit. Lisez les notes de version avant de redémarrer — les flags sont parfois renommés, et un flag renommé dans une unit systemd signifie un service qui refuse de démarrer à 2h du matin.

Prévoyez aussi la croissance du disque. Un nœud complet Geth ajoute de l’ordre de 10 à 15 Go par semaine mi-2026 ; Lighthouse grandit plus lentement. Sur un disque de 2 To, c’est un compte à rebours que vous pouvez réinitialiser — l’expiration de l’historique pré-Merge libère quelques centaines de Go (voir dépannage), et un snap sync frais reconstruit une base de données entièrement compactée en un à deux jours. Sur 4 To, la croissance est un sujet annuel plutôt que trimestriel. Le nœud n’a pas besoin d’être en ligne chaque seconde, mais plus il reste hors ligne, plus il lui faudra de temps pour rattraper son retard.

Un nœud complet n’est pas un validateur

Les 32 ETH dont tout le monde a entendu parler appartiennent au staking, pas à l’exploitation d’un nœud. Le nœud de ce guide n’a besoin d’aucun ETH — il valide les blocs au sens où il les vérifie, ce qui coûte du matériel, pas une mise.

Un validateur est un troisième programme à côté des deux clients : il détient des clés de signature, produit des attestations et des blocs, et gagne des récompenses pour cela, avec une adresse de fee recipient configurée pour les revenus. Les 32 ETH sont une garantie que le protocole peut confisquer en cas de faute prouvée. Le niveau d’exigence opérationnel change aussi — un nœud RPC qui passe un week-end hors ligne rattrape simplement son retard le lundi, tandis qu’un validateur hors ligne subit de petites pénalités à chaque epoch.

Avec moins de 32 ETH, le staking mutualisé est le point d’entrée : Rocket Pool et des protocoles similaires permettent à des opérateurs sans permission de faire tourner des validateurs avec une caution plus petite, et certaines configurations de pool tournent exactement sur le nœud construit ci-dessus. Un simple nœud complet ne rapporte rien. Vous le faites tourner pour l’indépendance et la confidentialité, pour le développement, ou comme la base sur laquelle un validateur s’appuiera plus tard.

Sécurité : la disposition des ports est la politique

Tout le modèle de sécurité de cette configuration est visible dans les règles de pare-feu de l’étape 1. Les ports 30303 et 9000/9001 sont ouverts parce que le peer-to-peer a besoin d’inconnus ; 8545 et 8551 se lient à 127.0.0.1 parce que rien en dehors de la machine n’a d’affaire là. Le secret JWT authentifie l’engine API sur 8551, mais traitez-le comme une seconde couche, pas comme une raison d’exposer le port.

Un 8545 ouvert est l’erreur la plus grave, car JSON-RPC n’a aucune authentification. Les scanners trouvent rapidement les ports RPC Ethereum exposés, et les dégâts vont au-delà du parasitisme : avec les mauvais namespaces activés, des étrangers obtiennent des internes de débogage et le contenu du mempool qu’ils ne devraient jamais voir. Gardez --http.api limité aux quatre namespaces de l’unit ; admin, debug et personal restent désactivés sur toute machine dont le port RPC pourrait un jour être accessible.

Quand d’autres machines ont légitimement besoin de la RPC, tunnelisez plutôt que d’exposer : WireGuard ou un tunnel SSH pour vous-même, nginx ou Caddy avec TLS et une allowlist d’IP pour une petite équipe. Les clients tournent déjà en tant qu’utilisateurs système sans connexion depuis l’étape 1, donc un processus client compromis n’hérite d’aucun compte shell. Ajoutez unattended-upgrades pour les correctifs du système, et la partie ennuyeuse de la sécurité serveur se gère toute seule.

Dépannage

Lighthouse n’arrive pas à joindre Geth (“Unable to connect to execution endpoint”)

Soit Geth est en panne (systemctl status geth), soit les secrets JWT diffèrent. Confirmez que les deux units pointent vers le même chemin jwt.hex. En cas de doute, régénérez le secret une fois et redémarrez les deux services.

Geth reste bloqué sur “State heal in progress” pendant des jours

La phase de state heal poursuit la tête de chaîne, et un disque avec de faibles performances en écriture aléatoire ne la rattrape jamais. Benchmarkez avec fio ; vous voulez des dizaines de milliers d’IOPS 4k. Les SSD SATA et les volumes cloud par défaut sont les coupables habituels. La solution est du vrai stockage NVMe — aucun flag ne sauve un disque lent.

Le nombre de peers reste à zéro

Le port 30303 (TCP et UDP) est bloqué ou non transféré par votre NAT. Vérifiez aussi l’horloge système : timedatectl devrait montrer une synchronisation NTP active, car une horloge décalée casse les handshakes de peers côté consensus.

Le disque se remplit

Trouvez d’abord la croissance : du -h --max-depth=2 /var/lib/geth. Un datadir créé avant Geth 1.13 utilise encore l’ancienne disposition basée sur le hachage ; le correctif propre est un resync frais, après quoi le state reste automatiquement élagué. Activer l’expiration de l’historique pré-Merge libère quelques centaines de Go supplémentaires, et le stockage ancien peut déménager vers un HDD bon marché via --datadir.ancient.

Geth signale une corruption de base de données après un crash

Une coupure de courant, un kill -9 ou un OOM kill en pleine écriture laisse des lignes de log sur une corruption ou des données manquantes au prochain démarrage. Parfois un redémarrage guérit cela ; si le log boucle, arrêtez de réparer et resynchronisez à la place — déplacez le datadir de côté, repartez de zéro, et le snap sync reconstruit tout en un à deux jours, généralement plus vite que toute tentative de réparation. La prévention est déjà dans l’unit : TimeoutStopSec=600 laisse à Geth le temps de flusher, et un systemctl stop propre est la seule façon dont le processus devrait jamais se terminer.

L’OOM killer termine Geth

journalctl -k | grep -i oom confirme le soupçon. Le --cache de Geth est fixé par défaut à 4096 Mo sur mainnet, et l’utilisation réelle dépasse ce réglage pendant la synchronisation ; ajoutez Lighthouse et le système d’exploitation, et une machine de 16 Go manque de mémoire. Définissez --cache 2048 sur les petites machines et gardez un fichier swap comme tampon — lent vaut mieux que tué, car un Geth tué ne flushe rien et provoque le cas de corruption ci-dessus.

Faire tourner son propre nœud — ou utiliser une API ?

Une comparaison honnête, puisque Chaingateway vend l’alternative.

Le nœud l’emporte quand vous avez besoin d’un JSON-RPC brut, lourd et soutenu : requêtes archive, tracing, surveillance du mempool, ou confidentialité et résistance à la censure maximales. Un nœud est un coût fixe avec des requêtes illimitées — au montant de quelques centaines d’euros par mois de la section coûts, il sous-cote toute offre RPC facturée à l’usage une fois votre volume suffisamment élevé. C’est aussi la meilleure façon de comprendre comment Ethereum fonctionne réellement.

L’API l’emporte quand le nœud ne serait qu’un moyen vers une fin, ce qui pour la plupart des entreprises signifie les paiements. Un nœud synchronisé vous donne eth_sendRawTransaction et les logs d’événements. Il ne vous donne pas d’adresses de dépôt par client, de notifications quand un paiement ERC-20 arrive, de gestion des clés ou de logique de retry. C’est un logiciel applicatif que vous devriez construire et exploiter par-dessus, et cela coûte généralement plus d’heures que le nœud lui-même.

L’API Ethereum de Chaingateway est exactement cette couche manquante : créer et importer des adresses (POST /api/v2/ethereum/addresses/import), envoyer des tokens ERC-20 (POST /api/v2/ethereum/transactions/erc20), et recevoir des webhooks signés HMAC pour les dépôts entrants — les livraisons échouées atterrissent dans une liste interrogeable (GET /api/v2/ethereum/webhooks/notifications/failed) et peuvent être renvoyées via l’endpoint de retry. Le seuil de rentabilité est de l’arithmétique : coût du serveur plus vos heures de construction et d’exploitation face à un plan sur /fr/pricing/. Pour les flux de paiement, le côté API de cette inégalité reste plus petit bien au-delà de l’échelle amateur ; pour la consommation RPC brute, le côté nœud l’emporte tôt. Commencez avec le quickstart et le guide des webhooks — l’essai de 7 jours sans KYC suffit pour tester un flux de dépôt de bout en bout (inscrivez-vous ici).

Vous faites tourner d’autres chaînes ? Consultez les guides pour BNB Smart Chain et TRON.