Le probleme de marge du tarif par org en DevOps Salesforce

En bref : la plupart des outils DevOps Salesforce facturent au siege ou a l'org connectee. C'est coherent pour un client final avec une seule org de production, et discretement punitif pour un cabinet qui porte dix ou vingt orgs clientes, parce que chaque nouveau logo ajoute du cout de licence avant d'ajouter une heure facturable. Standardiser sur un pipeline dont le prix ne bouge pas avec le nombre d'orgs transforme l'outillage en cout fixe plutot qu'en cout variable, et c'est une decision de marge avant d'etre une decision de qualite.

Pourquoi le tarif par siege et par org penalise-t-il surtout les cabinets ?

Un client final grandit sur un seul axe : les personnes. Une org de production, quelques sandboxes, une equipe qui s'etoffe lentement. Un outil au siege suit cette croissance honnetement.

Un integrateur boutique grandit sur un autre axe : les orgs. Dix clients, ce sont dix orgs de production, leurs sandboxes et, le plus souvent, des scratch orgs par-dessus. Le compteur tourne exactement sur l'axe ou l'entreprise se developpe, et ce developpement n'est pas facturable en soi. Trois problemes structurels en decoulent.

• Le cout arrive avant le revenu. Vous connectez et configurez une org cliente pendant l'onboarding, qui est en general au forfait ou absorbe.
• L'attrition est asymetrique. Le client part, la duree du contrat reste.
• La refacturation est difficile. Les clients financent volontiers les licences qu'ils voient dans leur propre org. Beaucoup moins les votres.

Que mesurent reellement les grilles tarifaires publiees ?

Mieux vaut lire les pages des editeurs que les comparatifs de seconde main. Gearset publie ses tarifs : le deploiement de base est facture par utilisateur Gearset et par mois, tandis que l'automatisation et la CI/CD sont vendues separement par equipe, chaque palier incluant un nombre fixe d'orgs cibles CI/CD. L'axe org existe donc bien, il se cache simplement dans la ligne automatisation plutot que dans le prix affiche.

Copado ne publie pas de grille tarifaire. Essentials demarre gratuitement et le palier entreprise renvoie vers un rendez-vous commercial. Pour un partenaire, c'est un cout en soi : on ne modelise pas une marge brute sur un chiffre qu'il faut d'abord negocier.

Aucun des deux modeles n'est malhonnete. Tous deux ont ete concus pour un client qui possede ses orgs. Un partenaire qui ne fait que les emprunter est un cas limite dans cette conception.

Quel effet l'axe org a-t-il sur un portefeuille client qui grandit ?

Modelisez la forme, pas les chiffres. Des qu'une ligne de votre facture bouge avec les orgs connectees, le cout d'outillage suit la liste de clients tandis que le revenu suit les heures facturables. Ces deux courbes divergent chaque fois que vous gagnez une mission que vous ne pouvez pas staffer immediatement.

Ce sont les paliers qui font mal. Quand un palier d'automatisation inclut cinq orgs cibles et que le suivant en inclut quinze, votre sixieme client peut couter un palier entier de plus que le cinquieme. Ce saut ne dit rien de l'effort reel de la sixieme mission, et ne figurait pas dans la proposition deja signee.

Standardiser un pipeline : decision qualite ou decision marge ?

On le vend en general comme de la qualite : moins de deploiements en echec, une vraie piste d'audit, un rollback que l'on ose ecrire dans un contrat cadre. Tout est vrai. Le chiffre le plus important est du cote des couts.

Un pipeline par client, c'est du savoir tribal par client. Le consultant qui a construit le modele de branches d'un client devient le seul a pouvoir livrer pour lui, la charge se fige sur des personnes et les conges deviennent un risque de livraison. Une forme de pipeline commune change trois choses.

• Onboarder un client devient de la configuration, plus un projet.
• N'importe quel consultant peut couvrir n'importe quel compte, la charge n'est plus otage d'une personne.
• Les preuves de livraison sont identiques pour tous les clients, ce qui rend audits et comites de pilotage peu couteux.

Standardiser ne veut pas dire que tous les clients travaillent a l'identique. Cela veut dire que les etapes sont figees (ticket, branche, validation, approbation, deploiement, rollback) et que seule la configuration varie.

Que verifier avant de signer un contrat DevOps ?

1. Une ligne du prix bouge-t-elle avec les orgs connectees ? Demandez le montant pour votre portefeuille actuel et pour le double.
2. Bouge-t-elle avec les sieges, et un referent chez le client peut-il approuver une release sans en acheter un ?
3. Que se passe-t-il si un client part en cours de contrat ?
4. Un consultant qui n'utilise pas Git peut-il lancer une release seul ?
5. L'outil installe-t-il quelque chose dans l'org du client ? Un package gere impose une approbation a l'entree et une desinstallation a la sortie, a chaque fois.
6. Si un client est ISV, le meme pipeline couvre-t-il les workflows de packages 1GP et 2GP, ou est-ce un achat separe ?

Qu'est-ce qui change avec un tarif fixe par entreprise ?

Serpent facture par entreprise, pas au siege ni a l'org. Scale coute 699 $ par entreprise et par mois, utilisateurs illimites, 0 $ de mise en place, et le prix ne bouge pas que vous connectiez trois orgs clientes ou trente. Un palier Essentials gratuit offre 30 credits par mois si vous voulez d'abord y passer un seul compte.

Soyons clairs sur le compteur : la consommation est en credits, donc il mesure du travail et non des clients. Un deploiement de fonctionnalite vaut un credit, une release en production deux, une action IA en ajoute un, une operation de donnees en vaut quatre, et Scale en inclut 300 par mois. C'est une variable que pilote votre volume de livraison, pas une variable creee par votre equipe commerciale quand elle signe un logo.

Deux details comptent particulierement pour le travail en partenariat. Serpent n'installe rien dans l'org du client et se connecte via les API standard : pas d'approbation de package a l'entree, pas de desinstallation a la sortie. Et comme le flux est pilote par tickets avec Git en arriere-plan, le consultant qui reprend un compte n'a pas besoin d'etre celui qui l'a mis en place.

FAQ

Le tarif au siege est-il toujours moins bon pour un cabinet ?

Non. Quatre consultants couvrant vingt orgs clientes peuvent revenir moins cher au siege qu'a l'org. Le probleme est que la plupart des contrats mesurent les deux, donc vous payez sur l'axe qui grandit en premier.

Peut-on refacturer l'outillage DevOps au client ?

Parfois, comme ligne d'un contrat de service manage. C'est bien plus difficile sur une implementation au forfait, la ou se trouve l'essentiel du revenu des integrateurs boutique.

Un pipeline standard impose-t-il le meme modele de branches a tous les clients ?

Non. Gardez les etapes identiques et laissez branches, environnements et portes d'approbation en configuration par client.

Et les clients qui sont eux-memes ISV ?

Verifiez que les workflows de packages sont inclus et non en option. Serpent couvre les workflows 1GP, 2GP et AppExchange sur tous les plans, y compris le plan gratuit.

Combien de temps prend le passage d'un client au pipeline commun ?

La mise en place de Serpent prend moins de 15 minutes par workspace et les sessions d'onboarding sont gratuites : la contrainte est en general la fenetre de changement du client, pas l'outil.