Comment l’usage est compté

Chaque requête d’IA que Tale émet pour ton organisation est enregistrée une fois, imputée à une personne et mesurée par rapport aux règles de budget qui s’appliquent à cette personne. Cette page explique qui est cette personne pour chaque type de travail, quelles limites le travail consomme et où tu le retrouves dans l’analyse de l’usage. Les membres voient leur propre part sous Paramètres > Utilisation.

Ce qui compte comme usage

Tale enregistre une requête chaque fois qu’un modèle ou un service mesuré tourne pour ton organisation : une réponse de chat, y compris une réponse régénérée ou modifiée et les deux côtés d’une comparaison de modèles ; le court appel de modèle qui donne son titre à un nouveau chat ; une réécriture avec Améliorer avec l'IA dans la boîte de réception ; l’appel de modèle d’une étape llm d’automatisation ; un tour d’un agent géré qui travaille sur une tâche ou dans une automatisation ; une image que crée un tel agent ; une sortie vocale ; la transcription d’un enregistrement téléversé ou d’une dictée ; les embeddings qui indexent les connaissances et ceux que demande chaque recherche de connaissances ; et un appel aux endpoints de modèles avec une clé API. Chaque enregistrement porte les tokens ou unités consommés — pour une transcription, les minutes d’audio — et le coût estimé d’après le tarif public du fournisseur à ce moment-là ; pour un appel aux endpoints de modèles, c’est le coût mesuré par la passerelle de modèles.

Tale compte aussi chaque appel qu’il fait par un connector — les outils de recherche et web de l’assistant, l’étape de connector d’un agent ou d’une automatisation, un e-mail envoyé depuis la boîte de réception — comme un appel de connector, sans coût. Un appel de connector n’est jamais une requête : les limites de requêtes ne comptent que les requêtes de modèle.

À qui une requête est imputée

La règle est la même partout : une requête compte pour la personne qui a demandé le travail. La porte par laquelle elle est arrivée, l’application, l’API REST, le point d’accès MCP ou les endpoints de modèles, n’y change rien.

Une nouvelle tentative d’une exécution d’agent poursuit l’exécution lancée par son initiateur ; son usage reste donc imputé à cette personne et à la clé API avec laquelle l’exécution a été lancée. Quand un commentaire qui mentionne un agent au travail relance son tour, le reste de ce tour est imputé à l’auteur du commentaire, et à la clé API avec laquelle il a été écrit. Quand une intégration agit avec une clé API pour un autre membre, l’exécution compte pour ce membre, et la limite de la clé la compte aussi.

Le travail dans un projet compte aussi pour ce projet, quelle que soit la personne qui l’a demandé : les chats du projet, avec leurs titres, les réponses lues à voix haute, les enregistrements qui y sont transcrits et les appels d’outils et recherches de l’assistant ; les fichiers indexés pour lui ; les exécutions de ses agents et les étapes d’agent et llm des automatisations qui y tournent, avec les images qu’elles créent ; et les appels faits avec les propres clés API du projet. Une exécution qui ne nomme aucun projet, d’une automatisation installée dans plusieurs projets, compte pour chacun d’eux ; une automatisation installée dans aucun projet ne compte que pour l’organisation.

Les tours de chat, les tentatives vocales et les appels de modèles d’automatisation conservent les projets enregistrés lors de leur admission. Déplacer le chat ou modifier les installations d’une automatisation dans des projets pendant son exécution ne déplace ni sa réservation ni son usage comptabilisé ensuite. Une tentative admise sans projet reste hors des budgets de projet.

Une clé API qu’un admin a créée pour un membre compte pour ce membre, comme sa propre clé. Une clé qui appartient à une équipe, à un projet ou à l’organisation (Clés API) n’est pas une personne : ce qu’elle demande compte pour la clé elle-même. L’analyse de l’usage la présente sur sa propre ligne sous Utilisation par utilisateur, sous le nom de la clé avec son équipe, son projet ou l’organisation en dessous, et ne la compte jamais comme utilisateur actif. La clé d’une équipe compte aussi dans l’usage de son équipe.

Quelles limites s’appliquent

• Les limites personnelles, d’équipe et de rôle s’appliquent à la personne à qui une requête est imputée. Une exécution lancée par une planification, un webhook ou un événement n’a pas de telle personne et n’est mesurée par rapport à aucune d’elles. La clé propre d’une équipe, d’un projet ou de l’organisation non plus, sauf que la clé d’une équipe est tenue par la limite de son équipe.
• Les limites de l’organisation s’appliquent à toute requête, y compris aux exécutions lancées par un déclencheur.
• Les limites de clé API s’appliquent aux requêtes authentifiées par cette clé : les messages de chat qu’elle a envoyés, ses appels aux endpoints de modèles et les exécutions qu’elle a lancées.
• Les limites de projet s’appliquent au travail dans ce projet, quelle que soit la personne qui l’a demandé, y compris aux exécutions lancées par un déclencheur.

