Le prix d'un créateur d'applications par IA dépend de ce qui compte comme travail

Le forfait le moins cher pour 100 itérations de prompts par semaine est souvent celui qui compte le moins de travail autour de chaque prompt. Le prix mensuel affiché ne dit presque rien tant que vous ne savez pas si une nouvelle tentative, une étape de planification, un test, un déploiement et un agent qui travaille en arrière-plan sont tous mesurés par le même compteur.

J'ai vu des équipes comparer des forfaits en divisant le prix d'un abonnement par 100 prompts. Le calcul est propre, mais faux. Un prompt qui modifie le texte d'un bouton et un prompt qui réorganise une base de données comptent chacun comme un message pour la personne qui les saisit, mais ils peuvent produire des factures très différentes. Une comparaison honnête commence par un registre de charge de travail, puis applique les règles de facturation de chaque fournisseur à ce même registre.

Cet article utilise un catalogue tarifaire hypothétique, et non les prix d'un fournisseur nommé. L'objectif est de vous donner un calcul que vous pourrez remplacer par les conditions réelles des forfaits avant d'acheter.

Le même nombre de prompts peut masquer trois factures différentes

Le nombre de messages utilisateur mesure une conversation, pas la puissance de calcul ni le travail terminé. Les forfaits à crédits mesurent généralement l'activité des modèles, les forfaits à la tâche mesurent une unité de travail définie par le fournisseur, et les forfaits fixes vendent un accès dans certaines limites. Ces limites produisent des totaux différents, même lorsque l'application et les 100 demandes hebdomadaires restent identiques.

Supposons qu'une fondatrice demande chaque semaine 70 petites modifications d'interface, 20 modifications qui touchent plusieurs fichiers et 10 modifications de build ou de déploiement. Le décompte visible est de 100. En coulisses, le créateur peut examiner le dépôt, établir un plan, appeler un modèle plusieurs fois, lancer des tests, corriger une modification ratée, reconstruire l'application et laisser un agent travailler après l'affichage de la réponse du chat. Un forfait peut facturer chaque appel de modèle. Un autre peut considérer toute la séquence comme une seule tâche. Un abonnement peut l'inclure, le plafonner ou facturer une partie en supplément.

C'est la distinction que les acheteurs confondent régulièrement : une itération correspond à un cycle de décision de l'utilisateur, tandis qu'un événement facturable est ce que le vendeur a choisi de mesurer. Les traiter comme des synonymes favorise le forfait dont la page tarifaire est la plus vague. Cela peut aussi rendre cher un forfait qui semblait économique après que l'équipe a engagé son application sur la plateforme.

Pour comparer, utilisez un facteur mensuel de 4,33 semaines au lieu de prétendre que tous les mois en ont quatre. Cent itérations hebdomadaires deviennent 433 itérations mensuelles. Cette petite correction ajoute 33 itérations, avant même de compter une seule nouvelle tentative ou tâche en arrière-plan.

Une demande de devis utile invite le fournisseur à classer le travail, pas seulement à estimer un total. Demandez : qu'est-ce qui démarre le compteur ? Quand s'arrête-t-il ? Une exécution échouée compte-t-elle ? Une nouvelle tentative automatique compte-t-elle ? Quel travail continue après que l'interface indique que la réponse est terminée ? La capacité inutilisée peut-elle être reportée ? Les réponses déterminent la facture.

Définissez une seule charge de travail avant d'ouvrir la calculatrice

Construisez une semaine représentative à partir du travail que vous prévoyez réellement, puis figez-la avant de comparer les forfaits. Si vous modifiez la charge de travail pour chaque modèle tarifaire, vous testez des arguments commerciaux, pas des prix.

Pour cette comparaison chiffrée, j'utiliserai cette charge de travail hebdomadaire :

