Sécurité des contrats intelligents : audit, vulnérabilités courantes, évolutivité et timelock

Guide technique. Mis à jour le 15 février 2026.

Les contrats intelligents ont perdu plus de 5 milliards de dollars d’utilisateurs entre 2020 et 2025. Non pas parce que la technologie est intrinsèquement non sécurisée, mais parce qu’il est difficile d’écrire du code correct qui gère la valeur et que les conséquences des erreurs sont irréversibles. Comprendre comment fonctionnent les bogues clés, ce que couvre un audit et comment vérifier un contrat avant d’interagir vous permet de réduire les risques de manière pratique.

Les bugs les plus courants dans les contrats intelligents

Reentrancy : la vulnérabilité qui a affecté The DAO

La réentrée est la classe de bugs la plus connue de l’histoire des contrats intelligents. Le mécanisme : un contrat A appelle un contrat B pour transférer des ETH ; le contrat B, dans sa fonction de réception, appelle A avant que A n’ait mis à jour son état interne. Le résultat est que A est trompé en lui faisant croire que le solde de l’attaquant est toujours élevé et peut être vidé plusieurs fois au cours de la même transaction.

Le piratage DAO de 2016 a exploité exactement cela : 60 millions de dollars d’ETH volés. La solution standard est le modèle « vérifications-effets-interactions » : mettez toujours à jour l’état interne (effets) avant d’interagir avec des contrats externes (interactions). ReentrancyGuard d’OpenZeppelin est aujourd’hui l’outil de défense standard.

Manipulation des prix Oracle

De nombreux protocoles DeFi lisent le prix d’un actif à partir d’un prix au comptant sur la chaîne (par exemple un pool AMM). Un attaquant disposant de suffisamment de capital – souvent via des prêts flash – peut manipuler temporairement ce prix et l’utiliser pour liquider artificiellement des positions ou extraire de la valeur des protocoles de prêt. La défense consiste à utiliser les prix TWAP (Time-Weighted Average Price) au lieu des prix spot : la moyenne dans le temps est beaucoup plus coûteuse à manipuler. Chainlink et d’autres oracles hors chaîne résolvent le problème différemment, mais introduisent une dépendance externe.

Attaque de prêt flash

Les prêts flash vous permettent d’emprunter n’importe quel montant sans garantie, à condition qu’il soit remboursé dans la même transaction. Ils ne sont pas intrinsèquement dangereux : ils constituent un outil utile pour l’arbitrage et les liquidations. Ils deviennent un vecteur d’attaque lorsqu’un protocole n’est pas conçu pour gérer des opérations volumineuses en un seul bloc. Beanstalk (2022, 182 millions de dollars), Cream Finance (2021, 130 millions de dollars) et des dizaines d’autres protocoles ont été soumis à des prêts flash qui ont amplifié les vulnérabilités dans la conception des contrats.

Dépassement et dépassement inférieur d’entier

Avant Solidity 0.8.x, les opérations arithmétiques pouvaient dépasser les limites du type entier sans revenir en arrière. Un compteur qui était censé aller à 100 pourrait « remonter » à 0 s’il était manipulé correctement. Depuis Solidity 0.8.x, le comportement par défaut est rétabli en cas de débordement, mais les contrats existants (ou les contrats compilés avec d’anciennes versions) restent vulnérables. SafeMath d’OpenZeppelin était la solution antérieure à la version 0.8.x.

Comment fonctionne un audit de sécurité

Un audit de contrat intelligent est un examen systématique du code par des experts en sécurité. Ce n’est pas une garantie qu’il n’y aura pas de bogues, mais une réduction significative de la probabilité de bogues courants et connus.

Ce que couvre un audit

Un bon audit couvre : la logique métier (le code fait-il ce que dit le livre blanc ?), les vulnérabilités connues (réentrance, débordement, manipulation d’oracle, accès non autorisé), les dépendances externes (oracle, jetons utilisés comme garantie, appelés contrats) et la centralisation (qui peut suspendre le contrat, qui peut le mettre à jour, par quel mécanisme).

