Fiorino.AI

Une phrase pour présenter

Fiorino.AI est un ensemble d’outils open source de gestion des coûts et de la consommation pour les LLM, qui aide les équipes SaaS d’IA à enregistrer les tokens par utilisateur, modèle et dimension métier, à estimer les coûts, à définir des surcoûts et à fournir des données de base pour la facturation selon la consommation.

Présentation des outils

Fiorino.AI s’adresse aux équipes de développement qui souhaitent intégrer OpenAI, Anthropic ou d’autres services de grands modèles dans leurs produits. Il reçoit via une API REST des informations telles que les identifiants des utilisateurs externes, les tokens d’entrée/sortie, le fournisseur et le modèle, puis rassemble ces données dans un tableau de bord des coûts.

Le projet est maintenu par l’organisation GitHub du même nom. L’backend utilise Python, FastAPI, SQLAlchemy et PostgreSQL, tandis que l’frontend utilise React, TypeScript, Vite et Recharts. Les utilisateurs peuvent déployer l’backend via Docker ou construire eux-mêmes un frontend indépendant.

Les responsables officiels ont identifié les restrictions de quantité, la facturation via Stripe, les étiquettes commerciales et l’analyse des coûts liés à l’IA comme des orientations pour le produit, mais plusieurs éléments du plan restent encore en cours d’achèvement. Étant donné que la dernière mise à jour publique du stockage remonte à juillet 2025, il convient de se baser sur le code réel et les tests locaux avant une adoption officielle.

Fonction principale

Enregistrer la consommation des appels LLM

L’application peut recevoir, via une interface de suivi, un ID d’utilisateur externe anonyme, un token d’entrée, un token de sortie, ainsi que le nom du fournisseur et du modèle. L’équipe doit envoyer la consommation exacte à Fiorino.AI une fois l’appel au modèle effectué.

Analyser les coûts par utilisateur

Le système distingue les utilisateurs à l’aide d’IDs externes anonymes, ce qui permet de visualiser l’utilisation et les coûts liés aux LLM par chaque utilisateur. Les IDs anonymes réduisent les données d’identité directes, mais si le tableau de correspondance reste stocké dans le système métier, les données peuvent encore être rattachées à des personnes.

Modèles multiples et fournisseurs multiples

L’objectif du projet est d’unifier le suivi des différents services de grands modèles et des versions de modèles, afin d’éviter que chaque fournisseur ne procède à des statistiques séparées. Le tableau des prix doit être mis à jour en temps réel, sinon même un nombre correct de tokens peut entraîner des coûts erronés.

Tableau de bord des coûts

L’interface utilisateur offre des visualisations en temps réel des tendances de coûts, de la consommation de tokens et de la distribution des modèles. Le tableau de bord permet d’identifier les utilisateurs à fort coût et les fluctuations anormales, mais il ne correspond pas à la facture finale du fournisseur de services cloud.

Coût du modèle et surcoût

L’back-end peut gérer les coûts des modèles et définir des majorations personnalisées, afin d’estimer la marge brute du service ou de déterminer les prix pour les clients. Le calcul des prix doit distinguer les entrées, les sorties, le cache, le traitement par lots et autres éléments de facturation des fournisseurs.

Frontière multi-locataires de Realm

La documentation officielle organise les différentes applications ou locataires au sein de Realm et génère une clé API pour chaque intégration. Une implémentation multi-locataire doit vérifier l’isolation des requêtes, des clés et des données entre les Realm, et ne pas se fier uniquement à l’interface.

Gestion de la clé API

La section README frontale liste les outils de développement pour créer et gérer les clés API. En environnement de production, seule la clé complète doit être affichée, elle doit être stockée sous forme de hash et prendre en charge l’annulation, le renouvellement et des droits minimaux.

Limite d'utilisation et rappels

Le site officiel et le README principal listent la définition de quotas par utilisateur ou par niveau d’abonnement, ainsi que les avertissements en cas de approche du plafond, comme fonctionnalités. L’ancienne feuille de route continue de qualifier les quotas, les limitations de vitesse et les périodes de réinitialisation de projets prévus, il est donc nécessaire de vérifier chaque élément dans le code actuel.

