Modèles de tarification pour une solution multilocataire

Un bon modèle tarifaire garantit votre rentabilité lorsque le nombre de locataires augmente et lorsque vous ajoutez de nouvelles fonctionnalités. Un point important à prendre en compte lors du développement d’une solution mutualisée commerciale est de savoir comment concevoir les modèles tarifaires pour votre produit. Dans cet article, nous fournissons des conseils aux décideurs techniques sur les modèles de tarification que vous pouvez envisager et les compromis impliqués.

Comprendre la rentabilité

Lorsque vous déterminez le modèle tarifaire de votre produit, vous devez équilibrer la valeur de retour (ROV) de vos clients et coût des marchandises vendues (CMV) pour fournir le service. Offrir des modèles commerciaux plus flexibles peut augmenter le ROV pour les clients, mais il peut également augmenter la complexité architecturale et commerciale de la solution, et donc augmenter votre COGS.

Lorsque vous développez des modèles tarifaires pour votre solution, tenez compte des questions suivantes :

• Le CMV sera-t-il plus élevé que le bénéfice que vous tirez de la solution ? Une approche de modèle tarifaire non rentable peut fonctionner pendant un certain temps, mais elle n’est pas durable à long terme.
• Le CMV peut-il évoluer au fil du temps, en fonction de l’augmentation du nombre d’utilisateurs ou des modifications apportées aux modèles d’utilisation ? Modélisez votre COGS et votre croissance pour comprendre si votre COGS rend votre solution non rentable à mesure que vous augmentez.
• Quelle est la difficulté à mesurer et à enregistrer les informations nécessaires pour le modèle tarifaire ? Par exemple, si vous envisagez de facturer vos clients en fonction du nombre d’appels d’API qu’ils effectuent, il est important d’identifier la façon dont vous mesurez les appels d’API effectués par chaque client.
• Votre modèle de tarification décourage-t-il l’utilisation de votre produit ? Évitez les situations où votre modèle de tarification réduit la valeur potentielle qu’un client peut obtenir à partir du produit, par exemple en rendant les activités courantes très coûteuses. Cette structure crée des primes incitatives incompatibles et peut entraîner une signalisation mixte aux clients.
• Si un client surutilise la solution, cela signifie-t-il qu’elle n’est plus rentable ? Si vous êtes préoccupé par l’utilisation abusive, placez les rails de garde en place comme les limites de taux.

Certains facteurs clés influencent la rentabilité :

• Modèles tarifaires des services Azure. Les modèles de tarification des services Azure ou des services tiers qui composent votre solution peuvent avoir un impact sur les modèles rentables.

• Modes d’utilisation du service. Les utilisateurs peuvent avoir besoin d’accéder à votre solution uniquement pendant les heures de travail ou il peut n’y avoir qu’un petit pourcentage d’utilisateurs à fort volume de transactions. Pouvez-vous réduire le CMV en réduisant la capacité inutilisée lorsque l’utilisation est faible ?

• Croissance du stockage. La plupart des solutions accumulent des données au fil du temps. Plus de données, c’est aussi un coût plus élevé pour le stockage et la protection, ce qui réduit votre rentabilité par locataire. Est-il possible de définir des quotas de stockage ou d’appliquer une période de rétention des données ?

• Isolation des locataires. Le modèle que vous appliquez affecte le niveau d’isolation entre vos locataires. Si vous partagez vos ressources, devez-vous tenir compte de la façon dont les locataires peuvent surutiliser votre service ou en abuser ? Comment le niveau d’isolation du client impactera-t-il sur votre COGS et vos performances pour tout le monde ?

  Certains modèles de tarification ne sont pas rentables sans contrôles supplémentaires sur l’affectation des ressources. Par exemple, vous devrez peut-être implémenter une limitation du service pour que le modèle tarifaire à taux fixe soit viable.

• Cycle de vie des locataires. Par exemple, les solutions avec des taux élevés d’attrition des clients ou des services nécessitant un effort d’intégration plus élevé peuvent souffrir d’une rentabilité inférieure, en particulier si elles sont facturées à l’aide d’un modèle basé sur la consommation.

