Smart Contract Audits: What Auditors Check—and What an Audit Does Not Guarantee

Un audit de smart contract est un examen indépendant du code et de l’architecture dans un périmètre défini. Il vise à identifier les vulnérabilités, les erreurs d’implémentation et les écarts entre le comportement prévu et le comportement réel.

Un audit peut réduire l’incertitude, mais il ne rend pas un contrat exempt de risque. Les recommandations officielles de sécurité d’Ethereum présentent les audits comme un examen supplémentaire, et non comme une solution miracle capable de détecter tous les bugs.

Cet article est fourni uniquement à des fins pédagogiques. Un audit ne garantit ni la sécurité, ni la récupération des fonds, ni un rendement.

Le périmètre est prioritaire

Un rapport utile indique précisément ce qui a été examiné :

• dépôt et hash du commit ;
• fichiers et contrats ;
• version du compilateur et paramètres de compilation ;
• dépendances ;
• architecture et rôles privilégiés ;
• branche ou version ;
• exclusions, limites et hypothèses ;
• date de l’examen.

Ce point est important, car même un audit authentique peut porter sur une ancienne version, un autre déploiement ou seulement une partie d’un système plus vaste.

Ce que les auditeurs examinent généralement

1. Comportement prévu et invariants

Les auditeurs comparent le code à sa spécification :

• qui peut appeler chaque fonction ;
• méthode de calcul des montants et des frais ;
• quand les changements d’état se produisent ;
• quelles propriétés doivent toujours rester valides ;
• gestion des cas limites et des défaillances.

Si la spécification omet une exigence importante, un code techniquement correct peut néanmoins mettre en œuvre une conception dangereuse ou indésirable.

2. Contrôle d’accès

Les auditeurs examinent les rôles owner, admin, operator et les autres rôles privilégiés, notamment leur pouvoir de :

• accorder ou révoquer des autorisations ;
• suspendre le système ;
• modifier les frais et les limites ;
• créer de nouveaux jetons ;
• retirer des actifs ;
• mettre à niveau une implémentation.

Ils examinent également si une seule clé peut effectuer une modification critique et si des contrôles comme une multisignature ou un verrouillage temporel font partie de la conception.

3. Appels externes et réentrance

Un contrat peut transférer le contrôle à un autre contrat pendant son exécution. Cela peut permettre une réentrance, lorsque le contrat externe effectue un rappel avant la fin de la transition d’état initiale. La documentation officielle de Solidity recommande, lorsque cela est pertinent, d’ordonner soigneusement les vérifications, les modifications d’état et les interactions externes.

4. Calculs et unités

Les auditeurs recherchent :

• arrondis et pertes de précision ;
• nombre de décimales du jeton incorrect ;
• ordre incorrect des opérations ;
• valeurs limites ;
• division par zéro ;
• unsafe unchecked arithmetic;
• écarts entre les unités internes et les unités affichées.

5. Déni de service et gas

Des boucles sans limite, des tableaux de taille croissante, des appels externes échoués ou des opérations coûteuses peuvent rendre l’exécution d’une fonction impraticable. Les examinateurs vérifient si la conception reste utilisable à mesure que les données augmentent et avec des entrées inhabituelles.

6. Proxys et mises à niveau

Pour les systèmes évolutifs, l’examen doit couvrir :

• contrats proxy et d’implémentation ;
• droits de mise à niveau ou d’administration ;
• initialisation ;
• compatibilité de la disposition du stockage ;
• mécanismes de mise à niveau non autorisés ;
• l’effet d’une modification de la logique après l’audit.

Un proxy peut conserver la même adresse visible par l’utilisateur tout en déléguant l’exécution à une nouvelle logique. Toute affirmation selon laquelle « le contrat ne peut pas changer » doit donc être vérifiée au regard de l’architecture réelle.

7. Intégrations

Les contrats peuvent dépendre de jetons, d’oracles de prix, de ponts, de DEX, de signatures ou d’autres contrats. Les auditeurs examinent les hypothèses liées à ces dépendances, les données obsolètes, les comportements inhabituels des jetons et les modes de défaillance externes.

8. Événements et surveillance

Les auditeurs peuvent vérifier si les événements rendent correctement visibles les actions importantes, telles que les changements de rôles, les mises à niveau, les suspensions et les transferts. Les événements facilitent la surveillance, mais ne remplacent pas l’examen de l’état.

Méthodes utilisées lors d’un audit

