Pourquoi la sécurité des contrats intelligents diffère-t-elle de celle des logiciels classiques ?
La sécurité des contrats intelligents est différente, car leur code est public, ils détiennent souvent directement des fonds et ne peuvent généralement plus être modifiés après leur déploiement. Un bogue dans une application Web peut être corrigé en une nuit ; un bogue dans un contrat peut être découvert par toute personne qui lit le code et exploité avant même que l’équipe ne se réveille. Ethereum.org estime les pertes dues aux défauts des contrats intelligents à plus d’un milliard de dollars et cite le piratage de la DAO en 2016 comme l’un des premiers exemples.
Prenons l’exemple d’un studio fictif de quatre personnes, Larkspur Labs, qui développe une simple cagnotte d’épargne où les membres déposent des fonds et retirent leur part. Avant le déploiement, le développeur, Kofi, laisse ses notes de revue : 'withdraw envoie les fonds puis met le solde à 0. setFee est publique, accès à restreindre plus tard. ancienne version du compilateur reprise du tutoriel. prix du jeton de récompense lu depuis une seule petite réserve de liquidités d’échange. tests : essayé deposit + withdraw une fois à la main, ça fonctionne'. Chaque ligne correspond à une catégorie de vulnérabilités connue.
Quelles sont les vulnérabilités les plus courantes des contrats intelligents ?
Les vulnérabilités les plus courantes des contrats intelligents sont les failles de contrôle d’accès, la manipulation des oracles de prix, les erreurs de logique, l’absence de validation des entrées et la réentrance, qui figurent en tête du OWASP Smart Contract Top 10 pour 2025. Ethereum.org couvre les mêmes grandes catégories.
Réentrance
Un contrat envoie des fonds ou appelle un autre contrat avant de mettre à jour ses propres données. Un destinataire malveillant le rappelle alors que l’ancien solde est encore affiché et effectue un nouveau retrait. La fonction withdraw de Kofi, qui verse les fonds avant de ramener le solde à zéro, en est l’exemple classique. La correction habituelle consiste à mettre d’abord l’état à jour et à interagir avec les autres contrats en dernier, selon l’ordre souvent appelé vérifications, effets, interactions.
Contrôle d’accès
Des fonctions sensibles que n’importe qui peut appeler. La fonction publique setFee de Kofi permet à n’importe quel inconnu de modifier les frais. Ethereum.org décrit des mécanismes tels qu’un rôle de propriétaire, des accès fondés sur les rôles et une approbation à signatures multiples.
Dépassement des limites supérieure et inférieure des entiers
Un calcul qui repart à l’autre extrémité de la plage de valeurs lorsqu’il dépasse sa limite, si bien qu’un solde inférieur à zéro devient un nombre énorme. Ethereum.org précise que Solidity 0.8.0 et les versions ultérieures rejettent ce comportement par défaut, tandis que le code plus ancien nécessite des vérifications explicites, d’où l’importance de l’ancien compilateur de Kofi.
Manipulation de l’oracle
Utiliser un prix provenant d’un seul marché peu liquide qu’un attaquant peut manipuler, souvent à l’aide d’un prêt éclair, emprunté et remboursé au sein d’une même transaction. Les architectures robustes utilisent des oracles décentralisés ou des prix moyens calculés sur une période.
Erreurs de logique et de validation
Des règles qui ne correspondent pas à la conception prévue, ou des données d’entrée qui ne sont jamais vérifiées, comme un montant nul ou une adresse inattendue.
Comment les équipes testent-elles et auditent-elles les contrats intelligents ?
Les équipes testent et auditent les contrats intelligents à plusieurs niveaux, car aucune méthode ne détecte tout : tests automatisés, outils d’analyse, déploiement sur un réseau de test, revue indépendante et, pour les contrats détenant une valeur importante, audit externe et programme de primes à la découverte de failles.
1. Tests unitaires et tests de propriétés
Rédigez des tests pour chaque fonction, y compris des cas malveillants, comme un destinataire qui rappelle la fonction pendant son exécution. Les tests par fuzzing essaient automatiquement des milliers d’entrées aléatoires.
2. Analyse statique
Ethereum.org cite des outils comme Slither, Mythril et Aderyn, qui analysent le code pour détecter des schémas à risque connus.
3. Testez les réseaux
Déployez sur un réseau de test public avant de passer au réseau principal. Ethereum.org recommande Sepolia pour le développement d’applications et de contrats ; l’ether du réseau de test est censé n’avoir aucune valeur réelle, les erreurs ne coûtent donc rien.
4. Évaluation par les pairs et bibliothèques auditées
Utilisez un système de gestion de versions, faites examiner chaque modification par des personnes indépendantes et utilisez des bibliothèques ayant fait l’objet de vérifications approfondies, comme OpenZeppelin Contracts, plutôt que de créer vous-même le contrôle d’accès.
5. Audit, primes de signalement et surveillance
Les audits indépendants apportent un examen supplémentaire, mais, comme le souligne ethereum.org, ne détectent pas tous les bogues. Les programmes de primes aux bogues, les fonctions de pause d’urgence et la surveillance des événements complètent cette protection.
À quoi ressemble une analyse de sécurité insuffisante ou améliorée ?
Contrôle insuffisant : « Dépôt et retrait testés manuellement, tout fonctionne, prêt à être déployé. » Un test du scénario nominal montre que le contrat fonctionne pour des utilisateurs honnêtes, ce que les attaquants ne sont justement pas.
Revue améliorée : Réentrance : withdraw met désormais le solde à zéro avant l’envoi, et un test utilise un contrat destinataire malveillant pour tenter un nouvel appel. Contrôle d’accès : setFee est réservé à un rôle de propriétaire issu d’une bibliothèque auditée, avec un test vérifiant que l’appel d’un tiers échoue. Compilateur : passage à une version 0.8 récente pour activer les contrôles de dépassement. Oracle : remplacement du prix d’un seul pool par un flux de prix décentralisé, avec une limite de cohérence sur les variations soudaines. Tests : tests unitaires, campagne de tests par entrées aléatoires et analyse statique avec explication de chaque constat, puis deux semaines sur Sepolia avec un collègue qui tente de mettre le contrat en défaut. Audit externe prévu avant toute acceptation de fonds réels.
Quelles sont les erreurs courantes en matière de sécurité des contrats intelligents ?
L’erreur la plus courante est de ne tester que le scénario nominal, comme si tous ceux qui appellent le contrat étaient honnêtes. Autres erreurs : laisser les fonctions d’administration accessibles en prévoyant de les restreindre plus tard, copier le code d’un tutoriel utilisant un compilateur obsolète, faire confiance à une seule source de prix, considérer un audit comme une garantie, sauter l’étape du réseau de test et déployer sans prévoir de mécanisme de suspension ou de mise à niveau.
Où se situe cette leçon dans Tosheo.ai ?
Cette leçon de programmation appartient à la catégorie Chaîne de blocs et au cours sur la chaîne de blocs. Cette page gratuite explique chaque étape sous forme de texte ; la version pratique complète, dans laquelle vous examinez et corrigez le code de vrais contrats et exécutez des tests sur un réseau de test, est proposée dans le parcours facultatif Programmation après inscription. Si vous découvrez les bases, commencez par l’explication des contrats intelligents. Tosheo.ai n’est ni une formation intensive à temps plein ni une qualification professionnelle d’auditeur, et aucun contenu présenté ici ne constitue un conseil en investissement ; les contrats qui détiennent des actifs de valeur réelle nécessitent un audit spécialisé.
Sources et périmètre
ethereum.org, sécurité des contrats intelligents (vérifié le 19 octobre 2026) ↗
ethereum.org, réseaux et réseaux de test (vérifié le 19 octobre 2026) ↗