Pour interroger des fichiers Excel en langage naturel, l'approche qui donne des chiffres justes est l'agent équipé d'un outil qui lit le classeur par plage et calcule en code, pas le RAG. Le passage en base SQL vient en deuxième position, uniquement quand le classeur est déjà une table propre, et le RAG sur fichiers Excel ne sert qu'à retrouver un onglet ou un commentaire, jamais à sortir un total.
Le cas type : une PME de 40 à 200 personnes tient ses tarifs, ses stocks, le planning et le suivi commercial dans une dizaine de classeurs partagés. Le dirigeant veut poser la question « quelle marge sur la gamme X en août » sans ouvrir trois fichiers.
Pourquoi un RAG répond à côté quand on lui donne un classeur Excel ?
Parce qu'un RAG découpe le fichier en morceaux de texte, et qu'un tableau perd son sens dès qu'on le coupe. La ligne 412 sans son en-tête est une suite de nombres. La cellule fusionnée qui titrait la colonne sur trois lignes disparaît. La formule SOMME(D2:D400) devient soit sa valeur figée au moment de l'export, soit une chaîne de caractères sans intérêt.
Le modèle reçoit ensuite les cinq ou dix morceaux les plus proches de la question et tente une addition mentale sur des fragments. Il produit un chiffre plausible, présenté avec assurance, souvent faux. Sur FinSheet-Bench (mars 2026), les trois meilleurs modèles du marché atteignent 93,6 % sur des recherches simples dans des feuilles financières, et tombent à 33,3 % sur les agrégations en plusieurs étapes. Les auteurs concluent qu'aucun modèle seul n'atteint un taux d'erreur compatible avec un usage financier non supervisé.
Le RAG garde une utilité. Il retrouve très bien « le fichier où on a noté les conditions de remise du client Durand ». On l'utilise pour localiser, jamais pour calculer. Notre guide de préparation d'une base documentaire pour le RAG détaille ce qui se prête au découpage, et Excel n'en fait pas partie.
Convertir le classeur en base et générer du SQL, ça marche dans quels cas ?
Quand le classeur est en réalité une base de données qui s'ignore. Un onglet, une ligne d'en-tête, un enregistrement par ligne, pas de sous-totaux intercalés, pas de couleurs porteuses de sens. Dans ce cas, on charge le fichier dans SQLite, DuckDB ou Postgres, le modèle génère une requête, la base l'exécute, et le chiffre est exact parce que c'est le moteur SQL qui a additionné, pas le modèle.
Le problème se déplace alors vers la génération de la requête. Sur des schémas simples, le text-to-SQL fonctionne bien. Sur des schémas réels d'entreprise, les résultats chutent. Le benchmark Spider 2.0 (novembre 2024, 632 tâches tirées de vrais entrepôts de données) donne 21,3 % de réussite à un modèle qui obtient 91,2 % sur l'ancien Spider 1.0. La différence tient aux colonnes mal nommées, aux jointures entre onglets et aux conventions métier que personne n'a écrites. Nous avons documenté ces modes d'échec dans notre analyse des limites du text-to-SQL en entreprise.
Le point qui fait mal en PME, c'est la maintenance. Un contrôleur de gestion insère une colonne « remarques » en C, tout le chargement décale. Une ligne de total ajoutée en bas devient un enregistrement fantôme. Il faut un script d'import qui vérifie les en-têtes à chaque exécution et refuse le fichier s'ils ont bougé. Sans ce garde-fou, la base se remplit de données fausses en silence, ce qui est pire qu'une panne.
Que change un agent qui exécute des opérations sur le classeur ?
Il change le lieu du calcul. L'agent ne lit pas le fichier comme un texte, il reçoit des outils : lister les onglets, lire une plage, agréger. Face à « quelle marge sur la gamme X en août », il lit l'onglet Ventes, filtre sur la date, calcule en Python, puis répond avec le chiffre et la plage utilisée. On peut vérifier.
Deux façons de brancher ces outils. La première, un appel de fonction propriétaire dans l'application : simple, mais lié à un fournisseur de modèle. La deuxième, un serveur exposé via le Model Context Protocol, standard ouvert d'Anthropic que Claude, ChatGPT, VS Code et Cursor savent consommer. Le même serveur qui expose « lire une plage » à un agent maison sert ensuite à un assistant de bureau sans rien réécrire. Pour le raisonnement complet entre les deux architectures, voir MCP ou RAG, comment choisir.
Côté fiabilité, l'agent gagne sur les agrégations parce qu'il ne calcule jamais lui-même. Il reste faillible sur le choix de la plage : lire l'onglet 2025 au lieu de 2026, oublier une feuille cachée. SpreadsheetBench 2 (juin 2026), qui évalue des agents sur 321 flux de travail multi-onglets, plafonne le meilleur agent à 34,89 % de tâches réussies de bout en bout. Ces tâches demandent en moyenne 593 modifications de cellules, loin d'une question de reporting, mais le chiffre remet les promesses commerciales à leur place. En production, on limite les outils à la lecture et à l'agrégation, on interdit l'écriture dans le classeur source, et on affiche toujours la plage lue à côté du chiffre.
Quel type de fichier appelle quelle approche ?
Le tableau ci-dessous résume les arbitrages qu'on fait en cadrage. Les efforts sont des ordres de grandeur constatés en PME, pas des devis.
| Type de fichier | Approche recommandée | Pourquoi | Effort et maintenance |
|---|---|---|---|
| Un onglet plat, une ligne d'en-tête, mis à jour chaque semaine (suivi commercial, export CRM) | Import en base et SQL généré | Le fichier est déjà une table, le moteur SQL fait le calcul | Faible au départ, script de contrôle des en-têtes obligatoire |
| Classeur multi-onglets avec formules croisées et sous-totaux (grille tarifaire, budget) | Agent avec outils de lecture par plage | La structure porte du sens que l'import à plat détruit | Moyen, deux à quatre semaines, peu de maintenance si les outils sont génériques |
| Planning avec cellules fusionnées, couleurs et commentaires | Agent, après reconstruction d'une table intermédiaire | Les couleurs et fusions ne sont lisibles que par du code dédié | Élevé, souvent le signal qu'il faut changer d'outil |
| Dossier de dizaines de fichiers hétérogènes, questions de type « où est » | RAG sur les métadonnées et les textes, pas sur les chiffres | On cherche un fichier, on ne calcule rien | Faible, mais aucune promesse sur les montants |
| Fichier de 200 000 lignes et plus, alimenté par plusieurs personnes | Sortir d'Excel vers une base de données | Excel n'est plus le bon contenant, quelle que soit l'IA posée dessus | Projet data classique, l'IA vient après |
Une remarque sur les outils grand public. Copilot dans Excel ou l'analyse de fichiers de ChatGPT, qui repose sur Code Interpreter et exécute du Python dans un conteneur qui expire après 20 minutes d'inactivité, relèvent de la troisième approche. Ils sont très bons pour une analyse ponctuelle sur un fichier qu'on vient de déposer. Ils ne savent pas surveiller un dossier, appliquer des droits par utilisateur ni garder une trace des réponses. Pour un usage d'équipe, on construit.
Qui voit quoi : comment gérer les droits sur des fichiers Excel interrogés par une IA ?
La sécurité se règle au niveau des outils, pas du modèle. Les salaires figurent parfois dans un onglet masqué du fichier planning, et un assistant qui lit tout le fichier pour tout le monde les expose au premier qui pose la bonne question.
Avec un RAG, le filtrage par utilisateur se fait sur les morceaux indexés, et un onglet masqué se retrouve indexé comme les autres. Avec une base SQL, on s'appuie sur les droits du moteur, ce qui est solide à condition d'avoir prévu une vue par profil. Avec un agent, chaque outil reçoit l'identité de l'utilisateur et refuse les plages non autorisées, ce qui donne le contrôle le plus fin et la trace la plus lisible. On journalise la question, l'outil appelé, la plage lue et la réponse. Le jour où un chiffre est contesté, on sait d'où il vient.
Sur l'hébergement, si les classeurs contiennent des données personnelles ou des prix négociés, le traitement reste en France ou en Europe.
Quand faut-il arrêter de mettre de l'IA sur Excel et changer d'outil ?
Dès que le classeur est modifié par plusieurs personnes en même temps, dépasse la centaine de milliers de lignes ou sert de référence à d'autres fichiers par liaison. À ce stade, l'IA ne répare rien. Elle fournit des réponses justes sur une donnée qui, elle, est déjà fausse ou périmée. Le bon investissement est une base de données et une chaîne d'alimentation, puis un agent branché dessus.
Le cas KAPIMS Pharma montre ce passage. L'équipe consolidait chaque mois 12 sources de données à la main pour produire son reporting. La collecte et la consolidation ont été automatisées, avec des tableaux de bord en temps réel, et 90 % du temps de reporting a été rendu aux équipes. La question en langage naturel devient facile une fois que la donnée est au bon endroit.
On déconseille en revanche de forcer une PME à abandonner Excel pour un fichier qui marche. Une grille tarifaire de 300 lignes tenue par une personne, mise à jour deux fois par an, se lit très bien par un agent. Le changement d'outil coûte plus que le gain.
Comment JUWA met en place l'interrogation de vos fichiers Excel
On commence par un inventaire court des classeurs, quelques jours suffisent. Chaque fichier est classé selon le tableau ci-dessus, avec son propriétaire, sa fréquence de mise à jour et les questions réellement posées dessus. Une bonne partie des classeurs n'a pas besoin d'IA mais d'un import en base, et on le dit.
Pour les fichiers qui le justifient, on développe un serveur MCP branché sur vos données, avec des outils de lecture par plage, d'agrégation et de recherche, des droits par utilisateur et un journal des appels. La première version part en production en 4 à 8 semaines, avec une validation humaine sur les réponses chiffrées tant que le taux d'erreur n'est pas mesuré, et un point hebdomadaire avec un chef de projet joignable en direct. Quand l'inventaire montre que le vrai sujet est le contenant, on le dit dès le cadrage, et le projet devient un projet de données avant d'être un projet d'IA.
