Un chiffre résume l’état de la sécurité DeFi en 2026 : 546 millions de dollars volés via des failles de smart contracts, selon le rapport annuel de CoinGecko sur la sécurité crypto. Ce montant ne compte que les bugs de code. En ajoutant le vol de clés et l’ingénierie sociale, certains agrégateurs comme Altfins avancent jusqu’à 840 millions de dollars de pertes DeFi sur l’année. Dans ce contexte, une question revient sans cesse chez les développeurs et les équipes de sécurité : quel langage de smart contract, entre Solidity, Rust et Move, protège le mieux les fonds des utilisateurs ? La réponse n’est pas celle qu’on attend.
Ce comparatif passe en revue les trois écosystèmes qui dominent la DeFi de 2026 : Solidity sur Ethereum et les réseaux compatibles EVM, Rust avec le framework Anchor sur Solana, et Move sur Aptos et Sui. On y croise les chiffres de pertes réelles de l’année, les prix d’audit pratiqués par les cabinets spécialisés, et les classes de vulnérabilités qui reviennent le plus souvent dans les rapports publics. L’objectif : donner aux équipes techniques des bases concrètes pour choisir leur pile, migrer un protocole existant, ou simplement comprendre pourquoi un hack fait la une et pas un autre.
Solidity, Rust et Move : trois philosophies de sécurité pour la DeFi
Les trois langages n’abordent pas la sécurité de la même façon, et c’est précisément ce qui rend la comparaison intéressante. Solidity, conçu pour la machine virtuelle Ethereum (EVM), hérite d’un modèle de stockage par slots et d’un typage relativement permissif. Le langage a onze ans d’existence et le plus grand nombre de développeurs actifs, mais aussi le plus grand nombre d’exploits documentés dans la littérature de sécurité, simplement parce que c’est là que se trouve la majorité de la valeur verrouillée (TVL) en DeFi.
Rust, utilisé via le framework Anchor sur Solana, mise sur son système de propriété (ownership) pour éliminer les corruptions de mémoire comme les use-after-free ou les accès concurrents mal synchronisés. C’est une garantie réelle, mais elle ne couvre qu’une partie du problème. Sur Solana, chaque programme reçoit explicitement la liste des comptes qu’il va manipuler, et c’est au développeur de vérifier que ces comptes appartiennent au bon propriétaire, qu’ils sont correctement signés, et que les adresses dérivées par programme (PDA) ne collisionnent pas. Un rapport cité par webthreeconsulting.com recense huit classes de vulnérabilités propres à ce modèle : signataires manquants, validation de propriété absente, collisions de seeds PDA et confusion de discriminants en tête de liste.
Move, développé initialement par Meta puis repris par Aptos et Sui, introduit un système de ressources typées qui ne peuvent être ni dupliquées ni supprimées accidentellement. Un jeton Move n’est pas un simple entier dans une table de correspondance, comme en Solidity, mais un objet linéaire que le compilateur suit à la trace. Cette propriété élimine une catégorie entière de bugs liés à la duplication d’actifs, mais elle ne protège ni contre un dépassement arithmétique, ni contre une manipulation d’oracle, ni contre une erreur de logique métier. L’incident Cetus sur Sui, détaillé plus bas, le démontre de façon assez brutale.
Solidity et l’EVM : la cible la plus riche reste la plus attaquée
Solidity concentre la plus grande part de la valeur totale verrouillée en DeFi, et logiquement la plus grande part des pertes en dollars absolus. Les classes de bugs qui reviennent le plus souvent dans les rapports d’audit publiés en 2026 restent familières : réentrance, contrôle d’accès défaillant, manipulation d’oracle, erreurs de calcul sur les montants, et problèmes liés à l’upgradeabilité des contrats proxy. Le point commun de ces failles n’est pas que le langage est intrinsèquement cassé, mais que les applications EVM composent souvent de nombreux contrats, tokens, oracles, ponts et appels externes, ce qui multiplie les surfaces d’attaque.
Le cas Truebit illustre ce risque de façon précise. En janvier 2026, le protocole a perdu environ 26,2 millions de dollars à cause d’un dépassement arithmétique dans une courbe de liaison (bonding curve) vieille de plusieurs années, selon Chainalysis. Le contrat n’était ni vérifié publiquement ni audité récemment, ce qui en fait un cas d’école plutôt qu’une preuve que Solidity échoue systématiquement. D’autres incidents EVM de l’année confirment des schémas connus : Aperture Finance a perdu environ 3,2 millions de dollars via un contournement de validation d’entrée sur une fonction transferFrom, et Ekubo environ 1,4 million de dollars à cause d’un callback qui ne vérifiait pas l’identité du payeur.
L’écosystème d’audit autour de Solidity reste de loin le plus mature des trois. C’est aussi celui où des plateformes comme Immunefi, Sherlock et Cantina ont développé des modèles de concours d’audit qui mobilisent des dizaines de chercheurs indépendants sur un même protocole, à un coût souvent inférieur à un audit privé classique. Cette profondeur de marché compense en partie le volume d’attaques, mais ne l’annule pas : en valeur absolue, l’EVM reste la chaîne qui perd le plus d’argent chaque année.
Un point mérite d’être précisé pour les équipes qui déploient sur des réseaux de couche 2 comme Arbitrum, Base ou Optimism : ces chaînes exécutent le même bytecode EVM et héritent donc exactement des mêmes classes de vulnérabilités Solidity. Un audit réalisé pour un déploiement Ethereum ne couvre généralement pas les risques spécifiques au pont entre la couche 1 et la couche 2, ni les délais de finalité propres à chaque rollup. Dans les faits, un protocole multi-chaînes EVM doit donc souvent financer plusieurs revues ciblées plutôt qu’un audit unique supposé couvrir l’ensemble du périmètre.
Rust et Solana : la sécurité mémoire ne suffit pas face au modèle de comptes
Solana a affiché environ 315,1 millions de dollars de pertes au premier semestre 2026, un chiffre tiré à la hausse par un seul incident majeur. En avril 2026, le protocole Drift a perdu près de 285 millions de dollars, mais la cause n’était pas un bug de mémoire en Rust. Les éléments publics pointent vers une opération d’ingénierie sociale attribuée à des acteurs liés à la Corée du Nord, combinée à une compromission d’infrastructure et de clés. Les contrats concernés avaient d’ailleurs été audités. C’est un rappel utile : un hack sur Solana ne démontre pas automatiquement une faille du langage Rust ou du framework Anchor.
Le vrai point de friction sur Solana se situe ailleurs. Chaque programme reçoit la liste des comptes qu’il va lire ou écrire, et rien dans le langage n’oblige automatiquement à vérifier que ces comptes sont légitimes. Un rapport d’audit cité par smartcontractaudit.com recense huit classes de vulnérabilités Anchor qui reviennent le plus fréquemment : vérifications de signataire manquantes, validation de propriété absente, collisions de seeds PDA, bump seeds non canoniques, escalade de privilèges via les invocations inter-programmes (CPI), confusion de discriminants, réinitialisation de comptes et erreurs arithmétiques. Ce sont des erreurs de logique de validation, pas des corruptions de mémoire, ce que le compilateur Rust ne peut pas détecter seul.
Step Finance a payé le prix d’une autre faiblesse en janvier 2026, perdant environ 27,3 millions de dollars après la compromission des clés privées de son portefeuille de trésorerie. Là encore, aucun rapport ne décrit ce vol comme un défaut de Rust : c’est un problème de gestion des clés, identique à celui qui touche aussi l’EVM. Rust réduit bel et bien une classe de défauts d’implémentation, comme les dépassements de tampon ou les accès concurrents mal synchronisés. Mais il ne rend pas un programme Solana sûr par construction face à une logique d’autorisation mal conçue.
// Faille Anchor fréquente : signataire non vérifié
#[derive(Accounts)]
pub struct Withdraw<'info> {
pub authority: AccountInfo<'info>, // pas de contrainte "Signer"
pub vault: Account<'info, Vault>,
}
// Version corrigée : la contrainte Signer force la vérification
#[derive(Accounts)]
pub struct WithdrawSecure<'info> {
pub authority: Signer<'info>,
#[account(has_one = authority)]
pub vault: Account<'info, Vault>,
}Cette différence entre AccountInfo et Signer paraît triviale sur le papier. Dans les faits, c’est l’une des erreurs les plus fréquentes relevées par les auditeurs spécialisés en Anchor, et elle n’a strictement rien à voir avec la sécurité mémoire native de Rust.
La croissance rapide de la valeur verrouillée sur Solana en 2026 change aussi la donne pour les équipes de sécurité. Plus un protocole gagne en liquidité, plus il devient une cible rentable pour un attaquant prêt à investir du temps dans la reconnaissance d’une architecture de comptes complexe. Les équipes les plus prudentes combinent désormais un audit Anchor classique avec une surveillance continue capable de repérer un schéma d’appels CPI inhabituel avant qu’il ne débouche sur un retrait massif, plutôt que de considérer l’audit initial comme une protection définitive.
Move sur Aptos et Sui : la sécurité par la rareté des ressources
Move part d’un principe différent des deux autres langages : un actif numérique est traité comme une ressource linéaire, un objet que le compilateur empêche de dupliquer, de supprimer silencieusement ou de copier par erreur. Ce modèle élimine mécaniquement des bugs qui ont coûté cher en Solidity, comme la frappe de jetons fantômes à cause d’un oubli de contrôle d’accès sur une fonction mint. Les modules Move définissent aussi des capacités explicites, ce qui rend les flux d’autorité plus lisibles pour un auditeur.
Mais cette garantie a des limites claires, et l’incident Cetus en mai 2026 les a révélées à grande échelle. Le protocole, construit sur Sui, a perdu environ 223 millions de dollars à cause d’un dépassement d’entier (integer overflow) dans le calcul des ticks de son market maker à liquidité concentrée. Le système de ressources de Move n’a rien pu faire contre cette erreur : la sûreté des types protège la structure des actifs, pas l’exactitude d’une formule mathématique. C’est l’exemple le plus cité en 2026 pour rappeler que la sécurité des ressources n’équivaut pas à la sécurité du protocole dans son ensemble.
Move reste par ailleurs exposé à la manipulation d’oracle, aux erreurs de capacité mal configurées, et aux erreurs de logique métier classiques qui touchent tous les langages. Son principal atout statistique en 2026 tient aussi à un facteur moins flatteur : l’écosystème Aptos et Sui pèse beaucoup moins en valeur verrouillée que l’EVM ou Solana, ce qui réduit mécaniquement le nombre d’incidents observables. Comparer les totaux de pertes bruts entre écosystèmes de tailles très différentes reste donc une démarche statistiquement fragile.
Un détail technique complique encore la comparaison : Aptos et Sui utilisent chacun leur propre variante du langage Move, avec des bibliothèques standards et des modèles d’objets qui ne sont pas strictement identiques. Un audit réalisé sur un module Aptos ne garantit donc pas automatiquement la sécurité d’un module équivalent déployé sur Sui, même si la syntaxe de base paraît proche. Les équipes qui déploient sur les deux chaînes doivent traiter chaque dialecte comme un écosystème d’audit distinct, avec ses propres spécialistes et ses propres outils de vérification.
Tableau comparatif : les spécifications techniques des trois écosystèmes
| Critère | Solidity / EVM | Rust / Solana (Anchor) | Move / Aptos & Sui |
|---|---|---|---|
| Chaînes principales | Ethereum, Arbitrum, Base, Optimism | Solana | Aptos, Sui |
| Modèle d’exécution | Bytecode EVM, séquentiel | Sealevel (BPF), exécution parallèle | MoveVM, orientée ressources |
| Sécurité mémoire native | Non garantie par défaut | Oui (ownership Rust) | Oui (ressources linéaires) |
| Modèle de données | Stockage par slots, mappings | Comptes externes passés explicitement, PDA | Objets/ressources typés non duplicables |
| Framework principal | Foundry, Hardhat | Anchor | Aptos CLI, Sui Move |
| Vulnérabilité dominante en 2026 | Contrôle d’accès, oracle, callbacks | Signataire/propriétaire manquant, PDA, CPI | Arithmétique, capacités, oracle |
| Protection native anti-duplication d’actifs | Non, logique explicite requise | Non nativement | Oui, par construction |
| Vérification formelle disponible | Certora et outils matures | Outils émergents, moins standardisés | Move Prover natif |
| Profondeur du marché d’auditeurs | La plus large des trois | Moyenne, en croissance rapide | Restreinte, spécialisée |
| Prime de coût d’audit vs Solidity | Référence (0 %) | +20 à 50 % | +20 à 50 % ou plus |
| Incident 2026 représentatif | Truebit, 26,2 M$ | Drift, 285 M$ (clé/ingénierie sociale) ; Step Finance, 27,3 M$ | Cetus, 223 M$ |
| Courbe d’apprentissage pour un développeur web2 | Modérée | Élevée (ownership, lifetimes) | Élevée (paradigme ressources) |
Ce tableau montre une chose importante : aucun des trois écosystèmes ne gagne sur tous les critères. Solidity domine en maturité d’outillage et en taille d’écosystème d’audit, Rust gagne en sécurité mémoire native et en débit transactionnel, Move gagne en garanties sur l’intégrité des actifs. Le choix dépend donc du profil de risque réel du protocole, pas d’un classement universel.
Benchmarks 2026 : qui perd le plus d’argent en exploits ?
Les chiffres de pertes varient fortement selon la méthodologie de chaque agrégateur, et c’est un point que tout article sérieux doit signaler plutôt que masquer. Le tableau suivant croise plusieurs sources publiées en 2026 pour montrer l’ampleur des écarts.
| Source | Périmètre mesuré | Montant 2026 | Observation |
|---|---|---|---|
| CoinGecko, 2026 State of Crypto Security Report | Exploits de smart contracts uniquement | 546 M$ | Exclut le vol de clés et le phishing |
| Altfins.com | Pertes DeFi totales 2026 | 840 M$ | 72 % attribués au vol de clés, pas au code |
| Yellow.com (tracker cité) | Hacks jusqu’à fin juin 2026 | 942 M$ sur 121 incidents | T2 2026 : trimestre le plus actif jamais recensé, 85 incidents |
| Smartcontractaudit.com, rapport S1 2026 | Incidents DeFi du premier semestre | 689 M$ | Détail protocole par protocole et par chaîne |
| Chainalysis | Contrats non vérifiés visés sur 6 mois | 36,7 M$ sur 4 hacks | Sous-catégorie ciblée, pas un total global |
La divergence entre 546 et 942 millions de dollars, ce dernier chiffre provenant d’un tracker cité par Yellow.com, n’est pas une erreur de calcul, c’est une différence de définition. Certains agrégateurs comptent uniquement les bugs de code, d’autres ajoutent le vol de clés, le phishing, et les compromissions d’infrastructure. Cette distinction est centrale pour notre comparatif : si environ 72 % des pertes documentées viennent du vol de clés selon Altfins, alors une bonne partie du débat Solidity contre Rust contre Move porte sur un facteur qui n’explique qu’une minorité des dommages réels. La gestion des clés, via des solutions MPC ou multisig, pèse souvent davantage que le choix du langage sur le risque final d’un protocole.
Cinq failles qui ont marqué 2026, chaîne par chaîne
Pour comprendre concrètement ce que ces chiffres signifient, voici les incidents les plus documentés de l’année, avec leur cause technique réelle plutôt qu’un raccourci de titre.
- Drift Protocol (Solana, Rust/Anchor), avril 2026, environ 285 M$ : ingénierie sociale attribuée à des acteurs liés à la Corée du Nord, combinée à une compromission opérationnelle de clés. Les contrats avaient été audités, ce qui confirme qu’un audit ne protège pas contre une attaque sur les humains.
- Kelp DAO (multi-chaînes via LayerZero), avril 2026, environ 292 M$ : mauvaise configuration d’un vérificateur LayerZero (DVN) et compromission liée au RPC, un problème d’infrastructure de pont plutôt qu’un bug dans un contrat Solidity ou Move spécifique.
- Cetus (Sui, Move), mai 2026, environ 223 M$ : dépassement d’entier dans le calcul des ticks d’un market maker à liquidité concentrée. La preuve la plus citée que le typage ressource de Move ne couvre pas l’arithmétique.
- Truebit (Ethereum, Solidity), janvier 2026, environ 26,2 M$ : dépassement arithmétique dans une courbe de liaison vieille de plusieurs années, jamais auditée publiquement selon Chainalysis.
- Step Finance (Solana, Rust/Anchor), janvier 2026, environ 27,3 M$ : compromission des clés privées de trésorerie, un problème de gestion de clés identique à ceux qui touchent l’EVM.
- Aperture Finance (Ethereum, Solidity), 2026, environ 3,2 M$ : contournement de validation d’entrée sur une fonction
transferFrom. - Ekubo (Ethereum, Solidity), 2026, environ 1,4 M$ : callback qui ne vérifiait pas l’identité réelle du payeur avant d’exécuter une opération.
Sur ces sept cas, trois sont des bugs de code au sens strict (Cetus, Truebit, Aperture Finance et Ekubo relèvent de ce registre), et deux sont des compromissions de clés ou d’infrastructure (Drift, Kelp DAO, Step Finance). Ce ratio confirme la tendance de fond de 2026 : la part des pertes directement causée par une faille de langage ou de compilateur recule, tandis que la part causée par la gestion opérationnelle des accès progresse.
Le prix réel d’un audit : tableau comparatif par langage
La rareté des auditeurs spécialisés en Rust et en Move se traduit directement en facture. Les cabinets ne publient quasiment jamais de grille tarifaire fixe, ils devisent au cas par cas selon la complexité du code et le délai demandé, mais plusieurs guides de marché publiés en 2026 permettent de dégager des fourchettes cohérentes.
| Écosystème | Fourchette de prix 2026 | Durée typique | Base de tarification |
|---|---|---|---|
| Solidity / EVM | 15 000 $ à 200 000 $+, jusqu’à 500 000 $+ pour les audits Tier-1 complexes | 2 à 8 semaines | 5 à 15 $/ligne (Tier-2), 15 à 40 $/ligne (Tier-1) |
| Rust / Solana (Anchor) | 15 000 $ à 120 000 $+, courant entre 30 000 et 120 000 $ | 3 à 5 semaines | Devis par portée, prime de 20 à 50 % vs EVM |
| Move / Aptos & Sui | 30 000 $ à 150 000 $+ | 3 à 8 semaines | Devis par portée, prime comparable ou supérieure à Rust |
| OpenZeppelin (référence Tier-1) | Environ 100 000 à 400 000 $ | 3 à 6 semaines | Devis par engagement |
| Trail of Bits (référence Tier-1) | Environ 60 000 à 400 000 $+ | 6 à 12 semaines | Environ 25 000 $ par ingénieur-semaine |
| Sherlock (modèle concours) | 5 000 $ (ERC-20 simple) à 150 000 $+ (multi-chaînes) | 1 à 4 semaines | Cagnotte financée par le protocole |
| Code4rena (modèle concours) | 10 000 $ à 60 000 $, jusqu’à 80 000 $ pour un protocole mi-complexe | 1 à 4 semaines | Cagnotte distribuée entre chercheurs |
La cause de cette surprime Rust et Move tient moins à la difficulté technique du code qu’à la taille du vivier de spécialistes disponibles. Solidity bénéficie d’un marché d’auditeurs profond et concurrentiel, ce qui maintient les prix de base relativement stables. Pour un protocole Solana ou Move, trouver un auditeur réellement compétent sur Anchor ou sur le Move Prover prend plus de temps, ce qui pousse les cabinets comme CertiK, OpenZeppelin ou Trail of Bits à facturer un délai de réservation plus long et un tarif plus élevé. Les plateformes de surveillance continue post-déploiement, comme Forta, Hypernative ou BlockSec, viennent compléter cet audit ponctuel par une détection en temps réel, un complément de plus en plus recommandé par les équipes de sécurité en 2026.
Qui audite vraiment chacun de ces trois écosystèmes
Tous les cabinets d’audit ne couvrent pas les trois langages avec la même profondeur, et c’est un angle mort fréquent chez les équipes qui choisissent un prestataire uniquement sur sa réputation générale. OpenZeppelin, Trail of Bits et CertiK publient des rapports sur les trois écosystèmes, mais leur historique et leur densité de rapports publics restent nettement plus importants côté Solidity. Sur Solana, des cabinets comme OtterSec et Zellic se sont construit une réputation spécifiquement sur l’audit de programmes Rust/Anchor, avec une connaissance fine du modèle de comptes et des invocations CPI. Côté Move, le marché reste plus restreint, avec un nombre limité de cabinets capables de couvrir à la fois Aptos et Sui avec la même rigueur.
Cette fragmentation du marché explique en partie pourquoi la vérification croisée, un audit mené par un cabinet généraliste suivi d’une revue par un spécialiste de la chaîne cible, progresse chez les protocoles qui gèrent une trésorerie importante. Un rapport d’audit obtenu auprès d’un cabinet qui maîtrise parfaitement Solidity mais découvre Anchor en cours de mission a statistiquement moins de chances de repérer une collision de PDA ou un bump seed non canonique qu’un cabinet spécialisé. Le choix du cabinet compte donc presque autant que le choix du langage lui-même.
Avantages et inconvénients de chaque langage
Solidity
- Avantage : écosystème d’audit le plus profond et le plus concurrentiel, avec des outils matures comme Foundry, Slither et Certora.
- Avantage : la plus grande base de développeurs disponibles, standards ERC largement adoptés et documentés.
- Inconvénient : pas de sécurité mémoire garantie par défaut, surface d’attaque élargie par la composition fréquente de nombreux contrats externes.
- Inconvénient : concentre la plus grande part des pertes en dollars absolus, simplement parce que la TVL y est la plus élevée.
Rust avec Anchor (Solana)
- Avantage : sécurité mémoire native, débit transactionnel élevé grâce à l’exécution parallèle de Solana.
- Avantage : Anchor réduit le code répétitif et peut imposer certaines contraintes de validation par déclaration.
- Inconvénient : modèle de comptes complexe, huit classes de vulnérabilités récurrentes documentées par les auditeurs spécialisés.
- Inconvénient : pool d’auditeurs plus restreint, ce qui allonge les délais et augmente le coût de 20 à 50 % par rapport à l’EVM.
Move (Aptos et Sui)
- Avantage : ressources non duplicables par construction, ce qui élimine une classe entière de bugs liés à la frappe ou à la copie non autorisée d’actifs.
- Avantage : Move Prover intégré pour la vérification formelle native, capacités explicites qui facilitent la lecture des flux d’autorité.
- Inconvénient : écosystème d’auditeurs encore restreint, ce qui pousse les prix vers le haut de la fourchette.
- Inconvénient : n’élimine ni les erreurs arithmétiques, ni la manipulation d’oracle, ni les erreurs de logique métier, comme l’a montré Cetus.
Guide de migration : faire évoluer un protocole d’un langage à l’autre
Porter un protocole de Solidity vers Rust ou vers Move n’est jamais une simple traduction syntaxique. Voici les étapes recommandées par les cabinets spécialisés pour limiter les risques pendant une migration.
- Étape 1 : cartographier les invariants de sécurité existants (qui peut appeler quoi, dans quel ordre, avec quelles garanties) avant de toucher au code.
- Étape 2 : refuser la traduction littérale. Le modèle de comptes de Solana et le modèle de ressources de Move n’ont pas d’équivalent direct en stockage par slots EVM.
- Étape 3 : former ou recruter sur le framework cible spécifique, Anchor pour Solana, ou les CLI Aptos/Sui pour Move, plutôt que de considérer Rust ou Move comme un langage générique.
- Étape 4 : réécrire les tests comme des spécifications de sécurité propres à la nouvelle chaîne, pas comme une copie des tests Solidity existants.
- Étape 5 : construire une check-list des classes de vulnérabilités spécifiques à la chaîne cible (les huit classes Anchor pour Solana, les erreurs arithmétiques et de capacité pour Move).
- Étape 6 : prioriser la vérification formelle sur les modules à forte valeur, trésorerie, oracle, logique de liquidation.
- Étape 7 : lancer un audit mené par un cabinet réellement spécialisé dans l’écosystème cible, pas un généraliste EVM qui découvre Anchor ou Move Prover en cours de mission.
- Étape 8 : déployer sur testnet avec un programme de bug bounty actif avant tout déploiement en production.
- Étape 9 : budgétiser l’audit avec une marge de 20 à 50 % par rapport à l’estimation initiale basée sur l’EVM, pour tenir compte de la rareté des spécialistes.
- Étape 10 : maintenir le contrat Solidity d’origine en parallèle jusqu’à ce que le nouveau système ait traversé un cycle d’audit complet et plusieurs semaines d’activité réelle à faible risque.
Quel langage choisir selon votre cas d’usage
Le choix d’un langage dépend avant tout du profil de risque réel du protocole, de l’équipe disponible, et du budget d’audit. Voici des recommandations concrètes selon les cas d’usage les plus fréquents en 2026.
- Protocole DeFi établi déjà déployé sur Ethereum : rester en Solidity, mais réinvestir dans un audit Tier-1 et dans la vérification formelle des modules critiques (oracle, trésorerie), plutôt que de migrer pour un gain de sécurité incertain.
- Application de trading à haute fréquence ou carnet d’ordres on-chain : Solana/Rust avec Anchor pour le débit de transactions, en budgétisant dès la conception un audit spécialisé sur les comptes et les PDA.
- Tokenisation d’actifs réels (RWA) ou NFT à garanties strictes anti-duplication : Move sur Aptos ou Sui, pour bénéficier des garanties natives de ressources linéaires.
- Startup à budget limité sans expérience Rust ou Move : rester en Solidity et utiliser un modèle d’audit compétitif comme Code4rena ou Sherlock pour maximiser la couverture au meilleur coût.
- Protocole cross-chain avec ponts et oracles multiples : le risque principal vient de l’infrastructure (clés, RPC, vérificateurs de pont), pas uniquement du langage. Prioriser une solution de gestion des clés par MPC avant de choisir le langage du contrat.
- Produit visé par une certification réglementaire européenne : privilégier l’écosystème avec le marché d’audit le plus mature et la meilleure traçabilité de rapports publics, ce qui reste aujourd’hui l’EVM.
- Protocole de restaking ou de dérivés de liquidité à fort effet de levier : quel que soit le langage choisi, consacrer une part significative du budget sécurité à la surveillance en temps réel plutôt qu’à un audit ponctuel unique, car ce sont les protocoles les plus imbriqués qui accumulent le plus de surfaces d’attaque indirectes.
Ce que révèlent vraiment les chiffres de 2026
En rassemblant les données de CoinGecko, Altfins, Chainalysis et smartcontractaudit.com, un constat s’impose : le débat sur le langage le plus sûr occulte souvent le vrai facteur de risque. Selon Altfins, environ 72 % des pertes DeFi documentées en 2026 proviennent du vol de clés et de l’ingénierie sociale, pas d’un bug de compilateur ou d’une erreur de syntaxe. Drift, Kelp DAO et une partie de Step Finance appartiennent à cette catégorie. Les pertes réellement causées par un défaut de code, comme Cetus, Truebit, Aperture Finance ou Ekubo, représentent une part plus restreinte du total, même si elles restent significatives en valeur absolue.
Cela ne signifie pas que le choix du langage n’a pas d’importance. Chaque écosystème a sa classe de bugs dominante, et un auditeur rompu à Solidity n’a aucune garantie de détecter une faille Anchor ou Move s’il ne connaît pas en profondeur le modèle sous-jacent. Les cabinets spécialisés le confirment en facturant une prime de 20 à 50 % pour les audits non-EVM, preuve que le marché reconnaît lui-même cette complexité différenciée plutôt qu’une hiérarchie simple de sécurité. Le même constat s’applique aux protocoles de restaking comme EigenLayer, Symbiotic ou Karak, où la complexité des interactions inter-contrats pèse souvent plus que le langage de base.
L’autre leçon de 2026 concerne le calendrier des attaques. Les données de Coinpaprika montrent que janvier a concentré près de 86 millions de dollars de pertes sur sept incidents distincts, un pic qui coïncide avec la période où de nombreuses équipes réduisent leurs effectifs de surveillance pendant les congés de fin d’année. Truebit et Step Finance appartiennent tous les deux à cette fenêtre. Un protocole qui maintient une astreinte de sécurité allégée pendant les périodes creuses s’expose donc à un risque qui n’a, là encore, rien à voir avec le choix de Solidity, de Rust ou de Move.
Le verdict : quel langage est le plus sûr en 2026 ?
Aucun des trois langages ne mérite le titre de langage le plus sûr dans l’absolu, et c’est précisément la conclusion la plus utile pour une équipe technique. Solidity porte la plus lourde facture en dollars, mais principalement parce qu’il porte aussi la plus grande valeur verrouillée du marché. Rust élimine un vrai problème, la corruption de mémoire, mais déplace le risque vers la validation de comptes et les invocations inter-programmes. Move résout élégamment la duplication d’actifs, mais Cetus a prouvé avec 223 millions de dollars que l’arithmétique reste un angle mort.
Le facteur qui pèse le plus lourd sur la sécurité réelle d’un protocole en 2026 n’est pas le langage choisi, c’est la qualité de la gestion des clés, la profondeur de l’audit réalisé par des spécialistes de l’écosystème cible, et la surveillance continue après déploiement. Pour une équipe qui doit choisir aujourd’hui, le critère le plus fiable reste donc moins “quel langage” que “quel niveau de rigueur opérationnelle l’équipe est-elle prête à financer, quel que soit le langage retenu”.
Questions fréquentes
Quel langage de smart contract est le plus sûr en 2026 ?
Aucun des trois ne l’est de façon absolue. Solidity concentre le plus de pertes en dollars car il porte la plus grande valeur verrouillée, Rust déplace le risque vers la validation de comptes, et Move élimine la duplication d’actifs sans protéger contre les erreurs arithmétiques, comme l’a montré l’incident Cetus.
Rust est-il automatiquement plus sûr que Solidity ?
Non. Rust apporte une sécurité mémoire native qui élimine certains bugs d’implémentation, mais les pertes les plus importantes sur Solana en 2026, comme Drift ou Step Finance, viennent de compromissions de clés ou d’ingénierie sociale, pas de défauts du langage.
Pourquoi les audits Solana et Move coûtent-ils plus cher qu’un audit Solidity ?
Principalement à cause de la rareté des auditeurs spécialisés en Anchor ou en Move Prover. Les guides de marché 2026 estiment cette prime entre 20 et 50 % par rapport à un audit EVM de complexité comparable.
Le piratage de Cetus remet-il en cause la sécurité de Move ?
Il remet en cause l’idée que le typage ressource de Move suffit à garantir la sécurité d’un protocole. La perte d’environ 223 millions de dollars venait d’un dépassement arithmétique dans le calcul des ticks, un bug que le système de ressources ne pouvait pas intercepter.
Combien coûte un audit de smart contract en 2026 ?
Entre 15 000 et plus de 500 000 dollars selon la complexité et le cabinet choisi pour un audit EVM, et généralement 20 à 50 % de plus pour un audit Rust/Solana ou Move/Aptos-Sui de complexité comparable.
Faut-il migrer un protocole Solidity vers Solana ou Aptos pour plus de sécurité ?
Pas uniquement pour la sécurité. Une migration déplace les classes de risques plutôt que de les supprimer, et elle expose le protocole à une période transitoire fragile si elle n’est pas accompagnée d’un audit spécialisé et d’un bug bounty préalable.
Quelle part des pertes crypto en 2026 vient réellement de bugs de code ?
Selon Altfins, environ 72 % des pertes DeFi documentées en 2026 proviennent du vol de clés et de l’ingénierie sociale, le reste étant attribuable à des failles de code au sens strict.
Quels outils de vérification formelle existent pour chaque langage ?
Certora reste l’outil de référence le plus mature pour Solidity. L’écosystème Rust/Anchor dispose d’outils plus récents et moins standardisés. Move intègre nativement le Move Prover, conçu dès l’origine du langage.
