Crypto : lire un smart contract sans être développeur

Voilà pourquoi savoir lire un smart contract devient une compétence utile en crypto, même sans être développeur.

Il ne s’agit pas d’apprendre Solidity en une soirée. Un audit complet nécessite des compétences techniques autrement plus profondes : architecture, logique métier, interactions entre contrats, sécurité de l’EVM, appels externes, manipulation du stockage, tests, attaques économiques. Lire quelques fonctions sur Etherscan ne remplace absolument pas ce travail.

L’objectif est plus modeste, et beaucoup plus accessible.

Un utilisateur ordinaire peut déjà vérifier l’adresse du contrat, voir si son code est public, identifier son propriétaire, rechercher certaines fonctions sensibles, comprendre qui peut appeler ces fonctions, repérer un système de rôles, vérifier si l’offre peut augmenter et découvrir si le code est modifiable.

Cette lecture ne répondra pas à toutes les questions.

Elle peut néanmoins en faire apparaître de très bonnes.

Et parfois, il suffit d’une seule fonction pour transformer complètement l’analyse d’un token.

Commencer par ce que le contrat permet vraiment

Un smart contract n’est pas un document juridique rempli de promesses. C’est un programme exécuté par une blockchain.

Sur Ethereum, il possède une adresse, contient des données et expose des fonctions. Certaines fonctions se contentent de lire ces données. D’autres les modifient lorsqu’une transaction valide les appelle. Ethereum décrit ainsi le contrat comme un programme vivant à une adresse précise du réseau.

Cette définition paraît technique. Elle devient beaucoup plus simple avec un exemple.

Un contrat de token peut contenir essentiellement les informations suivantes :

nom du token ;

symbole ;

offre totale ;

solde de chaque adresse ;

règles de transfert ;

permissions administratives ;

mécanismes permettant éventuellement de créer ou détruire des tokens.

Notre glossaire crypto complet permet déjà de retrouver les notions de wallet, multisig, vesting ou contrats conditionnels. Ici, il faut aller une étape plus loin : observer les règles directement là où elles sont exécutées.

Première étape : trouver la véritable adresse du contrat

Avant même de lire du code, encore faut-il analyser le bon contrat.

Le ticker ne suffit jamais.

N’importe qui peut créer un token baptisé USDT, PEPE, LINK ou reprendre le nom d’un projet qui n’a même pas encore lancé son actif. Deux tokens peuvent afficher exactement le même nom et le même symbole tout en étant contrôlés par des contrats totalement différents.

L’identifiant important est l’adresse du contrat.

Sur Ethereum, elle ressemble à une longue suite commençant par 0x.

Elle doit idéalement être récupérée depuis plusieurs sources cohérentes :

le site officiel du projet ;

sa documentation ;

un explorateur de blocs reconnu ;

éventuellement les liens publiés par l’équipe sur ses canaux officiels.

Il faut résister à un réflexe fréquent : chercher simplement le nom du token sur Google et cliquer sur le premier contrat ressemblant au bon.

Une copie peut avoir le même ticker.

Pas la même adresse.

Une fois l’adresse obtenue, on peut l’ouvrir sur Etherscan pour Ethereum, ou utiliser l’explorateur correspondant à la blockchain concernée. Le principe général reste proche sur plusieurs réseaux EVM.

« Source Code Verified » est le premier filtre

Sur Etherscan, ouvrez l’onglet Contract.

La première information importante est la vérification du code.

Lorsqu’un développeur vérifie son contrat, Etherscan compile le code source fourni et vérifie sa correspondance avec le bytecode présent sur la blockchain. Dans le cas d’une vérification exacte, le lecteur obtient alors une version humaine du programme qui correspond au contrat déployé, ainsi que son ABI et différentes informations de compilation.

C’est extrêmement important.

Sans cette vérification, la blockchain possède toujours le programme. Mais ce qui apparaît principalement au lecteur est du bytecode destiné à l’EVM, beaucoup moins pratique à analyser manuellement.

Un contrat vérifié transforme donc quelque chose ressemblant à une masse de données machines en fichiers Solidity lisibles.

Il faut cependant éviter une erreur.

Vérifié ne signifie pas audité.

Et audité ne signifie pas invulnérable.

La documentation Ethereum sur la vérification des smart contracts rappelle que la vérification sert essentiellement à établir la correspondance entre le code source et le bytecode déployé. Elle ne garantit pas que la logique est sûre.

Un développeur peut publier parfaitement le code d’un contrat comportant une fonction permettant de créer une quantité illimitée de tokens.

Le code sera vérifié.

Et le risque restera bien réel.

La vérification donne de la transparence.

Elle ne donne pas un certificat de bonne conduite.

L’onglet Read Contract est votre meilleur ami

Un non-développeur n’a même pas besoin de commencer par les fichiers Solidity.

Etherscan propose généralement deux interfaces beaucoup plus lisibles :

Read Contract

et

Write Contract.

Read Contract permet de consulter les données publiques exposées par le programme sans modifier la blockchain et sans payer de gas. Write Contract contient les fonctions capables de déclencher des transactions et donc de modifier l’état du contrat.

Commençons par Read.

Pour un ERC-20 classique, on peut retrouver des fonctions comme :

name

symbol

decimals

totalSupply

balanceOf

owner

Ces mots donnent déjà beaucoup d’informations.

name() vous donne le nom.

symbol() son ticker.

totalSupply() l’offre créée à cet instant.

balanceOf(address) permet de demander combien de tokens possède une adresse.

owner() peut révéler l’adresse disposant d’un pouvoir administratif si le contrat utilise le modèle d’ownership correspondant.

Il n’est pas nécessaire de comprendre chaque accolade de Solidity pour exploiter ces fonctions.

Etherscan transforme l’interface du smart contract en une série de champs.