• 70 petites modifications à une unité de crédit chacune
• 20 modifications sur plusieurs fichiers à trois unités de crédit chacune
• 10 modifications de build ou de déploiement à cinq unités de crédit chacune
• 25 nouvelles tentatives à deux unités de crédit en moyenne
• 35 exécutions en arrière-plan consommant 45 unités de crédit au total

Les 100 itérations demandées consomment 180 unités de crédit hypothétiques lors de leurs premiers passages. Les nouvelles tentatives en ajoutent 50. La planification, l'indexation, les tests et le travail de déploiement en ajoutent 45. Le total hebdomadaire est de 275 unités, soit 1 190,75 unités sur un mois moyen.

La même activité prend une autre forme avec une facturation à la tâche. Elle crée chaque semaine 100 débuts de tâche lancés par l'utilisateur, 25 débuts de nouvelle tentative et 35 débuts de tâche en arrière-plan. Cela fait 160 événements par semaine et 692,8 événements par mois. Le fait que les 692,8 soient tous facturables dépend de la définition contractuelle d'une tâche.

Consignez séparément le travail réussi et le travail échoué. Un taux d'échec fondé uniquement sur les messages d'erreur visibles ne tient pas compte des réparations silencieuses, des basculements automatiques de modèle et des nouveaux lancements de tests. L'export d'utilisation de la plateforme, s'il existe, constitue une meilleure preuve qu'un historique de chat, car le chat peut regrouper plusieurs exécutions d'agents dans une seule réponse.

Utilisez une semaine qui comprend les désagréments ordinaires : un prompt imprécis, un conflit de dépendances, un test qui échoue pour une raison sans rapport et une correction de déploiement. Une semaine de démonstration impeccable produit un budget qui ne tient que jusqu'au début du vrai développement.

N'augmentez pas artificiellement la charge de travail pour vous protéger. Ajoutez une marge de variation distincte après avoir calculé la base observée. En séparant la base et la marge, vous voyez si un forfait est coûteux à cause du travail normal ou parce que vous avez acheté une assurance contre un mois chargé.

Les packs de crédits facturent l'activité au sein du créateur

Les packs de crédits coûtent moins cher lorsque les prix unitaires de la plateforme sont bas, que les crédits inutilisés restent valables assez longtemps pour être employés et que le créateur nécessite peu de passages de correction. Ils coûtent davantage lorsqu'une simple demande se divise en plusieurs appels de modèles invisibles pour l'utilisateur.

Un crédit n'est pas une unité standard. Il peut représenter des tokens, des appels de modèle, des étapes d'agent, des secondes ou un mélange pondéré. Un fournisseur peut aussi facturer un nombre différent de crédits pour un modèle rapide et un modèle plus performant. Comparer le nombre de crédits de deux packs n'a aucun sens à moins que les deux plateformes définissent leur consommation de la même façon, ce qui est rarement le cas.

Chiffrez la charge de travail hypothétique avec un pack de 500 unités coûtant 30 $. La demande mensuelle est de 1 190,75 unités. Comme les packs sont indivisibles, l'acheteur a besoin de trois packs et paie 90 $. Le compte termine le mois avec 309,25 unités restantes si les crédits n'expirent pas. Le coût effectif du travail consommé est d'environ 7,56 cents par unité, même si le pack affiche 6 cents, car l'acheteur a dû acheter une capacité inutilisée.

Le report change le résultat. Si les 309,25 unités restantes restent valables, l'achat du mois suivant peut être de deux packs plutôt que trois. Sur plusieurs mois stables, le coût moyen se rapproche du tarif affiché. Si les crédits expirent tous les mois, le solde perdu fait partie du prix. Ne l'omettez jamais du modèle.

Le choix du modèle peut modifier la consommation sans changer le nombre de prompts. Si la plateforme oriente les modifications complexes vers un modèle avec un multiplicateur de quatre unités, les dix demandes les plus difficiles peuvent dominer la facture. Demandez si ce routage est automatique, si vous pouvez le voir après coup et si vous pouvez fixer un plafond. Un modèle moins cher qui échoue puis réessaie deux fois peut coûter plus qu'un modèle performant qui réussit une fois.

