Aller au contenu principal

Facturation à la seconde, pas au message : rapprocher les factures de temps d'instance de CloudAMQP en tant que COGS d'infrastructure

Publié 17 minutes de lectureMike ThriftMike Thrift
Facturation à la seconde, pas au message : rapprocher les factures de temps d'instance de CloudAMQP en tant que COGS d'infrastructure
Sur cette page

Votre plan CloudAMQP indique 99 $ par mois, mais la facture affiche 82,33 $, et le mois suivant 114,07 $, et vous n'avez rien changé à part redimensionner une instance un mardi. Rien ne cloche. CloudAMQP ne vend pas des messages. Elle vend du temps d'instance à la seconde, facture avec un décalage d'un mois et calcule au prorata chaque changement de plan à la seconde exacte où il s'est produit. Le prix affiché est une limite de vitesse, pas une promesse. Tant que votre comptabilité traite la facture comme un relevé de compteur plutôt que comme un abonnement, vos coûts d'infrastructure dériveront, vos provisions manqueront leur cible et votre marge brute absorberont silencieusement la différence.

Cet article explique comment CloudAMQP mesure et facture réellement, à quoi ressemblent des factures réalistes, pourquoi le broker de production appartient au coût des marchandises vendues, et comment rapprocher les factures de temps d'instance afin que chaque dollar atterrisse dans le bon compte.

Comment CloudAMQP mesure : le temps, pas les messages​

CloudAMQP est un hébergement géré RabbitMQ et LavinMQ exploité par 84codes. Vous choisissez un broker, un plan et une région, et vous obtenez une instance ou un cluster. Le modèle de facturation suit l'instance, pas le trafic qui la traverse, ce qui est l'inverse des services de messagerie à la requête où la taille de la charge utile dicte la facture. Ici, les deux questions qui déterminent votre facture sont la taille de l'instance que vous avez fait tourner et le nombre de secondes pendant lesquelles elle a tourné.

Les plans partagés ont des quotas, les plans dédiés ont de la capacité​

Les plans partagés multi-tenant sont le seul endroit où des comptages de messages apparaissent ne serait-ce qu'un peu. Loyal Lemming est gratuit avec un quota mensuel de 2 millions de messages et 40 connexions, et Elegant Ermine coûte 19 $ par mois avec un quota de 20 millions de messages et 200 connexions. Ils conviennent au développement, aux prototypes et aux projets personnels. Le quota est un plafond, pas un compteur : vous ne payez pas au message à l'intérieur de celui-ci.

Les plans dédiés suppriment entièrement le comptage de messages. Vous obtenez votre propre broker ou un cluster multi-AZ de ceux-ci, et chaque plan dédié fait tourner le même moteur à la même vitesse. Vous choisissez un palier selon ce que votre système contient : connexions, files d'attente et messages stockés. La gamme LavinMQ mono-nœud va de Passionate Puffin à 49 $ par mois en passant par Playful Penguin à 99 $, Lively Lynx à 199 $ et Wild Wolverine à 499 $, avec des paliers plus élevés au-dessus. Les formes de cluster à un, trois et cinq nœuds échangent du prix contre de la disponibilité. Le transfert de données est inclus dans une limite d'usage raisonnable, que la page tarifaire définit comme un transfert gratuit égal à 30 pour cent des dépenses de votre équipe chaque mois. Si vous la dépassez, vous disposez de 30 jours pour résoudre le dépassement avant que des frais de trafic n'apparaissent sur les factures ultérieures.

La conséquence pratique : votre volume de messages peut doubler sans faire bouger la facture d'un centime, tant que l'instance contient encore les connexions, les files d'attente et le backlog. Inversement, passer à un palier supérieur parce qu'une limite vous a contraint modifie le prix de chaque seconde à partir de ce moment, même si le trafic est stable. La planification de la capacité, et non la prévision du trafic, est la compétence qui maîtrise cette facture.

Chaque seconde compte, et la facture arrive un mois plus tard​