C’est presque un formulaire.

Attention aux decimals

Un détail déroute souvent les débutants.

Vous ouvrez totalSupply() et voyez :

1000000000000000000000000000

Un milliard de milliards ?

Pas nécessairement.

La plupart des ERC-20 utilisent des décimales. OpenZeppelin utilise par défaut 18 décimales dans son implémentation ERC-20. L’interface du wallet divise alors les nombres entiers utilisés par le contrat par 10^18 pour afficher une quantité compréhensible.

Donc :

1 000 000 000 000 000 000

peut simplement représenter 1 token avec 18 décimales.

Avant d’interpréter une offre, vérifiez decimals().

C’est un petit détail.

Il évite de grandes absurdités.

Trouvez maintenant owner

La prochaine question est plus importante :

qui contrôle le contrat ?

Si une fonction owner() existe, cliquez dessus.

Vous obtenez généralement une adresse.

Copiez-la.

Ouvrez-la.

Est-ce un wallet personnel ?

Un autre smart contract ?

Une multisig ?

Un timelock ?

Un contrat de gouvernance ?

L’adresse seule ne suffit donc pas. Il faut remonter d’un niveau.

OpenZeppelin décrit Ownable comme l’une des formes les plus simples de contrôle d’accès : une adresse est définie comme propriétaire et les fonctions protégées par un mécanisme de type onlyOwner lui sont réservées.

Cela peut être parfaitement raisonnable.

Une équipe doit parfois pouvoir gérer certains paramètres, surtout au lancement d’un protocole.

La vraie question devient :

quels pouvoirs cet owner possède-t-il ?

Un owner capable uniquement de modifier une adresse de métadonnées ne présente pas le même risque qu’un owner capable de mint, geler, confisquer, modifier les frais et remplacer tout le code.

L’existence d’un administrateur ne suffit donc ni à condamner ni à rassurer.

Il faut lire ses pouvoirs.

Faites Ctrl+F : onlyOwner

Nous arrivons à la partie étonnamment simple.

Dans l’onglet Code, utilisez la recherche de votre navigateur.

Tapez :

onlyOwner

Vous trouverez les fonctions réservées au propriétaire dans les contrats utilisant cette convention.

Exemple fictif :

function setFee(uint256 newFee) external onlyOwner

Même sans savoir coder, la phrase devient presque lisible.

function setFee

une fonction permet de modifier les frais.

newFee

elle reçoit le nouveau niveau de frais.

external

elle peut être appelée depuis l’extérieur du contrat.

onlyOwner

seul le propriétaire peut l’utiliser.

Vous venez de lire une partie d’un smart contract.

Pas besoin de comprendre comment fonctionne l’EVM.

Il faut maintenant poser la bonne question : y a-t-il une limite au nouveau niveau de frais ?

Par exemple :

require(newFee <= 5)

peut indiquer une limite à 5, selon la manière dont le pourcentage est représenté.

Sans limite visible, la fonction pourrait permettre des valeurs beaucoup plus grandes, selon le reste de la logique.

Ne concluez pas immédiatement.

Suivez la variable.

onlyOwner n’est pas le seul système de permission

Les projets plus complexes utilisent souvent des rôles.

Faites aussi des recherches comme :

hasRole

onlyRole

DEFAULT_ADMIN_ROLE

MINTER_ROLE

PAUSER_ROLE

UPGRADER_ROLE

Les noms varient.

OpenZeppelin propose justement un contrôle d’accès basé sur des rôles afin que différents comptes puissent disposer de responsabilités différentes : création de tokens, pause, administration et autres opérations.

C’est souvent préférable à une seule clé contrôlant absolument tout.

Encore faut-il regarder qui détient ces rôles.

Un projet peut annoncer :

« Ownership renounced ».

Très impressionnant.

Puis laisser un DEFAULT_ADMIN_ROLE capable d’accorder MINTER_ROLE à une nouvelle adresse.

La renonciation à owner ne répond alors pas à la vraie question.

Le véritable pouvoir se trouve ailleurs.

Ne recherchez donc jamais seulement le propriétaire. Recherchez toutes les permissions.

mint : peut-on créer de nouveaux tokens ?

Pour un token, l’une des recherches les plus évidentes est :

mint

La fonction mint crée généralement de nouvelles unités.

Ethereum utilise d’ailleurs cet exemple dans sa documentation pédagogique : une fonction mint peut augmenter le solde d’un destinataire, avec un contrôle limitant son utilisation au propriétaire.

La présence d’une fonction de mint n’est pas automatiquement inquiétante.

USDC, stablecoins, systèmes de récompenses, staking, blockchains avec émission programmée : de nombreux modèles légitimes nécessitent la création de nouveaux tokens.

La question est plutôt :

qui peut mint ?

Combien ?

Selon quelles règles ?

Existe-t-il une offre maximale ?

Le mint est-il utilisé par un mécanisme automatique ou par un administrateur ?

Un projet vous annonce une supply maximale de 100 millions de tokens.

Le contrat contient :

mint(address to, uint256 amount) onlyOwner

et aucune limite claire.

Vous avez une question à poser.

La supply marketing est-elle réellement plafonnée au niveau du contrat ?

Si oui, où ?

Un plafond peut être défini ailleurs, dans une extension ERC20Capped, une variable MAX_SUPPLY ou une condition.

Ne vous arrêtez donc pas au mot mint.

Cherchez la contrainte.

burn n’est pas toujours aussi bullish que le marketing le prétend

burn détruit des tokens.

Le terme plaît énormément aux investisseurs parce qu’il évoque une offre décroissante.

Mais là encore, il faut regarder qui peut brûler quoi.

Un utilisateur peut-il simplement brûler ses propres tokens ?

L’administrateur peut-il brûler ceux d’une autre adresse ?

