La plupart des utilisateurs DeFi, et un nombre surprenant d'investisseurs, lisent les rapports d'audit de la même manière : ouvrir le PDF, vérifier que le compteur de findings critiques est à zéro, fermer le PDF, conclure que le protocole est sûr.
C'est un filtre utile pour exclure le code non audité. C'est un filtre terrible pour distinguer les protocoles sûrs des non-sûrs.
Voici comment on lit un rapport d'audit de Smart Contract, le nôtre comme celui des autres, quand on fait de la vraie due diligence.
Page 1 : le scope statement
Avant tout finding, avant la cover, trouvez le scope statement et lisez-le. Deux fois.
Un scope statement dit, en termes concrets : quels fichiers Solidity ont été revus, à quel commit hash, par quels auditeurs, sur quelle fenêtre de temps, sous quelles hypothèses tenues constantes.
Les bons listent des fichiers spécifiques avec des compteurs de lignes spécifiques. Les mauvais disent « les smart contracts du protocole ». Si le scope est vague, l'audit est vague. Si le scope est en un paragraphe, l'audit est en un paragraphe.
Vérifiez en particulier :
- Les fichiers dans le périmètre sont-ils ceux réellement déployés ? Comparez au mainnet. Des protocoles auditent parfois une branche et livrent une autre.
- Le chemin d'upgrade est-il dans le périmètre ? Un protocole dont l'implémentation est auditée mais pas le proxy est un protocole où l'admin peut swap du code non audité à volonté.
- La configuration de déploiement est-elle dans le périmètre ? Mauvais arguments de constructor, mauvais owner initial, mauvaise adresse d'oracle, ça a déjà perdu de l'argent et ça vit en dessous de la logique du contrat.
- Les intégrations sont-elles dans le périmètre ? « Nous avons supposé que le feed Chainlink est correct » est une vraie hypothèse ; sa pertinence dépend de comment le protocole l'intègre vraiment.
Un scope statement qui énumère explicitement les exclusions est le signe d'un audit sérieux. Un scope qui agite les mains est le signe d'un document marketing.
Page 2 et au-delà : pas que les criticals
Chaque rapport classe les findings par sévérité : critical, high, medium, low, informational. La plupart des lecteurs se concentrent sur critical et high.
Le signal est souvent dans les mediums.
Les findings de sévérité moyenne, ce sont ceux que les auditeurs ont jugés réels mais sans exploit concret encore. Ce sont des patterns de reentrancy peut-être exploitables selon l'intégration. Ce sont des hypothèses sur les oracles peut-être fausses sous des conditions jugées peu probables. Ce sont des patterns d'access control peut-être contournables dans un upgrade.
Un protocole avec cinq findings medium, tous adressés par « ack, we won't fix because we believe the impact is limited », c'est un protocole différent de celui où les cinq mediums ont été patchés. Le second est plus prudent ; le premier prend des paris que vous n'avez peut-être pas pris.
Lisez les réponses de l'équipe aux mediums et aux informationals. Le pattern des réponses vous dit comment l'équipe pense la sécurité. « Will fix » est une réponse mature. « Disagrees » sans justification l'est moins. Les deux sont valides dans certains contextes ; la texture compte.
Le re-audit post-correctifs
Un rapport de premier draft est intéressant ; un re-audit post-correctifs est ce que vous voulez réellement lire.
Le rapport de premier draft décrit le code tel qu'il était quand l'audit a commencé. L'équipe applique des correctifs. Le re-audit décrit le code tel qu'il est quand l'équipe compte déployer. Les findings du premier draft devraient majoritairement dire « Fixed in commit X » ou « Acknowledged, not fixing for reason Y ».
Si le protocole publie le rapport de premier draft mais pas le re-audit, vous lisez du marketing, pas de la sécurité. Si le re-audit montre de nouveaux findings introduits par les corrections, c'est aussi de l'information utile, les corrections introduisent régulièrement de nouveaux bugs.
Ce que le rapport ne peut pas vous dire
Les rapports d'audit sont bornés par leur périmètre, ce qui veut dire qu'ils sont silencieux sur beaucoup de risques :
Sécurité opérationnelle. Le contrat le plus sûr du monde est exploitable si l'EOA de deployer a sa clé privée dans une sauvegarde Discord. Les audits ne vérifient pas ça. On le fait dans Wallet Setup et en Wallet Surveillance continue.
Design économique. Si la tokenomics rend le protocole stable, si les incentives LP créent de la liquidité durable, si le mécanisme de staking est compatible avec les incentives, ce sont des questions économiques, pas des questions de bug. Un protocole sans findings peut quand même mourir d'un mauvais design.
Dépendances externes. Les rapports disent souvent « on a supposé que Chainlink fonctionne correctement », « on a supposé que le protocole de prêt intégré se comporte comme documenté », « on a supposé que le bridge X est honnête ». Ces hypothèses sont de vrais risques, juste pas dans le périmètre de l'audit.
Le prochain déploiement. Un audit au commit 0xabc n'est pas un audit au commit 0xdef. Les protocoles qui livrent en continu doivent avoir une revue continue, pas des snapshots annuels. Bug bounties et hygiène de revue de code sont la couche manquante.
Trois signaux d'un audit sérieux
Au-delà du scope, trois signaux suggèrent un audit sérieux :
1. Les findings incluent des choses que vous ne comprenez pas
Un audit sérieux fait remonter des problèmes qui demandent de la connaissance de domaine. Si vous lisez le rapport et que chaque finding est intuitivement évident, l'auditeur n'a probablement pas cherché très fort. Les vrais findings impliquent souvent des variantes spécifiques de reentrancy, de la manipulation d'oracle sous conditions de flash loan, du replay de signature entre forks, des cas limites spécifiques à des EIPs. Ils prennent un paragraphe à expliquer.
2. Les recommandations sont spécifiques
« Add input validation » n'est pas une recommandation. « Add require(amount > 0 && amount <= MAX_AMOUNT) au début de deposit(), avec revert reason INVALID_AMOUNT, et émettre un event d'erreur correspondant » l'est. Un rapport plein de recommandations vagues est un rapport d'auditeurs qui n'ont pas engagé avec le code.
3. Les auditeurs sont nommés avec bios
La cover liste « John Smith, Senior Auditor, [profil] », pas « Audit Team ». Les auditeurs nommés ont des rapports antérieurs sous leur nom et un track record de findings en production. Si le rapport est anonyme, le cabinet cache soit du staff junior, soit l'absence de staff.
Trois signaux d'un audit léger
À l'inverse, signes que l'audit n'a peut-être pas fait grand-chose :
- Pas de findings ou seulement des informationals. Le vrai code a de vrais problèmes. Un rapport propre sur un protocole complexe veut dire soit que le code est exceptionnel (rare), soit que les auditeurs n'ont pas cherché fort (courant).
- Une fenêtre d'engagement courte. Un audit de 5 jours sur un codebase de 5 000 lignes, c'est une revue de code, pas un audit. Le travail de revue scale avec la complexité, pas avec le calendrier de l'auditeur.
- Le même cabinet audite tout le monde, à chaque fois. Les cabinets à pipeline sans fond livrent souvent du travail superficiel. Les vraies équipes ont des contraintes de capacité.
Quoi faire du rapport
Lire un rapport ne rend pas un protocole sûr d'usage. Il vous dit ce que vous pouvez croire raisonnablement à propos d'un commit spécifique à un moment spécifique.
Combinez avec :
- Un bug bounty avec un payout proportionnel à la valeur en jeu.
- Un monitoring continu du comportement on-chain réel et des clés admin.
- Un plan de réponse à incident pour les bugs que personne, ni les auditeurs, n'a trouvés.
Ce sont les trois jambes d'une posture de sécurité. L'audit est une jambe. Un rapport sans les deux autres, c'est un rapport sans jambes.
Les protocoles qui survivent à leur première année sont ceux qui lisent leur rapport d'audit comme on lit n'importe quel rapport d'expert : avec une attention complète à ce que le rapport couvre, et à ce qu'il ne couvre explicitement pas.