Un audit de smart contract qui rate une réentrance coûte cher. Trail of Bits, la société derrière Slither et Echidna, cite encore la réentrance et les erreurs de contrôle d’accès comme les deux premières causes de pertes DeFi recensées dans les référentiels d’audit 2026. Face à ce risque, trois outils open source dominent les pipelines d’audit Ethereum : Slither, Mythril et Echidna. Aucun des trois ne fait tout, et c’est justement le problème que rencontrent la plupart des équipes qui débutent en sécurité Solidity : lequel choisir, dans quel ordre, et pour quel budget de calcul ?
Ce comparatif détaille les trois méthodes (analyse statique, exécution symbolique, fuzzing basé sur les propriétés), leurs performances mesurées, leur tarification (tous gratuits, mais pas sans coût d’infrastructure), et la manière dont les équipes d’audit professionnelles les combinent réellement en 2026. Le contexte est loin d’être théorique : selon TRM Labs, les acteurs malveillants ont volé 2,87 milliards de dollars en cryptomonnaies sur près de 150 hacks et exploits distincts en 2025, avec une sévérité en forte hausse liée à un glissement structurel des vecteurs d’attaque vers la couche opérationnelle plutôt que vers le seul code du contrat.
Slither, Mythril, Echidna : trois philosophies différentes
La première chose à comprendre avant de choisir un outil d’audit smart contract, c’est qu’il n’existe pas de hiérarchie simple entre Slither, Mythril et Echidna. Chacun répond à une question différente sur le code.
Slither est un analyseur statique développé par Trail of Bits pour Solidity et Vyper. Écrit en Python, il convertit le code source en une représentation intermédiaire appelée SlithIR, puis exécute plus de 30 détecteurs intégrés sans jamais exécuter le contrat lui-même. Cette approche le rend extrêmement rapide : une analyse complète prend généralement moins d’une seconde sur un contrat de taille moyenne, ce qui en fait l’outil de choix pour une intégration en CI/CD, à chaque pull request. La dernière version disponible sur son dépôt GitHub, Slither 0.11.6, date du 28 juillet 2026, sur un total de 48 releases publiées depuis la création du projet.
Mythril, développé à l’origine par ConsenSys, repose sur une logique radicalement différente : l’exécution symbolique combinée à une analyse SMT (Satisfiability Modulo Theories). Au lieu de repérer des motifs de code dangereux, Mythril explore les chemins d’exécution possibles du contrat en traitant les variables d’entrée comme des symboles plutôt que des valeurs concrètes. Il peut ainsi révéler des combinaisons d’entrées qui mèneraient à une violation de sécurité, y compris des scénarios qu’un simple pattern-matching statique ne verrait jamais. Le revers de la médaille : cette exploration est coûteuse en temps de calcul, et devient difficile à faire converger sur des contrats complexes ou fortement interconnectés.
Echidna, également maintenu par Trail of Bits, applique une troisième méthode : le fuzzing basé sur les propriétés. L’auditeur définit des invariants (des règles qui doivent toujours rester vraies, par exemple “le solde total ne doit jamais dépasser l’offre maximale”), et Echidna génère automatiquement des séquences de transactions pour tenter de les casser. La version la plus récente identifiée sur son dépôt, Echidna 2.2.7, a été publiée le 21 juillet 2025, portant le total à 35 releases. Echidna a servi dans des revues de sécurité publiques concernant des protocoles comme Uniswap, Origin Dollar, TokenCard et Advanced Blockchain, selon la documentation officielle du projet.
Un point mérite d’être clarifié tout de suite : ces trois outils ne sont pas des concurrents interchangeables. Les guides d’audit publiés en 2026 recommandent unanimement de les combiner plutôt que de choisir l’un contre les autres. La question n’est donc pas “lequel est le meilleur”, mais “dans quel ordre les utiliser, et avec quel budget de temps”.
Tableau comparatif : Slither vs Mythril vs Echidna
Voici la comparaison technique complète des trois outils, sur les critères qui comptent réellement pour une équipe de développement ou d’audit.
| Critère | Slither | Mythril | Echidna |
|---|---|---|---|
| Éditeur | Trail of Bits | ConsenSys (communautaire depuis) | Trail of Bits |
| Méthode | Analyse statique (SlithIR) | Exécution symbolique + SMT | Fuzzing basé sur les propriétés |
| Exécution du contrat | Non | Modélisée symboliquement | Oui, via séquences générées |
| Vitesse typique | Moins d’une seconde | Plusieurs minutes à heures | Milliers de transactions/seconde |
| Langage cible | Solidity, Vyper | Solidity (bytecode EVM) | Solidity |
| Détecteurs intégrés | 30+ détecteurs prêts à l’emploi | Analyse de chemins, pas de liste fixe | Dépend des invariants définis |
| Meilleur usage | CI/CD, revue rapide à chaque commit | Exploration de chemins complexes | Test d’invariants métier et scénarios adverses |
| Faux positifs | Modérés, nécessite triage manuel | Faibles mais lenteur pénalisante | Faibles, dépend de la qualité des invariants écrits |
| Faux négatifs | Ne prouve pas l’exploitabilité réelle | Couverture variable sur code complexe | Rate ce qui n’est pas couvert par un invariant |
| Dernière version notée | 0.11.6 (28 juillet 2026) | Maintenance communautaire active | 2.2.7 (21 juillet 2025) |
| Intégration CI/CD | Native, très légère | Possible mais coûteuse en temps machine | Native via foundry ou hevm |
| Licence | AGPL-3.0, open source | Open source (dérivés communautaires) | AGPL-3.0, open source |
| Coût | Gratuit | Gratuit | Gratuit |
Un tableau annexe publié par le projet communautaire SolidityGuard en février 2026 confirme cette répartition des rôles : Slither et son concurrent en Rust Aderyn s’exécutent en sous-seconde avec plus de 90 à 100 détecteurs, Mythril prend plusieurs minutes pour une exploration en profondeur, et Echidna atteint plus de 3 000 transactions testées par seconde dans ses campagnes de fuzzing.
Benchmarks : ce que disent réellement les tests
Les chiffres de performance bruts varient selon les jeux de test, mais trois sources convergent sur les mêmes tendances. Le guide 2026 publié par CloudLogic, qui a testé les trois outils sur des contrats de production, confirme que Slither transforme le code Solidity en SlithIR et exécute ses 30+ détecteurs en quelques centaines de millisecondes, quand une passe Mythril complète sur le même contrat dépasse largement la minute. Le blog SmartContractAudit, dans son guide de test automatisé 2026, situe Slither et son rival plus récent Aderyn dans la même classe de vitesse sub-seconde, avec Mythril rangé dans une classe à part, celle des minutes, réservée aux analyses ciblées plutôt qu’aux vérifications systématiques.
Le troisième repère vient de la littérature académique. Une étude de 2025 publiée sur la plateforme Diva-Portal décrit un pipeline combinant les trois approches (Echidna pour le fuzzing basé sur les propriétés, Mythril pour l’exécution symbolique, Slither pour l’analyse statique) précisément parce qu’aucune des trois méthodes prise isolément n’atteint une couverture suffisante des classes de vulnérabilités connues. C’est aussi la conclusion opérationnelle à laquelle arrivent les checklists d’audit professionnelles publiées en 2026 : la réentrance, les failles de contrôle d’accès et les dépassements arithmétiques restent en tête des trois vulnérabilités les plus fréquentes, et un audit complet mélange revue manuelle, analyse statique, exécution symbolique et fuzzing plutôt que de s’appuyer sur un seul outil.
Sur le terrain de la couverture des classes de vulnérabilités du registre SWC (Smart Contract Weakness Classification), la répartition observée dans les guides d’audit 2026 est la suivante : la réentrance correspond à SWC-107, les fonctions non protégées à SWC-105, les valeurs de retour non vérifiées à SWC-104, les appels delegatecall risqués à SWC-112, et l’usage dangereux de tx.origin à SWC-115. Slither détecte nativement la plupart de ces motifs statiques. Mythril, via son exploration de chemins, capture davantage les combinaisons d’entrées qui déclenchent ces failles en conditions réelles. Echidna, lui, ne détecte rien par défaut : il ne casse que les invariants que l’auditeur a explicitement écrits, ce qui en fait l’outil le plus exigeant à configurer mais aussi le plus proche du comportement réel d’un attaquant.
Tarification et coût réel d’utilisation
Les trois outils sont gratuits et open source, mais “gratuit” ne veut pas dire “sans coût”. Le tableau ci-dessous détaille le coût réel, en temps machine, en compétences requises et en alternatives commerciales pour les équipes qui veulent déléguer.
| Poste de coût | Slither | Mythril | Echidna |
|---|---|---|---|
| Licence logicielle | 0 € | 0 € | 0 € |
| Temps de calcul CI/CD | Négligeable (secondes) | Élevé (minutes à heures par contrat) | Modéré à élevé selon la durée de campagne |
| Courbe d’apprentissage | Faible, usage en ligne de commande | Moyenne, réglages SMT à ajuster | Élevée, écriture d’invariants Solidity |
| Triage des résultats | Modéré (faux positifs à filtrer) | Faible mais résultats plus rares | Faible si invariants bien conçus |
| Alternative commerciale équivalente | Aderyn (gratuit, Rust) ou audits CertiK | MythX (service payant, dérivé de Mythril) | Foundry fuzzing (gratuit, intégré) |
| Audit manuel externalisé (référence marché) | Plusieurs dizaines de milliers de dollars par engagement chez Trail of Bits, OpenZeppelin ou équivalents | ||
Le vrai coût, en somme, se déplace des licences vers l’infrastructure et la compétence humaine. Une équipe qui lance Mythril sur chaque pull request va rapidement saturer ses runners CI si le contrat gagne en complexité, alors que Slither peut tourner à chaque commit sans ralentir le pipeline. Echidna, de son côté, demande un investissement initial pour écrire des invariants pertinents, mais ce travail devient un actif réutilisable à chaque nouvelle version du contrat.
Cinq cas réels où ces outils ont fait la différence (ou ont échoué)
La théorie des trois méthodes est utile, mais rien ne vaut des exemples concrets pour comprendre où chaque outil excelle et où il montre ses limites.
1. Uniswap et Origin Dollar, revues publiques via Echidna. La documentation officielle du dépôt Echidna cite plusieurs revues de sécurité publiques ayant utilisé l’outil, notamment sur Uniswap, Origin Dollar, TokenCard et Advanced Blockchain. Dans ces cas, le fuzzing basé sur les propriétés a permis de tester des invariants économiques complexes (conservation de la valeur dans les pools de liquidité, par exemple) qu’une analyse statique seule n’aurait pas pu vérifier.
2. Le hack Bybit à 1,4-1,5 milliard de dollars, un échec qui n’était pas un problème de smart contract. En février 2025, le groupe Lazarus Group, lié à la Corée du Nord, a dérobé environ 401 347 ETH au portefeuille froid de Bybit via une attaque de la chaîne d’approvisionnement logicielle visant Safe{Wallet}, l’interface multisig utilisée par l’exchange. L’enquête forensique menée par Sygnia et Verichains, relayée par Finance Magnates, a démontré que la faille se situait dans l’infrastructure front-end de Safe, pas dans le bytecode du smart contract lui-même. Cet exemple illustre une limite structurelle : ni Slither, ni Mythril, ni Echidna n’auraient détecté ce vecteur, puisqu’aucun des trois n’audite l’infrastructure web qui sert de couche de signature aux utilisateurs.
3. La faille CVE-2026-40072 dans web3.py. Cette vulnérabilité, répertoriée avec un score CVSS de 7,2 (High) sur OpenCVE, concernait l’implémentation CCIP Read / OffchainLookup (EIP-3668) dans la bibliothèque web3.py, qui permettait à un smart contract malveillant de déclencher des requêtes HTTP vers des URL qu’il contrôlait. Le correctif est arrivé dans les versions 7.15.0 et 8.0.0b2. Ce cas rappelle qu’une partie croissante des risques Ethereum se situe désormais dans les bibliothèques clientes et les standards d’interopérabilité, un périmètre que les trois outils d’audit de contrat ne couvrent pas directement.
4. La détection en amont via Slither dans les pipelines CI/CD. Les guides d’intégration continue publiés en 2026, notamment celui de CloudLogic, décrivent des équipes qui font tourner Slither à chaque pull request pour intercepter les erreurs de contrôle d’accès et les appels delegatecall risqués avant même la revue humaine. La rapidité de l’outil (sous la seconde) permet ce niveau de systématicité, impossible avec Mythril sur le même rythme.
5. La vague de manipulations d’oracle en 2026. Le cabinet TRM Labs a recensé 32 attaques par manipulation de prix en 2026 jusqu’à début septembre, contre 12 sur toute l’année 2025, selon un rapport relayé par Odaily Planet Daily. Ce type d’attaque, qui exploite des oracles de prix insuffisamment décentralisés plutôt qu’un bug de code isolé, échappe largement aux trois outils étudiés ici : ni l’analyse statique, ni l’exécution symbolique, ni le fuzzing d’invariants internes ne modélisent nativement une source de prix externe manipulée. C’est le créneau qu’occupent des plateformes de surveillance on-chain comme Forta ou Blockaid, complémentaires et non substituables aux outils d’audit pré-déploiement.
Comment lire et trier les résultats de chaque outil
Un rapport Slither brut peut afficher plusieurs dizaines d’alertes sur un contrat de taille moyenne, et c’est là que beaucoup d’équipes débutantes se découragent. La bonne pratique consiste à trier par sévérité (High, Medium, Low, Informational) avant tout, puis à ignorer explicitement (via des commentaires // slither-disable-next-line) les faux positifs déjà validés par un humain, plutôt que de les laisser réapparaître à chaque exécution. Un détecteur Slither classé “High” comme la réentrance ou l’auto-destruction non protégée mérite un traitement immédiat, alors qu’un détecteur “Informational” sur le style de code peut attendre une passe de nettoyage ultérieure.
Mythril fonctionne différemment : chaque résultat correspond à un chemin d’exécution concret qui viole une propriété de sécurité, accompagné d’une trace d’appel. Contrairement à Slither, un résultat Mythril n’est presque jamais un faux positif au sens strict, puisque l’outil a effectivement trouvé une entrée qui déclenche le problème. La difficulté n’est pas le tri, mais l’attente : sur un contrat comportant plusieurs boucles et appels externes imbriqués, une analyse Mythril complète peut ne jamais terminer dans un délai raisonnable, ce qui pousse la plupart des équipes à fixer une limite de temps (--execution-timeout) et à accepter une couverture partielle plutôt qu’exhaustive.
Echidna, enfin, ne produit un résultat que lorsqu’un invariant est cassé, ce qui rend chaque alerte de facto critique puisque l’auditeur a lui-même défini la règle censée protéger les fonds ou la logique du contrat. La lecture d’un rapport Echidna se fait donc à l’envers des deux autres outils : au lieu de trier une liste d’alertes par sévérité, l’équipe reçoit une séquence de transactions reproductible qui casse la règle, et doit remonter cette séquence pour comprendre où la logique métier a été mal implémentée. C’est souvent la découverte la plus coûteuse en temps de correction, mais aussi celle qui révèle les bugs les plus dangereux, car elle prouve qu’un scénario réaliste d’attaque fonctionne.
Les outils complémentaires qui montent en 2026
Slither, Mythril et Echidna ne sont plus les seuls noms qui comptent dans l’écosystème de la sécurité smart contract en 2026. Aderyn, un analyseur statique écrit en Rust par Cyfrin, a gagné du terrain en se positionnant sur le même créneau que Slither (vitesse sub-seconde, détecteurs prêts à l’emploi) tout en revendiquant plus de 100 détecteurs et une extension officielle pour VS Code qui affiche les résultats directement dans l’éditeur plutôt que dans un rapport post-hoc séparé. Pour les équipes qui utilisent déjà Foundry comme framework de développement, le moteur de fuzzing intégré à Foundry joue un rôle proche de celui d’Echidna, avec l’avantage de rester dans le même outil que les tests unitaires classiques.
Sur le segment de la surveillance post-déploiement, plusieurs approches coexistent désormais. Les plateformes d’entreprise comme Hypernative et Hexagate combinent une visibilité de niveau SIEM avec une intelligence native à la blockchain, pour détecter en temps réel des schémas d’attaque qui n’existaient pas au moment du déploiement du contrat. Les pare-feux en ligne comme Forta Firewall ou BlockSec interceptent les transactions avant leur inclusion dans un bloc pour bloquer les tentatives d’exploit détectées. Les flux de données en libre-service comme Defimon publient des alertes d’exploit en moins d’une seconde après détection, un délai crucial quand un exploit DeFi peut vider une trésorerie entière en quelques blocs. Cette diversification reflète un constat partagé par l’ensemble du secteur : l’audit pré-déploiement, aussi rigoureux soit-il, ne protège pas contre les attaques qui exploitent l’état du marché ou des dépendances externes après la mise en production.
Un autre développement notable de 2026 concerne les agents de sécurité assistés par intelligence artificielle, conçus pour tourner en continu plutôt qu’en audit ponctuel. Un rapport publié sur Security Boulevard en mars 2026 avance qu’un agent de sécurité IA à vocation spécifique aurait détecté 92 % des vulnérabilités présentes dans un échantillon de contrats DeFi testés, en recommandant d’adopter une sécurité continue assistée par IA intégrée aux pipelines CI/CD et de déploiement, plutôt que des audits ponctuels isolés dans le temps. Ce chiffre, comme tout résultat de ce type, dépend fortement de la composition de l’échantillon testé et mérite d’être interprété avec prudence, mais il confirme la tendance de fond : la frontière entre “outil d’audit” et “surveillance continue” s’estompe à mesure que les délais entre découverte de faille et exploitation se raccourcissent.
Guide de migration : passer d’un audit ponctuel à un pipeline outillé
Pour une équipe qui audite ses contrats manuellement ou pas du tout, voici la marche à suivre pour intégrer les trois outils sans tout casser d’un coup.
- Installer Slither via pip (
pip install slither-analyzer) et le lancer une première fois en local sur la base de code existante pour établir une ligne de base des alertes actuelles. - Trier les résultats Slither par sévérité et corriger d’abord les détecteurs à impact élevé (réentrance, contrôle d’accès, appels externes non vérifiés) avant d’intégrer l’outil en CI/CD.
- Ajouter Slither comme étape obligatoire dans le pipeline CI/CD (GitHub Actions, GitLab CI), en bloquant la fusion si un détecteur critique se déclenche.
- Installer Mythril (
pip install mythril) et le réserver aux contrats les plus sensibles (traitant des fonds utilisateurs, logique de gouvernance) plutôt qu’à l’ensemble du dépôt, pour limiter le temps de calcul. - Lancer Mythril en tâche asynchrone (nightly build ou déclenchement manuel avant mise en production), jamais à chaque commit.
- Installer Echidna et Foundry, puis écrire les premiers invariants métier : conservation du solde total, plafond d’émission, non-négativité des soldes individuels.
- Faire tourner des campagnes Echidna de plusieurs milliers d’exécutions sur les fonctions critiques (retraits, mint, transferts) avant chaque déploiement majeur.
- Documenter chaque faux positif écarté pour éviter que l’équipe ne les redécouvre à chaque itération.
- Externaliser un audit manuel (Trail of Bits, OpenZeppelin, ou équivalent) avant tout déploiement en mainnet gérant des fonds significatifs, en complément et non en remplacement de l’outillage automatisé.
- Mettre en place une surveillance post-déploiement (Forta, Blockaid ou équivalent) pour couvrir les risques que ni l’audit de code ni le fuzzing ne peuvent anticiper, comme la manipulation d’oracle ou le vol de clés d’infrastructure.
Cette séquence reflète directement la conclusion des guides d’audit 2026 consultés pour cet article : la sécurité smart contract n’est pas un choix binaire entre outils, mais un empilement de couches, chacune couvrant un angle mort de la précédente.
Avantages et inconvénients de chaque outil
Slither
Avantages : vitesse d’exécution sous la seconde, intégration native en CI/CD sans surcoût d’infrastructure, plus de 30 détecteurs prêts à l’emploi couvrant les classes SWC les plus courantes, support actif de Trail of Bits avec 48 releases publiées à ce jour, compatible Solidity et Vyper.
Inconvénients : ne prouve jamais qu’une faille détectée est réellement exploitable en conditions réelles, génère des faux positifs qui demandent un triage manuel régulier, et reste aveugle à toute logique métier qui ne correspond pas à un motif de code connu.
Mythril
Avantages : capacité unique à explorer des combinaisons d’entrées inattendues via l’exécution symbolique, détection de chemins d’exploitation que l’analyse statique ne peut pas modéliser, base technique reprise par des services commerciaux comme MythX pour les équipes qui veulent une offre gérée.
Inconvénients : temps d’exécution qui grimpe fortement sur des contrats complexes ou fortement couplés, coût en calcul qui rend une utilisation systématique en CI/CD impraticable, et une convergence qui n’est jamais garantie sur des bases de code volumineuses.
Echidna
Avantages : test d’invariants métier réels plutôt que de motifs de code génériques, débit de plusieurs milliers de transactions testées par seconde, historique d’utilisation sur des protocoles de référence comme Uniswap, intégration fluide avec Foundry.
Inconvénients : ne détecte rien par défaut, l’efficacité dépend entièrement de la qualité des invariants écrits par l’équipe, courbe d’apprentissage plus longue que Slither pour les développeurs qui découvrent le fuzzing basé sur les propriétés.
Erreurs fréquentes quand une équipe combine les trois outils
La première erreur, très répandue chez les équipes qui découvrent l’audit outillé, consiste à lancer Mythril sur l’intégralité du dépôt à chaque commit, exactement comme Slither. Le résultat est prévisible : la pipeline CI/CD se met à durer des heures, les développeurs désactivent l’étape par frustration, et l’outil finit par ne plus tourner du tout. La bonne pratique, décrite plus haut dans le guide de migration, consiste à réserver Mythril aux contrats sensibles et à des déclenchements planifiés, jamais à un usage systématique au rythme du développement quotidien.
La deuxième erreur consiste à écrire des invariants Echidna trop larges ou trop vagues pour être utiles. Un invariant du type “le contrat ne doit jamais planter” ne teste presque rien de spécifique à la logique métier. Les invariants efficaces ciblent des propriétés économiques précises : la somme des soldes individuels égale toujours le solde total du contrat, le ratio de collatéralisation ne descend jamais sous un seuil donné, ou le nombre de tokens en circulation n’excède jamais le plafond fixé dans le contrat. Écrire ces invariants demande une compréhension fine de la logique métier, ce qui explique pourquoi cette étape est souvent confiée aux développeurs du protocole plutôt qu’à un auditeur externe qui découvre le code pour la première fois.
La troisième erreur, plus insidieuse, consiste à traiter un audit “propre” (zéro alerte critique sur les trois outils) comme une garantie d’absence de faille. Les exemples cités plus haut, notamment le hack Bybit et la vague de manipulations d’oracle recensée par TRM Labs, montrent que la majorité des pertes les plus coûteuses de 2026 ne viennent pas d’un bug de code détectable par analyse statique, exécution symbolique ou fuzzing, mais de la couche opérationnelle : infrastructure de signature, gestion des clés, dépendances externes comme les oracles de prix. Un rapport propre sur ces trois outils signifie seulement que le code du contrat lui-même ne présente pas les classes de vulnérabilités qu’ils savent détecter, pas que le système dans son ensemble est sécurisé.
Enfin, la quatrième erreur consiste à sous-estimer le temps de formation nécessaire pour que l’équipe de développement s’approprie ces outils. Slither s’apprend en quelques heures grâce à sa ligne de commande simple et sa documentation. Mythril demande une compréhension minimale de l’exécution symbolique pour interpréter correctement les résultats et régler les paramètres de timeout. Echidna, le plus exigeant des trois, nécessite une vraie montée en compétence sur l’écriture de propriétés testables, souvent accompagnée par la lecture d’exemples publiés par Trail of Bits sur des protocoles réels comme Uniswap. Les équipes qui budgètent ce temps de formation dès le départ obtiennent des résultats bien plus rapidement que celles qui découvrent ces contraintes en cours de route.
Cinq cas d’usage et quel outil choisir
- Startup DeFi en phase de développement rapide, budget d’audit limité : Slither seul, intégré en CI/CD dès le premier commit, complété par un audit manuel externe avant le lancement mainnet.
- Protocole gérant une trésorerie de gouvernance ou un mécanisme de vote : Mythril ciblé sur les fonctions de gouvernance critiques, en tâche planifiée, pour explorer les combinaisons de votes ou de délégations inattendues.
- AMM ou protocole de prêt avec des invariants économiques clairs (conservation de valeur, ratio de collatéral) : Echidna en priorité, avec des campagnes de fuzzing longues sur les fonctions de retrait et de liquidation.
- Équipe d’audit externe facturant un engagement complet : les trois outils en séquence (Slither pour le balayage initial, Mythril pour l’exploration ciblée, Echidna pour la validation des invariants), suivis d’une revue manuelle ligne par ligne.
- Contrat déjà déployé en production, budget de refonte limité : Slither en mode diagnostic ponctuel pour prioriser les correctifs, sans réécriture complète, en complément d’une surveillance on-chain type Forta pour couvrir les risques post-déploiement.
Exemple de commande : lancer les trois outils sur un même contrat
Voici la séquence de commandes type utilisée par une équipe qui veut faire tourner les trois outils sur un contrat Solidity avant une mise en production.
# Analyse statique rapide (quelques centaines de millisecondes)
slither ./contracts/Vault.sol --checklist
# Exécution symbolique ciblée (réservée aux contrats sensibles)
myth analyze ./contracts/Vault.sol --execution-timeout 300
# Fuzzing basé sur les invariants (nécessite un fichier d'invariants dédié)
echidna ./contracts/Vault.sol --contract VaultInvariants --test-limit 50000Cette séquence, du plus rapide au plus coûteux, correspond à l’ordre recommandé par la majorité des guides d’audit 2026 : filtrer vite avec Slither, creuser sélectivement avec Mythril, puis valider les garanties économiques avec Echidna.
Ce que ces outils ne détectent pas
Le rapport 2026 de TRM Labs insiste sur un glissement structurel : les attaquants ciblent de plus en plus la couche opérationnelle (infrastructure de signature, clés privées, ingénierie sociale) plutôt que le seul bytecode du smart contract. Le hack Bybit en est l’illustration la plus coûteuse, avec une faille dans l’infrastructure front-end de Safe{Wallet} plutôt que dans un contrat audité. Un rapport sur les statistiques de la fraude crypto en 2026 va plus loin : 78 % des compromissions de portefeuilles réussies impliqueraient des campagnes d’ingénierie sociale sophistiquées qui manipulent les utilisateurs pour qu’ils révèlent volontairement leur seed phrase, un vecteur totalement extérieur au périmètre de Slither, Mythril ou Echidna.
La manipulation d’oracle, en forte hausse selon TRM Labs (32 attaques en 2026 contre 12 en 2025), échappe également aux trois outils, puisqu’elle exploite une source de données externe plutôt qu’un défaut de code interne. Pour ces angles morts, les équipes sérieuses complètent leur pipeline avec une surveillance on-chain en continu : Forta exploite un réseau décentralisé de plus de 1 000 bots de détection communautaires qui surveillent la mempool et les transactions confirmées, tandis que des plateformes comme Blockaid proposent une découverte automatique de l’écosystème de contrats exposés, un suivi des signaux financiers et de sécurité en temps réel, avec déclenchement d’alertes ou d’actions automatiques en cas d’anomalie.
Verdict : quel outil pour quelle équipe
Sur la base des données rassemblées, aucun des trois outils ne peut être qualifié de “meilleur” dans l’absolu, mais chacun a un domaine de compétence clair, mesurable en données. Slither gagne sur la vitesse (sous la seconde contre plusieurs minutes pour Mythril) et sur l’intégration en CI/CD, ce qui en fait le socle minimum incontournable pour toute équipe, même sans budget d’audit dédié. Mythril gagne sur la profondeur d’exploration de chemins d’exécution complexes, un terrain où l’analyse statique de Slither ne peut techniquement pas aller, au prix d’un temps de calcul qui interdit une utilisation systématique. Echidna gagne sur le réalisme des scénarios testés (jusqu’à 3 000+ transactions par seconde en fuzzing), à condition d’investir le temps nécessaire pour écrire des invariants pertinents, un effort qui devient rentable dès que le contrat gère des fonds significatifs.
Le vrai chiffre à retenir n’est pas un score de performance isolé, mais celui du rapport TRM Labs : 2,87 milliards de dollars volés en 2025 sur près de 150 incidents, avec une sévérité en hausse marquée en 2026 à mesure que les attaquants délaissent le code du contrat pour viser l’infrastructure autour. Autrement dit, Slither, Mythril et Echidna restent nécessaires mais ne suffisent plus seuls. La recommandation qui ressort de l’ensemble des sources consultées pour ce comparatif tient en une phrase : combiner les trois outils pour le code, ajouter une revue manuelle professionnelle avant tout déploiement significatif, et compléter par une surveillance on-chain continue pour couvrir ce qu’aucun outil de pré-déploiement ne peut voir.
Questions fréquentes
Slither, Mythril et Echidna sont-ils vraiment gratuits ?
Oui, les trois sont open source et gratuits à l’usage. Le coût réel se situe dans le temps de calcul (notamment pour Mythril) et dans le temps d’ingénierie nécessaire pour trier les résultats et écrire des invariants pour Echidna.
Faut-il utiliser les trois outils sur chaque projet ?
Pas systématiquement au même rythme. Slither peut tourner à chaque commit sans coût significatif. Mythril et Echidna sont généralement réservés aux contrats sensibles (gestion de fonds, gouvernance) et lancés en tâche planifiée ou avant chaque déploiement majeur, pas à chaque modification mineure.
Ces outils remplacent-ils un audit manuel professionnel ?
Non. Les guides d’audit 2026 consultés pour cet article sont unanimes : un audit sérieux combine outillage automatisé et revue manuelle par des auditeurs expérimentés, en particulier pour tout contrat gérant des fonds utilisateurs significatifs.
Pourquoi le hack Bybit n’a-t-il pas été détecté par ces outils ?
Parce que la faille ne se trouvait pas dans le bytecode d’un smart contract, mais dans l’infrastructure front-end de Safe{Wallet}, le service multisig utilisé pour signer les transactions. Slither, Mythril et Echidna analysent du code Solidity, pas une infrastructure web ou des serveurs de signature.
Qu’est-ce qu’un “invariant” dans le contexte d’Echidna ?
C’est une règle qui doit rester vraie quelle que soit la séquence de transactions exécutées, par exemple “la somme des soldes individuels ne doit jamais dépasser l’offre totale émise”. Echidna génère automatiquement des transactions pour tenter de violer cette règle.
Existe-t-il des alternatives à ces trois outils ?
Oui. Aderyn, un analyseur statique écrit en Rust, propose plus de 100 détecteurs en exécution sub-seconde et gagne en adoption depuis 2026. Foundry intègre également son propre moteur de fuzzing, dans la même famille méthodologique qu’Echidna. Pour la surveillance post-déploiement, Forta et Blockaid occupent un créneau complémentaire, pas substituable.
Quelle est la principale cause de perte de fonds en DeFi en 2026 ?
Les référentiels d’audit 2026 placent la réentrance, les erreurs de contrôle d’accès et les dépassements arithmétiques en tête des classes de vulnérabilités de code. Mais le rapport TRM Labs souligne que la sévérité des pertes en 2026 est de plus en plus tirée par des attaques visant la couche opérationnelle (clés, infrastructure de signature, ingénierie sociale) plutôt que le code du contrat seul.
Combien coûte un audit manuel professionnel en complément de ces outils ?
Les tarifs varient fortement selon la taille et la complexité du contrat, mais un engagement complet auprès d’un cabinet reconnu comme Trail of Bits ou OpenZeppelin se chiffre généralement en dizaines de milliers de dollars, à mettre en balance avec le coût d’un exploit réussi, qui se compte le plus souvent en millions.
