Posséder un hardware wallet récent, une plaque métallique et une passphrase ne suffit pas à démontrer qu’une architecture crypto est sûre. La sécurité réelle dépend de la façon dont les secrets ont été créés, sauvegardés, utilisés, contrôlés et récupérés — mais aussi des dépendances qui relient tous ces éléments.
Un audit utile ne cherche donc pas seulement « la bonne marque de wallet ». Il cherche les points de défaillance, les scénarios d’abus et les situations dans lesquelles le dispositif cesse de fonctionner comme prévu.
1. Commencer par cartographier les actifs et les responsabilités
Avant de parler de seed ou de multisig, il faut savoir ce qui est réellement protégé.
Un audit commence par identifier :
- les blockchains et actifs concernés ;
- les wallets réellement utilisés et leur rôle ;
- les personnes capables de signer, valider ou préparer une transaction ;
- les systèmes qui fournissent des adresses, des balances ou des données de transaction ;
- les procédures d’urgence et de récupération.
Cette cartographie évite un problème fréquent : sécuriser très fortement un wallet principal tout en oubliant un wallet opérationnel, une clé d’administration ou un compte logiciel capable de modifier le dispositif.
2. Vérifier comment les clés ont été générées
La sécurité d’une clé commence avant son premier dépôt.
Il faut documenter le modèle d’appareil, le firmware utilisé lors de la génération, la méthode d’entropie, l’éventuel ajout de dés et la provenance de la seed. Une seed importée depuis un ancien appareil conserve les propriétés de sa génération initiale.
L’incident COLDCARD de 2026 a rappelé qu’une suite BIP-39 peut sembler parfaitement valide alors que son espace de recherche est inférieur à celui attendu. Un audit doit donc s’intéresser à l’origine du secret, pas seulement à l’endroit où il est stocké aujourd’hui.
3. Examiner les sauvegardes comme des actifs sensibles
Une sauvegarde est une copie du pouvoir de dépenser.
L’audit doit vérifier :
- combien de copies existent réellement ;
- où elles sont stockées ;
- si plusieurs copies partagent le même risque physique ;
- si une photographie, un scan ou une saisie numérique a déjà existé ;
- si une passphrase est utilisée et comment son existence est documentée ;
- si les supports sont encore lisibles et récupérables.
La robustesse physique compte, mais la distribution compte davantage. Trois plaques métalliques conservées au même endroit constituent encore un seul domaine de défaillance.
GLOV SSS peut être utilisé comme brique de sauvegarde distribuée pour une seed saine. Il ne remplace cependant ni l’audit de l’architecture ni la qualité du secret d’origine.
4. Rechercher les dépendances corrélées
Un multisig 2-sur-3 n’est pas automatiquement trois fois plus résilient.
Trois signataires utilisant le même fabricant, le même firmware, la même procédure de génération et le même lieu de stockage peuvent partager une vulnérabilité commune. De la même manière, des clés séparées physiquement peuvent rester dépendantes du même ordinateur, du même logiciel de coordination ou du même fournisseur de sauvegarde.
L’objectif est d’identifier les domaines de défaillance : fabricant, firmware, système d’exploitation, lieu, personne, fournisseur cloud, canal de communication ou processus interne.
C’est l’une des raisons pour lesquelles une architecture de custody doit être pensée comme un système, pas comme une collection de périphériques.
5. Vérifier ce que l’utilisateur voit réellement avant de signer
Une architecture peut protéger parfaitement les clés et échouer au moment de la transaction.
Il faut déterminer comment sont vérifiés :
- l’adresse de destination ;
- le montant ;
- le réseau utilisé ;
- les frais ;
- les données d’un smart contract ;
- les permissions accordées par une signature.
Un écran de hardware wallet n’est utile que si l’opérateur sait ce qu’il doit y comparer. Un dispositif de sécurité qui repose systématiquement sur le copier-coller d’une adresse depuis un ordinateur compromis reste vulnérable.
6. Tester les procédures de récupération
Une sauvegarde qui n’a jamais été testée est une hypothèse.
L’audit doit vérifier qu’une restauration peut être effectuée sans exposer inutilement les secrets et que les informations nécessaires sont disponibles : format de seed, passphrase éventuelle, chemins de dérivation, descripteurs multisig, ordre des cosignataires, wallets compatibles et procédures de contrôle.
Pour les organisations, un test de récupération doit aussi répondre à une question plus difficile : que se passe-t-il si la personne qui connaît le système n’est pas disponible ?
7. Examiner les rôles et les pouvoirs, pas seulement les clés
Dans une organisation, la question n’est pas seulement « qui possède une seed ? ».
Il faut également savoir :
- qui peut demander une transaction ;
- qui peut la préparer ;
- qui peut l’approuver ;
- qui peut signer ;
- qui peut modifier les règles ;
- qui peut déclencher une procédure d’urgence.
Lorsque toutes ces capacités sont concentrées chez une seule personne, un multisig peut donner une impression de contrôle collectif sans véritable séparation des responsabilités.
8. Identifier les chemins de contournement
Les systèmes réels comportent souvent des raccourcis : wallet secondaire, seed de secours, clé admin, compte d’exchange, accès à distance, ancien téléphone, fichier de configuration ou procédure « temporaire » jamais supprimée.
Un audit doit activement chercher ces chemins, car un attaquant choisit rarement la route la mieux documentée. Il choisit la route la plus faible.
9. Prioriser les corrections selon le risque réel
Un bon audit ne se termine pas par une liste de vingt recommandations de même importance.
Les mesures doivent être classées selon leur impact et leur urgence : secret potentiellement compromis, sauvegarde unique, firmware ancien, absence de procédure de récupération, concentration excessive des pouvoirs, dépendance critique ou manque de documentation.
Certaines corrections peuvent être immédiates. D’autres nécessitent une migration de wallet, une nouvelle politique multisig ou une évolution de gouvernance.
L’objectif : comprendre le système avant de le complexifier
Ajouter davantage de hardware wallets, de fragments ou de règles ne rend pas automatiquement un dispositif plus sûr. Une architecture trop complexe peut devenir impossible à exploiter correctement, surtout lors d’une urgence.
La bonne architecture est celle dont les risques sont compris, dont les responsabilités sont explicites et dont la récupération a été réellement testée.
GLOV Secure accompagne les particuliers et organisations dans cette analyse sans détenir leurs fonds ni conserver leurs secrets. Un audit de sécurité crypto peut servir de point de départ avant une migration, un multisig ou une refonte complète de l’architecture.
GLOV Solutions ne fournit pas de conseil juridique, fiscal ou financier dans le cadre de cette analyse.