MeterFlow

MeterFlow · Guide du tableau de bord

Chaque boîte de dialogue « Nouveau … », expliquée en langage clair

Le tableau de bord MeterFlow comporte quelques boîtes de dialogue qui créent de vrais enregistrements dans la base de données — meters, plans, abonnements, crédits, événements d’usage, clés API. Cette page explique ce que fait chacune, champ par champ, avec des exemples simples. Aucune connaissance préalable du metering ou de la facturation à l’usage n’est nécessaire.

Commencez ici : la vue d’ensemble

MeterFlow répond à une seule question pour votre produit : « qui a utilisé combien de quoi — et combien cela lui coûte ? » Tout ce que vous voyez dans le tableau de bord existe pour répondre à cette question.

Vous admin clientLe développeur ou l’entreprise qui utilise MeterFlow. Vous vous connectez à ce tableau de bord, définissez quoi mesurer et fixez les règles tarifaires.
Votre application le SDKVotre propre backend, avec le SDK MeterFlow installé. Il envoie les événements d’usage automatiquement à mesure que vos clients utilisent votre produit. Les boîtes de dialogue usage/crédits/abonnements font à la main exactement ce que le SDK fait dans le code.
Votre client ID clientL’utilisateur final de votre produit. Il ne se connecte jamais à MeterFlow et n’a pas de compte MeterFlow — il n’existe ici que sous la forme d’une chaîne d’identification que vous choisissez (p. ex. user-842 ou un e-mail).

Comment les pièces s’assemblent

Pourquoi certains boutons « Créer » sont-ils grisés ?

Chaque boîte de dialogue désactive son bouton de confirmation tant que tous les champs obligatoires (marqués *) ne sont pas remplis — p. ex. « Create plan » reste désactivé tant que le plan n’a pas de Nom. Si un bouton semble bloqué, cherchez un champ obligatoire vide plus haut.

Nouvelle organisation conteneur

Le conteneur le plus externe — généralement votre entreprise. Tout le reste (projets, meters, plans…) vit à l’intérieur d’une organisation. Vous en avez reçu une automatiquement à l’inscription.

📍 Dashboard → le bouton « New organization » (proposé aussi à la première connexion, quand vous n’en avez pas encore)

  • Name *

    Le nom de votre entreprise ou de votre équipe. Une simple étiquette — modifiable plus tard.

  • Billing email

    Où iraient les factures et avis de facturation de votre compte MeterFlow. Facultatif ; le format est validé, mais rien n’est envoyé pour le vérifier.

ExempleAcme Robotics crée l’organisation « Acme Robotics » avec l’e-mail de facturation [email protected]. Ses deux produits deviendront deux projets à l’intérieur.

Nouveau projet conteneur

Un projet = un produit ou un environnement à mesurer. Chaque meter, plan, clé API, solde client et événement d’usage appartient à exactement un projet — les projets ne voient jamais les données les uns des autres.

📍 Dashboard → le bouton « New project » dans l’en-tête du tableau Projects

  • Organization *

    À quelle organisation appartient le projet. Présélectionnée si vous en avez déjà une active.

  • Name *

    Le nom du produit, p. ex. « PixelForge AI ». Affiché partout dans le tableau de bord et dans le sélecteur de projet.

  • Description

    Texte libre, pour votre propre référence.

ExempleAcme a un outil d’images et un chatbot. Ils créent deux projets — « PixelForge AI » et « ChatDesk » — pour que chaque produit ait ses propres meters, plans et soldes clients. Le même ID client dans deux projets est traité comme deux clients sans aucun lien.

Générer une clé API accès

L’identifiant que votre application utilise pour parler à MeterFlow. Votre backend le transmet au SDK ; chaque événement d’usage, opération de crédits et appel d’abonnement est authentifié — et limité à un seul projet — par cette clé.

📍 Ouvrez un projet → API Keys → le bouton dans l’en-tête du tableau

  • Key name *

    Une étiquette pour vous rappeler où la clé est utilisée — « Backend de production », « Staging », « Tests CI ». Aucun effet technique.

  • Environment

    Les clés Live commencent par mf_live_, les clés Test par mf_test_ — et elles accèdent à deux jeux de données totalement séparés au sein du même projet. Les abonnements, crédits et usages créés avec une clé Test sont invisibles pour les clés Live (et inversement), tandis que vos meters et plans sont partagés : vos tests s’exécutent donc toujours contre votre vraie configuration de facturation. Utilisez des clés Test pour le développement, le staging et la CI ; les clés Live uniquement pour le vrai trafic de production.

