Modélisation économique de l’IA : ce que le product manager doit chiffrer avant le prototype

Facturée 0,40 € pour un coût de service de 0,09 €, une facture saisie automatiquement laisse 77 % de marge à l’éditeur de l’outil. Ajoutez une étape de vérification qui triple les tokens, et la marge recule à 0,25 €. Perdez deux tiers du volume prévu, et elle tombe à 0,21 €. Aucun de ces glissements ne se voit dans la démonstration, ni même dans le pilote.

Les chiffres viennent de l’exemple développé plus bas, et ils sont hypothétiques. Le mécanisme, lui, se retrouve dans presque tous les produits d’IA vendus à l’usage.

Pour un product manager, la leçon est économique. Un produit d’IA peut gagner en précision et perdre de l’argent, parce que chaque amélioration se paie en latence, en calcul et en maintenance. La taille de marché, la segmentation, le prix et la rétention restent utiles. Ils ne suffisent plus.

Avec l’IA, les coûts varient avec l’usage et les résultats ne sont jamais garantis. Tout dépend des données, le modèle doit sans cesse être amélioré et il faut fixer des règles de contrôle. La question « qui paiera pour cette fonctionnalité ? » devient trop étroite. Il faut savoir comment une capacité crée de la valeur, à quel coût, avec quelle fiabilité, et à quelles conditions elle reste défendable à l’échelle.

Le PM d’un produit d’IA doit donc tenir ensemble la stratégie, les données, le comportement du modèle, la mesure, les tests, les coûts et le prix. C’est beaucoup, et c’est pourquoi tant de projets brillent au stade du prototype puis faiblissent quand il faut les déployer pour de bon. Un modèle brillant sans données fiables, sans évaluation et sans maîtrise des coûts ne fait pas une activité. Un modèle imparfait, bien encadré et bien intégré, peut en faire une.

Un cas d’usage IA se qualifie par sa fréquence, son impact et ses données

L’erreur la plus fréquente consiste à démarrer par la technologie. L’équipe débat du fournisseur, du RAG (génération augmentée par recherche documentaire), d’un éventuel ajustement fin, d’un copilote ou d’un agent. Ces questions sont légitimes. Elles arrivent trop tôt tant que le problème n’est pas clarifié.

Les bons cas d’usage se ressemblent. Il s’agit de trier, prévoir ou classer de gros volumes. Ou de traiter des textes, des images et des documents libres que les systèmes à règles gèrent mal. Ou encore de personnaliser pour beaucoup d’utilisateurs, ou d’aider à décider quand l’issue est incertaine.

Trois conditions sont à vérifier avant d’investir. La fréquence : sans elle, l’automatisation ne se rentabilise pas. L’impact métier : sans lui, l’effet reste cosmétique. Les données : sans elles, le modèle n’a pas de base solide.

Exemple chiffré (illustratif). Un cabinet d’expertise comptable de taille moyenne saisit 3 000 factures fournisseurs par mois. Chaque saisie prend 4 minutes à un collaborateur dont le coût chargé avoisine 36 € de l’heure, soit 2,40 € par facture et 7 200 € par mois. Le problème est fréquent, coûteux et riche en données : chaque facture déjà saisie est un exemple étiqueté.

Le même cabinet reçoit aussi une dizaine de demandes de rescrit fiscal par an. Le sujet est plus prestigieux, l’enjeu par dossier plus élevé. Mais dix cas par an ne paient ni l’évaluation ni la maintenance d’un modèle.

Une règle simple tranche entre les deux. On multiplie la fréquence annuelle par la valeur gagnée par cas, puis on compare au coût annuel de maintien du système. Pour la saisie des factures : 36 000 factures par an × 1,80 € = 64 800 €. Pour le rescrit : même avec 500 € gagnés par dossier, 10 dossiers rapportent 5 000 €.

Si le maintien coûte 18 000 € par an (1 500 € par mois), le premier cas couvre ce coût plus de trois fois, le second n’en couvre pas le tiers. Le rescrit reste un bon candidat pour un outil de recherche documentaire générique, acheté plutôt que construit.

