Ce que l’expérience d’Anthropic nous apprend sur une analytique réellement gouvernée

Synthèse critique de l’article publié par Anthropic le 3 juin 2026

La promesse du Talk with Data paraît désormais simple : un collaborateur pose une question en langage naturel, un agent identifie les données utiles, génère une requête SQL et restitue une réponse. En quelques secondes, chacun pourrait accéder à l’information sans attendre un analyste ni apprendre un langage de requête. L’article publié par Anthropic le 3 juin 2026, « How Anthropic enables self-service data analytics with Claude », montre pourtant que cette simplicité apparente repose sur un travail d’architecture, de gouvernance et de contrôle particulièrement exigeant.

Anthropic indique que 95 % de ses requêtes de business analytics sont automatisées par Claude, avec une précision agrégée proche de 95 %. Ces résultats impressionnent, mais le principal enseignement se situe ailleurs. Selon les auteurs, la fiabilité d’un agent analytique dépend moins de sa capacité à écrire du SQL que de sa faculté à retrouver le bon contexte, à sélectionner une définition métier gouvernée et à vérifier la réponse obtenue. En d’autres termes, l’IA ne supprime pas les disciplines historiques de la Business Intelligence. Elle les rend encore plus indispensables.

Cet article revient sur les idées les plus fortes du retour d’expérience d’Anthropic, sur les mécanismes techniques qui rendent leur dispositif crédible et sur les limites qui subsistent. Il permet surtout de comprendre ce que devrait être une architecture Data réellement prête pour l’IA.

Le vrai problème ne réside pas dans la génération de SQL

Les grands modèles de langage savent désormais produire une requête SQL correcte à partir d’une consigne relativement précise. Mais une question métier contient rarement toute la précision nécessaire. Lorsqu’un utilisateur demande combien l’entreprise compte de clients actifs, il ne précise pas toujours ce que signifie « actif », la période de référence, les populations à exclure, le niveau de granularité attendu ni la source officielle à utiliser.

La difficulté consiste donc à relier une formulation humaine à une entité exacte du modèle de données. Anthropic résume ce problème par trois causes principales d’erreur.

La première tient à l’ambiguïté entre le concept et l’entité. Un même terme peut désigner plusieurs mesures, plusieurs champs ou plusieurs populations. Le chiffre d’affaires peut correspondre aux commandes enregistrées, aux factures émises, aux paiements encaissés ou à une mesure retraitée par la finance. Si quarante jeux de données plausibles portent des définitions voisines, l’agent doit choisir parmi quarante réponses techniquement défendables, mais potentiellement incompatibles.

La deuxième cause est l’obsolescence. Les schémas changent, les règles métier évoluent, certaines tables deviennent anciennes et les définitions documentaires cessent de refléter la réalité. Une réponse peut alors reposer sur un raisonnement cohérent et une requête valide, tout en utilisant une connaissance devenue fausse.

La troisième cause est l’échec de recherche. La bonne définition existe parfois dans le système, mais l’agent ne la retrouve pas au milieu de milliers de tables, de champs, de requêtes historiques et de documents. Donner accès à davantage d’information ne garantit donc pas une meilleure réponse. Anthropic constate même que l’accès direct à des milliers d’anciens fichiers SQL a modifié la précision de moins d’un point. Dans environ 80 % des cas où l’agent se trompait, l’information correcte figurait pourtant dans ce corpus. Elle était présente, mais insuffisamment structurée pour guider le raisonnement.

Cette observation change la manière de concevoir la self service BI par l’IA. Il ne suffit pas de connecter un modèle à un entrepôt. Il faut réduire l’espace de recherche, organiser les connaissances et imposer un chemin privilégié vers les sources fiables.

Le retour des fondations Data classiques

La première couche de l’architecture d’Anthropic rassemble les modèles de données, les transformations, les tests, les tables et les métadonnées qui les décrivent. Les auteurs insistent sur les pratiques traditionnelles de data engineering : modélisation dimensionnelle, tables de faits et de dimensions, règles de nommage, contrôles de qualité et documentation maintenue.

Ce rappel mérite d’être souligné. Certaines présentations de l’IA générative laissent penser qu’un agent pourrait absorber le désordre d’un système d’information et reconstruire seul le sens des données. L’expérience d’Anthropic conduit à la conclusion inverse. Plus le modèle de données comporte de vues concurrentes, de définitions implicites et de tables difficiles à distinguer, plus l’agent rencontre d’occasions de produire une réponse plausible mais incorrecte.

La standardisation devient ainsi une condition de fiabilité. Les données les plus importantes doivent disposer de modèles canoniques, suffisamment documentés et reconnus comme références. Cette réduction volontaire du nombre de représentations possibles facilite le travail des utilisateurs humains comme celui des agents.