Ce qu’un audit ne couvre pas : le risque de marché, la qualité de l’équipe, la pérennité du business model, les vulnérabilités zero-day inconnues à la date de l’audit. Un audit sur l’ancien code ne couvre pas les modifications ultérieures, sauf s’il y a un nouvel audit.

Comment trouver et lire les audits

Les audits publics sont disponibles sur le GitHub du projet, dans leurs Docs ou sur des plateformes comme Solodit.xyz qui les regroupent. Lorsque vous lisez un audit, recherchez : Combien de problèmes « critiques » et « élevés » ont été trouvés ? Ont-ils été résolus ? Le rapport post-fix confirme-t-il la résolution ? Un rapport qui ne trouve que « faible » et « informatif » peut être le signe que l’audit n’a pas été approfondi ou que le code est vraiment propre – vous devez avoir le contexte pour comprendre lequel.

Auditeurs reconnus en 2026 : Trail of Bits, Spearbit, OpenZeppelin, Halborn, Code4rena (modèle de concours), Cantina. Un audit réalisé par un auditeur inconnu et invérifiable ne vaut presque rien comme signal de sécurité.

Évolutivité : modèles de proxy et risques

La plupart des grands contrats DeFi sont évolutifs : le code peut être modifié après le déploiement. Cela semble contredire le principe de « l’immuabilité » de la blockchain, mais il s’agit d’une nécessité pratique pour corriger des bugs ou ajouter des fonctionnalités.

Comment fonctionne le modèle de proxy

Le mécanisme standard est le modèle proxy : les utilisateurs interagissent avec un contrat proxy qui délègue l’exécution à un contrat d’implémentation. Pour effectuer une mise à niveau, le contrat de mise en œuvre est remplacé. Le stockage reste dans le proxy, le code change dans l’implémentation.

Le principal risque est qu’une mise à niveau mal conçue puisse provoquer une « collision de stockage » : si la nouvelle implémentation utilise des variables dans des emplacements de stockage différents de la précédente, elle peut corrompre les données existantes. Le modèle UUPS (Universal Upgradeable Proxy Standard) et le Transparent Proxy d’OpenZeppelin sont les plus utilisés et audités.

Qui peut effectuer une mise à niveau ?

La question cruciale n’est pas technique mais de gouvernance : qui détient les clés pour autoriser une mise à niveau ? S’il s’agit d’un multisig avec 3 personnes anonymes, le contrat peut être modifié de manière malveillante avec la compromission de 2 clés. S’il s’agit d’une gouvernance DAO avec un délai de 48 heures, vous avez au moins le temps de quitter avant qu’une modification malveillante ne prenne effet.

Timelock : le mécanisme de sécurité pour la gouvernance

Un timelock est un contrat qui impose un délai entre la proposition d’un changement et son exécution. Il s’agit de donner aux utilisateurs le temps de vérifier ce qui va se passer et de quitter s’ils n’approuvent pas.

Norme du marché : 24 à 48 heures pour les protocoles plus petits, 72 heures ou plus pour les protocoles TVL élevés. Aave v3 utilise un timelock de 24 heures pour les paramètres mineurs et de 7 jours pour les modifications critiques. Le composé utilise 48 heures. Un protocole sans timelocks – où les mises à niveau peuvent être effectuées instantanément – est structurellement dangereux pour les utilisateurs.

Vérifiez le timelock sur la chaîne : recherchez le contrat Timelock dans l’explorateur, vérifiez la valeur de minDelay et quelle adresse a le rôle de PROPOSEUR. Si le minDelay est 0 ou si l’exécuteur est un seul EOA (compte détenu en externe), le timelock est effectivement inutile.

Comment vérifier un contrat avant d’interagir

Etherscan : vérifié ou non vérifié

Sur Etherscan, un contrat est « vérifié » si le code source a été publié et correspond au bytecode déployé. Cela ne signifie pas que le code est sûr, cela signifie que vous pouvez le lire. Un contrat non vérifié ne vous permet pas de savoir ce qu’il fait : évitez-le pour toute interaction pertinente.

Vérifiez également la date de déploiement et le nombre de transactions. Un contrat déployé hier avec zéro transaction est un signal différent de celui déployé il y a 2 ans avec des millions d’interactions.

Allocation : le risque qui s’accumule en silence

