Système de gestion mutualisée de comptes de cryptoactifs, dans lequel une demande de réalisation d’une transaction sur un compte de cryptoactif ne peut être exécutée qu’après avoir reçu l’accord d’au moins un approbateur et satisfait une règle de gouvernance, le système comprenant : - un premier module de sécurité matériel (HSM1) pour exécuter des règles de gouvernance, et - un service de signature (SIGN1, MSIGN2) configuré pour générer une signature (SIG1) d’une transaction (T) à partir d’une donnée secrète (K0, SH2), le premier module de sécurité matériel (HSM1) étant configuré pour, en réponse à une demande de réalisation d’une transaction, solliciter l'approbation d’au moins un dispositif approbateur (APi) et vérifier si une règle de gouvernance applicable à la transaction demandée est satisfaite, système caractérisé en ce que le service de signature (SIGN1, MSIGN2) est exécuté par un second module de sécurité matériel (HSM2) ayant accès à la donnée secrète (K0, SH2), le premier module de sécurité matériel (HSM1) étant configuré pour, lorsque la règle de gouvernance est satisfaite, transmettre une demande de signature de la transaction au second module de sécurité matériel (HSM2), le second module de sécurité matériel étant configuré pour fournir (S32, S44) la signature (SIG1) de la transaction. Système selon la revendication 1, dans lequel le premier module de sécurité matériel (HSM1) est configuré pour inclure la transaction (T) dans la demande de signature de la transaction. Système selon la revendication 1, dans lequel le premier module de sécurité matériel (HSM1) est configuré pour ne pas inclure la transaction (T) dans la demande de signature de la transaction et y inclure seulement un condensat (HT) de la transaction (T) produit par une fonction de hachage, et des données complémentaires permettant au second module de sécurité matériel (HSM2) de générer la signature de la transaction à partir de ce condensat. Système selon la revendication 3, dans lequel les données complémentaires comprennent un chemin de dérivation (DRV) déterministe hiérarchique et une fonction de signature à utiliser pour générer la signature de la transaction, ou un identifiant (IDF) de cette fonction. Système selon l’une des revendications 3 et 4, dans lequel le second module de sécurité matériel (HSM2) n’a jamais connaissance du contenu de la transaction, le système comprenant un service (BCAST) de diffusion de transactions sur la blockchain recevant la signature de la transaction fournie par le second module de sécurité matériel (HSM2) et la transaction fournie par le premier module de sécurité matériel (HSM1). Système selon l’une des revendications 1 à 5, dans lequel le premier module de sécurité matériel (HSM1) est agencé dans un premier lieu à accès restreint, et le second module de sécurité matériel est agencé dans un second lieu à accès restreint différent du premier lieu. Système selon l'une des revendications 1 à 6, dans lequel la donnée secrète (K0) est une graine permettant de générer une clé maître permettant elle-même de générer des clés privées de comptes de cryptoactifs, ou une clé maître permettant de générer des clés privées de comptes de cryptoactifs. Système selon l'une des revendications 1 à 7, dans lequel une règle de gouvernance définit au moins un nombre d'approbations à recevoir de dispositifs approbateurs (OPi, APi) pour qu’une transaction soit signée et exécutée. Système selon l'une des revendications 1 à 8, comprenant au moins un dispositif approbateur (OPi, APi), le dispositif approbateur comprenant des moyens de calcul cryptographique (PSDi) pour établir un canal de communication sécurisé avec le premier module de sécurité matériel. Système selon la revendication 9, dans lequel le premier module de sécurité matériel (HSM1) et le dispositif approbateur (OPi, APi) sont membres d'une même infrastructure à clé publique (PA) comprenant une autorité de certification (CA) fournissant ladite clé publique, et dans lequel le dispositif approbateur et le premier module de sécurité matériel (HSM) sont configurés pour établir entre eux un canal de communication sécurisé en exécutant les étapes suivantes : - vérification mutuelle (S63, S70) par chaque entité que l'autre entité possède un certificat statique valide au regard de la clé publique de l'infrastructure à clé publique, - génération (S61, S64) par chaque entité d'un certificat éphémère comprenant une clé publique éphémère signée avec une clé privée de l'entité, - vérification mutuelle (S63; S70) par chaque entité que le certificat éphémère de l'autre entité est valide au regard de son certificat statique, - génération d'une clé de session (k) par échange de clés Diffie-Hellman entre les deux entités, et utilisation de la clé de session pour crypter le canal de communication sécurisé. Système selon l'une des revendications 9 et 10, dans lequel le premier module de sécurité matériel (HSM1) est configuré pour collecter une approbation émise par le dispositif approbateur (OPi, APi) de la façon suivante : - envoyer (S8) un challenge aléatoire et le descriptif de la transaction au dispositif approbateur, et attendre une réponse, - recevoir (S12) du dispositif approbateur, sous une forme signée (S11), le challenge ou une donnée comprenant le challenge, puis - vérifier la validité de la signature, la transaction étant réputée approuvée si la signature est valide, et dans lequel pour adresser une approbation de transaction au premier module de sécurité matériel (HSM1), le dispositif approbateur (OPi, APi) est configuré pour afficher à un utilisateur personne physique (USRi) une description de la transaction (S9), recueillir l'approbation de l'utilisateur (S10), signer (S11) le challenge ou une donnée comprenant le challenge avec une clé privée (dPi), puis envoyer (S12) la signature obtenue au premier module de sécurité matériel (HSM1). Procédé de gestion mutualisée de comptes de cryptoactifs, dans lequel une demande de réalisation d’une transaction sur un compte de cryptoactif ne peut être exécutée qu’après avoir reçu l’accord d’au moins un approbateur et satisfait une règle de gouvernance, procédé mis en œuvre au moyen d’un système comprenant : - un premier module de sécurité matériel (HSM1) pour exécuter des règles de gouvernance, et - un service de signature (SIGN1, MSIGN2) configuré pour générer une signature (SIG1) d’une transaction à partir d’une donnée secrète (K0, SH2), procédé dans lequel, en réponse à une demande de réalisation d’une transaction, le premier module de sécurité matériel sollicite l'approbation d’au moins un dispositif approbateur (APi) et vérifie si une règle de gouvernance applicable à la transaction demandée est satisfaite, procédé caractérisé en ce qu’il comprend les étapes consistant à : - prévoir un second module de sécurité matériel (HSM2) pour exécuter le service de signature (SIGN1, MSIGN2), et - lorsque la règle de gouvernance est satisfaite, transmettre une demande de signature de la transaction au second module de sécurité matériel (HSM2) et générer (S32) la signature de la transaction au moyen du second module de sécurité matériel (HSM2) et à partir de la donnée secrète (K0, SH2). Procédé selon la revendication 12, dans lequel la demande de signature de la transaction inclut la transaction (T). Procédé selon la revendication 12, dans lequel la demande de signature de la transaction transmise au second module de sécurité matériel (HSM2) n’inclut pas la transaction (T) et comprend seulement un condensat (HT) de la transaction (T) produit par une fonction de hachage, et des données complémentaires permettant au second module de sécurité matériel (HSM2) de générer la signature de la transaction à partir de ce condensat. Procédé selon la revendication 14, dans lequel les données complémentaires comprennent un chemin de dérivation (DRV) déterministe hiérarchique et une fonction de signature à utiliser pour générer la signature de la transaction, ou un identifiant (IDF) de cette fonction. Procédé selon l’une des revendications 14 et 15, dans lequel le second module de sécurité matériel (HSM2) ne reçoit jamais la transaction, le procédé comprenant les étapes consistant à : - prévoir un service (BCAST) de diffusion de transactions sur la blockchain exécuté par un serveur (SRV1), - fournir au service de diffusion (BCAST) la signature de la transaction fournie par le second module de sécurité matériel (HSM2), - fournir au service de diffusion (BCAST) la transaction connue du premier module de sécurité matériel (HSM1) mais inconnue du second module de sécurité matériel (HSM2), et - diffuser la transaction sur la blockchain au moyen du service de diffusion (BCAST). Procédé selon l’une des revendications 12 à 16, comprenant les étapes consistant à : - agencer le premier module de sécurité matériel (HSM1) dans un premier lieu à accès restreint, et - agencer le second module de sécurité matériel (HSM2) dans un second lieu à accès restreint différent du premier lieu. Procédé selon l'une des revendications 12 à 15, dans lequel la donnée secrète (K0) est une graine permettant de générer une clé maître permettant elle-même de générer des clés privées de comptes de cryptoactifs, ou une clé maître permettant de générer des clés privées de comptes de cryptoactifs. Procédé selon l'une des revendications 12 à 18, comprenant au moins un dispositif approbateur (OPi, APi), le dispositif approbateur comprenant des moyens de calcul cryptographique (PSDi) pour établir un canal de communication sécurisé avec le premier module de sécurité matériel, dans lequel le premier module de sécurité matériel (HSM1) et le dispositif approbateur (OPi, APi) sont membres d'une infrastructure à clé publique (PA) comprenant une autorité de certification (CA) fournissant ladite clé publique, et dans lequel l'établissement d'un canal de communication sécurisé entre le dispositif approbateur et le premier module de sécurité matériel comprend les étapes suivantes : - vérification mutuelle (S63, S70) par chaque entité que l'autre entité possède un certificat statique valide au regard de la clé publique de l'infrastructure à clé publique, - génération (S61, S64) par chaque entité d'un certificat éphémère comprenant une clé publique éphémère signée avec une clé privée de l'entité, - vérification mutuelle (S63; S70) par chaque entité que le certificat éphémère de l'autre entité est valide au regard de son certificat statique, - génération d'une clé de session (k) par échange de clés Diffie-Hellman entre les deux entités, et utilisation de la clé de session pour crypter le canal de communication sécurisé. Procédé selon la revendication 19, comprenant une étape de collecte par le premier module de sécurité matériel (HSM1) d'une approbation émise par le dispositif approbateur (OPi, APi), l'étape de collecte comprenant les étapes consistant à : - au moyen du premier module de sécurité matériel (HSM1), envoyer (S8) un challenge aléatoire et le descriptif de la transaction au dispositif approbateur, - au moyen du dispositif approbateur, afficher à un utilisateur personne physique (USRi) une description de la transaction (S9), recueillir l'approbation de l'utilisateur (S10), signer (S11) le challenge ou une donnée comprenant le challenge avec une clé privée (dPi) puis envoyer (S12) la signature obtenue au premier module de sécurité matériel, et - au moyen du premier module de sécurité matériel, vérifier la validité de la signature, la transaction étant réputée approuvée si la signature est valide.