L’IA peut aider à documenter ces fondations. Elle peut proposer des descriptions de colonnes, repérer des modèles non documentés ou préparer une définition à partir des usages observés. Anthropic maintient toutefois un principe clair : un humain doit rester propriétaire de la définition métier. Une tentative de génération automatique des métriques à partir des tables et des journaux de requêtes a produit des définitions convaincantes en apparence, mais qui reproduisaient les ambiguïtés initiales. Une couche sémantique plus réduite et validée par des humains a obtenu de meilleurs résultats.

La couche sémantique comme chemin de confiance

Dans le dispositif présenté, la couche sémantique occupe le premier rang parmi les sources de vérité. Elle compile les définitions des mesures et des dimensions, ainsi que les filtres, jointures et granularités associés. Lorsqu’une question correspond à une métrique gouvernée, l’agent appelle cette définition et renvoie le même résultat que les autres outils de restitution de l’entreprise.

L’ordre de recherche n’est pas laissé à l’improvisation. L’agent doit consulter la couche sémantique en premier. Si celle-ci ne couvre pas la question, il peut s’appuyer sur la documentation de référence, le lignage et les modèles gouvernés. L’accès aux tables brutes constitue un recours de dernier niveau, avec un degré de confiance inférieur.

Le lignage joue ici un rôle concret. Il aide l’agent à comprendre quelles transformations alimentent un indicateur, quelles tables ont été abandonnées et quels modèles partagent le même grain. Il permet aussi de rattacher une réponse à la fraîcheur de ses sources. La connaissance du contexte métier complète ce dispositif : feuilles de route, décisions, organisation interne et documentation projet aident l’agent à comprendre qu’un nom de lancement, d’équipe ou de produit peut désigner une réalité particulière dans l’entreprise.

La self service analytics devient donc une navigation gouvernée dans des niveaux de confiance. L’utilisateur accède facilement à la donnée, mais cette facilité repose sur des chemins préparés, des définitions explicites et une hiérarchie des sources.

Les skills transforment la connaissance en procédure

La contribution la plus originale de l’article concerne probablement les skills. Anthropic distingue les connaissances déclaratives des connaissances procédurales. La couche sémantique explique ce qu’une mesure signifie. Un skill indique comment l’agent doit travailler : quelles sources consulter, dans quel ordre, quels filtres appliquer, quelles ambiguïtés clarifier et comment vérifier le résultat.

Un premier skill joue le rôle de routeur. Il dirige la question vers le domaine pertinent et limite la recherche à quelques dizaines de fichiers de référence décrivant les tables, leur grain, leur périmètre, les exclusions et les pièges connus. Un second skill fonctionne comme le manuel opératoire d’un analyste expérimenté. Il décrit la démarche à suivre, de la clarification de la demande jusqu’à la revue contradictoire de la réponse, et contient des méthodes réutilisables pour des analyses telles que la rétention, les tunnels de conversion ou la décomposition d’un taux.

L’effet mesuré par Anthropic est considérable. Sans skills, Claude ne dépassait pas 21 % de précision sur leurs évaluations analytiques. Avec les skills et l’ensemble de la structure associée, la précision dépassait régulièrement 95 % en agrégé et atteignait environ 99 % dans certains domaines.

Ces chiffres ne prouvent pas une performance universelle de Claude. Ils montrent en revanche combien une procédure explicite améliore un agent. Le modèle ne reçoit plus seulement des tables et une question. Il reçoit aussi les habitudes de travail qu’un analyste senior transmettrait à un nouveau collaborateur.

Cette connaissance doit néanmoins rester synchronisée avec la plateforme Data. Anthropic a observé une chute de la précision hors ligne, d’environ 95 % à 65 % en un mois, lorsque les skills n’étaient pas maintenus assez activement. L’entreprise a donc placé les fichiers de skills dans le même dépôt que les modèles de transformation. Une modification du modèle doit s’accompagner d’une mise à jour de la documentation procédurale. Environ 90 % des demandes de modification de modèles Data incluent désormais un changement de skill dans le même ensemble de différences.

L’évaluation devient une composante du pipeline analytique

Une plateforme Data traditionnelle teste ses transformations, ses schémas et certaines règles de qualité. Une plateforme analytique agentique doit aussi tester la chaîne qui relie la question de l’utilisateur à la réponse finale.

Anthropic utilise des évaluations hors ligne constituées de couples question-réponse. Certaines proviennent des tableaux de bord et couvrent les questions fréquentes. D’autres explorent les cas moins courants à partir du contexte métier. Les corrections apportées par les utilisateurs deviennent également de nouveaux cas de test.