• Exigences de niveau de service. Le fait que des locataires requièrent des niveaux de service plus élevés peut indiquer que votre solution n’est plus rentable. Il est essentiel que vous soyez clair sur les attentes de niveau de service de vos clients et les obligations dont vous disposez, afin que vous puissiez planifier vos modèles tarifaires en conséquence. Envisagez d’utiliser différents niveaux tarifaires pour les clients ayant des exigences de niveau de service différentes.

Modèles tarifaires courants

Il existe de nombreux modèles de tarification communs souvent utilisés avec les solutions multilocataires. Chacun de ces modèles tarifaires présente des avantages et des risques et nécessite des considérations supplémentaires au niveau de l’architecture. Il est important de comprendre les différences entre ces modèles tarifaires, afin que vous puissiez vous assurer que votre solution reste rentable au fur et à mesure de son évolution.

Notes

Vous pouvez proposer plusieurs modèles pour une solution ou combiner plusieurs modèles. Par exemple, vous pouvez proposer un modèle par utilisateur pour vos clients qui ont un nombre d’utilisateurs assez stable et vous pouvez également proposer un modèle basé sur la consommation pour les clients dont les modèles d’utilisation sont fluctuants.

Lorsque vous sélectionnez un modèle de tarification, tenez compte de ce qui est judicieux du point de vue de vos clients. Si votre modèle de tarification est trop complexe ou abstrait, il peut être difficile d’estimer ses coûts. Visez à lier vos tarifs aux constructions commerciales de vos locataires.

Tarification basée sur la consommation

Le modèle basé sur la consommation est parfois appelé paiement à l’utilisation ou PAYG. À mesure que l’utilisation de votre service augmente, votre revenu augmente :

Lorsque vous mesurez la consommation, vous pouvez tenir compte de facteurs simples, tels que la quantité de données ajoutées à la solution. Vous pouvez également tenir compte d’une combinaison d’attributs d’utilisation. Les modèles basés sur la consommation offrent plusieurs d’avantages, mais peuvent être difficiles à mettre en place dans une solution multilocataire.

Avantages : du point de vue de vos clients, l’investissement initial requis pour utiliser votre solution est minimal, afin que ce modèle présente un faible obstacle à l’entrée. De votre point de vue, en tant qu’opérateur du service, vos coûts d’hébergement et de gestion augmentent à mesure que l’utilisation de vos clients et vos revenus augmentent. Cette augmentation peut en faire un modèle tarifaire hautement évolutif. Les modèles tarifaires à la consommation fonctionnent particulièrement bien lorsque les services Azure utilisés dans la solution sont également basés sur la consommation.

Complexité et coût opérationnel : les modèles basés sur la consommation s’appuient sur la mesure précise de l’utilisation et sur le fractionnement de cette utilisation par locataire. Cela peut être difficile, en particulier dans une solution avec de nombreux composants distribués. Vous devez conserver des enregistrements de consommation détaillés pour la facturation et l’audit, ainsi que fournir des méthodes permettant aux clients d’accéder à leurs données de consommation.

Risques : la tarification à la consommation peut inciter vos clients à réduire l’utilisation qu’ils font de votre système afin de réduire leurs coûts. En outre, les modèles basés sur la consommation entraînent un manque de visibilité sur les flux de revenus. Vous pouvez atténuer ce risque en proposant des réservations de capacité, système via lequel les clients paient un certain niveau de consommation à l’avance. En tant que fournisseur de services, vous pouvez utiliser ce revenu pour investir dans l’amélioration de la solution, afin de réduire les coûts de fonctionnement ou d’en augmenter la valeur en y ajoutant des fonctionnalités.

Notes

L’implémentation et la prise en charge des réservations de capacité peuvent augmenter la complexité des processus de facturation dans votre application. Vous devrez peut-être également réfléchir à la façon dont les clients sont remboursés ou échangent leurs réservations de capacité, ces processus pouvant eux aussi ajouter certains problèmes d’ordre commercial ou opérationnel.

Tarification par utilisateur

Un modèle de tarification par utilisateur implique de facturer vos clients en fonction du nombre de personnes qui utilisent votre service :

Les modèles tarifaires par utilisateur sont très courants, en raison de la simplicité de leur mise en œuvre dans une solution mutualisée. Toutefois, ils s’accompagnent de plusieurs risques commerciaux.

