Explorateur de programmes Solana : contrôlez un smart contract avant de lui faire confiance

Un explorateur de programmes Solana, c’est l’endroit où l’on contrôle un smart contract avant de signer quoi que ce soit qui le touche. La page d’un programme indique si le code est exécutable, quel loader le détient, si une autorité de mise à jour peut encore le remplacer, si le code source dispose d’un build vérifié et, pour les programmes Anchor, s’il existe un IDL qui décode chaque instruction. Ce guide passe en revue chaque champ sur un exemple réel, le programme pump.fun, et se termine par une liste de contrôle de sécurité que vous pouvez dérouler en deux minutes sur Solana Explorer, Solscan ou Orb.

Qu’est-ce qu’un compte de programme sur Solana ?

Un compte de programme est un compte on-chain marqué comme exécutable, qui contient du code compilé ou pointe vers lui. Sur Solana, « programme » désigne ce que les autres blockchains appellent un smart contract.

Les programmes Solana sont sans état (stateless). Ils ne conservent ni soldes ni données utilisateur en eux-mêmes : ces données vivent dans des comptes séparés que le programme possède. Quand vous appelez un programme, votre transaction lui transmet les comptes dont il a besoin, et le programme les lit et les modifie. C’est pour cela qu’une page d’explorateur de programme ne ressemble pas à une page de portefeuille : ce qui compte ici n’est pas un solde, mais qui peut modifier le code et ce que fait ce code.

La plupart des programmes actuels sont déployés avec le BPF Upgradeable Loader (BPFLoaderUpgradeab1e11111111111111111111111). Avec ce loader, le compte du programme lui-même est minuscule. Pour le programme pump.fun 6EF8rrecthR5Dkzon8Nwu78hRvfCKubJ14M5uBEwF6P, un appel brut getAccountInfo renvoie seulement 36 octets de données, executable: true, un propriétaire égal au loader modifiable et un seul champ analysé : programData. Le code se trouve ailleurs. Si la notion de compte est nouvelle pour vous, la documentation officielle sur les comptes reste la meilleure introduction.

Compte de données et autorité de mise à jour : l’essentiel

Le compte de données du programme (program data account) stocke le bytecode réel et deux métadonnées : le slot du dernier déploiement et l’autorité de mise à jour. Cette autorité est le champ le plus important de toute page d’explorateur de smart contract.

Dans l’exemple de pump.fun, le champ programData pointe vers B5MvUwXdiW1NMM6QFFD3ssPKBujD4zMohncbM73Z2BQu. Lorsque nous avons interrogé ce compte le 23 septembre 2026, il indiquait comme autorité de mise à jour 7gZufwwAo17y5kg8FMyJy2phgpvv9RSdzWtdXiWHjFr8. Concrètement : celui qui contrôle cette clé peut déployer un nouveau code pump.fun. C’est normal pour un protocole en développement actif, mais cela signifie que vous faites confiance à l’équipe, pas seulement au code.

Chaque explorateur présente ces données à sa façon. Solana Explorer affiche l’adresse des données du programme, l’autorité de mise à jour et le dernier slot de déploiement dans la vue d’ensemble. Solscan et Orb montrent les mêmes informations, avec des étiquettes lorsqu’ils connaissent l’adresse. Vous pouvez reproduire la vérification avec n’importe quel client RPC, ou coller l’adresse du programme dans notre outil de recherche pour voir le compte brut.

Ce qu’il faut regarder :

• Un seul portefeuille comme autorité. Une seule clé compromise suffirait à remplacer le programme. Risque plus élevé.
• Un multisig ou un compte de gouvernance. Toute modification exige plusieurs signataires ou un vote. Risque plus faible, et configuration courante pour les grands protocoles.
• Aucune autorité. Le programme est immuable. Voir la section suivante.

Programmes immuables : quand le code ne peut plus changer

