---
title: "Qu’est-ce que l’analytique conversationnelle vérifiable ?"
description: "L’analytique conversationnelle vérifiable répond par des requêtes réelles et livre la requête, les sources et le temps d’exécution : vérifiez chaque réponse."
canonical: https://datarelix.ai/fr/resources/guides/what-is-verifiable-conversational-analytics/
publishDate: 2026-08-07
updatedDate: 2026-08-17
lastVerified: 2026-08-17
---

# Qu’est-ce que l’analytique conversationnelle vérifiable ?

L'analytique conversationnelle vérifiable, c'est de l'analytique conversationnelle qui montre comment elle obtient ses réponses. Vous posez une question en langage courant ; le système la traduit en une vraie requête, exécute cette requête sur votre base de données en direct et renvoie la réponse accompagnée de ses preuves — la requête exacte qui s'est exécutée, les tables sources lues, le nombre de lignes et le temps d'exécution — pour que chacun puisse vérifier ce qui a été mesuré au lieu de faire confiance à un paragraphe bien tourné.

## À qui s'adresse cette définition

Les responsables data et BI qui décident si l'analytique conversationnelle a sa place dans leur stack, et à quelles conditions. Les dirigeants qui consommeront les réponses et veulent savoir ce qu'il y a derrière un chiffre avant qu'il n'entre dans une présentation au conseil. Les ingénieurs analytics à qui l'on demandera de connecter un entrepôt de données et qui ont besoin d'une définition concrète pour évaluer les fournisseurs.

## Deux familles d'outils pour poser des questions à votre base de données

« Analytique conversationnelle » désigne tout outil qui répond à des questions sur les données posées en langage courant. Le terme recouvre deux familles d'outils très différentes. Les premiers répondent à partir de texte — un export collé, un document, les associations apprises par le modèle — et produisent une prose qui ne se rattache à rien. Les seconds traduisent la question en requête, l'exécutent sur la base de données connectée et joignent le relevé d'exécution à la réponse. Si vous êtes arrivé ici en cherchant un moyen de [discuter avec votre base de données](/fr/chat-with-your-database/), c'est la seconde famille qui mérite votre attention. Les mécanismes de la traduction sont détaillés dans [comment fonctionne vraiment le text-to-SQL](/fr/resources/guides/text-to-sql-explained/).

## Ce qui la distingue d'un résumé de chatbot

| Critère | Résumé de chatbot | Analytique conversationnelle vérifiable |
|---|---|---|
| D'où vient la réponse | Des connaissances d'entraînement, ou d'un texte que vous avez collé | D'une requête exécutée sur votre base de données en direct |
| Fraîcheur | Figée à la date d'entraînement ou du copier-coller | À jour au moment où la requête s'est exécutée |
| Peut-il montrer comment il a obtenu la réponse ? | Non — il n'y a aucune requête à montrer | Oui — la requête exécutée est livrée avec la réponse |
| Reproductibilité | Reposer la question peut donner une autre réponse, sans moyen de comparer | La requête enregistrée peut être réexécutée et comparée |
| À quoi ressemble une réponse fausse | Un texte affirmatif, sans rien à inspecter | Une requête visible, dont vous pouvez contester la lecture ligne à ligne |
| Ce qu'implique une relecture | Refaire l'analyse depuis zéro | Confronter quatre éléments de preuve à la question |

La colonne de gauche n'est pas inutile — elle convient pour résumer un document. C'est le mauvais outil pour « quel a été le chiffre d'affaires le mois dernier ? », car lorsque le chiffre est faux, il n'y a aucun artefact à examiner, seulement un paragraphe à mettre en doute.

## Les quatre couches de preuve

La vérifiabilité, ce sont quatre artefacts précis attachés à chaque réponse, chacun interceptant une classe d'erreurs différente.

### La requête exacte qui s'est exécutée

Pas une reformulation, pas « j'ai regardé vos commandes » — l'instruction littérale qui s'est exécutée. C'est la couche qui tranche l'ambiguïté : le langage courant sous-spécifie, et le modèle doit s'engager sur une lecture. La requête est l'endroit où cet engagement devient visible. Quiconque sait lire du SQL de base peut vérifier le filtre, la jointure et l'agrégation en une seule passe.

### Les tables sources lues

Les schémas réels sont pleins de pièges : `orders` et `orders_v2`, une table d'événements bruts à côté d'un mart de chiffre d'affaires modélisé. Une réponse calculée à partir de la mauvaise table peut être cohérente en interne et rester fausse pour votre activité. Voir les sources vous dit si la réponse vient des tables que votre équipe considère comme la référence — une vérification qui demande un coup d'œil et pas une ligne de SQL.