Important — affichée une seule foisLa clé complète n’est affichée qu’une seule fois, juste après sa création. MeterFlow ne conserve qu’une empreinte cryptographique (un hachage SHA-256) — la vraie clé ne pourra plus jamais être affichée, pas même par nous. Copiez-la immédiatement dans votre coffre à secrets. Si vous la perdez, révoquez-la et générez-en une nouvelle.
ExempleVous créez « Production backend » / Live, obtenez mf_live_a1b2… une seule fois, et la placez dans les variables d’environnement de votre serveur : new MeterFlow({ apiKey: process.env.METERFLOW_KEY }). La liste du tableau de bord n’affichera plus jamais que le préfixe et les 4 derniers caractères.

Nouveau meter concept clé

Un meter est la définition d’un compteur nommé : il déclare une chose de votre produit qui mérite d’être mesurée, et la façon de transformer les événements bruts en un nombre. Voyez-le comme la création d’une nouvelle colonne dans un rapport d’usage, avant même qu’il n’existe des données.

📍 Ouvrez un projet → Meters → le bouton dans l’en-tête du tableau

  • Name *

    L’étiquette lisible affichée dans le tableau de bord — « Images générées », « Secondes de rendu vidéo ». Pour les yeux humains uniquement.

  • Event name *

    La clé machine — et oui, elle est stockée dans la base de données et comparée à l’exactitude près. Quand votre application signale un usage, elle envoie un nom d’événement ; MeterFlow cherche dans ce projet le meter actif dont l’event_name correspond exactement, casse comprise. S’il n’en existe aucun, l’événement est rejeté avec une erreur 404 (« No active meter found for event … ») et rien n’est enregistré. Chaque nom d’événement est unique au sein d’un projet. Convention : minuscules avec des points, p. ex. image.generated.

  • Aggregation type

    Comment de nombreux événements individuels sont combinés en un seul nombre dans les récapitulatifs d’usage. Voir le tableau ci-dessous — c’est le cœur du meter.

  • Aggregation field

    Obligatoire pour tous les types sauf Count. Il nomme le champ numérique de l’événement qui porte la quantité à agréger — c’est la réponse à « la somme de quoi ? ». En pratique votre app envoie le nombre dans le champ value de l’événement, et c’est lui qui est agrégé ; l’aggregation field documente ce que signifie cette valeur (p. ex. seconds, tokens, megabytes) afin que quiconque lit le meter connaisse l’unité. Pour Count, il est sans objet — compter n’exige que l’existence de l’événement.

  • Description

    Texte libre pour votre équipe.

Les types d’agrégation, par l’exemple

Supposons que le client user-842 déclenche 4 événements ce mois-ci avec les valeurs 3, 10, 2, 10. Un seul nombre est rapporté par meter — lequel dépend du type d’agrégation :

TypeÀ quelle question il répondRésultat pour 3, 10, 2, 10Usage typique
CountCombien de fois est-ce arrivé ? (valeurs ignorées)4Images générées, appels API, exports
SumCombien au total ?25Secondes de rendu, tokens consommés, Go transférés
MaxQuelle a été la plus grande valeur ?10Pic de tâches simultanées, plus gros envoi
MinQuelle a été la plus petite valeur ?2Rarement pour facturer — surtout du diagnostic
Unique countCombien de valeurs distinctes sont apparues ?3  (3, 10, 2)Jours actifs distincts, documents distincts touchés
Exemple — un meter completName « Video render seconds » · Event name video.rendered · Agrégation Sum · Aggregation field seconds.
Votre app termine le rendu d’un clip de 42 secondes pour user-842 et signale l’événement video.rendered avec la valeur 42. Répétez quelques fois et la page d’usage du client affichera une ligne : Video render seconds — 3 événements — 117.
Le nom d’événement doit-il correspondre à ce qu’envoie mon app ? Que se passe-t-il en cas de faute de frappe ?

Oui — exactement, casse comprise. Le nom d’événement du meter est stocké dans la base de données et sert d’étiquette d’adressage pour les événements entrants. Si votre app envoie video.render alors que le meter dit video.rendered, l’API répond 404 « No active meter found for event 'video.render' in this project » et l’événement n’est pas stocké. C’est voulu : une faute de frappe silencieuse laisserait fuir à jamais de l’usage non facturé. Créez d’abord le meter, puis commencez à envoyer des événements portant le même nom.