Le protocole rachète-t-il réellement des tokens avant de les brûler ?

Ou ne fait-il que détruire une partie de tokens nouvellement émis ?

Une économie qui crée 100 millions de nouveaux tokens puis en brûle 20 millions reste inflationniste de 80 millions.

La fonction est intéressante.

Le bilan d’offre l’est davantage.

pause : bouton d’urgence ou pouvoir central ?

Recherchez :

pause

unpause

paused

OpenZeppelin propose officiellement un mécanisme ERC20Pausable permettant de suspendre transferts, mint et burn lorsque le contrat l’intègre et que les fonctions correspondantes sont correctement reliées à un contrôle d’accès. L’idée peut servir de bouton d’urgence lorsqu’une faille majeure est découverte.

Voilà un exemple parfait où une fonction paraît à la fois rassurante et inquiétante.

Rassurante :

un exploit commence, l’équipe peut éventuellement stopper le système.

Inquiétante :

quelqu’un possède le pouvoir de stopper le système.

La bonne analyse n’est donc pas :

« pause = scam ».

Elle est :

qui peut déclencher la pause ?

Une seule clé ?

Une multisig ?

Un mécanisme de gouvernance ?

Existe-t-il un timelock ?

Que se passe-t-il précisément pendant la pause ?

Tous les transferts ?

Seulement certaines opérations ?

C’est la différence entre identifier une fonction et comprendre un risque.

blacklist, blocklist et freeze

Recherchez ensuite différents termes :

blacklist

blocklist

freeze

frozen

isBlocked

denylist

Ils peuvent révéler une capacité de bloquer certaines adresses.

Là encore, cela ne prouve pas un comportement malveillant.

Certains stablecoins centralisés intègrent volontairement des mécanismes de conformité permettant de geler des adresses liées à des sanctions ou à des fonds volés.

Mais si vous pensiez acheter un actif totalement censorship-resistant, cette fonction change votre analyse.

Le code ne dit pas nécessairement :

« ceci est mauvais ».

Il dit :

« voici le pouvoir qui existe ».

À vous de décider s’il correspond à la promesse du projet.

Cherchez les fonctions qui modifient les frais

Certains tokens prélèvent une taxe sur les transferts.

Recherchez :

fee

tax

setFee

setTax

buyTax

sellTax

marketingFee

liquidityFee

setFees

Vous pouvez parfois découvrir que le contrat distingue achat et vente.

Par exemple, une taxe de 2 % peut financer la trésorerie.

Rien d’extraordinaire.

Le problème apparaît lorsque l’administrateur peut changer cette taxe sans plafond raisonnable.

Un token peut alors fonctionner normalement aujourd’hui et devenir pratiquement impossible à vendre demain si une taxe extrêmement élevée peut être appliquée.

Cette technique apparaît dans certains honeypots ou tokens malveillants.

La simple existence d’une fonction setTax n’est pas la preuve d’un honeypot.

L’absence de limite mérite cependant d’être comprise avant d’acheter.

Les limites de transaction peuvent également piéger

Cherchez :

maxTx

maxTransaction

maxWallet

tradingEnabled

enableTrading

limits

cooldown

Ces fonctions servent parfois à protéger un lancement contre les bots ou à empêcher une trop grande concentration des tokens.

Elles peuvent aussi donner à l’administrateur un contrôle énorme sur les échanges.

Un projet peut, par exemple, définir la taille maximale d’une vente.

Il faut regarder si cette taille peut être réduite arbitrairement.

Même logique avec tradingEnabled.

Si l’owner décide quand les transferts deviennent libres, cela peut être logique avant le lancement.

Après le lancement, la question change :

peut-il les désactiver de nouveau ?

excludeFromFee mérite un détour

Une taxe s’applique à tous les investisseurs.

Sauf certaines adresses.

Pourquoi ?

C’est parfois parfaitement normal : routeur, contrat de liquidité, trésorerie ou autres composants techniques peuvent nécessiter un traitement spécifique.

Mais une whitelist de wallets privilégiés peut également créer un avantage important.

Recherchez :

excludedFromFees

isExcludedFromFee

whitelist

isWhitelisted

Puis cherchez comment cette liste peut être modifiée.

Qui ajoute une adresse ?

Qui la retire ?

Que permet le statut ?

L’analyse d’un smart contract fonctionne souvent comme une enquête : un mot mène vers une fonction, qui mène vers une adresse, qui mène vers un autre contrat.

Vous ne lisez pas tout.

Vous suivez le pouvoir.

Les vraies alertes se cachent dans les permissions

À ce stade, vous savez déjà lire beaucoup plus qu’un prix sur CoinMarketCap.

Reste néanmoins le cœur du problème : les smart contracts modernes fonctionnent rarement seuls.

Ils héritent de bibliothèques.

Appellent d’autres contrats.

Délèguent certaines fonctions.

Sont parfois contrôlés par plusieurs administrateurs.

Ou peuvent être remplacés par une nouvelle version.

C’est ici que la lecture devient réellement intéressante.

Le owner peut être une multisig

Vous cliquez sur owner().

L’adresse obtenue n’est pas un wallet classique mais un smart contract.

Ce n’est pas nécessairement plus compliqué.

Ce contrat peut être une multisig.

Une multisignature exige plusieurs clés pour valider une opération sensible.

C’est un élément important car le risque change énormément.

Une seule clé administrateur compromise :

une personne peut potentiellement agir.

Multisig 3-sur-5 :

un attaquant doit généralement compromettre suffisamment de signataires pour atteindre le seuil.

Ce n’est pas une garantie absolue. Les signataires peuvent être contrôlés par la même organisation. Les appareils peuvent être mal sécurisés. Un seuil peut être trop bas compte tenu du capital administré.

