Combien coûte l’analytique conversationnelle en 2026 ?

D’où proviennent les coûts liés à l’analyse conversationnelle ?

Les entreprises peuvent apprécier les coûts de la BI et de l’analytique conversationnelle sous plusieurs angles. Il y en a trois principaux : la technologie, l’état de leur patrimoine de données et les besoins en personnel.

Bharath Thota, associé du pôle numérique et analytique au sein du cabinet de conseils Kearney, explique que de nombreuses DSI commencent par budgétiser les logiciels. C’est le poste de dépense le plus facile à identifier. Or, d’après son expérience, les frais de licence ne représentent que 20 à 30 % du coût total de possession. Les 70 à 80 % restants, invisibles pour les utilisateurs, sont liés à la préparation des données, à l’ingénierie d’intégration, aux tests, à la gestion du changement et à la maintenance continue.

« Les déploiements en production coûtent généralement trois à cinq fois plus cher que l’estimation initiale du fournisseur », estime-t-il. « Environ 85 % des entreprises sous-estiment les coûts de leurs projets d’IA. Les dépassements de budget sont la norme, pas l’exception », souligne-t-il.

Les deux aspects les plus difficiles à évaluer pour les équipes FinOps sont la préparation des données et leur maintenance continue. La « data prep » peut absorber 30 % à 50 % du budget total. Or, ce volet est rarement inclus dans le devis du fournisseur. Les coûts d’exploitation courants représentent généralement 15 % à 30 % du coût initial de développement chaque année. Ils peuvent inclure la maintenance du modèle de données et des rapports, la mise à jour des évaluations et les ajustements liés à la dérive du pipeline.

Les DSI et les équipes « Data » devraient également réfléchir aux mesures nécessaires pour rendre le système fiable, plutôt que de considérer l’analytique conversationnelle comme un simple produit à activer.

« L’on dispose de chiffres concrets concernant les frais de licence, de modèle et de coût aux tokens, mais ils sont rarement à l’origine du problème », explique Hugh Mulligan, directeur associé de la gestion des risques et de la gouvernance cyber chez S-RM, une société de conseil en renseignement et cybersécurité. « Il existe un fossé entre la capacité du modèle à réaliser une démonstration convaincante et sa capacité à fournir des réponses que l’on pourrait présenter avec assurance à un conseil d’administration ou à un régulateur ».

En matière de coût, Hugh Mulligan se montre prudent quant à l’application d’un coefficient multiplicateur unique. Le point de départ de l’entreprise est déterminant. « Si vous disposez d’un entrepôt de données propre et bien modélisé, avec des définitions de métriques convenues, la couche conversationnelle est relativement simple à mettre en œuvre et moins coûteuse », déclare-t-il. « Cependant, les entreprises se trouvent à des stades très différents en matière de préparation aux données ».

John Pettit, directeur technique de Promevo, une ESN spécialisée dans les technologies de Google Cloud, fait le même constat que Bharath Thota concernant les surcoûts de l’analytique conversationnelle.

« Ces coûts supplémentaires ne proviennent pas de la technologie : ils sont liés aux ressources humaines et à l’organisation », insiste-t-il.

Le passage d’un projet pilote à la production nécessite des ingénieurs de données pour créer et maintenir la couche sémantique, des analystes pour définir des garde-fous et une surveillance constante pour s’assurer que le modèle ne déraille pas de manière incontrôlée.

« Il faut déployer des efforts considérables pour maintenir l’humain impliqué jusqu’à ce que le système soit véritablement prêt à gérer les cas particuliers », remarque John Petit.

Les trois manières d’intégrer l’analytique conversationnelle

Lors de la mise en place d’une solution d’analytique conversationnelle, les entreprises doivent choisir entre optimiser leurs outils existants, acquérir un produit dédié ou développer un système sur mesure tirant parti des dernières innovations en matière de gestion des langues. Chaque option présente des avantages et des coûts différents.

1. Ajouter des fonctionnalités de langage naturel aux outils de BI existants

