Le guide complet des signatures électroniques en marque blanche pour SaaS

Si vous développez un produit SaaS avec des signatures électroniques, vous avez deux choix. Vous pouvez ajouter un outil de signature qui rappelle à vos utilisateurs qu'ils utilisent le logiciel de quelqu'un d'autre. Ou vous pouvez en faire un produit entièrement en marque blanche afin qu'il semble natif pour votre produit.

La plupart des développeurs pensent que le marquage en blanc consiste à échanger un logo. En pratique, c'est plus profond que cela. Un flux de signature électronique entièrement en marque blanche implique des domaines de messagerie personnalisés, des interfaces intégrées, un contrôle des notifications et une isolation sécurisée des locataires. Et pour les produits SaaS multi-locataires, vous avez besoin de la capacité de mettre en marque blanche non seulement pour votre marque, mais aussi pour celles de chacun de vos clients.

Ce guide couvre tout ce dont vous avez besoin pour créer une expérience de signature entièrement en marque blanche avec Firma.dev.

Deux niveaux de Marque Blanche

Voici ce que la plupart des APIs de signature électronique manquent : les entreprises SaaS ont souvent besoin d'une marque blanche à deux niveaux.

Niveau 1 : Votre marque. Les e-mails de signature proviennent de votre domaine. L'interface de signature est intégrée dans votre application. Vos clients ne voient jamais le fournisseur d'API sous-jacent.

Niveau 2 : Les marques de vos clients. Chacun de vos clients obtient sa propre expérience de marque. Leurs utilisateurs voient des emails de leur domaine, pas le vôtre. Les documents et les modèles sont isolés. L'utilisation est suivie séparément.

Une plateforme de gestion immobilière, par exemple, pourrait vouloir le Niveau 2. Chaque société de gestion immobilière sur la plateforme envoie des contrats de location depuis leur propre domaine (leases@acmeproperties.com), et leurs locataires ne voient jamais la marque de la plateforme.

Un SaaS RH pourrait seulement nécessiter le Niveau 1. L'expérience de signature est marquée pour la plateforme RH, et tous les employés de leurs clients interagissent avec cette seule marque.

Firma.dev prend en charge les deux. La clé réside dans les espaces de travail client.

Espaces de Travail Client : Séparation Sécurisée par Conception

Les espaces de travail client vous permettent de créer des environnements isolés pour chacun de vos clients. Chaque espace de travail a ses propres :

• Modèles

• Demandes de signature et documents

• Suivi de l'utilisation des enveloppes

• Configuration du domaine de messagerie

• Clé API (facultative, pour l'accès découplé à l'espace de travail)

Il n'y a pas d'exposition inter-espaces de travail. Le Client A ne peut pas voir les documents du Client B. Les modèles créés dans un espace de travail n'apparaissent pas dans un autre. Les rapports d'utilisation sont délimités par espace de travail.

Ce n'est pas juste une question d'organisation. C'est une question de sécurité et de conformité. Si vous servez des clients d'entreprise ou opérez dans des industries réglementées (santé, finance, juridique), l'isolation des données n'est pas optionnelle. Les espaces de travail vous fournissent cette séparation sans que vous ayez à construire vous-même une isolation des locataires.

Pour les plateformes SaaS qui gèrent des documents et des workflows spécifiques à chaque client, les espaces de travail sont fondamentaux. Vous créez un espace de travail pour chaque compte client, et tout découle de là.

Les Quatre Piliers du Marquage en Blanc

1. Domaines de messagerie personnalisés

Par défaut, les emails de demande de signature proviennent du domaine de Firma.dev. Avec des domaines de messagerie personnalisés, ils proviennent du vôtre.

Vous pouvez configurer cela à deux niveaux :

Niveau entreprise : Tous les espaces de travail héritent de votre domaine. Les e-mails sont envoyés en tant que documents@yourcompany.com.

Niveau espace de travail : Chaque espace de travail peut avoir son propre domaine. Les e-mails du Client A proviennent de sign@customera.com. Ceux du Client B proviennent de contracts@customerb.com.

La configuration implique l'ajout de records DNS (SPF, DKIM, DMARC) pour vérifier la propriété et assurer la délivrabilité. Une fois vérifié, le domaine est activé immédiatement.

Pour un guide pas-à-pas, voir Comment marquer en blanc vos emails de signature électronique et vos liens de signature.

2. Contrôle des notifications

Les domaines personnalisés changent l'expéditeur. Le contrôle complet des notifications vous permet de remplacer entièrement les e-mails.

Firma.dev envoie quatre types d'emails automatiques : demandes de signature, confirmations de complétion, avertissements d'expiration et notifications d'annulation. Vous pouvez désactiver tout ou partie de ces e-mails par demande de signature.

Désactivez-les, récupérez les URL de signature via l'API, et envoyez des notifications via votre propre système de messagerie. Cela vous permet de :

