Pourquoi le coût de l’IA dépasse celui des modèles

« Générative » et « agentique » décrivent le fonctionnement d’un système d’IA. Ils n’établissent pas si ce système produit un meilleur résultat métier pour une tâche donnée. Pour les travaux à fort volume, cette distinction compte, car les appels au modèle, l’utilisation d’outils, les nouvelles tentatives et la vérification humaine peuvent s’accumuler sur des milliers d’exécutions. Les acheteurs doivent évaluer le mécanisme en parallèle du résultat et du volume de production attendu.

Une IA plus sophistiquée doit justifier sa place

Les équipes d’entreprise peuvent utiliser quatre grands mécanismes : fondé sur des règles, prédictif, génératif et agentique. Un système fondé sur des règles exécute une logique explicitement écrite, tandis qu’un modèle prédictif attribue un score à une entrée à l’aide de schémas appris à partir de données historiques. Un modèle génératif utilise un grand modèle de langage, ou LLM, pour créer du contenu ou des réponses à partir d’une entrée. Un système agentique place un modèle dans une boucle où il peut planifier des étapes, appeler des outils, inspecter les résultats et poursuivre vers un objectif.

Ces mécanismes offrent des capacités différentes. Les règles peuvent produire un comportement prévisible pour les conditions que les concepteurs ont encodées. Les systèmes prédictifs peuvent classer ou noter des cas à partir de schémas appris, tandis que les systèmes génératifs peuvent interpréter un langage ouvert et créer de nouvelles sorties. Les systèmes agentiques peuvent étendre ces capacités sur plusieurs étapes et outils externes, selon la conception du workflow.

Les discussions d’achat au niveau des fonctionnalités peuvent brouiller ces distinctions. Lorsqu’un fournisseur qualifie un produit de « pleinement agentique », il avance une affirmation sur sa conception ; cette formule, à elle seule, n’établit pas sa valeur métier. Une assistance peut utiliser un modèle génératif sans exécution autonome en plusieurs étapes, tandis que des workflows multi-systèmes peuvent aussi contenir des règles déterministes. Les acheteurs doivent établir ce que la tâche exige et quel mécanisme peut répondre à ces exigences au volume de production attendu.

Une plus grande complexité peut apporter des capacités utiles. Un modèle génératif peut traiter un langage qu’une règle explicite n’avait pas anticipé, et un workflow agentique peut récupérer des enregistrements, choisir des actions, invoquer des outils et s’adapter sur plusieurs étapes. Ces conceptions peuvent aussi impliquer des appels répétés au modèle, du contexte conservé, l’utilisation d’outils, des sous-agents et des nouvelles tentatives. Chaque étape supplémentaire peut ajouter de la consommation et un point supplémentaire où une erreur peut affecter le résultat final.

Prenons un workflow illustratif de remboursement client. Une règle pourrait approuver automatiquement une demande inférieure à 50 $ et effectuée dans les 30 jours, tandis qu’un modèle prédictif pourrait classer la demande en approuver, refuser ou escalader selon des schémas historiques. Un LLM pourrait rédiger une réponse à une demande formulée de manière inhabituelle. Un agent pourrait récupérer la commande, appliquer la politique, émettre le remboursement et envoyer une confirmation via le canal préféré du client.

Ces approches résolvent différentes versions du problème. Une exécution autonome en plusieurs étapes peut justifier un agent lorsque la tâche exige plusieurs outils et décisions. Une demande couverte de manière fiable par des conditions de politique explicites peut être traitée avec une logique déterministe, les cas exceptionnels étant orientés vers un parcours génératif ou agentique. La question économique est de savoir si cette capacité supplémentaire crée suffisamment de valeur incrémentale pour couvrir son coût de production et son risque.

L’économie de production peut modifier le calcul du prix

Le coût de production dépend de l’ensemble du workflow. Le prix d’un modèle peut baisser tandis que le coût d’exécution d’une tâche augmente si le workflow utilise davantage d’appels, de tokens, d’outils ou de nouvelles tentatives. Dans un workflow en plusieurs étapes, le modèle peut retraiter le contexte précédent avant de choisir son action suivante. Des sous-agents peuvent ajouter une consommation supplémentaire.