Avantages : lorsque vous facturez vos clients pour chaque utilisateur, il est facile de calculer et de prévoir votre flux de revenu. En outre, en supposant que vous disposez de modèles d’utilisation assez cohérents pour chaque utilisateur, les revenus augmentent au même rythme que l’adoption du service, ce qui rend ce modèle évolutif à mesure que vous augmentez.

Complexité et coût opérationnel : le modèle par utilisateur est en général facile à implémenter. Toutefois, dans certaines situations, vous devez mesurer la consommation par utilisateur, ce qui peut vous aider à vous assurer que le CMV pour un seul utilisateur reste rentable. Si vous mesurez la consommation et que vous l’associez à un utilisateur en particulier, vous risquez d’augmenter la complexité opérationnelle de votre solution.

Risques : les divergences entre les modèles de consommation des utilisateurs peuvent entraîner une réduction de la rentabilité. Par exemple, les utilisateurs intensifs de la solution peuvent coûter plus cher que les utilisateurs plus occasionnels. En outre, le retour réel sur la valeur (ROV) de la solution ne correspond pas au nombre réel de licences utilisateur achetées. Si votre solution inclut des fonctionnalités qui ne sont pas directement liées aux utilisateurs, telles que l’envoi d’e-mails à un grand nombre de destinataires, votre chiffre d’affaires peut ne pas augmenter à mesure que votre COGS augmente.

Tarification par utilisateur actif

Ce modèle est similaire à la tarification par utilisateur, mais plutôt que d’exiger un engagement initial du client sur le nombre d’utilisateurs attendus, le client est facturé uniquement pour les utilisateurs qui se connectent et utilisent réellement la solution sur une période :

Vous pouvez mesurer cet indicateur selon la période qui est la plus logique pour vous. Le plus souvent, il est mesuré par mois, cette mesure étant souvent enregistrée sous forme d’utilisateurs actifs par mois ou UAM.

Avantages : du point de vue de vos clients, ce modèle ne nécessite qu’un faible investissement et présente peu de risques, car il comprend peu de gaspillage, les licences non utilisées n’étant pas facturées. Elle est donc particulièrement attrayante en cas de commercialisation de la solution ou de croissance de la solution pour les plus grandes entreprises. De votre point de vue en tant que propriétaire du service, le nombre d’utilisateurs actifs mensuels reflète mieux le retour sur la valeur auprès du client.

Complexité et coût opérationnel : les modèles par utilisateurs actifs vous obligent à enregistrer l’utilisation réelle et à la mettre à la disposition du client dans le cadre de la facture. La mesure de la consommation par utilisateur permet de s’assurer que la rentabilité est maintenue avec le CMV pour un seul utilisateur, mais à nouveau, elle exige un travail supplémentaire pour mesurer la consommation de chaque utilisateur.

Risques : comme pour la tarification par utilisateur, il existe un risque que les modèles de consommation des différents utilisateurs aient un impact sur votre rentabilité. Par rapport à la tarification par utilisateur, les modèles par utilisateurs actifs offrent un flux de revenus moins prévisible. En outre, le système de remise n’est pas un bon moyen pour stimuler la croissance.

Tarification à l’unité

Dans de nombreux systèmes, le nombre d’utilisateurs n’est pas l’élément qui a le plus d’incidence sur les CMV globaux. Par exemple, dans les solutions orientées appareil, également appelées Internet des objets ou IoT, le nombre d’appareils est souvent le facteur qui affecte le plus le CMV. Dans ces systèmes, un modèle tarifaire à l’unité peut être utilisé. Vous devez alors définir la nature des unités, par exemple un appareil. Consultez le schéma suivant.

En outre, certaines solutions présentent des modèles d’utilisation très variables, dans lesquels un petit nombre d’utilisateurs a un impact disproportionné sur le CMV. Par exemple, dans une solution vendue aux détaillants de brique et de mortier, un modèle de tarification par magasin peut être approprié, quel que soit le nombre d’utilisateurs de chaque magasin.

Avantages : dans les systèmes où les utilisateurs individuels n’ont pas d’effet significatif sur le CMV, la tarification par unité est un meilleur moyen de représenter la façon dont le système évolue et l’impact résultant sur le CMV. Il peut également permettre de mieux s’aligner sur les modèles d’utilisation réels pour le client. Pour de nombreuses solutions IoT, où chaque appareil génère un volume prévisible et constant de consommation, il peut s’agir d’un modèle efficace pour mettre faire évoluer votre solution.