### Le nombre de lignes

Le nombre de lignes est un signal de plausibilité. Une question sur le chiffre d'affaires mensuel portant sur six mois devrait s'agréger en six lignes ; une question « meilleurs clients » plafonnée à dix devrait en renvoyer dix ou moins. Zéro ligne signifie que le filtre n'a rien trouvé — une réponse « aucun chiffre d'affaires » construite sur zéro ligne n'affirme pas du tout la même chose qu'une réponse construite sur des milliers de commandes trouvées. Le compte montre aussi quand une limite de lignes automatique a tronqué un résultat : vous savez alors que vous regardez une tranche bornée et non l'ensemble.

### Le temps d'exécution

Le temps d'exécution donne le contexte d'exécution. Une requête qui a balayé une grande table de faits et une requête qui a touché une petite table de correspondance ne laissent pas la même empreinte, et un temps d'exécution très éloigné de ce que la question laissait attendre invite à regarder de plus près ce qui a réellement été balayé. Il porte aussi une information opérationnelle qui intéresse les relecteurs. Sur les moteurs facturés au temps de calcul écoulé, comme Snowflake et Databricks, le temps d'exécution est un indicateur de coût approximatif ; sur BigQuery et Athena, facturés aux octets analysés, il ne l'est pas — il vous renseigne alors sur la forme du balayage plutôt que sur la dépense. Dans les deux cas, il indique si une question est assez peu coûteuse pour devenir un tableau de bord qui s'actualise.

## Un exemple détaillé : le chiffre d'affaires mensuel, vérifié en quatre coups d'œil

L'exemple ci-dessous s'appuie sur le schéma de démonstration d'un détaillant fictif — `customers`, `orders`, `order_items` — et sert d'illustration : ce n'est pas une sortie capturée sur un système réel.

**Question :** « Quel a été le chiffre d'affaires mensuel des 6 derniers mois ? »

Une requête générée plausible sur PostgreSQL :

```sql
SELECT
  date_trunc('month', o.ordered_at) AS month,
  SUM(oi.quantity * oi.unit_price) AS revenue
FROM orders AS o
JOIN order_items AS oi ON oi.order_id = o.order_id
WHERE o.status = 'completed'
  AND o.ordered_at >= date_trunc('month', CURRENT_DATE) - INTERVAL '6 months'
  AND o.ordered_at < date_trunc('month', CURRENT_DATE)
GROUP BY 1
ORDER BY 1;
```

Le graphique aura l'air correct dans tous les cas. Ce sont les preuves qui permettent de l'interroger :

- **Quelles tables ?** Le chiffre d'affaires a été calculé à partir de `orders` jointe à `order_items` — des tables transactionnelles brutes. Si la définition du chiffre d'affaires de votre équipe vit dans un mart modélisé, cette réponse a utilisé une autre source, et la ligne des sources le dit avant que vous ne présentiez le chiffre.
- **Brut ou net ?** La requête somme chaque ligne de commande des commandes terminées. Les remboursements ne sont pas déduits — `status = 'completed'` ne dit rien des remboursements ultérieurs. C'est un chiffre brut, et seul le texte de la requête vous l'apprend.
- **Quelle fenêtre ?** « Les 6 derniers mois » a été lu comme les six derniers mois calendaires *complets*, à l'exclusion du mois en cours, partiel. Défendable — mais si vous vouliez dire « en incluant le mois en cours », c'est aux deux bornes `date_trunc` que la différence se voit.
- **Quelle devise ?** `unit_price` est sommé tel quel. Si le détaillant vend dans plusieurs devises, cela additionne silencieusement des euros et des dollars — un défaut que la requête expose et qu'un paragraphe de résumé n'exposerait jamais.

