Monétisation, tarification et expériences « coût ↔ qualité »

1. Pourquoi penser à la monétisation dès maintenant

Jusqu’à ce module, la question principale était « est-ce que ça marche vraiment ? ». Maintenant, nous ajoutons un niveau de complexité : « est-ce rentable ? ».

Pour les applications LLM, c’est particulièrement douloureux : les coûts variables (tokens LLM, modèles de rerank, embeddings) peuvent vite vous dépasser, loin de vos habitudes « un serveur à 20 $ et Postgres à 15 $ ». Ignorer cela, c’est recevoir en fin de mois une facture OpenAI comparable à un prêt immobilier.

Nous allons donc traiter trois grands sujets :

1. Quelles modèles de monétisation existent pour une app ChatGPT, et pour notre GiftGenius en particulier.
2. Comment relier pricing ↔ cost_per_task et éviter de vendre « 100 sélections de cadeaux pour 1 $ » si une seule sélection coûte déjà 0,15 USD.
3. Comment mettre en place des expériences A/B « coût ↔ qualité » : changer de modèle, de prompts, d’UX et journaliser cela de manière à pouvoir décider sur données dans quelques semaines, et non à l’instinct.

Ce faisant, nous préparons en douceur le terrain pour le module suivant sur les LLM‑evals et le quality_score, sans plonger dans le code.

2. Modèles de monétisation pour une app ChatGPT : B2C, B2B, freemium et upsell

En mettant de côté la « magie » LLM, les modèles de monétisation ressemblent beaucoup à ceux des applications SaaS et mobiles classiques. Mais un interface conversationnelle a ses nuances : l’utilisateur ne perçoit pas toujours « où c’est gratuit et où c’est payant », et il faut le concevoir avec soin dans l’UX.

Voyons les options principales sur l’exemple de GiftGenius.

B2C : utilisateurs grand public et cadeaux

Ici, vos clients sont des personnes ordinaires qui viennent sur ChatGPT et demandent : « trouve un cadeau pour un fan d’espace pour 50 $ ». Vous ne vendez pas vos propres produits, vous ne faites “que” sélectionner des idées de cadeaux pour l’utilisateur.

Modèles B2C typiques :

1. Achat à l’unité.
   L’utilisateur paie pour un scénario précis. Par exemple : 3 idées gratuites, puis un « pack » payant de 10 idées supplémentaires pour un destinataire.
2. Abonnement.
   Paiement mensuel pour l’accès. Pour GiftGenius, cela peut être « jusqu’à 100 sélections par mois » ou « sélections illimitées pour les gros offreurs ».
3. Freemium (niveaux gratuit vs payant).
   Le scénario de base est gratuit (jusqu’à N sélections par mois, fonctionnalités limitées), et l’offre payante donne plus de quotas, un modèle plus puissant, des formats supplémentaires et l’historique. C’est le modèle le plus courant pour une app ChatGPT : « dans ChatGPT — gratuit en base, et les fonctionnalités premium — payantes ».
4. Upsell dans l’app.
   L’utilisateur fait une sélection de base gratuite, voit un résultat correct, et vous proposez en douceur : « pour X $, je fais une sélection approfondie en tenant compte de la wishlist, des réseaux sociaux, etc. » ou « achète tout de suite un bon cadeau ».

B2B : équipes, entreprises et cadeaux d’entreprise

Ici entrent en jeu les RH, le marketing et « les personnes responsables des cadeaux aux employés/clients ».

Le set traditionnel :

• Licence par utilisateur (per seat).
  Par exemple, un plan « Équipe RH » pour 10 personnes, chacune ayant accès à GiftGenius, avec rapports sur les cadeaux et budgets.
• Licence par entreprise (per company).
  « Jusqu’à 500 employés, prix mensuel fixe, sélections illimitées à l’intérieur ».
• Fonctionnalités enterprise supplémentaires.
  Console d’admin dédiée, intégrations HRIS/CRM, rapports personnalisés, SLA.

Dans les deux cas, vous ne comptez pas « combien coûte une sélection », mais cost_per_user_per_month ou cost_per_tenant_per_month, à comparer au prix de licence.

Comment choisir un modèle pour GiftGenius

Sans s’enliser dans la théorie, on peut prendre une option de départ simple :

• B2C : freemium.
  3 sélections par mois gratuites, puis un abonnement à 5 $ / mois avec sélections illimitées et modèle premium.