L’estimation de Gartner met en évidence le multiplicateur potentiel de consommation lorsqu’un workflow invoque un modèle de façon répétée. Les chiffres annoncés par EY impliquent un coût environ 30 fois plus élevé, même si la comparaison couvre des années et des architectures différentes. EY est un cabinet commercial de services professionnels qui vend des services aux entreprises ; son estimation sur l’économie de l’IA en entreprise provient donc d’une organisation qui peut tirer un bénéfice commercial de la demande pour des missions de conseil et d’implémentation associées.

L’unité d’achat utile est le coût total de production par résultat métier réussi. Ce calcul peut inclure la consommation du modèle, l’orchestration, l’utilisation d’outils, les nouvelles tentatives et le travail humain nécessaire pour rendre le résultat exploitable. Un tarif par token ou par interaction ne couvre que les composants inclus dans ce tarif. Comparer des workflows complets oblige les acheteurs à établir quel travail est inclus dans chaque unité tarifée.

Le volume amplifie l’économie unitaire. À titre d’illustration, à un dixième de centime par description produit, 200 000 descriptions coûteraient 200 $ pour une actualisation et 800 $ si l’ensemble du catalogue était actualisé quatre fois par an. À un tarif illustratif de 0,90 $ par ticket automatisé, 400 000 tickets par an coûteraient 360 000 $ avant toute dépense supplémentaire de revue. Un faible prix unitaire doit tout de même être multiplié par un usage annuel réaliste.

Le marketing rend cet effet visible, car certaines charges de travail répètent la même opération sur de grands catalogues ou de gros volumes clients. Le contenu produit en est un exemple : les coûts d’architecture reviennent à chaque exécution, puis de nouveau lorsque le contenu est actualisé. Le travail créatif ouvert, les interactions client et les processus inter-systèmes peuvent avoir des exigences différentes. Les acheteurs doivent calculer l’économie de production à partir de la charge de travail qu’ils prévoient d’exécuter.

Un projet pilote réussi peut masquer l’équation de production

Une preuve de concept peut montrer si un système exécute une tâche dans des conditions de test. Son économie peut sembler très différente au volume de production, car une petite expérimentation ne génère qu’une faible facture absolue. Un projet pilote illustratif avec 500 interactions pourrait démontrer la fonctionnalité sans établir si la même conception est économiquement viable à l’échelle de l’organisation. La validation économique exige un volume annuel réaliste et le travail de production autour de chaque interaction.

Les processus d’achats et de gouvernance peuvent séparer deux tests. La validation fonctionnelle demande si le système fonctionne dans des conditions définies. La validation économique demande si le coût par résultat réussi reste acceptable une fois inclus le volume attendu, les nouvelles tentatives, la revue, les révisions et les autres travaux de production. Rendre ces deux dimensions explicites évite qu’un succès technique se substitue à un business case de production.

Un calcul d’achat utile peut commencer avant le projet pilote. Appliquez l’estimation par interaction du fournisseur au volume annuel attendu de l’organisation, puis ajoutez le travail attendu pour la revue et la révision ainsi que les outils ou services facturés séparément. Le résultat dépend d’hypothèses ; il faut donc rendre ces hypothèses visibles et les tester pendant le projet pilote. Les équipes peuvent aussi tester le routage : dans l’exemple du remboursement, les demandes courantes peuvent suivre une logique de politique explicite, tandis que les cas exceptionnels sont orientés vers un workflow génératif ou agentique.

La vérification humaine fait partie du coût d’exploitation

Le calcul n’est qu’un composant du coût d’exploitation de l’IA lorsque des employés vérifient les sorties. Un processus déterministe et un système génératif peuvent échouer de façons différentes : une réponse générative peut contenir une déclaration de politique incorrecte formulée dans un langage fluide. Détecter cette erreur peut exiger qu’un employé qui comprend la politique concernée inspecte la réponse. Ce temps de revue fait partie de l’économie du workflow.

