Rattacher chaque appel IA à un flux et à une personne

Votre fournisseur de modèles sait exactement combien de tokens vous avez consommés le mois dernier. Il n’a aucune idée de quelle automatisation les a consommés, et il ne l’aura jamais. Ce rattachement ne peut se faire que de votre côté, et tant qu’il n’est pas fait, une facture IA est un chiffre qu’on peut payer mais pas piloter.

Ce n’est pas un problème de facturation. C’est un problème de gouvernance déguisé en problème de facturation.

Ce que la facture peut dire, et ce qu’elle ne dira jamais

Une facture de fournisseur vous donne, au mieux : un total, une ventilation par modèle, et parfois une ventilation par clé d’API. C’est suffisant pour répondre à « combien », et à rien d’autre.

Les questions qui reviennent vraiment en réunion de revue sont différentes :

• Quelle automatisation a porté la hausse de ce trimestre ?
• A-t-elle grossi parce que le volume a grossi, ou parce que quelqu’un a changé un prompt ?
• À quel service faut-il refacturer ?
• Ce flux utilise-t-il un modèle bien plus capable que ce que sa tâche demande ?
• Si on divise ce montant par deux, qu’est-ce qui cesse de fonctionner ?

Chacune demande un lien entre un appel et un flux. Aucune ne se répond depuis la facture.

Pourquoi les clés d’API ne sont pas un rattachement

La première tentative classique, c’est une clé par équipe, ou par projet. Ça aide, et ça cesse d’aider très vite.

Les clés se partagent, parce qu’en créer une demande un ticket et en copier une prend une seconde. Une clé créée pour un projet lui survit. Un flux monté par l’équipe A est dupliqué par l’équipe B avec la clé dedans. Six mois plus tard, la répartition par clé décrit l’organigramme tel qu’il était, pas tel qu’il est.

Plus fondamentalement : une clé dit qui a provisionné l’identifiant, pas ce qui a émis l’appel. Ce sont deux faits différents, et c’est le second dont vous avez besoin.

Ce que le rattachement demande réellement

Trois informations, jointes :

1. L’appel. Quel modèle, combien de tokens en entrée, combien en sortie, quand. Disponible chez le fournisseur, requête par requête, si vous le captez.

2. Le flux qui l’a émis. Ça n’existe que dans votre plateforme d’automatisation. C’est la clé de jointure, et c’est la pièce que personne n’a par défaut.

3. Le responsable de ce flux. Ça n’existe que dans vos propres registres, et souvent nulle part, ce qui est l’autre moitié du problème.

Une fois ces trois éléments joints, la facture IA cesse d’être un total et devient un tableau qu’on peut trier. Tout ce qui est utile vient de ce tableau.

Faire la jointure

Il y a deux façons honnêtes d’obtenir le lien entre un appel et un flux, et une troisième qui y ressemble sans en être une.

Étiqueter à l’émission. La plupart des fournisseurs acceptent des métadonnées sur une requête : un champ utilisateur, un en-tête, un identifiant libre. Si chaque flux qui appelle un modèle envoie son propre identifiant, ce sont les journaux du fournisseur qui portent le rattachement, et la jointure devient triviale. C’est la réponse propre, et elle demande de toucher tous les flux qui existent déjà.

Rapprocher des deux côtés. Lire les définitions de flux depuis la plateforme, repérer ceux qui appellent un modèle, extraire ce qu’ils envoient, et rapprocher des relevés de consommation du fournisseur par horodatage et par forme. Moins exact, ne demande aucune modification des flux existants, et fonctionne rétroactivement, ce qui compte, parce que les flux qu’on veut le plus comprendre sont ceux qui tournent déjà.

Estimer depuis le flux seul. Lire le prompt, compter les tokens, multiplier par le nombre d’exécutions. Ça ressemble à un rattachement et c’est de l’arithmétique. C’est un bon contrôle de cohérence et ce n’est pas une mesure : ça ne voit ni les reprises, ni les troncatures, ni la taille variable des entrées réelles. Ne le présentez pas comme la facture.

En pratique, un parc neuf doit étiqueter à l’émission. Un parc existant doit rapprocher, au moins jusqu’à ce que chaque flux ait été repris.

Ce que ça change

L’optimisation cesse d’être une intuition. « On devrait prendre un modèle plus petit » est une opinion. « Ce flux-là fait 60 % de notre dépense IA, il classe trois catégories, et il appelle le plus gros modèle disponible » est une décision qui prend dix secondes.

La refacturation devient possible. Un coût par flux s’agrège en coût par équipe. Ce seul changement fait passer la conversation de « l’IA coûte cher » à « les automatisations de votre service coûtent ce montant, voici le détail », et ça, c’est une conversation sur laquelle quelqu’un peut agir.

La dérive devient visible. Le coût d’un flux qui monte de 30 % sans que son nombre d’exécutions bouge, ça veut dire que ce qu’il envoie a changé. Sans rattachement, ça se voit comme une facture un peu plus grosse et personne ne regarde. Avec, ça se voit comme un flux qui monte dans la liste.

Les revues ont un point d’appui. « Lesquelles de nos automatisations dépendent d’un LLM, et qui l’a validé ? » est une question qui sera posée, par un comité des risques, un auditeur, ou un client. Y répondre depuis une facture est impossible. Y répondre depuis une liste de flux avec des responsables nommés tient sur un écran.

Le prérequis dont personne ne parle

Tout ceci suppose que chaque flux a un responsable. S’il n’en a pas, le rattachement s’arrête une marche trop tôt : vous saurez que Flow_v3_FINAL est ce qui vous coûte le plus, et vous ne saurez pas à qui en parler.

C’est pour ça que le rattachement des coûts et l’attribution des responsabilités sont le même chantier, même s’ils arrivent sous la forme de deux plaintes distinctes, l’une de la finance, l’autre de la DSI. Résolus séparément, ils donnent deux demi-réponses. Le flux est l’unité dont les deux ont besoin, et c’est l’unité qu’aucune plateforme ne leur donne.

C’est toute la raison d’être de Synoptial, et c’est pourquoi la première chose qu’il demande n’est pas un budget mais un nom.