• B2B : par entreprise.
  Tarif « Équipe RH » à 99 $ / mois, incluant jusqu’à 500 sélections pour les employés, une intégration au système RH et des rapports.

Ensuite, quand vous aurez des données réelles sur le cost_per_task et la conversion, vous pourrez tout ajuster. En fait, ces chiffres sortent pour l’instant « du chapeau » : ils paraissent raisonnables, mais nous n’avons pas encore vérifié combien nous coûte un scénario terminé. Dans la section suivante, nous relierons ces tarifs à un coût réel — le cost_per_task.

3. Lien entre prix et coût : qu’est-ce que cost_per_task

Passons maintenant à l’essentiel : comment éviter de se transformer en fondation caritative au nom de GPT‑5.

Intuition : prix ≥ cost_per_task × marge

Dans le sujet précédent, vous avez déjà vu la notion de cost_per_task — c’est le coût total d’un scénario réussi : de « l’utilisateur a commencé la sélection » à « il a reçu le résultat » (et a peut‑être payé quelque chose).

Il inclut :

• les dépenses LLM (tokens × price_per_token en entrée/sortie, incluant éventuellement les modèles de rerank, embeddings, etc.) ;
• la part des coûts d’infrastructure par tâche (serveurs, base de données, files, passerelle MCP) — souvent calculée à partir de données agrégées ;
• facultatif — les frais de transaction (frais Stripe, contrôles anti‑fraude), si vous comptez le cost_per_task jusqu’à « l’argent net ».

L’idée est simple : le prix d’un scénario ou d’un abonnement doit être supérieur au coût moyen d’un scénario, multiplié par une « marge de sécurité ».

En simplifiant beaucoup :

price_per_task >= cost_per_task * ( 1 + margin )

Nous n’allons pas saturer ce cours de chiffres et de marges en pourcentage, retenez surtout la règle intuitive.

Exemple pour GiftGenius

Supposons que vous ayez déjà mis en place la journalisation des coûts du cours précédent, et que vous disposiez d’un rapport agrégé :

• cost_per_task moyen (une sélection de cadeau terminée) = 0,15 USD ;
• il inclut déjà les tokens LLM (plusieurs appels à suggest_gifts, rerank et résumé final) et la part d’infrastructure.

Ensuite, vous examinez le scénario :

• un utilisateur gratuit fait une sélection, achète parfois un bon de 50 $ ;
• la conversion en achat parmi les sélections terminées est, disons, de 5 %.

Sans entrer dans une unit economics complète, on peut déjà estimer : si sur 100 sélections :

• vous dépensez 100 × 0,15 $ = 15 $ ;
• 5 se terminent par un checkout à 50 $ ;
• le revenu est de 5 × 50 $ = 250 $.

Ça paraît bien : grossièrement (250 $ – 15 $), plus les commissions Stripe, les taxes et autres « joies ». Mais il faut comprendre qu’avec un abonnement trop généreux (par exemple, 100 sélections pour 1 $), vous basculez facilement dans le négatif.

Mini‑exemple de code : sauvegarder cost_per_task en TypeScript

Supposons que vous ayez un outil MCP qui termine le workflow de sélection et connaît son coût total :

// Type pour les métriques finales d’un scénario
type TaskMetrics = {
  taskId: string;
  userId: string;
  costPerTaskUsd: number;
  modelName: string;
  completedAt: string;
};

// Fonction fictive de journalisation de métriques
async function logTaskMetrics(metrics: TaskMetrics) {
  console.log(JSON.stringify({ 
    level: "info",
    event: "workflow_completed",
    ...metrics,
  }));
}

// Quelque part dans le gestionnaire de fin de sélection :
await logTaskMetrics({
  taskId: context.taskId,
  userId: context.userId,
  costPerTaskUsd: context.costEstimateUsd, // calculé à partir des tokens
  modelName: context.modelName,
  completedAt: new Date().toISOString(),
});

Un tel log est ensuite facile à agréger dans un dashboard pour voir la distribution du cost_per_task par modèles, utilisateurs et scénarios.

4. Pricing : comment convertir cost_per_task en prix réels

Maintenant que nous avons un cost_per_task, il faut décider quoi facturer et combien facturer à l’utilisateur.

Règle simple pour le B2C

Pour le B2C, on peut choisir une règle empirique :

« Nous sommes prêts à dépenser pour LLM+infra au plus X % du revenu. »

Par exemple, vous décidez de ne pas dépenser plus de 20 % du chiffre d’affaires en coûts LLM. Alors :