Les dépenses de main-d’œuvre et de technologie peuvent aussi apparaître dans des budgets différents. La dépense de plateforme peut figurer sur une facture technologique, tandis que la vérification apparaît sous forme de temps salarié, de dépense de sous-traitance ou d’effectifs dans une équipe opérationnelle. Un système peut réduire le temps de rédaction ou d’exécution tout en conservant un travail de revue significatif. Le ROI doit refléter le processus de bout en bout, y compris les personnes nécessaires pour vérifier ou corriger les sorties.

Le coût change encore lorsqu’un système passe de la création de contenu à l’exécution d’actions. Un agent qui récupère un enregistrement de commande, interprète la politique et émet un remboursement crée des conséquences qui dépassent celles d’un brouillon qu’un employé approuve avant envoi. Une plus grande autonomie peut supprimer l’exécution manuelle, tandis que les contrôles, la vérification et l’impact attendu des erreurs restent intégrés au business case. Les acheteurs doivent mesurer ces coûts par rapport au travail que le workflow automatisé supprime réellement.

Les seuls taux d’automatisation nominaux ne peuvent pas rendre compte de ce travail. Si le personnel corrige, rejette ou revérifie régulièrement les sorties, son temps fait partie du coût d’exploitation du système. Le temps de revue rapporté au volume annuel peut affecter de manière significative une comparaison entre architectures. La finance et les responsables métier doivent rattacher le travail de vérification au même calcul de charge de travail que les dépenses de modèle et d’orchestration.

La responsabilité des coûts traverse les frontières organisationnelles

Différentes fonctions de l’entreprise voient différentes parties de la décision. Les achats voient les prix des contrats et des licences, le juridique examine le traitement des données, et le marketing juge si une sortie répond au besoin métier. Les responsables budgétaires voient les dépenses départementales, tandis que les équipes d’ingénierie et de données peuvent évaluer le mécanisme et estimer comment son architecture affecte la consommation en production. Une évaluation économique complète dépend de la combinaison de ces points de vue autour de la même charge de travail.

Lorsque les coûts restent séparés, aucun examen individuel ne saisit nécessairement ensemble la consommation du modèle, l’orchestration, la vérification humaine et le volume attendu. Le processus d’achat peut combler cet écart en attribuant la responsabilité du coût par résultat réussi. L’examen par l’ingénierie et les équipes data peut alors éclairer les décisions commerciales en identifiant quels cas exigent de la génération ou une exécution agentique et lesquels peuvent suivre des parcours déterministes ou prédictifs. La réponse doit découler des exigences de la tâche et de l’économie de production mesurée.

Points clés

• Faire correspondre la complexité de l’IA à la tâche : L’IA générative et l’IA agentique justifient leur place lorsque leurs capacités supplémentaires améliorent suffisamment les résultats métier pour couvrir un coût et un risque plus élevés. Les acheteurs peuvent orienter le travail prévisible vers des règles ou des modèles prédictifs et réserver les IA plus complexes aux cas qui l’exigent.
• Calculer le coût de production par résultat : Le seul pricing du modèle ne prend pas en compte l’orchestration, les appels d’outils, les nouvelles tentatives, la revue humaine ni le volume de production. Les achats et la finance peuvent comparer les architectures à l’aide du coût total par résultat métier réussi pour un usage annuel réaliste.
• Tester l’économie pendant le projet pilote : Une preuve de concept réussie peut masquer des coûts qui deviennent significatifs à l’échelle. Les responsables métier peuvent valider le volume attendu, les nouvelles tentatives, le travail de revue et les hypothèses de routage en parallèle de la performance fonctionnelle avant d’approuver un déploiement en production.
• Inclure la vérification humaine dans l’économie de l’IA : La revue, la correction et la supervision consomment du travail humain même lorsque l’IA automatise une partie d’un workflow. Les responsables budgétaires peuvent rattacher ce travail au même calcul de charge de travail que les dépenses de modèle et d’orchestration, en particulier lorsque les systèmes d’IA exécutent des actions à conséquences.
• Attribuer la responsabilité au-delà des frontières organisationnelles : Les coûts de l’IA s’étendent souvent aux factures technologiques, aux budgets opérationnels et au temps des employés. Les achats, l’ingénierie, la finance et les responsables métier peuvent établir une mesure partagée du coût par résultat qui capture l’ensemble du workflow de production.