Complexité et coût opérationnel : en règle générale, la tarification à l’unité est facile à implémenter et présente un coût opérationnel relativement faible. Toutefois, ce coût peut être plus élevé si vous devez distinguer et suivre l’utilisation au niveau de chaque unité, par exemple les appareils ou les magasins de vente au détail. La mesure de la consommation à l’unité permet de stabiliser la rentabilité, puisque vous pouvez déterminer le CMV pour une seule unité.

Risques : les risques liés au modèle tarifaire à l’unité sont similaires à ceux de la tarification par utilisateur. Les variations dans les modes de consommation peuvent indiquer que votre rentabilité est réduite, par exemple si certains appareils ou magasins utilisent la solution de façon plus intensive que d’autres.

Tarification basée sur les fonctionnalités et le niveau de service

Vous pouvez choisir de proposer votre solution avec différents niveaux de fonctionnalités à différents prix. Par exemple, vous pouvez fournir trois tarifs forfaitaires mensuels ou unitaires, deux offrant des offres de base avec un sous-ensemble de fonctionnalités disponibles et la troisième présentant l’ensemble complet des fonctionnalités de votre solution :

Ce modèle peut également proposer différents contrats de niveau de service pour les différents niveaux. Par exemple, votre niveau de base peut assurer une disponibilité à 99,9 %, alors que le niveau Premium peut offrir 99,99 %. Le contrat de niveau de service supérieur peut être mis en œuvre avec des services et des fonctionnalités qui déclenchent des objectifs de disponibilitéplus élevés.

Bien que ce modèle puisse être commercialement bénéfique, il exige des pratiques d’ingénierie plus perfectionnées. Utilisé avec prudence, ce modèle peut être très efficace.

Avantages : la tarification basée sur les fonctionnalités est souvent intéressante pour les clients, car ils peuvent choisir le niveau en fonction des fonctionnalités ou du niveau de service dont ils ont besoin. Il propose également un chemin d’accès clair qui incite vos clients à payer des fonctionnalités supplémentaires ou une meilleure résilience pour ceux qui en ont besoin.

Complexité et coût opérationnel : les modèles tarifaires basés sur les fonctionnalités peuvent être complexes à mettre en œuvre, car ils requièrent que votre solution connaisse les fonctionnalités disponibles pour chaque niveau tarifaire. Le basculement des fonctionnalités peut être un moyen efficace de fournir un accès à certains sous-ensembles de fonctionnalités, mais cela nécessite une maintenance continue. En outre, ce basculement de fonctionnalité augmente le traitement pour garantir une haute qualité, car il y aura davantage de chemins du code à tester. La définition d’objectifs plus élevés de disponibilité du service dans certains niveaux peut impliquer une plus grande complexité architecturale, afin de garantir que la bonne infrastructure est utilisée pour chaque niveau. De même, ce processus peut aussi augmenter le coût opérationnel de la solution.

Risques : les modèles tarifaires basés sur les fonctionnalités peuvent devenir compliqués et déroutants, si le nombre de niveaux ou d’options est trop important. En outre, la surcharge impliquée dans le basculement dynamique des fonctionnalités peut vous ralentir dans la mise à disposition de fonctionnalités supplémentaires.

Tarification freemium

Vous pouvez choisir d’offrir un niveau gratuit de votre service, avec des fonctionnalités de base et aucune garantie de niveau de service. Vous pouvez ensuite proposer un niveau payant distinct, avec des fonctionnalités supplémentaires et un contrat de niveau de service formel (comme indiqué dans le diagramme suivant).

Le niveau gratuit peut également être proposé en version d’évaluation limitée. Au cours de la période d’essai, vos clients peuvent accéder à des fonctionnalités complètes ou limitées. C’est ce qu’on appelle un modèle freemium, qui est en fait une extension du modèle tarifaire basé sur les fonctionnalités.

Avantages : il est très facile de commercialiser une solution lorsqu’elle est gratuite.

