Procédé pour établir une liaison de données sécurisée (LNK1) entre un dispositif électronique (CW1, HW, HDV, CW2, DV, CW3) et un serveur (ORC1), dans lequel le serveur et le dispositif 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) de l’autorité de certification, procédé caractérisé en ce que le dispositif et le serveur sont configurés pour exécuter les étapes suivantes : - le serveur 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 dispositif, - le dispositif génère (B5.4) une clé privée éphémère (peD) et une clé publique éphémère (PeD) - le dispositif génère (B5.4) une première signature de sa clé publique éphémère (PeD) à partir de sa clé privé (pD), - le dispositif génère (B5.4) une première clé de session (k0) à partir de sa clé privée éphémère (peD) et de la clé publique éphémère (PeO) du serveur, - le dispositif chiffre (B5.4) la première signature au moyen de la première clé de session (k0), pour obtenir une signature chiffrée, - le dispositif transfère (B5.5) au serveur un certificat éphémère (CeD) comprenant sa clé publique éphémère (PeD) et la signature chiffrée, - le serveur génère (B5.6) la première clé de session (k0) à partir de sa clé privée éphémère (peO) et de la clé publique éphémère (PeD) du dispositif, et - au moyen de la première clé de session (k0), le serveur déchiffre (B5.7) la signature présente dans le certificat éphémère (CeD). Procédé selon la revendication 1, dans lequel : - le serveur transfère (B5.2) son certificat (CO) au dispositif, - le dispositif chiffre (B5.4) son propre certificat (CD) avec la première clé de session, - le dispositif transfère (B5.5) au serveur son certificat (CD) chiffré avec la première clé de session, et - au moyen de la première clé de session (k0), le serveur déchiffre (B5.7) le certificat (CD) du dispositif. Procédé selon l’une des revendications 1 et 2 dans lequel, avant de générer la première signature de sa clé publique éphémère (PeD), le dispositif concatène (B5.4) sa clé publique éphémère (PeD) avec une donnée (ReD). Procédé selon l’une des revendications 2 et 3, dans lequel : - le dispositif vérifie (B5.3) la validité du certificat éphémère (CeO) du serveur (ORC1) au moyen du certificat (CO) du serveur, - le dispositif vérifie (B5.3) la validité du certificat (CO) du serveur (ORC1) au moyen de la clé publique (PL) de l'autorité de certification, - le serveur (ORC1) vérifie (B5.7) la validité du certificat éphémère (CeD) du dispositif au moyen du certificat (CD) du dispositif, et - le serveur vérifie (B5.7) la validité du certificat (CD) du dispositif au moyen de la clé publique de certification (CL). Procédé selon l’une des revendications 1 à 4 dans lequel le dispositif (CW1) comprend un portefeuille matériel de cryptoactifs (HW) comprenant une donnée secrète principale (S), ou clé maître. Procédé selon la revendication 5, dans laquelle le portefeuille matériel (HW) est dépourvu de moyen de connexion à l’Internet et est configuré pour être relié au serveur par l’intermédiaire d’un dispositif hôte (HDV) exécutant un logiciel compagnon (HSW) et pourvu d’une connexion à l’Internet. Procédé pour la sauvegarde d’une pluralité de données secrètes (Si) détenues par un portefeuille de cryptoactifs (CW1, HW, HDV, CW2, DV), les données secrètes étant stockées par le portefeuille de cryptoactifs ou pouvant être générées par le portefeuille de cryptoactifs à partir d’une donnée secrète principale (S) détenue par le portefeuille de cryptoactifs, le portefeuille de cryptoactifs étant la propriété d’un utilisateur (USR), le procédé comprenant les étapes consistant à : - prévoir un programme orchestrateur (ORC1) exécuté par un serveur (ORCSRV1) pour mettre en œuvre et superviser la sauvegarde des données, et - prévoir une pluralité de serveurs de sauvegarde (BCKSRVi), et dans lequel le programme orchestrateur est configuré pour : - établir une liaison de données sécurisée (LNK1) avec le portefeuille de cryptoactifs conformément au procédé selon l’une des revendications 1 à 6, - communiquer (B6) à chaque serveur de sauvegarde des informations (BCKDT) relatives à l’identité de l’utilisateur, - recevoir (B11) du portefeuille de cryptoactifs les données à sauvegarder ({Si}kBi), et - transférer (B12) à chaque serveur de sauvegarde l’une des données (Si) à sauvegarder. Procédé selon la revendication 7, 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 7 et 8, dans lequel : - chaque serveur de sauvegarde (BCKSRVi) possède une clé privée (pO, pD, pBi), une clé publique (PO, PD, PBi), un certificat (CO, CD, CBi) signé par l’autorité de certification (CA), et la clé publique (PL) de l’autorité de certification, - 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 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, - le portefeuille de cryptoactifs transfère (B5.5) son certificat (CD) et son certificat éphémère (CeD) au programme orchestrateur, qui le transfère (B6) à chacun des serveurs de sauvegarde (BCKi), - chaque serveur de sauvegarde génère une deuxième clé de session (kBi) à partir de sa clé privée éphémère (peBi) et de la clé publique éphémère (PeD) du portefeuille de cryptoactifs, - le portefeuille de cryptoactifs génère la deuxième clé de session (kBi) de chaque serveur de sauvegarde à partir de sa clé privée éphémère (peD) et de la clé publique éphémère (PeBi) du serveur de sauvegarde, - le portefeuille de cryptoactifs chiffre (B10) la donnée destinée à chaque serveur de sauvegarde avec la deuxième clé de session (kBi), la transfère (B11) à l’orchestrateur qui la transfère (B12) au serveur de sauvegarde, et - chaque serveur de sauvegarde déchiffre (B13) au moyen de la deuxième clé de session (kBi) la donnée (Si) reçue, et la stocke dans une mémoire (MEM). Procédé selon la revendication 9, dans lequel : - chaque serveur de sauvegarde vérifie (B7) la validité du certificat (CD) du portefeuille de cryptoactifs au moyen de la clé publique de certification (CL), - chaque serveur de sauvegarde vérifie (B7) la validité du certificat éphémère (CeD) du portefeuille de cryptoactifs au moyen du certificat (CD) du portefeuille de cryptoactifs, - 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 de certification (CL), et - le portefeuille de cryptoactifs vérifie (B8.8) la validité du certificat éphémère (CeBi) de chaque serveur de sauvegarde au moyen du certificat (CBi) de chaque serveur. Procédé selon l’une des revendications 9 et 10, dans lequel des données à l’attention du portefeuille de cryptoactifs transmises au programme orchestrateur par un serveur de sauvegarde sont transmises (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 7 à 11, comprenant une étape initiale (B3, IDV0) de vérification de l’identité de l’utilisateur par le programme orchestrateur, et dans lequel le programme orchestrateur est configuré pour ne pas permettre la sauvegarde des données (Si) dans les serveurs de sauvegarde si la vérification d’identité n’est pas concluante. Procédé selon l’une des revendications 7 à 12 dans lequel le portefeuille de cryptoactifs (CW1, CW3, DV, CW3) est configuré pour générer la pluralité de données secrète (Si) à partir de la clé maître (S) au moyen d’une fonction de partage de secret configurée pour générer un nombre m de données secrètes et permettre la reconstitution de la clé maître (S) à partir d’un seuil de n données secrètes (Si). Procédé selon la revendication 13, dans lequel m est égal à 3 et n est égal à 2. Procédé selon l’une des revendications 1 à 14, comprenant une étape (R11) de restauration de tout ou partie des données secrètes dans un deuxième portefeuille de cryptoactifs (CW1, HW’), l’étape de restauration étant précédée par des étapes (R11-R12) de récupération de tout ou partie des données secrètes dans les serveurs de sauvegarde par l’intermédiaire du programme orchestrateur, et dans lequel les étapes (R11-R12) de récupération des données secrètes dans les serveurs de sauvegarde sont précédées d’une pluralité d’étapes (R7, IDVi) de vérification de l’identité de l’utilisateur par au moins une partie des serveurs de sauvegarde (BCKSRVi), un serveur de sauvegarde configuré pour vérifier l’identité de l’utilisateur étant également configuré pour refuser de restituer la donnée secrète qu’il détient si la vérification de l’identité de l’utilisateur n’est pas concluante Procédé selon la revendication 15, dans lequel au moins un serveur de sauvegarde (BCKSRVi) est configuré pour déléguer l’étape de vérification de l’identité à serveur (IDVSRVi) spécialisé dans la vérification d’identité, le serveur de sauvegarde étant configuré pour établir une liaison de données avec le serveur spécialisé (IDVSRVi) afin de mettre l’utilisateur en relation avec ce serveur (IDVSRVi).