Bref Crypto a récemment illustré ce sujet avec l’analyse des pouvoirs administratifs de l’USDT sur Tron. Le sujet ne concernait pas une clé donnant directement accès aux USDT détenus dans tous les wallets. Il concernait le contrôle administratif du contrat lui-même.

Voilà exactement le type de nuance qu’une lecture du smart contract permet d’obtenir.

Un timelock peut changer complètement le risque

Imaginez maintenant que l’administrateur puisse changer une fonction.

Très bien.

Peut-il la changer immédiatement ?

Ou l’opération doit-elle attendre 24 heures, 48 heures ou une semaine ?

Un timelock impose un délai entre la programmation d’une opération administrative et son exécution.

Pour l’utilisateur, la différence est énorme.

Une clé administrateur sans délai peut modifier certains paramètres presque instantanément.

Avec un timelock public, les observateurs peuvent parfois voir la modification prévue avant son activation.

Ils disposent alors d’un délai pour réagir.

Cherchez :

TimelockController

delay

minDelay

getMinDelay

schedule

execute

Si le contrat utilise un système de gouvernance, cherchez également qui peut proposer l’opération et qui peut l’exécuter.

Une architecture décentralisée n’est pas seulement une question de nombre de wallets.

C’est une question de pouvoir et de délai.

« Ownership renounced » peut être presque vide de sens

Cette phrase apparaît régulièrement dans le marketing des tokens :

Ownership renounced.

Elle signifie généralement que le propriétaire a transféré son rôle vers une adresse inutilisable ou utilisé renounceOwnership().

Très bien.

Mais avant de célébrer, posez cinq autres questions.

Existe-t-il un AccessControl distinct ?

Un admin de proxy ?

Un rôle de minter ?

Un rôle d’upgrade ?

Une autre fonction privilégiée ?

La propriété d’un contrat n’est qu’un système de permission parmi d’autres.

Une équipe pourrait techniquement renoncer au rôle owner d’une partie du système tout en contrôlant un autre contrat capable de modifier le comportement effectif du protocole.

C’est pourquoi la recherche doit porter sur l’ensemble du chemin de contrôle.

Le mot « renounced » est un point de départ.

Pas une conclusion.

Regardez les imports

Le haut du fichier Solidity contient souvent des lignes comme :

import "@openzeppelin/contracts/token/ERC20/ERC20.sol";

ou :

import "@openzeppelin/contracts/access/Ownable.sol";

Même sans comprendre Solidity, ces imports fournissent des indices.

Le contrat réutilise des composants externes.

Ethereum encourage justement l’utilisation de bibliothèques reconnues plutôt que la réécriture permanente des mêmes mécanismes, notamment pour des comportements standards comme l’administration ou la pause d’urgence.

OpenZeppelin est extrêmement répandu.

Voir une bibliothèque connue est généralement plus rassurant qu’une implémentation entièrement artisanale d’une fonctionnalité standard.

Mais encore une fois :

utiliser OpenZeppelin ne rend pas automatiquement le contrat sûr.

Un développeur peut prendre un excellent composant ERC-20 et ajouter ensuite une fonction dangereuse.

Lisez donc surtout ce que le projet ajoute ou surcharge.

public, external, private, internal

Quelques mots Solidity suffisent pour mieux lire les fonctions.

public

la fonction peut notamment être appelée depuis l’extérieur.

external

elle fait partie de l’interface callable depuis l’extérieur.

private

elle n’est accessible qu’à l’intérieur du contrat où elle est définie.

internal

elle peut être utilisée par ce contrat et certains contrats qui en héritent.

Ethereum explique précisément ces différentes visibilités dans sa documentation.

Attention à un piège important :

public ne signifie pas nécessairement que tout le monde peut réussir à exécuter la fonction.

Une fonction peut être publique et comporter :

onlyOwner

ou une condition :

require(msg.sender == admin)

La visibilité vous indique comment la fonction peut être appelée.

Le contrôle d’accès vous indique qui est autorisé.

Les deux informations doivent être lues ensemble.

view et pure sont généralement moins inquiétants

Une fonction marquée view promet de ne pas modifier l’état du contrat.

Une fonction pure ne doit pas lire ni modifier l’état.

Pour une première analyse, elles sont généralement moins prioritaires que les fonctions capables d’écrire dans le contrat.

Ethereum cite par exemple balanceOf() comme fonction view typique : elle consulte un solde.

À l’inverse, une fonction capable de modifier un paramètre, transférer un actif, créer des tokens ou changer une permission mérite davantage votre attention.

Ce n’est pas une règle absolue de sécurité.

C’est une méthode de tri.

Vous ne savez pas coder ?

Commencez par regarder qui peut changer quelque chose.

payable signifie que la fonction peut recevoir de l’ETH

Autre mot utile :

payable.

Une fonction payable peut recevoir de l’ETH avec son appel.

Ce n’est pas dangereux par définition.

Un mint NFT payable, une vente de tokens ou certains protocoles DeFi en ont besoin.

Mais si vous êtes en train d’étudier une fonction à laquelle l’utilisateur doit envoyer des fonds, comprenez ce qu’elle fait avant de signer.

Les interfaces Web3 rendent parfois l’expérience tellement fluide qu’on oublie qu’un clic constitue une transaction adressée à un programme.

Comprendre approve avant de regarder le code exotique

Parfois, le risque le plus important ne vient même pas d’une fonction bizarre.

Il vient d’un standard.

Avec ERC-20, approve(spender, amount) permet à une autre adresse ou à un smart contract de dépenser une certaine quantité de vos tokens via le mécanisme d’allowance.

C’est indispensable à une grande partie de la DeFi.

Un DEX doit par exemple pouvoir transférer les tokens nécessaires au swap.

Mais une approbation extrêmement large donnée au mauvais contrat peut exposer les fonds concernés.

