Audits de sécurité : ce qu'un rapport d'audit vous apprend vraiment

·5 min de lecture·Par SSP Editorial Team
Couverture SSP Academy : lire les rapports d'audit de sécurité

Audits de sécurité : ce qu'un rapport d'audit vous apprend vraiment

« Audité par » est l'un des badges les plus courants dans la crypto. On le voit sur les sites web, dans les présentations aux investisseurs et lors des lancements de tokens, souvent comme s'il réglait la question de savoir si quelque chose est sûr. Ce n'est pas le cas — mais un vrai rapport d'audit, bien lu, vous apprend énormément. Tout l'art consiste à savoir quoi chercher.

Ce qu'est un audit

Un audit de sécurité est un examen, limité dans le temps, d'un code précis par une société externe. Les auditeurs lisent le code, le testent, essaient de le casser et consignent ce qu'ils trouvent. Pour les smart contracts, cela signifie généralement une revue manuelle complétée par des outils automatisés ; pour les portefeuilles, cela peut inclure les applications, la cryptographie, les serveurs avec lesquels elles communiquent et la façon dont tout cela s'articule.

Le résultat est un rapport : ce qui a été examiné, quand, ce qui a été trouvé, la gravité de chaque constat et si l'équipe l'a corrigé.

Trois expressions de cette description comptent plus que les autres : un code précis, limité dans le temps et ce qui a été trouvé.

Lisez d'abord le périmètre

Le périmètre indique exactement ce que les auditeurs ont examiné — généralement des dépôts, contrats ou composants nommés, souvent figés sur un commit particulier.

C'est là que s'effondrent la plupart des allégations trompeuses d'« audité ». Un projet peut avoir fait auditer un seul petit contrat et présenter l'ensemble du protocole comme audité. Un portefeuille peut avoir fait examiner ses smart contracts alors que l'application qui construit et signe réellement vos transactions n'a jamais été regardée. Si ce à quoi vous faites confiance n'est pas dans le périmètre, l'audit n'en dit rien.

Demandez-vous : le périmètre couvre-t-il les parties qui touchent à mes fonds ?

Vérifiez la date et la version

Un audit décrit le code tel qu'il était le jour de l'examen. Tout ce qui a été livré ensuite — nouvelles fonctionnalités, nouvelles chaînes, refontes — en est exclu, à moins d'avoir été examiné à nouveau.

C'est normal : un logiciel ne cesse d'évoluer. Mais cela signifie qu'un audit vieux de deux ans portant sur un projet qui évolue vite est un document historique. Les questions utiles sont : quand a-t-il eu lieu, quelle version couvrait-il, et les changements majeurs intervenus depuis ont-ils fait l'objet de leur propre examen ?

Pour les smart contracts, il y a une subtilité supplémentaire : si un contrat est évolutif (upgradeable), le code qui s'exécute aujourd'hui n'est peut-être pas celui qui a été audité. Qui contrôle les mises à niveau compte autant que l'audit lui-même.

Lisez les constats, pas seulement le résumé

Les rapports classent les constats par gravité — généralement critique, élevée, moyenne, faible et informative — et indiquent si chacun a été corrigé, reconnu ou laissé en l'état.

  • Les constats critiques et élevés sont ceux qui pourraient faire perdre des fonds. Y en a-t-il eu, et ont-ils été corrigés puis revérifiés ?
  • « Reconnu » ne veut pas dire « corrigé ». Cela signifie que l'équipe a accepté le risque. C'est parfois raisonnable ; lisez pourquoi.
  • Zéro constat n'est pas automatiquement une bonne nouvelle. Cela peut signifier un excellent code — ou un périmètre étroit et une mission courte.
  • La revérification compte. Un bon rapport indique que les auditeurs ont vérifié les correctifs, pas seulement que l'équipe a déclaré les avoir apportés.

Ce qu'un audit ne peut pas vous dire

Même un audit approfondi a des limites qu'il vaut mieux énoncer clairement :

  • C'est un échantillon d'attention, pas une preuve. Les auditeurs trouvent beaucoup de bugs, mais pas tous. Des protocoles audités ont déjà été exploités.
  • Il couvre le code, pas l'exploitation. La façon dont les clés sont stockées, qui peut déployer, comment l'équipe gère un incident : tout cela est généralement hors périmètre.
  • Il ne couvre pas la conception économique, sauf si elle figurait explicitement dans le périmètre. Un contrat peut fonctionner exactement comme il est écrit et rester exploitable via les prix, les incitations ou d'autres protocoles.
  • Il ne couvre pas ce que vous installez. Un audit du code source ne dit rien d'une fausse application portant le même nom. Ce sont les builds reproductibles qui relient le code publié au logiciel que vous exécutez réellement.

Signaux d'alerte dans les allégations d'« audité »

  • Aucun lien vers le rapport lui-même, ou un rapport hébergé uniquement par le projet.
  • Un auditeur introuvable, ou dont le site ne mentionne pas la mission.
  • Un périmètre qui ne correspond pas à ce qui est mis en avant.
  • Des constats de gravité élevée non corrigés présentés comme « traités ».
  • Un seul audit, réalisé il y a des années, sur un produit qui a complètement changé depuis.

L'approche de SSP

Le code de SSP est open source, donc tout le monde peut le lire — mais code ouvert et code audité ne sont pas la même chose, et nous les traitons séparément.

Halborn, une société de sécurité indépendante, a audité les smart contracts ERC-4337 de SSP ainsi que, conjointement, l'extension SSP Wallet, l'application SSP Key et SSP Relay. Les deux rapports sont publics sur le site de Halborn, sans constat critique ni élevé, et les constats faibles et informatifs ont été traités. Notre récapitulatif des audits 2025 précise le périmètre et les dates de chaque mission.

Les mêmes réserves s'appliquent à nous comme à tout le monde. Ces audits couvrent le code tel qu'il était au moment de l'examen ; les fonctionnalités et chaînes ajoutées depuis n'en font pas partie. Nous indiquons donc quel type d'examen a connu le code plus récent, plutôt que d'étirer un vieux badge pour le couvrir.

Le résumé honnête

Un audit est un élément de preuve, pas une garantie. Il vous dit qu'un code précis, à un moment précis, a été examiné par une société précise, et ce qu'elle a trouvé.

Lisez le périmètre, vérifiez la date et la version, regardez les niveaux de gravité et la façon dont ils ont été résolus, et retrouvez le rapport sur le site même de l'auditeur. Faites cela, et « audité » cesse d'être un badge pour devenir une information.

Partager cet article

Articles connexes