La facture d'une fonctionnalité fondée sur un modèle explose rarement à cause du prix unitaire. Elle explose par le nombre d'appels — ceux qu'on n'a pas comptés, ceux qui se répètent à l'identique, ceux qu'un seul utilisateur peut déclencher en boucle. Le levier n'est presque jamais le tarif du fournisseur ; c'est la conception de la fonctionnalité.
7 min de lecture · mis à jour le 20 septembre 2026
La formule à écrire avant de coder
Le coût d'une fonctionnalité se calcule ainsi : nombre d'utilisateurs, multiplié par le nombre d'actions par utilisateur, multiplié par le nombre d'appels par action, multiplié par le coût d'un appel.
Les trois premiers termes sont de votre ressort. Le quatrième appartient au fournisseur et change sans vous prévenir. C'est pourquoi il faut travailler sur les trois premiers : ce sont les seuls sur lesquels vous avez prise.
Le terme le plus souvent sous-estimé est le troisième. Une action qui paraît simple côté utilisateur en déclenche fréquemment plusieurs : une pour reformuler la demande, une pour produire la réponse, une pour la vérifier. Le coût est triplé avant même d'avoir un seul utilisateur.
Écrivez cette multiplication avec des ordres de grandeur réalistes avant d'écrire le code. Si le résultat vous inquiète à mille utilisateurs, il vous ruinera à dix mille — et la conception, elle, ne se change plus à ce stade.
Ce que vous payez : l'entrée autant que la sortie
La facturation se fait au jeton, une unité qui correspond grossièrement à un fragment de mot. Deux volumes sont comptés séparément : ce que vous envoyez et ce que le modèle produit. Les deux comptent, et le premier est le plus facile à laisser grossir sans s'en apercevoir.
Un exemple de dérive courante : une conversation où l'on renvoie tout l'historique à chaque tour. Le dixième message envoie les neuf précédents, le vingtième en envoie dix-neuf. Le coût de l'entrée croît de façon quadratique avec la longueur de l'échange, sans que rien dans l'interface ne le laisse deviner.
Autre dérive : les consignes longues. Une consigne de contexte détaillée est envoyée à chaque appel, pour tous les utilisateurs, indéfiniment. Cinq cents mots de consigne inutile ne se voient nulle part et se paient partout.
Côté sortie, le levier est de demander explicitement de la concision quand la tâche le permet, et de borner la longueur maximale. Un modèle non borné produit volontiers trois paragraphes là où une phrase suffisait.
La mise en cache, le levier le plus rentable
Beaucoup d'appels sont des doublons. Le même document résumé deux fois, la même question posée par deux utilisateurs, la même classification recalculée à chaque affichage d'une page.
Conserver le résultat et le réutiliser supprime le second appel entièrement. Ce n'est pas une optimisation à la marge : sur des fonctionnalités où les entrées se répètent, c'est le facteur qui change l'ordre de grandeur de la facture.
Deux niveaux existent. Votre propre cache, d'abord : vous stockez le résultat associé à l'entrée, et vous ne rappelez le modèle que si l'entrée change. Coût nul, gain total sur les doublons.
La mise en cache proposée par certains fournisseurs ensuite, qui réduit le prix de la partie d'entrée identique d'un appel à l'autre — typiquement une longue consigne commune. Elle demande d'organiser la requête pour que la partie stable soit au début, ce qui est une contrainte d'écriture, pas de développement.
Le bon modèle pour la bonne tâche
Les fournisseurs proposent plusieurs modèles à des tarifs très différents. Utiliser le plus capable pour tout est le réflexe par défaut, et c'est un des postes de gaspillage les plus importants.
Beaucoup de tâches de production sont simples : classer un message dans une catégorie, extraire trois champs d'un texte, décider si une phrase est une question. Un modèle plus petit les traite correctement, plus vite, et pour une fraction du prix.
La méthode : commencez avec le modèle le plus capable pour valider que la fonctionnalité a du sens, puis descendez en gamme en mesurant la qualité sur des cas réels. Le point où elle se dégrade vous donne le bon choix — et il est souvent plus bas qu'on ne le craint.
Pour les tâches répétitives à fort volume sur des données que vous préférez garder chez vous, un modèle exécuté sur votre propre serveur supprime le coût variable. Il le remplace par un coût fixe de machine et une charge d'exploitation ; l'arbitrage se fait au volume, et il bascule plus tôt qu'on ne l'imagine sur les tâches simples.
Les coûts que personne ne chiffre au départ
La facture du fournisseur n'est pas le coût complet. Trois postes s'y ajoutent systématiquement.
- Les essais. Chaque appel qui échoue et qu'on relance est facturé. Une validation stricte qui rejette souvent peut doubler le coût réel par rapport au coût théorique.
- Le développement des garde-fous. Validation des sorties, reprise sur erreur, limitation par utilisateur, journalisation : c'est du temps de développement, et il dépasse souvent celui de la fonctionnalité elle-même.
- La surveillance. Sans suivi de la consommation par fonctionnalité, une dérive se découvre sur la facture du mois suivant. Un tableau de bord interne, même rudimentaire, est le seul moyen de voir le problème avant qu'il ne coûte.
Facturer la fonctionnalité, ou l'absorber
Une fonctionnalité fondée sur un modèle a un coût variable : chaque usage coûte quelque chose. C'est une rupture avec le reste du logiciel, dont le coût marginal est nul, et elle a une conséquence sur votre modèle économique.
Trois approches existent, et le choix se fait tôt parce qu'il conditionne la conception.
- L'absorber dans le prix. Simple à vendre, mais il faut que le coût moyen par client reste largement sous la marge — et surveiller les usages extrêmes, qui existent toujours.
- La compter séparément, en crédits ou en volume. Aligne le prix sur le coût réel et protège des abus, mais ajoute une friction commerciale et une comptabilité à tenir.
- L'inclure dans un palier supérieur. L'usage intensif se retrouve naturellement chez les clients qui paient plus, sans qu'on ait à compter quoi que ce soit.
Les trois garde-fous qui évitent la mauvaise surprise
Une limite par utilisateur et par période, d'abord. Sans elle, une seule personne — ou un script mal intentionné — peut consommer un budget mensuel en une nuit. C'est la protection la plus simple et la plus souvent absente.
Une alerte sur seuil ensuite, posée chez le fournisseur quand il le permet, et doublée d'un compteur chez vous. Découvrir un dépassement sur la facture, c'est le découvrir trente jours trop tard.
Un plafond global enfin, avec un comportement décidé à l'avance : la fonctionnalité se dégrade proprement plutôt que de continuer à consommer. Un produit qui affiche « cette fonction est momentanément indisponible » vaut mieux qu'un produit qui vide un compte.