Un smart contract (ou « contrat intelligent ») est un programme enregistré sur une blockchain, qui s'exécute exactement comme il a été écrit dès qu'il reçoit une transaction. Il conserve ses propres données, souvent ses propres fonds, et applique des règles définies à l'avance sans intermédiaire chargé de les exécuter. Une fois déployé, son code est public et, dans la plupart des cas, ne peut plus être modifié.
Ce qu'est un smart contract
Un smart contract est un logiciel doté d'une adresse sur une blockchain, d'un ensemble de fonctions que chacun peut appeler et d'un état (soldes, paramètres, registres) que seules ces fonctions peuvent modifier. Le terme désigne aujourd'hui presque toujours des programmes exécutés sur Ethereum et les réseaux compatibles.
Trois propriétés le distinguent d'un code classique hébergé sur un serveur :
- Une exécution déterministe. Chaque nœud du réseau exécute le même code avec les mêmes données et doit obtenir le même résultat. Il n'y a ni serveur caché ni opérateur capable de modifier discrètement le résultat.
- Un code public et vérifiable. Le code déployé et son état sont visibles par tous. Les utilisateurs peuvent vérifier les règles avant d'interagir.
- La garde des actifs par le contrat lui-même. Un contrat peut détenir des jetons ou la monnaie native du réseau et ne les libérer que dans les conditions inscrites dans son code.
Un smart contract n'est pas un contrat au sens juridique. Il peut mettre en œuvre une partie d'un accord (un échéancier de paiement, une règle d'acquisition progressive, une restriction de transfert), mais sa portée juridique dépend de la documentation qui l'entoure et du droit applicable.
Comment un smart contract s'exécute sur une blockchain
Un smart contract ne s'exécute que lorsqu'une transaction ou un autre contrat appelle l'une de ses fonctions : il n'agit jamais de sa propre initiative. Son cycle de vie suit généralement ces étapes :
- Écriture. Les développeurs écrivent le contrat dans un langage comme Solidity ou Vyper pour les réseaux compatibles EVM, Rust pour Solana, Move ou Cairo pour d'autres écosystèmes.
- Compilation. Le code source est compilé en bytecode, compris par la machine virtuelle du réseau. Sur les réseaux EVM, il s'agit de l'Ethereum Virtual Machine.
- Déploiement. Une transaction de déploiement publie le bytecode et attribue au contrat une adresse définitive.
- Interaction. Utilisateurs, applications et autres contrats envoient des transactions à cette adresse. Chaque appel est validé par le réseau, exécuté par tous les nœuds et inscrit dans un bloc.
- Frais. Chaque opération consomme du calcul, payé en gas sur les réseaux EVM. C'est pourquoi l'efficacité du code compte : chaque ligne a un coût pour l'utilisateur.
Un contrat ne peut pas lire seul le monde extérieur. Un cours, une donnée météo ou le résultat d'un événement doivent être apportés sur la chaîne par un oracle, un service distinct auquel le contrat doit faire confiance.
Immuabilité et évolutivité
Par défaut, le code d'un smart contract déployé ne peut pas être modifié : pour changer son comportement, il faut déployer un nouveau contrat et y faire migrer les utilisateurs. Cette immuabilité fonde la confiance accordée aux contrats, et explique aussi pourquoi une erreur coûte si cher.
Comme un code définitif est difficile à maintenir, beaucoup de projets rendent leurs contrats évolutifs (on parle de contrats « upgradeable ») :
- Les contrats proxy. Les utilisateurs interagissent avec une adresse fixe, le proxy, qui transmet les appels à un contrat d'implémentation. Remplacer l'implémentation change la logique tout en conservant l'adresse et les données. Voir proxy évolutif.
- Les paramètres modifiables. Certaines valeurs (frais, plafonds, actifs acceptés) peuvent être ajustées par un administrateur sans toucher au code.
- La migration. Une nouvelle version est déployée et les utilisateurs sont invités, ou contraints, à y transférer leurs positions.
L'évolutivité est un arbitrage, pas une amélioration gratuite. Celui qui contrôle la mise à jour peut changer les règles : la vraie question devient donc qui détient ce pouvoir et avec quelles limites. Les garde-fous courants sont un portefeuille multisig, qui exige plusieurs signatures, et un timelock, qui impose un délai avant l'application d'un changement pour laisser aux utilisateurs le temps de réagir.
À quoi servent les smart contracts
Les smart contracts sont utilisés partout où des règles portant sur de la valeur ou des droits doivent s'appliquer de la même façon à tous, sans opérateur central. Les principales catégories sont les suivantes :
| Usage | Rôle du contrat | Exemples courants |
|---|---|---|
| Jetons (tokens) | Émettre des unités de valeur et suivre leurs transferts | Jetons fongibles au standard ERC-20, jetons d'usage ou de gouvernance |
| DeFi | Faire fonctionner des services financiers dont les règles sont inscrites dans le code | Plateformes d'échange à teneur de marché automatisé (AMM), protocoles de prêt, staking |
| NFT | Représenter des biens uniques et leur propriété | Collections ERC-721 ou ERC-1155, billets, certificats |
| Tokenisation | Représenter des actifs réels sur la chaîne | Parts de fonds, obligations, immobilier, avec restrictions de transfert et listes d'investisseurs autorisés |
| DAO | Organiser des décisions collectives | Propositions, votes, gestion d'une trésorerie exécutée par le contrat |
Ces catégories diffèrent beaucoup en complexité. Un jeton standard peut tenir en quelques centaines de lignes, appuyées sur des bibliothèques éprouvées. Un protocole de prêt combine flux de prix, modèles de taux, liquidations et de nombreux cas limites. La tokenisation d'actifs réels ajoute des contraintes réglementaires (qui peut détenir l'actif, comment les transferts sont restreints) qu'il faut traduire dans le code.
Limites et risques
Le principal risque d'un smart contract est qu'une erreur dans son code est publique, exploitable par n'importe qui et souvent irréversible. Les propriétés qui rendent les contrats dignes de confiance rendent aussi leurs défaillances graves.
Les bugs sont permanents
Si une fonction permet une action non prévue, un attaquant peut l'appeler dès qu'il la repère. Les transactions confirmées ne peuvent pas être annulées par le projet. Parmi les familles de failles connues figurent la réentrance, un contrôle d'accès insuffisant, les erreurs d'arrondi et d'arithmétique, ou une logique qui se comporte mal dans des conditions de marché inhabituelles. Le OWASP Smart Contract Top 10 constitue une référence publique utile.
Oracles et dépendances externes
Un contrat qui dépend de données externes n'est pas plus fiable que ces données. Un prix manipulé ou périmé peut déclencher des liquidations injustifiées ou permettre à un attaquant d'emprunter plus qu'il ne le devrait. Chaque protocole intégré importe aussi ses propres risques.
Clés et pouvoirs d'administration
Les fonctions d'administration sont protégées par des clés privées. Une clé perdue peut faire perdre le contrôle du projet ; une clé volée donne à l'attaquant les pouvoirs du propriétaire. La gestion des clés, les seuils de signature multisig et les timelocks font partie de la sécurité du contrat, ce ne sont pas de simples détails d'exploitation.
Ce qu'un audit peut apporter, et ce qu'il ne peut pas garantir
Un audit indépendant réduit le risque en confiant la relecture du code à des spécialistes, mais un audit ne garantit pas l'absence de bugs. Il porte sur un périmètre défini, à une version précise du code. Des tests solides, une documentation claire, un réaudit des corrections et, pour les projets importants, un bug bounty (programme de récompense pour la découverte de failles) ajoutent des niveaux d'assurance supplémentaires.
Ce qu'il faut pour construire un smart contract
Construire un smart contract avec rigueur passe par trois étapes distinctes : un cahier des charges précis, un développement accompagné de tests, puis un audit indépendant suivi d'un réaudit des corrections.
- Le cahier des charges. Un document qui décrit ce que le contrat doit faire : utilisateurs et rôles, règles, paramètres, blockchain cible, intégrations, pouvoirs d'administration, livrables et budget. Il sert de base à des devis comparables et au périmètre de l'audit. Le guide rédiger le cahier des charges d'un smart contract en détaille le contenu.
- Le développement. Les développeurs écrivent les contrats, les tests unitaires et, pour une logique complexe, des tests de fuzzing (génération massive d'entrées aléatoires) ou d'invariants. Ils déploient d'abord sur un réseau de test (testnet), puis préparent le déploiement sur le réseau principal.
- L'audit et le réaudit. Des auditeurs indépendants examinent une version figée du code et remettent des constats classés par gravité. Les développeurs les corrigent, puis les auditeurs vérifient ces corrections lors du réaudit. L'audit doit être confié à une société qui n'a pas développé le code, pour que la revue soit réellement indépendante.
À titre d'ordre de grandeur, le modèle public du site estime un jeton simple à environ 5 à 12 jours-développeur et un protocole de prêt à environ 60 à 130 jours-développeur, l'audit venant en plus. Ce sont des fourchettes indicatives : les devis réels dépendent du périmètre. Le calculateur de coût de développement vous permet de tester vos propres paramètres.
Par où commencer
La meilleure première étape consiste à décrire votre besoin par écrit avant de contacter le moindre développeur. Un document court et structuré oblige à trancher tôt les questions importantes et rend comparables les réponses que vous recevrez.
- Définissez l'objectif. Quel problème le contrat résout-il, et pour qui ? Une base de données classique suffirait-elle ? Si aucune partie n'a besoin de vérifier les règles de façon indépendante, un smart contract n'est peut-être pas nécessaire.
- Listez les règles. Qui peut faire quoi, dans quelles conditions, avec quelles limites.
- Choisissez la blockchain. Fondez ce choix sur vos utilisateurs, l'écosystème avec lequel vous devez vous intégrer et les coûts d'exploitation, plutôt que sur les tendances.
- Décidez du contrôle. Le contrat sera-t-il évolutif ? Qui détiendra les clés d'administration, et comment seront-elles protégées ?
- Prévoyez l'audit dès le départ. Intégrez son budget et son calendrier à votre planning, et choisissez des auditeurs indépendants de vos développeurs.
Le générateur de cahier des charges vous guide à travers ces questions et produit un document structuré à transmettre aux prestataires. smart-contract.com s'appuie sur ce type de document pour recueillir des devis au même format, d'abord auprès de développeurs, puis d'auditeurs indépendants.
À retenir
- Un smart contract est un programme sur une blockchain qui détient des données et des actifs, et applique ses règles exactement comme elles sont écrites à chaque appel.
- Le code déployé est public et généralement immuable ; l'évolutivité est possible, mais elle déplace la confiance vers celui qui contrôle les mises à jour.
- Jetons, DeFi, NFT, tokenisation et DAO sont les principaux usages, avec des niveaux de complexité très différents.
- Les bugs, les défaillances d'oracle et les clés compromises sont les principaux risques ; un audit les réduit mais ne garantit pas l'absence de bugs.
- Commencez par un cahier des charges écrit, puis un développement testé, puis un audit indépendant et un réaudit des corrections.