Facturation par utilisation de Stripe

La promotion du projet peut être combinée avec Stripe pour un tarif par usage, mais l’ancienne feuille de route prévoit encore un paiement modulaire. On ne peut pas supposer, à partir du README seulement, que les processus complets de facturation, de remboursement, de fiscalité et de rapprochement sont déjà prêts pour la production.

Analyste de coûts d’IA et insights personnalisés

La description officielle comprend le coût des requêtes en langage naturel, la reconnaissance des modes d’utilisation et la proposition de recommandations d’optimisation ; elle prend également en charge l’étiquetage des dimensions métier par fonction ou action. La feuille de route indique toujours que ces capacités ne sont pas encore achevées, et les déploieurs doivent les considérer comme des expériences ou des capacités de planification à valider.

Capacités déjà vérifiées et capacités à vérifier

Principe de fonctionnement

1. L’équipe déploie le backend Fiorino.AI et PostgreSQL dans son propre infrastructure.
2. Créer un Realm et générer une clé API pour ce produit ou locataire.
3. Les applications d’IA appellent les services de modèles pour obtenir les tokens d’entrée et de sortie réels ainsi que les informations sur le modèle.
4. L’application envoie l’ID de l’utilisateur anonyme, le token, le fournisseur et le modèle à l’interface de suivi de la consommation.
5. Fiorino.AI calcule le coût d’utilisation en fonction du prix du modèle et d’un surcoût personnalisé.
6. Le tableau de bord résume les tendances par utilisateur, modèle, temps et autres dimensions.
7. L’équipe compare les registres internes avec les factures des fournisseurs et corrige les prix ou les omissions.
8. Lorsqu’un facturation client est nécessaire, la consommation vérifiée est transmise à un processus de facturation et de rapprochement indépendant.

Tutoriel de déploiement

Lancer le backend avec Docker

1. Préparer une base de données PostgreSQL indépendante et créer un compte d’application aux droits restreints.
2. Conservez en toute sécurité les informations de connexion à la base de données, sans soumettre les mots de passe au dépôt de code.
3. Tirer l’image officielle de conteneur et mapper le port de l’application au réseau contrôlé.
4. Se connecter à PostgreSQL via la variable d’environnement DATABASE_URL.
5. Après le démarrage, vérifiez la migration de la base de données, son état de santé et la documentation des interfaces.
6. Configurer un proxy inversé, le chiffrement des transferts, l’authentification et les journaux d’accès.
7. Créez un Realm de test et une clé API, en n’envoyant que des volumes simulés pour effectuer la vérification.

Construire l’interface utilisateur

1. Obtenez le code source officiel du front-end et installez un environnement Node.js conforme aux exigences du projet.
2. Installez les dépendances et configurez l’adresse de votre interface backend dans le fichier d’environnement.
3. Vérifier les pages de connexion, du tableau de bord, de Realm et de la clé API en mode développement.
4. Exécuter les vérifications statiques et les builds de production, gérer les alertes de sécurité liées aux dépendances.
5. Déployer les résultats de la construction sur un service statique et restreindre les canaux backend autorisés à y accéder.
6. Vérifier les pages de taille mobile, mode sombre, état d’erreur et manque de permissions.

Accès aux applications d’IA

1. Créer un Realm et une clé API indépendants pour chaque environnement et produit.
2. Lire sur le serveur la quantité réelle de tokens retournée par le fournisseur du modèle.
3. Utiliser un ID externe stable qui ne permet pas d’identifier directement l’utilisateur.
4. Appeler l’endpoint de suivi de la consommation et fournir le token d’entrée, le token de sortie, le fournisseur et le modèle.
5. Définir des tentatives de récupération sécurisées pour les délais dépassés et les échecs, afin d’éviter un comptage répété.
6. Échantillonnage périodique des journaux d’application de contrôle, Fiorino.AI et factures du fournisseur.
7. Annuler et renouveler immédiatement en cas de fuite de clé ou de changement de personnel.

