Pour préparer un audit de smart contract, gelez le code sur un commit précis, documentez ce que le système est censé faire, décrivez l'architecture et les rôles privilégiés, livrez une suite de tests qui fonctionne, corrigez ce que les outils automatisés détectent déjà et listez les problèmes que vous connaissez. Un projet bien préparé permet aux auditeurs de consacrer leur temps aux vrais risques plutôt qu'à reconstituer l'intention à partir du code. Il réduit aussi le coût et la durée de l'audit, et rend le rapport plus utile.
Pourquoi la préparation compte
La préparation compte parce que les auditeurs sont payés à la journée : chaque heure passée à comprendre un code non documenté ou à réparer une compilation cassée est une heure de moins consacrée à la recherche de vulnérabilités. Un code mal préparé ne coûte pas seulement plus cher ; à budget égal, il est aussi examiné moins en profondeur.
La préparation pèse également sur le calendrier. Les auditeurs sont souvent réservés plusieurs semaines à l'avance. Si le code n'est pas prêt à la date prévue, le créneau peut être perdu, ou l'audit peut démarrer sur un code qui continue d'évoluer, ce qui fragilise ses conclusions. Notre guide sur le processus d'audit de smart contract décrit chaque étape de la mission qui suit.
Geler le code sur un commit
Le gel du code signifie que les fichiers du périmètre ne changent plus à partir du démarrage de l'audit, et que la revue est rattachée à un commit unique. C'est l'étape de préparation la plus importante.
En pratique :
- choisissez le commit à auditer et transmettez son empreinte (« commit hash ») à l'auditeur avant la date de démarrage ;
- terminez d'abord les fonctionnalités : pas de pull requests ouvertes, de code provisoire ni de commentaires « à faire » sur les chemins critiques ;
- poursuivez tout nouveau développement sur une branche séparée, qui devra être revue plus tard ;
- retirez du périmètre le code mort et les contrats inutilisés, ou excluez-les explicitement.
Le gel du code protège la valeur du rapport : ses conclusions valent pour ce commit, et pour rien d'autre.
Documenter la spécification, l'architecture et les rôles
Avant de commencer, les auditeurs ont besoin de trois éléments écrits : ce que le système doit faire, comment ses contrats s'articulent, et qui détient quels pouvoirs.
Spécification
La documentation indique à l'auditeur ce que le code est censé faire, et c'est le seul moyen de détecter un code qui fait autre chose. Beaucoup de constats graves sont des erreurs de logique : le code s'exécute correctement, mais pas comme prévu.
Une spécification utile couvre :
- la finalité du système et ses principaux parcours utilisateurs, en langage clair ;
- la responsabilité de chaque contrat et ses fonctions publiques et externes ;
- le comportement attendu dans les cas limites : montants nuls, pools vides, état de pause, valeurs maximales ;
- les formules utilisées (frais, intérêts, récompenses, prix), avec leurs unités et le sens des arrondis ;
- les hypothèses sur les systèmes externes : quel oracle, quels standards de token, quelles blockchains.
Les commentaires dans le code (NatSpec en Solidity) complètent la spécification sans la remplacer. Le format importe moins que l'exhaustivité et l'exactitude.
Architecture et rôles privilégiés
Les auditeurs ont besoin d'une vision claire des interactions entre contrats et de qui peut faire quoi. Un schéma simple et une liste des rôles leur épargnent des heures d'analyse.
Décrivez :
- les contrats et la façon dont ils s'appellent, y compris les protocoles externes ;
- chaque rôle privilégié (propriétaire, administrateur, émetteur, pause, mise à jour, automate) et les fonctions qu'il peut appeler ;
- qui détiendra chaque rôle au lancement : une clé unique, un multisig (portefeuille à signatures multiples), un timelock (délai obligatoire avant exécution), un contrat de gouvernance ;
- le caractère évolutif des contrats : lesquels peuvent être mis à jour, selon quel schéma de proxy, et qui autorise une mise à jour ;
- les hypothèses de confiance : ce que les utilisateurs doivent croire que l'équipe ou des tiers ne feront pas.
Les erreurs de contrôle d'accès figurent parmi les causes de pertes les plus fréquentes, et les auditeurs ne peuvent les juger que s'ils connaissent les permissions prévues.
Tests, couverture et analyse statique
Une suite de tests qui fonctionne et une analyse statique propre montrent à l'auditeur que les bases sont couvertes, ce qui lui permet d'aller plus loin.
Tests et couverture
Une suite de tests fonctionnelle montre à l'auditeur comment le système doit se comporter et lui donne une base pour écrire ses propres tests. C'est aussi un signe fort de maturité.
Avant l'audit :
- vérifiez que le projet compile et que tous les tests passent depuis un clone neuf, avec des instructions d'installation écrites ;
- couvrez les parcours principaux et les cas limites, pas seulement le cas nominal ;
- mesurez la couverture des lignes et des branches, et expliquez tout écart important ;
- ajoutez si possible des tests de fuzzing et des tests d'invariants sur la comptabilité centrale ;
- pour les intégrations, prévoyez des tests sur un fork de la chaîne avec les vrais contrats externes lorsque c'est pertinent.
Les tests ne prouvent pas l'absence de bugs, mais un projet bien testé demande en général moins de jours-auditeur, et ses constats sont plus faciles à reproduire et à corriger.
Lancer d'abord l'analyse statique
Lancez les outils d'analyse statique et traitez les avertissements du compilateur avant l'audit, puis corrigez ou documentez tout ce qu'ils signalent. Payer un auditeur pour relever ce qu'un outil gratuit trouve en quelques minutes est un mauvais usage du budget.
Les bonnes pratiques :
- résoudre tous les avertissements du compilateur et utiliser une version récente et figée du compilateur ;
- lancer au moins un analyseur statique et trier chaque résultat : le corriger, ou expliquer pourquoi c'est un faux positif ;
- appliquer un linter et un style de formatage cohérent ;
- supprimer les imports, variables et fonctions inutilisés.
Transmettez ces résultats triés à l'auditeur. Ils montrent ce qui a déjà été vérifié et lui permettent de se concentrer sur les problèmes de fond.
Problèmes connus et déploiement
Deux documents courts complètent la préparation : une liste des problèmes connus et une description du déploiement et de l'administration du système.
La liste des problèmes connus
Listez les limites et les risques que l'équipe connaît et accepte, avec une justification pour chacun. Par exemple : un risque de centralisation pendant les premiers mois, la dépendance à un seul oracle, ou une perte d'arrondi connue sous un certain seuil. Vous évitez ainsi de payer pour des constats que vous connaissez déjà, et vous distinguez clairement les risques qui relèvent de choix de conception.
Le déploiement et l'administration
Fournissez les scripts de déploiement, les paramètres initiaux (frais, plafonds, adresses) et les blockchains visées. Expliquez comment les clés d'administration seront détenues et comment fonctionnent les actions d'urgence (pause, mise à jour, changement de paramètres), y compris le seuil du multisig ou le délai du timelock. De nombreux incidents viennent d'erreurs de déploiement ou de configuration plutôt que du code des contrats. Si les scripts de déploiement font partie du périmètre, indiquez-le explicitement.
Checklist de préparation à l'audit
La checklist ci-dessous résume la préparation. Transmettez-la à l'auditeur avec le dépôt.
- Commit choisi et transmis ; gel du code déclaré sur les fichiers du périmètre
- Fichiers inclus et exclus listés, avec la taille du code
- Spécification décrivant la finalité, les parcours, les cas limites et les formules
- Schéma d'architecture, liste des contrats et de leurs interactions
- Liste des rôles privilégiés, de leurs fonctions et de leurs futurs détenteurs
- Schéma de mise à jour des contrats et autorisation des mises à jour décrits
- Compilation et tests qui passent depuis un clone neuf, avec instructions
- Couverture mesurée ; tests de fuzzing ou d'invariants sur la comptabilité centrale
- Avertissements du compilateur résolus ; analyse statique lancée et triée
- Liste des problèmes connus, avec justifications
- Scripts de déploiement, paramètres initiaux et administration documentés
- Un développeur disponible pour les questions pendant l'audit et pour les corrections
Comment la préparation réduit le coût et le délai
La préparation réduit directement le coût d'un audit, car elle diminue le nombre de jours-auditeur nécessaires. Dans le modèle indicatif du site, le niveau de préparation est un multiplicateur de l'effort : 0,9 lorsque tests et documentation sont bons, 1,0 lorsqu'ils sont partiels et 1,2 lorsqu'ils sont absents. Sans préparation, une revue demande environ un tiers d'effort de plus qu'avec une bonne préparation.
Par exemple, pour un code DeFi de 1 500 nSLOC en Solidity examiné par un auditeur indépendant, le modèle donne environ 6 jours-auditeur avec une préparation partielle, environ 5 avec une bonne préparation et environ 7 sans préparation. Ces fourchettes sont indicatives et issues du modèle public du site ; les devis réels dépendent du périmètre. Vous pouvez tester votre cas avec le calculateur de coût d'audit, et notre guide sur le coût d'un audit de smart contract détaille les autres facteurs.
La préparation réduit aussi les coûts indirects. Un code gelé évite les changements de périmètre et les nouvelles estimations. Une documentation claire limite les faux positifs et rend les constats plus nets. De bons tests accélèrent les corrections et raccourcissent le réaudit, ce qui compte puisque celui-ci représente environ 20 % du prix du premier audit dans le même modèle. Enfin, un projet bien préparé se planifie plus facilement et évite la majoration d'urgence appliquée lorsqu'un audit doit démarrer sous une ou deux semaines.
À retenir
- Gelez le code sur un commit unique avant le démarrage de l'audit : le rapport ne vaut que pour ce commit.
- Donnez aux auditeurs une spécification, une vue d'ensemble de l'architecture et la liste complète des rôles privilégiés, pour qu'ils détectent le code qui ne fait pas ce qu'il devrait.
- Livrez une suite de tests qui passe depuis un clone neuf, et corrigez ce que le compilateur et l'analyse statique signalent déjà.
- Documentez les problèmes connus, le déploiement et l'administration pour ne pas payer des constats que vous connaissez déjà.
- Dans le modèle indicatif du site, une bonne préparation demande environ 25 % d'effort d'audit de moins qu'une absence de préparation, et raccourcit corrections et réaudit.