Votre facture Tecton affiche un chiffre, votre facture AWS porte discrètement le reste, et aucun des deux documents ne se présente comme le coût complet du serving des features. Cette scission est le piège. Tecton facture à la consommation — des crédits de calcul pour les pipelines qu'il exécute, plus les ressources cloud que ces pipelines consomment sur votre propre compte — de sorte que la facture que vous recevez de Tecton ne représente jamais qu'une partie de la dépense. Si vos livres enregistrent la facture et s'arrêtent là, votre coût des marchandises vendues est sous-estimé, votre marge brute est surévaluée, et chaque décision de tarification que vous prenez sur cette marge repose sur un chiffre qui n'a jamais été complet.
Cet article explique comment Tecton mesure et facture réellement, pourquoi le serving des features en production relève du coût des marchandises vendues, comment traiter les crédits prépayés et les engagements de consommation, et comment tout rapprocher en fin de mois afin que chaque dollar atterrisse sur le bon compte.
Comment Tecton mesure : des vues de features, pas des sièges
Tecton est une plateforme de features managée pour le machine learning. Vous définissez des transformations sur vos données sous forme de vues de features, Tecton les calcule sur des pipelines batch ou streaming, et sert les résultats à vos modèles — un store offline pour la récupération à grande échelle pour l'entraînement et un store online pour la récupération à faible latence lors de l'inférence en direct. Il n'y a pas de licences par siège à compter. Vous payez pour ce que la plateforme consomme pendant qu'elle calcule, stocke et sert vos features.
Cette consommation se répartit en deux catégories qui se facturent à deux endroits différents, et c'est la première chose à intégrer.
La première catégorie, ce sont les crédits Tecton. Ils couvrent le calcul que Tecton gère en votre nom : les crédits de calcul Spark streaming pour les vues de features en streaming, les crédits de calcul Spark batch pour les vues de features batch. Votre usage de la plateforme se traduit en crédits, et les crédits apparaissent sur la facture Tecton.
La seconde catégorie, c'est l'infrastructure elle-même, et elle est facturée via votre propre compte cloud. Tecton gère des ressources de calcul et de stockage dans votre environnement AWS ou GCP, de sorte que les lectures et écritures du store online, le calcul des clusters Spark, le stockage du store online et le stockage S3 atterrissent tous sur votre facture cloud — pas sur celle de Tecton. Une équipe qui provisionne via un canal et rapproche via l'autre trouvera toujours un écart. Décidez une fois pour toutes que le coût réel d'une vue de features est la somme des deux catégories, et assurez-vous que votre extraction de fin de mois couvre à la fois la facture Tecton et les lignes taguées de la facture cloud.
Les vues de features en streaming et en batch consomment différemment
Les composantes de coût diffèrent selon le type de vue de features, et savoir lesquelles vous exploitez vous indique quelles lignes surveiller.
Les vues de features en streaming portent les lectures et écritures du store online, le calcul du cluster Spark streaming, les crédits de calcul Spark streaming de Tecton, le stockage S3 et le stockage du store online. Les vues de features batch portent une liste similaire — lectures et écritures du store online, calcul du cluster de jobs Spark, crédits de calcul Spark batch de Tecton et stockage S3 — moins les éléments propres au streaming.
Les paramètres qui font bouger la facture sont les choix de conception que vos ingénieurs ML font chaque jour. Le traitement continu en streaming fait des checkpoints et des écritures bien plus souvent que le traitement par intervalles, donc il coûte plus cher. Des fenêtres d'agrégation plus larges nécessitent plus de calcul. Des watermarks plus longs pour les données arrivant en retard augmentent les besoins en mémoire. La configuration du cluster tarifie directement chaque job. La compaction des données réduit le coût de stockage et améliore les performances en lecture. Aucun de ces réglages n'est un paramètre financier ; ce sont des paramètres d'ingénierie aux conséquences financières, et c'est pourquoi la comptabilisation de cette plateforme commence par une conversation entre les deux équipes sur les vues de features existantes et sur leur calibration.
La hiérarchie des coûts vous indique où va l'argent
Les propres recommandations de Tecton classent l'impact sur les coûts du plus élevé au plus faible, et cet ordre mérite d'être mémorisé car il prédit d'où viendront vos surprises.
Les opérations du store online arrivent en tête. Les écritures vers le store online constituent généralement le coût d'infrastructure le plus élevé, en particulier lors des backfills — le recalcul de features historiques pour une vue de features nouvelle ou modifiée — ou en traitement continu en streaming. Un backfill est un pic planifié : des jours ou des semaines de calcul historique et un flot d'écritures compressés dans une seule fenêtre. Si personne ne prévient la finance que cela arrive, le mois où il tombe ressemble à un dépassement de coûts plutôt qu'à un investissement.
Les ressources de calcul viennent ensuite : les coûts des clusters Spark pour le traitement streaming et batch, variables selon la configuration et la charge. Le stockage vient en troisième : le stockage et les lectures du store online plus S3, généralement d'impact inférieur au calcul et aux écritures.
La conséquence pratique est que votre facture est pilotée par les écritures et les événements de calcul, pas par le nombre de personnes qui se connectent à la console. La planification de capacité ici consiste à gouverner les backfills, les modes de traitement et les fenêtres d'agrégation — pas les effectifs.
Pourquoi le serving des features en production est du COGS
Selon les US GAAP, le coût des marchandises vendues d'une entreprise SaaS — le coût des revenus — inclut les coûts directs de prestation du service que les clients paient : l'infrastructure d'hébergement, le calcul et le stockage cloud, les logiciels tiers intégrés au produit, et tout ce qui évolue avec l'usage. Le serving des features pour un produit ML en production franchit facilement ce seuil. Quand votre modèle de fraude évalue une transaction, que votre moteur de recommandation classe un fil, ou que votre modèle de tarification propose un prix, les lectures du store online et les pipelines qui maintiennent ces features à jour sont un coût de prestation aussi direct que les serveurs applicatifs derrière eux.
Cette classification compte parce qu'elle se répercute directement sur la marge brute, le chiffre que les investisseurs, prêteurs et acquéreurs utilisent pour juger si l'économie de votre produit fonctionne. Loger les coûts de serving sous la ligne dans les charges d'exploitation générales gonfle la marge brute et masque l'histoire de la montée en charge. Une équipe de due diligence remappera de toute façon votre grand livre à une définition standard des COGS SaaS ; classer correctement dès le départ signifie que vos propres tableaux de bord racontent la même histoire que celle qu'un tiers calculera.
Tout dollar Tecton n'appartient pas au COGS pour autant. La répartition suit l'usage, pas le fournisseur :
- Le serving en production est du COGS. Les lectures et écritures du store online pour l'inférence en direct, les pipelines streaming et batch qui maintiennent les features de production à jour, et le stockage derrière eux concourent tous à la prestation du service orienté client.
- L'expérimentation et le staging sont des charges d'exploitation. Les vues de features de développement, l'expérimentation offline et les environnements de staging soutiennent la recherche et le développement, pas la prestation. Passez-les en R&D.
- Le travail dédié à l'entraînement requiert du jugement. Le calcul de features offline qui n'existe que pour entraîner la prochaine version du modèle ressemble davantage à de la R&D qu'à de la prestation ; le même pipeline alimentant le store online pour le serving en direct est du COGS. Quand une même vue de features fait les deux, allouez selon un driver défendable — les dépenses cloud taguées par environnement sont le plus propre dont disposent la plupart des équipes.
Tecton tague les instances de calcul et les ressources du store online par vue de features, donc les données d'allocation existent dans votre explorateur de coûts cloud. La tâche comptable consiste à décider du mapping une fois — quelles vues de features servent la production, lesquelles servent l'expérimentation — puis à l'appliquer chaque mois au lieu de le redébattre à chaque clôture.
Acheter Tecton est une charge ; construire l'équivalent peut être un actif
Une autre classification mérite d'être bien faite : l'équipe qui achète Tecton passe la consommation en charge comme décrit ci-dessus, mais l'équipe qui construit son propre feature store sur des logiciels open source fait face à une question d'activation en immobilisation. Un logiciel à usage interne développé pour vos propres opérations peut être éligible à l'activation dès qu'un projet franchit le stade préliminaire, ce qui transforme les salaires d'ingénierie et l'infrastructure en actif amortissable plutôt qu'en charge de la période.
Aucun des deux traitements n'est une coloration facultative. Si vous exploitez Tecton, n'activez pas ses factures comme si vous aviez construit la plateforme. Si vous migrez d'un store auto-construit vers Tecton, l'ancien actif activé continue de s'amortir tandis que la nouvelle consommation frappe le COGS — deux lignes différentes, deux histoires différentes, toutes deux correctes en même temps.
Les crédits prépayés et les engagements sont d'abord des actifs, des charges ensuite
Les plateformes à la consommation vendent couramment des crédits prépayés ou des engagements de dépense annuels, et la comptabilisation des deux suit le principe de rattachement des charges aux produits : enregistrez le paiement comme un actif, puis passez-le en charge à mesure que l'avantage est consommé. Un dollar viré à un fournisseur d'avance n'est encore le coût de rien. Il devient du COGS quand les crédits se consument contre le serving en production, de la R&D quand ils se consument contre l'expérimentation, et une perte s'ils expirent sans usage.
En pratique, cela signifie trois écritures, pas une. Quand vous achetez des crédits, débitez un actif prépayé et créditez la trésorerie. Chaque mois, diminuez le solde de ce qui a été réellement consommé — la consommation de production en COGS, la consommation de staging en R&D. Si les crédits portent une date d'expiration, inscrivez-la au calendrier ; un solde expiré est une perte réelle qui mérite une dépréciation planifiée, pas une découverte lors du nettoyage de l'année suivante.
Les minimums take-or-pay ajoutent une provision par-dessus. Si votre contrat vous engage à un minimum de dépense trimestriel, vous devez le plus élevé entre la consommation réelle et le minimum. Quand la consommation passe sous l'engagement en fin de période, provisionnez le manque que vous devrez de toute façon. La facture arrivera plus tard, mais le passif existe à la date de bilan, et la clôture doit le refléter.
Rapprocher en fin de mois : deux factures, une seule vérité
Tecton publie des journaux d'usage facturable — des enregistrements CSV détaillés de l'usage de la plateforme et de sa traduction en crédits, déposés dans votre propre stockage objet environ un ou deux jours après l'usage. Combinés aux dépenses cloud taguées, ces journaux sont les relevés de compteur auxquels s'accroche votre rapprochement. Traitez le processus mensuel comme une mise en correspondance de trois sources entre elles : les journaux d'usage, la facture Tecton et la facture cloud.
Une checklist de clôture praticable ressemble à ceci :
- Extraire les journaux d'usage du mois complet. Confirmez que les crédits de chaque vue de features de production et de chaque expérience sont présents, y compris les deux derniers jours — le décalage des journaux signifie qu'une clôture lancée le premier du mois manque de données. Soit attendez les journaux, soit provisionnez les derniers jours à partir du rythme de croisière et régularisez le mois suivant.
- Provisionner le côté Tecton non facturé. Comme la plupart de la facturation à la consommation, la facture arrive après la période qu'elle couvre. Passez une provision pour les crédits estimés du mois en COGS et en R&D selon la répartition par environnement, puis extournez et régularisez quand la facture arrive.
- Extraire les dépenses cloud taguées. Filtrez votre explorateur de coûts cloud par les tags de vues de features pour la même période. C'est la seconde catégorie — clusters Spark, opérations du store online, stockage — et elle doit être répartie entre prod et staging de la même manière.
- Rapprocher journaux, facture et facture cloud. Les journaux d'usage doivent se rattacher à la facture Tecton ; les lignes cloud taguées doivent évoluer dans le même sens. Un mois avec backfill fera culminer les deux. Une facture qui diverge des journaux est une question de facturation à soulever maintenant, pas au renouvellement.
- Débiter les prépaiements et les engagements. Passez en charge les crédits consommés en les sortant de l'actif prépayé, provisionnez tout manque d'engagement, et confirmez que les soldes restants semblent encore utilisables avant expiration.
L'échec le plus courant est l'étape trois — rapprocher méticuleusement la facture Tecton tandis que la dépense côté cloud se cache dans une facture d'infrastructure plus large sous un hébergement générique. Si votre relevé cloud affiche une seule ligne de calcul mélangée, corrigez le tagging avant toute autre chose. Une dépense non taguée ne peut pas être allouée, et une dépense non allouée finit toujours quelque part de travers.
Un mois concret dans les livres
Supposons que votre plateforme ML consomme en janvier des crédits Tecton facturés 40 000 $ contre le serving en production et 8 000 $ contre l'expérimentation, plus 12 000 $ de dépenses cloud taguées réparties en 9 500 $ pour la production et 2 500 $ pour le staging. Vous avez aussi prépayé 100 000 $ de crédits au début du trimestre. Les livres de janvier se présentent ainsi :
2026-01-01 open Assets:Cash:Operating USD
2026-01-01 open Assets:Prepaid:Tecton-Credits USD
2026-01-01 open Expenses:CostOfSales:Feature-Serving USD
2026-01-01 open Expenses:Research:ML-Experimentation USD
2026-01-01 open Liabilities:Accrued:Tecton USD
2026-01-01 open Liabilities:Accrued:Cloud USD
2026-01-05 * "Tecton" "Prepay Q1 consumption credits"
Assets:Prepaid:Tecton-Credits 100000.00 USD
Assets:Cash:Operating -100000.00 USD
2026-01-31 * "Tecton" "January credit consumption, prod serving plus experimentation"
Expenses:CostOfSales:Feature-Serving 40000.00 USD
Expenses:Research:ML-Experimentation 8000.00 USD
Assets:Prepaid:Tecton-Credits -48000.00 USD
2026-01-31 * "Cloud" "January tagged feature-platform infra, prod plus staging"
Expenses:CostOfSales:Feature-Serving 9500.00 USD
Expenses:Research:ML-Experimentation 2500.00 USD
Liabilities:Accrued:Cloud -12000.00 USDLe schéma se généralise : le prépaiement est un actif, la consommation le transfère en charge par environnement, et le côté cloud se provisionne séparément parce qu'il se facture séparément. Si votre équipe tient ses livres en texte brut, les modèles de suivi des coûts dans la documentation s'étendent naturellement à une répartition par vue de features, et les vues de tableau de bord rendent visible mois après mois la tendance prod contre staging.
Des erreurs qui faussent la marge
Quatre erreurs reviennent sans cesse chez les équipes exploitant une infrastructure ML facturée à la consommation. Chacune est peu coûteuse à prévenir et coûteuse à défaire sur des périodes retraitées.
Enregistrer la facture Tecton comme le coût total. La facture est une catégorie. Chaque mois, le calcul côté cloud, les opérations du store online et le stockage ajoutent une seconde catégorie d'ampleur comparable, et l'omettre sous-estime le COGS de près de moitié. Rapprochez les deux ou ne présentez ni l'une ni l'autre.
Passer les prépaiements en charge au moment du paiement. Un achat de 100 000 $ de crédits n'est pas une charge de 100 000 $ le mois où le virement part. C'est un actif qui se convertit en charge à mesure que les crédits se consument. Passer en charge au paiement charge d'avance le trimestre, prive les mois suivants de leur coût réel et rend illisibles les tendances de consommation.
Affecter le staging au COGS. Les vues de features d'expérimentation, les backfills offline pour la recherche de modèles et les environnements de staging relèvent de la R&D. Les mélanger aux coûts de serving surévalue le COGS et pénalise la marge brute pour un travail qui n'a jamais touché un client. Les tags de vues de features existent précisément pour garder cette répartition honnête — utilisez-les.
Omettre la provision. La consommation se facture en arriéré, les journaux d'usage ont un ou deux jours de décalage, et la facture cloud arrive plus tard encore. Une clôture sans provision enregistre un mois partiel comme un mois complet, et les jours manquants refont surface en écart mystérieux le mois suivant. Provisionnez à partir du rythme de croisière, puis régularisez quand les documents arrivent.
Votre dernière étape utile ce mois-ci est modeste : ouvrez votre explorateur de coûts cloud, filtrez par les tags de vues de features, et confirmez que le chiffre que vous voyez est celui de vos livres. Si les deux ne se sont jamais rencontrés, vous venez de trouver l'écart que cet article avait pour but de combler.
