Votre démonstration se passe bien. Le client apprécie le produit, puis pose une question qui paraît anodine : « Qui peut voir les données de mon équipe ? » Votre développeur répond que tout est sécurisé. Le client demande ensuite qui peut exporter les données, retrouver une modification ou retirer un accès. À ce moment-là, une belle interface ne suffit plus. Il faut pouvoir expliquer les fondations invisibles du produit.
Pour un SaaS B2B, le framework et le cloud ne résument pas l'architecture. Celle-ci détermine si vous pouvez promettre à un client que ses données restent séparées, que les bons collaborateurs disposent des bons accès et que votre équipe peut expliquer ce qui s'est passé en cas de litige.
Ce qu'un SaaS B2B doit pouvoir garantir
Un produit B2B entre dans les processus d'une entreprise et reçoit ses données. Le client ne vous interroge pas d'emblée sur votre modèle de données. Il veut savoir si ses équipes peuvent travailler sans exposer une information, perdre un accès ou payer pour une fonctionnalité verrouillée. Ces garanties dépendent pourtant du modèle de données choisi pour le SaaS.
Ces questions apparaissent lors d'un appel d'offres, d'une invitation temporaire ou d'une demande d'export. Si le produit n'a pas de réponse nette, l'équipe improvise. Le danger apparaît quand les cas particuliers s'accumulent.
La confusion la plus fréquente concerne l'authentification et l'autorisation. Savoir qui se connecte ne dit pas ce que cette personne peut voir ou modifier. OWASP rappelle qu'un utilisateur authentifié ne doit pas, pour autant, accéder à toutes les ressources possibles ; le contrôle doit porter sur l'action et la donnée concernées. Les bonnes pratiques OWASP sur l'autorisation recommandent notamment de refuser l'accès par défaut et de vérifier les droits à chaque demande.
Le fondateur n'a pas besoin de définir lui-même ces règles. Il doit savoir lesquelles engagent sa promesse commerciale et demander à l'équipe de les rendre lisibles. Une architecture saine n'élimine pas toutes les questions. Elle évite que chaque nouvelle demande client devienne une dérogation coûteuse.
Les cinq décisions qui créent la confiance
Le niveau de sophistication de ces cinq sujets dépend du stade du SaaS. Un prototype n'a pas besoin d'une gouvernance complète. Dès que plusieurs entreprises utilisent le produit, chacune doit toutefois obtenir des réponses claires.
Décision invisible | Ce que le client cherche à savoir | Ce que votre équipe doit expliciter |
|---|---|---|
| Séparation des données | Une autre entreprise peut-elle voir, deviner ou exporter mes données ? | Comment chaque action est rattachée au bon client et contrôlée |
| Rôles et permissions | Qui peut consulter, modifier, inviter ou supprimer ? | Les rôles disponibles, leurs droits et la règle appliquée aux cas particuliers |
| Traçabilité | Pouvons-nous retrouver qui a changé une donnée sensible et quand ? | Les actions enregistrées, leur durée de conservation et les personnes qui y accèdent |
Droits liés à l'abonnement | Le produit applique-t-il bien ce que le client a acheté ? | Le lien entre le plan payé, les fonctionnalités ouvertes et les changements de statut |
| Reprise du produit | Que se passe-t-il si un développeur ou un prestataire n'est plus disponible ? | Les accès, la documentation et les décisions qui permettent à une autre équipe de reprendre |
La séparation des données n'impose pas forcément une infrastructure distincte par client. L'équipe doit démontrer qu'une action réalisée dans l'espace d'une entreprise n'en touche pas une autre, notamment lors des recherches, exports et partages de fichiers.
Lorsque votre produit traite des données personnelles pour ses clients, cette séparation aide à documenter les traitements et les mesures de sécurité. La CNIL rappelle les éléments à tenir dans le registre des traitements, y compris comme sous-traitant. Le rôle exact de votre entreprise dépend de votre contexte et de vos contrats.
Les rôles suivent la même logique. Un dirigeant peut gérer les utilisateurs de son compte sans obtenir les droits internes de votre équipe. Le principe du moindre privilège, recommandé par OWASP, donne le minimum nécessaire à chaque personne. Mieux vaut commencer avec peu de rôles qu'accorder trop vite un accès administrateur.
La traçabilité couvre les actes qui peuvent créer un problème commercial, de sécurité ou de support. Le journal d'audit répond à la question « qui a fait cela ? ». AWS rappelle qu'une piste d'audit doit rester fiable et accessible à peu de personnes pour servir lors d'une investigation. Ses bonnes pratiques sur les journaux d'audit vont dans ce sens.
Le paiement confirme un achat, mais ne doit pas porter seul les droits d'accès. Le produit doit savoir quelle fonctionnalité ouvrir, ce qui change après une annulation et comment traiter une exception commerciale. Stripe appelle ces droits des « entitlements » et les relie au statut de l'abonnement. Sa documentation décrit ce lien. Cette séparation reste utile même sans Stripe.
La reprise ne doit pas attendre une crise. Votre entreprise doit détenir les comptes, les accès et le contexte nécessaires pour continuer à faire évoluer le produit. L'article sur le départ d'un développeur clé détaille cette reprise.
Si une règle de permission ne peut être expliquée que par une seule personne, cette règle est un risque business.
Comment vérifier ces décisions sans lire une ligne de code
Inutile de demander un diagramme à chaque sprint. Ces décisions doivent toutefois exister dans un format lisible et transmissible à un nouveau développeur, un client important ou un auditeur. Une page claire par sujet vaut mieux qu'une explication orale qui disparaît au prochain départ.
Commencez par un parcours réel. Prenez une donnée sensible, par exemple un document client, et demandez qui peut le voir, le modifier, l'exporter et le supprimer. Faites le même exercice avec un changement d'abonnement, l'invitation d'un nouvel utilisateur et le départ d'un administrateur. Les zones floues apparaissent vite : « normalement », « je crois que » et « il faudrait vérifier » sont des réponses utiles, parce qu'elles montrent où votre produit dépend encore d'une hypothèse.
Demandez ensuite une règle et une preuve. La règle répond à « qui peut faire quoi ? ». La preuve répond à « comment le savons-nous ? ». Pour une permission, cela peut être un test qui empêche un utilisateur de franchir une limite. Pour une facture, c'est un événement qui met à jour le droit d'usage. Pour une action sensible, c'est un historique consultable. Vous n'avez pas besoin de relire le code. Vous avez besoin de savoir que le comportement important est vérifié.
N'en faites pas un audit permanent. Le bon rythme dépend du produit. Un SaaS qui ajoute des clients B2B, une nouvelle intégration ou une offre entreprise a intérêt à revoir ces cinq sujets avant la signature ou le lancement. Un prototype utilisé par une seule équipe peut documenter les choix essentiels et reporter les mécanismes plus lourds. Commencer simple reste sain si l'équipe sait ce qu'elle reporte et pourquoi.
Les questions à trancher avant le prochain contrat
Avant de promettre une fonctionnalité ou une intégration à un client important, prenez une heure avec votre équipe et posez cinq questions. Peut-on expliquer où vivent les données de ce client et qui peut y accéder ? Les rôles correspondent-ils aux responsabilités réelles de ses utilisateurs ? Pourra-t-on retrouver une action contestée ? Le produit accordera-t-il et retirera-t-il les droits au bon moment ? Une autre équipe pourrait-elle reprendre ces règles sans dépendre d'une seule personne ? Si la demande vient d'un prospect Enterprise, utilisez ensuite cette méthode pour préparer votre SaaS au contrat grand compte sans surcharger la roadmap.
Ces questions ne demandent pas une réponse parfaite. Elles obligent à choisir ce qui doit être vrai avant de vendre. Si une réponse manque, nommez le risque, le responsable et l'échéance. La contrainte d'architecture peut alors entrer dans la roadmap sans voler la place des besoins produit.
Quand ces fondations deviennent un prérequis commercial, il vaut mieux les traiter comme un chantier produit à part entière. C'est précisément le rôle d'un développement SaaS B2B cadré : sécuriser permissions, données, facturation et reprise sans reconstruire toute l'application.
Ce qu'il faut retenir
Les décisions d'architecture les plus coûteuses sont souvent invisibles au moment où le produit paraît fonctionner. La séparation des données, les permissions, la traçabilité, les droits liés à l'abonnement et la reprise déterminent pourtant votre capacité à rassurer un client B2B et à faire évoluer le produit sans multiplier les dérogations.
Vous n'avez pas besoin de tout industrialiser maintenant. Vous devez pouvoir nommer les règles qui protègent le prochain contrat, montrer comment elles sont vérifiées et savoir qui les maintient. Le reste peut rester simple tant que cette simplicité est assumée.
Questions fréquentes
Faut-il une base de données par client pour faire du B2B ?
Non. Plusieurs modèles existent. Le choix dépend notamment du niveau d'isolation attendu, du volume, du coût et de vos contraintes contractuelles. Le point à vérifier est que l'équipe peut démontrer qu'un client ne peut pas accéder aux données d'un autre, quel que soit le modèle retenu.
À quel moment faut-il ajouter des rôles et permissions ?
Dès que plusieurs personnes n'ont pas les mêmes responsabilités dans le produit. Commencez avec les rôles qui correspondent à des décisions réelles, puis ajoutez de la finesse lorsqu'un besoin client ou un risque le justifie. Évitez de créer des rôles uniquement parce qu'ils figurent dans un modèle générique.
Un journal d'audit est-il nécessaire pour tous les SaaS ?
Pas avec le même niveau de détail. Dès qu'une action peut créer un litige, modifier une donnée sensible ou ouvrir un accès, vous devez pouvoir l'expliquer. Le périmètre et la conservation du journal dépendent ensuite de votre produit, de vos contrats et de vos obligations.
Conclusion
Si vous préparez un contrat B2B, une intégration ou une montée en gamme, parlons-en pendant 30 minutes pour identifier les fondations à sécuriser sans sur-construire votre produit.