Un programme immuable est un programme dont l’autorité de mise à jour a été supprimée. Personne, pas même le développeur d’origine, ne peut plus modifier son code.

L’immuabilité est une garantie forte, mais elle a un revers. Un bug dans un programme immuable ne peut pas être corrigé : l’équipe doit déployer un nouveau programme et demander aux utilisateurs de migrer. C’est pourquoi beaucoup d’équipes préfèrent garder une autorité de mise à jour derrière un multisig plutôt que de la « brûler ». Quand un explorateur affiche « Upgradeable: No » ou une autorité vide, vous savez que le bytecode que vous lisez aujourd’hui sera celui avec lequel vous interagirez demain. Un build vérifié prend alors tout son sens.

Builds vérifiés : solana-verify et l’API d’OtterSec

Un build vérifié prouve que le bytecode déployé on-chain a été compilé à partir d’un dépôt public et d’un commit précis. C’est l’équivalent Solana du « code source vérifié » des explorateurs Ethereum.

La procédure, décrite dans le guide officiel des builds vérifiés, repose sur la CLI open source solana-verify d’OtterSec :

1. solana-verify build compile le programme de façon déterministe dans une image Docker, pour que tout le monde obtienne le même hash.
2. solana-verify verify-from-repo recompile à partir du dépôt et compare le résultat au hash du programme on-chain.
3. Le développeur publie les données de vérification dans un PDA on-chain signé par l’autorité de mise à jour, puis lance solana-verify remote submit-job pour que l’API d’OtterSec, sur verify.osec.io, le confirme publiquement.

Solana Explorer interroge l’API d’OtterSec et affiche un onglet de build vérifié avec le lien vers le dépôt et le commit. Orb signale aussi les programmes vérifiés, et Solscan documente des programmes « Anchor-verified ». Quand nous avons testé le programme pump.fun sur l’endpoint de statut d’OtterSec le 23 septembre 2026, la réponse était is_verified: false. Cela ne veut pas dire que le programme est malveillant ; cela veut dire que l’explorateur seul ne vous permet pas de confirmer que le code déployé correspond à un source public.

La documentation de Solana est très claire sur ce point : un build vérifié ne doit pas être considéré comme plus sûr qu’un build non vérifié. Il supprime une incertitude, l’écart entre le source et le bytecode, et laisse les audits et le contrôle de l’autorité comme des questions distinctes.

L’onglet IDL des programmes Anchor

L’onglet IDL présente l’interface d’un programme : ses instructions, leurs arguments, les comptes attendus par chacune et les types de données personnalisés. Pour les programmes Anchor, les explorateurs peuvent lire un IDL publié on-chain et s’en servir pour décoder les transactions.

Anchor est le framework le plus utilisé pour écrire des programmes Solana, et il peut publier l’IDL du programme dans un compte on-chain dérivé de l’adresse du programme. Solana Explorer le détecte, affiche un onglet IDL et décode comptes et instructions Anchor en champs nommés. Orb affiche également les IDL des programmes vérifiés. Sans IDL, une instruction apparaît comme un bloc hexadécimal ou base58, et c’est à vous de deviner ce que signifie 0x66063d12....

En pratique, l’IDL transforme une « instruction inconnue » en quelque chose comme buy { amount, max_sol_cost }, avec des comptes étiquetés. C’est précieux quand vous cherchez à comprendre ce qu’une demande de signature de votre portefeuille s’apprête à faire. Gardez à l’esprit que l’IDL est téléversé par le développeur. Il décrit l’interface prévue, mais ce n’est pas une preuve de sécurité, et un développeur malveillant pourrait en publier un trompeur. Certaines équipes, dont pump.fun, documentent aussi leurs instructions et la structure de leurs comptes dans un dépôt GitHub public, comme la documentation publique de pump.fun.

Lire les logs d’un programme dans une transaction