• si le cost_per_task = 0,15 USD, le prix minimal pour un scénario payant doit être ≈ 0,75 $, pour que 0,15 soit environ 20 % de 0,75 ;
• si vous vendez un abonnement, estimez combien de scénarios moyens reviennent à un abonné par mois, et multipliez.

Il est tout à fait normal de commencer « à vue », puis d’ajuster les prix quand vous aurez des données réelles (spoiler : elles ne viendront pas tout de suite).

Règle simple pour le B2B

En B2B, on regarde généralement :

• cost_per_user_per_month ou cost_per_tenant_per_month ;
• la volonté de payer de l’entreprise (l’ampleur du problème que vous résolvez).

Par exemple, si une équipe RH distribue des cadeaux pour des dizaines de milliers de dollars par an via GiftGenius, un abonnement à 99 $ / mois est modeste, même si vos coûts LLM pour cette équipe ne sont que de 10 $ / mois. L’essentiel — comprendre que vous ne voulez pas vous retrouver avec un cost_per_tenant = 80 $ et un abonnement à 50 $.

Et oui, cela arrive si l’on se dit « nous sommes de l’IA, mettons tout gratuit pour l’instant, on verra plus tard ».

Petite fonction « garde‑fou » côté serveur

Vous pouvez avoir dans le code un simple « guard » qui vous alerte si le coût sort d’une plage raisonnable pour un prix donné :

function checkPricingSafety(params: {
  avgCostPerTaskUsd: number;
  plannedPricePerTaskUsd: number;
  maxCostShare: number; // par exemple, 0.3 = 30%
}): boolean {
  const share = params.avgCostPerTaskUsd / params.plannedPricePerTaskUsd;
  return share <= params.maxCostShare;
}

// Exemple :
checkPricingSafety({
  avgCostPerTaskUsd: 0.15,
  plannedPricePerTaskUsd: 0.75,
  maxCostShare: 0.3,
}); // true — ok, 20% < 30%

Ce n’est pas un modèle financier, mais cela donne une vérification rapide de bon sens, surtout lorsque vous expérimentez avec les prix.

5. Expériences « modèle / agent vs coût et conversion »

Passons maintenant au plus intéressant : les expériences A/B.

Intuition simple :

• Variante A — modèle coûteux / workflow plus complexe ;
• Variante B — modèle bon marché / workflow simplifié ;
• nous voulons comprendre l’impact simultané sur :
  • cost_per_task,
  • la qualité du résultat (ressenti utilisateur et futures évaluations par LLM),
  • les métriques business (conversion, revenu).

Sur quoi expérimenter précisément

Il y a trois axes principaux d’expérimentation :

1. Modèle.
   Par exemple, GPT‑5 vs GPT‑5‑mini, ou une autre gamme. En général, un modèle cher donne une meilleure qualité et un cost_per_task plus élevé, un modèle bon marché — l’inverse.
2. Logique d’agent / prompts.
   Plus d’étapes, prompts longs, raisonnement complexe — plus qualitatif mais plus cher ; logique minimaliste — moins cher et parfois presque aussi bon.
3. Format UX.
   Un assistant détaillé avec de nombreux champs et aides vs un mode inline rapide. Même modèle, mais le nombre de tokens et d’étapes peut varier fortement.

Vous pouvez déjà implémenter toutes ces variations, l’important est de les envelopper en expériences avec journalisation.

Quelles données journaliser pour les expériences

Au‑delà des champs que vous journalisez pour les coûts (tokens, model, cost_estimate, user_id, request_id, etc.), ajoutez des champs d’expérience :

• experiment_id — identifiant unique de l’expérience (par exemple, "gift_model_ab_2025_11").
• variant — la branche pour l’utilisateur : "A", "B", "control", "treatment", etc.
• model_name ou agent_version — pour ne pas oublier la configuration utilisée.
• le résultat du scénario :
  • y a‑t‑il eu workflow_completed ;
  • y a‑t‑il eu checkout_success ;
  • le cost_per_task final.
• facultatif — quality_score (nous y reviendrons plus tard, c’est le pont vers le module sur les LLM‑evals).

Exemple de log JSON d’un événement d’expérience

Un log d’événement typique peut ressembler à ceci :

