Quand on conçoit une app de safety physique pour détenteurs crypto, on ne part pas d’une page blanche : on part de l’analyse de comment les wrench attacks se déroulent réellement. Six mois de recherche sur les modes opératoires documentés, les comptes-rendus de police, les témoignages de victimes, et l’analyse des mécanismes de leurre existants dans d’autres industries.
Cet article expose les décisions de design clés derrière Kronobi : pourquoi tel choix, qu’est-ce qu’on a rejeté, et quelles sont les limites assumées. C’est un article produit, pas un argumentaire marketing.
Le brief initial : couvrir la phase B
Le marché crypto safety en 2024 était saturé de produits couvrant la phase A (avant l’attaque) : Ledger, Trezor, Casa, Unchained, Coinbase Vault. Mais l’analyse des cas documentés (notamment l’affaire Balland qui s’est produite pendant la phase de design) montrait que la phase B (pendant l’agression) restait totalement non-couverte.
C’était l’opportunité produit. Pas de concurrent direct, un besoin réel, une fenêtre d’agression typique de 30 minutes à 17 jours pendant laquelle aucun outil n’aidait l’utilisateur.
Le brief s’est donc figé tôt : concevoir une app qui aide spécifiquement pendant l’agression, sans empiéter sur ce que les wallets traditionnels font déjà. Trois fonctions ont émergé comme critiques :
- Tromper visuellement l’agresseur avec un faux wallet crédible
- Envoyer en silence une alerte géolocalisée aux contacts d’urgence
- Préserver l’accès aux vraies cryptos qui restent intactes dans les wallets habituels
Les fonctions à NE PAS faire ont été figées aussi tôt : Kronobi ne touche jamais aux clés privées, ne fait jamais de transactions on-chain, ne stocke jamais de seed phrase. C’est une couche safety au-dessus de votre wallet existant, pas un wallet de plus.
Décision 1 — Code de panique : 0 0 0 0 0 0 plutôt qu’un PIN configurable
Le premier débat de design a été le choix du trigger pour activer le mode leurre.
Options évaluées :
- PIN secondaire configurable par l’utilisateur (option Tor, OpenBSD)
- Geste tactile spécifique (swipe pattern, multi-tap)
- Mot-clé vocal (“OK Google, mode urgence”)
- PIN fixe ultra-mémorisable (
000000ou123456) - Biométrie inversée (déverrouillage avec un autre doigt que l’habituel)
Après tests utilisateurs sous stress simulé (10 participants, scénarios d’agression reconstitués sans violence réelle), le résultat a été clair : les triggers complexes échouent sous stress.
Un PIN configurable : 4 utilisateurs sur 10 ont oublié leur code de panique sous pression. Un swipe pattern : 6 sur 10 ont raté le geste. Un mot-clé vocal : 9 sur 10 ont jugé qu’ils n’oseraient pas le prononcer devant un agresseur (“il va comprendre que je parle à mon téléphone”).
Le PIN fixe 0 0 0 0 0 0 a gagné parce qu’il combine 5 propriétés que les alternatives n’avaient pas toutes :
- Mémorisable trivialement sous stress (pas besoin de réfléchir)
- Saisissable rapidement (6 fois la même touche, mains tremblantes OK)
- Plausible comme erreur pour un agresseur observant (ressemble à une faute de frappe, à un code d’usine)
- Universel (pas besoin de configuration utilisateur, fonctionne pour tous)
- Distinct du vrai PIN dans la quasi-totalité des cas (très peu d’utilisateurs choisissent
000000comme PIN principal)
Le compromis : un agresseur très informé qui a lu cet article et qui sait que 0 0 0 0 0 0 est un code de panique peut potentiellement le neutraliser en forçant la victime à prouver que c’est son vrai PIN. C’est un compromis assumé. Aucun système n’est invulnérable à un attaquant pleinement informé.
Décision 2 — Bouton Face ID : un second déclencheur
Même un code à 6 zéros peut échouer sous certaines conditions :
- Mains tremblantes au point que la victime saisit un mauvais chiffre
- Écran sale ou cassé (cas observé après une bousculade)
- Agresseur qui observe l’écran de très près et risque de voir les 6 zéros bizarres
- Stress psychologique qui paralyse la motricité fine
Pour ces cas, un second trigger de secours a été ajouté : un bouton Face ID visuellement standard, présent sur l’écran d’accueil. Pour l’utilisateur entraîné, le tap discret sur ce bouton active immédiatement le mode leurre. Pour l’agresseur, c’est un bouton anodin d’authentification biométrique.
Pourquoi spécifiquement Face ID et pas Touch ID ? Trois raisons :
- iOS a généralisé Face ID depuis 2017, c’est devenu l’attente UX standard
- Le geste est minimaliste (un seul tap), donc moins détectable
- Ce bouton fait sens visuellement même si l’utilisateur a désactivé Face ID dans ses préférences (il ressemble à un raccourci d’auth, pas à un trigger d’alerte)
Cette seconde voie de déclenchement a un effet psychologique fort : l’utilisateur sait qu’il a un plan B. Si le PIN échoue, il y a le bouton. Cette assurance réduit la paralysie sous stress (effet documenté en psychologie cognitive).
Décision 3 — Le mode leurre doit être visuellement parfait
Un faux wallet qui ne convainc pas l’agresseur ne sert à rien. La phase la plus longue du design (3 mois sur les 6) a été dédiée à l’UI du leurre.
Cinq propriétés requises :
1. Apparence générique de wallet crypto — pas de signature Kronobi visible. Le mode leurre ressemble à n’importe quel wallet du marché : design Coinbase-adjacent, icônes crypto standard, polices neutres.
2. Balances réalistes et configurables — l’utilisateur peut paramétrer en amont son “solde leurre” (entre 5 000 € et 50 000 € selon son profil public). Un milliardaire avec 5 k$ de faux solde n’est pas crédible. Un anonyme avec 500 k$ non plus.
3. Historique de transactions cohérent — dates espacées, montants variés, devises mélangées (BTC, ETH, USDC). Pas de pattern qui trahit une génération automatique.
4. Cours réels mis à jour — les prix affichés correspondent au marché réel au moment de la consultation. Une cryptomonnaie qui affiche un cours daté de 6 mois met l’agresseur en alerte.
5. Transactions simulables jusqu’au bout — l’agresseur peut saisir une adresse, valider un transfert, voir un hash factice apparaître, voir le solde diminuer. La simulation va jusqu’à la confirmation visuelle, sans broadcaster aucune transaction réelle.
Cette dernière propriété est la plus difficile techniquement. Elle exige de simuler côté app un comportement complet de réseau blockchain (génération de hash plausible, délais de confirmation réalistes, mise à jour du solde). C’est l’unique partie où nous avons engagé un ingénieur spécialisé blockchain pour valider que la simulation passe l’œil d’un expert.
Décision 4 — L’alerte silencieuse est le différentiel clé
Les mécanismes de leurre traditionnels (Tor, OpenBSD, banques) s’arrêtent au leurre. Ils ouvrent une fausse session, point.
Kronobi va une étape plus loin : l’alerte silencieuse géolocalisée envoyée en arrière-plan dès le déclenchement du code de panique. C’est la fonction qui transforme une protection passive (leurre) en protection active (alerte).
Quatre exigences ont guidé son design :
Aucun signal détectable par l’agresseur — pas de notification, pas de son, pas de vibration, pas de changement visuel sur l’écran. L’app continue de fonctionner comme un wallet normal. La détection de l’alerte par l’agresseur compromettrait tout.
Chiffrement de bout en bout — les alertes utilisent le Signal Protocol (mêmes garanties cryptographiques que les apps Signal et WhatsApp). Ni Kronobi, ni Twilio (transport SMS), ni l’opérateur télécom ne peuvent lire le contenu. Seuls les contacts désignés ont les clés de déchiffrement.
Multi-canal en sauvegarde — l’alerte part simultanément via Internet (E2EE) et SMS de secours. Si l’un des canaux échoue (zone blanche, opérateur down, agresseur qui désactive le wifi), l’autre prend le relais.
Géolocalisation continue pendant la fenêtre active — pas juste une position one-shot au moment du déclenchement, mais un suivi temps réel pendant 2 heures par défaut (configurable 15 min à 3 h). Si l’utilisateur est déplacé pendant l’agression, les contacts d’urgence voient le mouvement en temps réel.
Décision 5 — Ne jamais toucher aux vraies clés crypto
Le choix le plus structurant : Kronobi n’est pas un wallet. L’app ne génère, ne stocke et ne manipule aucune clé privée crypto. Pas de keystore, pas de seed phrase, pas de signing.
Pourquoi ce choix ? Trois raisons :
1. Sécurité par séparation — un bug Kronobi ne peut jamais affecter vos vraies cryptos. Vous restez sur Ledger, MetaMask, Phantom, etc. Ce sont eux les wallets, Kronobi est la couche safety au-dessus.
2. Crédibilité juridique — Kronobi n’est ni custodian, ni broker, ni service de paiement. Cela évite toute une couche de régulation financière (PSAN, KYC complet, etc.) qui ralentirait le développement et ajouterait des risques.
3. Confiance utilisateur — beaucoup de détenteurs crypto ont une méfiance instinctive contre les nouveaux wallets. “Pourquoi confierais-je mes clés à une startup ?” Kronobi répond : “Ne nous confiez rien. Gardez vos clés là où vous les avez déjà. Nous, on couvre uniquement le scénario que les wallets ne couvrent pas.”
C’est la décision qui définit le positionnement marché de Kronobi : pas un concurrent des wallets, mais une couche complémentaire.
Ce qui reste à améliorer
Aucun produit n’est parfait. Trois limites assumées en mai 2026 :
1. Le leurre ne couvre pas l’agresseur ultra-informé. Un agresseur qui sait que Kronobi existe et qui exige explicitement la “vraie” session peut contourner le mécanisme. Réponse partielle en roadmap : un mode “double leurre” où le mode leurre lui-même peut ouvrir une sous-couche encore plus décorative — mais complexité d’usage croissante.
2. La géoloc n’est pas optimale en intérieur dense. En métro, parking souterrain, bunker, le GPS dégrade. La couche Bluetooth/Wifi triangulation est en développement pour combler le gap.
3. L’alerte SMS dépend de Twilio. Si Twilio a une panne (rare mais possible), l’alerte SMS de secours ne part pas. La couche Internet E2EE prend le relais, mais en zone blanche totale c’est un risque. Une version satellite Iridium est en bêta.
Le produit s’améliore par cycles courts (release mensuelle), informé par les retours des utilisateurs francophones — c’est l’avantage du focus marché concentré.