Pourquoi le prix par utilisateur penalise les equipes Salesforce

Reponse courte : la tarification par siege ne coute pas seulement de l'argent, elle change les comportements. Les equipes achetent moins de sieges qu'elles n'ont de personnes, les releases passent par un ou deux power users, et la file d'attente qui se forme coute plus cher que les licences economisees. Sur Salesforce, l'effet est plus dur qu'ailleurs, parce que les personnes exclues pour economiser des sieges sont justement celles qui font le travail.

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

Par siege signifie que vous payez par utilisateur nomme ayant acces a l'outil. C'est le modele par defaut de l'outillage developpeur parce qu'il se previsionne facilement et qu'il fait croitre le revenu avec les effectifs. Sa faiblesse est bien documentee : le cout suit la taille de l'equipe et non la valeur livree, et la valeur suit rarement les effectifs (Schematic).

En DevOps Salesforce, cette faiblesse est plus aigue, car le processus de release n'est pas une activite reservee aux developpeurs. Les personnes qui ont legitimement besoin de deplacer un changement :

• Les admins qui construisent en declaratif et n'ouvrent jamais un terminal.
• Les consultants qui travaillent sur plusieurs orgs clientes.
• Les testeurs qui ont besoin d'un deploiement vers une sandbox de recette.
• Les release managers qui possedent 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 equipe achete des sieges ?

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-la. Trois consequences suivent, dans cet ordre :

1. Une file d'attente se forme. Les deploiements attendent desormais un creneau dans un agenda, pas la fin des travaux.
2. La connaissance se concentre. Les deux personnes licenciees sont les seules a comprendre le pipeline, ce qui est un risque RH bien avant d'etre un probleme de cout.
3. Les contournements reviennent. Change sets et modifications manuelles reapparaissent pour les "petits" changements, et la derive recommence.

L'outil avait ete achete pour supprimer un point unique de defaillance dans le processus de release. La tarification par siege le recree, puis vous facture pour l'elargir.

Combien coute reellement ce goulot ?

Faites le calcul avec vos propres salaires plutot qu'avec ceux d'un editeur. La forme du calcul :

• Comptez les personnes qui touchent a une release. Developpeurs, admins, consultants, testeurs, release manager. Huit est courant pour une equipe Salesforce de taille moyenne.
• Comptez les sieges que vous acheteriez vraiment. En general deux ou trois.
• Chiffrez l'ecart en temps, pas en licences. Si un ingenieur senior passe deux jours par semaine a executer les deploiements des autres, cela represente environ quarante pour cent d'un salaire senior consacre a gerer une file d'attente.
• Ajoutez le delai. Chaque changement qui attend trois jours une fenetre de deploiement, ce sont trois jours de valeur non livree.

Cote a cote, les stacks au siege et les offres a tarif fixe divergent vite quand l'equipe grandit (analyse de couts de Hyperping). Mais l'ecart de licences n'est que la petite moitie de l'argument. La moitie couteuse, c'est le comportement que le modele encourage.

Pourquoi les equipes en croissance sont-elles les plus touchees ?

Trois multiplicateurs s'additionnent :

• Les effectifs. Chaque recrutement devient une decision tarifaire, donc la croissance se transforme en discussion budgetaire recurrente sur qui a le droit de deployer.
• Le nombre d'orgs. Cabinets et ISV gerent plusieurs orgs. Une tarification qui suit les utilisateurs et les orgs frappe exactement les entreprises dont la marge depend d'une gestion efficace de nombreux clients.
• Rotation et prestataires. Les missions courtes rendent les sieges nominatifs administrativement couteux : les prestataires sont exclus par defaut et le goulot se resserre.

Le modele par siege convient a une equipe stable de cinq personnes. Il se comporte le plus mal avec les equipes en croissance, mixtes et multi-orgs, celles qui ont le plus besoin de DevOps.

Que faut-il regarder a la place ?

• Utilisateurs illimites. Si l'acces est une decision budgetaire, l'adoption est plafonnee par la finance et non par le besoin.
• Un prix independant du nombre d'orgs. Gerer plus d'orgs ne devrait pas etre une penalite.
• Un comptage transparent. Un acces forfaitaire avec mesure de la consommation est honnete, tant que le compteur est visible et l'unite explicable.
• Un palier gratuit qui en est vraiment un. Pas un compte a rebours avant un appel commercial.

C'est ainsi que Serpent est tarife. Scale, c'est 699 dollars par entreprise et par mois, utilisateurs illimites, quel que soit le nombre d'orgs, avec 0 dollar de mise en place et un engagement mensuel. La consommation est mesuree en credits (300 par mois sur Scale, recharge a 1 dollar le credit), le compteur reste donc visible au lieu de se cacher dans un nombre de sieges. Essentials est reellement gratuit avec 30 credits par mois, sans carte bancaire ni limite de duree, pour que toute l'equipe soit dans l'outil des le premier jour. Voir la tarification de Serpent.

FAQ

La tarification par siege est-elle toujours un mauvais modele ?

Non. Elle est raisonnable pour une petite equipe stable ou chacun est un utilisateur a plein temps. Elle vieillit mal des que le processus de release implique admins, testeurs et consultants.

Le tarif fixe n'est-il pas du par-siege deguise ?

Seulement si l'editeur plafonne les utilisateurs en petits caracteres. Un tarif fixe qui autorise vraiment un nombre illimite d'utilisateurs change qui a le droit de deployer, et c'est tout l'enjeu.

Et les credits, n'est-ce pas juste un autre compteur ?

C'est un compteur, et il faut le dire ainsi. La difference tient a ce qu'il mesure : une consommation que l'on peut planifier et voir, plutot que des effectifs, ce qui penalise la collaboration.

Comment defendre ce point en interne ?

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