Ce filtre évite deux dérives. La première consiste à chercher où mettre de l’IA après avoir décidé d’en faire. La seconde consiste à confondre une démonstration séduisante avec une opportunité économique. La faisabilité technique n’est qu’un prérequis : un bon cas d’usage améliore une variable économique importante, de façon crédible et répétable.

La valeur se mesure dans l’unité que suit le client

Avant le prix, il faut savoir ce que l’IA apporte exactement. Beaucoup d’équipes parlent d’« intelligence », de « personnalisation » ou de « gain de productivité » sans qualifier la valeur produite.

En pratique, l’IA crée de la valeur de six manières. Elle réduit des coûts en comprimant du travail manuel. Elle accélère un circuit de travail et augmente le débit. Elle réduit des erreurs coûteuses. Elle détecte plus tôt des risques ou des anomalies. Elle rend l’expérience plus fluide et plus pertinente. Elle ouvre des usages nouveaux, comme la génération assistée.

Ces six leviers n’ont pas le même poids. Le PM doit trouver celui qui porte réellement le produit, car il décidera des métriques suivies, des expériences menées et de la monétisation.

Dans le cabinet de l’exemple, le levier est clair : le temps de saisie. Si l’outil ramène la saisie à 1 minute, le cabinet économise 1,80 € par facture, soit 5 400 € par mois. La métrique de valeur est la facture saisie.

Le prix découle de cette économie. Facturer 0,40 € par facture revient à capter 22 % du gain (0,40 / 1,80). Plus la part captée monte, plus le client compare l’outil à d’autres options, comme un renfort temporaire en période fiscale. Garder la majorité du gain chez le client rend l’achat facile à défendre en interne.

La valeur perçue ne suit pas la sophistication technique. Un modèle plus coûteux ne crée pas toujours plus de valeur. Un système simple, bien intégré à un circuit critique, peut rapporter beaucoup. Le PM distingue donc trois choses : la valeur technique, la valeur perçue et la valeur économique. Le modèle économique se construit dans la traduction de l’une à l’autre.

La longueur de contexte illustre ce piège. Ajouter des documents au prompt semble enrichir la réponse. Liu et ses coauteurs ont pourtant montré en 2023 (« Lost in the Middle ») que les modèles exploitent mal l’information placée au milieu d’un long contexte. On paie plus de tokens pour une réponse qui ne s’améliore pas forcément.

La défense d’un produit d’IA se construit en couches autour du modèle

Croire que la différenciation vient du choix du modèle résiste mal à l’épreuve. Les modèles de fondation se banalisent, les performances convergent, les API se rapprochent sans devenir interchangeables. Ce qui protège un produit, c’est le système difficile à copier que l’équipe construit autour.

Dans un système d’IA en production, le code qui appelle le modèle n’est qu’une petite partie de l’ensemble. Le reste (collecte des données, réglages, surveillance, mise à disposition des réponses) fait à la fois la valeur et la dette technique.

Le système défendable tient en quatre couches, qui servent aussi de carte des capacités :

1. La couche données : la circulation et le stockage des données, leur préparation pour la recherche et leur annotation par des humains.
2. La couche modèle : les grands modèles, les modèles ajustés, la recherche dans les documents propres (RAG) et les tests de qualité.
3. La couche orchestration : les instructions (prompts), le choix du modèle pour chaque requête, les agents, la gestion du contexte et les solutions de repli.
4. La couche expérience : copilotes, automatisations, recommandations, tableaux de bord, interfaces conversationnelles.

Le cabinet montre comment la couche données s’accumule. Chaque facture corrigée par un collaborateur devient un exemple étiqueté. Au rythme de 3 000 factures par mois, cela fait 36 000 exemples en un an, propres à ce cabinet et à ses fournisseurs. Un concurrent qui arrive plus tard dispose du même modèle de fondation, pas de cet historique.

Aucune couche ne suffit seule. Le fossé défensif tient à leur accumulation coordonnée. Une évaluation robuste, des données mieux structurées, un meilleur routage ou une meilleure solution de repli peuvent valoir plus qu’une interface spectaculaire.

