Google Cloud détaille sa garde crypto à signatures partagées, encore en phase de préversion

Une offre présentée aux institutions, encore en préversion

Google Cloud précise le fonctionnement de Multi-party Compute, sa plateforme de protection des clés utilisées pour signer des transactions d’actifs numériques. Le service est discuté à l’occasion du symposium organisé à New York le 28 octobre 2026. Dans une mise à jour publiée le 29 octobre, Cointelegraph rapporte qu’un porte-parole de Google Cloud vise une disponibilité générale au début de 2027. Ce calendrier annoncé reste un objectif : la documentation officielle consultée classe toujours le produit en préversion, avec une fourniture en l’état et un support potentiellement limité.

La distinction intéresse les établissements qui évaluent une infrastructure de conservation. Une présentation technique et des essais ne signifient pas qu’un service est déjà ouvert à tous dans les conditions de sa future version commerciale. Les documents décrivent une plateforme de signature et de gouvernance, plutôt qu’un portefeuille grand public à installer. Ils ne constituent pas non plus, à eux seuls, une autorisation réglementaire de conserver les actifs de clients dans toutes les juridictions ou une garantie contre toute fraude.

Produire une signature sans réunir la clé complète

Le mécanisme repose sur des signatures à seuil. Des participants indépendants, appuyés sur du matériel sécurisé, génèrent et conservent chacun une part isolée du secret. Ils coopèrent pour produire une signature valide sans assembler la clé privée complète dans un emplacement unique. Selon Google, compromettre moins de participants que le seuil nécessaire ne permet pas de forger cette signature ou de reconstruire la clé. La continuité du service dépend toutefois du maintien d’un nombre suffisant de participants disponibles pour atteindre ce seuil.

La documentation mentionne la signature ECDSA sur la courbe secp256k1, utilisée notamment par Bitcoin, Ethereum et les réseaux compatibles EVM. La prise en charge d’Ed25519, associée notamment à Solana, y est indiquée comme à venir. Il faut distinguer cette capacité documentée de la version actuelle et les possibilités envisagées pour une disponibilité ultérieure. Une technologie destinée à plusieurs blockchains ne signifie pas que tous les réseaux, toutes les opérations et tous les mécanismes de signature sont déjà proposés dans les mêmes conditions.

Les règles internes orientent les signataires sans tout verrouiller

Le dispositif distingue des administrateurs, des auteurs de règles et des signataires, regroupés en équipes. Les politiques précisent les détenteurs de parts, le seuil de participation et leur lieu de conservation, par exemple dans le cloud ou dans les locaux du client. Des listes d’adresses et des règles de transaction peuvent aussi définir des destinations ou des limites. Ces fonctions organisent les responsabilités internes ; leur présence ne dispense pas l’établissement de choisir soigneusement ses droits, ses participants et ses procédures de récupération.

Une limite mérite une lecture attentive : le verdict automatique d’une règle de transaction guide les signataires, mais ne constitue pas un refus impossible à contourner. La documentation précise qu’une opération refusée peut encore être exécutée si suffisamment de signataires l’approuvent. La sécurité dépend donc également de cette gouvernance humaine et de l’indépendance réelle des participants. Avant la disponibilité générale annoncée, les institutions devront examiner ces paramètres et les conditions du service, plutôt que d’assimiler une clé répartie à une absence totale de risque.