Quand une limite est atteinte, Tale refuse la requête suivante avant de l’exécuter et nomme la limite. Un tour d’agent géré est refusé à son démarrage ; un tour déjà en cours conserve l’enveloppe qui lui a été accordée. Un tour servi par un abonnement de fournisseur que l’organisation paie en dehors de Tale ne coûte rien par appel : il compte pour une requête, avec les tokens que son agent indique. Une limite de requêtes ou de tokens le refuse donc à son démarrage, une limite de coût non. Une image que l’agent demande pendant son tour est vérifiée à part, avant l’appel au modèle d’images : si une limite est atteinte, Tale refuse l’image et le tour continue. L’image puise aussi dans l’enveloppe du tour qui l’a demandée. L’étape llm d’une automatisation est vérifiée avant chaque appel de modèle : si une limite refuse l’appel, l’étape échoue avec budget_exceeded et son erreur nomme la limite ; l’exécution échoue avec elle, sauf si le onError de l’étape vaut continue. L’étape réserve l’entrée estimée et la sortie autorisée au tarif du catalogue, ainsi qu’une requête, jusqu’à la comptabilisation. Les appels simultanés tiennent donc compte de leurs réservations respectives. Si le résultat du fournisseur reste inconnu, Tale comptabilise une seule fois l’estimation enregistrée au lieu de la libérer silencieusement ; une nouvelle tentative passe par une nouvelle admission. Le titre d’un chat, une réécriture avec Améliorer avec l'IA et une transcription sont vérifiés de la même façon avant que Tale appelle le modèle, par rapport à une estimation du coût le plus élevé que l’appel peut atteindre — pour une réponse écrite, le prompt et la plus longue réponse que l’appel permet ; pour une transcription, la durée de l’enregistrement sans ses longs silences, au prix par minute du modèle — et réservent ce montant pendant l’appel. Un titre refusé n’est pas une erreur : le chat est alors nommé d’après son premier message, sans appel de modèle. Un modèle de transcription dont le catalogue ne connaît pas le prix par minute — facturé aux tokens, ou servi par un endpoint qui ne publie aucun prix — ne compte que pour les limites de requêtes, sans coût. Une transcription refusée affiche Limite d'utilisation atteinte ; choisis Réessayer dès que la limite le permet. Une dictée refusée indique que la limite est atteinte, et un lien vidéo est refusé avant son téléchargement. Chaque requête d’embedding est vérifiée de la même façon. Une recherche de connaissances refusée par une limite le dit et ne répond jamais « rien trouvé » ; l’indexation attend en revanche : un document affiche En attente d'une limite d'utilisation, un site garde ses pages sans recherche par le sens, et tous deux reprennent d’eux-mêmes dans l’heure qui suit la réinitialisation ou le relèvement de la limite. Une réponse de chat réserve aussi chaque tour supplémentaire de son utilisation d’outils, dès que ce tour commence. Comment les règles se combinent traite le cas où plusieurs règles visent la même personne.

La sortie vocale réserve son coût estimé et une requête tant que la tentative est en cours. Une tentative déjà réservée qui échoue ou dont le résultat reste inconnu est comptabilisée une seule fois selon cette estimation, y compris si l’échec précède l’appel au fournisseur. Cette comptabilisation prudente ne confirme pas une facturation. Une nouvelle tentative tient compte de l’estimation précédente lors de la vérification du budget restant.

Trois situations à connaître

Un collègue mentionne ton agent dans un commentaire ou dans la description d’une tâche. Publier le commentaire ou enregistrer la description lance une exécution, et celle-ci compte pour le collègue qui en est l’auteur, pas pour toi en tant que créateur de l’agent.

Une automatisation planifiée dépense chaque nuit. Ses exécutions apparaissent sur la ligne Automatisations (déclencheurs). Elles n’augmentent jamais l’usage personnel de quelqu’un ni le nombre d’utilisateurs actifs, et seules les limites de l’organisation peuvent les arrêter, ou celles d’un projet quand l’automatisation y tourne. Définis une limite de coût ou de requêtes pour l’organisation ou le projet si tu as besoin d’un plafond pour elles.

Une intégration utilise une clé API au nom d’un membre. Les limites personnelles et d’équipe du membre voient l’exécution, et la limite de la clé aussi. Deux plafonds s’appliquent, et le plus strict refuse en premier.

Ce que voient les membres

Paramètres > Utilisation liste chaque limite qui s’applique au membre connecté avec son utilisation actuelle : les chats envoyés, les sorties vocales demandées, les appels aux endpoints de modèles et les exécutions d’agents et d’automatisations lancées, quelle que soit la façon de les lancer. Les limites partagées d’équipe et d’organisation y figurent aussi, parce qu’elles peuvent être atteintes avant une limite personnelle. La limite d’un projet n’y figure pas : un bandeau dans les chats du projet la signale dès que son seuil est dépassé, et une requête qu’elle refuse la nomme.