De nombreuses équipes en entreprise recherchent la même chose : un analyste de type ChatGPT pour les données de la société.
Elles souhaitent poser des questions en langage naturel et obtenir des réponses à partir de feuilles de calcul, de bases de données, de tableaux de bord et de rapports internes. Elles veulent la rapidité de l'IA sans perdre le contrôle sur leurs données sensibles.
Cela semble simple, jusqu'à ce que l'on tente de le construire.
Un système d'analyse de données par IA privée n'est pas un simple chatbot connecté à des fichiers. Il nécessite un accès gouverné, des calculs fiables, des journaux d'audit, un service de modèles et une expérience utilisateur adaptée aux méthodes de travail réelles des équipes.
Ce que les entreprises entendent par analyse de données par IA privée
Lorsqu'une entreprise demande des analyses par IA privée, elle exprime généralement plusieurs besoins simultanés :
- Les données ne doivent pas être envoyées vers des outils d'IA publics non approuvés.
- Les utilisateurs ne doivent voir que les données qu'ils sont autorisés à consulter.
- Les fichiers sensibles doivent rester dans des espaces de stockage approuvés.
- Les calculs doivent être traçables.
- Les prompts et les résultats doivent être auditables.
- Les modèles doivent s'exécuter dans un environnement approuvé.
- Les administrateurs doivent contrôler la rétention et la journalisation.
C'est pourquoi les démos d'IA génériques déçoivent souvent les acheteurs en entreprise. La démo répond à une question. Le système réel doit répondre à la question tout en respectant l'identité, les permissions, le lignage des données et les exigences de conformité.
Pourquoi un chatbot ne suffit pas
Un chatbot peut résumer du texte, aider à expliquer un rapport ou rédiger une réponse.
Mais l'analyse est différente. De nombreuses questions commerciales nécessitent des calculs.
Considérez cette question :
Pourquoi la marge brute a-t-elle baissé au troisième trimestre, et quelle région y a le plus contribué ?
Une réponse utile nécessite plusieurs étapes :
- Identifier les bons champs de revenus et de coûts.
- Appliquer la formule de la marge.
- Filtrer sur le T3.
- Comparer avec la période précédente.
- Grouper par région.
- Calculer la contribution au changement.
- Expliquer le résultat avec des preuves à l'appui.
Un système basé uniquement sur la recherche (retrieval) peut trouver un document mentionnant la marge, mais il ne calculera pas la réponse de manière fiable.
Pour l'analyse en entreprise, le RAG est utile, mais il ne suffit pas.
Les quatre couches d'un analyste IA privé
Un système pratique repose sur quatre couches.
1. Couche d'interface
C'est ici que les utilisateurs posent des questions et consultent les réponses.
Il peut s'agir de :
- Une interface de feuille de calcul.
- Une barre latérale de chat.
- Un assistant de tableau de bord.
- Une application web interne.
- Une API pour les outils existants.
Pour les équipes métier, l'interface de feuille de calcul est souvent la plus naturelle. C'est là que l'analyse ad hoc se produit déjà.
2. Couche de raisonnement
Il s'agit de la couche LLM ou agent.
Elle interprète la question de l'utilisateur, pose des questions de clarification, choisit les outils, écrit du SQL ou des formules, et explique les résultats.
Elle ne doit pas être considérée comme la source de vérité pour les calculs.
3. Couche d'exécution
C'est ici que le travail réel sur les données s'effectue.
La couche d'exécution peut utiliser :
- Des entrepôts de données SQL.
- DuckDB.
- pandas ou Polars.
- Des moteurs de formules de feuilles de calcul.
- Des couches sémantiques de BI.
- Des API internes.
Cette couche calcule les chiffres, joint les tables, filtre les lignes et renvoie des preuves structurées.
4. Couche de gouvernance
Cette couche contrôle qui peut accéder à quoi, ce qui est consigné, combien de temps les données sont conservées et comment les résultats sont révisés.
Elle comprend :
- Le SSO et le RBAC (contrôle d'accès basé sur les rôles).
- Des politiques au niveau des lignes et des colonnes.
- Des journaux d'audit.
- Des contrôles de rétention des prompts et des réponses.
- Le lignage des données (data lineage).
- La suppression des données sensibles.
- Les permissions relatives aux modèles et aux outils.
Sans cette couche, un analyste IA privé n'est pas prêt pour l'entreprise.
RAG vs analyse directe
Le RAG est utile lorsque la question porte sur du texte.
Exemples :
- Que dit cette politique ?
- Comment le revenu net est-il défini ?
- Quel rapport explique la méthodologie d'attrition (churn) ?
Le calcul direct est nécessaire lorsque la question porte sur des données chiffrées.
Exemples :
- Quelle région a causé la baisse ?
- Quels sont les cinq principaux clients par marge ?
- Quelles dépenses ont été inhabituelles ce mois-ci ?
- Qu'est-ce qui a changé entre ces deux exports ?
La meilleure architecture d'entreprise combine les deux.
Utilisez le RAG pour récupérer les définitions, le contexte métier et la documentation. Utilisez le SQL, les formules de tableur ou Python pour calculer les résultats. Utilisez ensuite le modèle pour expliquer la réponse en langage clair.
Exigences de gouvernance qui ne peuvent être ajoutées plus tard
La gouvernance doit être conçue dès le départ.
Un système d'analyse de données par IA privée doit pouvoir répondre à :
- Qui a posé la question ?
- À quelles données le système a-t-il accédé ?
- Quel modèle a répondu ?
- Quels outils ont été exécutés ?
- Quelle requête ou formule a été générée ?
- Quel résultat a été renvoyé ?
- Des données sensibles ont-elles été masquées ?
- Un autre utilisateur pourrait-il reproduire ou réviser la réponse ?
Ces questions sont cruciales pour les équipes réglementées, mais elles comptent aussi pour les opérations commerciales normales. Si une réponse d'IA influence une prévision ou un rapport de direction, il faut savoir d'où elle vient.
Observabilité et évaluation
L'analyse par IA en entreprise nécessite plus qu'une simple surveillance de la disponibilité (uptime).
Les mesures opérationnelles incluent :
- La latence.
- L'utilisation des tokens.
- Les erreurs de modèle.
- Les échecs d'appels d'outils.
- Le temps d'exécution des requêtes.
- L'utilisation des GPU.
- Le coût par question.
Les mesures de qualité incluent :
- L'exactitude de la réponse.
- La précision des citations.
- La validité du SQL.
- La validité des formules.
- Les incidents d'hallucination.
- Le taux de correction par l'utilisateur.
- Le taux de clarification.
Les meilleures équipes créent un ensemble de tests basés sur des questions réelles et des réponses attendues. Elles l'exécutent avant de modifier les modèles, les prompts, les outils ou les paramètres de recherche.
Besoins spécifiques aux feuilles de calcul
Les feuilles de calcul constituent un cas particulier car elles sont flexibles et souvent désordonnées.
Un système de production doit gérer :
- Les feuilles multiples.
- Les feuilles masquées.
- Les formules.
- Les cellules fusionnées.
- Les plages nommées.
- Les commentaires.
- Les en-têtes incohérents.
- Les exports CSV.
- Les résumés de type tableau croisé dynamique.
- Les formats locaux de date et de devise.
C'est pourquoi l'IA pour feuilles de calcul diffère d'un Q&A documentaire générique. Le système doit comprendre la structure et effectuer des calculs, pas seulement résumer du texte.
Développer ou acheter
Construire son propre analyste de données par IA privée offre un contrôle maximal, mais exige une ingénierie conséquente. De nombreuses équipes cartographient d'abord l'étendue du produit dont elles ont besoin, du reporting par IA à la diffusion de tableaux de bord, avant de décider quoi construire :
- Service de modèles.
- Analyse de classeurs (workbooks).
- Orchestration de prompts.
- Connecteurs de données.
- Exécution en bac à sable (sandboxed).
- Contrôle d'accès.
- Journalisation d'audit.
- Évaluation.
- Interface utilisateur.
Acheter ou déployer une couche de flux de travail spécialisée peut raccourcir ce chemin.
L'essentiel est d'éviter de lier toute la stratégie à un seul modèle. Les modèles évoluent rapidement. La partie durable est le flux de travail gouverné autour des données de l'entreprise.
Le rôle de RowSpeak
RowSpeak est conçu pour l'analyse par IA native pour les feuilles de calcul, particulièrement lorsque les équipes ont besoin d'une analyse de données par IA sans exposer les utilisateurs à des points de terminaison de modèles bruts.
Dans une architecture privée, RowSpeak peut se situer au-dessus des modèles et des systèmes de données approuvés. Le modèle assure le raisonnement. RowSpeak fournit le flux de travail pour télécharger des feuilles de calcul, poser des questions, générer des graphiques, produire des résumés et maintenir l'analyse liée aux données sous-jacentes.
Cela différencie RowSpeak d'un simple serveur de modèles. C'est la couche qui transforme une capacité d'IA privée en une expérience d'analyste utilisable pour les équipes métier, similaire à la stratégie décrite dans Stratégie de données pour l'intelligence d'affaires par IA.
Conclusion
Un analyste IA privé n'est pas simplement un modèle et un prompt. C'est un système gouverné.
Le modèle gagnant est le suivant :
Raisonnement LLM + calcul déterministe + accès aux données respectueux des permissions + auditabilité + un flux de travail que les utilisateurs comprennent déjà.
Pour de nombreuses équipes en entreprise, ce flux de travail commence encore par des feuilles de calcul.
Sources et lectures complémentaires
- KServe : https://kserve.github.io/website/
- NVIDIA NIM : https://www.nvidia.com/en-us/ai-data-science/products/nim-microservices/
- Couche sémantique dbt : https://docs.getdbt.com/docs/use-dbt-semantic-layer/dbt-sl
- Snowflake Cortex Analyst : https://docs.snowflake.com/en/user-guide/snowflake-cortex/cortex-analyst
- Serveur vLLM compatible OpenAI : https://docs.vllm.ai/en/latest/serving/openai_compatible_server/