Voilà pourquoi une transaction approve ne doit pas être interprétée comme :

« je confirme juste quelque chose ».

Vous accordez une permission.

Regardez :

quel token ?

quel spender ?

quel montant ?

Une approval illimitée peut rester valide longtemps après l’interaction initiale.

Ici encore, savoir lire les mots suffit déjà à améliorer considérablement la sécurité.

Méfiez-vous d’une fonction dont le nom rassure trop

Les noms des fonctions sont choisis par les développeurs.

Une fonction baptisée :

safeTransfer

n’est pas automatiquement sûre.

Une fonction :

protectUsers

ne protège pas nécessairement les utilisateurs.

Une fonction :

renounceOwnership

peut avoir été modifiée dans un contrat personnalisé.

Il faut regarder ce qu’elle exécute réellement.

C’est particulièrement important dans les scams volontairement obscurcis.

Le développeur peut choisir des noms innocents.

Le code exécuté compte plus que le nom.

Le contrat principal peut importer la vraie logique ailleurs

Vous ouvrez un token.

Le fichier principal comporte 50 lignes.

Formidable.

Sauf qu’il hérite de cinq autres contrats.

La logique se trouve ailleurs.

Cherchez la déclaration :

contract MyToken is ERC20, Ownable, Pausable...

Le mot is indique ici l’héritage.

Une partie du comportement provient donc des contrats cités.

Etherscan présente généralement les différents fichiers d’un contrat vérifié. Vous pouvez passer de l’un à l’autre.

Un non-développeur ne doit pas forcément lire les milliers de lignes d’OpenZeppelin.

L’intérêt est surtout d’identifier :

quelle partie est standard ;

quelle partie est spécifique au projet.

La logique personnalisée mérite souvent le plus d’attention.

Les événements racontent aussi l’histoire

Les smart contracts peuvent émettre des événements enregistrés dans les logs.

Ethereum explique que ces événements permettent notamment aux interfaces et applications de suivre les changements produits par le contrat.

Pour l’utilisateur, cela devient utile lorsque l’on veut vérifier si un pouvoir a réellement été utilisé.

Cherchez des événements comme :

OwnershipTransferred

RoleGranted

RoleRevoked

Paused

Unpaused

Upgraded

Les noms varient selon les contrats.

Vous pouvez alors dépasser la question :

« l’administrateur peut-il faire cela ? »

et demander :

« l’a-t-il déjà fait ? »

Un contrat peut théoriquement posséder une fonction d’urgence jamais utilisée.

Un autre peut changer régulièrement de paramètres.

L’historique on-chain apporte le contexte.

Les transactions de l’administrateur sont parfois plus parlantes que sa promesse

Lorsque vous avez identifié l’owner ou le multisig, ouvrez son adresse.

Regardez ses transactions.

Quel type d’opérations effectue-t-elle ?

Des modifications de frais ?

Des mint ?

Des transferts de propriété ?

Des upgrades ?

Des mouvements réguliers de trésorerie ?

L’analyse d’un smart contract ne se limite donc pas à lire du code statique.

La blockchain montre aussi comment ce pouvoir a été utilisé.

C’est l’avantage considérable du système.

Une documentation peut être réécrite.

Une transaction confirmée reste dans l’historique.

Comparez les pouvoirs avec la communication du projet

C’est ici que la lecture devient journalistiquement intéressante.

Le contrat est-il cohérent avec le récit ?

Le projet dit :

« offre fixe ».

Le contrat permet-il un mint supplémentaire ?

« Entièrement décentralisé ».

Qui détient les permissions critiques ?

« Impossible de bloquer les utilisateurs ».

Existe-t-il une blocklist ?

« Contrat immutable ».

Existe-t-il un mécanisme d’upgrade ?

« Communauté souveraine ».

Une multisig de l’équipe possède-t-elle encore un pouvoir de veto ?

Il ne faut pas nécessairement crier au mensonge à la première différence.

Une architecture complexe peut avoir de bonnes raisons techniques.

Mais la contradiction mérite une explication.

C’est là que le smart contract devient beaucoup plus qu’un fichier technique.

Il devient un outil permettant de vérifier les promesses.

Un smart contract peut aussi dépendre de données extérieures

Le code on-chain ne sait pas spontanément quel est le prix du pétrole, le résultat d’un match ou le PIB américain.

Il peut avoir besoin d’un oracle.

Bref Crypto a récemment montré comment Chainlink distribue désormais certaines données économiques américaines à des smart contracts. Le contrat peut alors agir en fonction d’une donnée venant du monde extérieur.

Cela crée une nouvelle question :

d’où vient l’information ?

Si vous analysez une plateforme de lending, le prix du collatéral peut dépendre d’un oracle.

Un oracle défaillant peut provoquer de mauvaises liquidations même lorsque la logique du smart contract fonctionne exactement comme prévu.

« Le code fonctionne » n’est donc pas toujours égal à « le système fonctionne ».

Les dépendances comptent.

Le proxy est le piège que tout débutant doit connaître

Vous avez trouvé l’adresse.

Le code est vérifié.

L’owner semble correct.

Aucune fonction de mint dangereuse.

Vous pensez avoir terminé.

Puis un petit message apparaît sur Etherscan :

Proxy.

À cet instant, votre analyse change.

Un proxy sépare généralement l’adresse utilisée par les utilisateurs de la logique qui exécute réellement le programme.

Pour simplifier : vous interagissez avec une même porte, mais la pièce située derrière cette porte peut être remplacée.

Pourquoi les développeurs utilisent des proxys

Un smart contract classique déployé sur Ethereum n’est pas modifiable comme une application Web2 ordinaire.

Si une erreur apparaît, il n’existe pas simplement un bouton « remplacer le fichier sur le serveur ».

L’upgradeabilité répond à ce problème.

