+150 XP

Qui détient réellement le pouvoir dans la stack SaaS

Une startup de cinq personnes vend un logiciel de gestion de projet à des entreprises du bâtiment. Ses clients pensent avoir une relation avec cette startup. Salesforce estime détenir la relation, parce que tout le pipeline commercial de la startup vit dans le CRM Salesforce (customer relationship management, le système qui suit les leads, les deals et les données clients). AWS (Amazon Web Services, la branche d'infrastructure cloud d'Amazon) estime aussi détenir la relation, parce que chaque ligne de code livrée par la startup tourne sur les serveurs d'Amazon, et que si AWS augmentait ses prix ou limitait l'accès, la startup cesserait d'exister en quelques jours.

Les trois ont raison. Les trois ont aussi tort, sur ce qui compte pour la marge. Cette leçon démêle cette contradiction : qui détient vraiment le pouvoir dans la stack SaaS (Software as a Service), et pourquoi la couche que les clients ne voient jamais devient discrètement celle qui capte le plus de profit.

La stack, en clair

Voyez le SaaS comme quatre couches empilées, chacune vendant à celle du dessus :

  1. Hyperscalers (AWS, Microsoft Azure, Google Cloud) : vendent du compute, du stockage et du réseau bruts.
  2. Plateformes installées (Salesforce, Microsoft 365, SAP, ServiceNow) : vendent les systèmes logiciels qui font tourner les entreprises, plus une marketplace où les applications plus petites se branchent.
  3. Éditeurs applicatifs (la startup de cinq personnes, et des milliers d'autres comme elle) : vendent un outil spécifique construit sur les deux autres couches, souvent intégré avec elles.
  4. Clients finaux : les entreprises qui utilisent réellement le logiciel au quotidien.

Chaque couche vend « la relation » au client dans un sens différent : infrastructure (existez-vous), plateforme (vous insérez-vous dans des workflows auxquels le client fait déjà confiance), application (résolvez-vous le point de douleur du jour). Dans cette chaîne, le pouvoir ne dépend pas de qui touche le client le plus visiblement. Il dépend de qui contrôle le coût de sortie.

Le coût de sortie est la véritable monnaie

Le coût de sortie, c'est ce qu'il coûte à un client, en argent, en temps ou en risque, de quitter un fournisseur. C'est le meilleur prédicteur, à lui seul, de qui détient le pouvoir en SaaS.

  • Les clients de la startup du bâtiment pourraient changer d'outil de gestion de projet en quelques semaines si un concurrent fait mieux.
  • La startup elle-même ne pourrait pas quitter AWS sans des mois de migration et un risque réel d'interruption de service.
  • Une grande entreprise qui utilise Salesforce ne peut pas en partir facilement : dix ans de données clients, de workflows sur mesure et de formation des collaborateurs y sont enfermés.

C'est pourquoi AWS, Azure et Google Cloud captent de plus en plus une marge démesurée alors qu'ils sont la couche la moins visible pour le client final. Personne n'achète un t-shirt parce qu'il était hébergé sur AWS. Mais la marge opérationnelle du segment cloud d'AWS a historiquement été très supérieure à celle de l'activité retail d'Amazon (Amazon publie la marge opérationnelle du segment AWS dans ses 10-K ; elle est couramment citée autour de 30 % ces dernières années, et doit être traitée comme une donnée publiée mais fluctuante, pas comme une constante). Comparez avec les éditeurs applicatifs classiques, dont beaucoup opèrent à des marges à un chiffre élevé ou dix et quelques pourcents, voire à perte, en cherchant la croissance.

L'hyperscaler vend la même commodité indifférenciée (du compute) à presque tout le monde, mais verrouille ses clients par le coût de sortie, des structures de remises liées à des engagements de volume, et la difficulté pure de déplacer données et workloads. Faible visibilité, fort levier.

L'arme des acteurs installés : la taxe de plateforme

Salesforce, Microsoft et SAP tiennent leur pouvoir d'un autre mécanisme : ils possèdent le workflow et la marketplace dont les éditeurs plus petits dépendent pour leur distribution.

Salesforce opère AppExchange, une marketplace où des applications tierces se branchent sur son CRM. Microsoft fait de même avec Teams et son équivalent d'App Store dans Microsoft 365. Ces plateformes permettent à une startup de cinq personnes d'atteindre des clients grands comptes auxquels elle ne pourrait jamais vendre en direct. En échange, l'acteur installé prélève généralement une part de revenu (l'AppExchange de Salesforce a historiquement utilisé des structures de l'ordre de 15 à 25 % de part de revenu sur les ventes d'abonnements passant par la marketplace, des chiffres qui varient selon les programmes et qu'il faut vérifier au regard des conditions partenaires actuelles) et, plus important, contrôle les règles d'accès : limites d'API (application programming interface, la porte technique qui permet à un logiciel externe de dialoguer avec une plateforme), permissions de partage de données, mise en avant.

On parle parfois de « taxe de plateforme » : l'acteur installé n'a pas besoin de construire chaque fonctionnalité lui-même. Il laisse un écosystème les construire, prend une commission et conserve la relation client au niveau du compte. Le bundling de longue date de Teams avec Office par Microsoft (qui a valu une plainte antitrust formelle de Slack auprès de l'UE en 2020, et a conduit la Commission européenne à ouvrir une enquête formelle en 2023 au titre des règles de concurrence de l'UE) en est un cas d'école : une plateforme installée qui gagne par son pouvoir de distribution, pas par la supériorité de son produit.

D'où vient réellement le levier de la startup

La startup de cinq personnes n'est pas sans pouvoir. Son levier vient d'une autre source : la spécificité et la douleur de sortie qu'elle crée *en aval*.

Si son outil de gestion de chantier s'incruste profondément dans la façon dont une entreprise générale planifie ses sous-traitants, suit ses permis et facture, cette entreprise fait désormais face à son propre coût de sortie, une couche plus bas dans la chaîne. Le pouvoir de la startup est réel mais étroit et durement acquis : elle doit prouver sa valeur chaque jour pour éviter d'être clonée par Salesforce elle-même (qui peut, et le fait souvent, absorber des fonctionnalités populaires d'AppExchange dans son produit cœur, une pratique parfois appelée « platform envelopment »).

C'est la tension centrale du fait de construire sur la plateforme d'un autre : la distribution maintenant, le risque d'extinction plus tard.

Les régulateurs commencent à regarder la stack, pas seulement le point de contact

Historiquement, les régulateurs antitrust se concentraient sur le fait qu'une entreprise détienne ou non une part de marché dominante dans une catégorie de produits. De plus en plus, aux États-Unis et dans l'UE, l'attention se déplace vers le pouvoir au niveau de la stack : le contrôle des couches par lesquelles les autres entreprises doivent passer.

Le Digital Markets Act de l'UE (DMA, en vigueur depuis 2023, appliqué par la Commission européenne) désigne certaines grandes plateformes comme « contrôleurs d'accès » et leur impose des obligations spécifiques, comme des exigences d'interopérabilité et de portabilité des données, précisément parce que la propriété d'une couche de plateforme confère un pouvoir que l'analyse ordinaire des parts de marché ne voit pas. Les activités cloud et app store de Microsoft, Google et Amazon ont toutes fait partie des discussions ou du périmètre du DMA, même si les services précisément désignés ont évolué et doivent être vérifiés au regard de la liste actuelle des gatekeepers de la Commission (présentation du DMA par la Commission européenne).

Aux États-Unis, la FTC (Federal Trade Commission) a de la même manière examiné les pratiques de bundling du cloud et des plateformes, même si le droit américain a traditionnellement exigé la preuve d'un préjudice au consommateur, plus difficile à établir pour des couches d'infrastructure que pour une hausse de prix visible.

Vérification des acquis

1. Dans la stack SaaS décrite, pourquoi l'hyperscaler, la plateforme installée et l'éditeur applicatif peuvent-ils tous prétendre de façon plausible « détenir » la relation client ?

2. Selon le cadrage de la leçon, qu'est-ce qui détermine réellement le pouvoir dans la stack SaaS ?

3. Une entreprise du bâtiment utilise chaque jour l'outil de gestion de projet de la startup de cinq personnes, mais le pipeline de la startup vit dans Salesforce et son code tourne sur AWS. Selon la logique de la leçon, pourquoi cet agencement pourrait-il sous-estimer le véritable pouvoir de négociation de la startup dans la stack ?

CHOIX MULTIPLES

4. Sélectionnez TOUTES les réponses correctes concernant les quatre couches de la stack SaaS telles que décrites dans la leçon.

Sélectionnez toutes les réponses correctes.

CHOIX MULTIPLES

5. Sélectionnez TOUTES les réponses correctes expliquant pourquoi le « coût de sortie » est décrit comme la véritable monnaie du pouvoir dans la stack.

Sélectionnez toutes les réponses correctes.

Une méthode simple pour lire le pouvoir dans n'importe quel deal SaaS

Pour évaluer qui détient le pouvoir entre deux entreprises de cette stack, posez trois questions :

  1. Qui contrôle les données ? Celui qui peut verrouiller ou exporter les données clients contrôle le coût de sortie.
  2. Qui contrôle la distribution ? Celui par qui le client découvre le produit (une marketplace, une plateforme, une force de vente directe) a du levier sur le vendeur.
  3. Qui est fongible ? Le compute est une commodité mais verrouillée par les termes contractuels et le coût de migration. Les applications sont différenciées mais facilement clonées par la plateforme au-dessus d'elles. Il est rare qu'une des parties soit en position de pouvoir pur et incontesté.

Appliqué à notre scène d'ouverture : la startup détient la relation client *émotionnelle* (support, décisions produit). Salesforce détient la relation *opérationnelle* (là où vivent les données au quotidien). AWS détient la relation *existentielle* (rien ne tourne sans lui). La marge afflue de manière disproportionnée vers celui dont la défaillance serait catastrophique et dont le remplacement est le plus difficile, c'est-à-dire d'ordinaire la couche infrastructure, même si elle est invisible pour le client final.

🎬 [VIDEO: "How AWS, Azure, and Google Cloud Actually Make Money" - youtube.com - chercher un contenu explicatif récent d'une chaîne tech business reconnue décomposant les structures de marge des hyperscalers et la façon dont la tarification cloud verrouille les clients grands comptes]

Points clés

  • Le pouvoir dans la stack SaaS est déterminé par le coût de sortie et le contrôle de la distribution, pas par celui que le client final voit ou à qui il parle le plus.
  • Les hyperscalers (AWS, Azure, Google Cloud) captent une marge démesurée malgré une faible visibilité client, parce que le lock-in sur le compute est coûteux et lent à défaire.
  • Les plateformes installées (Salesforce, Microsoft) prélèvent une « taxe de plateforme » sur les éditeurs plus petits en contrôlant l'accès à la marketplace, et peuvent absorber les fonctionnalités tierces qui marchent dans leur produit cœur.
  • Les petits éditeurs applicatifs construisent un pouvoir réel mais étroit en se rendant difficiles à retirer du workflow quotidien spécifique d'un client, pas en concurrençant l'infrastructure.
  • Les régulateurs (DMA de l'UE, FTC américaine) ciblent de plus en plus le pouvoir au niveau de la couche plateforme et des gatekeepers, et plus seulement la domination classique en part de marché, reflétant le fait que c'est la position dans la stack, et non la part de marché visible, qui crée aujourd'hui l'avantage concurrentiel.