{
  "level": "info",
  "timestamp": "2025-11-21T20:15:03.123Z",
  "event": "experiment_task_result",
  "experiment_id": "gift_model_ab_2025_11",
  "variant": "A",
  "user_id": "user_123",
  "task_id": "task_456",
  "model_name": "gpt-5.2",
  "workflow_completed": true,
  "checkout_success": false,
  "cost_per_task_usd": 0.18,
  "quality_score": null,
  "request_id": "req_abc",
  "trace_id": "trace_xyz"
}

De tels enregistrements s’agrègent très bien dans n’importe quelle analytique : on peut construire des tableaux « variant A vs B par coût/conversion/revenu ».

Exemple de code : journaliser une expérience dans un MCP‑tool

Imaginons que votre serveur MCP ait déjà calculé le coût du scénario (cost_per_task) et sache dans quelle branche d’expérience se trouve l’utilisateur :

type ExperimentContext = {
  experimentId: string;
  variant: "A" | "B";
};

async function logExperimentResult(params: {
  ctx: ExperimentContext;
  userId: string;
  taskId: string;
  modelName: string;
  costPerTaskUsd: number;
  workflowCompleted: boolean;
  checkoutSuccess: boolean;
}) {
  const event = {
    level: "info" as const,
    event: "experiment_task_result",
    timestamp: new Date().toISOString(),
    experiment_id: params.ctx.experimentId,
    variant: params.ctx.variant,
    user_id: params.userId,
    task_id: params.taskId,
    model_name: params.modelName,
    cost_per_task_usd: params.costPerTaskUsd,
    workflow_completed: params.workflowCompleted,
    checkout_success: params.checkoutSuccess,
  };

  console.log(JSON.stringify(event));
}

Plus haut, vous décidez à quelle variante appartient l’utilisateur (selon user_id, tenant_id ou aléatoirement), et vous passez le ExperimentContext au gestionnaire de workflow. À ce stade, nous avons fixé quoi et comment journaliser pour les expériences : quels champs et où les écrire. Ensuite, voyons comment transformer ces expériences en hypothèses produit compréhensibles et décisions de pricing, plutôt qu’en simple amas de logs.

6. Un mot sur le quality_score et les LLM‑evals

J’en parlerai en détail dans le module 20, et pour l’instant, retenez l’idée : le quality_score est une évaluation de la qualité de la réponse/solution sur une échelle, par exemple de 0 à 10, souvent par un modèle LLM « juge » distinct. Plus de détails sur le LLM‑as‑judge dans le module 20.

Nous n’avons pas besoin des détails d’implémentation maintenant — ce sera le sujet du module suivant — mais il est important de comprendre le concept :

• en plus de l’argent, nous voulons mesurer la qualité ;
• nous pouvons demander à un humain ou à un second modèle d’évaluer : « à quel point GiftGenius a‑t‑il bien choisi un cadeau sur une échelle de 0 à 10 ? » ;
• ensuite, nous pouvons observer comment le quality_score est corrélé avec :
  • la conversion en achat ;
  • la rétention des utilisateurs ;
  • la disposition à payer (willingness‑to‑pay).

Du point de vue des logs, ce n’est qu’un champ de plus :

type ExperimentResultEvent = {
  experiment_id: string;
  variant: string;
  user_id: string;
  task_id: string;
  cost_per_task_usd: number;
  quality_score?: number; // 0-10, peut être undefined
};

Nous nous arrêterons là pour aujourd’hui : les détails des LLM‑evals, des « golden cases » et du « LLM‑as‑judge » viendront plus tard dans le cours. Pour l’instant, il suffit de savoir où insérer ce score dans les expériences. C’est précisément le quality_score qui empêche l’erreur classique d’optimiser « uniquement le coût » : il permet de voir numériquement quand nous avons trop bradé le scénario, perdu en qualité, et avec elle — conversion et revenu.

7. Exploiter les expériences pour le pricing et la monétisation

À présent, nous ne faisons pas que journaliser des expériences, nous les formalisons en hypothèses business claires avec des métriques de succès et un impact sur la monétisation. Simplement journaliser un experiment_id ne suffit pas : il faut formaliser les changements produit en hypothèses avec une métrique de succès explicite.

Exemple d’hypothèse : modèle cher vs modèle bon marché

Imaginons une telle expérience pour GiftGenius :

• Variante A — modèle cher (GPT‑5), raisonnement riche, assistant détaillé.
• Variante B — modèle bon marché (GPT‑5‑mini), prompt un peu plus simple et conversation plus courte.

