Un audit de smart contract est l'examen du code d'un protocole par des spécialistes chargés d'y trouver les failles avant que quelqu'un ne les exploite. Pour un investisseur, ce n'est pas un label de qualité : c'est une pièce à vérifier, et la vérifier prend cinq minutes que presque personne ne prend.

Un audit réduit le risque, il ne l'annule pas.Des protocoles audités par les meilleurs cabinets se font vider chaque année. Son absence, en revanche, est un signal sans appel.

À quoi sert vraiment un audit

Un smart contract devient immuable une fois déployé. Un bug découvert ensuite ne se corrige pas par une mise à jour, et il n'existe aucun bouton d'annulation. Cette irréversibilité change tout : dans le logiciel classique, on corrige en production ; ici, on ne corrige pas.

D'où la pratique de faire relire le code avant déploiement. Concrètement, un cabinet spécialisé lit ligne à ligne, teste des scénarios d'attaque connus, exécute des outils d'analyse automatique et tente de casser le contrat. Il publie ensuite un rapport listant les problèmes par gravité, l'équipe corrige, et le cabinet vérifie les corrections.

Ce que l'audit couvre : les erreurs de logique, les failles d'accès, les erreurs de calcul, les vulnérabilités classiques comme la réentrance.

Ce qu'il ne couvre pas, et c'est là que les gens se font avoir :

La malhonnêteté de l'équipe. Un contrat peut être irréprochable techniquement et prévoir une fonction permettant aux fondateurs de tout retirer. Ce n'est pas une faille, c'est une fonctionnalité, et un rapport d'audit la mentionnera au mieux dans une note de bas de page.

Les sources de données extérieures. Un contrat qui dépend d'un oracle pour connaître un prix peut être parfait et se faire vider par manipulation de cette source. Une part considérable des sommes volées en finance décentralisée vient de là, pas du code audité.

Ce qui a changé après. Un audit porte sur une version précise du code, à une date précise. Si l'équipe a redéployé depuis, le rapport ne vaut plus grand-chose.

La viabilité économique. Un protocole peut être techniquement solide et reposer sur un modèle qui s'effondre dès que les récompenses baissent.

Les cinq vérifications à faire avant d'investir

Infographie des cinq vérifications à faire sur un smart contract avant d'investir : code publié, existence réelle de l'audit, version auditée, détention des droits d'administration et ancienneté du contrat

Voici la partie qui vous concerne. Elle ne demande aucune compétence technique.

1. Le code est-il publié ?

Sur un explorateur de blockchain, l'onglet du contrat indique si le code source a été vérifié. S'il ne l'est pas, personne ne peut savoir ce que fait ce contrat, aucun audit sérieux n'a pu avoir lieu, et la question est réglée. C'est éliminatoire, sans discussion.

2. Le rapport d'audit existe-t-il vraiment ?

C'est la vérification la plus rentable, parce que la fraude y est massive. Un projet affiche le logo d'un cabinet connu, parfois un lien vers un PDF hébergé sur son propre site. Allez sur le site du cabinet et cherchez le rapport dans sa liste publique. Les cabinets sérieux publient tous leurs audits.

Un logo sans rapport correspondant chez l'auditeur, c'est un mensonge, et un mensonge sur ce point précis vous dit tout ce qu'il faut savoir sur le reste du projet.

3. Sur quelle version porte-t-il ?

Le rapport indique une date et souvent une empreinte du code examiné. Comparez cette date à celle du déploiement du contrat que vous vous apprêtez à utiliser. Un audit de janvier sur un contrat redéployé en juin ne couvre rien.

Vérifiez aussi que les problèmes signalés ont été corrigés. Un rapport listant trois failles critiques sans mention de correction est un rapport à charge, pas un gage de sécurité, et beaucoup de projets le publient tel quel en comptant sur le fait que personne ne l'ouvre.

4. Qui garde la main ?

C'est la question que les investisseurs particuliers ne posent jamais et que les professionnels posent en premier. Beaucoup de contrats conservent des fonctions d'administration : mettre en pause, modifier un paramètre, remplacer une partie du code, créer des jetons.

Ce n'est pas nécessairement malveillant, c'est même souvent prudent pour pouvoir réagir à un incident. Mais il faut savoir qui détient cette clé. Une adresse unique contrôlée par une personne, c'est un point de défaillance et une tentation. Une signature multiple répartie entre plusieurs acteurs identifiés, avec un délai avant exécution, c'est autre chose. Un bon rapport d'audit détaille toujours ces droits, dans une section que tout le monde saute.

5. Depuis combien de temps, avec combien dedans ?

Un contrat qui détient des centaines de millions depuis trois ans a été attaqué en continu par des gens très motivés, sans céder. Aucun audit ne vaut cette preuve-là. À l'inverse, un contrat déployé il y a trois semaines n'a rien démontré, quel que soit son rapport.

Les outils qui font le travail à votre place

Plusieurs services analysent automatiquement un contrat à partir de son adresse et renvoient un score : détention des droits d'administration, possibilité de bloquer les ventes, répartition des jetons, verrouillage de la liquidité.

Ils sont utiles pour éliminer rapidement les cas grossiers, en particulier les honeypots. Deux réserves toutefois. Un score élevé ne prouve rien sur la logique métier du contrat, que seule une lecture humaine peut juger. Et certains projets frauduleux conçoivent leur code précisément pour passer ces tests automatiques.