La carte sert à rendre visibles les liens entre capacité, valeur et coût. Chaque capacité a une promesse utilisateur, une contrainte technique, une charge d’exploitation et une exigence d’évaluation. Chaque arbitrage se chiffre avant d’être tranché : RAG ou ajustement fin, petit ou grand modèle, cache ou inférence à la volée. Trois colonnes suffisent souvent : coût par requête, latence attendue, part des requêtes qui finissent en repli.

Cette carte change l’ordre de construction. En produit classique, on priorise des fonctionnalités. En IA, une fonctionnalité facile à raconter masque souvent la vraie limite, logée dans les données, l’évaluation ou l’orchestration. L’unité de priorisation devient la capacité.

Six questions de diagnostic, à poser pour chaque capacité :

• L’adéquation entre problème et modèle est-elle assez forte ?
• Les données sont-elles disponibles, propres et assez riches ?
• Les exigences de latence et de précision sont-elles réalistes ?
• Les dépendances techniques sont-elles absorbables ?
• Les risques de gouvernance restent-ils contrôlables ?
• La capacité est-elle viable au coût par tâche visé ?

Une fonctionnalité désirable adossée à une capacité trop chère ou trop instable reste un pari perdu. Mieux vaut d’abord rendre la capacité moins chère ou plus stable. À l’inverse, une capacité peu visible mais réutilisable peut accélérer plusieurs lignes de produits. Le PM doit alors savoir quand la traiter comme un actif de plateforme plutôt que comme un élément local de la feuille de route.

Mesurer l’utilisateur et le modèle dans la même lecture

Avec l’IA, la performance dépend à la fois de l’utilisateur et du modèle. Un modèle qui dérive peut laisser l’activation intacte pendant des semaines alors que la qualité des réponses baisse déjà. Seule une lecture conjointe des deux séries le révèle à temps.

Le logiciel classique réagit toujours de la même façon. Un modèle, lui, dérive. Sa qualité varie avec le contexte, les demandes reçues changent et les coûts suivent l’usage. En production, le modèle voit des données qui ne ressemblent plus à celles de son entraînement.

L’instrumentation commence par un journal par tâche. Six champs suffisent pour tout recalculer plus tard : identifiant de tâche, version du modèle et du prompt, tokens en entrée et en sortie, latence, déclenchement ou non du repli, correction faite par l’utilisateur. Ils tiennent dans une table de journalisation ordinaire. Sans ces champs, la marge par tâche reste une estimation.

Côté utilisateur, on suit l’activation, l’intensité d’usage, les tâches menées à bout, le temps économisé et la rétention. Côté modèle, on suit la part de bonnes réponses, la part des cas trouvés, la pertinence, les réponses inventées, le temps de réponse, le coût de calcul et les signes de dérive. Le PM ne laisse pas ces indicateurs aux seules équipes techniques : il les traduit en expérience, en coût et en risque.

Un indicateur relie les deux mondes : le coût par tâche réussie. Il se calcule en divisant le coût de service par le taux de réussite. À 0,09 € par tâche et 90 % de réussite, une tâche réussie coûte 0,10 €. Si la réussite tombe à 60 % après une dérive, elle coûte 0,15 €, sans qu’aucune ligne de la facture du fournisseur ait bougé.

L’évaluation automatique a ses propres biais. Un LLM utilisé comme juge favorise par exemple les réponses longues ou celles qu’on lui présente en premier (Zheng et coauteurs, NeurIPS 2023). Pour le cabinet, le juge se calibre donc chaque mois sur un échantillon de factures vérifiées à la main par un collaborateur.

Les tests, ensuite, vont plus loin que le choix d’une interface. Ils vérifient que le modèle tient la route, qu’il est sûr, ce qu’il coûte et comment il se comporte quand la charge monte. Les tests sur données passées éliminent les candidats faibles. Les tests avec de vrais utilisateurs montrent ce que l’historique cache : nouveaux comportements, cas rares, dérive, charge réelle et lien entre coût et qualité.

Les attentes doivent rester modestes. La plupart des variantes testées ne battent pas la version en place, et sur 10 variantes d’un assistant, en voir une ou deux gagner est déjà un bon résultat. Il faut le savoir avant de promettre un calendrier au comité produit.