Hypothèse : remplacer par le modèle bon marché réduira le cost_per_task d’au moins 50 %. En même temps, la qualité côté utilisateur et l’évaluation LLM (notre quality_score) baissera de 5–10 % au maximum, et la conversion en achat ne chutera pas.

Techniquement, pour chaque tâche vous journalisez les mêmes champs qu’en section 5.2 :

• experiment_id = "gift_model_ab_2025_11" ;
• variant = "A" ou "B" ;
• model_name ;
• cost_per_task_usd ;
• workflow_completed ;
• checkout_success ;
• quality_score (lorsque les LLM‑evals seront en place).

Après une ou deux semaines, vous pouvez :

• calculer le cost_per_task moyen pour A et B ;
• comparer le checkout‑rate (part des scénarios avec paiement réussi) ;
• comparer le quality_score moyen, s’il existe.

Si B perd peu en qualité mais coûte deux fois moins, vous pouvez soit :

• passer à B et augmenter la marge ;
• ou conserver le prix mais baisser le prix d’abonnement pour l’utilisateur (et ainsi stimuler la croissance).

Exemple d’hypothèse : un upsell qualitatif

Autre hypothèse : si, après 3 idées gratuites, on affiche un upsell premium « rapport complet sur les cadeaux + recommandations pour le texte de la carte » à 4,99 $, la conversion en achat augmente d’au moins 2 points de pourcentage (2 p.p.). Dans le même temps, le cost_per_task n’augmente pas de plus de 0,05 $.

Ici, l’expérience porte moins sur le modèle que sur l’UX et la logique produit. Mais techniquement, c’est la même chose :

• différentes variantes d’UX via variant ;
• journalisation du coût et du revenu par scénario ;
• analyse de l’uplift (dans quelle mesure la nouvelle logique a généré plus d’argent sans faire exploser les coûts).

Exemple de code : enregistrer un revenu simple par tâche

Il est parfois pratique d’écrire le revenu du scénario à côté du coût :

type RevenueEvent = {
  taskId: string;
  userId: string;
  experimentId?: string;
  variant?: string;
  revenueUsd: number;
  checkoutSuccess: boolean;
};

async function logRevenue(event: RevenueEvent) {
  console.log(JSON.stringify({
    level: "info",
    event: "task_revenue",
    timestamp: new Date().toISOString(),
    ...event,
  }));
}

En reliant ensuite task_revenue et experiment_task_result par le taskId, on peut calculer pour chaque variante :

• le revenue_per_task moyen ;
• le cost_per_task moyen ;
• et construire un ROI simple.

8. Exercice pratique : expérience A/B pour GiftGenius

Pour ancrer la théorie dans la pratique, détaillons à quoi ressemblerait une expérience « modèle cher vs modèle bon marché » pour GiftGenius — étape par étape, au format exercice.

Ce que nous changeons

• Variante A :
  • modèle gpt-5 ;
  • system prompt plus détaillé et étapes d’agent plus riches ;
  • éventuellement plus d’appels de raisonnement intermédiaires.
• Variante B :
  • modèle gpt-5-mini ;
  • prompt légèrement plus compact ;
  • moins d’appels d’outils auxiliaires, flux simplifié.

Comment répartir les utilisateurs par branche

La méthode la plus simple — via un hash de user_id :

function assignVariant(userId: string): "A" | "B" {
  const hash = Array.from(userId).reduce((acc, ch) => acc + ch.charCodeAt(0), 0);
  return hash % 2 === 0 ? "A" : "B";
}

Cela garantit une répartition à peu près uniforme, et un même utilisateur tombe toujours dans la même branche.

Ce que nous journalisons

À la fin du workflow de sélection, vous journalisez le même ensemble de champs que dans les sections précédentes (5.2 et 7.1), et vous ajoutez le revenu :

• experiment_id = "gift_model_ab_2025_11" ;
• variant de la fonction ci‑dessus ;
• model_name, le modèle réellement utilisé ;
• cost_per_task_usd, le coût total des tokens et de l’infrastructure ;
• workflow_completed (true/false) ;
• checkout_success (true/false) ;
• revenue_usd (0 ou le montant de l’achat).

Optionnellement (un peu plus tard dans le cours), on ajoutera le quality_score.

Ces données alimentent ensuite vos logs/analyses, où elles peuvent être agrégées en tableaux :

Un tel tableau montre que B rapporte presque autant avec un coût deux fois moindre — un argument fort en sa faveur.