À qui s’adresse-t-il

• Équipe de développement AI SaaS : visualisation des coûts et du bénéfice brut par utilisateur final.
• Entreprises privilégiant l’hébergement auto-géré : elles conservent les enregistrements des coûts dans leur propre base de données.
• Application multi-modèles : comparaison unifiée de la consommation de tokens entre différents fournisseurs et modèles.
• Produits à facturation au forfait : préparation d’enregistrements de consommation auditable pour le système de facturation ultérieur.
• Équipe d’ingénierie de plateforme : Création d’un centre de coûts unifié pour plusieurs fonctionnalités d’IA internes.
• Contributeur open source : améliorations du backend FastAPI, du frontend React et des documents de déploiement.

Scénarios d'utilisation typiques

• Déterminer si un petit nombre d’utilisateurs consomment la majeure partie du budget du modèle.
• Comparer le coût unitaire lors de l’utilisation de différents modèles pour la même fonction.
• Répartir les frais des LLM en fonction de la fonction du produit, de l’action ou du locataire.
• Estimer le coût moyen par utilisateur et la marge brute avant la conception du forfait.
• Fournir aux clients entreprises des détails d’utilisation et des rapports d’audit interne.
• Détecter des anomalies de token, des boucles d’erreur ou une augmentation soudaine de la longueur du prompt.
• Transférer la quantité du modèle validé au système de facturation existant pour le tarification.

Avantages du produit

• Le code source est publié tant pour le backend que pour le frontend, ce qui permet de vérifier l’implémentation et de le déployer soi-même.
• Les champs d’accès à la REST API sont simples, ce qui convient pour ajouter des enregistrements dans les applications IA existantes.
• Utiliser un ID externe anonyme pour réduire la nécessité de transmettre directement le nom et l’adresse e-mail.
• Prend en charge plusieurs fournisseurs et modèles, sans être lié à un service LLM en particulier.
• Le tableau de bord React offre une vue centralisée des tokens, des coûts et des tendances.
• La licence Apache 2.0 permet de modifier et de distribuer sous réserve du respect de ses conditions.
• Docker réduit les obstacles à la mise à l’essai et au déploiement locaux en arrière-plan.

Restrictions d'utilisation et risques

• L’échelle du projet est petite, et le dépôt officiel ne reçoit que peu d’attention et de signaux de contribution.
• Les dernières mises à jour publiques du backend et du frontend datent de juillet 2025, et l’activité de maintenance est limitée.
• Le entrepôt ne dispose pas de version officielle Release ; la mise à niveau et le rollback doivent être gérés manuellement.
• La feuille de route a été mise à jour pour la dernière fois en novembre 2024, et de nombreuses fonctionnalités promotionnelles indiquent encore qu’elles ne sont pas terminées.
• Les prix des modèles changent fréquemment, et une table des coûts obsolète peut entraîner des erreurs dans l’évaluation des profits et des quotas.
• Les tentatives de réessai, les délais d’attente ou un traitement concurrentiel inadéquat peuvent entraîner une duplication ou une omission des enregistrements de consommation.
• L’ID d’utilisateur anonyme n’assure pas une anonymisation automatique ; en combinant avec la mise en correspondance métier, il est encore possible d’identifier une personne.
• L’autogestion signifie que le déploiementur est responsable de la base de données, des sauvegardes, du suivi, des clés et des correctifs de sécurité.
• Les fonctionnalités de facturation Stripe, les quotas, Cost Analyst et les outils de conformité ne peuvent pas être considérés comme opérationnels simplement sur la base de documents.
• Le README de l’interface utilisateur indique à tort que la licence est GPL v3, alors que le fichier LICENSE réel est Apache 2.0.
• Il n’y a pas de niveaux de service de hébergement publics, de support entreprise, de politique de confidentialité ou de certifications de sécurité.
• Le projet ne remplace pas la facture du modèle cloud ; il convient de comparer régulièrement celle-ci avec la facture du fournisseur.

