Lancez une fonctionnalité d’IA et la première facture du fournisseur de modèle ne vous dit presque rien de ce qu’elle coûte réellement à servir. Le prix par token est le dixième visible de l’iceberg. En dessous se trouvent la recherche documentaire, l’orchestration, la journalisation, la relecture humaine des cas que le modèle rate, et les demandes de support que la fonctionnalité génère quand elle se trompe avec assurance. La plupart des équipes fixent le prix de la fonctionnalité, ou décident de la garder, en ne regardant que la partie visible.
Combien coûte réellement une fonctionnalité d’IA à servir ?
La facture de l’API du modèle n’est qu’une ligne du coût réel. Un chiffre complet ajoute la recherche documentaire et le stockage vectoriel, l’infrastructure d’orchestration et de journalisation, la relecture humaine ou la modération d’une part des résultats, et le coût de support lié au traitement des erreurs. Pour la plupart des fonctionnalités d’IA, ces coûts périphériques sont comparables à la facture d’inférence elle-même, parfois supérieurs. C’est pourquoi traiter la facture de l’API comme le coût de service le sous-estime lourdement.
La facture que vous voyez, et celle que vous ne voyez pas
La facture d’inférence est facile à suivre parce qu’elle arrive sous forme d’un document unique et détaillé : tokens en entrée, tokens en sortie, un prix au million. Cette visibilité est précisément la raison pour laquelle on la prend pour le coût entier. Tout le reste de ce qui fait fonctionner la fonctionnalité, la recherche qui va chercher le contexte avant même que le modèle ne tourne, la couche d’orchestration qui appelle le modèle, vérifie la réponse et la relance parfois, la journalisation qui vous permettra de déboguer une mauvaise réponse six semaines plus tard, est une dépense d’infrastructure qui apparaît sur une facture cloud sous une douzaine de lignes sans rapport entre elles, et non sur la facture du fournisseur de modèle.
La recherche documentaire et l’orchestration ne sont pas gratuites
Une fonctionnalité augmentée par la recherche lance une requête avant de lancer un modèle : un appel d’embedding, une consultation de base vectorielle, parfois une étape de reclassement. Chacune a son propre coût, croît avec l’usage exactement comme l’appel au modèle, et se trouve très souvent exclue des unités économiques parce qu’elle vit dans une autre partie de la pile, facturée par un autre fournisseur et suivie par une autre équipe. L’orchestration ajoute les relances, les bascules vers un modèle moins cher quand le principal est indisponible, et le calcul des contrôles qui décident quel modèle appeler. Rien de tout cela n’est exotique. Tout cela est un coût réel par requête qu’un modèle de coût de service doit intégrer.
Le coût que personne ne met dans le tableur : se tromper
Toute fonctionnalité d’IA se trompe sur une part de ses réponses, et une mauvaise réponse a un coût bien réel même quand il n’apparaît sur aucune facture : une demande de support, le temps d’un relecteur, un remboursement, un client qui part. Une fonctionnalité avec 3 % d’erreurs et une autre avec 15 % peuvent avoir une facture d’inférence identique et un coût total complètement différent, parce que la seconde génère beaucoup plus de travail en aval. Prendre la facture de l’API pour le coût de la fonctionnalité fait passer le modèle bon marché et peu fiable pour le meilleur choix, jusqu’au jour où la file de support dit le contraire.
Construire un vrai coût de service pour une fonctionnalité d’IA
La méthode ne change pas parce que le coût implique un modèle : définissez l’activité, répondre à une question, rédiger un document, classer une demande, puis tracez chaque pool de coûts qu’une unité de cette activité consomme. L’inférence est un inducteur. Les appels de recherche en sont un autre. Les minutes de relecture humaine, quand une part des résultats l’exige, en sont un troisième, valorisé comme toute activité à forte intensité de main d’oeuvre l’est dans un modèle TDABC. Additionnez-les par unité de travail réellement effectué, et non par euro dépensé en modèle, et la marge réelle de la fonctionnalité, et la question de savoir si elle mérite d’être gardée sous sa forme actuelle, deviennent visibles pour la première fois.
La facture du fournisseur de modèle est le coût des tokens. Ce n’est pas le coût de la fonctionnalité.
Ce qu’il faut vérifier avant de croire les unités économiques d’une fonctionnalité d’IA
Avant d’annoncer un coût par requête ou une marge pour une fonctionnalité d’IA, vérifiez que l’infrastructure de recherche et d’orchestration lui a bien été affectée, et non laissée dans un coût de plateforme partagé que personne ne retrace. Vérifiez qu’un taux d’erreur réaliste a été estimé et valorisé dans le modèle, à partir de données réelles de relecture ou de support plutôt que de la précision annoncée dans le comparatif d’un fournisseur. Et vérifiez que la comparaison entre un modèle moins cher et moins précis et un modèle plus cher et plus précis intègre le coût aval de l’erreur, et pas seulement les deux factures côte à côte.
Réservez une démonstration en direct de CostCtrl et voyez comment les coûts d’inférence, de recherche, de relecture et de support se rejoignent en un seul chiffre réel par fonctionnalité.
À lire également : le coût à servir avec l’IA et construire un modèle TDABC avec l’IA.