Les packs de crédits conviennent bien aux projets irréguliers, car vous payez lorsque le travail a lieu, à condition que les crédits aient une durée de validité utile. Ils sont plus difficiles à budgéter pour une équipe qui expérimente librement. Le compteur peut modifier les comportements : les personnes regroupent des demandes sans rapport dans des prompts trop volumineux, évitent les tests ou acceptent une sortie faible pour économiser des crédits. Ces choix réduisent la facture en dégradant l'application.

La question délicate est de savoir si le travail en arrière-plan doit consommer des crédits. Il consomme des ressources, il est donc défendable de le facturer. Le problème apparaît lorsque l'acheteur ne peut ni le prévoir ni l'arrêter. Une évaluation équitable vérifie si l'interface affiche chaque frais en arrière-plan et si une limite de dépenses bloque les nouveaux travaux avant que le solde n'atteigne zéro.

La facturation à la tâche dépend du début et de la fin d'une tâche

La facturation à la tâche peut être le modèle le moins cher lorsqu'un prix couvre toute la tentative, y compris la planification, les appels de modèle, les tests et les corrections. Elle devient la plus chère lorsque chaque action interne devient une nouvelle tâche.

Appliquez un tarif hypothétique de 0,14 $ à chaque événement démarré dans le registre. Avec 692,8 événements mensuels, le coût est de 96,99 $ après arrondi au centime. C'est plus que le résultat de 90 $ des packs de crédits, même si quatorze cents semblent peu sur une page tarifaire.

Modifiez maintenant une phrase du contrat : ne facturer que les 433 itérations demandées par l'utilisateur, tout en incluant les nouvelles tentatives et le travail en arrière-plan dans chaque tâche. Le coût mensuel tombe à 60,62 $. L'application n'a pas changé. La limite de la tâche a changé, et ce changement représente 36,37 $.

La facturation à la tâche terminée exige une autre définition. Si une exécution modifie des fichiers mais échoue au déploiement, la plateforme a-t-elle terminé la tâche ? Si l'utilisateur rejette le résultat et demande une correction, s'agit-il d'une nouvelle tâche ou de la suite de la précédente ? Les fournisseurs ont besoin de règles pour éviter un travail illimité à prix fixe, mais les acheteurs ont besoin de règles qu'ils peuvent reproduire à partir d'un journal d'activité.

La recommandation populaire de comparer le coût par prompt réussi est fausse lorsque la réussite est déclarée par l'utilisateur. Les utilisateurs acceptent des résultats partiels, découpent de grandes demandes et corrigent la sortie manuellement. Un faible coût par réussite enregistrée peut masquer des heures de nettoyage. Comparez plutôt le coût par modification acceptée, au moment où l'équipe fusionnerait, déploierait ou conserverait le résultat.

La tarification à la tâche offre un avantage budgétaire lorsque l'unité correspond à quelque chose qu'une personne reconnaît. Une équipe peut estimer 400 modifications acceptées avec plus de confiance que des millions de tokens. Cet avantage disparaît si le produit étiquette l'indexation, la planification, les tests et le déploiement comme des tâches distinctes. Lisez les noms des événements sur une facture réelle ou dans un export d'utilisation avant de considérer l'unité comme stable.

Demandez aussi comment fonctionne la concurrence. Deux agents lancés en même temps peuvent réduire le temps écoulé tout en doublant les débuts de tâche. Une réparation en arrière-plan qui lance un agent de test peut compter une fois, deux fois ou pas du tout. La facture suit le compteur, pas l'horloge.

Les abonnements fixes ne gagnent qu'à l'intérieur de leur limite incluse

Un abonnement fixe coûte le moins cher pour cette charge de travail lorsque le prix mensuel comprend les 433 itérations utilisateur, les 108,25 débuts de nouvelles tentatives et les 151,55 débuts en arrière-plan. Si une catégorie sort de l'abonnement, ajoutez-la avant de déclarer le forfait fixe moins cher.