Prix et coûts d’utilisation

Au 22 août 2026, Fiorino.AI ne propose pas de forfaits d’hébergement commercial publics. Le code source peut être utilisé gratuitement sous la licence Apache 2.0, mais l’hébergement auto-géré entraîne néanmoins des coûts en matière d’infrastructure, de développement et de maintenance.

Un logiciel libre et open source ne signifie pas un service à coût nul. En environnement de production, il est également nécessaire d’évaluer les bases de données hautement disponibles, le stockage des journaux, la conservation des données, la mise à niveau des dépendances, le renouvellement des clés et l’implication du personnel technique.

API et intégration

L’infrastructure backend de Fiorino.AI offre une API REST et des documents d’interface interactive. Le processus d’intégration typique consiste à créer un Realm, à générer une clé API, puis à appeler l’endpoint de suivi de l’utilisation pour enregistrer l’ID de l’utilisateur externe, le token, le fournisseur et le modèle.

Logiciels libres et licences

Les fichiers LICENSE réels dans les dépôts backend et frontend sont tous soumis à la licence Apache License 2.0, qui autorise l’utilisation, la modification et la distribution sous réserve du respect de la licence, du maintien des mentions et de l’annotation des modifications. La licence ne confère pas de droits d’utilisation sur les marques commerciales, ni ne garantit la qualité du logiciel.

La section README en tête du projet indique GPL v3, mais le fichier LICENSE du dépôt ainsi que l’identification des licences sur GitHub montrent Apache 2.0. En raison de cette contradiction dans la documentation du projet, il convient de demander aux mainteneurs des éclaircissements avant toute redistribution officielle ou intégration commerciale, en se basant sur les résultats de l’examen juridique.

Confidentialité et sécurité

Fiorino.AI met l’accent sur l’utilisation d’identifiants d’utilisateurs anonymes et du self-hosting, mais cela ne remplit pas automatiquement les exigences des réglementations sur la vie privée. Le déploiteur contrôle la base de données, les journaux, les interfaces et les sauvegardes, et assume ainsi la majeure partie des responsabilités en matière de protection des données.

• Ne mettez pas les noms, adresses e-mail, texte original des instructions ou informations confidentielles de l’entreprise directement dans external_id.
• Déterminer clairement si l’interface de suivi doit recevoir le contenu du message, afin de minimiser au maximum les données transmises uniquement en cas de besoin.
• La base de données utilise des comptes indépendants, des permissions minimales, le chiffrement des transferts et le chiffrement statique.
• La clé API n’est stockée que du côté serveur ou dans un système de gestion des clés, et son renouvellement ainsi que son révocation sont enregistrés.
• Restreindre l’accès public aux documents d’interface, à l’interface d’administration et à la base de données.
• Définir des politiques de durée de conservation, de suppression, d’exportation et d’isolation des locataires pour les enregistrements de consommation.
• L’examen dépend des versions, des alertes de sécurité et des canaux d’images de conteneurs.
• Mettre en place des processus d’identité, de rapprochement, de correction d’erreurs et d’audit avant d’utiliser les factures clients.

Informations de base

Indice de recommandation

Note de recommandation : 3,8 / 5. Fiorino.AI offre une base claire pour le suivi des coûts open source, avec des champs API simples, et Docker ainsi que PostgreSQL facilitent également aux équipes de développement la validation dans leur propre environnement.

Les principaux défauts sont un signal de maintenance du projet faible, l’absence d’une version officielle, des disparités entre la feuille de route et les promesses fonctionnelles, ainsi que des contradictions dans les documents de licence frontale. Il convient mieux aux équipes d’ingénierie disposées à lire du code et à améliorer les capacités de production, et n’est pas adapté en tant que service prêt à l’emploi ne nécessitant aucune maintenance.

Questions fréquentes

À quoi sert Fiorino.AI ?