Un examen associe généralement :

• analyse manuelle du code et de l’architecture ;
• tests unitaires et d’intégration ;
• analyse statique et dynamique ;
• tests aléatoires avec des entrées générées ;
• tests fondés sur les propriétés ;
• recherche de catégories de vulnérabilités connues ;
• examen de la compilation et du déploiement ;
• parfois une vérification formelle de propriétés sélectionnées.

Aucune méthode ne couvre tout. La vérification formelle peut prouver que le code respecte une spécification formelle ; elle ne peut pas prouver une propriété que la spécification n’a pas exprimée.

Comment un utilisateur doit lire un audit

1. Comparer avec la version auditée

Trouvez le hash du commit et déterminez :

• si l’implémentation actuelle a été compilée à partir de ce code ;
• si des mises à niveau ont eu lieu après la date du rapport ;
• si la blockchain et les adresses déployées correspondent ;
• si les dépendances critiques étaient incluses dans le périmètre.

Si cela ne peut pas être établi, le rapport fournit peu d’éléments probants sur le déploiement actif.

2. Lire les constats, pas uniquement le résumé

Pour chaque constat, examinez :

• gravité et scénario ;
• le code concerné ;
• recommandation ;
• réponse du développeur ;
• état actuel ;
• si l’auditeur a testé de nouveau la correction.

Réparé ou Résolu is meaningful only when tied to a specific corrected version.

3. Lire les limitations

Les rapports peuvent exclure :

• systèmes frontaux et dorsaux ;
• gestion des clés ;
• conception économique ;
• contrats tiers ;
• infrastructure de déploiement ;
• configuration de production ;
• problèmes juridiques et opérationnels.

Les utilisateurs interagissent avec l’ensemble du système, et pas seulement avec ses fichiers Solidity.

4. Examiner le risque administratif

Demandez-vous :

• qui contrôle les mises à niveau ;
• si les opérations peuvent être suspendues ;
• si les frais ou les adresses associées peuvent changer ;
• si un verrouillage temporel existe ;
• si une multisignature est utilisée ;
• manière dont les utilisateurs sont informés des modifications.

Il s’agit de questions de gouvernance et de confiance, même si aucune vulnérabilité n’a été découverte dans le code.

5. Continuer à surveiller la sécurité après l’audit

Parmi les mesures de suivi utiles figurent :

• test de chaque version ;
• examen des mises à niveau importantes ;
• un programme de primes aux bugs ;
• surveillance des rôles et des implémentations ;
• procédures de réponse aux incidents ;
• limitation du montant des actifs exposés.

Ce qu'un audit ne garantit pas

Un audit ne garantit pas :

• l’absence de tout bug ;
• sécurité du code modifié après l’examen ;
• sécurité du site web, du portefeuille, du DNS ou des serveurs ;
• sécurité des clés privilégiées ;
• exactitude des jetons externes, des oracles et des ponts ;
• résistance à toute attaque économique ;
• intégrité d’une équipe ;
• conformité juridique ;
• liquidité du jeton ;
• restitution des fonds ;
• rendements fixes ou de toute autre nature.

Questions qu’un utilisateur prudent doit poser

Is an auditor’s logo enough?
No. Find the report from the auditor’s own source and check its scope, commit, date, and findings.

If every finding was fixed, is the contract safe?
It means the listed findings were addressed in a stated version. Unknown issues and out-of-scope risks remain.

Are several audits automatically better?
The count alone says little. Coverage, quality, independence, recency, and version matching matter more.

Does an audit still apply after a proxy upgrade?
Only if the new implementation and configuration are covered by the reviewed version.

Liste de contrôle du rapport

• Le rapport est disponible auprès de l’auditeur.
• Le dépôt et le hash du commit sont indiqués.
• Les contrats et dépendances critiques sont inclus dans le périmètre.
• La version examinée correspond au déploiement actif.
• Le proxy, l’implémentation et l’administration sont couverts.
• La recherche du statut et le nouveau test sont documentés.
• Les hypothèses et exclusions ont été lues.
• Les risques extérieurs au code ont été évalués séparément.

Sources et lectures complémentaires

1. Ethereum.org — Sécurité des smart contracts
2. Ethereum.org — Test des smart contracts
3. Ethereum.org — Vérification formelle des smart contracts
4. Solidity Documentation — Considérations de sécurité
5. OpenZeppelin Docs — Modèle de mise à niveau par proxy