Architecture SaaS B2B : 5 choix invisibles

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.

J'ai vu ce moment arriver juste après un premier gros contrat. Le produit fonctionnait, les utilisateurs étaient satisfaits, mais personne n'avait décidé précisément ce qu'un administrateur pouvait faire, ce qui se passait après un impayé, ni comment prouver l'origine d'une modification sensible.

Le problème venait de décisions jamais formulées. Chaque réponse existait quelque part, dans une règle codée, un email ou la tête du développeur qui avait lancé le projet.

Pour un SaaS B2B, l'architecture ne se résume pas au framework ou au cloud choisi. Elle 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 vend souvent plus qu'une fonctionnalité. Il entre dans les processus d'une entreprise, reçoit ses données et devient une pièce de son quotidien. Le client ne vous demande pas d'emblée votre modèle de données. Il vous demande si ses équipes peuvent travailler sans exposer une information à la mauvaise personne, perdre un droit d'accès ou payer pour une fonctionnalité qui reste verrouillée.

Ces questions apparaissent parfois lors d'un appel d'offres. Elles arrivent aussi plus simplement : un responsable veut inviter un prestataire pour une semaine, une équipe finance demande un export, ou un client souhaite savoir qui a modifié une règle métier. Si le produit n'a pas de réponse nette, l'équipe improvise. Cette improvisation coûte rarement cher le premier jour. Elle devient dangereuse 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

Les cinq sujets suivants ne demandent pas le même niveau de sophistication selon le stade du SaaS. Un prototype n'a pas besoin d'une gouvernance complète. En revanche, dès que plusieurs entreprises utilisent le produit, chacune doit pouvoir obtenir des réponses claires.

La séparation des données est la première promesse. Elle ne signifie pas forcément une infrastructure distincte par client. Elle signifie que l'équipe peut démontrer qu'une action réalisée dans l'espace d'une entreprise ne touche pas une autre entreprise. C'est particulièrement important pour les recherches, les exports, les pièces jointes et les liens partagés, là où une règle oubliée peut traverser les frontières entre clients.

Lorsque votre produit traite des données personnelles pour le compte de ses clients, cette séparation aide aussi à documenter les traitements, les destinataires et les mesures de sécurité. La CNIL rappelle les éléments à tenir dans le registre des traitements, y compris pour les activités menées en tant que sous-traitant. Ce n'est pas un avis juridique : 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 vouloir gérer les utilisateurs de son compte sans obtenir les droits internes de votre équipe. Un collaborateur peut avoir besoin de préparer une action sans pouvoir la valider. Le principe du moindre privilège, recommandé par OWASP, consiste à donner le minimum nécessaire à chaque personne. Commencer avec peu de rôles est souvent plus sûr que d'accorder un rôle administrateur large parce qu'il est plus rapide à implémenter.

La traçabilité doit couvrir les actes qui peuvent créer un problème commercial, de sécurité ou de support : changement de permission, export, modification d'une donnée contractuelle ou action réalisée par un administrateur. Les journaux d'audit deviennent utiles le jour où un client demande « qui a fait cela ? ». AWS rappelle qu'une piste d'audit doit rester fiable pour servir lors d'une investigation ; cela implique aussi de limiter l'accès à ces journaux. Les bonnes pratiques AWS sur les journaux d'audit vont dans ce sens.

La facturation mérite une décision séparée. Le paiement confirme un achat ; il ne doit pas être l'unique endroit où vivent les droits d'accès. Votre produit doit savoir quelle fonctionnalité est ouverte pour quel client, ce qui change après une annulation et comment gérer une situation commerciale atypique sans casser le reste. Stripe appelle ces droits des « entitlements » et les relie explicitement aux fonctionnalités du produit et au statut de l'abonnement. La documentation Stripe sur les entitlements décrit ce lien. Même si vous n'utilisez pas Stripe, la séparation entre paiement et droit d'usage évite beaucoup de règles fragiles.

Enfin, 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 les premières semaines d'une reprise. Ici, l'enjeu est plus simple.

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

Vous n'avez pas à demander un diagramme à chaque sprint. En revanche, ces décisions doivent exister dans un format que vous pouvez lire et remettre à 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é.

Évitez de transformer cela en 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 est 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 ?

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. C'est ainsi qu'une contrainte d'architecture entre dans la roadmap sans voler la place des besoins produit.

Un prospect B2B sérieux ne vous demande pas une architecture compliquée pour le plaisir. Il cherche à savoir si vous contrôlez ce qui arrivera à ses données, à ses utilisateurs et à son activité une fois le contrat signé.

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.