FinOps de l'IA générative sur Azure : comprendre, mesurer et tenir les coûts en tokens

1. Pourquoi l'IA générative casse le FinOps classique

Le FinOps cloud s'est construit sur des ressources : une machine virtuelle qui tourne, un disque alloué, un cluster dimensionné. On les voit dans le portail, on les tague, on les éteint. L'IA générative facture autre chose : des tokens, c'est-à-dire des fragments de texte entrés et sortis d'un modèle, à un prix par million qui dépend du modèle, du type de déploiement, du sens (entrée ou sortie) et, de plus en plus, de l'usage du cache. Une ressource Azure OpenAI à zéro appel coûte zéro ; la même ressource peut coûter dix mille euros le mois suivant sans qu'aucune alerte de ressource ne se déclenche.

Trois propriétés rendent le sujet piégeux. Le coût est piloté par le comportement, pas par l'infrastructure : un prompt système de 3 000 tokens répété à chaque message coûte plus que l'équipe qui l'a écrit ne l'imagine. Il est asymétrique : un token de sortie coûte souvent quatre fois un token d'entrée, et les modèles de raisonnement produisent des tokens « invisibles » facturés. Et il est partagé : sans passerelle, toutes les équipes tirent sur le même quota et la même facture, et personne n'est responsable.

Règle n° 1 : on ne gouverne pas ce qu'on ne mesure pas par équipe. Avant tout levier d'optimisation, mettez en place la mesure des tokens par équipe et par application. Tout le reste en découle.

2. Le modèle de coût : ce qui est facturé, et par qui

Sur Microsoft Foundry (qui porte Azure OpenAI et les autres modèles vendus par Azure), la facture se décompose en cinq postes. Les tarifs exacts changent souvent ; retenez la structure plutôt que les chiffres.