Aucune de ces vérifications n'exige de refaire l'analyse. Chacune est une question ciblée à laquelle les preuves répondent directement — l'habitude de relecture qu'il vaut la peine de prendre, pas à pas, dans [comment vérifier les réponses d'une IA sur vos données](/fr/resources/guides/verify-ai-data-answers/).

## Ce que les preuves corrigent, et ce qu'elles ne corrigent pas

Les preuves n'empêchent pas le modèle de se tromper. Il peut mal lire une question ambiguë, choisir la mauvaise de deux colonnes aux noms proches, ou appliquer une définition d'indicateur que votre entreprise définit autrement — « client actif », « attrition » et « chiffre d'affaires » ne veulent pas dire la même chose d'une entreprise à l'autre, et aucun modèle ne connaît votre définition tant que personne ne l'a écrite dans une description de schéma.

Ce que les preuves changent, c'est le mode de défaillance. Dans un système non vérifiable, ces erreurs sont invisibles : la réponse est un texte, et le seul recours est le soupçon. Dans un système vérifiable, les mêmes erreurs sont inspectables — le contresens vit dans une requête que vous pouvez voir, sur des tables que vous pouvez nommer, avec une forme dont vous pouvez juger la vraisemblance. Le taux d'erreur est une propriété du modèle ; la possibilité de repérer les erreurs est une propriété de l'architecture.

Trois conséquences en découlent, et ce sont les limites honnêtes de la catégorie. Les preuves ne servent que si quelqu'un les lit : une équipe qui n'ouvre jamais le panneau de la requête obtient le profil de risque d'un outil non vérifiable, avec des étapes en plus. La qualité des réponses suit la qualité du schéma : des noms de colonnes énigmatiques et des descriptions absentes dégradent tout système de cette catégorie, et soigner les descriptions est un vrai travail qui incombe à votre équipe. Enfin, la catégorie se limite à la lecture. Écrire des données, lancer des migrations et faire de la modélisation en plusieurs étapes avec une logique métier lourde relèvent de vos outils de transformation et d'administration, l'analytique conversationnelle interrogeant leurs sorties.

## La sécurité, en bref

La vérifiabilité et la sécurité découlent de la même décision de conception : le modèle propose, et une couche d'exécution distincte valide et exécute chaque étape. Les instructions générées sont analysées en arbre syntaxique et rejetées si ce ne sont pas des lectures — [comment fonctionne le validateur](/fr/resources/guides/read-only-ai-analytics/) — et l'identifiant de connexion est déchiffré au moment de l'exécution uniquement, sans jamais être placé dans le contexte du modèle — [la frontière des identifiants](/fr/resources/guides/credentials-away-from-the-model/). La page sécurité énonce les deux sous leur forme canonique.

## Une liste de contrôle avant achat

Quand vous évaluez des outils de cette catégorie, posez à chaque fournisseur ces questions :

- Peut-on voir la requête exacte exécutée sur chaque réponse — par défaut, et non sur demande ?
- Peut-on voir les tables sources lues par chaque réponse ?
- L'accès est-il en lecture seule par conception — appliqué en analysant et en validant chaque instruction, et non en demandant au modèle de bien se tenir ?
- Où vivent les identifiants de connexion, et le modèle les reçoit-il à un moment quelconque ?
- Des limites de lignes sont-elles appliquées automatiquement à chaque requête ?
- Chaque exécution est-elle enregistrée — question, plan, requête exécutée, résultat — et réouvrable plus tard ?
- Si l'outil exécute du code d'analyse généré, celui-ci tourne-t-il dans un bac à sable isolé, avec le trafic sortant bloqué au niveau réseau ?
- Le modèle de compte et d'accès correspond-il à la façon dont votre équipe doit travailler ?

Un fournisseur incapable de répondre aux deux premières ne vous laisse rien contre quoi vérifier une réponse.

## Une implémentation de la catégorie

Datarelix est une implémentation hébergée de la définition ci-dessus : chaque réponse est livrée avec les quatre couches de preuve, et chaque exécution est réouvrable depuis l'historique. Les réponses qui méritent d'être conservées deviennent des tableaux de bord qui s'actualisent à partir de la même logique de requête, comme le décrit le [guide des tableaux de bord](https://docs.datarelix.ai/fr/guides/dashboards/). L'ensemble des fonctionnalités figure sur la [page fonctionnalités](/fr/features/), et les limites d'exécution sur la [page sécurité](/fr/security/).

## Notes et provenance

Les affirmations produit décrivent Datarelix tel que livré en août 2026 ; la [page sécurité](/fr/security/) fait foi. L'exemple détaillé s'appuie sur le schéma de démonstration d'un détaillant fictif : il illustre le propos, il n'a pas été capturé sur un système réel. Le découpage en quatre couches et la liste de contrôle avant achat sont les nôtres ; aucun benchmark externe, aucune citation ni référence client n'est utilisé.

## La suite : le mécanisme

Descendez d'un cran. [Comment fonctionne vraiment le text-to-SQL](/fr/resources/guides/text-to-sql-explained/) parcourt la chaîne, du contexte de schéma au plan structuré puis à l'exécution validée — ce qui, au départ, rend les quatre couches de preuve possibles.