Prenez un forfait hypothétique à 79 $ par mois, qui inclut jusqu'à 600 exécutions interactives et nouvelles tentatives, ainsi que 200 exécutions en arrière-plan. L'exemple produit 541,25 exécutions interactives et nouvelles tentatives et 151,55 exécutions en arrière-plan par mois. Les deux totaux sont dans les limites, donc le coût reste de 79 $. Avec ces hypothèses, la tarification fixe bat les packs de crédits à 90 $ et le forfait à la tâche démarrée à 96,99 $.

Le mot « illimité » ne mérite aucune valeur dans un tableur. Remplacez-le par le seuil réel d'usage raisonnable, la limite de concurrence, la restriction de modèle ou la règle de ralentissement. Si le fournisseur refuse d'indiquer une limite, modélisez un cas bas et un cas haut. Un forfait qui paraît bon marché uniquement avec une interprétation sans limite ne vous a pas donné un prix fiable.

Les forfaits fixes créent aussi des coûts par paliers. À 599 exécutions incluses, une exécution de plus peut ne rien coûter. À 600, l'exécution suivante peut déclencher un supplément ou imposer un niveau supérieur. Représentez au moins trois niveaux de charge : un mois calme, le mois attendu et un mois de mise en production. Le cas attendu seul masque le moment où l'abonnement augmente.

Les licences comptent lorsque la facturation suit les utilisateurs plutôt que le travail. Un forfait de 79 $ pour une personne coûte 316 $ pour quatre licences obligatoires, même si l'équipe partage les mêmes 433 itérations. Ne supposez pas que le partage de compte est autorisé. Chiffrez les personnes qui doivent examiner les prompts, approuver les déploiements ou consulter l'utilisation.

Un prix fixe peut encourager une expérimentation saine, car chaque idée ratée ne génère pas de microfacturation visible. Il peut aussi cacher le gaspillage jusqu'à ce que la plateforme limite le compte. La visibilité sur l'utilisation reste importante. Vous devez savoir si des agents tournent en boucle et si un mois de mise en production franchira la limite incluse.

Les remises annuelles doivent intervenir en dernier dans le calcul. Commencez par identifier le modèle le moins cher aux conditions mensuelles. Appliquez ensuite la remise et le coût de l'engagement. Payer dix mois pour un outil abandonné au bout de trois mois n'est pas une économie.

Les nouvelles tentatives appartiennent à la base, pas à une note de bas de page

Les nouvelles tentatives font partie du travail normal de développement. Une comparaison de prix qui suppose un résultat parfait dès le premier passage ne convient pas à un achat. Le chiffre utile est le coefficient d'amplification des nouvelles tentatives : le total des tentatives divisé par les itérations demandées.

L'exemple compte 125 tentatives interactives pour 100 itérations demandées, ce qui donne un coefficient de 1,25. Cela ne signifie pas que 25 % des prompts échouent simplement. Certaines demandes nécessitent des précisions, certaines modifications passent les vérifications de code mais ne répondent pas à l'intention, et certains échecs viennent des outils ou des dépendances. L'effet sur la facturation est le même lorsqu'un forfait mesure une nouvelle tentative.

Mesurez les nouvelles tentatives avec une règle que deux personnes peuvent appliquer de façon cohérente. Comptez une nouvelle tentative lorsque l'utilisateur répète le même résultat attendu après avoir rejeté ou corrigé la sortie précédente. Ne comptez pas une exigence réellement nouvelle comme une nouvelle tentative. Étiquetez séparément les nouvelles tentatives automatiques, car l'utilisateur peut ne jamais les voir.

Un petit essai doit inclure les tâches que vous attendez les plus difficiles. Si vous testez uniquement le texte de pages d'accueil et les changements de couleur, le taux de nouvelles tentatives renseigne peu sur les migrations de base de données, l'authentification, la gestion de l'état ou les builds mobiles. Faites passer au moins une modification risquée dans chaque option envisagée et examinez le journal d'activité.

