Pourquoi le prix par utilisateur pénalise les équipes Salesforce

Réponse courte : la tarification par siège ne coûte pas seulement de l'argent, elle change les comportements. Les équipes achètent moins de sièges qu'elles n'ont de personnes, les releases passent par un ou deux power users, et la file d'attente qui se forme coûte plus cher que les licences économisées. Sur Salesforce, l'effet est plus dur qu'ailleurs, parce que les personnes exclues pour économiser des sièges sont justement celles qui font le travail.

Qu'est-ce que la tarification DevOps par siège, et pourquoi domine-t-elle ?

Par siège signifie que vous payez par utilisateur nommé ayant accès à l'outil. C'est le modèle par défaut de l'outillage développeur parce qu'il se prévisionne facilement et qu'il fait croître le revenu avec les effectifs. Sa faiblesse est bien documentée : le coût suit la taille de l'équipe et non la valeur livrée, et la valeur suit rarement les effectifs (Schematic).

En DevOps Salesforce, cette faiblesse est plus aiguë, car le processus de release n'est pas une activité réservée aux développeurs. Les personnes qui ont légitimement besoin de déplacer un changement :

• Les admins qui construisent en déclaratif et n'ouvrent jamais un terminal.
• Les consultants qui travaillent sur plusieurs orgs clientes.
• Les testeurs qui ont besoin d'un déploiement vers une sandbox de recette.
• Les release managers qui possèdent le calendrier mais pas le code.
• Les product owners qui veulent simplement savoir ce que contient la prochaine release.

Que se passe-t-il vraiment quand une équipe achète des sièges ?

Personne ne licencie tout le monde. Le budget passe pour les deux profils les plus techniques, et tous les autres font transiter leurs demandes par ces deux-là. Trois conséquences suivent, dans cet ordre :

1. Une file d'attente se forme. Les déploiements attendent désormais un créneau dans un agenda, pas la fin des travaux.
2. La connaissance se concentre. Les deux personnes licenciées sont les seules à comprendre le pipeline, ce qui est un risque RH bien avant d'être un problème de coût.
3. Les contournements reviennent. Change sets et modifications manuelles réapparaissent pour les "petits" changements, et la dérive recommence.

L'outil avait été acheté pour supprimer un point unique de défaillance dans le processus de release. La tarification par siège le recrée, puis vous facture pour l'élargir.

Combien coûte réellement ce goulot ?

Faites le calcul avec vos propres salaires plutôt qu'avec ceux d'un éditeur. La forme du calcul :

• Comptez les personnes qui touchent à une release. Développeurs, admins, consultants, testeurs, release manager. Huit est courant pour une équipe Salesforce de taille moyenne.
• Comptez les sièges que vous acheteriez vraiment. En général deux ou trois.
• Chiffrez l'écart en temps, pas en licences. Si un ingénieur senior passe deux jours par semaine à exécuter les déploiements des autres, cela représente environ quarante pour cent d'un salaire senior consacré à gérer une file d'attente.
• Ajoutez le délai. Chaque changement qui attend trois jours une fenêtre de déploiement, ce sont trois jours de valeur non livrée.

Côte à côte, les stacks au siège et les offres à tarif fixe divergent vite quand l'équipe grandit (analyse de coûts de Hyperping). Mais l'écart de licences n'est que la petite moitié de l'argument. La moitié coûteuse, c'est le comportement que le modèle encourage.

Pourquoi les équipes en croissance sont-elles les plus touchées ?

Trois multiplicateurs s'additionnent :

• Les effectifs. Chaque recrutement devient une décision tarifaire, donc la croissance se transforme en discussion budgétaire récurrente sur qui a le droit de déployer.
• Le nombre d'orgs. Cabinets et ISV gèrent plusieurs orgs. Une tarification qui suit les utilisateurs et les orgs frappe exactement les entreprises dont la marge dépend d'une gestion efficace de nombreux clients.
• Rotation et prestataires. Les missions courtes rendent les sièges nominatifs administrativement coûteux : les prestataires sont exclus par défaut et le goulot se resserre.

Le modèle par siège convient à une équipe stable de cinq personnes. Il se comporte le plus mal avec les équipes en croissance, mixtes et multi-orgs, celles qui ont le plus besoin de DevOps.

Que faut-il regarder à la place ?

• Utilisateurs illimités. Si l'accès est une décision budgétaire, l'adoption est plafonnée par la finance et non par le besoin.
• Un prix indépendant du nombre d'orgs. Gérer plus d'orgs ne devrait pas être une pénalité.
• Un comptage transparent. Un accès forfaitaire avec mesure de la consommation est honnête, tant que le compteur est visible et l'unité explicable.
• Un palier gratuit qui en est vraiment un. Pas un compte à rebours avant un appel commercial.

C'est ainsi que Serpent est tarifé. Scale, c'est 699 dollars par entreprise et par mois, utilisateurs illimités, quel que soit le nombre d'orgs, avec 0 dollar de mise en place et un engagement mensuel. La consommation est mesurée en crédits (300 par mois sur Scale, recharge à 1 dollar le crédit), le compteur reste donc visible au lieu de se cacher dans un nombre de sièges. Essentials est réellement gratuit avec 30 crédits par mois, sans carte bancaire ni limite de durée, pour que toute l'équipe soit dans l'outil dès le premier jour. Voir la tarification de Serpent.

Pour voir comment dix plateformes Salesforce DevOps facturent réellement, par siège, par équipe ou par entreprise, lisez notre comparatif des outils Salesforce DevOps.

FAQ

La tarification par siège est-elle toujours un mauvais modèle ?

Non. Elle est raisonnable pour une petite équipe stable où chacun est un utilisateur à plein temps. Elle vieillit mal dès que le processus de release implique admins, testeurs et consultants.

Le tarif fixe n'est-il pas du par-siège déguisé ?

Seulement si l'éditeur plafonne les utilisateurs en petits caractères. Un tarif fixe qui autorise vraiment un nombre illimité d'utilisateurs change qui a le droit de déployer, et c'est tout l'enjeu.

Et les crédits, n'est-ce pas juste un autre compteur ?

C'est un compteur, et il faut le dire ainsi. La différence tient à ce qu'il mesure : une consommation que l'on peut planifier et voir, plutôt que des effectifs, ce qui pénalise la collaboration.

Comment défendre ce point en interne ?

Cessez d'en faire une comparaison de licences. Comptez les déploiements en attente dans l'agenda d'une seule personne et mettez un montant de salaire en face de ce temps.