Risques et Sécurité

Audit

Audit de Smart Contract

Revue de sécurité du code de smart contract pour identifier les vulnérabilités

Définition

Un audit de smart contract est une revue de sécurité menée par un cabinet spécialisé sur un périmètre de code et à une date donnés. L'auditeur lit le code, modélise les scénarios d'attaque, teste les hypothèses économiques et publie un rapport classant les problèmes par sévérité, du critique à l'informatif. C'est utile et c'est très largement survendu : un audit ne prouve pas l'absence de faille, il réduit la probabilité qu'une faille connue subsiste. Des protocoles audités par les meilleurs cabinets ont été vidés, souvent parce que la vulnérabilité se trouvait hors périmètre, dans un oracle, dans une dépendance externe ou dans du code déployé après l'audit. Le badge « audité par X » affiché sur une page d'accueil n'a donc aucune valeur informative en soi : seul le rapport, sa date, son périmètre et le suivi des corrections en ont.

Un audit, c'est un cabinet qui relit le code à un instant donné et publie ce qu'il a trouvé. Cela réduit le risque, cela ne le supprime pas, et beaucoup de protocoles audités ont été vidés.

Exemple

Un rapport typique liste par exemple deux points critiques, trois majeurs et une dizaine de points mineurs, avec pour chacun la réponse de l'équipe : corrigé, atténué, ou « risque accepté ». Cette dernière mention mérite une lecture attentive, car elle signifie que l'équipe a choisi de vivre avec le problème. Le cas Euler en mars 2023 est instructif : le protocole avait été audité plusieurs fois, et l'exploit à 197 M$ portait sur une fonction ajoutée après les audits, dont un détail de vérification de santé avait été omis. Le code audité était propre ; celui qui a été exploité ne l'était pas.

Comment ça marche

L'auditeur examine un périmètre de contrats défini, classe les vulnérabilités par sévérité, et l'équipe corrige, atténue ou accepte chaque point. Le rapport final est public, y compris les points non corrigés.

Pourquoi c'est important

Le label « audité » sert massivement d'argument commercial, alors que sa valeur réelle dépend du périmètre, de la date, du cabinet et du suivi des corrections.

À vérifier

Vérifiez la date et le périmètre, comparez les contrats audités aux contrats déployés, lisez la réponse de l'équipe sur chaque point critique, et regardez la section centralisation ainsi que l'existence d'un bug bounty actif.

Risques à considérer

Un audit ne couvre qu'un instantané du code : tout déploiement ultérieur repart de zéro en matière de garanties
Le périmètre exclut souvent les oracles, les dépendances externes et les hypothèses économiques, qui sont précisément les vecteurs les plus fréquents
La qualité varie énormément d'un cabinet à l'autre, et certains signent des rapports complaisants pour des projets qui paient bien
Le label rassure l'utilisateur et sert d'argument marketing, ce qui crée un faux sentiment de sécurité mesurable dans les flux de dépôt

Questions fréquentes

Comment lire un rapport d'audit utilement ?

Commencez par le périmètre et la date, puis comparez le hash des contrats audités à ceux réellement déployés. Lisez ensuite les points critiques et majeurs et surtout la réponse de l'équipe : « corrigé » et « risque accepté » ne sont pas la même chose. Terminez par les sections sur la centralisation, qui listent en général les pouvoirs d'administration, c'est-à-dire ce qu'une clé compromise permettrait de faire.

Plusieurs audits valent-ils mieux qu'un seul ?

Oui, à condition qu'ils soient réalisés par des cabinets différents et qu'ils couvrent des périmètres complémentaires, car chacun a ses angles morts. Mais la meilleure garantie n'est pas un nombre d'audits : c'est la combinaison d'un bug bounty généreux et actif, d'un historique long avec une valeur importante sécurisée, et d'un timelock qui laisse le temps de réagir. Le temps reste le test le plus honnête qu'un contrat puisse passer.

Un protocole non audité est-il forcément à éviter ?

Pas mécaniquement, mais il faut traiter le dépôt comme du capital à risque total. Un fork bien connu d'un contrat éprouvé, déployé sans modification, est moins risqué qu'un code original audité à la va-vite. Regardez ce qui a été changé par rapport à l'original, qui détient les clés d'administration, et dimensionnez la position en fonction de ce que vous pouvez perdre entièrement.