Le module XI (Coûts et AI FinOps) comptabilise les dépenses IA depuis le flux de coûts fournisseur et applique les budgets. Au plafond, un contrôle budgétaire refuse la dépense. C’est une application en direct, toujours câblée dans le binaire par défaut — pas une fonctionnalité à la demande que vous provisionnez plus tard. Si un budget est configuré, le contrôle est actif.
Contrôles budgétaires
Un contrôle budgétaire a deux modes d’application :
- Throttle — limite le débit de la dépense, dégradant gracieusement. L’agent est ralenti, pas arrêté net, jusqu’à ce que le budget récupère ou qu’un opérateur l’augmente.
- Block — refus dur au plafond. L’agent reçoit un signal clair que son budget est épuisé et qu’aucune dépense supplémentaire n’est autorisée.
Les deux modes sont fermés par défaut : si l’état du budget est illisible — erreur de store, ligne corrompue, enregistrement manquant — le contrôle refuse, ne permet jamais. Un état de budget inconnu est traité comme épuisé, pas comme illimité. C’est la même posture que le reste de la plateforme maintient pour les contrôles d’application (voir gouvernance).
Comptabilité des coûts
La dépense est dérivée du flux de coûts fournisseur et de la tarification de référence vérifiée par l’opérateur gérée par le module X (Gestion des modèles et fournisseurs). Les échantillons de coûts proviennent de la télémétrie observée — les tokens, le modèle, le fournisseur — pas de l’interception d’appels API. La plateforme ne se place pas dans le chemin d’inférence ; elle lit le signal de coût hors bande, de la même manière qu’elle lit toute autre observation.
La tarification de référence est vérifiée par l’opérateur, pas fabriquée. Le module X vous permet de déclarer le prix par token ou par requête pour chaque modèle et fournisseur, et l’application budgétaire utilise cette tarification comme base comptable. Si le prix déclaré diverge de ce que le fournisseur facture réellement, le contrôle budgétaire applique contre le prix déclaré — la plateforme ne peut pas connaître la facture du fournisseur tant que celui-ci ne la communique pas.
Configurer un budget
Les budgets se scopent sur trois niveaux :
- Par tenant — un plafond pour toutes les dépenses IA au sein d’un tenant.
- Par agent — un plafond pour la dépense d’un seul agent, au sein de son tenant.
- Par modèle — un plafond pour la dépense sur un modèle spécifique, au sein d’un tenant ou d’un agent.
L’application est immédiate. Une fois qu’un budget est configuré avec un plafond et un mode de contrôle (throttle ou block), le contrôle est actif. Il n’y a pas de préchauffage, pas de délai, pas de « l’application commencera après le prochain cycle de facturation ». Le contrôle vérifie la dépense accumulée par rapport au plafond à chaque événement de coût gouverné.
Les périmètres de budget se composent par intersection : un budget par agent et un budget par tenant s’appliquent tous les deux, et le premier plafond atteint déclenche son contrôle. Un budget par modèle au sein d’un agent est en outre restreint par tout budget par agent et par tenant au-dessus de lui.
Ce qui se passe au plafond
Quand la dépense accumulée atteint ou dépasse le plafond configuré :
- Le contrôle budgétaire refuse la dépense — throttle ou block, selon le mode.
- Le refus est enregistré comme une découverte dans la surface de découvertes de la plateforme, avec le périmètre du budget, le plafond, et la dépense accumulée au moment du refus.
- L’agent reçoit un signal clair que son budget est épuisé. La plateforme n’abandonne pas silencieusement la requête et ne retourne pas d’erreur ambiguë.
- Si des notifications sont configurées, le refus est routé via le module XV.
Un refus de dépense est un événement gouverné. Il est inscrit dans le registre d’audit dans la même transaction que le refus, il n’y a donc pas de fenêtre où un refus de budget serait non enregistré.
Notifications
Les alertes budgétaires s’intègrent avec le module XV (Intégrations de sortie et notifications). Quand un budget approche ou atteint son plafond, la découverte peut être routée vers toute destination configurée :
- Slack / Teams — notification dans un canal ou en message direct.
- PagerDuty / Opsgenie — escalade d’alerte.
- Webhook signé — pour les intégrations personnalisées.
- SIEM — ajouté au flux d’export d’audit.
Les destinations de notification sont provisionnées par l’opérateur. Un contrôle budgétaire applique indépendamment du fait qu’une destination de notification soit configurée — le contrôle est l’application, la notification est la couche de sensibilisation.
L’interaction avec le coupe-circuit
Le coupe-circuit est le contrôle de refus à l’échelle de l’environnement et il surpasse tout, y compris les contrôles budgétaires. Quand le coupe-circuit est engagé :
- Tout actionnement gouverné est refusé, y compris toute dépense que les contrôles budgétaires auraient autrement limitée ou autorisée.
- Le mode throttle/block d’un contrôle budgétaire est sans objet — l’environnement est arrêté.
- La réactivation de l’environnement nécessite l’approbation de double contrôle habituelle (deux humains distincts, pas de chemin break-glass pour la réactivation).
Le contrôle budgétaire et le coupe-circuit sont des contrôles indépendants. Ils se composent, ne se concurrencent pas : le coupe-circuit est un refus superset qui subsume tout autre contrôle.
Routage de modèle et budget
Le module X gère le routage de modèle avec une tarification de référence vérifiée par l’opérateur. L’application budgétaire consomme cette tarification — elle ne maintient pas sa propre table de prix et ne fabrique pas de données de coût. La dépendance est unidirectionnelle :
- Le module X déclare le catalogue de modèles et les prix de référence.
- Le module XI lit ces prix pour comptabiliser la dépense et appliquer les plafonds budgétaires.
Si le module X n’a pas de prix de référence pour un modèle, le module XI ne peut pas comptabiliser la dépense par rapport à un budget. La dépense non gouvernée (pas de prix, pas de budget) est remontée comme une découverte, pas silencieusement ignorée.
Limites honnêtes
L’application budgétaire est active et fermée par défaut pour les surfaces que la plateforme gouverne, mais elle a des limites que vous devez comprendre avant de vous y fier :
- La précision des coûts dépend du fournisseur. La plateforme comptabilise la dépense en utilisant la tarification de référence déclarée par l’opérateur et les comptages de tokens observés. Si la facturation réelle du fournisseur diffère du prix déclaré, le contrôle budgétaire applique contre le prix déclaré, pas la facture. La plateforme ne fabrique pas de données de coût et n’invente pas de benchmarks.
- La couverture est bornée par l’observation. L’application budgétaire s’applique aux dépenses qui passent par les canaux gouvernés — les sources que la plateforme observe. Un agent qui appelle un modèle par un chemin non gouverné (pas de source câblée, pas de télémétrie émise) est invisible pour le contrôle budgétaire. La plateforme remonte les chemins non gouvernés comme des découvertes quand elle peut les détecter, mais elle ne peut pas appliquer sur ce qu’elle ne peut pas voir.
- La plateforme est pré-1.0. L’application budgétaire est livrée et câblée aujourd’hui, mais considérez le détail comptable comme un travail en cours. Voir transparence et limites pour la posture complète.
Voir aussi
- Catalogue de modules — Module XI (Coûts et AI FinOps) et Module X (Gestion des modèles et fournisseurs).
- Gouvernance — le modèle d’application fermé par défaut que suivent les contrôles budgétaires.
- Visite FinOps — la page produit pour la gouvernance des coûts.
- Coupe-circuit — le contrôle de refus à l’échelle de l’environnement qui surpasse l’application budgétaire.
- Transparence et limites — ce qui est actif versus en conception.