Puis-je changer le type d’agrégation plus tard ?

Non — après la création, seuls le nom, la description et l’indicateur actif sont modifiables. L’agrégation définit ce que signifie l’historique stocké ; la changer rétroactivement réécrirait le passé. S’il vous faut un autre calcul, créez un nouveau meter avec un nouveau nom d’événement.

Pourquoi « Aggregation field » est-il facultatif dans le formulaire alors qu’il est dit obligatoire ?

Le formulaire le laisse librement vide parce qu’il n’est obligatoire que pour les types autres que Count — c’est le serveur qui fait respecter la règle. Si vous choisissez Sum/Max/Min/Unique count en le laissant vide, la création est rejetée avec une erreur de validation claire ; avec Count, vous pouvez ignorer complètement ce champ.

Nouveau plan concept clé

Un plan est un palier tarifaire — « Free », « Pro à 29 $/mois »… Il associe un prix récurrent à un ensemble de limites de meter qui disent quelle quantité de chaque fonction mesurée est incluse et ce qui se passe au-delà. Les clients sont rattachés à un plan via un abonnement.

📍 Ouvrez un projet → Plans → le bouton dans l’en-tête du tableau

  • Name *

    Le nom du palier — « Free », « Pro », « Enterprise ». Obligatoire ; le bouton de création reste désactivé tant qu’il n’est pas rempli.

  • Description

    Texte libre, p. ex. la phrase d’accroche marketing du palier.

  • Price / Currency / Billing period

    L’abonnement récurrent : Price est le montant (0 convient très bien à un palier gratuit), Currency un code comme USD, et Billing period la fréquence — mensuel, annuel, hebdomadaire ou paiement unique. Figés après la création — modifier le plan ensuite ne peut pas les changer (créez plutôt un nouveau plan, pour que les conditions des abonnés existants ne changent pas en douce).

  • Trial days

    Jours gratuits au début de chaque nouvel abonnement. Avec 14, un nouvel abonné passe 2 semaines au statut « trialing » avant le début de la période payante. 0 = pas d’essai.

  • Public

    Si le plan est visible par votre application via la liste des plans du SDK (p. ex. pour afficher votre page tarifaire). Décoché = interne/masqué — utile pour des accords enterprise sur mesure ou des plans encore en brouillon.

Limites de meter — la section « + Add limit »

Chaque ligne de limite relie ce plan à un meter et répond à : quelle quantité de cette chose est incluse, et que se passe-t-il au-delà ?

  • Meter *

    À quelle grandeur mesurée cette limite s’applique. La liste déroulante affiche les meters que vous avez créés dans ce projet — ni plus, ni moins. Ce n’est pas un catalogue figé : toute nouvelle capacité du produit demande simplement un nouveau meter d’abord, et il apparaît ici aussitôt.

  • Included units

    Le volume compris dans le prix du plan, par période de facturation. « Pro inclut 500 images par mois » → 500.

  • Overage rate

    Le prix en crédits par unité une fois que le client dépasse les unités incluses. 0.5 signifie que chaque unité supplémentaire coûte un demi-crédit sur le solde du client. N’a de sens qu’avec le type de limite Metered.

  • Limit type

    Hard (bloquer) — l’usage au-delà des unités incluses doit être refusé ; le client se heurte à un mur. Soft (avertir) — l’usage continue, mais vous êtes prévenu pour inciter le client à passer au palier supérieur. Metered (facturer) — l’usage continue et chaque unité supplémentaire est automatiquement prélevée sur le solde de crédits du client au tarif de dépassement. Metered est l’option « paiement à l’usage » et la seule qui déplace de l’argent (des crédits) toute seule.

Exemple — un plan Pro réalistePro · 29 $ USD · Mensuel · 14 jours d’essai · Public ✓
Limite 1 : meter Images générées, incluses 500, type Hard → après 500 images, la génération est bloquée jusqu’au mois suivant ou à une montée en gamme.
Limite 2 : meter Secondes de rendu vidéo, incluses 1 000, dépassement 0,02, type Metered → au-delà de 1 000 secondes, chaque seconde supplémentaire coûte en silence 0,02 crédit du portefeuille du client.
Pourquoi « + Add limit » est-il grisé ?

