Keychain expose une interface SolanaSigner unique pour tous les backends, donc
le choix est opérationnel, et non architectural — vous pouvez le modifier
ultérieurement via la configuration. C'est pourquoi partez de vos besoins, pas
d'un produit. Deux questions déterminent l'essentiel : où réside la clé
privée, et qui est autorisé à valider une signature avec elle ?
Il n'existe pas de backend universellement optimal. Chacun est mieux adapté à un ensemble particulier de contraintes — le cloud sur lequel vous opérez déjà, selon que vous souhaitez gérer une infrastructure de clés, et quels contrôles de garde et d'approbation vous êtes tenus d'avoir. Le schéma ci-dessous associe ces contraintes à un backend.
Ce guide couvre la signature côté backend (serveur). Lorsque vos utilisateurs finaux signent leurs propres transactions dans un navigateur, utilisez un portefeuille via le Wallet Standard à la place — voir Signature en production.
Arbre de décision
Le développement local et les tests n'ont besoin d'aucune de ces configurations — utilisez le backend Memory pour le prototypage, puis basculez vers l'un des backends de production ci-dessus via la configuration.
Parcourir les questions
Signez-vous pour votre propre application, ou pour vos utilisateurs finaux ?
Si vous provisionnez des portefeuilles dont les utilisateurs finaux sont propriétaires et qu'ils gèrent (applications grand public, flux d'intégration), utilisez un backend de portefeuille embarqué / géré — Privy, Turnkey, CDP, Crossmint ou Openfort. Ces solutions gèrent les portefeuilles par utilisateur et l'authentification en votre nom.
Si vous signez en tant que votre propre application — un payeur de frais, une trésorerie, une automatisation backend — continuez ci-dessous.
Avez-vous besoin d'une approbation multi-parties, d'une garde institutionnelle ou de contrôles réglementaires ?
Si les signatures doivent passer par une politique d'approbation, une limite de dépenses ou un flux de conformité avant d'être produites — ou si vous avez besoin d'un dépositaire réglementé détenant les clés — utilisez un backend MPC / garde institutionnelle : Fireblocks, Dfns, Para ou Utila. Ces solutions divisent ou conservent la clé et co-signent selon votre politique.
Si vous avez uniquement besoin d'une clé qui signe à la demande, continuez ci-dessous.
Souhaitez-vous conserver la clé vous-même, ou la confier à un fournisseur ?
Si un fournisseur cloud doit détenir la clé dans une infrastructure matérielle sécurisée et que votre politique IAM contrôle qui peut signer, utilisez le KMS de ce cloud :
- Sur AWS → AWS KMS
- Sur GCP → GCP KMS
Si vous souhaitez gérer vous-même l'infrastructure de clés — ou si vous êtes multi-cloud ou on-prem — utilisez HashiCorp Vault. Vous l'exploitez et l'auditez vous-même ; la clé reste dans le moteur Transit et signe à la demande.
Modèles de garde
Les backends se regroupent en cinq modèles de garde. Le flux ci-dessus vous place dans l'un d'eux.
- Auto-garde (en cours de processus) — votre application détient la clé privée brute. Pratique pour le développement, mais inadaptée à la production. Backend : Memory.
- Gestion de clés auto-hébergée — vous exploitez l'infrastructure de clés ; la clé y reste et signe à la demande. Backend : HashiCorp Vault.
- Cloud KMS / HSM — un fournisseur cloud stocke la clé dans une infrastructure matérielle sécurisée ; la clé ne quitte jamais le service et votre politique IAM contrôle qui peut signer. Backends : AWS KMS, GCP KMS.
- MPC & garde institutionnelle — la clé est divisée ou conservée chez un fournisseur, qui co-signe selon votre politique (approbations, limites). Backends : Fireblocks, Dfns, Para, Utila.
- Portefeuilles intégrés & gérés — un fournisseur gère les portefeuilles en votre nom, souvent pour l'intégration des utilisateurs finaux. Backends : Privy, Turnkey, CDP, Crossmint, Openfort.
Comparaison des backends
| Backend | Modèle de garde | Idéal pour | Remarques |
|---|---|---|---|
| Memory | Auto-garde (in-process) | Développement local, tests, CI | Clé brute dans le processus — ne pas utiliser en production |
| HashiCorp Vault | Gestion de clés auto-hébergée | Équipes gérant leur propre infrastructure de clés | Moteur Transit ; vous l'exploitez et l'auditez |
| AWS KMS | KMS cloud / HSM | Backends fonctionnant sur AWS | La clé ne quitte jamais KMS ; IAM contrôle la signature |
| GCP KMS | KMS cloud / HSM | Backends fonctionnant sur GCP | La clé ne quitte jamais KMS ; IAM contrôle la signature |
| Fireblocks | Garde MPC / institutionnelle | Trésoreries, exchanges, garde réglementée | Moteur de politiques et workflows d'approbation |
| Dfns | Infrastructure de wallets MPC | Wallets programmatiques avec contrôles de politique | Signature Ed25519 |
| Para | Wallets MPC | Applications souhaitant des wallets adossés à MPC | Clé API + ID de wallet |
| Utila | Garde MPC + co-signataire | Wallets Solana gérés par Utila | signMessage non pris en charge ; vous diffusez la tx |
| Privy | Wallets intégrés | Applications grand public intégrant des wallets | Wallets intégrés gérés par l'application |
| Turnkey | Gestion de clés non-custodiale | Signature programmatique avec contrôle de politique | Gestion de clés non-custodiale |
| CDP | Wallet géré (Coinbase) | Applications sur la plateforme développeur Coinbase | signMessage accepte uniquement les charges utiles UTF-8 |
| Crossmint | Wallets gérés | Marketplaces et applications à wallets gérés | Wallets smart et mpc ; signMessage non pris en charge |
| Openfort | Wallets backend intégrés | Wallets côté serveur | Clés stockées dans un TEE |
Scénarios d'entreprise
Une application unique a souvent besoin de plusieurs de ces éléments simultanément. Comme l'interface est identique, vous pouvez utiliser un backend différent par rôle sans modifier les points d'appel.
- Opérations de trésorerie — séparez un signataire opérationnel « chaud » d'un signataire de trésorerie « froid ». Protégez la trésorerie avec une conservation MPC ou un HSM cloud et exigez des politiques d'approbation avant les signatures de haute valeur.
- Flux d'approbation — les backends MPC et de conservation (ex. Fireblocks) imposent une approbation multi-parties avant qu'une signature soit produite.
- Conformité et audit — les KMS cloud (AWS/GCP) et Vault émettent des journaux d'audit de signature ; les dépositaires institutionnels ajoutent l'application des politiques et les rapports.
- Environnements réglementés — conservez le matériel de clé dans un HSM, un KMS ou un dépositaire institutionnel afin que les clés brutes ne touchent jamais votre application.
Consultez Bonnes pratiques de production pour exploiter ces backends en toute sécurité.
Is this page helpful?