Les nouvelles tentatives affectent les modèles différemment :

• La facturation à crédits facture généralement les ressources consommées par chaque tentative.
• La facturation à la tâche démarrée facture généralement chaque tentative si la nouvelle tentative crée un événement.
• La facturation à la fin peut absorber les tentatives échouées, selon sa règle d'achèvement.
• La facturation fixe absorbe les nouvelles tentatives jusqu'à ce qu'elles atteignent une limite incluse ou un contrôle d'usage raisonnable.

N'acceptez pas les nouvelles tentatives gratuites comme réponse complète. Demandez si la nouvelle tentative utilise le même modèle, si le basculement automatique consomme une réserve distincte et combien de temps la fenêtre de gratuité reste ouverte. Une correction soumise le lendemain matin peut devenir une nouvelle tâche même si le travail est clairement le même.

Il existe aussi un coût humain des nouvelles tentatives. Un forfait peut être bon marché en dollars et coûteux en attention si les utilisateurs doivent superviser chaque correction. Suivez le nombre de minutes de révision par modification acceptée pendant l'essai. Ne forcez pas ce temps à entrer dans la facture de la plateforme, mais affichez-le à côté afin qu'un prix bas ne cache pas un mauvais processus.

Les agents en arrière-plan sont le multiplicateur invisible

Le travail des agents en arrière-plan doit apparaître sur sa propre ligne, car il peut continuer après que l'utilisateur voit une réponse. L'indexation du dépôt, la planification, les contrôles de dépendances, les tests, la surveillance de build, le déploiement et les agents de réparation peuvent tous consommer du budget sans ajouter un autre message de chat.

Notre exemple attribue 35 exécutions en arrière-plan et 45 unités de crédit chaque semaine. Ces nombres sont volontairement des hypothèses visibles. Remplacez-les par les relevés d'utilisation d'un essai. Si un fournisseur n'affiche qu'un total combiné, lancez le même prompt une fois avec l'automatisation facultative désactivée et une fois activée. La différence est une estimation, pas une preuve, mais elle vaut mieux que de considérer ce travail comme gratuit.

Le mode planification mérite une attention particulière. Un plan peut réduire les échecs coûteux de mise en œuvre en détectant tôt les conflits, ou ajouter une étape payante avant chaque modification triviale. Testez-le séparément sur de petites et de grandes modifications. La bonne règle peut être de l'utiliser pour les changements de schéma et le travail sur plusieurs fichiers, tout en l'évitant pour les modifications de texte.

L'indexation a une forme de coût différente. Le premier passage sur un dépôt peut être coûteux, tandis que les mises à jour incrémentales ultérieures coûtent peu. Un essai d'une semaine peut exagérer le coût permanent s'il inclut l'indexation initiale, ou le sous-estimer si le dépôt de production est beaucoup plus grand. Séparez la consommation de mise en place de la consommation récurrente.

Les tests et le déploiement ne sont pas du gaspillage facultatif. Les désactiver pour respecter une réserve de crédits transfère la détection des problèmes aux utilisateurs. Chiffrez le processus sûr que vous prévoyez d'utiliser, y compris les contrôles qui le protègent. Une comparaison fondée sur des tests désactivés répond à la mauvaise question métier.

Koder.ai prend en charge le mode planification, le déploiement et l'hébergement, les instantanés et la restauration, ainsi que l'export du code source. Un essai peut donc observer ces éléments du processus au lieu de tarifer les seuls messages de chat. Les noms des forfaits et leurs prix doivent tout de même être vérifiés dans l'interface actuelle du produit, car le contexte du site établit ici des niveaux, pas leurs limites actuelles.

Fixez un budget pour l'arrière-plan si le produit le permet, mais ne confondez pas plafond et prévisibilité. Un plafond évite les dépenses excessives en arrêtant le travail. L'application peut tout de même manquer une mise en production pendant qu'un agent attend plus de capacité. Notez la limite financière et sa conséquence opérationnelle.

