La tarification par siège était élégante en 2012. Vous achetiez un logiciel pour des postes de travail, chaque poste avait son identifiant, et l'entreprise qui vous facturait savait exactement comment faire croître ses revenus avec votre croissance. C'était propre, prévisible et discrètement punitif. Surtout le dernier.
Nous ne facturons pas par siège. Nous ne l'avons jamais fait. Les gens supposent que c'est parce que nous ne pouvions pas rivaliser sur la rétention nette du chiffre d'affaires face aux SaaS facturés par siège — et ils n'ont pas tort, mais ce n'est pas la raison. Nous ne facturons pas par siège parce que par utilisateur est une taxe sur ce que vous voulez le plus que votre client fasse.
Quelle tarification par siège facture réellement.
L’histoire que vous vend la tarification par utilisateur est la suivante : plus de valeur revient aux équipes comptant plus d’utilisateurs, donc le prix évolue avec la valeur. Plausible. Examinons cela de près.
Une agence de 10 personnes recrute son 11e employé. La valeur marginale de HubSpot pour cette équipe n'augmente pas de façon linéaire. La nouvelle recrue n'utilise pas le CRM 1,0x plus que l'utilisateur moyen existant — généralement, elle l'utilise moins, le temps de monter en puissance. Les données sont les mêmes. Les intégrations sont les mêmes. La charge de calcul sur les serveurs de HubSpot est pratiquement identique.
Mais la facture de HubSpot vient encore d'augmenter de $50 à 90. Vous ne payez pas pour la valeur livrée. Vous payez pour l'acte d'embaucher. Le tarif par siège est une taxe sur la ligne « effectifs » de votre compte de résultat.
Les tarifs devraient refléter le coût ou la valeur, pas le service paie du client.
Et le pire n'est pas le coût explicite. C'est le coût implicite — la pression culturelle lente et récurrente de pas ajoutez des sièges. Ne donnez pas de licence au stagiaire. Partagez l'identifiant de Bob avec toute l'équipe. Ne mettez pas les commerciaux en lecture seule, mettez-les sans accès. La tarification par siège apprend à votre équipe à être mesquine sur qui a le droit d'utiliser un logiciel, et la mesquinerie est l'opposé de ce qu'un logiciel devrait produire dans une organisation.
Le coût caché : la taxe par siège sur la paie.
L'exemple le plus flagrant est celui des logiciels de paie. Gusto facture environ $40 par mois en base, plus $6 par employé et par mois. ADP, Justworks, Rippling, tous dans la même fourchette. Petit calcul pour une équipe de 20 personnes : $160 de frais de charges sociales par mois. Par an : $1,920.
C'est $1,920/an que vous payez parce que — voyons les notes — votre logiciel de paie doit traiter la paie des personnes sur votre liste de paie. La chose pour laquelle le produit existe littéralement. La « fonctionnalité » facturée n'est autre que sa fonction de base.
Multipliez à l'échelle de toute votre stack — le CRM coûte $90/utilisateur, la gestion de projet $20/utilisateur, le helpdesk $25/utilisateur — et vous arrivez au chiffre que chaque fondateur finit par redécouvrir : le logiciel coûte plus par employé que les collations de bureau, et à peu près autant par employé que les subventions d'assurance maladie. C'est une vraie ligne dans le budget. La tarification par utilisateur est le moteur qui la fait gonfler.
L'argument pour par siège.
Pour être juste : le tarif par utilisateur a un atout. Cela aligne les revenus du fournisseur sur la croissance du client. Une entreprise de 200 personnes paie plus qu'une entreprise de 10 personnes. Cela semble juste. C'est probablement est tout en haut de la fourchette.
L'argument est vrai à l'extrême et faux entre les deux. Une entreprise du Fortune 500 comptant 80 000 employés devrait probablement payer plus cher pour HubSpot qu'une agence de 10 personnes. Mais la courbe de 10 à 80 000 n'est pas linéaire en valeur, même si la facturation au siège la traite comme si elle l'était. Autour de 30 à 50 employés, l'utilisateur marginal n'apporte aucune valeur nouvelle au fournisseur et un coût supplémentaire substantiel au client.
C'est le point d'inflexion où les forfaits fixes deviennent rentables. Et il se trouve que c'est exactement le profil client idéal de la plupart des plateformes tout-en-un construites aujourd'hui.
Pourquoi nous avons choisi le forfait fixe, et ce à quoi nous avons renoncé.
Mewayz Business coûte $149/mois avec 30 utilisateurs inclus. Agency coûte $349/mois avec un nombre illimité d'utilisateurs. C'est tout. Quelle que soit la croissance de votre équipe, votre facture ne bouge pas.
Qu'est-ce que cela nous a coûté ? La rétention nette en dollars, en partie. Les clients facturés par poste vous paient automatiquement davantage l'année suivante à mesure qu'ils embauchent ; les clients à tarif forfaitaire, non. Nous compensons la différence en vendant davantage de modules au fil du temps, par l'expansion en marque blanche et par les options de stockage et de crédits IA. Mais nous mentirions en prétendant ne pas surveiller nos chiffres de NDR avec une légère grimace chaque trimestre.
Ce que nous avons obtenu en retour : une confiance client que nous n'aurions pu acheter d'aucune autre manière. Personne ne se méfie de sa facture Mewayz au moment de doubler ses effectifs. Personne ne rationne les accès. Personne ne recrute pour contourner le logiciel. Le produit est reconnu comme étant le système de référence, et la décision d'embauche peut être prise sur ses propres mérites.
Le compromis : à l'usage, pas par poste.
Il existe un solide juste milieu entre le par-siège et le forfaitaire : la tarification à l’usage. Vous facturez ce que le client consomme réellement — e-mails envoyés, paiements traités, appels API effectués, stockage utilisé.
Stripe en est l'exemple canonique. Twilio. Snowflake. Aucun d'entre eux ne facture par utilisateur. Ils facturent par transaction, et les incitations du client sont parfaitement alignées : plus ils grandissent, plus ils paient, mais le coût évolue avec la métrique de succès plutôt qu'avec la ligne de coût.
C'est le modèle que nous préférerions au forfait. Il est simplement difficile à appliquer à 150 modules ayant des unités de consommation différentes. Le forfait est donc notre compromis — pour l'instant. À long terme, attendez-vous à ce que nous migrions certaines catégories (génération IA, paiements, stockage) vers un modèle à l'usage, tout en gardant les frais de plateforme eux-mêmes au forfait.
Ce que cela signifie pour vous.
Deux enseignements pratiques pour quiconque achète un logiciel en 2026 :
- Calculez explicitement la taxe par utilisateur lorsque vous comparez les fournisseurs. Prenez le coût par utilisateur, multipliez-le par vos effectifs prévus dans 24 mois et utilisez ce chiffre comme véritable coût total de possession. La comparaison honnête favorise les produits à tarif forfaitaire bien plus que les prix affichés ne le laissent croire.
- Méfiez-vous surtout des frais de paie « par employé ». Ils se cumulent. Ils constituent la ligne la plus coûteuse de votre facture SaaS au-delà de 15 employés, et ils relèvent entièrement d'une décision côté fournisseur déguisée en reflet de coût.
Nous ne nous attendons pas à ce que le modèle par utilisateur disparaisse. Salesforce ne va pas changer demain. Les piles héritées ont trop investi dans le calcul par tableur. Mais chaque nouvelle plateforme en cours de construction — y compris la nôtre — a la possibilité de choisir différemment. Nous l'avons fait. Nous pensons que d'autres le feront.