Tous les plans sont facturés à la seconde. À la fin de chaque mois, votre facture reflète le temps exact pendant lequel chaque instance a été disponible à l'utilisation, de sorte qu'une instance créée en cours de mois, supprimée en cours de mois ou redimensionnée en cours de mois produit une charge au prorata plutôt qu'un mois complet ou nul. Vous pouvez changer de plan à tout moment sans interruption de service, et l'autoscaling entre paliers a le même effet : chaque segment du mois est facturé au palier qui était actif pendant ces secondes.

Le paiement intervient le mois suivant la livraison. La FAQ de CloudAMQP le dit clairement : la facturation est calculée au prorata, les clients ne paient que le temps pendant lequel le service a été disponible pour eux, et vous recevez votre première facture au début du mois suivant plutôt qu'à l'inscription. Ce rythme de facturation en décalage est le fait le plus important pour votre comptabilité. Il n'y a aucune charge à la clôture sur laquelle provisionner, ce qui signifie que chaque clôture mensuelle nécessite une provision pour le temps de broker non facturé, et chaque facture nécessite une régularisation par rapport à l'estimation du mois précédent.

Deux autres mécanismes de facturation comptent. Premièrement, le prépaiement : vous pouvez prépayer un à plusieurs mois à l'avance, et un prépaiement est valable un an avant d'expirer. Un client sur un plan à 99 $ peut prépayer douze mois et éviter les charges mensuelles pendant un an, et le crédit couvre tous les plans du compte, de sorte que l'ajout d'une seconde instance l'épuise plus vite. Il s'agit d'un actif prépayé avec une échéance d'un an, non d'une charge au moment du paiement. Deuxièmement, il n'y a pas de facture annuelle. Parce que les clients changent si souvent de plan, CloudAMQP ne propose pas de facturation annuelle ; le crédit de prépaiement en est le substitut. Si votre processus d'achat exige une facture annuelle ou des bons de commande distincts par abonnement, anticipez-le tôt : des bons de commande distincts nécessitent des comptes distincts afin que les abonnements soient facturés séparément, et les conditions de facturation passent par leur équipe de facturation plutôt que par le flux de carte en libre-service.

Les instances de marketplace sont facturées via la plateforme, pas CloudAMQP​

Si vous avez provisionné via les add-ons Heroku ou les marketplaces AWS, Azure ou GCP, la dépense n'apparaît pas du tout sur une facture CloudAMQP. Elle atterrit sur la facture de la plateforme, la facture mensuelle de Heroku ou la répartition des coûts de votre fournisseur cloud, sous la dénomination de cette plateforme. C'est l'écart de rapprochement le plus courant pour les équipes qui font tourner des brokers à deux endroits : la facture directe se rapproche proprement tandis que le jumeau de la marketplace se cache dans une facture cloud plus importante, souvent classée comme hébergement générique. Décidez une fois pour toutes d'où chaque instance est facturée, et assurez-vous que votre extraction de fin de mois couvre à la fois le panneau de contrôle CloudAMQP et chaque marketplace où elle pourrait se cacher.

Ce que cela coûte pour des configurations réalistes​

Les prix catalogue n'ont de sens que multipliés par des secondes, voici donc trois configurations construites à partir des prix mono-nœud publiés.

Un projet annexe fait tourner le staging sur le palier Lemming gratuit et un Puffin à 49 $ pour un petit service de production. La ligne broker est de 49 $ par mois, fixe, et la seule tâche de rapprochement consiste à confirmer que l'instance a tourné tout le mois.

Une équipe SaaS en croissance fait tourner la production sur un Penguin à 99 $ et le staging sur un Ermine à 19 $. En cours de mois, la profondeur de file impose une mise à niveau : le staging au niveau Puffin reste inchangé, mais la production passe du Puffin à 49 $ au Penguin à 99 $ dix jours après le début d'un mois de trente jours. La partie production est facturée comme dix jours au palier inférieur plus vingt jours au palier supérieur, soit environ 16,33 $ plus 66,00 $, ou environ 82,33 $, et le staging ajoute 19 $. Le total de la facture atteint près de 101,33 $ pour une configuration dont les prix catalogue totalisent 118 $. Le mois suivant, avec le Penguin actif sur toute la période, la même configuration est facturée les 118 $ pleins. Quiconque comptabilise le prix catalogue les deux mois surestime le premier mois et ne sous-estime rien le second, ce qui est exactement la dérive que la facturation à la seconde punit.