Avec un proxy, les utilisateurs continuent à interagir avec une adresse stable tandis que les appels sont délégués à un contrat d’implémentation contenant la logique.

Lors d’une mise à niveau, l’implémentation peut changer.

Les données peuvent rester au niveau du proxy.

OpenZeppelin documente notamment les modèles Transparent et UUPS, deux architectures courantes d’upgradeabilité. Dans un proxy transparent, l’administration du proxy gère les upgrades ; dans UUPS, la logique d’upgrade se trouve principalement dans l’implémentation et doit être protégée par un mécanisme d’autorisation.

Pour les développeurs, cela apporte beaucoup de flexibilité.

Pour l’investisseur, cela introduit une question gigantesque :

qui peut changer le code ?

Un contrat audité aujourd’hui peut être différent demain

Imaginez :

Version 1 auditée.

Aucun mint illimité.

Pas de frais abusifs.

Très bien.

Le proxy possède cependant un administrateur capable de remplacer l’implémentation.

Deux mois plus tard, il passe à Version 2.

La nouvelle logique peut être différente.

L’audit du premier contrat ne suffit plus nécessairement.

C’est pourquoi OpenZeppelin décrit un déploiement upgradeable comme comportant au minimum une logique de proxy et une implémentation, avec des mécanismes permettant au proxy de pointer vers une nouvelle implémentation lors d’un upgrade.

Ce n’est pas un défaut automatique.

DeFi utilise largement l’upgradeabilité parce que corriger des bugs et faire évoluer un protocole peut être indispensable.

Mais un protocole upgradeable et un protocole immutable n’ont pas exactement le même modèle de confiance.

Etherscan vous aide avec « Read as Proxy »

Heureusement, les explorateurs modernes détectent souvent les proxys.

Etherscan indique que des onglets supplémentaires liés au proxy peuvent apparaître dans la section Contract. Son interface distingue également le code, les fonctions de lecture et les fonctions d’écriture.

Vous pouvez alors voir des options du type :

Read as Proxy

Write as Proxy

et l’adresse de l’implémentation.

Pour un débutant, la règle devient simple :

si Etherscan indique Proxy, ne lisez pas uniquement le petit contrat proxy. Trouvez aussi l’implémentation.

C’est là que réside généralement la logique métier.

Cherchez upgradeTo et upgradeToAndCall

Dans un système upgradeable, les noms suivants méritent votre attention :

upgradeTo

upgradeToAndCall

_authorizeUpgrade

implementation

ProxyAdmin

admin

OpenZeppelin utilise notamment upgradeToAndCall dans ses mécanismes actuels d’upgrade de proxy et explique que les proxies transparents s’appuient sur un ProxyAdmin, tandis que les UUPS font reposer l’autorisation sur la logique de l’implémentation.

Encore une fois, la fonction n’est pas le problème.

Le pouvoir est le problème.

Qui peut appeler l’upgrade ?

Une adresse personnelle ?

Une multisig 2-sur-3 ?

Une multisig 5-sur-8 ?

Une gouvernance ?

Un timelock de sept jours ?

Ces architectures possèdent des profils de risque profondément différents.

Le proxy peut même cacher plusieurs niveaux

Un protocole complexe peut utiliser :

proxy → implémentation → autre contrat → oracle → bridge → multisig.

Bienvenue dans la DeFi.

C’est précisément le moment où il faut connaître ses limites.

Un particulier peut raisonnablement effectuer une analyse de premier niveau.

Il n’a pas besoin de prétendre réaliser un audit professionnel de cinquante contrats imbriqués.

Lorsque l’architecture devient trop complexe, la bonne réaction n’est pas forcément :

« je dois tout comprendre ».

Elle peut être :

« ce système dépasse mon niveau d’analyse personnel ; je vais regarder les audits, bug bounties, documentation technique et évaluations indépendantes ».

Reconnaître cette limite est une compétence.

Un audit réduit un risque, il ne le supprime pas

Cherchez les audits.

Mais lisez au minimum :

qui les a réalisés ;

quand ;

sur quelle version ;

quels fichiers étaient inclus ;

quels problèmes ont été trouvés ;

quels problèmes restent ouverts ;

si le contrat a été modifié depuis.

Un badge « Audited by X » placé sur le site ne suffit pas.

Le rapport compte.

Un audit vieux de deux ans sur Version 1 ne couvre pas automatiquement Version 4.

Un protocole peut également être techniquement sécurisé et économiquement vulnérable.

Un contrat de lending peut fonctionner exactement comme prévu tout en utilisant un oracle manipulable.

Une pool peut respecter son code et perdre énormément d’argent à cause d’une mauvaise conception économique.

Le smart contract n’est qu’une partie du système.

Vérification exacte, Similar Match : ne mélangez pas

Etherscan distingue plusieurs niveaux de vérification.

Un Exact Match correspond au code et aux informations de déploiement vérifiés précisément.

Un Similar Match repose sur une correspondance avec un bytecode similaire déjà vérifié et comporte davantage de limites, notamment sur certains paramètres de déploiement.

Etherscan prévient par exemple que des arguments de constructeur différents peuvent modifier le comportement réel.

Pour une analyse sérieuse, regardez donc le type de vérification.

Le badge coloré n’est pas un détail décoratif.

Le constructeur raconte comment le contrat a commencé

Recherchez :

constructor

Cette fonction est exécutée une seule fois lors du déploiement classique d’un contrat. Elle sert souvent à définir les paramètres initiaux : propriétaire, supply initiale ou différentes adresses. Ethereum utilise justement l’exemple d’un constructeur attribuant owner = msg.sender.

Pourquoi est-ce intéressant ?

Parce qu’une fonction de mint peut avoir disparu après le lancement alors que toute la supply a été créée dans le constructeur.

