It's audited.

« It's audited » clôt plus de discussions que n'importe quelle autre phrase de la crypto.

Elle est vraie étonnamment souvent. Et elle en dit bien moins qu'elle n'en a l'air.

Voici le deuxième épisode de notre série « Safe, they said. » Dix phrases que les projets utilisent pour vous rassurer, une par semaine. Voici la deuxième, démontée.

Un audit, en un paragraphe

Un projet paie une société de sécurité pour lire son code. La société reçoit une version figée de ce code et un temps fixé. Elle cherche des erreurs, les consigne avec un niveau de gravité, et le projet répond à chacune. Le résultat est un rapport qui porte une date.

Un audit est donc une affirmation sur une version d'un code, à un moment donné, par des personnes qui peuvent passer à côté de quelque chose. Un bon rapport le dit lui-même, en général vers la fin.

Première limite : le périmètre

Le rapport couvre ce que la société a reçu. En général, ce sont les contrats. En général, ce n'est ni le site web, ni les serveurs, ni les paramètres avec lesquels les contrats sont déployés, ni les clés qui les contrôlent.

« Audité » sans le mot « quoi » est une demi-phrase.

Deuxième limite : la date

Le code change. Un contrat qui peut être mis à niveau peut être remplacé le lendemain du rapport. Le rapport décrit alors quelque chose qui ne tourne plus.

La question n'est pas « a-t-il été audité ? » mais « ce qui tourne aujourd'hui est-il ce qui a été lu ? »

Troisième limite : trouvé ne veut pas dire corrigé

Un rapport énumère des constats, avec un statut à côté de chacun. « Resolved » ou « fixed » veut dire que l'erreur a disparu. « Acknowledged » veut dire que le projet l'a lue et l'a laissée telle quelle. Avec l'un comme avec l'autre statut, un projet peut dire « audité ».

Quatrième limite : les clés

C'est celle qui coûte le plus d'argent.

Le 1er avril 2026, un grand protocole de trading sur Solana a perdu environ 285 millions de dollars, d'après le décompte de la société de sécurité Cyfrin. Cyfrin et le protocole lui-même disent tous deux qu'aucune faille des contrats n'a été exploitée.

Les droits d'administration du protocole étaient détenus par un multisig dans lequel deux signataires sur cinq suffisaient. D'après les conclusions préliminaires du protocole lui-même, des attaquants ont passé environ six mois à gagner la confiance de contributeurs, en personne, lors de conférences. Ils ont probablement compromis des appareils et obtenu des signatures sur des transactions dont les signataires ne pouvaient pas voir le contenu réel. Celles-ci ont été retenues, puis exécutées plus tard. Le siphonnage a duré environ douze minutes.

Aucune lecture du code n'aurait pu trouver cela. Le code a fait exactement ce que des signatures valides lui disaient de faire.

Un audit vérifie si la serrure fonctionne. Il ne vérifie pas qui détient les clés, ni comment elles sont protégées.

Comment le vérifier pour n'importe quel token

Pour cela, vous n'avez à faire confiance à aucun site, pas même au nôtre.

1. Trouvez le rapport sur le site de l'auditeur lui-même, pas seulement sur celui du projet.
2. Comparez l'adresse ou la version du code indiquée dans le rapport avec celle qui est utilisée aujourd'hui.
3. Lisez le statut de chaque constat. Comptez séparément les « resolved » et les « acknowledged ».
4. Lisez le périmètre. Cherchez ce qui n'y figure pas : les clés d'administration, les mises à niveau, le Bridge, le site web.
5. Demandez si le contrat peut encore être modifié, et par qui. Si c'est le cas, le rapport a une date d'expiration que personne n'y a imprimée.

Où en est SHIBC

Le contrat du token SHIBC a été audité par Hashlock en décembre 2024. Le rapport est public sur le site de Hashlock. La note est « Secure », avec un constat de faible gravité, une remarque sur le gas et quatre remarques de qualité.

Les six portent la mention « Acknowledged », et non « Resolved ». Ils sont mineurs. La propriété du contrat a été abandonnée, si bien que plus personne ne peut modifier son code. Ce que l'auditeur a lu en 2024 est ce qui tourne aujourd'hui.

Hashlock réserve une note plus élevée aux projets dotés d'un bug bounty ou d'une surveillance on-chain. Les deux sont prévus : un programme de divulgation avec un périmètre publié, et une surveillance.

L'audit couvre le contrat du token. Ce qui se construit autour a ses propres conditions à remplir avant le mainnet. Pour le Bridge, elles sont écrites dans notre whitepaper, section 7.6. Les détails de l'audit se trouvent à la section 8.7.

Ce que nous en retenons

Un audit est un élément de preuve, pas une garantie. Il répond à « ce code est-il ce qu'il prétend être ? » Il ne répond pas à « qui peut le modifier, et qui peut déplacer les fonds ? »

Notre vision de la façon dont un token devrait être géré : dites ce qui a été lu, par qui et quand. Dites ce qui a été laissé tel quel. Et traitez les clés comme la question la plus importante, car c'est bien le cas.

La semaine prochaine, troisième épisode : « We have a multisig. »