Complexité et coût opérationnel : toutes les préoccupations en termes de complexité et de coût opérationnel s’appliquent comme pour le modèle tarifaire basé sur les fonctionnalités. Vous devez également prendre en compte le coût opérationnel impliqué dans la gestion des locataires gratuits. Vous devrez peut-être vous assurer que les locataires périmés sont éliminés ou supprimés et mettre en place une stratégie de rétention claire, en particulier pour les locataires gratuits. Lors du déplacement d’un locataire vers un niveau payant, vous devrez peut-être migrer les données ou la charge de travail du locataire entre les services Azure pour obtenir des contrats SLA plus élevés. Il est également important de conserver les données et la configuration du locataire durant le passage à un niveau payant.

Risques : vous devez vous assurer que vous offrez une valeur suffisante pour que les locataires envisagent de passer au niveau payant. En outre, le coût de mise à disposition de votre solution aux clients sur le niveau gratuit doit être couvert par la marge bénéficiaire de ceux qui utilisent les niveaux payants.

Prix du coût des marchandises vendues

Vous pouvez choisir de prix de votre solution afin que chaque locataire paie uniquement le coût d’exploitation de leur part des composants qui composent votre solution, sans marge bénéficiaire ajoutée. Ce modèle, également appelé tarification directe ou rétrofacturation , est parfois utilisé pour les solutions multilocataires qui ne sont pas destinées à être un centre de bénéfices.

Le modèle de coût des marchandises vendues convient bien aux solutions multilocataires internes. Chaque unité d’organisation correspond à un locataire et les coûts de vos ressources Azure doivent être répartis entre elles. Il peut également être approprié quand les revenus sont dérivés des ventes d’autres produits et services qui consomment ou augmentent la solution multilocataire.

Avantages : Étant donné que ce modèle n’inclut pas de marge ajoutée pour le bénéfice, le coût pour les locataires est inférieur.

Complexité et coût d’exploitation : À l’instar du modèle de consommation, le prix du coût des marchandises vendues s’appuie sur des mesures précises de l’utilisation et sur la division de l’utilisation par locataire. Le suivi de la consommation peut être difficile, en particulier dans une solution avec un grand nombre de composants distribués. Vous devez conserver des enregistrements de consommation détaillés pour la facturation et l’audit, ainsi que fournir des méthodes permettant aux clients d’accéder à leurs données de consommation.

Pour les solutions multilocataires accessibles en interne, les locataires peuvent accepter des estimations de coût approximatives et avoir des exigences moins strictes en matière d’audit de la facturation. Ces exigences moins strictes réduisent la complexité et le coût d’exploitation de votre solution.

Risques : La tarification du coût des marchandises vendues peut inciter vos locataires à réduire l’utilisation qu’ils font de votre système de façon à réduire leurs coûts. Cependant, étant donné que ce modèle est utilisé pour des applications qui ne représentent pas des centres de profit, ceci ne devrait pas poser un problème.

Tarification forfaitaire

Dans ce modèle, vous faites payer un taux forfaitaire à un locataire pour votre l’utilisation de votre solution sur une période donnée. La même tarification s’applique quel que soit le volume utilisé par le service, le nombre d’utilisateurs, le nombre d’appareils auxquels ils se connectent ou toute autre mesure.

C’est le modèle le plus simple à implémenter et à comprendre pour les clients, et c’est souvent celui qui est demandé par les entreprises. Toutefois, la rentabilité peut facilement chuter si vous devez continuer à ajouter de nouvelles fonctionnalités ou si la consommation du locataire augmente sans revenu supplémentaire.

Avantages : le tarif forfaitaire est facile à vendre et il est facile pour vos clients de le comprendre et de l’intégrer à leur budget.

Complexité et coût opérationnel : les modèles tarifaires forfaitaires peuvent être faciles à mettre en place, car la facturation au client ne nécessite pas de contrôle ou ni de suivi de la consommation. Toutefois, bien que cela ne soit pas essentiel, il est recommandé de mesurer la consommation par locataire pour vous assurer que vous mesurez le CMV avec précision et que votre rentabilité est maintenue.

Risques : si certains de vos locataires utilisent votre solution de façon intensive, ce modèle tarifaire peut facilement perdre en rentabilité.

Remise tarifaire

Une fois que vous avez défini votre modèle tarifaire, vous pouvez choisir d’ajouter des stratégies commerciales pour stimuler la croissance via des remises. La remise tarifaire peut être appliquée sur le tarif à la consommation, la tarification par utilisateur et la tarification à l’unité.