Il enregistre la consommation de tokens pour chaque utilisateur anonyme et chaque modèle dans les applications d’IA, calcule les coûts et effectue des analyses via un tableau de bord. L’équipe peut également utiliser ces données vérifiées pour définir des quotas ou facturer les clients.

Fiorino.AI est-il gratuit ?

Le code source est libre et open source, sans prix de abonnement de hébergement public. Les coûts de serveur, de PostgreSQL, d’appel des modèles, ainsi que ceux de surveillance et de maintenance doivent être pris en charge par l’utilisateur lui-même.

Quels modèles sont pris en charge ?

Les interfaces sont enregistrées selon le fournisseur et le nom du modèle, sans être liées à une plateforme spécifique. Le calcul des coûts réels dépend de la complétude et de la mise à jour régulière du tableau des prix des modèles utilisés dans le déploiement.

Est-il possible de suivre les coûts par utilisateur ?

Oui, il est possible de enregistrer les utilisateurs anonymes via external_id. Ne utilisez pas le nom ou l’adresse e-mail directement comme identifiant, et protégez soigneusement les relations de mappage dans le système d’entreprise.

Peut-on se connecter directement à Stripe pour les paiements ?

La promotion du projet et le README mentionnent la facturation basée sur l’utilisation Stripe, mais l’ancienne feuille de route classe toujours ce module comme inachevé. Avant son déploiement en production, il est nécessaire d’examiner le code actuel et de finaliser les tests de facturation réelle, de remboursement et de rapprochement.

L’analyste de coûts IA est-il déjà disponible ?

La présentation officielle le classe comme une capacité, mais la feuille de route indique encore qu’il n’est pas achevé. Il convient de se baser sur l’interface et les interfaces réelles après déploiement, sans s’y fier à l’avance.

Comment déployer ?

L’backend peut fonctionner avec PostgreSQL via Docker, tandis que l’frontend doit être développé lui-même après avoir configuré l’adresse de l’backend. En environnement de production, il est également nécessaire d’ajouter le chiffrement des transferts, un contrôle d’accès, ainsi que des sauvegardes et une surveillance.

Y a-t-il une API ?

Une API REST est disponible, permettant d’enregistrer les tokens, les fournisseurs, les modèles et les utilisateurs anonymes à l’aide d’une clé API. Le SDK du client officiel reste encore en phase de planification.

Fiorino.AI est-il open source ?

Oui, le code source est public tant pour le backend que pour le frontend. Les fichiers LICENSE des deux dépôts sont tous deux sous licence Apache 2.0.

Pourquoi la licence doit-elle être confirmée à nouveau ?

La page README en ligne indique par erreur GPL v3, tandis que le fichier LICENSE réel indique Apache 2.0. L’essai interne a peu d’impact, mais une clarification doit être obtenue avant toute redistribution et intégration commerciale.

Le projet est-il encore en maintenance ?

Les dernières mises à jour publiques pour le backend et le frontend remontent à juillet 2025, et il n’y a pas eu de version officielle Release. Il est possible de l’essayer, mais on ne doit pas supposer qu’il y ait une maintenance continue ou un support entreprise.

Peut-il remplacer la facture du fournisseur de modèles ?

Il ne peut pas être entièrement substitué. Il s’agit d’une fonction de gestion des volumes internes et des coûts, qui doit être vérifiée régulièrement avec les factures réelles du fournisseur du modèle.

Résumé

Fiorino.AI convient aux équipes de produits AI qui souhaitent maîtriser les coûts liés aux LLM pour les utilisateurs finaux, tout en conservant la capacité d’hébergement propre et de revue du code source. Il offre des interfaces backend, un stockage PostgreSQL et une interface frontend visuelle, pouvant servir de point de départ pour la gouvernance des coûts.

Avant une adoption officielle, il est nécessaire de vérifier les fonctionnalités du plan d’action, les licences, la sécurité des clés, le comptage des doublons et la mise à jour du tableau des prix. Il est plus prudent de le considérer comme une base open source extensible, plutôt que comme un produit fini déjà doté de capacités complètes en matière de facturation d’entreprise et de conformité.