Le widget ci-dessus est déjà réglé sur le devnet. Collez une signature, un portefeuille ou une adresse de programme devnet : il lit directement api.devnet.solana.com. Basculez le sélecteur de réseau sur testnet ou mainnet quand vous avez besoin d’un autre cluster. La suite de cette page explique comment fonctionne un explorateur devnet Solana dans Solana Explorer et Solscan, comment pointer un explorateur vers un validateur local, comment se comporte le faucet en septembre 2026, et quelles confusions expliquent la quasi-totalité des messages « transaction not found » pendant le développement.
Que sont les clusters Solana, et pourquoi l’explorateur s’en soucie-t-il ?
Un cluster est un réseau Solana indépendant, avec son propre registre, ses validateurs et ses nœuds RPC. Solana exploite trois clusters publics : Mainnet Beta (vrais SOL), Devnet (tests d’applications) et Testnet (tests des validateurs et des nouvelles versions). Une transaction ou un compte présent sur l’un n’existe pas sur les autres : l’explorateur doit donc savoir quel cluster interroger.
La référence officielle des clusters indique un endpoint RPC public par cluster :
- Mainnet Beta :
https://api.mainnet-beta.solana.com - Devnet :
https://api.devnet.solana.com - Testnet :
https://api.testnet.solana.com
Les trois partagent les mêmes limites publiées : 100 requêtes par tranche de 10 secondes et par IP, 40 requêtes par 10 secondes pour une même méthode RPC, et 40 connexions simultanées. Ils sont conçus pour les tests et un usage léger, pas pour des applications en production. Lors de nos propres tests de septembre 2026, les endpoints devnet et testnet ont répondu de façon fiable aux requêtes du navigateur, alors que l’endpoint mainnet renvoyait une erreur HTTP 403 depuis notre IP de test. C’est pourquoi l’outil de recherche de Solscanner fait tourner d’autres nœuds sans clé pour le mainnet (détails sur notre page consacrée aux API d’explorateurs Solana), mais utilise les endpoints officiels pour le devnet et le testnet.
Devnet ou testnet : lequel choisir ?
Utilisez le devnet, sauf raison précise. Le devnet reproduit le logiciel qui tourne sur le mainnet, dispose d’un faucet, et c’est le réseau par défaut des portefeuilles, SDK et tutoriels quand ils parlent de « test ». Le testnet est l’endroit où les opérateurs de validateurs et les ingénieurs du cœur essaient les nouvelles versions avant le mainnet. La semaine du 22 septembre 2026, par exemple, la mise à jour de consensus Alpenglow a été activée sur le testnet alors que sa date mainnet n’était pas encore annoncée. Le testnet est donc utile pour suivre les évolutions du réseau, mais moins prévisible pour développer une application.
Les deux clusters de test peuvent être réinitialisés, et les SOL de test n’ont aucune valeur marchande. Ne considérez jamais un solde devnet comme de l’argent, et ne collez jamais une clé privée mainnet dans un outil sous prétexte qu’il « ne vise que » le devnet.
Ouvrir l’explorateur Solana sur le devnet en 5 étapes
En bref : ajoutez un paramètre de cluster à l’URL. La version détaillée ci-dessous sert aussi de liste de contrôle quand une signature refuse d’apparaître.
- Vérifiez le cluster utilisé. Lancez
solana config get, regardez le réseau réglé dans votre portefeuille ou lisez l’URL RPC dans votre code. C’est le seul cluster où l’explorateur pourra trouver votre transaction. - Ouvrez l’explorateur sur le devnet. Ajoutez
?cluster=devnetou?cluster=testnetà une URL Solana Explorer ou Solscan, ou choisissez Devnet dans le sélecteur de réseau du widget ci-dessus. - Collez la signature ou l’adresse. Une signature de transaction compte généralement 87 à 88 caractères base58, une adresse de compte 32 à 44. La page charge alors les données depuis le nœud RPC de ce cluster.
- Pointez l’explorateur vers localhost. Pour un
solana-test-validatorlocal, choisissez Custom RPC dans Solana Explorer et saisissezhttp://localhost:8899. - Alimentez un portefeuille de test. Demandez des SOL de test sur faucet.solana.com ou avec
solana airdrop. Il en faut pour les frais et le rent avant qu’une transaction de test puisse aboutir.
Une fois la page chargée, une transaction devnet se lit exactement comme sur le mainnet : statut, frais, compute units, instructions et variations de soldes. Notre guide de l’explorateur de transactions détaille chaque champ.
URL devnet de Solana Explorer et de Solscan
Les deux principaux explorateurs acceptent un paramètre de requête cluster : une URL d’explorateur devnet n’est donc que l’URL habituelle suivie de ce paramètre. C’est aussi la façon la plus simple de partager un lien devnet avec un collègue, puisque le cluster voyage dans le lien.
| Explorateur | Devnet | Testnet | Local / personnalisé |
|---|---|---|---|
| Solana Explorer | ?cluster=devnet | ?cluster=testnet | Custom RPC dans le menu |
| Solscan | ?cluster=devnet | ?cluster=testnet | Pas son usage principal |
| Recherche Solscanner | Sélecteur de réseau | Sélecteur de réseau | Non |
Des modèles concrets à mettre en favori :
https://explorer.solana.com/tx/<signature>?cluster=devnethttps://explorer.solana.com/address/<address>?cluster=testnethttps://solscan.io/tx/<signature>?cluster=devnethttps://explorer.solana.com/?cluster=custom&customUrl=http://localhost:8899
L’explorateur officiel Solana Explorer, édité par la Solana Foundation, est l’option la plus complète pour les clusters de test. Son code source sur GitHub définit quatre choix de cluster (Mainnet Beta, Testnet, Devnet et Custom RPC), et des fonctions comme l’onglet IDL, le décodage des comptes Anchor ou la simulation d’instructions fonctionnent aussi sur le devnet. Solscan, sur solscan.io, convient très bien pour des recherches devnet rapides, même si certains de ses tableaux de bord analytiques et étiquettes de tokens sont pensés d’abord pour le mainnet. Tous les explorateurs ne couvrent pas les clusters de test : si vous utilisez un autre outil, vérifiez sa documentation avant de compter dessus pour le devnet.
RPC personnalisé ou localhost avec solana-test-validator
Solana Explorer peut lire n’importe quelle URL RPC que vous lui fournissez, y compris celle d’un validateur qui tourne sur votre ordinateur portable. Lancez solana-test-validator (son JSON-RPC écoute par défaut sur le port 8899), puis choisissez Custom RPC dans le menu des clusters et saisissez http://localhost:8899. Comme l’explorateur s’exécute dans votre navigateur, la requête va de votre machine à votre machine, et aucune donnée ne quitte votre ordinateur.
C’est la boucle de retour la plus rapide pour développer un programme. Déployez avec Anchor ou la CLI Solana, envoyez une instruction de test et ouvrez la signature dans l’explorateur pour voir les logs décodés, les compute units et les modifications de comptes. Quand vous réinitialisez le registre local, l’explorateur n’affiche plus rien, ce qui est normal.
Les guides développeurs de Solana mentionnent désormais aussi Surfpool, un validateur local qui récupère les comptes et programmes du mainnet dont dépendent vos transactions, avec son propre studio web. Le principe reste le même : pointez votre explorateur vers l’URL RPC locale affichée au démarrage.
Vous pouvez également saisir un endpoint RPC privé ou payant dans Custom RPC. C’est pratique quand l’endpoint devnet public vous limite pendant une grosse série de tests. Le guide de l’explorateur de programmes détaille ce qu’il faut vérifier une fois votre programme déployé.
Obtenir des SOL de test : faucet et airdrop en 2026
Même sur le devnet, il vous faut des SOL de test pour les frais et le rent. Le faucet web faucet.solana.com sert le devnet et le testnet. Au moment où nous écrivons, il autorise au maximum deux demandes toutes les huit heures sans connexion, et une connexion GitHub relève cette limite (le faucet valide les comptes GitHub, et certains ne passent pas).
En ligne de commande :
solana config set --url devnet
solana airdrop 2
solana balance
solana airdrop appelle la méthode RPC requestAirdrop sur l’endpoint public, souvent limitée quand de nombreux développeurs la sollicitent en même temps. En cas d’échec, passez par le faucet web, patientez et réessayez, ou lancez un validateur local sur lequel vous pouvez vous créditer autant que vous voulez.
Le calcul des frais est le même que sur le mainnet : 5 000 lamports par signature en frais de base, plus d’éventuels frais de priorité, et des dépôts d’exemption de rent pour chaque nouveau compte. Un portefeuille de test avec une fraction de SOL va loin, mais le déploiement d’un programme en demande davantage, car le compte du programme contient son bytecode.
Attention aux arnaques : personne ne peut vous vendre des SOL devnet qui deviendraient de vrais SOL, et aucun faucet n’a besoin de votre phrase de récupération. Les sites qui promettent des « airdrops mainnet » en échange de la connexion d’un portefeuille ou d’un paiement sont du phishing. Les SOL de test n’existent que sur les clusters de test.
Pourquoi votre transaction devnet est « introuvable »
Dans la plupart des cas, l’explorateur regarde tout simplement le mauvais cluster. Avant de déboguer votre code, vérifiez que le cluster de l’explorateur correspond à l’URL RPC par laquelle vous avez envoyé la transaction. Voici les confusions que nous voyons le plus souvent, à peu près par ordre de fréquence.
L’explorateur s’est ouvert sur le mainnet. Solana Explorer et Solscan démarrent sur Mainnet Beta. Si vous collez une signature devnet sans ?cluster=devnet, vous obtenez une page « not found » alors que la transaction est parfaitement valide. Les portefeuilles aggravent parfois le problème : leur lien « voir dans l’explorateur » oublie de temps en temps le paramètre de cluster.
Votre portefeuille et votre code ne sont pas d’accord. Votre portefeuille navigateur peut être sur le devnet pendant que votre script utilise une URL RPC mainnet, ou l’inverse. Le portefeuille signe, le script envoie, et la transaction atterrit sur un cluster inattendu.
La transaction n’a jamais abouti. Une transaction Solana fait référence à un blockhash récent qui reste valide 150 slots, comme l’explique la documentation sur les transactions. Avec le temps de slot actuel d’environ 250 à 300 ms, cela représente nettement moins d’une minute. Si votre client n’a pas attendu la confirmation, ou si le réseau a abandonné la transaction, il n’y a rien à trouver sur aucun cluster. Une transaction simulée n’est jamais on-chain non plus.
Décalage de commitment. Si votre code n’a attendu que processed, un bloc peut encore être annulé. Les explorateurs interrogent généralement en confirmed ou finalized : une signature toute fraîche peut donc mettre quelques secondes à apparaître.
Confusion d’adresses entre clusters. Les identifiants de programme peuvent être identiques sur plusieurs clusters : le programme pump.fun, par exemple, a la même adresse sur le mainnet et le devnet. Ce n’est généralement pas le cas des mints de tokens. L’USDC devnet a un autre mint que l’USDC mainnet : un solde de token « manquant » signifie souvent que vous avez utilisé le mint mainnet dans un test devnet. Notre guide de l’explorateur de tokens explique comment vérifier un mint.
Quel explorateur Solana pour développeurs choisir sur les clusters de test ?
Pour le devnet et le travail en localhost, Solana Explorer est le meilleur choix, car il accepte les URL RPC personnalisées et décode les programmes Anchor. Solscan fait un bon deuxième onglet pour les recherches devnet rapides. Pour l’analytique propre au mainnet, consultez notre classement des meilleurs explorateurs Solana.
Une configuration pratique utilisée par beaucoup de développeurs :
- Solana Explorer en Custom RPC pour le validateur local pendant la phase de développement.
- Solana Explorer ou Solscan avec
?cluster=devnetpour les déploiements de test partagés et les liens de recette. - L’outil de recherche Solscanner pour vérifier rapidement, sans fioritures, un solde ou une signature devnet, surtout quand vous voulez passer du devnet au testnet puis au mainnet avec un seul sélecteur.
Si les explorateurs sont nouveaux pour vous, notre guide débutant pour lire un explorateur Solana explique comptes, signatures et slots avant de vous lancer dans les tests.
Les bons réflexes avec un explorateur devnet
Quelques habitudes évitent la plupart des maux de tête sur les clusters de test. D’abord, journalisez toujours l’URL complète de l’explorateur, avec son paramètre de cluster, à côté de chaque signature affichée par vos scripts. Ensuite, gardez une seule variable d’environnement pour l’URL RPC et dérivez-en à la fois la connexion du portefeuille et le lien vers l’explorateur : ils ne pourront jamais diverger. Enfin, quand vous signalez un bug devnet, indiquez le cluster, la signature et le niveau de commitment attendu.
Pour finir, considérez le devnet comme jetable. Conservez des scripts de déploiement capables de recréer de zéro vos comptes et mints de test, car les deux clusters de test peuvent être réinitialisés et les limites du faucet rendent un gros réapprovisionnement lent. Quand tout fonctionne, les mêmes réflexes s’appliquent tels quels au mainnet ; vous retirez simplement le paramètre ?cluster=.
Par l’équipe de recherche SolscannerMis à jour le · Méthodologie d’évaluation