Pendant longtemps, la promesse du SaaS était assez simple.

Vous utilisez le logiciel. Nous nous occupons du reste.

Nous opérons l'application, choisissons l'infrastructure, hébergeons la base de données, assurons les sauvegardes et faisons évoluer le produit.

Le client achète un service terminé.

Cette promesse reste valable. Mais, dans les discussions avec les grands groupes, je vois apparaître de plus en plus de demandes qui la font évoluer.

« Est-ce que les données peuvent rester dans notre environnement Azure ? »

« Peut-on utiliser notre propre SQL Server ? »

« Peut-on utiliser nos propres clés de chiffrement ? »

« Peut-on gérer les utilisateurs et leurs droits depuis notre IAM ? »

« Peut-on utiliser notre contrat et notre fournisseur de LLM ? »

« Peut-on utiliser notre fournisseur d'email ou de SMS ? »

« Peut-on envoyer les événements de sécurité dans notre SIEM ? »

Ces demandes peuvent sembler très différentes.

En réalité, elles racontent souvent la même chose.

Les grands groupes veulent continuer à acheter du SaaS, mais ils veulent reprendre le contrôle de certaines briques.

Et ce changement n'est pas seulement technique ou réglementaire.

Il est aussi culturel.

Quand la culture du client devient une composante du produit

Prenons une demande très simple :

« Je veux savoir qui se connecte à l'application. »

Techniquement, ce n'est pas forcément une fonctionnalité spectaculaire.

Mais derrière cette phrase peuvent se trouver un audit ISO, une politique de sécurité, une équipe cybersécurité, un SIEM central, une procédure d'investigation ou simplement une culture d'entreprise dans laquelle chaque accès doit être traçable.

Même chose avec la gestion des utilisateurs.

Le client peut ne pas vouloir administrer les droits dans chaque SaaS qu'il achète. Il veut que les identités, les groupes et parfois les droits soient pilotés depuis son propre IAM.

On pourrait regarder certaines de ces demandes et conclure qu'elles ne créent aucune valeur métier.

Et ce serait vrai.

Mais ce serait passer à côté du sujet.

Le produit que nous construisons pour résoudre le problème métier du client n'est qu'une partie de ce qu'il achète réellement.

C'est là que la distinction entre core product et whole product devient utile.

Le core product concentre ce qui fait réellement notre valeur : notre connaissance du métier, nos règles, nos workflows, notre orchestration, notre capacité à résoudre un problème mieux qu'une alternative.

Le whole product correspond à tout ce qu'il faut autour de cette valeur pour qu'un client donné puisse effectivement acheter, déployer et exploiter le produit.

Le SSO n'est probablement pas notre différenciation.

Le SIEM non plus.

La résidence des données non plus.

La capacité à utiliser l'IAM du client non plus.

Mais l'absence de l'un de ces éléments peut suffire à empêcher une vente.

Ils ne créent pas nécessairement la valeur.

Ils permettent à cette valeur d'entrer dans l'entreprise.

« Je veux utiliser votre SaaS, mais garder ma base chez moi »

Le cas le plus intéressant est probablement celui de la base de données.

Imaginons un logiciel de paie.

Tout le monde comprend immédiatement la nature des données concernées : salaires, contrats, informations personnelles, organisation de l'entreprise.

Dans le modèle SaaS classique, l'éditeur opère le logiciel et la base qui va avec.

Maintenant, imaginons un grand groupe qui nous dit :

Nous voulons votre application, mais les données doivent rester dans une base SQL Server ou Azure SQL située dans notre environnement Azure.

Ce n'est pas une demande absurde.

Et, dans notre cas, elle est même cohérente avec le marché que nous voulons servir : l'immense majorité de nos clients ciblés évoluent déjà dans l'écosystème Microsoft.

Le moteur du SaaS resterait opéré par l'éditeur.

Mais sa base pourrait être hébergée dans l'environnement du client.

Pourquoi un client demanderait-il cela alors que nous savons parfaitement héberger une base ?

Parce que sa question n'est pas nécessairement :

« Êtes-vous capables de bien héberger mes données ? »

Elle peut être :

« Est-ce que mes données restent sous le contrôle de mon organisation ? »