Notes

Le système de remises n’a en général pas d’impact au niveau de l’architecture, au-delà de la complexité supplémentaire de la structure de facturation. Une discussion complète sur les avantages commerciaux de la remise est au-delà de l’étendue de cet article.

Les modèles de remises les plus courants sont les suivants :

• Prix fixe. Le coût pour chaque utilisateur, unité ou volume de consommation est le même, quel que soit le volume acheté ou consommé. Il s’agit de l’approche la plus simple. Toutefois, les clients qui utilisent de manière intensive votre solution peuvent avoir l’impression de bénéficier d’économies d’échelle avec une remise.
• Tarification dégressive. À mesure que les clients achètent ou consomment plus d’unités, vous en réduisez le coût unitaire. Ceci est plus attrayant pour les clients d’un point de vue commercial.
• Tarification progressive. À mesure que les clients achètent davantage, vous réduisez le coût par unité. Toutefois, vous le faites de façon progressive, en fonction de plages de volumes prédéfinies. Par exemple, vous pouvez faire payer plus pour les 100 premiers utilisateurs, un peu moins pour les 100 utilisateurs suivants, puis encore moins au-delà. Cette approche peut être plus rentable que la tarification dégressive.

Le schéma suivant illustre ces modèles tarifaires.

Remises sur les environnements hors production

Dans de nombreux cas, les clients ont besoin d’accéder à un environnement hors production qu’ils peuvent utiliser à des fins de test, de formation ou de création de leur propre documentation interne. Les environnements hors production présentent généralement des exigences et des coûts de consommation inférieurs de fonctionnement. Par exemple, les environnements hors production ne sont souvent pas soumis aux contrats de niveau de service (SLA) et les limites peuvent être plus basses. Vous pouvez également envisager une mise à l’échelle automatique plus agressive sur les services Azure qui prennent en charge les charges de travail hors production.

De même, les clients s’attendent souvent à ce que les environnements hors production soient beaucoup moins chers que leurs environnements de production. Il existe plusieurs alternatives possibles lorsque vous fournissez des environnements hors production :

• Proposez un niveau freemium, comme vous le faites peut-être déjà pour les clients payants. Il doit être surveillé avec soin, car certaines organisations peuvent créer de nombreux environnements de test et de formation qui vont consommer des ressources supplémentaires.

  Notes

  Les essais limités dans le temps du niveau freemium ne sont généralement pas adaptés aux environnements de test et de formation. Les clients ont généralement besoin que leurs environnements hors production soient disponibles pendant toute la durée de vie du service de production.

• Proposez un niveau de test ou de formation de votre service, avec des limites d’utilisation inférieures. Vous pouvez choisir de limiter la disponibilité de ce niveau aux clients qui disposent déjà d’un locataire payant.
• Proposez un tarif préférentiel par utilisateur, par utilisateur actif ou à l’unité pour les locataires hors production, avec un contrat de niveau de service inférieur ou égal.
• Pour les locataires utilisant un tarif forfaitaire, les environnements hors production peuvent être négociés dans le cadre du contrat.

Notes

La tarification basée sur les fonctionnalités n’est généralement pas une bonne option pour les environnements hors production, à moins que les fonctionnalités proposées soient les mêmes que celles offertes par l’environnement de production. Ceci est dû au fait que les locataires doivent généralement effectuer les tests et proposer les formations sur les mêmes fonctionnalités que celles disponibles en production.

Modèles tarifaires non rentables

Dans un modèle tarifaire non rentable, le fait de fournir le service vous coûte plus cher que le revenu que vous en tirez. Par exemple, vous pouvez faire payer un tarif forfaitaire par client sans limite pour votre service, mais vous étendez ensuite votre service avec des ressources Azure basées sur la consommation et sans limites d’utilisation par locataire. Dans ce cas, vous risquez que vos clients abusent de votre service et que ce service ne soit plus rentable pour vous.

En règle générale, les modèles tarifaires non rentables sont à éviter. Il existe cependant quelques situations dans lesquelles vous pouvez choisir d’adopter un modèle tarifaire non rentable, notamment :