Une structure plus importante fait tourner un cluster de production à trois nœuds plus le staging et un solde de crédit prépayé. Le cluster multiplie le tarif mono-nœud, les changements de plan lors de la réponse aux incidents ajoutent des segments au prorata, et le prépaiement absorbe le total sans débit de carte. La facture détaille toujours chaque instance et chaque segment, et c'est le tirage du crédit qu'il faut comptabiliser, pas le zéro sur le relevé de carte.

Aucune de ces configurations n'implique de comptages de messages. Si votre modèle financier multiplie les messages attendus par un tarif au message, il modélise un autre fournisseur. Modélisez les paliers d'instance multipliés par les secondes attendues, et révisez l'hypothèse de palier dès que la croissance des connexions ou des files d'attente force un redimensionnement.

Pourquoi le broker de production est un COGS, pas un frais généraux​

Un broker de messages qui transporte des événements de commandes, des envois de tâches et des notifications clients en production est un coût direct de la livraison de votre produit. Il évolue avec l'entreprise, il cesse d'avoir de l'importance dès que plus rien ne se vend, et il se place naturellement au-dessus de la ligne de marge brute aux côtés du compute, de la base de données, du stockage et de la bande passante de production. La pratique de la marge brute SaaS applique un test de coût direct : une dépense qui existe pour servir des clients en production est un coût des revenus, tandis qu'une dépense qui construit, vend ou administre l'entreprise est une charge d'exploitation. Un SaaS classique affiche une marge brute de 75 à 85 pour cent sur cette base, les entreprises à forte intensité d'infrastructure étant plus basses, et les investisseurs vous comparent à ces fourchettes.

Appliquez le test instance par instance, car un compte CloudAMQP contient généralement plusieurs instances. Les brokers de production portant des charges de travail clients passent en coût des marchandises vendues. Les instances de staging, de test de charge et de bac à sable de développement basculent en recherche et développement ou en frais généraux. L'Ermine partagé qui fait tourner votre environnement de staging n'est pas un COGS simplement parce qu'il partage une facture avec le Penguin de production. La facture les regroupe, alors répartissez-la chaque mois par instance, en utilisant la répartition par instance du panneau de contrôle. Les équipes qui sautent la répartition se trompent généralement dans le sens flatteur, en enfouissant l'infrastructure dans les frais généraux et en déclarant une marge que leur économie unitaire ne peut défendre. Un examen de due diligence la reclasse en un après-midi, et la marge retraitée n'est jamais la plus élevée.

Les normes comptables le confirment. Selon l'ASC 350-40, un contrat d'hébergement géré dans lequel le fournisseur exploite le logiciel est un contrat de service, et les frais sont passés en charge au fur et à mesure sur la période d'utilisation. Les travaux de mise en œuvre peuvent avoir leur propre traitement, mais la charge mensuelle de temps d'instance est une charge de la période, jamais un actif immobilisé. Les prépaiements sont l'image miroir : trésorerie décaissée aujourd'hui, charge plus tard, de sorte que le prépaiement demeure un actif prépayé et se libère en charge au fur et à mesure de la consommation du crédit. Comptabiliser le prépaiement en charge le jour du paiement surestime le mois du paiement et sous-estime chaque mois que le crédit couvre.

Comptabilisez le montant net que vous payez réellement. Le palier Lemming gratuit est une capacité gratuite, pas un revenu, il n'y a donc rien à majorer. Si vous voulez voir ce que la charge de travail coûterait sans lui, suivez cela dans vos métriques et tenez le grand livre au coût réel.

Comment le comptabiliser pour que la facture se rapproche​