• Correspondre à vos modèles d'e-mails existants et à votre ton de marque

• Contrôler le timing pour les rappels et les suivis

• S'intégrer à votre infrastructure d'email transactionnel (SendGrid, Postmark, Customer.io)

• Déclencher des notifications basées sur votre propre logique métier

Certaines équipes utilisent des domaines personnalisés avec les modèles d'e-mails de Firma.dev. D'autres désactivent tout et contrôlent entièrement la couche de communication. Les deux fonctionnent.

3. Éditeurs intégrés

L'expérience de signature ne doit pas ressembler à une redirection vers un autre produit. Les éditeurs intégrés vous permettent de construire tout le workflow dans votre application.

Firma.dev propose deux composants intégrables :

Éditeur de modèle : Permettez à vos utilisateurs (ou à ceux de vos clients) de créer et d'éditer des modèles directement dans votre application. Téléchargez des documents, placez des champs de signature, définissez des rôles de signataire. Tout cela au sein de votre interface utilisateur.

Éditeur de demande de signature : Configurez les demandes de signature, ajoutez des destinataires, définissez l'ordre de signature, et prévisualisez les documents sans quitter votre produit.

Les deux éditeurs utilisent l'authentification JWT. Votre backend génère un jeton éphémère, et le frontal charge le composant avec ce jeton. Aucune clé API n'est exposée au client.

Pour les produits où la préparation des documents est un noyau central, les éditeurs intégrés valent l'effort de mise en œuvre. Votre application semble cohérente, et les utilisateurs ne changent jamais de contexte pour une interface tierce.

Voir Comment marquer en blanc une API de signature de documents dans votre produit SaaS pour une décomposition complète de l'implémentation.

4. Signature intégrée

Le dernier élément. Au lieu de rediriger les signataires vers une page de signature hébergée, vous intégrez l'interface de signature directement dans votre application.

Les utilisateurs signent des documents sans quitter votre domaine. Ils voient votre en-tête, votre navigation, votre design. L'interface de signature apparaît comme une partie homogène de votre produit.

C'est la solution de marquage en blanc complète. Combinée avec des domaines de messagerie personnalisés et un contrôle des notifications, vos utilisateurs ne rencontrent jamais la marque Firma.dev à aucun moment du workflow.

Choisir l'approche adéquate

Tous les produits n'ont pas besoin d'un marquage en blanc complet. Voici comment décider :

Si vous construisez un SaaS multi-locataire où chaque client a besoin de sa propre image de marque, ajoutez les Espaces de Travail Client à l'une de ces approches. Le modèle d'espace de travail s'adapte que vous serviez 10 clients ou 10 000.

Liste de contrôle de mise en œuvre

Avant de commencer :

Définissez la portée de votre marquage en blanc. Quels points de contact sont les plus importants ? Les emails ? L'interface de signature ? La création de modèles ? Cartographiez le parcours utilisateur et identifiez où le marquage tiers casserait l'expérience.

Décidez entre une marque unique et une multi-marque. Si vous avez besoin d'une image de marque par client, planifiez la structure de votre espace de travail tôt. Créez un espace de travail lorsque vous intégrez chaque client, et délimitez toute leur activité à cet espace.

Mettez en place les enregistrements DNS. Les domaines de messagerie personnalisés nécessitent des enregistrements SPF, DKIM et DMARC. Coordonnez-vous avec votre équipe ops ou les équipes informatiques de vos clients si vous configurez des domaines au niveau de l'espace de travail.

Générez des JWT sur le backend. Ne jamais exposer les clés API au client. Utilisez des jetons éphémères (1-4 heures) pour les composants intégrés.

Gérez la conformité. Le marquage en blanc ne change pas la validité légale des signatures. Firma.dev supporte l'ESIGN, l'UETA, l'eIDAS et d'autres cadres, quelle que soit la marque. Mais si vous désactivez l'écran des conditions de Firma.dev, assurez-vous que vos propres conditions couvrent le consentement des signatures électroniques.

Coût

Les plateformes de signature électronique d'entreprise facturent souvent des frais premium pour le marquage en blanc. Parfois, c'est un ajout séparé. Parfois, c'est verrouillé derrière un niveau de tarification supérieur.

Firma.dev inclut toutes les capacités de marquage en blanc à chaque niveau de tarification. Domaines de messagerie personnalisés, éditeurs intégrés, signature intégrée, Espaces de Travail Client. Tout est inclus.

Payez à l'utilisation à €0,029 par enveloppe. Pas de contrats. Pas de minimums. Pas de frais supplémentaires pour la marque de votre expérience de signature.

Commencer

Prêt à construire ? Le Guide de marquage en blanc Firma.dev dans notre documentation contient les détails techniques : les points de terminaison de l'API, des exemples de code et des options de configuration.

Ou entrez directement. Obtenez votre clé API et commencez à intégrer en heures, pas en semaines.