Un tableau de bord à 3 000 dollars ou un rapport IA à 30 centimes ? Quand la BI complète n’est pas nécessaire
La façon classique de construire des tableaux de bord de direction est bien connue. L’entreprise choisit d’abord une plateforme de BI : Power BI, Tableau, DataLens ou un autre outil de visualisation.
Elle construit ensuite un entrepôt où les informations des systèmes opérationnels sont collectées, nettoyées, transformées et agrégées. Viennent après les datamarts, les calculs, les chargements planifiés, puis la conception des tableaux de bord au-dessus de cette structure.
La direction obtient au final un tableau de bord soigné, avec graphiques, filtres, onglets et indicateurs.
L’approche fonctionne. Elle reste le standard du secteur, et tout un marché d’intégration s’est construit autour : éditeurs de BI, consultants, intégrateurs, analystes et ingénieurs data.
Mais en développant Logsheet.ai, notre plateforme de journaux de production, nous nous sommes heurtés à une question concrète. Il nous fallait des tableaux de bord. Deux options s’offraient à nous :
- construire une couche BI classique, avec entrepôt, datamarts, intégrations et développement sur mesure ;
- générer les rapports de direction par IA, directement au-dessus de données opérationnelles structurées.
Nous avons choisi la seconde. À ce jour, nous ne le regrettons pas.
Cela ne signifie pas que la BI est morte. Elle ne l’est pas. Les rapports générés par IA fonctionnent très bien dans certains cas et échouent nettement dans d’autres.
La bonne question n’est pas de savoir si l’IA peut remplacer la BI partout, mais plutôt : quand un déploiement BI complet est-il superflu, et quand reste-t-il indispensable ?
Ce que coûte réellement un tableau de bord classique
Une fois terminé, un tableau de bord paraît simple. Quelques graphiques. Deux ou trois filtres. Un tableau d’indicateurs. Peut-être un bloc prévu-réalisé et quelques cartes de KPI.
Mais même un tableau de bord moyennement complexe demande un vrai volume de travail. La mise en page seule prend 10 à 20 heures — en supposant que les données soient déjà propres, les besoins clairs et les utilisateurs constants dans leurs demandes. En réalité, aucune de ces hypothèses n’est garantie.
Le déploiement comprend généralement aussi :
- la connexion des systèmes sources ;
- la mise en place des imports ;
- la construction d’un entrepôt ou d’une couche de préparation ;
- le nettoyage et la normalisation des données ;
- la création des agrégats ;
- la définition des calculs ;
- la préparation des datamarts ;
- les échanges sur les besoins avec les utilisateurs ;
- la refonte de certaines parties après retours.
Un projet type demande 20 à 30 heures pour les intégrations et le chargement, une trentaine d’heures pour la préparation, les calculs et les datamarts, 20 à 30 heures supplémentaires d’analyse, plus 10 à 20 heures pour le tableau de bord lui-même.
En pratique, un seul tableau de bord atteint facilement 3 000 à 5 000 dollars. Et ce n’est pas nécessairement une dépense unique.
Les utilisateurs demandent de nouveaux filtres. La direction veut un autre découpage. Un service change sa logique de reporting. Un nouveau système source apparaît. Une règle de calcul évolue. Chaque demande relance un cycle de développement : l’utilisateur dépose une demande, attend un analyste ou un développeur, examine le résultat, puis demande un autre ajustement.
C’est normal dans un projet BI classique. C’est aussi l’une des raisons pour lesquelles beaucoup de petits besoins de reporting ne voient jamais le jour. Le tableau de bord serait utile — juste pas assez pour justifier plusieurs milliers de dollars et des semaines de travail.
Ce que change un rapport généré par IA
L’alternative consiste à connecter un modèle de langage à la base opérationnelle et à laisser l’utilisateur décrire son rapport en langage naturel. Chez nous, les données sont dans PostgreSQL.
L’utilisateur peut demander : « Crée un rapport pour le directeur avec les retards de production, les plans non tenus, les arrêts et les problèmes non résolus sur la période choisie. »
Le modèle prépare alors la logique du rapport :
- quelles tables et quels journaux utiliser ;
- où se trouvent les valeurs prévues ;
- où se trouvent les valeurs réelles ;
- comment calculer les retards ;
- quels indicateurs afficher ;
- quels graphiques et tableaux inclure ;
- que souligner dans les conclusions.
Le système produit un rapport HTML qui sert de modèle réutilisable. Quand l’utilisateur choisit une nouvelle date ou une nouvelle période, le rapport est régénéré sur des données à jour. Le HTML est stocké puis transmis au front.
Le résultat n’est pas un tableau de bord BI conçu à la main au sens classique. C’est un rapport de direction généré dynamiquement au-dessus de données structurées.
Générer un tel rapport coûte en général de 0,10 à 0,40 dollar, selon le modèle, la taille du contexte et la complexité du rapport. Même exécuté chaque jour, le coût mensuel d’IA peut se limiter à quelques dollars.
Avec davantage de rapports, plus de données et une logique plus complexe, le total augmentera. Mais à l’échelle d’une entreprise, il reste largement en dessous du coût de création et de maintenance d’un tableau de bord classique.
Pourquoi la comparaison n’est pas tout à fait honnête
Il serait trompeur d’affirmer qu’un rapport IA à 30 centimes équivaut toujours à un tableau de bord BI à 3 000 dollars. Les deux répondent à des besoins qui se recoupent, sans être identiques.
Un déploiement BI classique peut inclure :
- un stockage de données sur le long terme ;
- des datamarts gouvernés ;
- une gestion fine des accès ;
- des rafraîchissements planifiés ;
- des modèles sémantiques à l’échelle de l’entreprise ;
- des agrégats très performants ;
- des métriques standardisées entre services ;
- des tableaux de bord stables utilisés par des centaines ou des milliers de personnes.
Un rapport généré par IA est bien plus léger. Il fonctionne directement au-dessus d’une base opérationnelle existante. Il peut viser un seul responsable, un seul service ou un seul scénario. Il n’est régénéré qu’au besoin. C’est précisément pour cela qu’il coûte si peu.
L’approche IA n’est pas « meilleure » en soi. C’est simplement un autre niveau de solution. Pour beaucoup de besoins de reporting opérationnel, ce niveau suffit.
Pourquoi les chiffres restent fiables
La première réaction face au reporting par IA est prévisible : les modèles hallucinent, comment faire confiance aux chiffres ?
La réponse est simple : ne laissez pas le modèle calculer. Il ne doit pas inventer de totaux, de moyennes, de pourcentages ni d’écarts. Il ne doit pas porter la responsabilité du résultat chiffré final.
Le modèle doit plutôt :
- comprendre la demande de l’utilisateur ;
- déterminer ce qu’il faut calculer ;
- générer ou préparer le SQL ;
- structurer le rapport ;
- choisir la présentation des résultats ;
- rédiger les explications et les conclusions.
C’est la base qui effectue les calculs. Sommes, moyennes, écarts prévu-réalisé, totaux d’arrêts et autres agrégats sont calculés de façon déterministe, en SQL ou dans une autre couche de calcul contrôlée.
Cela crée une répartition claire des responsabilités. La base fournit les chiffres. Le modèle fournit la structure, la présentation et le texte.
Chaque valeur du rapport peut donc être remontée jusqu’à sa source. Si un responsable voit que la production accuse 12 % de retard, le système peut montrer :
- quels enregistrements ont été retenus ;
- quelles valeurs prévues ont été utilisées ;
- quelles valeurs réelles ont été utilisées ;
- quelle formule a produit le résultat.
La source de vérité n’est pas l’IA, c’est la base de données. C’est l’une des raisons principales pour lesquelles cette architecture tient.
Ce n’est pas « envoyez 200 fichiers Excel et demandez un rapport »
Il y a une limite importante. Cette approche ne signifie pas qu’un utilisateur peut envoyer des centaines de fichiers Excel disparates à un modèle et obtenir un tableau de bord de gestion fiable. En général, cela échoue.
Les fichiers bruts doivent d’abord être analysés, normalisés et chargés dans un système structuré. L’IA doit travailler au-dessus de données structurées, pas se substituer à la base.
Quelques fichiers passeront. Des centaines de fichiers aux structures hétérogènes, avec des en-têtes à plusieurs niveaux, des versions différentes et des champs ambigus, non. Le modèle produira peut-être une synthèse soignée, mais les chiffres risquent de ne pas correspondre et le résultat d’être invérifiable.
Un rapport IA ne devient fiable que lorsque les données sous-jacentes sont déjà structurées.
Comment cela fonctionne dans Logsheet.ai
Nous avons rencontré ce problème en construisant Logsheet.ai, une plateforme de journaux de production et de suivi opérationnel. Les utilisateurs créent des journaux pour différents processus :
- postes de production ;
- arrêts d’équipement ;
- maintenance ;
- contrôle qualité ;
- interventions sur le terrain ;
- mouvements de matières ;
- suivi environnemental ;
- autres processus opérationnels.
Dès que les saisies sont stockées sous forme structurée, les mêmes données servent aux rapports. L’utilisateur décrit son rapport avec ses mots — par exemple : « Montre toutes les opérations en retard, compare le prévu et le réalisé, mets en avant les problèmes récurrents et prépare une synthèse pour la direction. »
Le modèle analyse la structure des journaux disponibles et construit la logique du rapport. Il crée la structure HTML, demande les données nécessaires et transforme le résultat en rapport visuel.
L’utilisateur n’a pas à dessiner de graphiques. Il n’a pas à connaître le schéma de la base. Il n’a pas à attendre un développeur chaque fois qu’il veut un nouveau découpage. C’est là le bénéfice principal.
L’IA ne remplace pas la base de données. Elle remplace une partie du travail de développement des rapports au-dessus de cette base.
Quand cette approche fonctionne bien
Les rapports générés par IA sont particulièrement utiles quand plusieurs conditions sont réunies.
Les données sont déjà structurées. Le schéma de base est clair et le système sait où se trouvent les valeurs prévues, les valeurs réelles, les statuts, les dates, les services et les autres champs.
Le modèle de données n’est pas trop complexe. Chez nous, le système opérationnel compte une cinquantaine de tables. C’est gérable : avec le bon contexte et les bonnes consignes, le modèle comprend la structure.
Les transformations restent simples. Calculs prévu-réalisé, analyse des arrêts, suivi des statuts, synthèses de tendances et KPI opérationnels sont de bons candidats.
Les rapports changent souvent. Quand les utilisateurs réclament sans cesse de nouveaux filtres, sections, explications ou découpages, la génération réduit la dépendance aux développeurs.
L’audience est limitée. Si le rapport s’adresse à un responsable, un service ou un petit groupe plutôt qu’à des milliers d’utilisateurs, un rapport HTML généré à la demande peut suffire.
Les performances en temps réel à très grande échelle ne sont pas exigées. Si les données se requêtent en un temps raisonnable, le rapport peut se générer à la demande.
Où l’approche atteint ses limites
L’approche par IA a ses bornes. Quiconque a déployé du reporting d’entreprise sérieux pensera immédiatement à des contre-exemples — à juste titre.
Premier problème : les données sortent de l’entreprise. Nous utilisons aujourd’hui des fournisseurs de modèles externes, ce qui signifie que des données opérationnelles peuvent quitter l’infrastructure de l’entreprise. Pour certaines organisations, c’est rédhibitoire.
Des options existent. Les offres entreprise, où le fournisseur s’engage contractuellement à ne pas utiliser les données clients pour entraîner ses modèles, n’effacent pas toutes les inquiétudes, mais déplacent le sujet vers la confiance dans le fournisseur, les conditions juridiques et la conformité. Une architecture hybride est une autre voie : un modèle externe puissant génère les règles détaillées de reporting dans un environnement de test ou non sensible, puis les données réelles sont traitées par un modèle local selon ces règles. Les modèles locaux sont plus faibles, mais restent utiles sur des tâches étroites et maîtrisées. Cette piste hybride semble prometteuse, même si elle demande des tests dédiés.
Deuxième problème : un paysage de données trop complexe. Notre cas est relativement simple : l’IA travaille directement avec la base du système opérationnel. Nous n’avons pas des dizaines de plateformes historiques sans lien entre elles, chacune avec des centaines de tables non documentées.
Dans une grande entreprise, la situation peut être tout autre. Les heures d’équipement prévues vivent dans un système, l’utilisation réelle dans un autre. Le plan est détaillé par type de travaux, le réel utilise des catégories plus larges qui ne correspondent pas. Les heures réelles ne sont pas stockées telles quelles : il faut les calculer à partir de feuilles de route, les filtrer, les regrouper et les transformer selon des règles métier complexes.
L’IA peut-elle aider à implémenter cette logique ? Probablement. Un utilisateur métier peut-il décrire toute la transformation de façon fiable ? Probablement pas. Plus la logique métier est complexe, plus le risque d’erreur augmente. À un certain point, ingénieurs data, analystes et couches de transformation gouvernées restent indispensables.
Troisième problème : les performances. Générer des rapports directement depuis les tables opérationnelles n’a de sens que si les requêtes s’exécutent dans un temps acceptable. Si chaque exécution doit traiter des millions de transactions, de relevés de capteurs ou d’événements historiques, interroger les données brutes à la demande est une mauvaise architecture.
Dans ce cas, un entrepôt, une couche d’agrégation ou un datamart pré-calculé restent nécessaires. L’IA peut générer des rapports au-dessus de ces couches agrégées, mais on ne peut pas attendre d’elle qu’elle règle seule le problème de performance. C’est là que l’architecture BI classique garde toute sa pertinence.
Les rapports IA ne tuent pas la BI
La conclusion utile n’est pas que l’IA remplace la BI. C’est que l’IA permet, dans bien des cas, de repousser, de simplifier ou de réduire le besoin d’un déploiement BI complet.
Une entreprise n’a pas besoin d’un grand projet de tableau de bord pour chaque demande de reporting. Parfois la direction veut un rapport souple, pas un tableau de bord permanent. Parfois les données existent déjà dans un système opérationnel structuré. Parfois le résultat ne concerne que quelques personnes. Parfois les besoins changent trop souvent pour que le développement manuel soit rentable.
Dans ces cas, la génération de rapports par IA est une alternative concrète. Dans les autres, la BI classique reste la bonne réponse — surtout quand l’entreprise cumule :
- de nombreux systèmes sources ;
- une logique de transformation complexe ;
- des métriques à l’échelle de l’entreprise ;
- un accès utilisateur à grande échelle ;
- des exigences strictes de gouvernance ;
- des volumes de données massifs ;
- de fortes attentes de performance.
Rapports IA et tableaux de bord BI ne s’excluent pas. Dans beaucoup d’architectures, ils fonctionneront ensemble.
Une façon concrète de trancher
Avant de lancer un projet de tableau de bord à 3 000–5 000 dollars, posez-vous quelques questions.
- Les données sont-elles déjà structurées ?
- Les calculs nécessaires peuvent-ils se faire directement en SQL ?
- Le rapport concerne-t-il un petit nombre d’utilisateurs ?
- Les besoins changent-ils souvent ?
- La base répond-elle rapidement aux requêtes ?
- L’entreprise a-t-elle besoin d’un tableau de bord permanent, ou simplement d’un rapport de gestion souple ?
Si les réponses sont favorables, mieux vaut tester d’abord un rapport généré par IA. L’expérience peut coûter moins d’un dollar.
Si le résultat convient, l’entreprise s’épargne des semaines de développement. Sinon, le test aura au moins clarifié les besoins avant de lancer un projet BI classique.
En conclusion
Un tableau de bord classique peut coûter plusieurs milliers de dollars et demander des semaines. Un rapport généré par IA coûte quelques centimes par exécution et part d’une demande en langage naturel.
Cela ne les rend pas équivalents. Mais cela crée une catégorie nouvelle, entre le tableur et la BI complète. Pour beaucoup d’entreprises de taille moyenne, d’équipes opérationnelles et de besoins de reporting au niveau d’un service, c’est peut-être exactement cette couche qui manquait.
L’enseignement pratique est simple : avant de vous engager dans un déploiement BI lourd, essayez de générer un rapport directement au-dessus de données structurées. Vous découvrirez peut-être que la solution légère va bien plus loin que prévu. Et si ce n’est pas le cas, vous comprendrez plus clairement pourquoi la BI vous reste nécessaire.
