Le rapport d'audit de smart contract est la sortie écrite d'un audit. C'est le document que votre communauté, vos investisseurs et (parfois) vos régulateurs vont lire pour décider si le protocole est sûr à utiliser.
Un rapport crédible contient :
- Un scope statement : quels contrats, quel commit hash, quelles fonctions, et ce qui était hors périmètre. Lisez ça en premier. La plupart des post-mortems d'exploit retracent à quelque chose que l'audit avait explicitement exclu.
- Une section méthodologie : revue manuelle par des auditeurs seniors nommés, l'outillage automatisé utilisé (Slither, Mythril, Echidna, invariants Foundry), et le threat model construit par les auditeurs.
- Les findings, classés critique → haut → moyen → bas → informationnel, chacun avec : description, impact, scénario d'attaque, référence au code, justification de la sévérité, recommandation de remédiation, et un champ statut mis à jour après le re-audit.
- Les résultats du re-audit : quels findings ont été corrigés, lesquels partiellement, lesquels acceptés comme risques hors périmètre.
- Un executive summary pour les décideurs non techniques.
Trois signaux de qualité à vérifier :
- Des findings spécifiques, pas des recommandations génériques de best-practice.
- Du code de proof-of-concept pour les findings de haute sévérité.
- Une section résumé public que le protocole peut publier. Les auditeurs crédibles ne bloquent pas ça.
Lire un rapport d'audit avec esprit critique est une compétence : voir notre guide sur comment en lire un sans se faire avoir.