Donnez au broker son propre compte de coût des ventes plutôt que de le mélanger aux dépenses cloud ou logiciels génériques. Un compte dédié tel que messagerie broker vous permet de diviser la dépense de production du mois par les secondes-instance du mois et de voir votre vrai coût par unité de capacité, qui est le chiffre qui vous dit si un redimensionnement a acheté de la marge de manœuvre ou simplement une facture plus importante.

Parce que la facturation fonctionne avec un décalage d'un mois, le rythme est provision, puis règlement, puis régularisation. Estimez la part du broker à partir des paliers d'instance et des secondes à la clôture, séparez la production du staging et corrigez selon la facture lorsqu'elle arrive. Voici un cycle complet pour un mois où la production a coûté 82,33 $ après un redimensionnement en cours de mois et le staging a ajouté 19,00 $ :

2026-01-01 open Assets:Cash:Operating USD
2026-01-01 open Assets:Prepaid:CloudAMQP USD
2026-01-01 open Expenses:CostOfSales:Message-Broker USD
2026-01-01 open Expenses:Research:Staging-Infra USD
2026-01-01 open Liabilities:Accrued:CloudAMQP USD
 
2026-01-31 * "CloudAMQP" "January estimate, prod Puffin-to-Penguin resize plus Ermine staging"
  Expenses:CostOfSales:Message-Broker  82.33 USD
  Expenses:Research:Staging-Infra  19.00 USD
  Liabilities:Accrued:CloudAMQP  -101.33 USD
 
2026-02-04 * "CloudAMQP" "January invoice settles, estimate was exact"
  Liabilities:Accrued:CloudAMQP  101.33 USD
  Assets:Cash:Operating  -101.33 USD

Lorsqu'un prépaiement couvre le mois, la branche de règlement tire sur l'actif prépayé plutôt que sur la trésorerie. Enregistrez le prépaiement comme un actif lorsque vous le payez, puis libérez la consommation de chaque mois :

2026-01-05 * "CloudAMQP" "Prepay 12 months Big Bunny at 99 per month"
  Assets:Prepaid:CloudAMQP  1188.00 USD
  Assets:Cash:Operating  -1188.00 USD
 
2026-01-31 * "CloudAMQP" "January consumption against prepayment, prod plus staging"
  Expenses:CostOfSales:Message-Broker  82.33 USD
  Expenses:Research:Staging-Infra  19.00 USD
  Assets:Prepaid:CloudAMQP  -101.33 USD

Suivez l'expiration à un an du prépaiement comme vous suivez tout crédit à utiliser ou à perdre. Un solde qui expire est une perte réelle, et il mérite un rappel de calendrier, pas une découverte lors du nettoyage de l'année suivante. Si vous tenez votre comptabilité en texte brut, les modèles de suivi des coûts dans la documentation s'étendent naturellement à une répartition du broker par instance.

Un piège de classification : un supplément de dépassement de transfert de données et un palier plus élevé sont tous deux des coûts de broker, mais ils signifient des choses différentes. Le changement de palier est de la capacité planifiée ; le dépassement est une consommation imprévue au-delà de la limite d'usage raisonnable. Comptabilisez les deux au compte broker, mais étiquetez ou notez le dépassement séparément afin que le mois où il apparaît se lise comme une exception plutôt que comme une nouvelle base de référence.

Cinq contrôles qui gardent le temps d'instance honnête​

La facturation à la seconde récompense l'attention et punit le « configurer et oublier ». Ces cinq contrôles attrapent les dérives courantes.

1. Rapprochez instance par instance, pas facture par facture​

Faites correspondre chaque ligne de facture à une instance que vous reconnaissez, à un palier que vous avez autorisé, pour des secondes qui couvrent à peu près le mois. Une ligne pour une instance que personne ne possède est généralement un broker de staging oublié ou un cluster de test de charge de trois sprints plus tôt qui facture toujours à la seconde. Supprimez sans pitié ; il n'y a aucune récompense pour la capacité inutilisée ici.

