Sécurité des contrats intelligents : les vulnérabilités les plus courantes en 2025

Les contrats intelligents sont censés être infaillibles. Automatiques. Immutables. Mais en 2025, ils ont encore causé plus de 3,2 milliards de dollars en pertes à cause de failles simples, évitables, et souvent mal comprises. Ce n’est pas la technologie qui échoue. C’est la façon dont les développeurs les écrivent.

Les huit vulnérabilités les plus dangereuses en 2025

Le groupe OWASP a publié sa liste mise à jour en mars 2025 : le Smart Contract Top 10. Ce n’est pas un simple classement. C’est une cartographie des erreurs qui ont vidé des protocoles entiers. Voici les huit principales menaces.

SC01 : Contrôle d’accès défaillant - C’est la plus coûteuse. En 2024, elle a causé 953,2 millions de dollars de pertes. Pourquoi ? Parce qu’un développeur a oublié de vérifier qui peut appeler une fonction. Un exemple récent : en septembre 2023, un contrat a été réinitialisé par un attaquant parce que la fonction d’initialisation n’était pas protégée. Résultat ? L’attaquant est devenu propriétaire du contrat. Il a pu modifier les règles, voler les fonds, et personne ne l’a vu venir. Ce n’est pas un bug complexe. C’est une erreur de base. Un seul mot manquant : onlyOwner.

SC02 : Manipulation des oracles de prix - Les contrats intelligents ne voient pas le monde réel. Ils dépendent des oracles pour connaître le prix de l’ETH, du BTC, ou d’un token. Mais si un oracle est trompé, le contrat suit. En 2024, 37 attaques ont réussi en ciblant les oracles. Un attaquant a acheté une petite quantité d’un token sur un DEX, fait monter artificiellement son prix, puis emprunté des millions via un prêt flash pour acheter plus de tokens à un prix bas. Quand le prix est retombé, le contrat a payé selon la valeur fausse. Le protocole Hundred Finance a perdu 38 100 $ en août 2024 à cause de ça. Les oracles comme Chainlink ne sont pas parfaits. Ils doivent être redondants, diversifiés, et surveillés en temps réel.

SC03 : Erreurs de logique métier - Ce n’est pas un bug dans le code, mais dans la pensée. Par exemple, un contrat distribue des récompenses chaque semaine. Mais il oublie de vérifier si un utilisateur a déjà été récompensé. Résultat : un utilisateur peut appeler la fonction 100 fois et toucher 100 fois la récompense. OpenZeppelin a identifié 12 % des vulnérabilités comme étant de ce type. C’est difficile à détecter avec des outils automatisés. Il faut lire le code comme un humain. Comme si vous suiviez un processus bancaire. Où est l’erreur ?

SC04 : Absence de validation des entrées - Un utilisateur envoie 1000 tokens à un contrat. Le contrat suppose qu’il y en a toujours assez. Mais s’il envoie 0 ? Ou -1 ? Le contrat peut planter, ou pire, déclencher un comportement inattendu. En 2024, cela a coûté 14,6 millions de dollars. La solution ? Toujours vérifier les valeurs. Même si vous pensez que l’utilisateur ne fera pas ça. Il le fera.

SC05 : Attaques de réentrance - C’est la vulnérabilité du DAO en 2016. Elle a fait perdre 60 millions de dollars. Le principe ? Un contrat envoie des fonds à un autre contrat. Mais ce contrat malveillant appelle à nouveau le contrat original avant que la transaction ne soit terminée. Et encore. Et encore. Jusqu’à vider le portefeuille. Solidity 0.8.0 a rendu cette attaque plus difficile, mais elle n’a pas disparu. En 2024, 28 attaques ont encore réussi. Pourquoi ? Parce que certains développeurs utilisent encore des versions anciennes. Ou ils utilisent des bibliothèques tierces qui contiennent le même bug.

SC06 : Appels externes non vérifiés - C’est la nouvelle menace montante. En 2021, elle était à la 10e place. En 2025, elle est à la 6e. Pourquoi ? Parce que les développeurs pensent que les contrats externes sont fiables. Ils appellent someContract.transfer() sans vérifier si l’appel a réussi. Si l’adresse externe est un contrat malveillant, il peut bloquer la transaction, ou renvoyer une erreur silencieuse. Le contrat pense que tout va bien. En réalité, les fonds sont bloqués. En 2024, 19 attaques ont exploité ce bug. La bonne pratique ? Toujours vérifier le retour de l’appel. Avec require(success, "Call failed").