La vérité de référence doit rester stable. Un résultat calculé sur des données vivantes finit par changer. Les équipes peuvent donc fixer une date de photographie, s’appuyer sur une table stable ou évaluer la requête produite plutôt que le chiffre lui-même. Chaque exécution conserve la version du skill, le commit Git, le modèle utilisé, les résultats de chaque assertion, la consommation de jetons et la durée. Ces éléments transforment les évaluations en télémétrie exploitable et permettent de suivre les régressions dans le temps.

Anthropic applique aussi des tests par ablation. L’équipe retire ou modifie un composant à la fois, puis mesure l’effet sur un ensemble d’évaluations constant. Cette méthode permet de distinguer une amélioration réelle d’une intuition séduisante. Elle a notamment révélé la faible valeur de l’accès brut aux requêtes historiques et l’intérêt d’une documentation structurée par domaine.

En production, une revue contradictoire menée par un autre agent a augmenté la précision de six points dans les évaluations d’Anthropic. Cette amélioration a toutefois entraîné 32 % de jetons supplémentaires et une latence supérieure de 72 %. L’architecture doit donc arbitrer entre exactitude, coût et rapidité selon le risque associé à chaque usage.

La provenance aide à juger la réponse sans la certifier

Chaque réponse peut comporter un pied de provenance indiquant le niveau de source utilisé, la fraîcheur des données et le propriétaire du modèle. Une réponse issue de la couche sémantique, alimentée récemment et placée sous la responsabilité d’une équipe identifiée inspire davantage confiance qu’un résultat calculé directement sur une table brute dont la fraîcheur reste inconnue.

Cette provenance ne garantit pas que le résultat soit juste. Elle rend toutefois le niveau de risque visible et facilite la décision de vérifier une réponse avant de la transmettre. Elle constitue l’une des rares protections contre les erreurs silencieuses, ces réponses fausses mais suffisamment plausibles pour ne susciter aucune correction.

Anthropic reconnaît ne pas disposer d’une solution robuste à ce dernier problème. L’entreprise combine le pied de provenance, une validation humaine pour les contenus destinés à la direction et des contrôles quotidiens des indicateurs essentiels. Cette franchise importe autant que les taux de précision annoncés : même un système très évalué ne peut pas prouver automatiquement la validité de toutes ses réponses.

Les contrôles de qualité de données complètent cette approche. Un agent peut sélectionner la bonne table, employer la bonne mesure et appliquer les bons filtres, puis produire un résultat erroné parce que la donnée source est incomplète ou anormale. La fraîcheur, la complétude et la détection d’anomalies doivent donc accompagner la réponse analytique.

Vers une architecture Data prête pour l’IA

Le modèle proposé par Anthropic pourrait être prolongé par un contrat explicite de qualité entre les couches de données et l’agent. Ce contrat indiquerait les contrôles réussis, les seuils acceptables, la date de dernière validation et les conditions dans lesquelles une mesure peut être utilisée. L’agent ne consulterait pas seulement une définition officielle. Il saurait aussi si les données qui l’alimentent satisfont les exigences attendues.

Une architecture de ce type associe un pipeline Data, des modèles canoniques, une couche sémantique, du lignage, des métadonnées, des skills versionnés, des évaluations continues et une provenance visible. Elle nécessite également une gouvernance des accès. Plus un agent dispose de contexte, plus il peut être performant, mais un accès trop large peut entrer en conflit avec les règles de confidentialité. Selon les organisations, plusieurs agents limités à des domaines ou à des audiences précises peuvent s’avérer préférables à un agent unique disposant de tous les droits.

Le retour d’expérience d’Anthropic ne livre donc pas une recette universelle. La complexité acceptable dépend du niveau de risque, du nombre d’utilisateurs, de la stabilité du modèle Data et du coût que l’entreprise accepte de supporter pour améliorer la précision. Les auteurs recommandent d’ailleurs de commencer avec quelques jeux de données canoniques, quelques dizaines d’évaluations et un skill de connaissance léger.

La conclusion reste néanmoins solide. L’analytique en langage naturel ne devient fiable qu’à partir du moment où l’entreprise traite le contexte, les définitions, la recherche et la validation comme des composants d’architecture. Le LLM apporte une nouvelle interface et une capacité de raisonnement. Il ne remplace ni la modélisation, ni la qualité, ni l’ownership humain.

La self service BI assistée par l’IA ne constitue donc pas la fin de la BI gouvernée. Elle en représente peut-être la forme la plus exigeante. Lorsque chaque utilisateur peut interroger les données sans médiation technique, l’entreprise doit rendre ses définitions plus explicites, ses sources plus canoniques et ses contrôles plus visibles. L’agent n’efface pas l’architecture Data. Il révèle immédiatement ses forces et ses faiblesses.

Source principale

Anthropic, Josh Cherry, Clement Peng, Johanne Jiao, Justin Leder et Chen Chang, « How Anthropic enables self-service data analytics with Claude », 3 juin 2026.