Audits de smart contracts : comprendre ce qu'on vérifie et comment lire un rapport

"Audité par Trail of Bits." "Sécurisé par Certora." Ces labels sont devenus des arguments marketing aussi courants que les certifications SSL sur les sites e-commerce. Sauf que — et c'est crucial — un audit ne garantit pas l'absence de faille.

Tu l'as probablement remarqué : même les protocoles auditées plusieurs fois par des firmes prestigieuses se font hacker. Euler Finance a perdu 197 millions en mars 2023 après un audit complet. Pourquoi ? Parce qu'un audit est une photographie à un moment T, pas une garantie de sécurité absolue.

Comprendre ce qu'on vérifie réellement dans un audit — et ses limites — est essentiel pour évaluer la sécurité d'un protocole. C'est la différence entre rejeter un projet au prétexte qu'il n'a pas d'audit, et accepter un risque calculé avec les yeux ouverts.

Cet article te guide à travers :

• La mécanique d'un audit smart contract
• Les principales firmes et leurs spécialités
• Les catégories de vulnérabilités qu'on cherche
• Comment décoder un rapport sans background technique approfondi
• Une checklist pour évaluer la sécurité d'un protocole

Qu'est-ce qu'un audit de smart contract ?

Définition formelle

Un audit smart contract est une revue systématique du code par des experts sécurité indépendants, qui cherchent à identifier les vulnérabilités, les logiques défectueuses et les vecteurs d'attaque non anticipés.

Contrairement à un test unitaire (écrit par le développeur lui-même), l'audit est une relecture adversariale : l'auditeur adopte la posture "comment casseriez-vous ce contrat ?"

Ce qu'un audit vérifie réellement

L'auditeur examine :

• La logique du code : Les opérations mathématiques sont-elles correctes ? Y a-t-il des chemins d'exécution qui mènent à des états inconsistants ?
• La conformité aux spécifications : Le code implémente-t-il ce que le protocole a déclaré faire ?
• Les vulnérabilités connues : Reentrancy ? Integer overflow ? Access control faible ? Flash loan attacks ?
• Les patterns d'attaque : Comment pourrait-on exploiter les interactions entre contrats ?
• Les intégrations externes : Comment le protocole appelle-t-il les oracles, les tokens externes, les protocoles partenaires ?

Tout cela avec des outils semi-automatisés (Slither, Hardhat, forge) qui détectent les patterns suspects, et une analyse manuelle approfondie pour les failles logiques complexes.

Ce qu'un audit NE GARANTIT PAS

Ici, les limites sont critiques :

• Absence de toute faille : Un audit ne peut examiner qu'un scope limité, dans une limite de temps. Les bugs complexes logiques passent parfois à travers.
• Sécurité des intégrations futures : Si le protocole intègre un nouvel oracle ou un nouveau token après l'audit, les risques changent.
• Sécurité des comportements économiques : Un audit examine le code, pas les game theory. Un protocole peut être sûr techniquement et désastreux économiquement.
• Protection contre les admin keys compromises : L'audit ne compte pas sur la prémisse que l'équipe est honnête, mais un admin malhonnête peut toujours voler les fonds.
• Failles zero-day : Les nouvelles classes de vulnérabilités découvertes après l'audit ne sont pas couvertes.

Durée et coût typiques

Les auditeurs les plus prestigieux (Trail of Bits, OpenZeppelin) fatiguent leurs ressources et peuvent avoir des délais de plusieurs mois. Les protocoles plus petits utilisent souvent des audits compétitifs (Code4rena) qui coûtent 50 000€–100 000€ mais parallélisent la recherche de bugs.

Les principales firmes d'audit et leurs spécialités

Il n'existe pas de "meilleur" auditeur universel. Chaque firme a des spécialités, des forces et des clients de référence. Voici le panorama des incontournables :

Trail of Bits : la référence du détail technique

Trail of Bits est réputée pour la profondeur de ses audits. Tu trouveras dans leurs rapports des analyses cryptographiques pointues, des investigations sur les intégrations externes et des recommandations architecturales.

Avantage : Très rigoureux, adapté aux protocoles complexes.

Inconvénient : Très cher, délais longs, rapports très techniques (moins accessible aux non-devs).

OpenZeppelin : l'accessible et systématique

OpenZeppelin propose une approche structurée et documentée. Leurs rapports sont clairs, utilisent des catégories de sévérité cohérentes et sont plus accessibles aux non-développeurs.

