Procédé pour la sauvegarde et la restauration d'un secret (S) détenu par un portefeuille de cryptoactifs (CW1, CW2, CW3, HW, HDV), caractérisé en ce qu’il comprend, pour la sauvegarde du secret, les étapes consistant à : - prévoir une pluralité de serveurs de sauvegarde (BCKi), - collecter (B3) des informations (BCKDT) relatives à l’identité de l’utilisateur, - communiquer (B6) à chaque serveur de sauvegarde les informations (BCKDT) relatives à l’identité de l’utilisateur, - au moyen du portefeuille de cryptoactifs, générer une pluralité de données secrètes (Si) à partir du secret (S), et - transférer (B11, B12) à chaque serveur de sauvegarde l'une des données secrètes fournies par le portefeuille de cryptoactifs, sous une forme chiffrée ({Si}kBi), et associer la donnée secrète à l'identité de l'utilisateur dans le serveur de sauvegarde. Procédé selon la revendication 1, dans lequel chaque donnée chiffrée ({Si}kBi) est chiffrée au moyen d'une clé de chiffrement (kBi) qui n'est connue que par le portefeuille de cryptoactifs et le serveur de sauvegarde à qui elle est destinée. Procédé selon l'une des revendications 1 et 2, dans lequel les informations relatives à l’identité de l’utilisateur comprennent au moins le prénom de l’utilisateur, le nom de famille de l’utilisateur et la date de naissance de l’utilisateur. Procédé selon l'une des revendications 1 à 3, dans lequel le portefeuille de cryptoactifs est configuré pour générer une pluralité de données secrètes (Si) au moyen d’une fonction de partage de secret (SS) prévue pour générer un nombre m de données secrètes à partir du secret (S) et permettre la reconstitution du secret (S) à partir d’un seuil de n données secrètes (Si). Procédé selon l'une des revendications 1 à 4, dans lequel le portefeuille de cryptoactifs (CW1) comprend un portefeuille matériel (HW) dépourvu de moyen de connexion à l’Internet relié ou configuré pour être relié à un dispositif hôte (HDV) exécutant un logiciel compagnon (HSW) et pourvu d’une connexion à l’Internet. Procédé selon l'une des revendications 1 à 5, comprenant, pour la restauration du secret, les étapes suivantes : - communication (R3) à chaque serveur de sauvegarde des informations (BCKDT) relatives à l’identité de l’utilisateur, - réception (R11) par le portefeuille de cryptoactifs, sous une forme chiffrée ({Si}kBi), de tout ou partie des données secrètes (Si) détenues par les serveurs de sauvegarde, et - reconstitution (R13) du secret par le portefeuille de cryptoactifs à partir des données secrètes ({Si}kBi) fournies par les serveurs de sauvegarde et après déchiffrement de celles-ci. Procédé selon l'une des revendications 1 à 6, comprenant les étapes consistant à : - prévoir un programme orchestrateur (ORC1) exécuté par un serveur (ORCSRV1), et - configurer le programme orchestrateur et le portefeuille de cryptoactifs pour qu'ils exécutent au moins l'une des étapes suivantes : - lors de la sauvegarde du secret, transfert au programme orchestrateur par le portefeuille de cryptoactifs des données secrètes générées par le portefeuille de cryptoactifs, et transfert (B12) aux serveurs de sauvegarde, par le programme orchestrateur des données secrètes reçues du portefeuille de cryptoactifs, et - lors de la restauration du secret, réception (R11) par le programme orchestrateur de tout ou partie des données secrètes détenues par les serveurs de sauvegarde, et transfert (R12) de ces données secrètes au portefeuille de cryptoactifs par le programme orchestrateur. Procédé selon la revendication 7, comprenant les étapes consistant à : - établir un premier canal de communication sécurisé entre le portefeuille de cryptoactifs et le programme orchestrateur (ORC1), au moyen d'une première clé de session (k0) générée après un échange de clés (PD, PeD, PO, PeO) entre le portefeuille de cryptoactifs et le programme orchestrateur (ORC1), et - établir un deuxième canal de communication sécurisé entre le portefeuille de cryptoactifs et chaque serveur de sauvegarde (BCKi) par l'intermédiaire du programme orchestrateur (ORC1), au moyen d'une pluralité de deuxième clés de session (kBi) générées après un échange de clés (PD, PeD, PBi, PeBi) entre le portefeuille de cryptoactifs et chaque serveur de sauvegarde (BCKi) par l'intermédiaire du programme orchestrateur (ORC1). Procédé selon la revendication 8, dans lequel le programme orchestrateur (ORC1), le portefeuille de cryptoactifs possèdent chacun une clé privée (pO, pD), une clé publique (PO, PD), un certificat (CO, CD) signé par une autorité de certification (CA), et une clé publique (PL) fournie par l’autorité de certification et dans lequel : - le programme orchestrateur transfère (B5.2) son certificat (CO) au portefeuille de cryptoactifs, - le portefeuille de cryptoactifs transfère (B5.5) son certificat (CD) au programme orchestrateur, - le programme orchestrateur génère (B5.1) une clé privée éphémère (peO), une clé publique éphémère (PeO) et un certificat éphémère (CeO) signé avec sa clé privée (pO), et transfère (B5.2) son certificat éphémère au portefeuille de cryptoactifs, - le portefeuille de cryptoactifs génère (B5.4) une clé privée éphémère (peD), une clé publique éphémère (PeD) et un certificat éphémère (CeD) signé avec sa clé privée (pD), et transfère (B5.5) son certificat éphémère au programme orchestrateur, - le portefeuille de cryptoactifs génère (B5.4) la première clé de session (k0) à partir de sa clé privé éphémère (peD) et de la clé publique éphémère (PeO) du programme orchestrateur, et - le programme orchestrateur génère (B5.6) la première clé de session (k0) à partir de sa clé privé éphémère (peO) et de la clé publique éphémère (PeD) du portefeuille de cryptoactifs. Procédé selon la revendication 9, dans lequel, avant de transférer son certificat éphémère au programme orchestrateur : - le portefeuille de cryptoactifs génère (B5.4) une première signature de sa clé publique éphémère (PeD) à partir de sa clé privé (pD), - le portefeuille de cryptoactifs chiffre (B5.4) la première signature au moyen de la première clé de session (k0), pour obtenir une signature chiffrée, - le portefeuille de cryptoactifs transfère (B5.5) à l'orchestrateur un certificat éphémère (CeD) comprenant sa clé publique éphémère (PeD) et la signature chiffrée, puis : - le programme orchestrateur génère (B5.6) la première clé de session (k0) à partir de sa clé privé éphémère (peO) et de la clé publique éphémère (PeD) du portefeuille de cryptoactifs, et - au moyen de la première clé de session (k0), le programme orchestrateur déchiffre (B5.7) la signature présente dans le certificat éphémère (CeD). Procédé selon la revendication 10, dans lequel, avant de générer la première signature de sa clé publique éphémère (PeD) à partir de sa clé privé (pD), le portefeuille de cryptoactifs concatène (B5.4) sa clé publique éphémère (PeD) avec une donnée (ReD). Procédé selon l’une des revendications 10 et 11, comprenant les étapes suivantes : - le portefeuille de cryptoactifs chiffre (B5.4) son certificat (CD) avec la première clé de session (k0) avant de le transférer (B5.5) au programme orchestrateur, et - au moyen de la première clé de session (k0), le programme orchestrateur déchiffre (B5.7) le certificat (CD) du portefeuille de cryptoactifs. Procédé selon l'une des revendications 9 à 12, dans lequel les serveurs de sauvegarde (BCKi) possèdent chacun une clé privée (pBi), une clé publique (PBi), un certificat (CBi) signé par une autorité de certification (CA), et une clé publique (PL) fournie par l’autorité de certification, - le programme orchestrateur transfère (B6) le certificat (CD) du portefeuille de cryptoactifs et le certificat éphémère (CeD) du portefeuille de cryptoactifs à chacun des serveurs de sauvegarde (BCKi), - chaque serveur de sauvegarde transfère (B8.4) son certificat (CBi) au programme orchestrateur, qui le transfère (B8.5) au portefeuille de cryptoactifs, - chaque serveur de sauvegarde (BCKi) génère (B8.1) une clé privée éphémère (peBi), une clé publique éphémère (PeBi) et un certificat éphémère (CeBi) signé avec sa clé privée (pBi), et transfère (B8.4) le certificat éphémère au programme orchestrateur qui le transfère (B8.5) au portefeuille de cryptoactifs, - chaque serveur de sauvegarde génère (8.2) la deuxième clé de session (kBi) à partir de sa clé privé éphémère (peBi) et de la clé publique éphémère (PeD) du portefeuille de cryptoactifs, et - le portefeuille de cryptoactifs génère (8.9) la deuxième clé de session (kBi) de chaque serveur de sauvegarde à partir de sa clé privé éphémère (peD) et de la clé publique éphémère (PeBi) du serveur de sauvegarde. Procédé selon la revendication 13, comprenant les étapes suivantes : - pour chaque serveur de sauvegarde, le portefeuille de cryptoactifs chiffre (B10) la donnée secrète destinée au serveur de sauvegarde avec la deuxième clé de session (kBi), transfère (B11) la donnée secrète chiffrée au programme orchestrateur qui la transfère (B12) au serveur de sauvegarde, et - chaque serveur de sauvegarde déchiffre (B13) la donnée secrète (Si) reçue au moyen de la deuxième clé de session (kBi), et la stocke dans une mémoire (MEM). Procédé selon l'une des revendications 13 et 14, dans lequel : - le portefeuille de cryptoactifs vérifie (B5.3) la validité du certificat (CO) du programme orchestrateur au moyen de la clé publique (PL) de l’autorité de certification, - le portefeuille de cryptoactifs vérifie (B5.3) la validité du certificat éphémère (CeO) du programme orchestrateur au moyen de la clé publique du certificat (CO) du programme orchestrateur, - le portefeuille de cryptoactifs vérifie (B8.8) la validité du certificat (CBi) de chaque serveur de sauvegarde (CBi) au moyen de la clé publique (PL) de l’autorité de certification, - le portefeuille de cryptoactifs vérifie (B8.8) la validité du certificat éphémère (CeBi) de chaque serveur de sauvegarde au moyen de la clé publique du certificat (CBi) de chaque serveur de sauvegarde, - le programme orchestrateur vérifie (B5.7) la validité du certificat (CD) du portefeuille de cryptoactifs au moyen de la clé publique (PL) de l’autorité de certification, - le programme orchestrateur vérifie (B5.7) la validité du certificat éphémère (CeD) du portefeuille de cryptoactifs au moyen de la clé publique du certificat (CD) du portefeuille de cryptoactifs, - chaque serveur de sauvegarde vérifie (B7) la validité du certificat (CD) du portefeuille de cryptoactifs au moyen de la clé publique (PL) de l’autorité de certification, et - chaque serveur de sauvegarde (BCKi) vérifie (B7) la validité du certificat éphémère (CeD) du portefeuille de cryptoactifs au moyen de la clé publique du certificat (CD) du portefeuille de cryptoactifs. Procédé selon l’une des revendications 13 à 15, dans lequel des données transmises au programme orchestrateur par un serveur de sauvegarde sont retransmises (8.5) par le programme orchestrateur au portefeuille de cryptoactifs sous une forme chiffrée au moyen de la première clé de session (k0), et dans lequel certaines de ces données (RETDTi) sont préalablement hachées (B8.3) par le serveur de sauvegarde au moyen d’une fonction de hachage, puis chiffrées (B8.3) au moyen de la deuxième clé de session (kBi). Procédé selon l'une des revendications précédentes, dans lequel avant de fournir (R11) la donnée secrète (Si) qu'il détient, au moins un serveur de sauvegarde soumet l'utilisateur à une étape de vérification de son identité, et refuse de restituer la donnée secrète si la vérification de l’identité de l’utilisateur n’est pas concluante. Portefeuille de cryptoactifs (CW1, HW, HDV, CW2, CW3) détenant ou prévu pour détenir un secret (S), caractérisé en ce qu’il est configuré pour proposer à un utilisateur les options suivantes : - sauvegarder le secret manuellement (D2.1) sous la forme d'une phrase de récupération qui devra être conservée par l'utilisateur, ou - sauvegarder le secret dans une pluralité de serveurs de sauvegarde (D2.2), et, si l'utilisateur choisit de sauvegarder le secret dans une pluralité de serveurs de sauvegarde : - conduire une étape de collecte (B3, D4, BCKID, D8-D11, D28-D32, D34) d'informations relatives à l'identité de l'utilisateur, en présence de l'utilisateur, et à une étape de communication (B6, D9, D11, D30, D32) à chaque serveur de sauvegarde des informations relatives à l’identité de l’utilisateur, - générer une pluralité de données secrètes (Si) à partir du secret (S), et - transférer (B12) les données secrètes à la pluralité de serveurs de sauvegarde (BCKi), sous une forme chiffrée ({Si}kBi). Portefeuille de cryptoactifs selon la revendication 18, configuré pour proposer également à l'utilisateur les options suivantes : - restaurer le secret manuellement (D24.2) à partir d'une phrase de récupération, ou - restaurer le secret à partir d'une pluralité de serveurs de sauvegarde (D24.2), et, si l'utilisateur choisit de restaurer le secret à partir d'une pluralité de données secrètes détenues par une pluralité de serveurs de sauvegarde, reconstituer (R13) le secret à partir des données fournies par les serveurs de sauvegarde. Portefeuille de cryptoactifs selon l'une des revendications 18 et 19, configuré pour générer une pluralité de données secrètes (Si) à partir du secret (S) au moyen d’une fonction de partage de secret (SS) prévue pour générer un nombre m de données secrètes et permettre la reconstitution du secret (S) à partir d’un seuil de n données secrètes (Si). Portefeuille de cryptoactifs selon l'une des revendications 18 à 20, configuré pour : - transférer (B12) les données secrètes dans la pluralité de serveurs de sauvegarde (BCKi) par l'intermédiaire d'un programme orchestrateur (ORC1) exécuté par un serveur (ORCSRV1), et - récupérer (R12) chacune des données fournies par les serveurs de sauvegarde par l'intermédiaire du programme orchestrateur. Portefeuille de cryptoactifs selon la revendication 19, configuré pour, si l'utilisateur choisit de restaurer le secret à partir des données secrètes, conduire au moins une étape de vérification de l’identité de l’utilisateur à la demande d'un serveur de sauvegarde. Portefeuille de cryptoactifs (CW1) selon l'une des revendications 18 à 22, comprenant un portefeuille matériel (HW) dépourvu de moyen de connexion à l’Internet, et un dispositif hôte (HDV) exécutant un logiciel compagnon (HSW) et pourvu d’une connexion à l’Internet, le logiciel compagnon complétant le portefeuille matériel (HW) pour la réalisation d'étapes (D1-D13, D20-D38) nécessitant une interaction avec l'utilisateur, notamment des étapes de collecte d'informations relatives à l'identité de l'utilisateur. Portefeuille de cryptoactifs selon la revendication 23, dans lequel le portefeuille matériel (HW) comprend un écran tactile (TS) d'une diagonale supérieure ou égale à 3,5 pouces et exclusivement contrôlé par un élément sécurisé (SE), utilisé notamment pour collecter des informations relatives à l'identité de l'utilisateur.