Chaque fois que vous approuvez un contrat pour dépenser vos jetons (via l’approbation ERC-20), vous donnez une signature permanente jusqu’à ce que vous la révoquiez. Au fil du temps, vous accumulez des dizaines d’indemnités sur des contrats dont vous ne pourrez peut-être plus vous servir. Si l’un de ces contrats est compromis, cela peut vous priver de jetons approuvés même si vous n’interagissez plus avec lui.

Vérifiez et révoquez périodiquement les allocations avec des outils tels que Revoke.cash ou Etherscan Token Approvals. Définissez l’allocation au minimum requis au lieu de « approuver le maximum » – de nombreux portefeuilles et dApps proposent cette option. Le coût en gaz d’une révocation est minime par rapport au risque qu’elle élimine.

Liste de contrôle de sécurité avant d’interagir avec un nouveau contrat

Le contrat est-il vérifié sur Etherscan/Basescan/etc. ?
Existe-t-il un audit récent (datant de moins de 12 mois pour une base de code active) réalisé par un auditeur reconnu ?
Qui peut mettre à niveau le contrat et dans quel délai ?
Quel oracle utilise-t-il pour la tarification : prix au comptant ou TWAP ?
Quelle est l’allocation que j’accorde : est-elle limitée ou illimitée ?
Existe-t-il un bug bounty actif sur Immunefi ou similaire ?
Quel est l’historique de sécurité du protocole au cours des 12 derniers mois ?

Contrôle d’accès : propriétaires, rôles et autorisations

La plupart des exploits de gouvernance – pas de purs bugs de code, mais des manipulations intentionnelles – exploitent des erreurs de configuration du contrôle d’accès. Qui peut appeler quelle fonction sur un contrat est tout aussi important que l’exactitude de la logique interne.

Le modèle propriétaire

Le contrat le plus simple a un « propriétaire » qui peut exercer des fonctions administratives. OpenZeppelin Ownable est le modèle standard : une variable propriétaire, un modificateur onlyOwner et des fonctions de transfert de propriété. Le principal risque est que si la clé privée du propriétaire est compromise, l’attaquant en a le contrôle total. Pour les contrats avec une TVL élevée, un EOA en tant que propriétaire est insuffisant : au moins un multisig est nécessaire.

Contrôle d’accès basé sur les rôles (RBAC)

AccessControl d’OpenZeppelin introduit des rôles granulaires : ADMIN_ROLE, PAUSER_ROLE, UPGRADER_ROLE, etc. Chaque rôle peut être attribué à différentes adresses : une multisig pour les mises à niveau, une adresse distincte pour les pauses d’urgence, une troisième pour les paramètres opérationnels. La granularité réduit les risques : compromettre le rôle PAUSER ne donne pas accès aux mises à niveau du contrat.

Comment vérifier : sur Etherscan, dans la section « Lire le contrat », recherchez les fonctions hasRole, getRoleAdmin et lisez quelles adresses ont quels rôles. Vérifiez ensuite ces adresses : sont-elles EOA ou multisig ? S’ils sont multisig, combien de signataires et avec quel seuil ?

Comment lire et interpréter un rapport d’audit

Un rapport d’audit est un document technique qui décrit les vulnérabilités trouvées, leur gravité et l’état de résolution. Comprendre comment le lire permet de l’utiliser comme un outil d’évaluation, et non comme un simple certificat à afficher en marketing.

Structure d’un rapport typique

La plupart des rapports d’audit sont structurés en : résumé, portée (quel code a été examiné, à quelle validation), conclusions (vulnérabilités) et annexe technique. La section la plus importante pour un non-technicien concerne les résultats avec leur statut de résolution.

Niveaux de gravité

Gravité	Signification	Réponse attendue
Critique	Perte de fonds directe et immédiate possible	Correctif obligatoire avant le déploiement
Haut	Perte de fonds possible sous certaines conditions	Correctif fortement recommandé
Moyen	Mauvaise conduite, perte de fonds peu probable	Correctif recommandé
Faible	Problème de conception, bonnes pratiques non suivies	Réparer à discrétion
Informatif	Observation, pas de risque direct	Envisager des améliorations futures

