Un audit de smart contract suit une séquence bien établie : le périmètre est figé sur un commit précis, les auditeurs examinent le code manuellement et avec des outils automatisés, ils remontent des constats classés par sévérité, le développeur les corrige, puis l'auditeur vérifie les corrections avant d'émettre un rapport final. Pour un code de taille petite à moyenne, la revue dure en général d'une à trois semaines, auxquelles s'ajoutent le temps des corrections et du réaudit.
Vue d'ensemble du processus d'audit
Le processus d'audit comporte neuf étapes, et le client a un rôle dans chacune d'elles.
| Étape | Pilotée par | Ce que fait le client |
|---|---|---|
| 1. Périmètre et commit | Client et auditeur | Définit les fichiers audités, gèle le code, transmet le commit |
| 2. Réunion de lancement | Auditeur | Présente la conception aux auditeurs et répond à leurs questions |
| 3. Revue manuelle | Auditeur | Reste disponible, ne modifie pas le code audité |
| 4. Analyse automatisée | Auditeur | Fournit une suite de tests fonctionnelle et les instructions de compilation |
| 5. Constats et sévérité | Auditeur | Lit les premiers constats, demande des précisions |
| 6. Remise du rapport | Auditeur | Examine le rapport provisoire avec le développeur |
| 7. Corrections | Développeur | Priorise les corrections, relie chaque constat à un commit |
| 8. Réaudit | Auditeur | Transmet les commits de correction et une réponse par constat |
| 9. Rapport final et publication | Auditeur et client | Décide de la publication, relie le rapport au code déployé |
Périmètre et lancement
L'audit commence par deux étapes de préparation : s'accorder sur le code exact à examiner, puis expliquer aux auditeurs son fonctionnement.
Étape 1 : le périmètre et le commit de référence
Le périmètre définit exactement le code que l'auditeur va examiner, et il est rattaché à un commit unique, identifié par son empreinte (le « commit hash »). Il précise le dépôt, les fichiers et contrats inclus, les fichiers explicitement exclus (tests, mocks, bibliothèques tierces) et la taille du code, généralement mesurée en nSLOC (lignes de code normalisées).
À ce stade, le client doit :
- transmettre le dépôt et le commit exact à auditer ;
- décréter un gel du code (« code freeze ») sur les fichiers du périmètre ;
- fournir la spécification, les notes d'architecture et la liste des rôles privilégiés ;
- signaler les intégrations externes (oracles, bridges, autres protocoles) et le caractère évolutif des contrats, qui élargissent la revue.
Le périmètre détermine le devis. Le modifier en cours d'audit entraîne une nouvelle estimation, un décalage, ou les deux. Notre guide pour bien préparer un audit de smart contract détaille cette préparation.
Étape 2 : la réunion de lancement
La réunion de lancement permet à l'équipe de développement d'expliquer le système aux auditeurs avant le début de la revue. Elle dure souvent une à deux heures et couvre la finalité du protocole, les hypothèses de confiance, les rôles et les zones jugées les plus sensibles.
Venez-y avec au moins un développeur qui connaît le code en profondeur, et convenez d'un canal pour les questions pendant la revue. Un lancement clair fait gagner du temps aux auditeurs, et c'est ce temps que vous payez.
Étapes 3 et 4 : revue manuelle et outils automatisés
Le cœur d'un audit est la revue manuelle par des auditeurs expérimentés, complétée par des outils automatisés qui couvrent ce que l'humain fait moins efficacement.
La revue manuelle
Les auditeurs lisent le code ligne par ligne pour trouver comment le détourner. Ils confrontent la logique métier à la spécification, examinent le contrôle d'accès, la gestion des appels externes et de la réentrance, les hypothèses sur les prix et les oracles, l'arithmétique et les arrondis, les mécanismes de mise à jour et les incitations économiques de chaque acteur. C'est là qu'apparaissent les erreurs de logique, rarement détectées par les outils.
Les outils automatisés
Les auditeurs combinent généralement plusieurs techniques :
- l'analyse statique : des outils parcourent le code à la recherche de schémas de vulnérabilités connus et de mauvaises pratiques ;
- le fuzzing : les contrats sont appelés avec un grand volume d'entrées aléatoires ou semi-aléatoires pour faire apparaître des états imprévus ;
- les tests d'invariants : l'auditeur écrit des propriétés qui doivent toujours être vraies (par exemple, les dépôts couvrent la totalité des sommes dues) et tente de les mettre en défaut ;
- la vérification formelle, dans certaines missions : une preuve mathématique que des propriétés précises sont respectées. Plus coûteuse, elle est en général réservée aux composants critiques.
Pendant cette phase, le client répond rapidement aux questions et ne modifie pas le commit audité.
Constats, sévérité et rapport
La revue produit une liste de constats classés par sévérité, remise dans un rapport provisoire que le client et le développeur examinent ensuite.
Étape 5 : les constats et leur sévérité
Chaque problème identifié est consigné sous forme de constat (« finding ») avec une description, sa localisation dans le code, son impact, une recommandation et un niveau de sévérité. La sévérité combine l'impact d'une exploitation et sa probabilité.
Les niveaux usuels sont :
- Critique : perte ou blocage direct de fonds, ou prise de contrôle du système, avec un scénario d'exploitation réaliste.
- Élevée : perte ou perturbation importante dans des conditions plausibles.
- Moyenne : impact limité, ou impact important mais soumis à des conditions inhabituelles.
- Faible : problèmes mineurs, écarts aux bonnes pratiques à faible impact.
- Informative : qualité du code, documentation, optimisation du gas.
Les constats importants sont souvent communiqués dès leur confirmation, parfois avec une preuve de concept : lisez-les sans attendre.
Étape 6 : la remise du rapport
À la fin de la revue, l'auditeur remet un rapport d'audit provisoire. Il contient en général le périmètre et le commit de référence, la méthodologie, une synthèse par sévérité et le détail de chaque constat.
Le client et le développeur l'examinent, confirment ou contestent chaque constat et décident de son traitement : corrigé, partiellement corrigé, ou reconnu (risque accepté en connaissance de cause, avec une justification).
Corrections, réaudit et rapport final
Après le rapport, les rôles se séparent : le développeur corrige, l'auditeur vérifie, et le rapport final consigne le résultat.
Étapes 7 et 8 : corrections et réaudit
Le développeur corrige les constats, puis l'auditeur vérifie les corrections lors d'un réaudit. Ce sont deux rôles distincts : l'auditeur n'écrit pas les corrections, et le développeur ne les valide pas.
Pour les corrections, le client veille à :
- traiter d'abord les constats critiques et élevés, sans mélanger corrections et nouvelles fonctionnalités ;
- relier chaque constat à un commit ou à une pull request précise ;
- rédiger une courte réponse par constat expliquant ce qui a changé, ou pourquoi le risque est accepté ;
- ajouter des tests qui reproduisent chaque problème corrigé.
Lors du réaudit, l'auditeur examine l'écart entre le commit audité et le commit de correction, vérifie que chaque correction règle le problème sans en créer un nouveau et met à jour le statut de chaque constat. Plus court que la première revue, il n'est pas gratuit : dans le modèle indicatif du site, il représente environ 20 % du prix du premier audit.
Étape 9 : le rapport final et sa publication
Le rapport final consigne le statut de chaque constat après le réaudit et identifie le commit exact qui a été examiné. Le client décide ensuite de sa publication. La publication est courante pour les projets qui détiennent des fonds d'utilisateurs.
Avant de publier, assurez-vous que le code déployé correspond bien au commit final audité, et indiquez-le clairement. Un rapport sur un autre commit que celui déployé sur le mainnet donne une assurance trompeuse.
Combien de temps dure un audit de smart contract
La durée dépend surtout de la taille et de la complexité du code, du nombre d'auditeurs et du niveau de préparation du projet. Dans le modèle indicatif du site, un code DeFi de 1 500 nSLOC en Solidity représente environ 6 jours-auditeur avec un auditeur indépendant, ou environ 8,5 jours-auditeur (deux semaines environ) avec un cabinet établi. Un code DeFi de 5 000 nSLOC demande environ trois semaines avec deux auditeurs. Les petits contrats de token relèvent de la mission minimale de 3 jours-auditeur.
Il faut y ajouter le délai de réservation (souvent plusieurs semaines), le temps des corrections et le réaudit. Ces fourchettes sont indicatives (modèle public du site) ; les délais réels dépendent du périmètre. Pour des chiffres adaptés à votre projet, consultez notre guide sur le coût d'un audit de smart contract ou le calculateur de coût d'audit.
Ce qu'un audit garantit et ne garantit pas
Un audit réduit le risque, il ne le supprime pas. C'est une revue limitée dans le temps, sur un commit précis, dont la valeur dépend du périmètre, du temps accordé et de la préparation.
Un audit permet de :
- identifier des vulnérabilités et des faiblesses de conception dans le code du périmètre ;
- obtenir un avis indépendant sur le code à un commit donné ;
- recevoir des recommandations et faire vérifier les corrections lors du réaudit.
Un audit ne permet pas de :
- garantir l'absence de bugs ni la sécurité des fonds ;
- couvrir le code hors périmètre, les modifications ultérieures ou d'autres déploiements ;
- couvrir les composants hors chaîne, la gestion des clés ou la sécurité opérationnelle, sauf inclusion explicite ;
- valider la solidité économique du modèle, sauf si la mission le prévoyait.
C'est pourquoi de nombreuses équipes y ajoutent des tests étendus, un bug bounty (récompense pour la découverte de failles) après le lancement, une surveillance, un multisig et un timelock sur les fonctions d'administration. L'indépendance compte aussi : la société qui a écrit le code ne devrait pas l'auditer. C'est une règle sur smart-contract.com, où une société engagée pour développer un projet ne peut jamais être retenue pour son audit ou son réaudit.
À retenir
- Le processus d'audit va du périmètre figé sur un commit jusqu'au rapport final sur le code corrigé, avec la revue manuelle au centre et les outils automatisés en appui.
- Le client intervient à chaque étape : préparation du périmètre, réunion de lancement, réponses aux questions, corrections et documentation de chaque correction.
- Le développeur corrige les constats et l'auditeur les vérifie lors du réaudit, estimé à environ 20 % du premier audit dans le modèle indicatif du site.
- La revue dure de quelques jours pour un petit contrat à plusieurs semaines pour un code DeFi important, sans compter la réservation, les corrections et le réaudit.
- Un audit réduit le risque sur un commit précis ; il ne garantit pas l'absence de bugs.