Avantage : Excellente pédagogie, coût raisonnable.

Inconvénient : Moins approfondi que Trail of Bits sur les sujets vraiment complexes.

Certora : la révolution des preuves formelles

Certora introduit la vérification formelle : au lieu de tester et chercher des bugs manuellement, on écrit des spécifications mathématiques qui prouvent que le code est correct pour tous les cas possibles.

Exemple : au lieu de tester "le swap retourne le bon montant dans 100 scénarios", on prouve formellement "pour tout input valide, la fonction de swap retourne exactement le montant spécifié."

Avantage : Couverture exhaustive, détecte des bugs que l'audit manuel raterait.

Inconvénient : Expensive, requiert une spec très clairement définie, moins utile pour les contrats avec business logic flou.

Halborn et autres : le large spectre

Halborn couvre EVM et Solana, inclut des audits d'infrastructure (DevOps, multi-sig), et propose un diagnostic holiste.

Avantage : Flexibilité, couverture multi-chaînes.

Inconvénient : Moins spécialisé qu'une firme purement EVM.

Code4rena / Sherlock : les audits compétitifs

Au lieu d'une équipe soudée, Code4rena organise des compétitions où des dizaines de whitehats cherchent simultanément des failles, récompensés en tokens ou en stablecoins.

Compétition Code4rena typical :
- Durée : 2–4 semaines
- Récompenses : 50 000€–500 000€ en prix
- Nombre de participants : 50–200 whitehats
- Résultat : 20–80 bugs trouvés (vs. 5–15 en audit traditionnel)