Le client veut parfois que la ressource se trouve dans son abonnement Azure.

Il veut appliquer ses règles réseau.

Ses politiques de sécurité.

Ses clés.

Ses mécanismes d'inventaire.

Ses contrôles.

Ses standards internes.

Et surtout pouvoir dire à son RSSI, à son auditeur ou à son organisation :

« Ces données restent chez nous. »

Ce n'est pas toujours une obligation réglementaire.

Cela peut être simplement une condition pour que l'entreprise accepte le produit.

Contrôler l'emplacement des données ne signifie pas contrôler le produit

Donner davantage de contrôle au client introduit néanmoins une frontière qu'il faut préserver.

Le moteur métier reste chez l'éditeur.

Sa propriété intellectuelle reste chez l'éditeur.

Et surtout, sa capacité à faire évoluer le produit doit rester chez l'éditeur.

Prenons les migrations de base.

Supposons que nous ajoutions une fonctionnalité qui nécessite une nouvelle colonne, un index ou une évolution du schéma.

Si chaque mise en production exige d'envoyer une procédure à l'équipe du client, d'attendre une validation, de réserver une fenêtre de maintenance puis de vérifier manuellement que la migration a été appliquée, le modèle ne tient pas.

Il est déjà difficilement compatible avec un SaaS qui livre plusieurs fois par semaine.

Et il le sera encore moins demain.

Le développement logiciel assisté par l'IA augmente déjà notre capacité à produire, tester et modifier du logiciel. Il est raisonnable de penser que la cadence de livraison continuera d'augmenter.

Construire aujourd'hui une architecture qui nécessite davantage d'interventions humaines chez chaque client à chaque évolution irait exactement dans le sens inverse.

Très vite, un client applique la migration mardi.

Un autre attend vendredi.

Un troisième la reporte au mois suivant.

On obtient alors plusieurs versions du moteur, plusieurs états du schéma et une complexité qui grandit à chaque release.

On finit par perdre l'un des avantages structurels du SaaS : faire évoluer en continu un produit commun pour tous les clients.

Or le client qui demande à conserver ses données dans son environnement ne demande pas nécessairement à gérer nos migrations.

Il veut le contrôle sur où vivent ses données.

Pas sur la manière dont notre produit évolue.

La frontière devient alors assez simple :

le client contrôle où vivent ses données ; l'éditeur contrôle comment le produit évolue.

Le BYO-Database n'est donc réellement compatible avec le SaaS que si les migrations peuvent rester automatisées et pilotées par l'éditeur, dans un cadre de sécurité accepté par le client.

Le contrôle déplace aussi les responsabilités

Déplacer la base dans l'environnement du client produit une autre conséquence.

Une partie de l'infrastructure dont dépend notre service n'est plus entièrement sous notre contrôle.

Et le jour où l'application tombe, cette distinction devient très concrète.

Est-ce notre moteur ?

La base SQL Server du client ?

Azure ?

Une règle réseau qui vient d'être modifiée ?

Un certificat ?

Une configuration IAM ?

Une saturation des connexions ?

Un quota ?

Un problème de latence ?

Dire :

« La base est chez le client, ce n'est pas notre problème »

ne fonctionne pas.

Pour l'utilisateur, c'est notre SaaS qui ne fonctionne plus.

Le BYO impose donc une exigence qui me paraît non négociable : nous devons pouvoir monitorer suffisamment la base et sa connectivité pour comprendre d'où vient un incident.

Cela ne veut pas dire administrer toute l'infrastructure à la place du client.

Cela veut dire disposer des signaux nécessaires : disponibilité, latence, erreurs de connexion, saturation, état de santé, événements utiles au diagnostic.

Cette observabilité est indispensable opérationnellement.

Mais elle l'est aussi contractuellement.

Si notre SLA exclut les pannes provoquées par une ressource sous contrôle du client, nous devons être capables de déterminer objectivement qu'un incident venait bien de cette ressource.

Le partage des responsabilités n'existe réellement que si l'on peut attribuer les incidents.

Le client paie sa base. Pourtant son SaaS peut coûter plus cher.

C'est là qu'apparaît un paradoxe intéressant.

Le client peut payer directement son Azure SQL ou son SQL Server.

On pourrait donc penser :