Cette approche, bien que moins onéreuse, peut masquer des coûts liés à la capacité et à la préparation des données. Par exemple, Microsoft Power BI Copilot requiert une option Fabric payante, dont le prix de départ se situe autour de 200 dollars par mois (172 euros HT, N.D.L.R.). Selon Bharath Thota, ce coût peut atteindre environ 5 500 dollars par mois (4740 euros HT, N.D.L.R.) pour répondre aux besoins des entreprises, sans compter les frais supplémentaires liés à la consommation de tokens. L’amélioration du modèle sémantique, pour une meilleure qualité des réponses, représente un autre coût caché. Ce travail inclut la définition précise des noms de champs, des descriptions et des synonymes, ainsi que la sécurité au niveau des lignes. Par conséquent, une fonctionnalité apparemment peu coûteuse peut inciter une entreprise à entreprendre un projet de modélisation sémantique plus tôt que prévu.

2. Achetez un outil sur étagère (standalone)

Avec des outils autonomes comme ThoughtSpot, Tellius et Dot, les prix affichés sont plus transparents. La tarification par utilisateur est le modèle le plus simple, environ 100 dollars (92 euros HT) par utilisateur et par mois. Cependant, certains éditeurs utilisent une tarification au crédit ou à la consommation, ce qui peut brouiller les estimations de coûts. Même avec des modèles de tarification simples par poste, les coûts peuvent augmenter avec l’expansion du réseau. Les organisations peuvent également devoir payer pour des services d’implémentation et redéfinir les indicateurs au sein de la couche sémantique propriétaire de l’éditeur. Cette couche sémantique propriétaire peut être un fardeau à l’avenir. Elle risque de complexifier le changement de fournisseur et de le rendre plus coûteux.

3. Créer un projet personnalisé basé sur un LLM

Malgré les inquiétudes liées à la hausse du coût des tokens, Bharath Thota considère que l’utilisation des LLM par API représente désormais une dépense relativement faible (à condition d’utiliser la mise en cache). La majeure partie du coût d’une implémentation personnalisée est imputable au personnel et à l’évaluation, confirme-t-il.

Les entreprises peuvent prévoir de consacrer 40 % à 60 % de leur budget aux talents d’ingénierie, auxquels s’ajoutent un cadre d’évaluation permanent, des garde-fous et une maintenance annuelle représentant 15 % à 30 % du coût initial. Ce travail est indispensable. Seuls, les modèles frontières atteignent des taux de précision d’environ 86 % à 91 % sur les benchmarks académiques de conversion de texte en SQL, contre seulement 17 % à 21 % sur le parangonnage Spider 2.0, qui utilise des schémas d’entreprise plus réalistes. Combler cet écart repose davantage sur le travail d’ingénierie que sur le seul choix du modèle. Les systèmes affichant les plus gros scores au classement de Spider 2.0 couplent plusieurs LLM, agents IA et outils.

Les coûts négligés de l’analytique conversationnelle

Certains coûts liés à l’analytique conversationnelle n’apparaissent qu’après la phase de validation du concept. À mesure que le nombre d’utilisateurs augmente au sein de l’entreprise, les besoins en données et en ressources de calcul augmentent également. Mais la mise à l’échelle n’est pas le seul défi. Des coûts supplémentaires peuvent provenir de la production du contexte métier nécessaire à l’obtention de réponses fiables et de la gestion des connexions au sein de schémas de données complexes.

Le coût de l’analyse conversationnelle peut exploser lorsqu’un système initialement conçu pour une petite équipe est déployé à l’échelle de l’entreprise. Boobesh Ramadurai, vice-président de LatentView Analytics (une société de consultance américaine spécialisée dans l’analytique), explique que les entreprises sous-estiment souvent le coût de cette transition. Ce coût peut être multiplié par dix par rapport à la preuve de concept initiale.

Selon Boobesh Ramadurai, les coûts de la couche de données peuvent quadrupler, ceux de la couche de contexte tripler et l’utilisation des tokens par les LLM doubler. Les évaluations et les améliorations itératives des performances des agents peuvent engendrer un coût supplémentaire souvent équivalent à celui du PoC.

