Le problème de marge du tarif par org en DevOps Salesforce

En bref : la plupart des outils DevOps Salesforce facturent au siège ou à l'org connectée. C'est cohérent pour un client final avec une seule org de production, et discrètement punitif pour un cabinet qui porte dix ou vingt orgs clientes, parce que chaque nouveau logo ajoute du coût 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 coût fixe plutôt qu'en coût variable, et c'est une décision de marge avant d'être une décision de qualité.

Pourquoi le tarif par siège et par org pénalise-t-il surtout les cabinets ?

Un client final grandit sur un seul axe : les personnes. Une org de production, quelques sandboxes, une équipe qui s'étoffe lentement. Un outil au siège suit cette croissance honnêtement.

Un intégrateur 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 où l'entreprise se développe, et ce développement n'est pas facturable en soi. Trois problèmes structurels en découlent.

• Le coût arrive avant le revenu. Vous connectez et configurez une org cliente pendant l'onboarding, qui est en général au forfait ou absorbé.
• L'attrition est asymétrique. Le client part, la durée du contrat reste.
• La refacturation est difficile. Les clients financent volontiers les licences qu'ils voient dans leur propre org. Beaucoup moins les vôtres.

Que mesurent réellement les grilles tarifaires publiées ?

Mieux vaut lire les pages des éditeurs que les comparatifs de seconde main. Gearset publie ses tarifs : le déploiement de base est facturé par utilisateur Gearset et par mois, tandis que l'automatisation et la CI/CD sont vendues séparément par équipe, chaque palier incluant un nombre fixe d'orgs ciblés CI/CD. L'axe org existe donc bien, il se cache simplement dans la ligne automatisation plutôt que dans le prix affiché.

Copado ne publie des prix que pour son offre Essentials (Free, Basic à 79 $, Plus à 195 $ par utilisateur et par mois, facturés annuellement) ; la plateforme complète est sur devis et renvoie vers un rendez-vous commercial. Pour un partenaire, c'est un coût en soi : on ne modélise pas une marge brute sur un chiffre qu'il faut d'abord négocier.

Aucun des deux modèles n'est malhonnête. Tous deux ont été conçus pour un client qui possède 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 ?

Modélisez la forme, pas les chiffres. Dès qu'une ligne de votre facture bouge avec les orgs connectées, le coût 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 immédiatement.

Ce sont les paliers qui font mal. Quand un palier d'automatisation inclut cinq orgs ciblés et que le suivant en inclut quinze, votre sixième client peut coûter un palier entier de plus que le cinquième. Ce saut ne dit rien de l'effort réel de la sixième mission, et ne figurait pas dans la proposition déjà signée.

Standardiser un pipeline : décision qualité ou décision marge ?

On le vend en général comme de la qualité : moins de déploiements en échec, une vraie piste d'audit, un rollback que l'on ose écrire dans un contrat cadre. Tout est vrai. Le chiffre le plus important est du côté des coûts.

Un pipeline par client, c'est du savoir tribal par client. Le consultant qui a construit le modèle de branches d'un client devient le seul à pouvoir livrer pour lui, la charge se fige sur des personnes et les congés 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 comités de pilotage peu coûteux.

Standardiser ne veut pas dire que tous les clients travaillent à l'identique. Cela veut dire que les étapes sont figées (ticket, branche, validation, approbation, déploiement, rollback) et que seule la configuration varie.

Que vérifier avant de signer un contrat DevOps ?

1. Une ligne du prix bouge-t-elle avec les orgs connectées ? Demandez le montant pour votre portefeuille actuel et pour le double.
2. Bouge-t-elle avec les sièges, et un référent 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 géré impose une approbation à l'entrée et une désinstallation à la sortie, à chaque fois.
6. Si un client est ISV, le même pipeline couvre-t-il les workflows de packages 1GP et 2GP, ou est-ce un achat séparé ?

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

Serpent facture par entreprise, pas au siège ni à l'org. Scale coûte 699 $ par entreprise et par mois, utilisateurs illimités, 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 crédits par mois si vous voulez d'abord y passer un seul compte.

Soyons clairs sur le compteur : la consommation est en crédits, donc il mesure du travail et non des clients. Un déploiement de fonctionnalité vaut un crédit, une release en production deux, une action IA en ajoute un, une opération de données en vaut quatre, et Scale en inclut 300 par mois. C'est une variable que pilote votre volume de livraison, pas une variable créée par votre équipe commerciale quand elle signe un logo.

Deux détails comptent particulièrement 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 à l'entrée, pas de désinstallation à la sortie. Et comme le flux est piloté par tickets avec Git en arrière-plan, le consultant qui reprend un compte n'a pas besoin d'être celui qui l'a mis en place.

FAQ

Le tarif au siège est-il toujours moins bon pour un cabinet ?

Non. Quatre consultants couvrant vingt orgs clientes peuvent revenir moins cher au siège qu'à l'org. Le problème 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 managé. C'est bien plus difficile sur une implémentation au forfait, là où se trouve l'essentiel du revenu des intégrateurs boutique.

Un pipeline standard impose-t-il le même modèle de branches à tous les clients ?

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

Et les clients qui sont eux-mêmes ISV ?

Vérifiez 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 général la fenêtre de changement du client, pas l'outil.