Parce que le projet n’a pas encore de meter — une limite est toujours un plafond sur un meter ; sans meter, il n’y a rien à quoi la rattacher. La boîte de dialogue affiche l’indice « Create meters first to attach limits to this plan. » Allez dans Meters → New meter, créez-en au moins un, puis rouvrez cette boîte de dialogue.

Pourquoi la liste Meter ne montre-t-elle que quelques options ? Et si mon produit a quelque chose de nouveau ?

La liste déroulante, ce sont simplement vos propres meters du projet sélectionné. Dans les données de démonstration, il se trouve que ce sont « Upscales processed », « Video render seconds » et « Images generated » — mais cette liste vous appartient et peut grandir. Elle ne restreint pas ce que les clients peuvent faire : les clients ne choisissent jamais de meters ; c’est vous qui définissez des meters pour tout ce que fait votre produit. Une nouvelle fonctionnalité demain ? Créez un meter pour elle et il apparaîtra ici.

Pourquoi ne puis-je pas modifier le prix ou les limites d’un plan existant ?

C’est voulu : les abonnés existants ont souscrit à ces conditions, donc le prix, la devise, la période de facturation et les limites de meter sont gelés à la création. La modification d’un plan ne peut changer que son nom, sa description, ses jours d’essai, sa visibilité et son indicateur actif. Pour changer les tarifs, créez un nouveau plan (p. ex. « Pro 2026 ») et orientez-y les nouveaux clients.

Nouvel abonnement relie client ⇄ plan

Un abonnement rattache un de vos clients à un plan. À partir de ce moment, son usage est jugé à l’aune des limites de meter de ce plan. En production, c’est généralement votre backend qui le crée via le SDK à l’instant où quelqu’un choisit un palier au paiement — la boîte de dialogue fait la même chose à la main.

📍 Ouvrez un projet → Subscriptions → le bouton dans l’en-tête du tableau

  • Customer ID *

    Votre propre identifiant du client final — n’importe quelle chaîne de votre choix : un ID utilisateur de votre base (user-842), un e-mail, un slug de tenant. MeterFlow ne le valide contre rien ; ce que vous envoyez désigne le propriétaire de l’abonnement. Utilisez le même ID partout (abonnements, crédits, usage), sinon les pièces ne se relieront pas.

  • Plan *

    Sur quel palier tarifaire il se trouve — la liste affiche les plans de ce projet. Si le plan a des jours d’essai, l’abonnement démarre en « trialing » ; sinon en « active ».

ExempleLe client user-842 clique sur « Passer à Pro » dans votre app → votre backend appelle subscriptions.create({ customer_external_id: 'user-842', plan_id: … }). Chaque événement d’usage de user-842 est désormais confronté aux limites de Pro.
Et si un client n’a pas d’abonnement — ses événements sont-ils perdus ?

Non. Les événements sont toujours stockés et apparaissent toujours dans les récapitulatifs d’usage. Mais sans abonnement actif, il n’y a pas de limites de plan à appliquer : rien n’est bloqué, rien n’est facturé — l’usage est simplement enregistré. La logique de facturation s’active à l’instant où un abonnement existe.

Créditer / Débiter des crédits le portefeuille

Les crédits sont un solde prépayé par client (par projet) — pensez à un portefeuille ou à une carte rechargeable. C’est vous qui décidez de la valeur d’un crédit dans votre tarification. Le dépassement « metered » puise dans ce portefeuille automatiquement ; les deux boîtes de dialogue déplacent des crédits à la main.

📍 Ouvrez un projet → Credits → recherchez un client → « Grant » / « Deduct »

  • Amount *

    Combien de crédits ajouter (Grant) ou retirer (Deduct). Doit être supérieur à zéro — la direction est décidée par le bouton qui a ouvert la boîte de dialogue, pas par un signe moins.

  • Description

    Une note facultative enregistrée sur la ligne du registre — « Bonus de bienvenue », « Remboursement suite à l’incident », « Geste commercial ». Votre futur vous dira merci.