• Vous proposez un service gratuit pour favoriser la croissance.
• D’autres flux de revenus supplémentaires peuvent provenir de services ou de fonctionnalités complémentaires.
• L’hébergement d’un locataire en particulier offre une certaine valeur commerciale, par exemple comme point d’entrée sur un nouveau marché.

Si vous créez par inadvertance un modèle tarifaire qui n’est pas rentable, il existe plusieurs façons d’atténuer les risques associés, notamment :

• Limiter l’utilisation du service par le biais de limites d’utilisation.
• Exiger l’utilisation de réservations de capacité.
• Demander au locataire de passer à une fonctionnalité ou à un niveau de service supérieur. Envisagez de rendre les nouvelles fonctionnalités exclusivement disponibles sur un niveau de service rentable pour encourager les locataires à se déplacer.

Modèles tarifaires risqués

Quand vous mettez en place un modèle de tarification pour une solution, vous devez en général émettre un certain nombre d’hypothèses sur la façon dont elle sera utilisée. Si ces hypothèses ne sont pas correctes ou si les modes d’utilisation changent, votre modèle tarifaire peut ne plus être rentable. Les modèles tarifaires qui risquent de ne plus être rentables sont appelés modèles tarifaires risqués. Par exemple, si vous adoptez un modèle tarifaire qui s’attend à ce que les utilisateurs limitent automatiquement le volume d’utilisation de votre solution, vous avez peut-être choisi un modèle tarifaire risqué.

La plupart des solutions SaaS ajoutent régulièrement de nouvelles fonctionnalités. Cela augmente la valeur pour les utilisateurs, ce qui peut également entraîner une augmentation de l’utilisation de la solution. Cela peut faire que la solution devient inutilisable si l’utilisation des nouvelles fonctionnalités prend en compte l’utilisation, mais que le modèle tarifaire n’en tient pas compte.

Par exemple, si vous introduisez une nouvelle fonctionnalité de chargement vidéo dans votre solution, qui utilise une ressource basée sur la consommation et que l’utilisation de la fonctionnalité est plus élevée que prévu, déterminez si vous pouvez atténuer le risque de tarification à l’aide d’une combinaison de limites d’utilisation et de tarification des fonctionnalités et des niveaux de service.

Limites d’utilisation

Les limites d’utilisation vous permettent de limiter l’utilisation de votre service afin d’éviter que vos modèles tarifaires ne soient plus rentables ou afin d’empêcher un seul locataire de consommer une part disproportionnée de la capacité de votre service. Cela peut être particulièrement important dans les services mutualisés, où un seul locataire peut avoir un impact sur l’expérience des autres locataires en raison d’une surutilisation des ressources.

Notes

Il est important de faire en sorte que vos clients sachent que vous appliquez des limites d’utilisation. Si vous mettez en place des limites d’utilisation sans que vos clients en soient informés, cela peut provoquer une certaine insatisfaction chez le client. Il est donc important d’identifier et de planifier les limites d’utilisation à l’avance. L’objectif doit être de planifier la limite et de mentionner ensuite ces limites aux clients avant qu’elles ne soient vraiment nécessaires.

Les limites d’utilisation sont souvent utilisées avec la tarification basée sur les fonctionnalités et le niveau de service, afin de proposer un plus grand volume d’utilisation à des niveaux supérieurs. Les limites sont également souvent utilisées pour protéger les composants de base qui sont à l’origine des goulots d’étranglement ou des problèmes de performances du système s’ils sont surexploités.

Limites du taux de transfert

Une méthode courante pour appliquer une limite d’utilisation consiste à ajouter des limites aux API ou aux fonctions spécifiques aux applications. C’est ce que l’on appelle aussi une limitation. Les limites de taux de transfert empêchent la surutilisation en continu. Elles sont souvent utilisées pour limiter le nombre d’appels à une API sur une période donnée. Par exemple, une API peut n’être appelée que 20 fois par minute et elle renvoie une erreur HTTP 429 si elle est appelée plus souvent.

Les scénarios suivants incluent souvent des limites de débit :

• Des API Rest.
• Des tâches asynchrones.
• Des tâches qui ne sont pas urgentes.
• Des actions qui dont l’exécution présente un coût élevé.
• Génération de rapports.

L’implémentation de la limitation peut augmenter la complexité de la solution, mais les services tels que la Gestion des API Azure peuvent simplifier ce mode avec des stratégies de limite.