La durée compte aussi. Hohnhold et ses coauteurs ont montré chez Google (KDD 2015) que l’effet d’un changement mesuré sur quelques semaines peut différer de son effet à long terme, parce que les utilisateurs apprennent et s’adaptent. Pour un assistant, l’effet de nouveauté gonfle l’usage du premier mois ; la vraie mesure vient ensuite.

Les garde-fous prennent ici une place centrale : combien de réponses inventées on tolère, quels contenus sont interdits, à partir de quel taux d’échec on arrête, quand on passe à la solution de repli, quel niveau de confiance minimum on exige. Ils protègent la marque, réduisent le risque réglementaire et évitent qu’un gain apparent devienne une dette d’exploitation.

La rigueur statistique fait le reste : taille d’échantillon et durée se fixent avant le lancement, et personne n’arrête le test au premier signal favorable. La variante gagnante doit enfin respecter ses plafonds de latence et de coût. Une préférence utilisateur bien mesurée ne dit pas encore si le système mérite d’entrer en production.

Le coût de service par tâche décide de la marge

L’IA introduit une différence décisive avec le SaaS classique : servir un utilisateur ne coûte pas un montant presque fixe. Le coût varie avec la taille du modèle, la quantité de texte envoyée, la fréquence des requêtes, le trafic, la réutilisation des réponses (cache) et le choix du modèle pour chaque requête. La modélisation financière se rapproche donc du design produit.

L’inférence n’est qu’une partie du tableau. Le cycle de vie du modèle coûte aussi : préparation des données, annotation, ajustement fin, évaluation, tests de non-régression, montée en charge, correction de la dérive. Ces coûts continus dépassent souvent le coût de l’intégration initiale. Un tableau mensuel par poste suffit pour démarrer, à condition que chaque ligne ait un responsable et une date de revue.

Décomposer le coût de service (formule)

coût de service par tâche
  = coût d’inférence par tâche
  + coût d’orchestration et de recherche documentaire
  + amortissement des coûts de cycle de vie

coût d’inférence par tâche
  = requêtes par tâche × (tokens moyens ÷ 1000) × prix pour 1000 tokens

marge de contribution par tâche
  = prix facturé par tâche moins coût de service par tâche

Chaque terme se lit simplement. Le coût d’inférence dépend du nombre d’appels qu’une tâche déclenche (recherche, raisonnement puis vérification), de la longueur moyenne des échanges et du tarif du modèle. L’orchestration ajoute les appels vectoriels et le routage. L’amortissement répartit sur les tâches les coûts récurrents, réentraînement, jeux d’évaluation, surveillance de la dérive, que le prix par requête ne montre pas.

Application au cabinet (montants HT). Une facture déclenche 3 requêtes de 2 500 tokens en moyenne, à 0,004 € les 1 000 tokens : 3 × 2,5 × 0,004 = 0,03 €. L’orchestration ajoute 0,01 €. Les coûts de cycle de vie, 1 500 € par mois, se répartissent sur 30 000 factures traitées pour l’ensemble des clients : 0,05 €. Le coût de service atteint 0,09 € par facture.

Facturée 0,40 € HT, la facture laisse 0,31 € de marge, soit 77 %. La marge est confortable tant que les hypothèses de volume et de tokens tiennent, et c’est précisément ce que la suite met à l’épreuve. Le cabinet paie 1 200 € HT par mois pour 3 000 factures et en économise 5 400 : il garde 4 200 €.

La formule montre aussi où la marge casse. Si l’équipe ajoute une étape de vérification qui triple les tokens, l’inférence passe à 0,09 € et la marge tombe à 0,25 €. Si le volume total n’atteint que 10 000 factures par mois, l’amortissement grimpe à 0,15 € et la marge à 0,21 €. Le volume compte autant que le modèle.

Deux leviers d’infrastructure jouent directement sur ces lignes. La mise en cache des prompts d’Anthropic facture les lectures de cache à 0,1 fois le prix normal. L’API Batch d’OpenAI accorde 50 % de remise pour un traitement livré sous 24 heures, ce qui convient à une saisie de factures faite la nuit.

