Les systèmes de self-custody sont souvent présentés comme un problème de matériel : choisir un hardware wallet, protéger une seed, éventuellement ajouter un multisig. Pourtant, beaucoup d’incidents se produisent alors que la cryptographie fonctionne exactement comme prévu.
L’utilisateur signe la mauvaise transaction. Une sauvegarde est photographiée « juste quelques secondes ». Une personne partage une information sensible sur le mauvais canal. Un processus d’urgence n’a jamais été testé. La sécurité technique reste intacte, mais le système réel échoue.
La sécurité dépend de décisions répétées
Une architecture crypto n’est pas utilisée une seule fois. Elle traverse des dizaines de situations :
- réception d’une nouvelle adresse ;
- préparation d’un transfert ;
- signature d’une transaction ;
- mise à jour d’un firmware ;
- changement de téléphone ou d’ordinateur ;
- ajout d’un cosignataire ;
- restauration d’un wallet ;
- absence d’une personne clé ;
- incident de sécurité.
À chaque étape, l’opérateur doit savoir quoi vérifier et dans quel ordre. Plus le montant ou le nombre d’intervenants augmente, moins il est raisonnable de dépendre de la mémoire d’une seule personne.
Une procédure n’est pas une bureaucratie
Une bonne procédure ne cherche pas à ralentir l’utilisateur. Elle réduit le nombre de décisions à improviser sous pression.
Pour une transaction importante, elle peut imposer quelques contrôles simples : vérifier le réseau, afficher l’adresse sur un appareil indépendant, comparer le montant, confirmer le bénéficiaire par un second canal, comprendre les données signées et conserver une trace de l’approbation.
Le but n’est pas d’ajouter dix validations à chaque paiement. Le but est de définir à l’avance ce qui change lorsque le niveau de risque augmente.
Les moments d’urgence sont les plus dangereux
Un message annonçant une faille critique, un appareil perdu ou une transaction inconnue crée une forte incitation à agir vite.
C’est précisément dans ce contexte que les faux supports techniques, les sites de phishing et les procédures frauduleuses deviennent efficaces.
Une organisation mature prépare donc une procédure d’incident avant l’incident :
- qui peut décider d’une migration ;
- quels appareils sont considérés comme sains ;
- comment vérifier les sources officielles ;
- comment créer une nouvelle adresse ;
- comment effectuer une transaction de test ;
- qui doit être informé ;
- quels secrets ne doivent jamais être communiqués.
La préparation permet d’agir rapidement sans agir aveuglément.
La vérification indépendante réduit les erreurs silencieuses
Une même personne peut préparer et vérifier une transaction, mais elle reste exposée aux mêmes biais et au même environnement compromis.
Pour les opérations importantes, une seconde personne ou un second appareil peut créer une indépendance utile. Cela ne nécessite pas forcément un multisig : il peut simplement s’agir d’une validation de l’adresse, du montant ou du contexte avant signature.
Dans une organisation, cette séparation peut devenir formelle : demandeur, préparateur, approbateur et signataire ne disposent pas nécessairement des mêmes pouvoirs.
Le hardware wallet ne peut pas expliquer une transaction à votre place
Un hardware wallet protège la clé privée et affiche des informations avant signature. Mais si l’utilisateur ne sait pas interpréter ce qu’il voit, l’écran ne suffit pas.
C’est particulièrement important avec les smart contracts. Une signature peut autoriser une dépense future, modifier une permission ou interagir avec un contrat complexe. « Le hardware wallet m’a demandé de confirmer » n’est pas une analyse de risque.
La formation doit donc couvrir le sens des opérations, pas seulement l’emplacement des boutons.
Les secrets doivent être absents des procédures opérationnelles
Documenter une procédure ne signifie pas documenter la seed.
Une procédure saine décrit où trouver le bon processus, quels rôles interviennent, quels contrôles effectuer et comment reconnaître le matériel utilisé. Elle peut indiquer qu’une passphrase existe sans en révéler la valeur.
Les secrets doivent rester dans leur dispositif de sauvegarde prévu. Les documents opérationnels doivent permettre de comprendre le système sans permettre à eux seuls de le compromettre.
Les exercices révèlent ce que la documentation cache
Une procédure peut sembler excellente sur le papier et échouer lors de sa première utilisation.
Un exercice de récupération ou de transaction contrôlée permet de découvrir :
- une sauvegarde illisible ;
- un câble ou adaptateur manquant ;
- une version logicielle incompatible ;
- un descripteur multisig absent ;
- une personne qui ne connaît pas son rôle ;
- un processus qui dépend d’un compte inaccessible.
Ces exercices doivent être réalisés sans exposer inutilement les actifs réels. L’objectif est de tester la capacité opérationnelle, pas de créer une nouvelle surface de risque.
La complexité doit rester proportionnée
La réponse au facteur humain n’est pas d’écrire un manuel de cent pages pour un wallet personnel.
Une procédure efficace doit être adaptée au contexte. Un particulier peut avoir une checklist courte pour les transferts importants et une fiche de récupération. Une entreprise peut nécessiter des rôles, des approbations, une journalisation et des exercices périodiques.
Plus l’architecture est complexe, plus la documentation et la formation deviennent essentielles.
Construire une sécurité utilisable
Le meilleur dispositif est celui qui reste sûr lorsqu’il est utilisé dans la vraie vie, y compris lorsqu’une personne est fatiguée, pressée ou absente.
GLOV Secure travaille sur cette dimension opérationnelle : architecture, audit, procédures et formation à la sécurité crypto, toujours dans une approche non-custodial. GLOV ne détient pas les fonds et n’a pas besoin de conserver les secrets pour analyser un dispositif.
La sécurité crypto ne repose pas sur la perfection humaine. Elle repose sur une architecture qui rend les bonnes décisions plus faciles et les erreurs critiques plus difficiles.