# Chapitre 2 – Sécurité: garder vos actifs en sécurité, quoi qu’il arrive

Alice a toujours pris la sécurité crypto très au sérieux. Elle protégeait ses wallets, faisait régulièrement des sauvegardes sécurisées, et suivait les bonnes pratiques. Pourtant, les solutions d’accès d’urgence, de Récupération ou de transmission continuaient de l’inquiéter :

* **Wallets multisig ou MPC:** Le risque de coordination est bien réel. Si une clé est perdue ou compromise, les actifs peuvent se retrouver bloqués… ou exposés. Et compter sur plusieurs signataires ajoute aussi des risques humains : conflits, désaccords, indisponibilité.
* **Partage de phrase mnémonique:** Simple, mais fragile. Un seul fragment divulgué ou perdu peut entraîner une perte immédiate et irréversible.
* **Garde juridique traditionnelle (avocats, notaires, sociétés fiduciaires):** Confier des sauvegardes ou des clés à des intermédiaires crée de nouvelles surfaces d’attaque. Les documents peuvent être copiés, perdus ou détournés, et les procédures légales ne peuvent pas exécuter des actions on-chain.

C’est pour ça qu’Alice a choisi CryptoLegacy.

Avec CryptoLegacy, Alice gardait le contrôle total tant qu’elle était active. Ses actifs restaient dans ses propres wallets et n’étaient jamais déposés dans des contrats de tiers. Le système fonctionnait comme une machine à états prédéfinie : tant qu’Alice restait active, personne ne pouvait initier des transferts ni déplacer des actifs.

Elle avait désigné à l’avance des Garants — des membres de sa famille, des amis, ou des conseillers — qui ne pouvaient agir que dans des limites strictes définies par le protocole. Aucun Garant, à lui seul, ne pouvait déclencher l’exécution. Il fallait un seuil de confirmations prédéfini, suivi d’une période de contestation obligatoire avant que le moindre transfert ne devienne possible.

Les Garants n’avaient aucun accès direct aux fonds, et aucune visibilité sur les soldes. Même si le compte d’un Garant était compromis, cela ne pouvait pas provoquer une exécution immédiate. Leur rôle se limitait à apporter une confirmation pour une transition d’état — pas à donner le contrôle.

Les Bénéficiaires étaient eux aussi limités par conception. Même si le compte d’un bénéficiaire était compromis, les actifs ne pouvaient pas être retirés d’un seul coup. Les demandes de retrait n’étaient possibles qu’une fois le système entré en Période de distribution, et en respectant le calendrier prédéfini par Alice, avec une libération progressive des actifs.

Quand Alice a eu un grave accident et est restée inconsciente pendant des semaines, l’incertitude s’est propagée autour d’elle. Malgré ça, ses actifs sont restés inaccessibles à toute action non autorisée. Impossible de contourner les seuils, de zapper la période de contestation, ou d’accélérer l’exécution. Ce n’est qu’après validation des confirmations requises et des vérifications basées sur le temps que le système a changé d’état et a permis l’application des règles de distribution prévues.

Alice s’est ensuite rétablie. Grâce au mécanisme de Récupération prédéfini, elle a repris le contrôle des actifs restants détenus par le contrat. Les transferts déjà effectués étaient définitifs, mais aucun actif supplémentaire n’a été exposé ni déplacé trop tôt.

CryptoLegacy n’a pas éliminé le risque. Mais il a réduit les modes de défaillance critiques par conception:

* **Les actifs restent sous le contrôle du Propriétaire** tant que les seuils et les conditions basées sur le temps ne sont pas remplis.
* **L’exécution nécessite plusieurs confirmations**, pas un seul acteur compromis.
* **Les périodes de contestation empêchent les exécutions précipitées ou erronées.**
* **La Récupération ne s’applique qu’aux actifs restants**, sans réécrire l’historique.

CryptoLegacy a offert à Alice quelque chose que les autres approches ne pouvaient pas : un modèle de sécurité qui continue de fonctionner correctement même quand le Propriétaire ne peut pas agir.

**Vos clés. Votre crypto. Votre sécurité.**