Sécurité des contrats intelligents : les vulnérabilités les plus courantes en 2025
nov., 17 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.
- Utilisez Solidity 0.8.0 ou plus récent. Cela élimine automatiquement les débordements d’entiers.
- Ne jamais faire confiance aux appels externes. Toujours vérifier le résultat avec
require(success, "..."). - Implémentez un contrôle d’accès strict. Utilisez OpenZeppelin’s AccessControl. Ne créez pas votre propre système de rôle.
- Utilisez plusieurs oracles. Ne dépendez jamais d’un seul fournisseur de prix. Combine Chainlink, Pyth, et des oracles internes.
- 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 %.
- 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.
- 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.
Quelle est la vulnérabilité la plus courante en 2025 ?
La vulnérabilité la plus courante et la plus coûteuse en 2025 est le contrôle d’accès défaillant (SC01). Elle a causé 953,2 millions de dollars de pertes en 2024 selon Tokenmetrics. Cela signifie qu’un développeur a oublié de vérifier qui peut exécuter une fonction critique - comme transférer des fonds ou modifier les paramètres du contrat. Ce n’est pas un bug technique complexe, mais une erreur de base qui arrive encore trop souvent.
Les contrats intelligents sont-ils plus sûrs qu’avant ?
Oui, mais seulement pour les nouveaux contrats. Depuis 2021, Solidity 0.8.0 a éliminé automatiquement les débordements d’entiers, et les outils d’audit comme Slither sont devenus plus précis. En 2025, 89 % des nouveaux protocoles DeFi font un audit formel, contre 63 % en 2023. Cependant, les contrats anciens et mal mis à jour restent des cibles faciles. La sécurité s’est améliorée, mais elle n’est pas encore standard.
Les prêts flash sont-ils illégaux ?
Non, les prêts flash ne sont pas illégaux. Ce sont des transactions techniques qui permettent d’emprunter et de rembourser en une seule opération. Mais ils sont souvent utilisés pour exploiter des failles dans les protocoles DeFi. En 2024, 42 attaques ont utilisé des prêts flash pour voler 382,1 millions de dollars. Ce n’est pas le prêt qui est le problème, c’est la mauvaise conception du contrat qui le rend vulnérable.
Dois-je utiliser Solidity ou un autre langage comme Move ?
Si vous débutez, Solidity reste le langage le plus utilisé, surtout sur Ethereum. Mais Move (sur Aptos et Sui) a montré 87 % moins de vulnérabilités critiques dans les audits de 2024. Move est conçu pour éviter les erreurs courantes dès la compilation. Si vous pouvez choisir, Move est plus sûr. Mais si vous devez travailler sur Ethereum, utilisez Solidity 0.8.30 ou plus récent, avec les meilleures pratiques d’OpenZeppelin.
Un audit garantit-il la sécurité d’un contrat ?
Non. Un audit réduit les risques, mais ne les élimine pas. Les auditeurs peuvent manquer des erreurs de logique, des combinaisons complexes de vulnérabilités, ou des attaques par oracle. Le meilleur audit est celui qui est suivi par des tests automatisés, des simulations en production, et une surveillance continue. Un audit est une étape, pas une fin.
Comment savoir si un contrat a été audité ?
Vérifiez la page du protocole. Les projets sérieux affichent le rapport d’audit en ligne, avec le nom de l’entreprise (Trail of Bits, OpenZeppelin, etc.), la date, et les vulnérabilités corrigées. Si vous ne trouvez pas ce rapport, ou s’il est ancien (plus d’un an), évitez de vous y connecter. Un audit non publié, c’est comme un certificat de sécurité sans signature.
Les contrats intelligents sont-ils une menace pour la stabilité financière ?
Oui, selon le Forum économique mondial en juin 2025. Les vulnérabilités des contrats intelligents sont classées parmi les cinq principaux risques systémiques pour la stabilité financière mondiale. Pourquoi ? Parce que des milliards de dollars sont verrouillés dans des protocoles décentralisés, et une seule faille peut provoquer une panique, une fuite massive de fonds, et une perte de confiance dans toute l’écosystème blockchain.
James Kaigai
novembre 18, 2025 AT 01:08C’est fou comment une simple ligne manquante peut tout faire exploser 😅 Je viens de relire mon dernier contrat… j’ai cru que j’avais oublié le onlyOwner, mais non, j’étais juste fatigué. Bon, j’ai corrigé, merci pour le rappel !
Lizzie Perrin
novembre 19, 2025 AT 02:09les contrats intelligents… c’est comme une porte qui s’ouvre toute seule parce que t’as oublié la clé… mais en plus, t’as mis ton argent dedans. et maintenant, tout le monde peut entrer. et personne ne comprend pourquoi. c’est pas de la tech. c’est de la négligence. et ça fait mal. j’ai vu un truc comme ça en 2023… j’ai pleuré. pas pour l’argent. pour la naïveté.
Adrien GAVILA
novembre 19, 2025 AT 16:14SC01 ? T’as lu le rapport OWASP ou t’as juste copié le résumé du Medium ? Parce que la vraie vulnérabilité, c’est la surconsommation de gas par les auditeurs qui font des checks inutiles. Et le vrai problème, c’est que personne ne veut payer pour du code propre. On veut du quick-win, pas du secure-win. Et c’est pour ça qu’on a des désastres. Pas parce que les devs sont nuls. Parce que les investisseurs sont des cons.
Arnaud Gawinowski
novembre 21, 2025 AT 10:09Je viens de perdre 40k sur un truc qui disait "audité". L’audit était signé par un gars qui a été banni de GitHub en 2022. J’ai appelé le support. Ils m’ont répondu "merci pour votre feedback". C’est pas une entreprise. C’est un scénario de film d’horreur avec des tokens.
Andre Swanepoel
novembre 22, 2025 AT 15:53J’ai travaillé sur un projet DeFi l’an dernier. On a fait un audit, on a testé avec Foundry, on a utilisé OpenZeppelin… et on a quand même eu un bug de logique métier. Un utilisateur pouvait réclamer ses récompenses 3 fois par jour au lieu d’une. On l’a vu en production. 12 heures après. On a dû arrêter tout le protocole. C’était un cauchemar. Mais on a appris. Et maintenant, on fait des reviews pair à pair. Chaque ligne. Même si ça prend 3 fois plus de temps. Parce que la sécurité, c’est pas un bonus. C’est le cœur.
Mehdi Alba
novembre 22, 2025 AT 16:31Les oracles ? C’est une arnaque. Chainlink ? C’est une entreprise centralisée qui ment. Les prix sont manipulés par les hedge funds. Les prêts flash ? C’est juste une façon de voler légalement. Et les audits ? Des blagues. Les auditeurs sont payés par les projets qu’ils audient. C’est comme si un voleur payait le détective pour qu’il dise que sa maison n’était pas volée. La blockchain est un système de contrôle social. Rien de plus. Et vous, vous croyez encore à la décentralisation ? 😏
Djamila Mati
novembre 23, 2025 AT 11:40En Afrique, on n’a pas les moyens de faire des audits de 50 000 €. Mais on a des développeurs brillants. On utilise des contrats plus simples. Moins de fonctionnalités. Plus de sécurité. On ne copie pas les modèles américains. On construit autrement. Et on n’a pas perdu un centime. Parce qu’on ne veut pas brûler la chandelle par les deux bouts. La sécurité, ce n’est pas un luxe. C’est une nécessité culturelle.
Vianney Ramos Maldonado
novembre 23, 2025 AT 18:16Il convient de souligner que l’adoption de Solidity 0.8.0, bien que techniquement optimale, ne constitue pas une garantie absolue de sécurité fonctionnelle, étant donné la nature intrinsèquement probabiliste des interactions contractuelles sur des environnements décentralisés non supervisés. Il est impératif de considérer les implications épistémologiques de la confiance algorithmique dans un cadre régulatoire encore embryonnaire.
Laurent Rouse
novembre 25, 2025 AT 06:42Les développeurs sont des crétins. Les auditeurs sont des escrocs. Les oracles sont des mensonges. Et vous, vous continuez à mettre de l’argent là-dedans ? Vous êtes des fous. Je vous l’ai dit en 2021. Je vous l’ai répété en 2023. Maintenant, vous avez perdu 3,2 milliards. Et vous voulez encore plus ? Allez-y. Je vais regarder. Avec du pop-corn. Et un verre de vin. Parce que c’est du spectacle. Et moi, j’aime les tragédies.
Philippe AURIENTIS
novembre 26, 2025 AT 17:12Je viens de refaire mon contrat avec OpenZeppelin AccessControl. 2 heures de travail. 0 erreur. J’ai même ajouté un timer de 10 min avant toute modification. C’est pas sexy, mais ça marche. Et j’ai dormi cette nuit. Merci pour l’article, c’est clair et utile. On a besoin de ça.
Denis Groffe
novembre 27, 2025 AT 14:22La SEC poursuit un protocole ? Quelle blague. Ils veulent contrôler la blockchain. C’est pas la sécurité qu’ils veulent. C’est la mainmise. Les contrats intelligents sont la seule chose qui résiste au système. Et ils vont tout détruire pour garder le contrôle. Move ? C’est un piège. Sui est financé par des fonds de capital-risque. Tout est corrompu. Vous croyez que vous êtes libres ? Vous êtes des cobayes.
Jeremy Horn
novembre 28, 2025 AT 07:19Je suis prof de dev à l’université. Depuis que j’ai introduit cet article dans mon cours, mes étudiants comprennent enfin que coder, c’est pas juste écrire des lignes. C’est penser comme un attaquant. On fait des jeux de rôle : "Comment tu détruis ce contrat ?". Et là, les lumières s’allument. Un étudiant a trouvé un bug dans un projet open-source qu’on utilisait en TP. On l’a signalé. Il a été récompensé 5000 $. Il a pleuré. Pas de joie. De fierté. Parce qu’il a compris : la sécurité, c’est un métier. Pas un bonus. Et ça, c’est une révolution.
jerome houix
novembre 30, 2025 AT 06:12SC04 : validation des entrées. J’ai corrigé ça hier. J’avais un uint256 sans check. Un testeur a envoyé -1. Le contrat a planté. J’ai mis require(amount > 0, "Invalid amount"). Simple. Mais j’ai mis 3 heures à le voir. Parce que j’étais pressé. Le pire, c’est que j’ai déjà fait ça deux fois. Je vais mettre un linter sur mon IDE. Maintenant. Sans exception.
Aurelien Amsellem
novembre 30, 2025 AT 18:51Vous parlez de Solidity 0.8.30 comme si c’était la Bible. Mais avez-vous vérifié vos dépendances ? Vos bibliothèques tierces ? J’ai vu un contrat "audité" qui utilisait une version vulnérable de SafeMath… parce que quelqu’un avait copié un package de 2020. L’audit a dit "tout est bon". Parce qu’il n’a pas checké les sous-dépendances. Donc oui, les audits sont des blagues. Et les développeurs qui croient en eux sont des enfants.
Lass Diaby
décembre 2, 2025 AT 11:12En Afrique de l’Ouest, on utilise beaucoup de contrats pour les paiements mobiles. On n’a pas de gas. On a des données limitées. On a donc créé des contrats ultra-simples. Pas de prix oracle. Pas de prêt flash. Juste un transfert vérifié. Et ça marche. Pas besoin de 800 lignes de code. Parfois, moins, c’est plus sûr. La technologie ne doit pas compliquer la vie. Elle doit la rendre plus juste.
Patrick Hochstenbach
décembre 4, 2025 AT 03:14Je viens de faire un audit pour un petit projet. Le code était propre. Mais le contrat appelait un oracle externe sans fallback. J’ai ajouté un système de médiane avec 3 sources. 15 lignes. Le projet a sauvé 2 millions. Le dev m’a dit "merci". J’ai répondu "c’est normal". C’est ça, la sécurité : pas de gloire. Juste du travail bien fait. Et si vous ne faites pas ça, vous êtes irresponsable.