Un rapport présentant des problèmes critiques ou élevés non résolus avant le déploiement constitue un signal d’alarme sérieux. Un rapport avec uniquement Low et Informational peut indiquer une base de code bien écrite ou un audit qui n’est pas assez approfondi. Le contexte et la réputation de l’auditeur sont essentiels à une interprétation correcte.

Que faire si l’audit est ancien

Un audit valable au moment du déploiement peut devenir obsolète si le contrat est modifié. Recherchez toujours : le rapport est-il daté ? Y a-t-il eu des améliorations ou des changements depuis l’audit ? Si oui, existe-t-il un nouvel audit couvrant les changements ? Un protocole qui se vante d’audits en 2021 sur un code qui a été modifié 10 fois depuis n’offre pas les garanties qu’il semble être.

Bug bounty : le marché de la sécurité continue

Un bug bounty est un programme qui récompense ceux qui trouvent et signalent de manière responsable des vulnérabilités au lieu de les exploiter. Sur Immunefi, le principal agrégateur de bug bounty crypto, les récompenses vont de quelques milliers à des millions de dollars pour les vulnérabilités critiques. MakerDAO, Compound, Aave, Uniswap proposent tous des primes de bugs avec des récompenses maximales supérieures à 1 million de dollars.

L’existence d’un bug bounty actif et bien financé est un signe positif : cela indique que l’équipe a un intérêt économique à trouver les bugs avant les attaquants, et que la communauté des chercheurs en sécurité est incitée à examiner le code. Un protocole doté de 500 millions de dollars TVL et sans prime de bug parie que ses audits ont été parfaits – un pari qui a historiquement un mauvais bilan.

Surveillance continue : l’audit initial ne suffit pas

La sécurité d’un protocole n’est pas statique. De nouveaux blocs sont extraits toutes les quelques secondes ; les nouvelles transactions interagissent avec les contrats d’une manière qu’aucun audit ne pourrait pleinement prédire ; Les mises à jour de gouvernance modifient les paramètres. La surveillance continue fait partie intégrante de la sécurité.

Des outils comme Tenderly et Forta vous permettent de définir des alertes sur des événements spécifiques : une transaction importante inhabituelle sur un contrat que vous utilisez, un changement de propriétaire, l’activation d’une fonction d’urgence. OpenZeppelin Defender propose une suite plus complète pour les équipes gérant les contrats en production.

Pour les utilisateurs (et non les équipes de développement), la surveillance pratique est plus simple : suivez les canaux d’alerte des protocoles que vous utilisez (beaucoup ont des robots Telegram ou Discord pour les alertes de sécurité), configurez des alertes Etherscan par e-mail pour les contrats majeurs et utilisez des agrégateurs de sécurité comme DeFi Safety ou DefiWatch qui signalent les exploits dès qu’ils sont détectés.

La rapidité de réaction est essentielle en cas d’exploit : les protocoles sérieux prévoient des procédures de réponse aux incidents qui incluent des pauses d’urgence (disjoncteurs). Mais en tant qu’utilisateur, recevoir une alerte dans les 30 minutes suivant un exploit vous donne le temps de sortir avant que la situation ne se détériore davantage – ce qui fait souvent la différence entre récupérer 90 % et 20 % de la valeur.

Bug bounty : le marché de la sécurité préventive

Les programmes de bug bounty représentent l’un des mécanismes les plus efficaces pour la sécurité préventive des contrats intelligents. Des plateformes comme Immunefi ont distribué plus de 100 millions de dollars de récompenses aux chercheurs indépendants qui ont identifié des vulnérabilités critiques avant qu’elles ne soient exploitées. Le coût d’une prime de bug est presque toujours inférieur au coût d’un exploit non atténué.

Conclusion

La sécurité des contrats intelligents n’est pas un problème résolu, mais c’est un problème gérable. Les bugs les plus coûteux de l’histoire (réentrance, manipulation d’Oracle, mises à niveau malveillantes) peuvent tous être évités grâce à des modèles de conception connus, des audits de qualité et des mécanismes de gouvernance transparents. En tant qu’utilisateur, votre rôle est de vérifier que ces éléments existent avant de confier un contrat avec votre capital.