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 (MSIGN1, MSIGN2) configuré pour générer une signature (SIG1, SIG2) d’une transaction (T), 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 comprend : - un premier service de signature (MSIGN1) exécuté par un dispositif de signature intermédiaire (SIGNDV) et configuré pour générer une première signature (SIG1) à partir d’une première donnée secrète (SH1), - un second service de signature (MSIGN2) exécuté par un second module de sécurité matériel (HSM2) et configuré pour générer une seconde signature (SIG2) à partir d’une seconde donnée secrète (SH2), la signature d’une transaction étant une signature multipartite fonction de la première signature (SIG1) et de la seconde signature (SIG2), 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 moins au premier service de signature (MSIGN1). Système selon la revendication 1, dans lequel le premier module de sécurité matériel (HSM1), le dispositif de signature intermédiaire (SIGNDV) et le second module de sécurité matériel (HSM2) sont configurés de sorte que le second module de sécurité matériel (HSM2) ne reçoive jamais la transaction, le second module de sécurité matériel étant configuré pour générer la seconde signature (SIG2) sans avoir connaissance du contenu de la transaction. Système selon l’une des revendications 1 et 2, dans lequel le second module de sécurité matériel (HSM2) est configuré pour générer la seconde signature à partir de la première signature et de la seconde donnée secrète (SH2), la seconde signature formant la signature de la transaction. Système selon l’une des revendications 1 et 2, dans lequel la première signature (SIG1) et la seconde signature (SIG2) sont complémentaires, le système comprenant un service (BCAST) de diffusion de la transaction sur la blockchain configuré pour combiner (Fmpc) la première signature et la seconde signature afin d’obtenir la signature de la transaction. Système selon l’une des revendications 1 à 4, dans lequel le premier module de sécurité matériel (HSM1) est configuré pour, lorsque la règle de gouvernance est satisfaite, transmettre au moins au dispositif de signature intermédiaire (SIGNDV) un condensat (HT) de la transaction (T) généré par une fonction de hachage, et des données complémentaires permettant au dispositif de signature intermédiaire de générer la première signature (SIG1) à partir de ce condensat. Système selon la revendication 5, dans lequel les données complémentaires comprennent un chemin de dérivation déterministe hiérarchique (DRV) et une fonction de signature à utiliser pour générer la signature ou un identifiant (IDF) de cette fonction. Système selon l’une des revendication 1 à 6, dans lequel le premier module de sécurité matériel (HSM1) forme le dispositif de signature intermédiaire (SIGNDV) et exécute le premier service de signature (MSIGN1). Système selon l’une des revendications 1 à 7, 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 (HSM2) est agencé dans un second lieu à accès restreint différent du premier lieu. Système selon l'une des revendications 1 à 8, 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 à 9, 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 10, 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 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 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 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 10 et 11, 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) avec une clé privée (dPi) un challenge ou une donnée comprenant le challenge reçu du premier module de sécurité matériel (HSM1), puis envoyer (S12) la signature obtenue au premier module de sécurité matériel. 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), et - un service de signature (MSIGN1, MSIGN2) configuré pour générer une signature (SIG1, SIG2) d’une transaction (T), procédé dans lequel, en réponse à une demande de réalisation d’une transaction, le premier module de sécurité matériel (HSM1) 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 premier service de signature (MSIGN1) exécuté par un dispositif de signature intermédiaire (SIGNDV) et configuré pour générer une première signature (SIG1) à partir d’une première donnée secrète (SH1), - prévoir un second service de signature (MSIGN2) exécuté par un second module de sécurité matériel (HSM2) et configuré pour générer une seconde signature (SIG2) à partir d’une seconde donnée secrète (SH2), et - lorsque la règle de gouvernance est satisfaite, transmettre une demande de signature de la transaction au moins au premier service de signature (MSIGN1), - au moyen du premier service de signature (MSIGN1), générer la première signature (SIG1), - au moyen du second service de signature (MSIGN2), générer la seconde signature (SIG2), la signature de la transaction étant une signature multipartite fonction de la première signature (SIG1) et de la seconde signature (SIG2). Procédé selon la revendication 13, dans lequel le second module de sécurité matériel (HSM2) ne reçoit jamais la transaction, le second module de sécurité matériel étant configuré pour générer la seconde signature (SIG2) à partir de la première signature (SIG1) sans avoir connaissance du contenu de la transaction. Procédé selon l’une des revendications 13 et 14, dans lequel la première signature (SIG1) et la seconde signature (SIG2) sont cumulatives, le second module de sécurité matériel (HSM2) étant configuré pour générer la seconde signature à partir de la première signature et de la seconde donnée secrète (SH2), la seconde signature formant la signature de la transaction. Procédé selon l’une des revendications 13 et 14, dans lequel la première signature (SIG1) et la seconde signature (SIG2) sont complémentaires, le système comprenant une étape consistant à combiner la première signature et la seconde signature afin d’obtenir la signature de la transaction. Procédé selon l’une des revendications 13 à 16, comprenant l’étape consistant à, au moyen du premier module de sécurité matériel (HSM1), lorsque la règle de gouvernance est satisfaite, transmettre au moins au dispositif de signature intermédiaire (SIGNDV) un condensat (HT) de la transaction (T) généré par une fonction de hachage, et des données complémentaires permettant de générer la première signature (SIG1) à partir de ce condensat. Procédé selon la revendication 17, dans lequel les données complémentaires comprennent un chemin de dérivation déterministe hiérarchique (DRV) et une fonction de signature à utiliser pour générer la signature ou un identifiant (IDF) de cette fonction. Procédé selon l’une des revendications 13 à 18, 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 (HSM2) est agencé dans un second lieu à accès restreint différent du premier. Procédé selon l'une des revendications 13 à 19, dans lequel une règle de gouvernance autorise la signature d’une transaction en fonction d’un nombre d'approbations à recevoir de dispositifs approbateurs (OPi, APi).