9. Schéma visuel : à quoi ressemble la boucle « coût ↔ qualité ↔ monétisation »

Pour rassembler le tout, traçons un petit schéma « les données circulent » :

flowchart TD
    U[Utilisateur dans ChatGPT] --> A["App ChatGPT (GiftGenius)"]
    A --> E[Module d’expérimentation
assigne la variante A/B]
    E --> AG[Agent / MCP tools
avec des modèles différents]
    AG -->|Appels LLM| L[Logs d’usage & de coût]
    AG -->|Résultats de sélection| UI[Widget / réponse de chat]
    UI -->|comportement : clics, achats| BE[Backend commerce]

    L --> M[Métriques : cost_per_task,
cost_per_user]
    BE --> M
    M --> D[Dashboard de pricing & d’expériences]

    subgraph "Module 20 à venir"
      J[LLM-juge
quality_score]
      J --> M
    end

Vous êtes exactement au milieu de ce schéma : vous savez journaliser les coûts et le revenu, et vous ajoutez par‑dessus des expériences et du pricing. Dans le module suivant arrivera le thème Juge Dredd (LLM-juge).

10. Erreurs typiques en travaillant la monétisation et les expériences

Avec une vision d’ensemble, il est plus facile de voir où ça casse en général. Voici une liste d’erreurs courantes, utile comme check‑list pour travailler la monétisation et les expériences de coût.

Erreur n° 1 : optimiser uniquement le coût en oubliant la qualité.
Scénario fréquent : vous passez à un modèle moins cher, vous voyez que la facture OpenAI est plus agréable, et vous proclamez la victoire. Puis, un mois plus tard, vous constatez que les utilisateurs achètent moins souvent des bons cadeaux, reviennent moins, et que le support reçoit « on m’a proposé n’importe quoi ». Sans journaliser le quality_score, ni même des proxys (clics sur les idées, sauvegardes, conversions), on tombe facilement dans le mode « peu cher mais inutile ».

Erreur n° 2 : calculer le cost_per_task uniquement pour le LLM, en ignorant l’infrastructure et les paiements.
Parfois, les développeurs comptent consciencieusement les tokens mais oublient Redis, les files, les API tierces, les frais Stripe, etc. Le cost_per_task est alors fortement sous‑estimé, et les prix paraissent plus confortables qu’ils ne le sont. L’infrastructure se calcule souvent à partir de données agrégées, mais sa part doit rester dans le coût d’un scénario.

Erreur n° 3 : changer de modèles/UX sans experiment_id et variant explicites.
« On a un peu réécrit le prompt, ça semble mieux » — un mois après, personne ne se souvient quand c’était, sur quelles données c’était basé, ni ce que ça a donné. Sans marquage explicite des expériences dans les logs (experiment_id, variant) et liaison à des releases concrètes, il est difficile d’analyser en rétrospective et de prouver que les améliorations ne sont pas du hasard.

Erreur n° 4 : décider avec trop peu de données ou trop tôt.
Si l’expérience tourne deux jours et que vous décidez, sur la base de dix paiements, que le modèle B est « bien plus rentable », c’est l’exemple classique d’une conclusion bruitée. Il faut un horizon minimal — une semaine, idéalement plus — et un volume suffisant de scénarios pour comparer moyennes et conversions. Nous n’entrons pas dans la statistique ici, mais gardez la règle « ne concluez pas sur 5 événements ».

Erreur n° 5 : utiliser un pricing complexe sans règle mentale simple.
Vous pouvez dessiner un plan tarifaire à trois niveaux, des prix dans différentes devises et des remises par code de parrainage, mais ne pas avoir de règle produit simple du type « nous ne dépensons pas plus de X % du revenu en coûts LLM » ou « le prix d’un scénario ne doit pas descendre sous 3× le cost_per_task moyen ». Sans ces garde‑fous, on perd facilement la marge et on s’en rend compte trop tard.

Erreur n° 6 : oublier le lien entre monétisation, marketing et croissance.
La monétisation et le pricing ne vivent pas en vase clos : plus l’abonnement est cher, plus le churn est élevé et la conversion faible ; plus le prix est bas, plus les exigences d’optimisation de coût sont fortes. L’erreur est de ne regarder que « combien nous gagnons maintenant » sans relier cela aux métriques d’acquisition/activation/rétention, que nous verrons au prochain sujet du module. Les expériences de pricing devraient être journalisées dans le même cadre que celles de qualité et de coût, pour voir l’ensemble.