Faites passer chaque option par le même registre

Un registre rend la comparaison reproductible et révèle les ambiguïtés contractuelles avant qu'elles ne deviennent un litige de facture. Une ligne doit décrire un événement mesuré, avec suffisamment de contexte pour le mapper aux crédits, aux tâches et aux limites d'abonnement.

Copiez cet en-tête CSV et utilisez-le pendant un essai :

week,event_id,requested_iteration,event_type,outcome,retry_of,background_kind,credit_units,task_events,flat_bucket,notes
2026-W01,001,1,user_edit,accepted,,,1,1,interactive,copy change
2026-W01,002,2,user_edit,rejected,,,3,1,interactive,multi file edit
2026-W01,003,2,retry,accepted,002,,2,1,interactive,repair after failed test
2026-W01,004,2,background,completed,,test,1,1,background,automatic test run

Gardez le type d'événement et le résultat séparés. Un test en arrière-plan peut se terminer avec succès alors que la modification demandée échoue encore à l'acceptation. Si vous regroupez ces faits dans un seul statut, vous ne pouvez pas vérifier la règle du fournisseur sur les tâches terminées.

À la fin de la semaine, calculez quatre valeurs :

monthly_iterations = weekly_requested_iterations * 4.33
monthly_credits = weekly_credit_units * 4.33
monthly_task_events = weekly_task_events * 4.33
retry_amplification = (user_attempts + retry_attempts) / requested_iterations

Appliquez ensuite les conditions du forfait sans modifier les lignes. Pour le catalogue hypothétique, le calcul est :

credit_cost = ceil(1190.75 / 500) * $30 = $90.00
started_task_cost = 692.8 * $0.14 = $96.99
flat_cost = $79.00, because 541.25 interactive runs < 600
             and 151.55 background runs < 200

Un tableur doit aussi afficher les crédits perdus, la capacité incluse restante et la prochaine limite tarifaire. Le forfait gagnant dans l'exemple conserve 58,75 exécutions interactives et 48,45 exécutions en arrière-plan. Cette marge est trop faible pour une semaine de mise en production qui double le travail de déploiement, donc l'équipe doit calculer ce cas avant de s'engager.

Demandez au fournisseur d'examiner une page anonymisée du registre. Ne demandez pas quel forfait est le moins cher, demandez comment chaque ligne serait classée. Une classification écrite est plus utile qu'une estimation commerciale, car vous pourrez la comparer à la première facture.

La variation compte davantage que le prix affiché

Dans l'exemple, l'abonnement fixe arrive à 79 $, les packs de crédits à 90 $ et la facturation à la tâche démarrée à 96,99 $. Ce classement ne vaut que pour le catalogue et la charge de travail indiqués. Un petit changement dans le traitement des nouvelles tentatives ou le travail en arrière-plan inclus peut l'inverser.

Calculez un seuil de rentabilité pour chaque paire. Le forfait fixe à 79 $ bat les packs à 30 $ dès que la demande mensuelle nécessite trois packs ou plus, en supposant que les crédits inutilisés n'ont aucune valeur future. Si le report permet à l'acheteur d'utiliser chaque unité, 79 $ correspondent à environ 1 316,7 unités de crédit à six cents l'unité. Sous ce niveau d'usage, les crédits entièrement utilisés coûtent moins cher.

Face aux tâches démarrées à 0,14 $, 79 $ correspondent à environ 564,3 événements. Les 692,8 événements attendus dépassent ce seuil. Si le forfait à la tâche facture seulement les 433 itérations demandées, il coûte toutefois 60,62 $ et l'emporte. Une fois encore, une définition compte davantage que le tarif affiché.