Puisqu'il paie lui-même la base, notre SaaS devrait coûter moins cher.

Pas nécessairement.

Notre coût de service ne se limite pas au prix de l'infrastructure.

Supporter des bases dans les environnements clients peut nous obliger à gérer davantage de variantes.

Versions différentes.

Contraintes réseau différentes.

Mécanismes de réplication.

Sauvegardes.

Snapshots.

Restaurations.

Droits.

Monitoring.

Configurations spécifiques.

Et surtout davantage de scénarios à comprendre quand quelque chose ne fonctionne plus.

Externaliser une ressource peut donc réduire notre coût d'infrastructure direct tout en augmentant notre coût de service.

Les sauvegardes illustrent bien ce partage.

Si nous nous engageons à gérer les backups et à garantir la restauration d'une base située dans l'environnement du client, nous prenons une responsabilité supplémentaire.

Elle demande de la technologie.

Des tests.

Du monitoring.

Des procédures de reprise.

Cette responsabilité a donc un coût et doit être facturée.

À l'inverse, le client peut choisir de gérer lui-même ses sauvegardes.

Dans ce cas, il faut que les responsabilités soient explicites : rétention, qualité des backups, restauration et conséquences d'un backup inutilisable doivent relever de lui.

Le BYO ne fait pas disparaître les responsabilités.

Il oblige simplement à dire beaucoup plus précisément qui porte lesquelles.

Toutes les briques n'ont pas besoin de rester chez nous

Une fois ce raisonnement posé, la base de données apparaît comme le cas le plus difficile d'un phénomène plus général.

Une question simple permet de réfléchir aux autres briques :

si je remplace ce fournisseur par un autre, est-ce que la valeur de mon service change ?

Prenons l'envoi d'emails.

Si nous remplaçons notre fournisseur d'email par celui du client, la valeur métier de notre produit change-t-elle ?

Probablement pas.

Le message est toujours envoyé au bon moment parce que notre moteur a décidé qu'il devait l'être.

Même chose pour un SMS.

Même chose, dans certains cas, avec un LLM.

Notre produit peut fournir par défaut un modèle d'IA.

Mais un grand groupe peut préférer utiliser son propre contrat Azure OpenAI, ses propres clés ou un fournisseur déjà approuvé.

Si notre valeur se trouve dans le workflow métier, le contexte, les règles, les données et l'orchestration, changer le modèle d'exécution ne doit pas déplacer le cœur du produit.

Cela ne veut pas dire que tous les fournisseurs sont parfaitement interchangeables.

Un modèle peut être plus performant qu'un autre.

Un fournisseur d'email peut avoir une meilleure délivrabilité.

Mais la bonne question reste :

est-ce cette brique qui porte la valeur pour laquelle le client achète notre produit ?

Si remplacer un fournisseur détruit la valeur du service, il se trouve probablement trop près de notre core product pour être librement substituable.

Si son remplacement ne change pas la valeur métier fondamentale, il peut devenir un candidat à la configuration, à la substitution ou au BYO.

Toutes les substitutions ne coûtent pas la même chose

Il reste une différence importante.

Une gateway d'email est relativement stateless.

Même chose pour un provider SMS.

Et un LLM peut l'être aussi, à condition que la mémoire durable, le contexte métier et les décisions restent dans notre produit.

Une base de données est différente.

Elle contient l'état durable du système.

On ne passe pas d'un SQL Server à un autre en changeant simplement une clé API.

Il faut migrer les données.

Garantir leur cohérence.

Prévoir la reprise.

Gérer les sauvegardes.

Parfois la réplication.

La substituabilité n'est donc pas binaire.

C'est un gradient.

Une brique peut être non différenciante pour notre produit tout en étant extrêmement importante d'un point de vue opérationnel.

C'est particulièrement vrai pour la base.

Ne pas transformer le whole product en catalogue

À partir de là, la tentation pourrait être de construire toutes les possibilités.

Azure.

AWS.

GCP.

SQL Server.

PostgreSQL.

Oracle.

Cinq fournisseurs d'IA.

Trois fournisseurs d'email.

Quatre gateways SMS.

Ce serait probablement une erreur.

La bonne question n'est pas :

« Que pouvons-nous techniquement supporter ? »

Mais :

