Votre équipe ML vient de passer cinq mois-ingénieurs à déployer un feature store open source. Votre contrôleur de gestion regarde le journal de paie et pose une question que personne dans l'équipe n'attendait : ces 180 000 $ de temps d'ingénierie représentent-ils une charge qui frappe ce trimestre, ou un actif qui figure au bilan ? La réponse déplace votre burn multiple, le calcul de votre runway et — si vous levez des fonds — l'histoire que racontent vos états financiers. Et elle change complètement selon que vous avez construit sur Feast ou acheté Tecton.
Un feature store est la couche d'infrastructure qui gère, stocke et sert les features de machine learning, à la fois pour l'entraînement et pour l'inférence en temps réel. Son rôle central est de prévenir le décalage entraînement-service (training-serving skew) : garantir que le modèle voit en production exactement les mêmes features que celles sur lesquelles il a été entraîné. L'architecture comporte cinq composants — un store hors ligne pour les données d'entraînement, un store en ligne pour le service à faible latence, des pipelines de features qui calculent les valeurs, un registre central de features et des API de service. Quand les équipes choisissent entre Feast et Tecton, elles choisissent entre deux modèles de possession très différents, et chaque modèle produit un traitement comptable très différent.
Feast vs. Tecton : l'arbitrage construire vs acheter
Feast est le principal feature store open source : gratuit à utiliser, auto-hébergé et flexible. Vous exploitez vous-même le store en ligne (généralement Redis ou DynamoDB), le store hors ligne (S3, BigQuery ou Snowflake), et vous assumez chaque mise à niveau, chaque astreinte d'incident et chaque décision de mise à l'échelle. Tecton est l'alternative commerciale entièrement managée, construite par des membres de l'équipe à l'origine de la plateforme Michelangelo d'Uber. Elle gère le service en ligne et hors ligne, le calcul de features en streaming et la surveillance intégrée des features, dans le cadre d'un contrat SaaS d'entreprise.
La comparaison standard ressemble à ceci :
| Facteur | Feast | Tecton |
|---|---|---|
| Coût de licence | Gratuit (coûts d'infrastructure uniquement) | Tarification SaaS d'entreprise |
| Service en ligne | Redis, DynamoDB — vous l'exploitez | Entièrement managé |
| Store hors ligne | Parquet, BigQuery, Snowflake — vous le câblez | Managé |
| Features en streaming | Basé sur push, vous construisez les pipelines | Calcul temps réel natif |
| Surveillance des features | Outillage externe que vous assemblez | Intégrée |
| Charge opérationnelle | Élevée — votre équipe gère tout | Faible — SLA du fournisseur |
La version comptable de ce tableau comporte une ligne supplémentaire : où l'argent apparaît. Avec Tecton, la quasi-totalité du coût arrive sous forme de facture fournisseur — une charge d'abonnement. Avec Feast, la ligne de licence est nulle et le coût réel se cache dans la masse salariale d'ingénierie : les semaines que vos ingénieurs data passent à déployer le registre, écrire les pipelines de features, régler le store en ligne et construire la surveillance que Feast ne fournit pas. L'infrastructure open source « à coût de licence nul » nécessite tout de même une ligne de compte de résultat pour les heures d'ingénierie, et cette ligne est précisément ce que régit l'ASC 350-40.
La question comptable : ce que dit réellement l'ASC 350-40
Selon les US GAAP, les coûts des logiciels à usage interne relèvent de l'ASC 350-40, qui classe chaque dollar d'un projet logiciel dans l'une de trois phases (voir notre guide pratique de la décision capitaliser vs passer en charge pour le cadre général) :
- Phase préliminaire du projet — passée en charge au fur et à mesure. Évaluation des fournisseurs, prototypes exploratoires, comparaison de Feast et Tecton, études de faisabilité et l'analyse construire-vs-acheter elle-même. Tout cela frappe immédiatement le compte de résultat.
- Phase de développement de l'application — capitaliser les coûts éligibles. Une fois que la direction a autorisé et engagé le projet, les coûts de conception, de codage, de configuration, de test et d'intégration du logiciel sont capitalisés en tant qu'actif et amortis sur sa durée d'utilité. C'est la seule phase qui construit un actif.
- Phase post-implémentation et d'exploitation — passée en charge au fur et à mesure. Formation, maintenance, corrections de bugs et exploitation continue après la mise en production. De nouvelles fonctionnalités ajoutées ultérieurement peuvent rouvrir une fenêtre de capitalisation, mais maintenir le système en fonctionnement ne le fait jamais.
Pour entrer dans la phase de développement de l'application, deux conditions doivent être réunies : la direction disposant de l'autorité compétente a autorisé le projet (implicitement ou explicitement), et il est probable que le projet sera mené à bien et que le logiciel sera utilisé pour sa fonction prévue. Tant que ces deux conditions ne sont pas réunies, chaque dollar reste une charge de phase préliminaire — y compris un « prototype » qui deviendra plus tard la version de production.
La capitalisation repose également sur une définition étroite des coûts éligibles. La masse salariale directe des développeurs travaillant sur la construction, les charges liées à la paie comme les avantages sociaux, et les honoraires de tiers versés à des développeurs externes travaillant sur le projet sont généralement éligibles. La conversion des données depuis un ancien système, la formation, la maintenance, les frais généraux et les coûts administratifs ne le sont pas — même lorsqu'ils sont engagés pendant la fenêtre de développement de l'application.
Faire correspondre le travail sur le feature store aux trois phases
Voici comment une construction typique sur Feast se mappe sur l'ASC 350-40 :
Charge : l'évaluation. Votre équipe passe trois semaines à comparer Feast et Tecton, prototype un pipeline d'exemple et lit la documentation des fournisseurs. Phase préliminaire — charge. Cela vaut même si le code du prototype est ensuite réutilisé en production ; la phase est jugée selon l'objectif de l'activité au moment des faits, et non selon ce que le code devient.
Capitaliser : la construction. La direction approuve le choix de Feast et finance le projet. Les ingénieurs déploient alors le registre, écrivent les définitions de features de production, construisent les pipelines batch et streaming, intègrent le store en ligne à votre service d'inférence, et exécutent les tests d'intégration et de charge. La masse salariale directe d'ingénierie durant cette fenêtre, plus les honoraires de prestataires pour l'implémentation, est capitalisée — à condition de pouvoir documenter qui a travaillé sur quoi et quand.
Charge : tout ce qui suit la mise en production. Votre rotation d'astreinte règle la latence de Redis, réalimente une feature après un bug de pipeline, intègre de nouveaux modèles aux pipelines existants, met à niveau les versions de Feast et maintient les tableaux de bord de surveillance. Post-implémentation — charge. Si six mois plus tard vous ajoutez une capacité véritablement nouvelle, comme un pipeline streaming pour une nouvelle gamme de produits, cette amélioration distincte peut ouvrir sa propre fenêtre de capitalisation.
Le mode de défaillance le plus courant est la piste documentaire manquante. Une capitalisation sans suivi du temps contemporain par phase de projet résiste rarement à un audit. Si le temps de vos ingénieurs n'est pas suivi entre la construction du feature store et le travail courant, votre auditeur passera tout en charge — ce qui est peut-être la bonne réponse de toute façon, mais cela doit être une décision, pas un défaut par défaut.
Ce qui change lorsqu'on achète Tecton à la place
Acheter un feature store managé renverse le tableau comptable. Tecton est un contrat de service, pas un logiciel que vous possédez, donc les frais d'abonnement sont des charges d'exploitation comptabilisées sur la durée du contrat — simple, prévisible et à l'épreuve de l'audit.
La partie subtile est l'implémentation. Configurer une plateforme SaaS pour votre usage — intégrer Tecton à votre entrepôt de données, câbler les API de service dans l'inférence, migrer les définitions de features — suit la même logique de l'ASC 350-40 en vertu des règles sur l'informatique en nuage : les coûts d'implémentation de la phase de développement de l'application peuvent être éligibles à la capitalisation même si le logiciel sous-jacent est hébergé par le fournisseur. En pratique, les implémentations de Tecton sont assez courtes pour que beaucoup de petites entreprises les passent en charge au nom du seuil de signification. Mais si votre intégration atteint six chiffres de temps d'ingénierie, la même analyse par phases s'applique, et la même exigence documentaire tient.
Il y a ici une note stratégique pour les fondateurs en levée de fonds. Capitaliser une construction sur Feast améliore l'EBITDA de la période courante et l'image de la marge brute, au prix d'une charge d'amortissement croissante et d'un actif que l'équipe de diligence d'un acquéreur scrutera. Passer en charge un abonnement Tecton maintient le compte de résultat honnête sur le burn en rythme de croisière, mais alourdit l'apparence des chiffres de cette année. Aucun traitement n'est « meilleur » — mais les investisseurs demanderont lequel vous avez choisi et pourquoi ; choisissez donc délibérément et documentez le raisonnement.
ASU 2025-06 : le modèle par phases disparaît
Le cadre à trois phases remonte à 1998, quand les logiciels étaient construits en phases séquentielles en cascade aux frontières nettes. Il s'applique mal à un travail agile et itératif sur un feature store — quel sprint est « préliminaire » quand chaque sprint livre en production ? Le FASB en est convenu. En septembre 2025, il a publié l'ASU 2025-06, qui élimine les règles fondées sur les phases et les remplace par un cadre fondé sur des principes, centré sur la question de savoir s'il subsiste une incertitude de développement significative.
Selon le nouveau modèle, la capitalisation commence lorsque la direction a autorisé le projet, que l'achèvement et l'usage prévu sont probables, et que le concept a dépassé une incertitude significative quant aux exigences de performance, à l'approche de développement ou à la faisabilité. Il est applicable aux exercices ouverts après le 15 décembre 2027, avec adoption anticipée permise. Pour une construction de feature store qui démarre aujourd'hui, le conseil pratique reste inchangé : obtenez la note d'autorisation, suivez le temps consacré à la construction et séparez l'évaluation de la réalisation. Ces habitudes satisfont aussi bien les anciennes phases que les nouveaux principes.
Un guide pratique pour votre construction de feature store
Que vous choisissiez Feast, Tecton ou une troisième option, cinq pratiques maintiennent la comptabilité propre :
Obtenez l'autorisation par écrit avant le début de la construction. Un courriel du CTO approuvant la construction sur Feast, le budget et l'usage de production prévu satisfait le seuil d'autorisation. Datez-le. Les auditeurs demandent ce document en premier.
Suivez le temps d'ingénierie par phase dès le premier jour. Les prototypes d'évaluation dans un compartiment, le travail de construction de production dans un autre, la maintenance post-lancement dans un troisième. Le suivi du temps par étiquettes ou l'étiquetage des sprints fonctionnent tous deux ; reconstituer la répartition de mémoire six mois plus tard, non.
Ne capitalisez que les coûts directs. La masse salariale et les avantages des développeurs pour les heures consacrées à la construction, plus les factures de prestataires liées à l'implémentation. Excluez la formation, la migration des données depuis les pipelines existants, les répartitions de frais généraux et la facture d'infrastructure cloud pour faire tourner le store en ligne — l'hébergement est un coût d'exploitation du système fini, pas un coût pour le construire.
Choisissez une durée d'amortissement que vous pouvez défendre. Les logiciels à usage interne sont généralement amortis linéairement sur trois à cinq ans. Un feature store construit sur de l'open source à évolution rapide, où une version majeure de Feast pourrait forcer une reconstruction, plaide pour le bas de la fourchette. Documentez le raisonnement dans la note de capitalisation.
Testez la dépréciation lorsque les faits changent. Si vous abandonnez la construction sur Feast à mi-parcours et signez avec Tecton, l'actif capitalisé est déprécié — passez-le en perte de valeur. Il en va de même si un pivot tue la gamme de produits que servait le feature store. Un logiciel capitalisé qui n'a plus d'usage n'est pas un actif.
Erreurs courantes qui entraînent des ajustements d'audit
Les erreurs que les auditeurs trouvent dans la capitalisation d'infrastructure sont d'une constance déprimante. Capitaliser la phase d'évaluation — la comparaison de fournisseurs, la preuve de concept, le prototype — est la plus fréquente ; le travail de phase préliminaire n'est jamais capitalisable, quelle que soit son utilité démontrée par la suite. Capitaliser la maintenance déguisée en développement arrive en deuxième position : régler la latence de service et réalimenter des features relève de l'exploitation, pas de la construction. En troisième lieu, la note manquante : un solde capitalisé sans document d'autorisation, sans analyse par phases et sans justification d'amortissement est passé en charge sur des principes généraux. En quatrième lieu, l'amortissement sur des durées fantaisistes — dix ans pour une infrastructure collée à un projet open source qui livre des changements majeurs chaque année. Et en cinquième lieu, l'oubli pur et simple de la facture cloud : les équipes qui capitalisent soigneusement la masse salariale tout en ignorant un rythme annuel de dépenses DynamoDB-et-calcul à six chiffres faussent la comparaison construire-vs-acheter qui justifiait le projet au départ.
Suivez la construction comme l'actif qu'elle peut devenir
La décision Feast-vs-Tecton est généralement présentée comme une fierté d'ingénieur contre la commodité d'un fournisseur. Reformulez-la comme une question financière et l'arbitrage s'affûte : Feast convertit une rémunération en numéraire en actif capitalisable avec une traîne d'amortissement, tandis que Tecton convertit la même capacité en charge d'exploitation nette avec une date de renouvellement. Votre modèle de runway, votre marge brute et votre récit de diligence changent tous avec ce choix — c'est précisément pourquoi la comptabilité mérite une place à la revue d'architecture, et non une note de bas de page après coup.
Cela commence par une discipline comptable ordinaire : temps étiqueté par projet, autorisation datée, factures de prestataires liées à la construction et note de capitalisation que votre auditeur peut suivre. Si vos coûts de feature store vivent actuellement comme une masse salariale d'ingénierie indifférenciée dans un seul compte du grand livre, vous avez déjà perdu l'option de capitaliser — les enregistrements ne peuvent pas être reconstitués après coup.
Simplifiez votre gestion financière
À mesure que vous faites évoluer votre infrastructure ML, tenir des enregistrements financiers clairs pour les décisions construire-vs-acheter, les logiciels capitalisés et les échéanciers d'amortissement est essentiel. Beancount.io propose une comptabilité en texte brut qui vous offre une transparence et un contrôle complets sur vos données financières — sans boîtes noires, sans verrouillage fournisseur. Commencez gratuitement et découvrez pourquoi les développeurs et les professionnels de la finance passent à la comptabilité en texte brut.
