Faire tourner un LLM on-premise n'est que la première étape.
Si l'objectif est l'analyse de feuilles de calcul par l'IA, le point de terminaison (endpoint) du modèle ne suffit pas. Un utilisateur métier ne veut pas envoyer du JSON brut à un serveur d'inférence interne. Il veut télécharger un classeur, poser une question, obtenir une réponse fiable, générer un graphique et savoir d'où proviennent les chiffres.
Cela nécessite une architecture structurée autour du modèle.
Ce guide explique les principaux composants d'un système d'analyse de tableurs par l'IA on-premise.
Architecture de référence
Une architecture pratique pour l'analyse de tableurs par l'IA on-premise ressemble à ceci :
L'ordre peut varier, mais le principe reste le même : le LLM doit raisonner et expliquer, tandis que des systèmes contrôlés gèrent l'accès aux données, le calcul, la sécurité et l'auditabilité.
Identité et contrôle d'accès
Tout commence par l'identité.
Chaque réponse de l'IA doit être liée à un utilisateur, un espace de travail, un fichier et une décision d'autorisation.
Les déploiements en entreprise nécessitent généralement :
- SSO via SAML ou OIDC
- Contrôle d'accès basé sur les rôles (RBAC)
- Correspondance de groupes depuis le fournisseur d'identité
- Autorisations au niveau de l'espace de travail
- Autorisations au niveau du fichier
- Listes d'autorisation de jeux de données
- Contrôles administratifs
Si le système se connecte à des bases de données ou à du stockage objet, il ne doit pas contourner les permissions existantes. L'IA ne doit pas devenir un raccourci pour contourner la gouvernance.
Ingestion des classeurs
L'ingestion de feuilles de calcul est plus complexe qu'il n'y paraît.
Un classeur réel peut contenir :
- Plusieurs feuilles
- Des feuilles masquées
- Des formules
- Des cellules fusionnées
- Des en-têtes incohérents
- Des plages nommées
- Des commentaires
- Un formatage porteur de sens
- Des feuilles protégées
- Des graphiques et des tableaux croisés dynamiques
- Des liens externes
- Des macros
Un système de production doit analyser suffisamment cette structure pour éviter de donner au modèle une vue déformée des données.
Pour la sécurité, les fichiers avec macros doivent être manipulés avec précaution. Si le système exécute quoi que ce soit, il doit le faire dans un bac à sable (sandbox). Dans de nombreux déploiements, les macros doivent être analysées, bloquées ou traitées comme des métadonnées plutôt qu'exécutées.
Compréhension du tableur
Après l'ingestion, le système doit construire une représentation utile du classeur.
Cela peut inclure :
- Des résumés de feuilles
- Les limites des tableaux
- Les noms de colonnes et les types inférés
- Des exemples de lignes
- Des cartes de dépendance des formules
- Les métriques détectées
- Les plages de dates
- Les valeurs manquantes
- Les anomalies
- Les relations entre les feuilles ou les fichiers
C'est cette représentation que le modèle doit voir en premier. Envoyer un classeur entier dans un prompt est généralement inefficace et risqué.
L'objectif est de donner au modèle assez de contexte pour planifier l'étape suivante, pas de lui faire mémoriser tout le fichier.
Couche de calcul déterministe
Pour l'IA appliquée aux tableurs, c'est l'un des composants les plus critiques.
Le modèle ne doit pas calculer de chiffres critiques en interne. Il doit appeler des outils.
La couche de calcul peut inclure :
- Des formules de tableur
- SQL
- DuckDB
- pandas
- Polars
- Le pushdown vers l'entrepôt de données (warehouse)
- La génération de graphiques
- Des vérifications de validation
Par exemple, si un utilisateur demande les meilleurs clients par chiffre d'affaires, le modèle identifie les champs corrects et produit une requête. La couche de calcul exécute la requête. Le modèle explique ensuite le résultat.
Cette séparation améliore la précision, la vitesse et l'auditabilité.
Hébergement privé du modèle
La couche de modèle peut être servie de plusieurs manières.
vLLM est couramment utilisé pour l'inférence auto-hébergée à haut débit et fournit un serveur compatible OpenAI.
KServe est utile lorsque l'organisation souhaite un service de modèle natif Kubernetes et des services d'inférence standard.
NVIDIA NIM fournit des microservices d'inférence optimisés pour l'infrastructure accélérée par NVIDIA.
Ollama est utile pour les pilotes et les tests locaux, bien que les déploiements en production nécessitent souvent une mise à l'échelle, un contrôle d'accès et une observabilité plus robustes.
La couche de modèle doit être traitée comme une infrastructure interne :
- Authentifiée
- Versionnée
- Surveillée
- Isolée par des contrôles réseau
- Configurée avec des politiques de rétention de données claires
- Évaluée avant les mises à jour de modèle
Orchestration de l'IA
La couche d'orchestration décide de la manière dont le système utilise le modèle et les outils.
Elle gère :
- Les modèles de prompts (templates)
- La sélection du modèle
- La sélection des outils
- La construction du contexte
- Les questions de clarification
- La validation des requêtes
- Le sandboxing du code
- La logique de réessai (retry)
- Le formatage des réponses
C'est dans cette couche que se situent de nombreux contrôles de sécurité.
Par exemple, si le modèle génère du SQL, le système doit valider que le SQL est en lecture seule, limité aux tables autorisées et pas trop coûteux. Si le modèle génère du Python, le système doit l'exécuter dans un bac à sable avec l'accès réseau désactivé, sauf autorisation explicite.
Auditabilité
Les journaux d'audit (audit logs) ne sont pas optionnels dans les déploiements sérieux.
Un journal utile doit inclure :
- L'utilisateur
- L'horodatage
- Le classeur ou le jeu de données consulté
- Le prompt
- Le nom et la version du modèle
- La requête, la formule ou le code généré
- Les sorties des outils
- La réponse finale
- Les décisions d'autorisation
- Les erreurs et les solutions de repli (fallbacks)
Cela ne signifie pas que chaque valeur sensible doit être stockée indéfiniment. La rétention doit être configurable. Mais le système a besoin de suffisamment de traçabilité pour la révision, le débogage et la conformité.
Observability
Les équipes techniques doivent surveiller à la fois l'infrastructure et la qualité des réponses.
Métriques d'infrastructure :
- Latence
- Utilisation du GPU
- Profondeur de la file d'attente
- Utilisation des tokens
- Erreurs du modèle
- Temps d'exécution des outils
- Utilisation du stockage
Métriques de qualité :
- Exactitude des réponses
- Qualité des citations
- Validité des formules
- Taux de réussite des requêtes
- Corrections des utilisateurs
- Rapports d'hallucinations
- Échecs de clarification
Sans observabilité, les équipes ne peuvent pas savoir si l'analyste IA s'améliore ou s'il produit discrètement un travail peu fiable.
Pièges courants
Traiter le modèle comme le moteur du tableur
Cela conduit à des totaux hallucinés et des réponses fragiles. Utilisez des outils pour les calculs.
Récupérer d'abord et filtrer ensuite
Les permissions doivent être appliquées avant que le contexte n'atteigne le modèle.
Ignorer la complexité des classeurs
Les démos sur fichiers CSV ne prouvent pas que le système peut gérer de vrais fichiers Excel.
Journaliser trop de données sensibles
L'auditabilité est importante, mais les journaux doivent également respecter les règles de rétention et de confidentialité.
Construire autour d'un seul modèle
Les modèles évoluent rapidement. Concevez le flux de travail pour que le modèle puisse être remplacé facilement.
Plan de déploiement progressif
Un déploiement réaliste peut se faire par étapes.
- Prototyper avec des tableurs d'exemple ou anonymisés.
- Valider les tâches d'analyse courantes et les cas d'échec.
- Ajouter le calcul déterministe pour tout le travail numérique.
- Connecter l'identité et les permissions avant d'utiliser des fichiers réels.
- Déployer un point de terminaison de modèle privé via vLLM, KServe, NIM ou une autre pile approuvée.
- Ajouter les journaux d'audit et la surveillance.
- Piloter avec une équipe, généralement la finance, les opérations ou le reporting des ventes.
- Évaluer les résultats par rapport à des réponses connues avant d'étendre l'usage.
Cela évite l'erreur classique de transformer une démo de modèle en système de production avant que la couche de gouvernance n'existe.
Le rôle de RowSpeak
RowSpeak peut agir comme la couche de flux de travail au-dessus des points de terminaison de modèles privés et de l'exécution de données gouvernée.
Le serveur de modèle fournit le raisonnement. RowSpeak fournit l'expérience tableur : téléchargement de classeur, questions en langage naturel, graphiques, résumés, rapports et flux d'analyse orientés utilisateur, tels que le reporting hebdomadaire des ventes.
Pour les déploiements on-premise, cette séparation est précieuse. L'IT peut contrôler le modèle et l'infrastructure. Les utilisateurs métier peuvent continuer à travailler via une interface conçue pour l'analyse de tableurs plutôt que par des appels d'API bruts, que le résultat final soit un tableau de bord IA ou un rapport financier.
Note finale
Un point de terminaison LLM on-premise est une infrastructure. Un analyste de tableurs IA on-premise est une expérience produit doublée d'une gouvernance.
Le modèle est important, mais c'est l'architecture qui l'entoure qui détermine si le système est digne de confiance. Pour un exemple spécifique à un modèle, consultez le guide sur l'auto-hébergement de DeepSeek pour RowSpeak.
Sources et lectures complémentaires
- Serveur vLLM compatible OpenAI : https://docs.vllm.ai/en/latest/serving/openai_compatible_server/
- KServe : https://kserve.github.io/website/
- NVIDIA NIM : https://www.nvidia.com/en-us/ai-data-science/products/nim-microservices/
- Bibliothèque Ollama : https://ollama.com/library
- llama.cpp : https://github.com/ggml-org/llama.cpp