« Que devons-nous supporter pour les clients que nous avons choisi de servir ? »

Si 90 % des grands groupes que nous ciblons sont déjà structurés autour de Microsoft et Azure, commencer par Azure et SQL Server a du sens.

Pas parce que SQL Server serait intrinsèquement meilleur qu'une autre base.

Mais parce que cette configuration est celle qui maximise probablement notre capacité à vendre sur le marché que nous ciblons.

À l'inverse, supporter une base ou un cloud que personne dans notre segment ne demande n'ajoute pas forcément de valeur.

La largeur du support technologique n'est pas un objectif en soi.

Elle doit suivre le positionnement commercial.

Le whole product n'est pas une checklist universelle du « SaaS enterprise parfait ».

Il est la traduction concrète de la question :

qu'est-ce qu'il faut ajouter autour de notre core product pour que les clients que nous avons choisi de servir puissent réellement l'acheter ?

Comprendre le besoin derrière la demande

Cela ne veut pas dire qu'il faille répondre littéralement à chaque demande client.

Quand un grand groupe dit :

Je veux mes données dans mon Azure.

La bonne réponse n'est pas immédiatement :

D'accord, construisons du BYO-Database.

Il faut comprendre pourquoi.

Est-ce une obligation réglementaire ?

Une exigence de résidence ?

Une politique du RSSI ?

Un besoin de contrôler les clés ?

Une contrainte d'audit ?

Une volonté de réversibilité ?

Ou simplement une culture selon laquelle les données sensibles doivent rester sous contrôle direct de l'entreprise ?

La solution peut dépendre de cette réponse.

Une région dédiée peut parfois suffire.

Du Customer Managed Key peut parfois suffire.

Un environnement single-tenant peut parfois suffire.

Dans d'autres cas, il faudra réellement héberger la base dans le tenant du client.

Comprendre pourquoi le client demande du contrôle permet de proposer le bon niveau de contrôle.

Mais cela ne change pas le constat de départ.

Si l'on décide de vendre aux grands groupes, leur culture de gouvernance fait partie du marché.

On ne peut pas vouloir leurs volumes, leurs budgets et leurs contrats tout en considérant leurs contraintes d'audit, de sécurité ou de contrôle comme des détails gênants.

Ce n'est pas une stratégie d'infrastructure

C'est probablement le point le plus important.

À première vue, tout ce sujet ressemble à une discussion d'architecture.

Où héberger SQL Server ?

Comment connecter le moteur ?

Comment migrer le schéma ?

Comment monitorer ?

Comment gérer les backups ?

Ce sont de vraies questions.

Mais elles viennent après une autre :

quels clients avons-nous décidé de servir ?

Le core product crée la valeur.

Le positionnement choisit le marché.

Et le whole product rend le core product compatible avec la réalité de ce marché.

Si les grands groupes que nous voulons servir ont une culture forte du contrôle de leurs données, de leurs identités, de leurs clés et de leurs fournisseurs, alors certaines de ces capacités doivent probablement devenir une composante de notre whole product.

Pas parce que le BYO serait meilleur que le full-managed.

Le full-managed doit probablement rester le choix par défaut.

Il reste plus simple à exploiter, plus homogène et plus facile à faire évoluer.

Le BYO devient une option lorsque le marché le justifie.

Et son périmètre doit être décidé de la même manière.

Nous n'avons pas besoin de rendre chaque composant interchangeable.

Nous n'avons pas besoin de supporter toutes les technologies.

Nous devons surtout identifier les contraintes qui empêchent réellement les clients que nous avons choisi de servir d'acheter notre produit.

Puis décider lesquelles nous voulons lever.

Le BYO n'est donc pas d'abord une stratégie d'infrastructure. C'est une décision de whole product et de positionnement commercial.

La conséquence technique peut être un SaaS plus modulaire.

Le moteur reste sous notre contrôle.

Certaines données restent chez le client.

Certains fournisseurs deviennent substituables.

Certaines responsabilités changent de main.

Mais ce n'est pas le point de départ.

Le point de départ reste le marché.

On ne cherche pas à donner tous les choix possibles à tous les clients. On cherche à construire le whole product qui permet à notre core product d'être acheté par les clients que nous avons décidé de servir.