Cycle de vie du modèle tarifaire

Tout comme les autres parties de votre solution, les modèles tarifaires ont un cycle de vie. À mesure que votre application évolue, vous devrez peut-être modifier vos modèles tarifaires. Cela peut être impulsé par un changement des besoins des clients, des besoins commerciaux ou des modifications apportées aux fonctionnalités de votre application. Les modifications qui interviennent couramment au cours du cycle de vie de la tarification sont les suivantes :

• Ajout d’un nouveau modèle tarifaire. Par exemple, l’ajout d’un modèle tarifaire à la consommation à une solution qui offre actuellement un modèle forfaitaire.
• Retrait d’un modèle tarifaire existant.
• Ajout d’un niveau à un modèle tarifaire existant.
• Suppression d’un niveau dans un modèle tarifaire existant.
• Modification des limites d’utilisation d’une fonctionnalité dans un modèle tarifaire.
• Ajout ou suppression de fonctionnalités dans un modèle tarifaire basé sur les fonctionnalités et le niveau de service.
• Passer d’un modèle commercial B2C (business-to-consumer) à un modèle commercial business-to-business (B2B). Cette modification nécessite de nouvelles structures de tarification pour les clients entreprise.

Il est généralement difficile d’implémenter et de gérer de nombreux modèles tarifaires en même temps. Et c’est également source de confusion pour vos clients. Il est donc préférable de n’implémenter qu’un ou deux modèles, avec un petit nombre de niveaux. Cela rend votre solution plus accessible et plus facile à gérer.

Notes

Les modèles tarifaires et les fonctions de facturation doivent être testés, idéalement à l’aide de tests automatisés, comme n’importe quelle autre partie de votre système. Plus les modèles tarifaires sont complexes, plus les tests sont nécessaires, et le coût du développement et de la complexité opérationnelle augmente.

Lorsque vous modifiez des modèles tarifaires, tenez compte des facteurs suivants :

• Implications contractuelles. Si les locataires ont signé des contrats basés sur un modèle de tarification spécifique, veillez à ne pas violer accidentellement ces contrats.
• Désirabilité. Communiquez clairement le ROV pour les nouveaux modèles tarifaires à vos locataires existants. Veillez à rendre le nouveau modèle suffisamment attrayant pour que les locataires souhaitent migrer vers le nouveau modèle. Déterminez comment vous empêcherez les locataires d’utiliser des modèles tarifaires plus anciens que vous prévoyez de mettre hors service.
• Chronologie. Donnez aux locataires beaucoup de préavis pour toute modification, afin de leur permettre de se préparer.
• Processus de migration. Facilitez la migration des locataires vers le nouveau modèle.
• Réduisez les risques de tarification. Évaluez chaque nouveau modèle de tarification pour comprendre s’il est risqué. Par exemple, soyez prudent lors de la suppression des limites de débit qui protègent actuellement les ressources critiques contre la surutilisation. Tout au long du changement, surveillez les performances et l’utilisation de vos services afin de garantir une satisfaction et une rentabilité continues.
• Réduire les risques de choc de facture. Les changements dans le modèle de tarification peuvent entraîner un choc de facture, ce qui est une réaction négative à une facture inattendue. Communiquer les modifications du modèle tarifaire de manière claire et proactive. Calculez ou simulez la facture de chaque locataire avant et après le changement afin de détecter les situations où un locataire paiera beaucoup plus après le changement.

Contributeurs

Cet article est géré par Microsoft. Il a été écrit à l’origine par les contributeurs suivants.

Auteur principal :

• Daniel Scott-Raynsford | Stratégiste de la technologie partenaire

Autres contributeurs :

• Bohdan Cherchyk | Ingénieur client senior, FastTrack for Azure
• John Downs | Ingénieur logiciel principal
• Chad Kittel | Ingénieur logiciel principal
• Paul Salvatori | Ingénieur client principal, FastTrack for Azure
• Arsen Vladimirskiy | Ingénieur client principal, FastTrack for Azure

Pour afficher les profils LinkedIn non publics, connectez-vous à LinkedIn.

Étapes suivantes

Réfléchissez à la façon dont vous allez mesurer la consommation des locataires dans votre solution.