MeterFlow 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.
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.
finance@acme.dev. 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.
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 parmf_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.
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_namecorrespond 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
valuede 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épond | Résultat pour 3, 10, 2, 10 | Usage typique |
|---|---|---|---|
| Count | Combien de fois est-ce arrivé ? (valeurs ignorées) | 4 | Images générées, appels API, exports |
| Sum | Combien au total ? | 25 | Secondes de rendu, tokens consommés, Go transférés |
| Max | Quelle a été la plus grande valeur ? | 10 | Pic de tâches simultanées, plus gros envoi |
| Min | Quelle a été la plus petite valeur ? | 2 | Rarement pour facturer — surtout du diagnostic |
| Unique count | Combien de valeurs distinctes sont apparues ? | 3 (3, 10, 2) | Jours actifs distincts, documents distincts touchés |
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.5signifie 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.
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 ».
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.
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.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-842etUSER-842sont deux clients différents. - Value
La quantité,
1par 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.
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.
dana@acme.dev comme Viewer pour que l’équipe finance puisse suivre l’usage et les soldes sans pouvoir changer les tarifs.