Faites varier les paramètres au lieu de prétendre que l'estimation est exacte. Pour cette charge de travail, faites passer le coefficient d'amplification des nouvelles tentatives de 1,10 à 1,50, le travail en arrière-plan de 20 à 60 événements hebdomadaires, et la consommation des modifications complexes selon un multiplicateur raisonnable communiqué par le fournisseur. Vous n'avez pas besoin de dizaines de scénarios. Il vous faut les quelques variables qui peuvent modifier la décision.

Considérez séparément la trésorerie et l'engagement, plutôt que le seul coût unitaire. Les packs peuvent préserver la flexibilité. Un abonnement mensuel crée un plafond prévisible tant que vous restez dans sa limite. Un abonnement annuel échange de la flexibilité contre une remise. L'export du code source et les instantanés peuvent réduire le coût de sortie d'un créateur, mais ne rendent pas la migration gratuite : l'application exportée a encore besoin d'un build fonctionnel, d'une infrastructure et d'une personne capable de la maintenir.

Une fondatrice dont l'usage est incertain devrait privilégier le modèle dont le risque de hausse est visible. Il peut s'agir de packs avec un long report, même lorsque le total mensuel attendu est légèrement plus élevé. Une équipe dont le travail est régulier et mesuré peut choisir un forfait fixe proche du milieu de sa capacité incluse. Un forfait à la tâche convient à un travail qui correspond clairement à des résultats acceptés et inclut les corrections dans la tâche.

Ne choisissez pas en fonction du gagnant de l'exemple. Choisissez après avoir remplacé chaque tarif et limite hypothétiques par des conditions auxquelles vous pouvez vous référer, et chaque hypothèse de charge de travail par une observation faite lors d'un essai.

Soumettez le modèle de facturation à un test d'acceptation

Un modèle tarifaire est prêt pour une décision lorsqu'une autre personne peut reproduire le total mensuel à partir du registre et des conditions du forfait. Si le calcul dépend de l'interprétation après coup d'une tâche interne par un commercial, le modèle échoue au test.

Utilisez cette liste de contrôle compacte :

1. Enregistrez 100 itérations demandées représentatives, ou un échantillon plus petit incluant chaque grand type de travail.
2. Étiquetez les nouvelles tentatives, les nouvelles tentatives automatiques, les plans, les tests, les builds, les déploiements et les autres exécutions en arrière-plan.
3. Associez chaque événement à la règle du fournisseur concernant les crédits, les tâches ou la capacité incluse.
4. Calculez les totaux d'un mois attendu, calme et de mise en production avec le même facteur de 4,33.
5. Conservez les conditions du forfait et comparez la première facture réelle avec la prévision.

Fixez une tolérance avant l'essai. Par exemple, vous pouvez décider d'examiner tout total supérieur de plus de 10 % à la prévision. Ce pourcentage est un choix de gestion, pas une norme du secteur. Son rôle est de forcer un examen tant que l'historique des événements existe encore.

Si l'usage réel dépasse la prévision, identifiez la catégorie de lignes responsable. Davantage de travail accepté est différent de davantage de nouvelles tentatives. Davantage d'exécutions de déploiement planifiées est différent d'une boucle d'agent. La solution peut être un forfait plus grand, une politique d'agent plus restrictive, des prompts plus clairs ou une correction de facturation. Un total unique ne peut pas vous dire lequel.

Gardez le registre à côté de la facture pendant les trois premiers cycles de facturation, car un essai calme peut manquer les tâches par lot, le travail de mise en production et les réparations automatiques. Le modèle le moins cher pour 100 itérations hebdomadaires dépend donc du contexte, mais la décision n'a pas besoin d'être vague. Dans l'exemple explicite, l'abonnement fixe à 79 $ l'emporte. Avec une facturation à la tâche limitée à la réussite, le même travail coûte 60,62 $ et la facturation à la tâche l'emporte. Les packs de crédits gagnent avec une consommation plus faible ou ponctuelle lorsque le report évite le gaspillage. Notez ce qui compte, mesurez le travail caché et laissez la facture prouver la promesse.