Un rapport d'audit propre ne veut pas dire que votre protocole est sûr. Il veut dire qu'un cabinet précis, dans une fenêtre de temps précise, a examiné un périmètre précis. L'écart entre « audité » et « sûr », c'est exactement là que vivent la plupart des exploits.
Voici la checklist qu'on utilise en interne pour mener un Smart Contract Audit, et celle que nous recommandons aux équipes pour évaluer la proposition de n'importe quel auditeur, la nôtre comprise.
1. Le périmètre est écrit avant qu'on lise une seule ligne
La phrase la plus importante de tout rapport d'audit, c'est le scope statement. Lisez-la en premier. Deux fois. Elle vous dit quels contrats, quelles fonctions, quel commit hash, et quelles hypothèses ont été dans le périmètre.
Un périmètre qui exclut le process de déploiement, le chemin d'upgrade, la logique d'initialisation, ou l'intégration avec des protocoles externes est un périmètre qui rate là où les exploits se produisent. Si le scope statement de votre auditeur tient en un paragraphe, c'est un problème.
2. La revue manuelle est le livrable, pas l'outillage
Slither, Mythril et les tests Foundry sont la base. Tout auditeur qui vous présente une sortie d'outil comme livrable vous vend une version chère de ce que vous pouvez lancer vous-même.
Ce que vous payez, c'est des auditeurs seniors qui lisent chaque ligne du code dans le périmètre, avec la logique économique du protocole en tête, à la recherche des patterns que les outils de pattern-matching ne trouvent pas : hypothèses sur les oracles, reentrancy entre fonctions, access control cassé, risques sur le chemin d'upgrade.
3. Le threat modeling se fait avant la lecture ligne à ligne
Un audit sérieux commence par un ou deux jours de non-lecture du code. Les auditeurs construisent un modèle :
- Que fait le protocole, en clair ?
- Qui voudrait l'attaquer, et quelle cible viserait-il en premier ?
- Quels invariants de plus haute valeur, s'ils sont cassés, drainent le protocole ?
- De quelles dépendances (oracles, bridges, autres protocoles) hérite-t-il du risque ?
Ce modèle dirige ensuite la revue ligne à ligne. Sans lui, la revue devient générique et rate les risques propres au protocole.
4. Les invariants sont écrits, pas seulement exécutés
Les invariants Foundry et les propriétés Echidna sont la manière de prouver qu'un contrat se comporte comme prévu sous des conditions qu'aucun humain n'énumère. L'auditeur doit écrire de nouvelles propriétés, pas seulement lancer les vôtres.
Posez la question : quelles propriétés as-tu écrites que nous n'avions pas ? Cette réponse sépare un vrai audit d'un audit-checkbox.
5. Les conditions de flash loan sont testées explicitement
Presque tous les exploits DeFi majeurs depuis 2020 ont utilisé des flash loans pour amplifier une vulnérabilité plus petite. L'audit doit explicitement tester :
- Une séquence d'un seul bloc peut-elle drainer une fonction ?
- Une logique de pricing dépend-elle d'un prix spot que les flash loans peuvent bouger ?
- La fenêtre TWAP est-elle assez longue pour qu'un seul bloc ne puisse pas la manipuler ?
- Les changements d'état d'une même adresse dans un bloc sont-ils bornés ?
Si l'auditeur ne peut pas vous dire qu'il a spécifiquement testé sous conditions de flash loan, l'audit est incomplet.
6. Le chemin d'upgrade est dans le périmètre
La plupart des contrats audités sont upgradeables. La plupart des chemins d'upgrade ont leurs propres contrats privilégiés (proxies, timelocks, gouvernance). Un bug dans le chemin d'upgrade contourne l'audit du contrat d'implémentation.
Vérifiez : qui peut faire l'upgrade, sur quel timelock, avec quelles protections, et le multisig qui contrôle les upgrades est-il dans le périmètre de l'audit ?
7. Les rôles privilégiés sont énumérés et tenus par les bonnes adresses
Pour chaque fonction privilégiée, le rapport doit répondre à : quelle adresse peut l'appeler, et quel type d'adresse est-ce ? Une EOA qui détient le onlyOwner d'un contrat de trésorerie, c'est un finding. Un multisig 2-sur-3 dont tous les signataires sont sur le même fournisseur de hardware, c'est un finding. Un timelock à 30 secondes de délai, c'est un finding.
On couvre ça en profondeur dans la mission Wallet Setup, qui tourne souvent en parallèle de l'audit de contrat.
8. Le re-audit après corrections est dans le contrat
Le rapport que vous publiez, c'est le rapport post-correctifs, pas le rapport des findings initiaux. Assurez-vous que la mission inclut un re-audit du code modifié, pas juste une revue patch-par-patch. Les corrections introduisent régulièrement de nouveaux bugs.
9. Le résumé public vous appartient
Votre communauté demandera à voir le rapport. Négociez en amont qui publie, dans quel format, et selon quel calendrier. Un bon auditeur ne bloque pas la publication une fois les corrections appliquées.
10. L'audit n'est pas la fin
Une fois en mainnet, les disciplines pertinentes sont la Surveillance de wallets sur la trésorerie et les clés admin, un retainer Réponse à incident pour les moments où la première heure compte, et un programme de bug bounty avec des payouts proportionnels à la valeur en jeu.
Si vous lancez un protocole DeFi, les quatre, audit, surveillance, réponse, bounty, sont la base. Tout en dessous, c'est de l'espoir, pas de la sécurité.
Trois questions à poser avant de signer
- Montrez-moi un rapport récent que vous avez écrit. Lisez la qualité d'écriture, la profondeur de description des findings, le re-audit post-correctifs. Le rapport est le livrable.
- Qui spécifiquement va travailler sur la mission ? Les auditeurs seniors sont la valeur. Du staff junior + outillage, ce n'est pas ce que vous payez.
- Quelles sont trois vulnérabilités que vous avez trouvées dans des protocoles similaires au nôtre ? Si la réponse n'est pas spécifique, ils n'ont pas fait ce travail avant.
Les protocoles qui survivent à leur première année sont ceux qui ont traité l'audit comme le début d'une fonction sécurité, pas comme la fin d'une checklist.