Le tournant silencieux : de « interroger le modèle » à « orchestrer des agents sur la donnée »
En 2024 et pendant une bonne partie de 2025, la conversation sur les modèles de langage appliqués à l’analyse de données tournait autour du chat : coller un CSV, demander un graphique, obtenir un tableau. Ce schéma s’essouffle. Ce qui domine les nouveautés récentes est autre chose : des modèles qui ne répondent pas avec du texte, mais qui exécutent du code, consultent des catalogues, valident des hypothèses et renvoient des résultats auditables.
La différence pratique est énorme. Un chat qui « interprète » un CSV hallucine des lignes et des moyennes avec une facilité inquiétante. Un agent qui exécute du SQL ou du Python contre un entrepôt réel ne peut pas inventer un chiffre sans que le moteur de base de données proteste. C’est là l’axe du changement : le modèle cesse d’être l’analyste et devient le planificateur qui écrit des requêtes et vérifie les résultats.
Text-to-SQL mature : où ça fonctionne et où ça continue de casser
La génération de requêtes SQL à partir du langage naturel est l’application la plus répandue, et aussi la plus surestimée en démo. Selon la documentation officielle des principaux fournisseurs de bases de données analytiques, les benchmarks publics de text-to-SQL se sont améliorés de manière soutenue, mais ces chiffres sont obtenus sur des schémas propres, avec des noms de colonnes explicites et sans ambiguïté sémantique.
Dans un entrepôt réel, les choses changent. Un cas qui se répète : la table s’appelle fact_ventas_v3, il existe une fact_ventas_v2 qui n’est plus mise à jour mais reste vivante, et il y a une colonne importe qui est en réalité en centimes dans les lignes antérieures à une migration précise. Aucun modèle ne devine cela. C’est un catalogue de données avec des descriptions, du lignage et des règles métier documentées qui le résout.
Ce qui fonctionne réellement
- Les requêtes d’exploration sur un domaine restreint (un département, un ensemble de tables fermé).
- La traduction de questions fréquentes en requêtes paramétrées préalablement revues par un humain.
- La génération de brouillons de SQL qu’un analyste corrige en quelques secondes au lieu de les écrire de zéro.
Ce qui ne fonctionne pas (et qu’il vaut mieux admettre)
- Les questions qui exigent de connaître des définitions métier non écrites (« clients actifs » peut signifier cinq choses différentes).
- Les schémas avec des centaines de tables sans descriptions : le taux d’erreur explose.
- Les calculs où un JOIN mal choisi duplique des lignes et où personne ne le détecte avant que le rapport n’arrive à la direction.
Agents avec exécution de code : le schéma qui s’impose
L’approche qui a le plus progressé consiste à donner au modèle un interpréteur de code isolé. Le modèle écrit du pandas, du DuckDB ou du R, l’exécute, lit la sortie et, en cas d’erreur, itère. Cela présente un avantage décisif pour l’analyse : le résultat est reproductible. Vous pouvez sauvegarder le script, le versionner et le réexécuter le mois suivant.
Il y a ici un détail que l’on n’apprend qu’en utilisant ces outils au quotidien : la plupart des échecs ne viennent pas du raisonnement statistique, mais de la gestion des types et des valeurs nulles. Des dates dans des formats mélangés, des catégories avec des espaces finaux, des montants avec virgule décimale hérités d’un ancien export. Un modèle puissant écrit un groupby impeccable puis regroupe mal parce que « Madrid » et « Madrid » sont deux valeurs distinctes. La solution n’est pas un meilleur modèle : c’est une couche de nettoyage préalable et des validations explicites.
Intégration avec le stack : MCP et catalogues sémantiques
La nouveauté architecturale la plus marquante des derniers mois est la standardisation des connecteurs. Le protocole ouvert promu pour connecter les assistants à des sources de données (connu sous le nom de MCP) permet à un même modèle d’interroger un entrepôt, un CRM et un tableur sans que chaque intégration soit un développement sur mesure.
Cela a une conséquence que les organisations commencent à assumer : la valeur n’est plus dans le modèle, elle est dans la couche sémantique. Définir les métriques une seule fois (revenus nets, churn, marge) et les exposer comme des outils que le modèle peut invoquer, voilà ce qui sépare un pilote séduisant d’un système qui survit au troisième mois.
Un schéma qui apparaît dans les équipes ayant déjà passé la phase de test : moins de prompts longs, plus de fonctions enregistrées avec un nom et une description précise. Le modèle choisit parmi dix outils bien documentés au lieu d’improviser du SQL sur cinquante tables.
Évaluation : le problème que presque personne ne résout bien
Mesurer si un LLM analyse bien est plus difficile que de le faire fonctionner. Les benchmarks publics ne reflètent pas vos données. La pratique qui se consolide parmi les équipes matures est de construire un ensemble de questions à réponse vérifiée manuellement sur son propre entrepôt, et de l’exécuter à chaque changement de modèle ou de prompt.
Sans cet ensemble d’évaluation, toute migration vers un nouveau modèle est un pari à l’aveugle. Et il y a ici une nuance qu’il convient de garder à l’esprit : progresser sur un benchmark générique ne garantit pas de progresser sur votre domaine. Nous avons vu des modèles baisser en performance sur des tâches d’agrégation avec des hiérarchies de dates parce qu’ils changent de style de raisonnement, non parce qu’ils sont moins bons.
Coût et latence : le facteur qui décide de l’architecture
Une analyse interactive tolère deux secondes d’attente ; un rapport programmé qui s’exécute sur des milliers de lignes chaque nuit ne tolère pas le coût d’un grand modèle pour chaque requête. D’où la tendance aux architectures hybrides :
- Des modèles petits ou des règles déterministes pour les questions fréquentes et bien typifiées.
- Des modèles grands uniquement pour l’exploration ouverte et le débogage d’erreurs.
- Un cache de résultats pour les requêtes répétées, qui sont en pratique la majorité.
La dépense en tokens devient une véritable ligne de coût opérationnel lorsque le système est utilisé par vingt personnes au quotidien. Concevoir sans en tenir compte, c’est la voie rapide vers l’annulation du projet.
Gouvernance et confidentialité : la conversation qui arrive tard mais qui arrive
Envoyer des données clients à un fournisseur externe exige de revoir les contrats, la rétention et la résidence de la donnée. Les options de déploiement privé et les modèles exécutés sur une infrastructure propre ont suffisamment mûri pour être viables dans les secteurs régulés, mais avec un coût de maintenance que beaucoup d’entreprises sous-estiment.
Une erreur courante : supposer que « le fournisseur n’entraîne pas ses modèles avec mes données » résout le problème. Cela ne le résout pas si la donnée sort de votre périmètre. La décision réelle est architecturale, pas contractuelle.
Ce qu’il faut surveiller dans les prochains mois
- La vérification des résultats : des mécanismes qui confrontent la sortie du modèle à une source de vérité avant de l’afficher.
- Le lignage automatique : savoir de quelle table et de quelle transformation provient chaque chiffre que le système présente.
- Les interfaces hybrides : le chat ne disparaît pas, mais il cohabite avec des dashboards où le LLM ne fait que rédiger l’explication du graphique.
- L’évaluation continue : des suites propres exécutées à chaque mise à jour du modèle.
La conclusion honnête est que les LLM apportent déjà une valeur claire en exploration, en documentation des données et en génération assistée de requêtes, et qu’ils restent fragiles dans toute tâche où un chiffre erroné a des conséquences. Concevoir avec cette asymétrie à l’esprit, en plaçant la donnée et la validation au centre et le modèle en périphérie, c’est aujourd’hui la différence entre une expérimentation et un système en production.