0,009 dollar par requête la première année, 0,021 la deuxième, pour le même produit vendu au même prix. En IA, la difficulté d’un modèle économique ne vient pas du modèle lui-même. Elle vient d’un coût que le logiciel classique ne connaissait pas. Chaque réponse livrée coûte quelque chose : un appel au modèle, une recherche dans les documents, parfois un réentraînement ou une personne qui relit une réponse douteuse.
Dans un SaaS, servir un client de plus ne coûte presque rien. Avec l’IA, ce coût reste nettement au-dessus de zéro. Il a même tendance à monter quand le produit s’améliore. Une meilleure réponse demande plus de contexte, plus d’étapes et plus de tokens, ces morceaux de texte que le fournisseur facture.
Un éditeur français a en plus deux contraintes que les modèles de business plan venus des États-Unis oublient. Il paie ses coûts en dollars et encaisse ses prix en euros. Et il vend à des acheteurs publics ou régulés qui imposent leurs propres règles d’hébergement.
Stratégie, architecture, prix, coûts, données et validation ne sont pas des chapitres séparés. Chacun limite les autres. La stratégie décide quoi construire. L’architecture décide ce que cela coûte à faire tourner. Et le prix ne peut se fixer qu’ensuite. Si vous inversez cet ordre, vous devrez revoir vos tarifs après coup, quand tous vos tableaux reposent déjà sur l’ancienne hypothèse.
La valeur se facture à trois niveaux
Une proposition de valeur tient en une phrase. Un système de valeur, lui, décrit d’où vient vraiment l’argent, et il se lit sur trois niveaux. Le premier est la tâche brute que le modèle fait à la place d’une personne : résumer, prévoir, classer, chercher. Le deuxième rend un travail existant plus rapide et plus précis, avec moins d’effort. Le troisième crée ce qui était impossible avant, par exemple un assistant qui prépare seul une décision.
La plupart des entreprises qui durent font payer le deuxième et le troisième niveau, même si la démo montre le premier. Une capacité brute se copie vite. Un outil bien intégré au travail se copie mal. Savoir quel niveau vous facturez évite bien des erreurs de prix.
Un cas français rend la différence concrète. Avec la réforme de la facturation électronique, toutes les entreprises doivent pouvoir recevoir des factures électroniques depuis le 1er septembre 2026. Les grandes entreprises et les ETI doivent aussi en émettre. Les PME et les microentreprises devront en émettre à partir du 1er septembre 2027. Toutes passent par des plateformes agréées.
Prenons un éditeur qui vend aux cabinets d’expertise comptable. Lire les champs d’une facture relève du premier niveau : n’importe quel concurrent l’achète par API. Rapprocher chaque facture reçue de la commande et du relevé bancaire, puis ne signaler au collaborateur que les anomalies, relève du deuxième. Préparer pour l’expert-comptable une revue de fin de mois qui explique les écarts de TVA, c’est le troisième. Le cabinet paie volontiers pour les deux derniers, beaucoup moins pour le premier.
Reste à savoir ce qui protège ces niveaux. Les modèles seuls font peu la différence ; ce sont les systèmes qui distinguent un produit. Ce qui protège, c’est ce qui s’accumule avec le temps et qu’un concurrent ne peut pas monter en un week-end. Des données propres qui grossissent avec l’usage. Un modèle ajusté sur des données que personne d’autre n’a. Des tests assez solides pour livrer sans casser. Et un outil si bien intégré au travail de l’équipe que changer d’outil reviendrait à la reformer.
Un avantage durable, ce que les investisseurs appellent un « moat », peut aussi venir de la maîtrise de la distribution, de la confiance qu’exige un acheteur régulé ou d’une plateforme sur laquelle d’autres construisent.
En France, la distribution passe souvent par des prescripteurs plutôt que par la vente directe : experts-comptables, intégrateurs, éditeurs de logiciels métier déjà installés chez le client. Un partenariat avec ces réseaux vaut parfois plus qu’un meilleur modèle.
Le test reste simple. Si demain un concurrent bien financé copiait vos prompts et appelait le même modèle de base, que lui resterait-il de difficile ? Si la réponse est « rien », votre avantage est dans la roadmap, pas dans le produit.
Traduire la stratégie en pile de capacités
Un produit d’IA repose sur quatre couches. Chacune a son coût et ses pannes typiques. La couche données regroupe tout ce qui collecte, range, annote et contrôle les données. C’est elle qui avale l’essentiel de la dépense courante, souvent sans qu’on le remarque.
La couche modèle comprend les modèles loués par API, les versions ajustées sur vos données et les montages qui cherchent d’abord dans des documents avant de répondre. C’est elle qui fixe le coût minimal de chaque appel. La couche d’orchestration décide comment le produit enchaîne les appels. Quelles instructions donner, quel modèle pour quelle demande, que faire en cas d’échec, comment vérifier la réponse. Ici, un seul choix de conception peut multiplier la consommation de tokens sans que personne ne le voie.
La couche expérience, enfin, est la seule que le client voit : assistants, tâches automatisées, tableaux de bord, recherche, recommandations, génération de contenu.
Lue de haut en bas, la pile dit quoi construire. Lue de bas en haut, elle dit ce que cela coûte. Avant d’entrer dans la roadmap, chaque capacité passe le même examen. Quelle valeur pour l’utilisateur ? Est-ce faisable ? Quelles données faut-il ? Combien coûte chaque réponse ? Quels risques ? Et que se passe-t-il quand l’usage grandit ? Deux fonctionnalités aussi désirables l’une que l’autre peuvent coûter dix fois plus l’une que l’autre à servir. Cet écart doit peser sur les priorités autant que la demande.
La pile change encore quand le client est public ou sensible. Un éditeur qui vise le secteur public, la santé, la banque ou l’énergie découvre vite une contrainte absente des canvas importés : l’hébergement. La doctrine « Cloud au centre » de l’État impose aux administrations un haut niveau de protection pour les données sensibles. C’est celui de la qualification SecNumCloud, que l’ANSSI délivre après audit. Elle protège notamment contre les lois étrangères qui s’appliquent hors de leur territoire. En pratique, cela exclut beaucoup de services hébergés hors d’Europe. Des acheteurs privés de secteurs critiques reprennent souvent la même exigence dans leurs appels d’offres.
Pour le modèle économique, la conséquence est lourde. Si votre produit appelle par API un modèle chez un fournisseur américain, il vous faudra peut-être une seconde architecture pour ces clients. Par exemple, un modèle à poids ouverts hébergé chez un prestataire qualifié, avec des GPU réservés. Le coût ne suit plus alors la consommation, mais la capacité réservée. La marge de ce segment se calcule à part. Il faut un prix plancher qui couvre l’infrastructure dédiée, même quand l’usage est faible. Mieux vaut le savoir avant de répondre au premier appel d’offres qu’après l’avoir gagné.
Usage, abonnement, crédits ou valeur, que facturer
En IA, le prix doit tenir compte de l’usage, de la valeur et du coût de service. L’unité que vous choisissez change tout le reste.
La tarification à l’usage suit la consommation : tokens, requêtes, unités de calcul, recherches documentaires ou tâches d’agents. On choisit l’unité qui reflète le mieux le travail fait. Le prix suit alors le coût de service, ce qui protège la marge quand l’usage s’envole. C’est aussi la formule la plus claire pour des clients techniques.
Les abonnements assortis de plafonds transforment le prix en forfait. Chaque niveau débloque autre chose : accès au modèle, longueur de texte traitée, qualité de génération, degré d’automatisation, options de conformité. Ce format rassure les acheteurs qui veulent une dépense prévisible. C’est le plus répandu, des PME aux grands comptes. Un détail français compte ici. On affiche les prix HT pour les professionnels. Mais un indépendant ou une très petite entreprise raisonne souvent en TTC, avec la TVA à 20 %. Un plan à 49 € HT devient 58,80 € sur le relevé bancaire.
Les systèmes à crédits ajoutent une unité intermédiaire. Mille tokens, une image ou une analyse consomment chacun un nombre de crédits fixé. L’utilisateur n’a plus à comparer des unités différentes pour prévoir sa facture. Il passe plus facilement d’une fonctionnalité à l’autre, et la montée en gamme devient naturelle.
La tarification à la valeur ne suit plus la consommation mais le résultat : heures gagnées, volume en plus, risque évité, hausse de conversion ou documents traités. C’est la plus rentable quand le gain se mesure et s’attribue clairement. C’est la plus fragile dans le cas contraire. Elle suppose un accord écrit avec le client sur la façon de mesurer le gain.
Enfin, la monétisation grands comptes vend autre chose : modèles spécialisés, circuits de données privés, outils de contrôle, engagements de service (SLA), calcul dédié, intégration et personnalisation. Le client paie autant la maîtrise du risque que la capacité du produit. On signe souvent des contrats de plusieurs années, avec un socle fixe pour la plateforme et une part variable liée à l’usage. Dans les marchés publics, le bordereau de prix est figé à la remise de l’offre. La marge se protège donc dans la conception technique, puisque le prix ne bougera plus.
Ce que coûte réellement une inférence
Le coût d’inférence est le coût marginal qui décide de la marge brute. Il dépend surtout de la taille du modèle et de la quantité de texte qu’on lui envoie et qu’il renvoie, comptée en tokens. Les recherches documentaires, le cache et la façon dont le produit enchaîne les appels comptent aussi. À la différence du SaaS classique, ce coût grandit avec l’usage et pèse directement sur la marge.
Le piège principal est le suivant. Un an plus tard, le même produit envoie plus de contexte, ajoute une étape où il vérifie sa propre réponse et fait plus d’appels. La marge glisse alors sans bruit. Il faut la simuler avant de fixer un prix : plusieurs niveaux de trafic, la marge minimale acceptable, le point mort. Et il faut suivre à part deux mouvements qui n’avancent pas au même rythme : la consommation qui monte et le prix du token qui baisse.
Un exemple chiffré de la dérive silencieuse (chiffres indicatifs)
Un produit est facturé 19 € HT par mois, soit environ 21,85 dollars quand un euro vaut 1,15 dollar. Un utilisateur lance 400 requêtes par mois sur un modèle à 3 dollars le million de tokens en entrée et 15 dollars en sortie.
- Année 1 : une requête = 1 appel de 1 500 tokens en entrée et 300 en sortie. Coût : 1 500 × 3/1 000 000 + 300 × 15/1 000 000 = 0,0045 + 0,0045 = 0,009 dollar par requête, soit 3,60 dollars par mois, environ 16 % du prix encaissé.
- Année 2 : même produit, mais avec plus de contexte et une étape de vérification : 2 appels, 4 000 tokens en entrée et 600 en sortie au total. Coût : 4 000 × 3/1 000 000 + 600 × 15/1 000 000 = 0,012 + 0,009 = 0,021 dollar par requête, soit 8,40 dollars par mois, environ 38 % du prix encaissé.
Ni le prix ni le nombre de requêtes n’ont bougé. Pourtant, la marge sur l’inférence seule est passée d’environ 84 % à 62 % du tarif. Si l’euro recule face au dollar pendant la même période, c’est pire, sans qu’aucune ligne de code n’ait changé. À 1,05 dollar pour un euro, les 8,40 dollars de l’année 2 font déjà 42 % du prix. C’est cette double dérive, technique et monétaire, qu’il faut modéliser avant qu’une facture ne la révèle.
L’inférence n’est pas le seul coût qui revient. L’entraînement se paie une fois. Le travail sur les données, lui, ne s’arrête jamais : nettoyer, annoter, voir quand le modèle se dégrade, le réentraîner, tenir les jeux de test à jour. Au total, il coûte souvent plus que l’entraînement. La fiabilité a aussi sa facture. Une erreur du modèle entraîne des relectures manuelles, parfois des escalades, des audits de conformité et des corrections. Tous ces coûts entrent dans l’économie par client. Sinon, la fiabilité a l’air gratuite.
La marge s’améliore par la technique autant que par le prix. On peut confier les demandes simples à un modèle plus petit, garder en mémoire les réponses déjà calculées, traiter les tâches par lots et raccourcir les instructions envoyées au modèle. Réduire les coûts fait partie de la roadmap, au même titre que les fonctionnalités.
« Le prix des tokens baisse tout seul » : jusqu’où compter dessus
Un directeur financier qui lit ce qui précède répondra souvent ceci : le prix du token baisse vite, la dérive se corrigera donc d’elle-même. L’argument n’a rien d’absurde. Les fournisseurs ont plusieurs fois baissé leurs tarifs. Et un petit modèle atteint souvent aujourd’hui la qualité d’un grand modèle d’hier.
Le calcul montre pourtant où cet argument s’arrête. Reprenons l’exemple et supposons que le prix unitaire baisse de 30 % entre l’année 1 et l’année 2. La requête de l’année 2 coûte alors 0,021 × 0,7 = 0,0147 dollar. C’est encore 63 % de plus que les 0,009 dollar de départ. Le nombre de tokens par requête a été multiplié par 2,6, de 1 800 à 4 600. Or une baisse de prix de 30 % ne compense qu’une hausse de volume d’environ 43 %. La baisse des prix aide. Elle ne rattrape pas une architecture qui consomme deux fois et demie plus.
D’où une règle de pilotage. Si l’inférence dépasse 30 % du prix HT sur une cohorte de clients, l’éditeur agit d’abord sur l’architecture. Il envoie les requêtes simples vers un petit modèle, utilise le cache et raccourcit le contexte. Il ne touche au prix qu’ensuite. Si la part dépasse encore 40 % après ces réglages, le plan concerné passe à des crédits plafonnés. Le seuil de 30 % n’a rien d’universel. Il se règle selon la marge brute visée. Mais il doit être écrit avant la première hausse de facture.
Un seul indicateur suffit pour savoir si la règle marche : la marge brute par cohorte mensuelle de clients, suivie dans le temps. Le garde-fou est la satisfaction mesurée sur les requêtes envoyées au petit modèle. Si elle baisse de plus de quelques points, l’économie se paiera en résiliations.
La donnée comme seul avantage difficilement copiable
La stratégie de données décide de ce qu’une entreprise d’IA peut devenir. Les sources les plus solides sont celles qui s’accumulent avec l’usage. Contenu produit par les utilisateurs, traces d’usage, intégrations, réseaux de partenaires. Les jeux de données publics les complètent, mais ne les remplacent jamais. Chaque source vient avec des droits d’usage et une fiabilité différents. Il faut les clarifier dès l’intégration. La qualité et l’exclusivité pèsent bien plus lourd que le volume.
Cette qualité se mesure. Les données sont-elles récentes, complètes, sans biais, annotées de la même façon ? Quelles erreurs reviennent ? Ces questions aident à comprendre une baisse de performance sans réentraîner le modèle à l’aveugle.
Le contrôle des données fait partie du modèle commercial. Il faut gérer les consentements, savoir d’où vient chaque donnée, pouvoir supprimer ou corriger les données d’une personne, protéger les données personnelles jusque dans les index du modèle et garder des journaux d’audit. Depuis avril 2024, la CNIL publie des recommandations sur l’application du RGPD au développement des systèmes d’IA. Les services juridiques des clients s’en servent désormais comme grille de lecture. Un éditeur qui peut montrer, documents à l’appui, comment il les respecte vend nettement plus vite.
La conformité ne s’arrête pas au RGPD, et elle change le calendrier. Le droit européen classe désormais les usages de l’IA par niveau de risque. Un assistant qui résume des réunions internes a peu d’obligations. Un système qui trie des candidatures ou évalue la solvabilité d’un particulier est classé à haut risque. Il doit alors documenter ses risques, contrôler ses données, tenir des journaux, prévoir un contrôle humain et passer une évaluation de conformité. Les dates de ces obligations ont déjà bougé une fois. Un business plan sérieux les traite comme une hypothèse datée, à revérifier avant chaque appel d’offres.
Côté français, le schéma présenté en septembre 2025 par la DGE et la DGCCRF confie la coordination à ces deux directions. En général, chaque entreprise s’adresse à son régulateur habituel, avec l’appui technique de l’ANSSI et du PEReN. Sa mise en œuvre passe par la loi. Pour le modèle économique, le message est le même que pour l’hébergement. Si votre cas d’usage est à haut risque, la conformité a un coût fixe et élevé. Il se rentabilise mieux sur quelques grands comptes en contrat long que sur des milliers d’abonnements à bas prix.
Valider le modèle, le produit, le prix et l’économie
Une idée d’entreprise d’IA doit lever quatre doutes. Les clients en veulent-ils ? Peut-on la construire ? Est-elle rentable ? Le modèle est-il assez bon ? Chaque doute demande son propre test. Le modèle se vérifie d’abord hors production, sur des jeux de questions de référence qui ne changent pas. On teste aussi la sécurité et les réponses inventées (les « hallucinations ») avant de laisser une version sortir du laboratoire.
En production, ce sont les usages qui tranchent : taux de tâches réussies, effet sur la fidélité, envie de payer, adoption réelle dans le travail. Ces mesures disent si la qualité technique gagnée devient une valeur perçue. Les benchmarks ne le disent jamais.
Les prix se testent aussi. Quels niveaux d’offre marchent ? Comment les ventes réagissent-elles à une hausse ? Les packs de crédits plaisent-ils ? Que changent les plafonds ? Le but est de faire monter le revenu sans que les plus gros utilisateurs coûtent plus qu’ils ne rapportent. Il reste à vérifier que le modèle tient sous pression. Tests de charge, simulations d’usage et calculs de marge montrent à partir de quel volume l’économie se retourne. Ce test sépare une croissance rentable d’une croissance qu’on subventionne.
Le canvas vérifie la cohérence, la ligne d’inférence décide de la marge
Le canvas réunit les couches précédentes en une seule vue. Ainsi, aucune décision stratégique ne repose sur une couche laissée vide. La couche stratégique fixe le marché, le problème, le système de valeur, ce qui vous distingue et ce qui vous protège. La couche capacités décrit les données, le modèle, l’orchestration, l’hébergement et l’interface. La couche économique aligne revenus, coûts, change, économie par client et point mort. La couche expérimentation rassemble l’évaluation du modèle, la validation de la valeur et les tests de prix. La couche gouvernance couvre la sécurité, la conformité, le niveau de risque et la documentation du cycle de vie. Enfin, la couche organisation traite la maturité des équipes produit, data science et technique, les écarts de compétences et les changements de modèle opérationnel.
Lues ensemble, ces six couches servent de test de cohérence. Une promesse stratégique qu’aucune capacité ne soutient saute aux yeux. Un client public qu’aucune architecture qualifiée ne peut servir aussi. Tout comme une économie qui ne résiste pas à la montée en charge.
Le canvas a une limite. Il montre les incohérences, mais ne dit pas laquelle coûtera le plus cher. Dans un modèle économique d’IA, c’est presque toujours la ligne d’inférence en euros, que l’on suppose fixe alors qu’elle bouge avec l’usage et le change. L’exemple chiffré plus haut le montre sans détour. Sans toucher au prix ni au volume, la part de l’inférence dans le tarif passe d’environ 16 % à 38 %, puis à 42 % si l’euro recule. Aucun réglage de l’interface ne compense une telle glissade.
Avant de figer une grille tarifaire, recalculez donc la ligne d’inférence en euros sur l’usage réel, avec un taux de change prudent, le contexte de l’année 2 et la part des clients qui exigeront un hébergement qualifié. Tant que ce calcul manque, le reste du canvas repose sur une hypothèse que personne n’a vérifiée.