Pour un jeton récent, la vérification la plus efficace reste empirique : achetez une somme dérisoire et tentez immédiatement de la revendre. Si la vente échoue, vous venez de détecter un piège pour le prix d'un café.

Pourquoi des protocoles audités se font quand même vider

Parce qu'un audit est un examen à un instant donné, mené par des humains, sur un périmètre défini. Trois causes reviennent.

La faille est ailleurs. Le protocole est correct mais s'appuie sur une brique qui ne l'est pas : une bibliothèque, un langage, un oracle. Curve en a fait l'expérience en juillet 2023, quand un bug du langage Vyper, et non de son propre code, a permis de vider plusieurs pools.

L'attaque combine plusieurs protocoles. Chaque contrat pris isolément se comporte correctement, mais leur enchaînement dans une même transaction produit un résultat que personne n'avait envisagé. C'est le mécanisme des attaques par flash loan, et aucun audit portant sur un seul protocole ne peut les anticiper.

Le code a changé. L'équipe a déployé une mise à jour non auditée, ou activé une fonctionnalité qui ne figurait pas dans le périmètre examiné.

Ce que ça change pour vous

La bonne façon de lire un audit n'est pas « ce protocole est sûr » mais « ce protocole a été examiné, voici sur quoi et par qui ».

Trois réflexes suffisent à écarter l'essentiel du risque. Ne jamais engager de fonds sur un contrat dont le code n'est pas publié. Toujours vérifier le rapport chez l'auditeur plutôt que chez le projet. Et considérer l'ancienneté combinée aux montants immobilisés comme le meilleur indicateur disponible, devant n'importe quel rapport.

Reste le geste qui protège le plus, et qui n'a rien à voir avec l'audit : limiter les autorisations que vous accordez. Un contrat ne peut déplacer vos jetons que si vous l'y avez autorisé. Révoquer régulièrement les autorisations dont vous n'avez plus l'usage vous protège même contre un protocole irréprochable qui se ferait compromettre plus tard.

Audit de smart contract : les questions fréquentes

Qu'est-ce qu'un audit de smart contract ?

C'est l'examen du code d'un contrat par des spécialistes chargés d'identifier les failles avant son déploiement. Le cabinet lit le code, teste des scénarios d'attaque, exécute des outils d'analyse et publie un rapport classant les problèmes par gravité. L'équipe corrige, puis l'auditeur vérifie les corrections. C'est une étape devenue standard, rendue nécessaire par le fait qu'un contrat déployé ne peut plus être modifié.

Comment vérifier un smart contract ?

Cinq vérifications suffisent, sans compétence technique. Le code est-il publié et vérifié sur un explorateur de blockchain ? Le rapport d'audit existe-t-il bien dans la liste publique du cabinet cité, et pas seulement sur le site du projet ? Porte-t-il sur la version déployée ? Qui détient les droits d'administration du contrat ? Et depuis combien de temps tourne-t-il, avec quels montants immobilisés ?

Un audit garantit-il qu'un projet est sûr ?

Non. Un audit couvre le code examiné à une date donnée, pas l'honnêteté de l'équipe, pas les sources de données extérieures dont dépend le contrat, pas les mises à jour ultérieures et pas la viabilité économique du projet. Des protocoles audités par les meilleurs cabinets se font vider chaque année. Son absence, en revanche, est un signal négatif sans appel sur un projet qui collecte des fonds.

Comment savoir si un rapport d'audit est authentique ?

En le cherchant sur le site du cabinet plutôt que sur celui du projet. Les auditeurs sérieux publient l'intégralité de leurs rapports dans une liste accessible. Un logo affiché sans rapport correspondant chez l'auditeur signifie que la mention est fausse. Vérifiez ensuite la date, le périmètre examiné et le fait que les problèmes signalés aient été corrigés plutôt que simplement listés.

Pourquoi des protocoles audités se font-ils quand même pirater ?

Trois raisons principales. La faille se situe dans une brique sous-jacente que l'audit ne couvrait pas, comme un langage ou un oracle. L'attaque enchaîne plusieurs protocoles qui, pris séparément, fonctionnent correctement, ce qui est le principe des attaques par flash loan. Ou le code a changé depuis l'audit, par une mise à jour non réexaminée.

Combien coûte un audit de smart contract ?

Le prix dépend de la taille du code et de la réputation du cabinet, et il se compte généralement en dizaines de milliers d'euros pour un protocole de taille moyenne, davantage pour un système complexe. C'est précisément ce coût qui explique que beaucoup de petits projets s'en dispensent, ou se contentent d'un prestataire bon marché dont le rapport n'a pas la même valeur.

Que sont les droits d'administration d'un contrat ?

Ce sont des fonctions permettant à certaines adresses d'agir sur le contrat après son déploiement : le mettre en pause, modifier un paramètre, remplacer une partie du code ou créer des jetons. Leur présence n'est pas forcément malveillante et sert souvent à réagir en cas d'incident. Ce qui compte est de savoir qui détient ces droits : une adresse unique constitue un point de défaillance, une signature multiple répartie entre acteurs identifiés est bien plus rassurante.

Les outils d'analyse automatique suffisent-ils ?

Ils éliminent rapidement les cas grossiers, notamment les contrats empêchant la revente, et méritent d'être utilisés en première passe. Mais un score élevé ne dit rien de la logique métier du contrat, que seule une lecture humaine peut évaluer, et certains projets frauduleux sont conçus pour passer ces tests. Sur un jeton récent, acheter une somme dérisoire puis tenter de la revendre reste la vérification la plus fiable.