Trois scénarios suffisent pour un comité produit, avec les mêmes hypothèses de prix :

• prudent : 10 000 factures par mois sur l’ensemble des clients, coût de service 0,19 €, marge 0,21 € (53 %) ;
• central : 30 000 factures, coût 0,09 €, marge 0,31 € (77 %) ;
• tension : 30 000 factures avec une étape de vérification qui triple les tokens et un fournisseur 20 % plus cher, coût d’environ 0,17 €, marge 0,23 € (58 %).

Le scénario prudent dit quelque chose d’utile : sous 10 000 tâches par mois, ce sont les coûts fixes de cycle de vie qui pèsent le plus, devant l’inférence.

Ce calcul a ses limites. Il suppose une facture moyenne, alors qu’une facture manuscrite peut coûter dix fois plus qu’une facture PDF propre. Il ne dit rien de la tolérance du cabinet aux erreurs. Si le taux d’erreur oblige à relire une facture sur trois, l’économie de 1,80 € par facture fond d’autant.

Tant que la marge par tâche reste positive quand le volume augmente, le prix tient. Pour le choisir, plusieurs options existent : tarification à l’usage, accès par paliers, prix fondé sur la valeur ou modèle hybride. Le bon choix dépend du lien entre coût et usage, de la clarté de la métrique de valeur et du type de client. Structure de coûts, structure de prix et hypothèse de retour sur investissement doivent tenir ensemble.

Les obligations réglementaires entrent dans ce coût. Les factures contiennent des données personnelles de fournisseurs indépendants, ce qui place la chaîne sous le RGPD et sous le regard de la CNIL. Former les collaborateurs et documenter les traitements sont des lignes du tableau de coûts.

Quelle couche renforcer en premier ?

Mis bout à bout, problème, valeur, couches, mesure, expérimentation et finance forment un circuit de décision. On définit le problème et la valeur, on vérifie les données, on cartographie les capacités, on fixe les critères d’évaluation, on expérimente, puis on modélise la finance et les scénarios. Reste l’alignement organisationnel entre produit, données, ML, ingénierie, gouvernance et exploitation. Sans lui, même un modèle prometteur devient ingouvernable.

Chaque indicateur gagne à avoir un seul responsable nommé :

• le product manager : métrique de valeur, marge par tâche, prix ;
• l’équipe ML : précision, dérive, coût d’inférence ;
• l’ingénierie : latence, disponibilité, taux de repli ;
• la conformité : traçabilité, registre des traitements, formation des équipes.

Les équipes qui démarrent opposent souvent un argument à tout ce dispositif : modéliser la marge par tâche avant d’avoir des utilisateurs serait prématuré, puisque les prix des modèles baissent de toute façon.

Avant l’adéquation produit-marché, elles ont souvent raison : mieux vaut apprendre vite avec un modèle trop cher que chiffrer finement un produit dont personne ne veut. L’argument tombe dès que l’usage croît plus vite que les prix ne baissent, ce qui arrive le jour où un client intègre l’outil à son circuit quotidien.

Le parcours revient rarement en ligne droite. Une modélisation financière qui ne tient pas renvoie à la carte des capacités, parfois jusqu’au choix du problème. L’incertitude ne disparaît pas, mais elle devient mesurable.

En production, quatre symptômes désignent la couche qui cède :

• les utilisateurs signalent des réponses fausses que les tableaux de bord n’ont pas vues : l’évaluation ;
• la qualité varie fortement d’un client à l’autre : souvent les données ;
• la latence ou le taux de repli grimpent avec la charge : l’orchestration ;
• la marge par tâche baisse quand le volume augmente : l’économie, avec la formule ci-dessus comme point de départ.

La couche au symptôme le plus coûteux passe devant les fonctionnalités de la feuille de route au trimestre suivant. La revue suivante dit si le symptôme a reculé. Une fois la couche renforcée, le diagnostic se refait, car un système probabiliste a toujours une couche plus faible que les autres.

La règle de décision tient en une ligne : une amélioration du modèle qui fait baisser la marge par tâche n’est pas livrée tant que le prix ou le coût n’ont pas bougé.