Ou le contrat peut avoir attribué dès le départ des rôles importants à certaines adresses.

Dans les proxys upgradeables, la situation est plus particulière : les implémentations utilisent généralement une fonction d’initialisation plutôt qu’un constructeur classique pour initialiser l’état du proxy.

Cherchez alors :

initialize

initializer

reinitializer

Une mauvaise initialisation peut même constituer une vulnérabilité importante dans certains systèmes upgradeables.

Pour le débutant, retenez surtout ceci :

constructor ou initialize = comment le pouvoir initial a été distribué.

delegatecall mérite une attention particulière

Si vous voyez :

delegatecall

vous êtes probablement dans une zone plus technique.

Le mécanisme permet essentiellement d’exécuter le code d’un autre contrat tout en utilisant le contexte de stockage du contrat appelant. Les proxys reposent justement sur ce principe.

Pour un non-développeur, inutile d’essayer immédiatement de comprendre tous les détails EVM.

Il faut plutôt demander :

vers quelle adresse l’appel est-il délégué ?

Cette adresse peut-elle changer ?

Qui contrôle ce changement ?

Voilà les questions économiques derrière le mot technique.

selfdestruct n’a plus la même portée qu’autrefois

Les anciens guides de sécurité recommandaient souvent de chercher selfdestruct comme un énorme drapeau rouge permettant de détruire un contrat.

La situation a évolué avec les changements du protocole Ethereum : le comportement de l’opcode a été fortement modifié par les mises à niveau récentes. Il ne faut donc pas appliquer mécaniquement de vieilles règles sans tenir compte de la version et du réseau concernés.

Ethereum continue néanmoins de classer l’utilisation de selfdestruct parmi les opérations modifiant l’état lorsqu’il explique les restrictions des fonctions view.

C’est un bon rappel plus général :

un guide de smart contracts datant de 2020 peut être techniquement dépassé en 2026.

Ne cliquez pas sur Write Contract pour « tester »

L’onglet Write Contract est très utile.

Il peut aussi provoquer une vraie transaction.

Etherscan explique clairement que les opérations de lecture ne changent pas la blockchain, alors que Write Contract peut soumettre une transaction nécessitant une signature du wallet et des frais de gas.

Donc :

lisez librement Read Contract.

Soyez beaucoup plus prudent avec Write Contract.

Ne connectez pas un wallet contenant vos fonds principaux juste pour explorer.

Ne testez pas une fonction que vous ne comprenez pas.

Ne signez pas pour voir « ce que ça fait ».

Sur blockchain, la curiosité peut être irréversible.

L’ABI permet même de comprendre un contrat sans lire tout le code

L’ABI, ou Application Binary Interface, décrit essentiellement comment communiquer avec les fonctions publiques du contrat : leurs noms, paramètres, types de données et valeurs retournées.

Etherscan souligne justement qu’il est possible de comprendre une partie importante des interactions d’un contrat en lisant l’ABI, sans analyser chaque ligne du code source.

C’est exactement l’approche adaptée à notre objectif.

Vous n’avez pas besoin de savoir écrire :

function transfer(address _to, uint256 _value)

pour comprendre que :

transfer

déplace des tokens,

_to

est l’adresse destinataire,

_value

est la quantité.

L’interface vous traduit déjà une grande partie du langage.

Une méthode de 15 minutes suffit pour le premier filtre

Prenons maintenant un token inconnu.

Vous avez quinze minutes.

Voici l’ordre que j’utiliserais.

Minute 1 : l’adresse.

Vérifiez que le contrat correspond bien au token officiel.

Minute 2 : la vérification.

Code vérifié ? Exact Match ? Proxy ?

Minutes 3 à 5 : Read Contract.

Regardez :

owner

totalSupply

decimals

et les fonctions administratives visibles.

Minutes 6 à 8 : recherche dans le code.

Ctrl+F :

onlyOwner

onlyRole

mint

pause

blacklist

fee

tax

maxTx

upgrade

Minutes 9 et 10 : les permissions.

Qui détient les rôles ?

Wallet simple ?

Multisig ?

Timelock ?

Gouvernance ?

Minutes 11 et 12 : proxy.

Le contrat est-il upgradeable ?

Quelle est l’implémentation ?

Qui peut la changer ?

Minutes 13 et 14 : historique.

L’administrateur a-t-il déjà utilisé ces fonctions ?

Y a-t-il eu des upgrades ou transferts de rôles ?

Minute 15 : cohérence.

Les pouvoirs constatés correspondent-ils à ce que le projet raconte ?

Ce n’est pas un audit.

C’est un contrôle technique de base.

Et c’est déjà beaucoup mieux que d’acheter parce que le logo est joli.

La grille rouge, orange, verte

On peut même classer les observations, sans transformer cela en score automatique.

Plutôt rassurant :

code exactement vérifié ;

utilisation de standards largement documentés ;

permissions clairement documentées ;

multisig suffisamment distribuée ;

timelock sur les opérations critiques ;

offre conforme aux informations publiques ;

limites explicites sur les fonctions sensibles ;

audits correspondant à la version actuelle ;

historique administratif cohérent.

À approfondir :

proxy upgradeable ;

possibilité de pause ;

mint contrôlé ;

blocklist ;

taxes configurables ;

contrat très récent ;

multisig avec peu de signataires ;

grandes permissions administratives.

Ces éléments peuvent avoir des raisons parfaitement légitimes.

Très préoccupant sans bonne explication :

mint arbitraire caché malgré une promesse d’offre fixe ;

taxes modifiables vers des valeurs extrêmes ;

possibilité de bloquer sélectivement la vente ;

administrateur caché après une prétendue renonciation au contrôle ;

implémentation proxy modifiable par un seul wallet alors que le protocole se présente comme immutable ;

source non vérifiée pour un projet demandant déjà des capitaux importants ;