2. Consignez chaque redimensionnement avec son horodatage​

Chaque changement de plan découpe le mois en segments tarifés. Tenez un journal des changements léger, même une note partagée avec la date, l'instance, l'ancien palier et le nouveau palier, et rapprochez les segments de la facture de celui-ci. Sans le journal, un total mélangé comme 82,33 $ est une arithmétique invérifiable. Avec lui, le calcul se vérifie en une minute.

3. Ramenez les dépenses de marketplace dans la même revue​

Si une instance est facturée via Heroku ou une marketplace cloud, ajoutez ces lignes à la même revue mensuelle que la facture directe. Nommez la marketplace dans la narration du grand livre afin que le réviseur du mois suivant ne cherche pas une ligne CloudAMQP qui n'existera jamais. C'est aussi là que se cache la double facturation : une instance migrée d'une marketplace vers la facturation directe tourne parfois en double pendant quelques jours.

4. Surveillez la limite de transfert à usage raisonnable avant qu'elle ne soit facturée​

Le transfert de données est inclus jusqu'à 30 pour cent des dépenses de l'équipe, avec une fenêtre de résolution de 30 jours après un dépassement avant que les suppléments n'atteignent les factures ultérieures. Traitez le premier avis de dépassement comme le contrôle, pas le supplément. Vérifiez quelle instance a vu son trafic exploser, confirmez qu'il s'agit d'une croissance légitime et non d'une tempête de tentatives ou d'un consommateur bavard, et résolvez-le dans la fenêtre. Une boucle de tentatives qui se propage à travers un cluster peut transformer un mois calme en dépassement de transfert sans changer aucun palier.

5. Automatisez l'extraction​

Le panneau de contrôle liste chaque facture, et l'API client expose les opérations de facturation parallèlement à la gestion des instances, de sorte que l'extraction de fin de mois n'a pas besoin d'être un humain qui clique dans une console. Scriptez le téléchargement, analysez les lignes par instance et comparez avec votre journal des changements et votre provision. L'estimation de provision elle-même peut venir des mêmes données : tarifs des paliers multipliés par les secondes écoulées, ce qui bat l'estimation à partir du total du mois précédent chaque fois qu'un redimensionnement a eu lieu en cours de cycle.

Liste de vérification de fin de mois pour les coûts de broker​

Bouclez la boucle de la même manière chaque mois pour que les chiffres restent fiables :

  1. Listez chaque instance et cluster, facturés directement et via marketplace, et confirmez que chacun a toujours un propriétaire et un objectif.
  2. Rapprochez chaque ligne de facture à une instance, un palier et un segment de temps, en utilisant votre journal de redimensionnements pour tout total mélangé.
  3. Séparez la production des dépenses de staging et de bac à sable, et confirmez que seule la production est allée en coût des marchandises vendues.
  4. Régularisez la provision du mois précédent par rapport à la facture réglée et reportez l'écart dans l'estimation du mois suivant.
  5. Déduisez tout prépaiement par la consommation réelle, et vérifiez le solde restant par rapport à son expiration à un an.
  6. Confirmez que l'utilisation du transfert est restée dans la limite à usage raisonnable, et résolvez tout avis de dépassement dans sa fenêtre de 30 jours.
  7. Confirmez que chaque instance créée au cours du mois a hérité de la bonne étiquette d'environnement et est arrivée dans le bon compte dès le premier jour.

Téléchargez la facture CloudAMQP de ce mois aujourd'hui et faites correspondre chaque ligne à une instance que vous pouvez nommer. Si chaque ligne se rapproche proprement, votre comptabilité de broker est honnête. Si l'une ne le fait pas, vous venez de trouver soit une instance oubliée qui facture encore à la seconde, soit un jumeau de marketplace caché dans une autre facture, et l'une ou l'autre découverte paie la revue.

Source : https://beancount.io/fr/blog/2026/11/10/cloudamqp-instance-time-billing-infra-cogs-reconciliation-guide

Publié: 10 novembre 2026