Le type de déploiement est la décision tarifaire structurante. Standard (paiement à l'usage) existe en trois périmètres — global, zone de données (Europe ou États-Unis) et régional — avec des prix et des quotas croissants à mesure que le périmètre se resserre ; Batch traite des lots asynchrones sous 24 heures pour environ la moitié du prix du standard global ; Provisionné réserve une capacité en PTU à un coût horaire, que l'on réduit par une réservation mensuelle ou annuelle. Le même modèle peut donc coûter du simple au triple selon la manière dont il est déployé.

3. Mesurer : des tokens par équipe, indépendamment du code

La mesure fiable ne vient pas des applications — chaque équipe compterait à sa façon, ou pas du tout — mais de la passerelle par laquelle tous les appels passent. Azure API Management, en passerelle IA devant Foundry, fournit cette comptabilité.

1. Un produit API Management par équipe et un abonnement par application. Ce découpage devient la clé d'imputation : il n'a rien à voir avec la sécurité (l'authentification est le jeton Entra), il sert au comptage.
2. La politique llm-emit-token-metric envoie à Application Insights les tokens d'entrée, de sortie, totaux et en cache de chaque appel, avec des dimensions libres : équipe, application, modèle, type de déploiement, utilisateur. C'est la source de vérité du showback.
3. Côté Azure Cost Management, taguez les ressources Foundry, API Management, Redis et AI Search avec la même clé « équipe » quand elles sont dédiées ; pour les ressources partagées, répartissez au prorata des tokens mesurés par la passerelle.
4. Construisez un tableau de bord qui croise les deux : tokens par équipe (passerelle) et euros par équipe (facture, après répartition). L'écart entre les deux révèle les coûts fixes (PTU sous-utilisées, Redis, observabilité) à discuter séparément.

<!-- Mesure des tokens par équipe (produit) et par application (abonnement) -->
<llm-emit-token-metric namespace="finops-ia">
  <dimension name="Equipe"       value="@(context.Product.Name)" />
  <dimension name="Application"  value="@(context.Subscription.Name)" />
  <dimension name="Modele"       value="@(context.Request.MatchedParameters["deployment-id"])" />
  <dimension name="Deploiement"  value="@(context.Request.Headers.GetValueOrDefault("x-deployment-type","standard"))" />
</llm-emit-token-metric>

Pour les agents, ajoutez la trace OpenTelemetry : les conventions sémantiques GenAI (gen_ai.usage.input_tokens, gen_ai.usage.output_tokens, gen_ai.request.model) permettent de descendre au niveau d'une conversation ou d'un appel d'outil, et de repérer l'agent qui boucle ou le prompt système devenu obèse.

4. Les huit leviers techniques, du moins cher au plus engageant

Une fois la mesure en place, les économies viennent de huit leviers. Les premiers se mettent en œuvre en une journée ; les derniers engagent l'entreprise sur un an.

1. Réduire les prompts : un prompt système passé de 3 000 à 800 tokens sur un assistant à 50 000 messages par jour économise 110 millions de tokens d'entrée par mois. Mesurez la longueur moyenne des prompts par application ; c'est souvent le premier poste.
2. Choisir le bon modèle par tâche : les modèles « mini » ou « nano » coûtent 10 à 30 fois moins que les modèles frontière et suffisent à la classification, l'extraction et le résumé. Routez par type de tâche, pas par habitude ; l'API de modèle unifiée d'API Management permet de changer de modèle sans toucher aux applications.
3. Exploiter le prompt caching : placez le contenu stable (consignes, définitions d'outils, documents de référence) en début de prompt ; les tokens en cache sont facturés à une fraction du prix d'entrée, et déduits à 100 % de l'utilisation en provisionné. Attention : les modèles récents peuvent facturer l'écriture en cache selon la durée de rétention choisie — structurez les prompts pour favoriser les lectures.
4. Activer le cache sémantique à la passerelle : les politiques llm-semantic-cache-lookup et -store servent une réponse déjà produite quand un prompt est sémantiquement proche d'un précédent. Sur une FAQ interne, 20 à 40 % des appels n'atteignent plus le modèle.
5. Basculer en Batch ce qui n'est pas interactif : enrichissement de catalogues, résumés de documents, classification de masse — tout ce qui tolère 24 heures de délai coûte moitié prix en Batch global ou zone de données, avec un quota séparé qui ne gêne pas le trafic interactif.
6. Choisir le périmètre de déploiement : le standard global est le moins cher ; la zone de données Europe satisfait la plupart des exigences de résidence pour un surcoût modéré ; le régional ne se justifie que par une contrainte réglementaire explicite.
7. Passer en provisionné quand la charge est prévisible : au-delà d'un certain volume régulier, la capacité réservée (PTU) revient moins cher que l'usage et garantit la latence. Dimensionnez avec le calculateur Foundry à partir des tokens réellement mesurés, déployez d'abord, puis réservez.
8. Réserver : la réservation Azure sur les PTU (1 mois ou 1 an, périmètre souscription, groupe de gestion ou compte de facturation) applique une remise significative sur le tarif horaire. Elle ne réserve pas de capacité, elle garantit un prix : créez les déploiements avant d'acheter la réservation pour ne pas sur-acheter.

Architecture de coût recommandée pour une plateforme mature : une base en PTU réservées dimensionnée sur le trafic plancher, un débordement en standard global ou zone de données via un pool de backends API Management avec disjoncteur, et le Batch pour tout ce qui n'est pas interactif. C'est le profil qui minimise le coût par token sans dégrader la latence.

5. Tenir : quotas et plafonds exécutoires par équipe

Mesurer et optimiser ne suffisent pas si une équipe peut, par un bug ou un enthousiasme, consommer le budget des autres. Les plafonds doivent être techniques, pas contractuels.

• La politique llm-token-limit d'API Management fixe, par produit (équipe), un débit en tokens par minute et un quota sur une période (jour, semaine, mois). Quand le quota est atteint, les appels renvoient 429 : l'équipe vient discuter, le budget est intact.
• Les quotas Foundry (tokens par minute par modèle, région et souscription) restent la limite de dernier ressort ; répartissez-les consciemment entre déploiements plutôt que de laisser le premier arrivé tout prendre.
• Les budgets Azure Cost Management, par souscription et par groupe de ressources, avec alertes à 50, 80 et 100 % envoyées au responsable de l'équipe et au FinOps, ferment la boucle côté facture.
• Pour les agents, limitez aussi le nombre d'étapes et d'appels d'outils par session : un agent qui boucle consomme des tokens à chaque itération, et aucune alerte de budget ne le rattrape en temps réel.

<!-- Plafond par équipe : 50 000 tokens/min et 20 millions de tokens par mois -->
<llm-token-limit counter-key="@(context.Product.Id)"
                 tokens-per-minute="50000"
                 token-quota="20000000"
                 token-quota-period="Monthly"
                 estimate-prompt-tokens="true"
                 remaining-tokens-variable-name="remainingTokens"
                 remaining-tokens-header-name="x-tokens-remaining" />

6. Imputer et prévoir : showback, chargeback et modèle prévisionnel

Le showback — montrer à chaque équipe ce qu'elle consomme — suffit souvent à faire baisser la facture de 20 à 30 % en un trimestre, sans aucune optimisation technique : les équipes découvrent leur prompt système, leur modèle surdimensionné, leur traitement de nuit oublié. Le chargeback — refacturer réellement — vient ensuite, quand la mesure est stable et acceptée.

• Rapport mensuel par équipe : tokens d'entrée, de sortie et en cache, coût estimé au tarif public, part des coûts fixes de plateforme, évolution sur trois mois, top 3 des applications.
• Coût unitaire métier : ramenez les tokens à l'unité qui parle au métier — coût par conversation, par document traité, par ticket résolu, par utilisateur actif. C'est ce chiffre qui permet de décider si un cas d'usage est rentable, pas le total de tokens.
• Modèle prévisionnel : pour chaque cas d'usage, estimez tokens moyens par interaction × interactions par utilisateur × utilisateurs × prix du modèle. Un tableur suffit ; mettez-le à jour avec les mesures réelles après le pilote. La plupart des écarts viennent des tokens d'entrée (contexte RAG plus long que prévu) et des reprises de conversation.
• Seuil provisionné : calculez le point où le coût horaire des PTU réservées devient inférieur au coût à l'usage de votre trafic plancher. En dessous, restez en standard ; au-dessus, réservez la base et débordez.

7. La boucle FinOps mensuelle en cinq étapes

Le FinOps de l'IA n'est pas un projet mais une routine. Une heure par mois et par équipe, trois heures pour la plateforme.

1. Lire : le rapport de showback par équipe et le tableau de bord plateforme (tokens, coûts, taux de cache, utilisation des PTU, erreurs 429).
2. Expliquer : chaque variation de plus de 15 % a une cause — nouveau cas d'usage, prompt modifié, changement de modèle, trafic. L'équipe l'explique en une phrase dans le rapport.
3. Décider : ajuster les quotas, basculer un traitement en Batch, changer un modèle, redimensionner ou renouveler une réservation, retirer un agent sans usage.
4. Appliquer : les décisions se traduisent en modifications d'infrastructure as code (politiques API Management, déploiements Foundry, budgets), revues et déployées comme n'importe quel changement.
5. Vérifier : le mois suivant, l'effet de chaque décision est mesuré. Ce qui n'a pas produit d'effet est annulé.

8. Les cinq erreurs que je vois le plus souvent

• Acheter des PTU avant de mesurer. La réservation garantit un prix, pas l'usage ; sans trafic plancher connu, on paie de la capacité vide. Déployez en standard, mesurez trois mois, puis réservez.
• Un quota global pour tout le monde. Le premier traitement par lots bloque les applications interactives, et personne n'est responsable de la facture. Un produit par équipe, un quota par produit.
• Ignorer les tokens de sortie et de raisonnement. Les tableaux de bord qui ne comptent que les prompts sous-estiment le coût d'un facteur deux à quatre sur les modèles de raisonnement.
• Optimiser le modèle avant le prompt. Changer de modèle fait gagner 30 % ; couper un prompt système redondant et activer le cache en fait gagner 60 % sans changer la qualité.
• Confondre résidence des données et région. Beaucoup d'exigences « données en Europe » sont satisfaites par la zone de données Europe, nettement moins chère et mieux dotée en quota que le déploiement régional.

9. Par où commencer

Par la mesure, en deux semaines : une passerelle API Management devant Foundry si elle n'existe pas, un produit par équipe, la politique de métriques de tokens, un tableau de bord. Au premier rapport de showback, les trois quarts des économies apparaissent d'elles-mêmes : prompts à couper, modèles à rétrograder, traitements à passer en Batch. Les quotas suivent le mois d'après, quand les équipes connaissent leur consommation normale. Le provisionné et les réservations se décident au troisième mois, sur des chiffres réels.

Si vous voulez un ordre de grandeur de ce que votre plateforme pourrait économiser, c'est le genre de calcul que l'on fait en trente minutes à partir d'un export de facture.