contradiction majeure entre documentation et code.

Aucun élément isolé ne constitue automatiquement la preuve d’une fraude.

Plusieurs contradictions ensemble changent néanmoins sérieusement le dossier.

Le smart contract ne vous dira pas si le token est bon marché

Voilà une limite fondamentale.

Vous pouvez parfaitement analyser un contrat sûr appartenant à un token horriblement surévalué.

Le smart contract ne répond pas à :

la FDV est-elle raisonnable ?

les unlocks vont-ils diluer le marché ?

l’équipe sait-elle construire un produit ?

la demande existe-t-elle ?

le token capture-t-il une valeur économique ?

Pour cela, il faut revenir à la tokenomics, aux revenus, aux utilisateurs, aux investisseurs et à la liquidité.

Notre analyse précédente de la tokenomics et le contrat sont donc deux couches complémentaires.

Tokenomics : qui recevra les tokens et quand ?

Smart contract : quelles règles ces tokens suivent-ils et qui peut les modifier ?

Un investisseur sérieux a besoin des deux.

Le code ne vous dira pas non plus si l’équipe mentira demain

Même un contrat immutable et parfaitement écrit ne garantit pas le succès d’un projet.

L’équipe peut disparaître.

Le frontend peut être compromis.

Un oracle externe peut échouer.

Un bridge peut être piraté.

La liquidité peut disparaître.

Le marché peut abandonner le produit.

Un smart contract n’est pas l’entreprise entière.

Il est seulement l’une des parties les plus vérifiables.

C’est déjà remarquable.

Dans la finance traditionnelle, un particulier ne peut pas ouvrir le logiciel interne d’une banque et vérifier lui-même quelles fonctions administratives existent.

En crypto, une partie du système financier est directement observable.

Encore faut-il regarder.

Lire le contrat change surtout les questions que l’on pose

Voilà peut-être la véritable compétence.

Avant :

« Ce token peut-il faire x10 ? »

Après quelques minutes sur le smart contract :

« Qui peut augmenter son offre ? »

« Qui peut stopper les transferts ? »

« Cette adresse administrateur est-elle une multisig ? »

« Pourquoi existe-t-il un UPGRADER_ROLE ? »

« Le contrat présenté comme immutable est-il réellement un proxy ? »

« Le plafond de taxe est-il inscrit dans le code ? »

« Qui peut ajouter une adresse à la blacklist ? »

Ce sont de meilleures questions.

Elles ne prédisent pas le prix.

Elles diminuent l’asymétrie d’information.

Lire un smart contract, ce n’est finalement pas lire du code

Pas au début.

C’est lire du pouvoir.

Qui peut créer ?

Qui peut détruire ?

Qui peut déplacer ?

Qui peut bloquer ?

Qui peut modifier ?

Qui peut remplacer le programme ?

Et combien de personnes faut-il pour le faire ?

Une fois ces réponses trouvées, le reste devient beaucoup plus clair.

Un projet peut parfaitement assumer un modèle centralisé.

Un stablecoin peut avoir besoin de mécanismes de conformité.

Une plateforme DeFi peut conserver un bouton d’urgence.

Un protocole jeune peut rester upgradeable avant de transférer progressivement davantage de contrôle à sa gouvernance.

Aucun de ces choix n’est automatiquement mauvais.

Ce qui devient problématique, c’est lorsqu’un système possède davantage de contrôle que ce que sa communication laisse entendre.

La blockchain a une particularité utile dans ce cas.

Le marketing peut dire « trustless ».

Le smart contract, lui, donne l’adresse de l’admin.

Le réflexe à conserver

La prochaine fois qu’un token vous intéresse, ne commencez donc pas uniquement par son graphique.

Copiez son adresse.

Ouvrez l’explorateur.

Cliquez sur Contract.

Vérifiez le code.

Ouvrez Read Contract.

Cherchez le propriétaire.

Puis recherchez quelques mots.

mint.

owner.

onlyRole.

pause.

blacklist.

fee.

upgrade.

Vous ne comprendrez peut-être pas tout.

Ce n’est pas grave.

Le but n’est pas de rivaliser avec un auditeur Solidity.

Le but est de ne plus être totalement aveugle devant le programme auquel vous allez confier de l’argent.

Dans un marché où une interface élégante peut masquer plusieurs couches de smart contracts, cette compétence devient presque aussi élémentaire que savoir vérifier une adresse avant un transfert.

Un smart contract ne devient pas simple parce qu’on ne connaît pas Solidity.

Mais une grande partie des pouvoirs importants peut être rendue lisible.

Et souvent, le code n’a pas besoin de vous dire si le projet est « bon ».

Il suffit qu’il vous montre qui peut changer les règles après votre arrivée.

En bref

Un non-développeur peut déjà apprendre beaucoup d’un smart contract sans analyser toute sa logique. L’adresse correcte, le statut de vérification du code, owner, les rôles administratifs, les fonctions de mint, de pause, de blacklist, de modification des frais et les mécanismes d’upgrade constituent un premier filtre puissant.

Le point le plus important reste le contrôle d’accès. Une fonction sensible n’est pas forcément dangereuse si son utilisation est limitée par une multisig, une gouvernance ou un timelock adapté. À l’inverse, un simple wallet disposant de nombreux pouvoirs constitue un modèle de confiance beaucoup plus centralisé.

Les contrats proxy demandent une attention particulière. L’adresse utilisée par les utilisateurs peut déléguer sa logique à une implémentation modifiable. Il faut donc identifier l’implémentation et l’entité autorisée à effectuer les upgrades.

Enfin, un code vérifié n’est ni un audit ni une garantie. Etherscan permet de vérifier que le code publié correspond au programme déployé ; il ne certifie pas que ce programme est exempt de vulnérabilité.