Un audit de smart contract indépendant est une revue de sécurité réalisée par une société qui n'a pas écrit le code et qui n'a aucun engagement de développement sur le projet. Un développeur ne peut pas réellement auditer son propre code : sa relecture est un contrôle qualité utile, mais elle partage les angles morts et les intérêts de ceux qui ont construit le système. C'est l'indépendance qui transforme une relecture en un élément de preuve sur lequel un tiers peut s'appuyer.
Pourquoi une relecture interne n'est pas un audit
Une relecture interne n'est pas un audit, car le relecteur confronte le code à sa propre compréhension, c'est-à-dire précisément là où se cachent les failles les plus graves. Le développeur vérifie ce qu'il voulait que le contrat fasse. L'auditeur vérifie ce que le contrat permet réellement à n'importe qui de faire.
Deux problèmes distincts rendent l'autocontrôle insuffisant.
Les angles morts
Ceux qui ont conçu un système transportent les mêmes hypothèses dans sa relecture. Si l'équipe a considéré qu'un flux de prix ne pouvait pas être manipulé au sein d'une seule transaction, ou qu'une fonction ne serait appelée que par sa propre interface, ces convictions façonnent à la fois le code et les tests. Relire le code ne les remet pas en cause.
L'auditeur externe part de la position inverse. Il lit la spécification, puis cherche tous les chemins qui la mettent en défaut : ordres d'appel inhabituels, entrées malveillantes, interactions avec d'autres protocoles, cas limites dans les calculs. Le regard neuf n'est pas ici une image, c'est la méthode.
Le conflit d'intérêts
Le second problème est structurel. Une société de développement qui audite son propre travail se note elle-même. Chaque constat sérieux est aussi l'aveu d'un défaut dans un livrable pour lequel elle a été payée, avec parfois une correction à ses frais et un retard de calendrier. Même avec la meilleure volonté, l'incitation pousse vers des niveaux de gravité adoucis et une lecture étroite du périmètre.
C'est pourquoi utilisateurs, plateformes d'échange, investisseurs et partenaires accordent en général peu de poids à un « audit » signé par l'équipe qui a écrit le code. Le rapport sert à rassurer des tiers, et ces tiers doivent savoir que le relecteur n'avait rien à gagner à un résultat favorable.
La relecture interne, les tests unitaires, le fuzzing (tests automatisés par entrées aléatoires) et l'analyse statique restent indispensables. Ils réduisent le nombre de problèmes que l'auditeur trouvera et rendent l'audit plus productif. Ils préparent l'audit, ils ne le remplacent pas.
Ce que l'indépendance signifie concrètement
L'indépendance signifie que la société d'audit n'a aucun intérêt à ce que le code soit jugé correct, et aucune relation avec le projet qui rendrait un constat coûteux à signaler. En pratique, elle repose sur trois conditions.
- Une société différente. L'auditeur est une entité juridique distincte du développeur, et non une équipe sœur, une filiale ou un sous-traitant de la société de développement. Les personnes ayant contribué au code ne doivent pas faire partie de l'équipe d'audit.
- Aucun engagement de développement sur le projet. La société d'audit n'a pas été engagée pour construire, faire évoluer ou maintenir les contrats examinés. Une société qui a développé une version précédente, ou qui doit développer la suivante, n'est pas indépendante pour ce projet.
- Le réaudit est réalisé par l'auditeur. Après l'audit, le développeur corrige les constats et l'auditeur vérifie les corrections. Le développeur ne déclare pas lui-même ses constats comme résolus. La définition du réaudit précise ce que couvre cette vérification.
L'indépendance comporte aussi des aspects moins visibles à vérifier : actionnariat commun entre les deux sociétés, partage de revenus, commissions d'apport d'affaires, ou rémunération de l'auditeur conditionnée au lancement du projet. Demandez à chaque prestataire de déclarer par écrit tout lien de ce type.
L'indépendance ne veut pas dire distance ou défiance. Un bon audit suppose une collaboration étroite : le développeur explique la conception, répond aux questions et fournit la documentation. La frontière porte sur qui juge le résultat, pas sur qui parle à qui.
Comment smart-contract.com applique la règle
Sur smart-contract.com, une société qui a un engagement de développement sur un projet ne peut jamais être invitée ni retenue pour l'audit ou le réaudit de ce même projet, et cette règle d'indépendance est appliquée par une contrainte en base de données, et non laissée à des vérifications manuelles. Le même principe vaut quelle que soit la façon dont vous trouvez votre auditeur : vérifiez-le avant de signer, pas après.
Comment organiser les passations entre développeur et auditeur
Une passation réussie remet à l'auditeur un code figé, documenté et testable, ainsi qu'un interlocuteur unique côté développement. La plupart des retards et des différends en audit viennent de passations mal définies, pas de la revue elle-même.
Avant le début de l'audit
Le développeur prépare les éléments ; le client décide de leur remise.
- Figer le code. Convenez d'un hash de commit qui définit exactement ce qui est audité. Toute modification ultérieure sort du périmètre, sauf accord des deux parties.
- Définir le périmètre. Listez les fichiers et contrats inclus, ceux explicitement exclus, et les dépendances externes considérées comme fiables.
- Fournir la documentation. Une spécification du comportement attendu, les rôles et permissions, les hypothèses connues et le plan de déploiement.
- Livrer des tests qui fonctionnent. L'auditeur doit pouvoir compiler le projet et lancer la suite de tests sans assistance.
La préparation a un effet direct sur le coût, puisque le niveau de préparation est l'un des facteurs du modèle indicatif d'audit du site. Le guide pour préparer un audit de smart contract détaille cette étape.
Pendant l'audit
Mettez en place un canal commun entre l'auditeur, le développeur et le client. Le développeur répond rapidement aux questions de conception ; l'auditeur signale les problèmes critiques dès qu'ils sont confirmés, sans attendre le rapport final. Le client doit être en copie de tous les échanges, car l'audit est commandé pour lui, et non pour le développeur.
Après le rapport
La séquence qui suit le rapport doit être écrite à l'avance :
- L'auditeur remet le rapport, avec chaque constat et son niveau de gravité.
- Le développeur corrige les constats, ou documente pourquoi un constat est accepté comme risque connu, avec l'accord du client.
- L'auditeur vérifie chaque correction sur un nouveau hash de commit lors du réaudit.
- L'auditeur publie une version finale du rapport indiquant le statut de chaque constat.
- Le client déploie exactement le commit qui a été vérifié.
L'étape 5 est souvent négligée. Si le code déployé diffère du commit audité, le rapport ne décrit plus ce qui tourne réellement sur la blockchain.
Ce qu'il faut vérifier dans les contrats
Vos contrats avec le développeur et avec l'auditeur doivent rendre explicites l'indépendance et la séquence de passation, pour qu'aucune des deux ne repose sur la bonne volonté. Utilisez la liste suivante comme base d'échange avec votre conseil juridique.
| Contrat | Clause à vérifier | Pourquoi c'est important |
|---|---|---|
| Développeur | Obligation de corriger les constats dans un délai défini | Évite un vide entre le rapport et le réaudit |
| Développeur | Corrections incluses dans le prix ou facturées à part | Les constats sont attendus ; leur coût ne doit pas être une surprise |
| Développeur | Tests et documentation inclus dans les livrables | L'auditeur en a besoin, et ils réduisent l'effort d'audit |
| Auditeur | Déclaration écrite d'indépendance et d'absence de conflit | Rend la condition d'indépendance vérifiable |
| Auditeur | Réaudit des corrections inclus ou chiffré à l'avance | Le modèle indicatif du site ajoute 20 % du prix du premier audit pour un réaudit |
| Auditeur | Périmètre défini par fichiers et hash de commit | Évite les désaccords sur ce qui a été examiné |
| Auditeur | Droit de publier le rapport, et qui en décide | Clarifie ce que le client peut montrer à des tiers |
| Les deux | Confidentialité et divulgation responsable des constats | Les problèmes critiques ne doivent pas fuiter avant leur correction |
Deux points méritent une attention particulière. D'abord, vérifiez que le contrat de l'auditeur ne donne au développeur aucun rôle dans la validation du rapport ou des niveaux de gravité. Ensuite, aucun auditeur sérieux ne garantit l'absence de bugs : un audit réduit le risque, il ne le supprime pas. Méfiez-vous de toute proposition qui laisserait entendre le contraire.
Si vous en êtes encore à définir le projet, le générateur de cahier des charges vous aide à rédiger une spécification sur laquelle le développeur, puis l'auditeur, pourront travailler.
À retenir
- La relecture par le développeur est un contrôle qualité utile, mais ce n'est pas un audit : elle partage les angles morts de l'équipe et comporte un conflit d'intérêts.
- L'indépendance suppose une société différente, aucun engagement de développement sur le projet, et un réaudit réalisé par l'auditeur, pas par le développeur.
- Organisez la passation autour d'un hash de commit figé, d'un périmètre écrit, d'une documentation et de tests fonctionnels, et ne déployez que le commit vérifié.
- Inscrivez l'indépendance, le délai de correction et le réaudit dans les deux contrats, pour que le processus ne dépende pas de la bonne volonté.
- Un audit indépendant réduit le risque ; il ne garantit jamais que le code est exempt de bugs.