ExempleLe nouvel inscrit user-842 reçoit un crédit de 100 (« Bonus de bienvenue »). Il rend 2 500 secondes de vidéo sur un plan avec 1 000 incluses et un dépassement metered de 0,02 → 1 500 × 0,02 = 30 crédits débités automatiquement. Solde : 70.
Bon à savoir — le registre ne ment jamaisLes soldes ne sont jamais modifiés directement. Chaque crédit, débit et prélèvement automatique d’usage est une nouvelle ligne permanente dans un registre en ajout seul, qui note le solde avant et après — une piste d’audit complète, comme un relevé bancaire. Une erreur ? On ne supprime pas la ligne ; on en ajoute une de compensation. Et un débit supérieur au solde est refusé net (l’API renvoie une erreur « 402 solde insuffisant ») — un portefeuille ne peut pas passer en négatif.

Enregistrer un événement d’usage concept clé

Un événement d’usage = « ce client vient de faire cette chose, dans cette quantité. » En production, votre application les envoie automatiquement via le SDK, des milliers de fois par jour ; la boîte de dialogue existe pour en injecter un à la main, pour les tests et les démos.

📍 Ouvrez un projet → Usage → recherchez un client → « Record event »

  • Event name *

    Doit correspondre exactement au nom d’événement d’un meter existant et actif dans ce projet (sensible à la casse). C’est cette correspondance qui indique à MeterFlow quel compteur cet événement alimente. Aucun meter correspondant → l’API rejette l’événement avec un 404 et rien n’est stocké. Vérifiez l’orthographe exacte sur la page Meters.

  • Customer ID *

    Lequel de vos clients l’a fait — la même chaîne d’ID libre que pour les abonnements et les crédits. La cohérence est primordiale : user-842 et USER-842 sont deux clients différents.

  • Value

    La quantité, 1 par défaut. Sa signification dépend de l’agrégation du meter : pour un meter Count, la valeur est ignorée (chaque événement compte pour une occurrence) ; pour Sum, c’est la quantité à additionner (42 secondes, 1 300 tokens) ; pour Max/Min, c’est la mesure comparée ; pour Unique count, c’est la chose dont on compte les valeurs distinctes.

Ce qui se passe après avoir appuyé sur « Record » — le parcours complet1. Le nom d’événement est associé à un meter — disons video.rendered → « Video render seconds ». 2. L’événement est stocké définitivement (brut — l’agrégation a lieu plus tard, à la lecture). 3. En arrière-plan, MeterFlow vérifie si le client a un abonnement actif et si ce plan a une limite sur ce meter. 4. Si la limite est Metered avec un tarif de dépassement, le montant (valeur × tarif) est débité du solde de crédits du client et une ligne de registre est écrite. 5. Le récapitulatif d’usage affiché sur cette page est recalculé à partir des événements bruts selon le type d’agrégation du meter.
J’ai enregistré un événement et j’ai eu une erreur — pourquoi ?

Presque toujours le nom d’événement : il ne correspond exactement à aucun meter actif de ce projet. L’erreur le dit mot pour mot — « No active meter found for event '…' in this project. » Copiez le nom d’événement depuis la page Meters plutôt que de le retaper. Notez aussi que les meters sont propres à chaque projet : un meter d’un autre projet ne compte pas.

Si mon app rejoue une requête, l’événement sera-t-il compté deux fois ?

Pas si vous utilisez le SDK correctement : chaque écriture accepte une clé d’idempotence — une étiquette unique pour « cette action précise ». Si la même clé arrive deux fois (une nouvelle tentative après un raté réseau), MeterFlow la reconnaît et renvoie le résultat d’origine au lieu de stocker un doublon. La boîte de dialogue manuelle n’en envoie pas : appuyer deux fois sur Record à la main crée donc bel et bien deux événements.

Inviter un membre accès de l’équipe

Ajoute un collègue à votre organisation pour qu’il puisse voir (ou gérer) ses projets dans ce tableau de bord. La personne doit déjà avoir un compte MeterFlow — l’inscription d’abord, l’invitation ensuite.

📍 Dashboard → tableau Organizations → action de ligne « Invite member »

  • Email *

    L’e-mail sous lequel son compte MeterFlow est enregistré.

  • Role

    Admin — gestion complète : projets, meters, plans, clés, membres. Member — les opérations du quotidien. Viewer — lecture seule. Notez qu’il n’y a délibérément pas d’option « owner » : la propriété ne se distribue pas par invitation.

ExempleVous invitez [email protected] comme Viewer pour que l’équipe finance puisse suivre l’usage et les soldes sans pouvoir changer les tarifs.