Les logs d’un programme sont les messages qu’il écrit pendant son exécution, et ils constituent le moyen le plus rapide de comprendre pourquoi une transaction a échoué. Tous les explorateurs les affichent dans la vue transaction.

Les logs suivent toujours le même schéma. Vous verrez Program 6EF8... invoke [1] quand un programme démarre, des lignes Program log: contenant les messages du code, une ligne indiquant le nombre de compute units consommées, puis success ou failed suivi d’une erreur. Les appels imbriqués vers d’autres programmes apparaissent en invoke [2], invoke [3], ce qui vous donne l’arbre des appels. Une erreur Anchor se nomme généralement elle-même, par exemple une contrainte personnalisée non respectée, ce qui est bien plus parlant qu’un simple numéro d’erreur.

Quand une transaction échoue, lisez d’abord les dernières lignes du log. Elles pointent le plus souvent vers une limite de slippage dépassée, un compte non initialisé ou un budget de calcul épuisé ; le maximum est de 1 400 000 compute units par transaction. Notre guide de l’explorateur de transactions détaille le reste de la page transaction, et le guide de l’explorateur devnet montre comment tester les mêmes appels de programme sans risque sur un cluster de test.

Explorer un programme pas à pas : l’exemple de pump.fun

Voici la routine complète appliquée à un vrai programme. Elle prend deux minutes et fonctionne sur n’importe quel explorateur de contrats Solana.

Ouvrez 6EF8rrecthR5Dkzon8Nwu78hRvfCKubJ14M5uBEwF6P sur Solana Explorer, Solscan ou Orb. La vue d’ensemble confirme qu’il est exécutable et détenu par le BPF Upgradeable Loader. Suivez le lien vers les données du programme et notez l’autorité de mise à jour : au moment où nous écrivons, elle vaut 7gZu…jFr8, donc le code peut changer. Ouvrez aussi cette adresse ; si elle appartient à un programme multisig, plusieurs signataires sont nécessaires pour une mise à jour. Consultez l’onglet de vérification : non vérifié lors de notre dernier contrôle. Cherchez un onglet IDL et servez-vous-en, ou du dépôt de documentation publique, pour comprendre le nom des instructions. Enfin, ouvrez une transaction récente ayant appelé le programme et lisez les logs pour voir un flux buy ou sell normal.

Comparez ensuite avec un programme dont l’autorité est un multisig connu et dont le build est vérifié : vous aurez une idée nette du niveau de confiance que chacun vous demande. Pour travailler sur de gros volumes de données, par exemple récupérer toutes les signatures liées à l’adresse d’un programme, consultez notre guide des API d’explorateurs Solana.

Contrôles de sécurité avant d’interagir avec un smart contract Solana

Avant d’approuver une transaction qui appelle un programme inconnu, vérifiez cinq choses : l’adresse exacte, l’autorité de mise à jour, le statut de vérification, l’IDL ou la documentation, et l’activité récente.

• Adresse exacte. Récupérez l’identifiant du programme dans la documentation officielle ou sur GitHub, jamais dans un message privé ou sur un site inconnu, et comparez-le caractère par caractère.
• Autorité de mise à jour. Clé unique, multisig ou aucune : sachez laquelle avant de déposer une somme importante.
• Build vérifié. Un plus appréciable, qui confirme que le dépôt que vous lisez correspond au code exécuté.
• IDL et instructions. Assurez-vous que l’instruction affichée par votre portefeuille correspond à ce que vous voulez faire. Un « claim airdrop » qui déclenche un transfert vers un compte inconnu, c’est un drainer.
• Contact de sécurité. Solana Explorer affiche les données security.txt lorsqu’un programme les intègre, ce qui vous indique où signaler un problème.

Tous les explorateurs ne présentent pas ces champs avec la même clarté. Notre classement des meilleurs explorateurs Solana les note notamment sur les outils pour développeurs, et notre avis sur Orb détaille ses vues IDL et programme particulièrement lisibles.