« Le véritable centre de coût, c’est le taux de confiance dans le système. Une seule mauvaise réponse et l’utilisateur est perdu. Reconstruire cette crédibilité n’apparaît dans aucun budget, mais c’est le poste de dépense le plus important », martèle-t-il.

De nombreuses entreprises sous-estiment le travail nécessaire à la création de la couche de contexte. Elle fournit la logique sémantique indispensable à l’exploitation des données conversationnelles. Cette couche inclut les définitions des indicateurs, les formules métier, les règles d’inférence spécifiques aux fonctions et d’autres éléments de contexte métier. Par exemple, elle permet au système de répondre à des questions telles que : les services marketing et finance définissent-ils différemment le retour sur investissement d’un événement ?

Pour ceux qui ne se sont pas encore frottés à l’exercice, ces connaissances résident souvent uniquement dans la mémoire des employés. Produire cette documentation peut représenter 20 à 25 % de l’effort de mise en œuvre. À titre de comparaison, la personnalisation de l’IA, incluant l’ajustement des profils d’utilisateurs et la mise en forme des réponses, ne représente que 5 à 15 % de l’effort lorsque les couches de données et de contexte sont bien développées.

« Les grandes entreprises consacrent généralement des années à optimiser leur infrastructure de données, ce qui leur confère un avantage considérable pour la mise en œuvre de l’IA », apprécie Boobesh Ramadurai. « Mais seulement 10 % d’entre elles environ disposent d’une couche de contexte adéquate. C’est dans cette lacune que se produisent les coûts imprévus. »

Les coûts peuvent également augmenter avec la taille et la complexité du schéma de données. L’ajout d’une table introduit une nouvelle structure de données à interpréter pour le modèle, ainsi que ses interactions potentielles avec les tables existantes. Sans gestion adéquate, le coût de chaque modification peut rapidement s’envoler.

« L’un des pièges est de penser qu’il s’agit d’une relation linéaire : ajouter une table n’est pas synonyme d’un surcoût fixe. Je pense qu’en réalité, ce sont les relations qui déterminent cela, plutôt que les tables elles-mêmes », déclare Hugh Mulligan.

Commencer par les fondations de données

Les démos laissent croire en la simplicité de l’analytique conversationnelle. Cependant, pour une estimation de coûts plus fiable, il est préférable de commencer par déterminer les éléments nécessaires à la mise en place des fondations de données.

« La base de données n’est pas seulement une partie du projet, c’est véritablement l’élément central », rappelle John Pettit.

Il estime que la modélisation et le nettoyage des données représentent environ 70 à 80 % du coût total d’un projet. Les entreprises ignorent souvent le nombre de règles cachées ou intégrées à leurs pipelines de données. Des éléments simples, comme un champ vide, peuvent avoir des significations différentes selon les intégrations de données complexes. John Pettit constate que, dans certains systèmes de données, un même champ peut avoir des significations différentes d’une ligne à l’autre.

Le dirigeant met en garde contre l’effet « waouh » des démonstrations. Elles ont tendance à minimiser le coût et la complexité d’un déploiement en production. Une démo est souvent performante grâce à l’utilisation d’un jeu de données soigneusement préparé et l’anticipation des questions les plus courantes. Les données réelles d’une entreprise, elles, sont rarement aussi propres et cohérentes. Si un utilisateur demande le chiffre d’affaires total, sa définition peut varier selon le système CRM et le logiciel comptable. Si ces termes ne sont pas explicitement définis et intégrés au modèle, le LLM pourrait déduire une réponse à partir des noms de colonnes. Cette réponse, qui semble pourtant fiable, pourrait être totalement erronée.

« Le travail de fond que représentent la définition des indicateurs et l’étiquetage des métadonnées est le seul moyen de construire un système auquel les employés feront réellement confiance », conclut John Pettit.

Ce conseil est une adaptation d’un article écrit par George Lawton, paru en anglais sur les sites de TechTarget.