Avantage : Couverture très large (nombreuses paires d'yeux), dynamique communautaire, souvent plus de bugs trouvés.

Inconvénient : Moins profond pour les bugs subtils, pas de garantie de qualité des rapports.

Les catégories de vulnérabilités auditées

Les auditeurs catégorisent les findings par sévérité. Voici le framework standard (inspiré du CVSS) :

Critiques (Critical)

Ces vulnérabilités permettent un vol ou gel direct des fonds, ou compromettent la sécurité du protocole entièrement.

Reentrancy Attacks : Un contrat peut appeler un autre contrat qui lui rappelle avant que l'état interne ne soit mis à jour.

Exemple historique : The DAO (2016). Un attaquant a exploité une reentrancy pour voler 60M$ en ETH. Le fallback function du contrat lui permettait de rappeler withdrawBalance() avant que le solde ne soit décrémenté.

// ❌ DANGEREUX
function withdraw(uint amount) public {
    require(balances[msg.sender] >= amount);
    (bool success, ) = msg.sender.call{value: amount}("");
    require(success);
    balances[msg.sender] -= amount; // État mis à jour APRÈS l'appel externe
}

Si msg.sender est un contrat malveillant, son fallback peut rappeler withdraw() avant que le solde ne soit décrémenté. Résultat : l'attaquant reçoit N fois le montant.

Integer Overflow/Underflow : Avant Solidity 0.8, les entiers enroulaient silencieusement. uint8(255) + 1 == 0.

Exemple : Euler Finance (2023). Une faille d'underflow a permis à un attaquant de drainer le contrat. Même avec Solidity 0.8+, les bugs logiques de ce genre restent possibles avec des opérations plus complexes.

Access Control Missing : Le contrat ne vérifie pas qui appelle une fonction sensible.

// ❌ DANGEREUX
function transferAll(address to) public {
    // Pas de vérification : n'importe qui peut transférer tous les fonds
    token.transfer(to, token.balanceOf(address(this)));
}

Price Oracle Manipulation : Le protocole utilise un oracle de prix (DEX, Chainlink) sans vérification d'intégrité. Un attaquant peut flashloaner massivement et manipuler le prix.

Élevées (High)

Ces vulnérabilités permettent l'extraction de valeur ou mènent à un grief opérationnel sérieux.

Flash Loan Vulnerabilities : Le protocole emprunte sans vérifier qu'il rembourse dans le même bloc. Un attaquant emprunte 1M$ pour 1 seconde, manipule le protocole, rembourse l'emprunt. Coût : quasi zéro.

Logic Errors dans les Calculs Financiers : Erreurs de rounding, divisions tronquées, ordre des opérations incorrect.

Exemple : reward = (deposit rate) / 100 vs. reward = deposit / 100 rate (le deuxième perd de la précision).

Frontrunning / Sandwich Attacks : Quelqu'un voit ta transaction en mempool, place une transac avant toi pour manipuler le prix, puis une après pour bénéficier du changement de prix.

Exemple : Tu swappes 100 USDC pour du USDT. L'attaquant achète 50M$ de USDT juste avant toi (montant limité en liquidity pool), le prix montrera, tu reçois moins, il vend après toi et encaisse le profit.

Signature Replay Attacks : Le contrat accepte une signature sans vérifier un nonce unique ou une chaîne spécifique.

// ❌ DANGEREUX
function permit(address owner, address spender, uint value, bytes memory sig) public {
    address recovered = recoverSigner(owner, spender, value, sig);
    require(recovered == owner);
    allowance[owner][spender] = value;
    // Pas de nonce : la même signature peut être rejouée indéfiniment
}

Moyennes (Medium)

Ces vulnérabilités causent un dysfonctionnement ou une fuite d'information, mais ne sont pas exploitables directement pour le vol.

Denial of Service (DoS) : Une action à bas coût peut paralyser le protocole.

Exemple : Boucle sur un array non borné en fonction qui peut être appelée par quiconque, épuisant le gas.

Timing Attacks : Le temps de validation d'une signature ou d'une condition dépend de données sensibles.

Centralization Risks : L'admin dispose de pouvoirs excessifs (peut minter indéfiniment, mettre en pause les transferts, etc.). Techniquement sûr, mais risqué économiquement.

Faibles (Low) et Informationnelles

• Gas Optimisation : Code inefficace qui coûte plus cher à exécuter.
• Code Style : Pas de vraie faille, juste lisibilité ou maintenabilité.
• Documentation : Fonctions non documentées ou mal expliquées.

Ces catégories n'affectent pas la sécurité, mais sont répertoriées pour l'exhaustivité.

Comment lire un rapport d'audit

Un rapport d'audit solide suit toujours la même structure. Voici comment le décoder :

Structure typique

1. Executive Summary

Résumé exécutif : 1–2 pages. Tu y trouveras :

• Scope de l'audit (quels contrats, version du code)
• Durée et méthodologie utilisée
• Nombre total de findings par sévérité
• Avis global ("protocole sûr sous réserves", "préoccupations sérieuses identifiées", etc.)

2. Scope & Méthodologie

• Liste exacte des fichiers auditées
• Version Git du code (commit hash)
• Période de l'audit (du X au Y)
• Outils utilisés (Slither, Hardhat, etc.)
• Hypothèses de base (e.g., "on suppose que l'admin est honnête")

Important : Vérifie que la version auditée correspond à celle déployée on-chain. Si l'audit porte sur le commit abc123def et le déploiement sur xyz789, c'est un red flag.

3. Findings (le cœur du rapport)

Chaque finding suit un format standardisé :

ID: AUD-07
Sévérité: High
Titre: Absence de vérification du retour de transfert ERC-20
Description: La fonction deposit() appelle token.transfer() sans vérifier le
boolean de retour. Certains tokens non-standard (comme USDT, TUSD) retournent
false au lieu de reverter quand le transfert échoue. Cela permet à un
attaquant de simuler un dépôt sans que les tokens ne soient réellement
transférés.

Impact: Un attaquant peut appeler deposit(1000) sans posséder les tokens.
Il reçoit 1000 shares de la vault, mais la vault reçoit 0 tokens réels.
Lors du prochain retrait, le retrait échouera car la vault n'a pas assez
de fonds.

Code affected:
  File: Vault.sol, function deposit(), line 42

Recommandation: Utiliser SafeERC20.safeTransfer() d'OpenZeppelin, qui
wraps le boolean et reverts sur false :

    import "@openzeppelin/contracts/token/ERC20/utils/SafeERC20.sol";
    using SafeERC20 for IERC20;

    function deposit(uint amount) public {
        IERC20(token).safeTransferFrom(msg.sender, address(this), amount);
        // ...
    }

Statut: Fixed (commit 4a3f2bc, PR #127)

Chaque finding expose :

• ID unique : référence du rapport
• Sévérité : Critical, High, Medium, Low, Informational
• Titre descriptif
• Description détaillée : qu'est-ce qui ne va pas
• Impact : quelles seraient les conséquences d'une exploitation
• Code affecté : le fichier et la ligne exacte
• Recommandation : comment corriger
• Statut : Fixed, Acknowledged, Won't Fix, Partially Fixed

4. Conclusion

Avis final : le protocole est-il utilisable ? Y a-t-il des risques résiduels acceptables ?

Ce qu'il faut regarder en priorité dans un rapport

Si tu dois auditer rapidement un rapport (tu es pressé), concentre-toi sur :

1. Les Critical et High

Combien de findings Critical y a-t-il ? Les protocoles sérieux ont généralement 0–2 Critical. Si tu en vois 5+, c'est une alerte rouge.

Sont-ils tous "Fixed" ? Un "Acknowledged" ou "Won't Fix" pour une vulnérabilité Critical est inacceptable. Sauf cas très rare où l'équipe explique pourquoi le risque est contrôlé.

2. Les "Acknowledged" non corrigés

Un finding "Acknowledged" signifie : l'auditeur a identifié un problème, l'équipe reconnaît l'existence, mais elle choisit de ne pas le corriger. Souvent parce que :

• Le fix casserait la compatibilité backward
• Le coût est disproportionné
• L'équipe accepte le risque

C'est une zone grise. Tu dois comprendre pourquoi c'est non-fixé.

3. Version auditée vs. Version déployée

Descends dans le détail technique :

• Audit : commit a1b2c3d
• Déploiement : commit x9y8z7w

Si ce ne sont pas les mêmes, quelle est la différence ? Une ligne changée ? 500 lignes ? C'est critique.

4. Ancienneté de l'audit

Un audit de 24 mois, c'est presque du vent. Les protocoles évoluent, les vecteurs d'attaque émergent. Un audit de moins de 12 mois depuis le dernier changement majeur, c'est acceptable. Idéalement moins de 6 mois.

5. Nombre total de Medium et Low

Les Medium et Low ne sont pas critiques individuellement, mais 50 findings Medium/Low indiquer un code d'une qualité générale faible. 5–15 est normal.

Interpréter les résultats pour l'investisseur

Tu es investisseur ou product manager, pas auditeur. Comment utiliser les rapports d'audit pour évaluer le risque ?

Checklist : Évaluer la sécurité d'un protocole via ses audits

• [ ] Au moins 1 audit par une firme reconnue ? (Trail of Bits, OpenZeppelin, Certora, Halborn, ou top 10 de Code4rena). Un audit par une firme inconnue n'a pratiquement aucune valeur.

• [ ] Tous les findings Critical et High marqués "Fixed" ? Accepte zéro exception. Si un Critical n'est pas fixé, le protocole n'est pas prêt.

• [ ] La version auditée correspond-elle à celle déployée ? Télécharge le rapport, récupère le commit hash auditée, compare avec ce qui tourne on-chain (via etherscan pour l'EVM). Si ce ne correspond pas, demande à l'équipe pourquoi.

• [ ] L'audit date de moins de 12 mois ? Ou depuis le dernier changement majeur ? Un audit de 3 ans sur un protocole qui change chaque mois est inutile.

• [ ] Y a-t-il un bug bounty actif ? Un protocole sérieux maintient un bug bounty sur Immunefi avec des récompenses significatives (10 000$+ pour un Critical). C'est un sign que l'équipe reste vigilante post-launch.

• [ ] L'équipe répond-elle publiquement aux questions de sécurité ? Sur Discord, Twitter, Github issues ? Une équipe qui ghoste les questions "Is contract X safe?" est suspecte.

• [ ] Y a-t-il plusieurs audits indépendants ? Un audit c'est bien. Deux audits complémentaires (par exemple, Trail of Bits + Certora pour vérification formelle), c'est mieux. Trois, c'est excellent.

• [ ] Les Medium et Low findings sont-ils documentés et justifiés ? Une équipe qui dit "on accepte ce Medium parce que..." est plus rassurante qu'une équipe silencieuse.

Cas d'étude : Comment un bug a échappé aux auditeurs

Petit détour pédagogique. Euler Finance a été auditée complètement avant son hack de 197M$ en mars 2023.

La faille : une fonction interne donateToReserves() pouvait être appelée indirectement via un mécanisme de liquidation. L'attaquant a exploité une underflow complexe dans les calculs de bilan :

1. 1Emprunte 100M$ en DAI (flash loan)
2. 2Dépose le DAI dans Euler
3. 3Manipule les liquidations pour forcer un appel à donateToReserves() avec un montant négatif
4. 4Due à une opération non-protégée : reserves -= negativeAmount → reserves augmente
5. 5Retire plus qu'il n'a déposé

Pourquoi l'audit a raté : La faille combinait plusieurs layers (flash loans + liquidations + calculs d'underflow + interactions entre fonctions). Un audit traditionnel vérifie généralement les fonctions isolément. La faille était dans les interactions entre contrats.

C'est pourquoi la vérification formelle (Certora) aurait potentiellement trouvé ce bug : elle prouve que pour tous les chemins possibles d'exécution, l'invariant "reserves >= 0" tient. Avec une faille comme celle-ci, la preuve formelle échouerait.

Au-delà de l'audit : mesures complémentaires

Un audit n'est qu'une couche de sécurité. Voici ce qui compte aussi :

Bug Bounty

Les protocoles sérieux maintiennent des bug bounties avec des récompenses proportionnées au risque :

• Critical : 50 000$–500 000$
• High : 10 000$–50 000$
• Medium : 2 000$–10 000$

Plus les récompenses sont élevées, plus de whitehats investigueront. C'est une détection continue post-launch.

Multi-sig & Timelock

Un protocole dont l'admin peut changer le taux de commission instantanément, c'est dangereux (même techniquement sûr, c'est un risque économique). Les protocoles DeFi sérieux utilisent :

• Multi-sig : plusieurs signatures requises pour les changements sensibles
• Timelock : les changements doivent être annoncés 48–72h à l'avance

Exemple : MakerDAO utilise une 5-of-9 multi-sig avec un timelock de 4 heures minimum pour les changements critiques.

Upgrade Mechanism

Comment le protocole se met-à-jour ? Via proxy (UUPS, Transparent Proxy)? Via governance? Les upgrades sécurisées permettent de patcher les bugs découverts post-launch sans redéployer entièrement.

Mais les proxies introduisent aussi des risques (storage layout issues). Un audit doit vérifier l'upgrade mechanism.

Assurance

Des protocoles comme Nexus Mutual ou Cover Protocol offrent une assurance "hack" : si le protocole se fait voler, tu es couvert à hauteur de la prime payée.

C'est une couche de risque supplémentaire, pas un substitut à la sécurité.

Ça va plus loin : comment les auditeurs trouvent les bugs

Très rapidement, comment un auditeur pense :

1. Automatisation : Slither scanne pour les patterns connus (appels non-vérifiés, reentrancy, etc.).

2. Code review manuel : L'auditeur lit le code ligne par ligne, annoté les patterns suspects.

3. Fuzzing / Property-based testing : On envoie 10 000 inputs aléatoires et on regarde si l'invariant "totalSupply == sum(balances)" tient toujours.

4. Vérification formelle : On écrit une spécification mathématique du code et on prouve qu'elle est toujours satisfaite (Certora Prover).

5. Threat modeling : On liste les acteurs malveillants (user, attacker, miner, oracle, admin), et on explore chaque vecteur d'attaque.

Les meilleures firmes combinent tous ces angles.

Ressources pour apprendre à lire un audit

Si tu veux devenir fluide en lecture d'audits :

1. 1OpenZeppelin Blog : publie des post-mortems d'audits célèbres avec explications pédagogiques.
2. 2Immunefi : base de données publique des bugs trouvés et récompensés.
3. 3Samczsun's blog : un des top security researchers de DeFi, explique les hacks récents en détail.
4. 4Rekt News : post-mortems des gros hacks, très accessibles.

Conclusion : audit ≠ sécurité absolue

Un rapport d'audit solide est une condition nécessaire (tu ne dois pas toucher à un protocole sans audit) mais pas suffisante pour la sécurité.

Les éléments qui complètent l'audit :

• Ancienneté et réputation de l'équipe
• Transparence des opérations (multisig, timelock)
• Bug bounty actif
• Vérifications post-launch continues

Liens internes CRYPTOBOOST :

• Explore notre [guide des oracles DeFi et risques de manipulation](/defi/oracles-securite)
• Comprendre les [smart contract assurance et multi-sig protocols](/securite/assurance-multisig)
• Approfondis les [stratégies risk management en DeFi](/defi/risk-management)
• Consulte notre [liste des hacks DeFi : lessons learned](/securite/hacks-defi-analysis)
• Découvre [les tokens ERC-20 non-standards et leurs pièges](/evm/erc-20-edge-cases)

Pour investir en confiance en DeFi, combine audit solide + due diligence continue. Un audit date rapidement; ta vigilance, jamais.