SC07 : Attaques par prêt flash - Ce n’est pas une vulnérabilité du contrat. C’est un outil. Mais il est devenu une arme. Un prêt flash permet d’emprunter des millions de dollars, de les utiliser dans un seul bloc, puis de les rembourser - tout en une seule transaction. Si un protocole n’est pas conçu pour résister à ce genre de manipulation, il peut être déstabilisé en 15 secondes. En 2024, 42 attaques ont utilisé cette méthode. Aave a été ciblé 19 fois. Le seul moyen de se protéger ? Limiter les montants maximaux, introduire des délais de vérification, et ne jamais faire confiance à une seule source de prix dans un seul bloc.

SC08 : Débordement et sous-débordement d’entiers - Ceux-ci ont presque disparu. Depuis Solidity 0.8.0 (juillet 2021), les dépassements de nombres sont bloqués automatiquement. Mais il reste des contrats anciens. Des contrats sur d’autres blockchains. Des contrats mal mis à jour. En 2024, ils ont encore causé 28,4 millions de pertes. La règle est simple : ne jamais utiliser Solidity 0.7.x ou plus ancien. Et vérifiez les dépendances de vos bibliothèques. Elles peuvent contenir du code ancien.

Qui est responsable ?

Les développeurs ? Les auditeurs ? Les utilisateurs ?

La vérité, c’est que tout le monde a un rôle. Mais les développeurs portent la plus grande part de la responsabilité. Un audit ne peut pas sauver un contrat mal conçu. Les outils comme Slither, Mythril ou Echidna détectent 80 % des vulnérabilités. Mais pas toutes. Pas les erreurs de logique. Pas les oublis de contrôle d’accès. Ce sont des erreurs humaines.

Et pourtant, 74 % des développeurs interrogés en 2025 disent que la sécurité est la partie la plus difficile de la programmation de contrats intelligents. Pourquoi ? Parce qu’il n’y a pas de formation sérieuse. Pas de certificat reconnu. Pas de bonnes pratiques enseignées dans les écoles. Les développeurs apprennent sur GitHub, sur Discord, en copiant-collant du code. Et ça ne marche pas.

Comment se protéger ?

Il n’y a pas de solution magique. Mais il y a des actions concrètes.

1. Utilisez Solidity 0.8.0 ou plus récent. Cela élimine automatiquement les débordements d’entiers.
2. Ne jamais faire confiance aux appels externes. Toujours vérifier le résultat avec require(success, "...").
3. Implémentez un contrôle d’accès strict. Utilisez OpenZeppelin’s AccessControl. Ne créez pas votre propre système de rôle.
4. Utilisez plusieurs oracles. Ne dépendez jamais d’un seul fournisseur de prix. Combine Chainlink, Pyth, et des oracles internes.
5. Faites un audit formel. Pas un audit de 5000 dollars. Un audit sérieux. Par Trail of Bits, OpenZeppelin, ou Quantstamp. Le coût d’un audit, c’est 1 à 3 % du montant total verrouillé. Le coût d’une attaque, c’est 100 %.
6. Testez avec des outils formels. Echidna, Foundry, ou les nouveaux outils de vérification formelle intégrés dans le workflow Ethereum. Ils ne sont pas faciles. Mais ils détectent des bugs que personne ne voit.
7. Surveillez les mises à jour. Solidity 0.8.30 (mai 2025) a ajouté des vérifications automatiques pour les appels externes. Mettez à jour vos outils. Vos dépendances. Vos contrats.

Les bonnes nouvelles

Il y a de l’espoir.

En 2023, seulement 63 % des nouveaux protocoles DeFi faisaient un audit. En 2025, c’est 89 %. Les entreprises comme MakerDAO ont mis en place des systèmes de gouvernance multi-signature qui ont bloqué une attaque potentielle de 1,2 milliard de dollars en mars 2025. Les plateformes comme Immunefi versent en moyenne 28 745 $ par rapport de vulnérabilité. Le plus grand paiement en 2024 : 2,1 millions de dollars pour un bug d’accès dans Aave.

Les langages comme Move (utilisé par Aptos et Sui) montrent 87 % moins de vulnérabilités critiques que Solidity. Ce n’est pas une coincidence. Ce sont des langages conçus pour la sécurité, pas pour la rapidité.

La sécurité des contrats intelligents n’est plus une option. C’est une exigence. Et en 2025, les régulateurs commencent à agir. La SEC a poursuivi un protocole DeFi pour « absence de contrôle de sécurité adéquat ». C’est un signal clair : si vous êtes vulnérable, vous êtes responsable.

Et maintenant ?

Si vous êtes développeur : relisez votre code comme si vous étiez un attaquant. Posez-vous cette question : « Comment est-ce que je pourrais détruire ce contrat ? »

Si vous êtes utilisateur : ne mettez pas plus d’argent dans un protocole que vous ne comprenez pas. Et vérifiez si le contrat a été audité. Par qui ? Quand ? Quels bugs ont été trouvés ?

La blockchain n’est pas une technologie magique. Elle est juste un outil. Et comme tout outil, elle peut être dangereuse si on ne la manipule pas avec soin.