---
title: "Pourquoi votre outil d’IA choisit la mauvaise colonne"
description: "Un outil qui répond avec assurance et se trompe manque souvent de contexte sémantique. Comment descriptions de colonnes, tables clés et jointures changent le SQL généré."
canonical: https://datarelix.ai/fr/resources/guides/why-semantic-context-matters/
publishDate: 2026-08-13
updatedDate: 2026-08-17
lastVerified: 2026-08-17
---

# Pourquoi votre outil d’IA choisit la mauvaise colonne

Quand un outil d'IA filtre sur la mauvaise colonne, la cause habituelle est un **contexte sémantique** manquant, pas un modèle faible. La **structure du schéma** lui indique qu'une colonne nommée `status` existe et contient du texte. Elle ne dit pas que `'completed'` signifie payé et expédié, que `'closed'` était l'orthographe d'avant 2024 pour la même chose, ni que `orders_v2` est la table active et `orders` une migration abandonnée. C'est cette couche manquante qui sépare un outil qui fonctionne sur vos données d'un outil qui écrit du SQL bien formé sur la mauvaise colonne.

## Si vous avez déjà vu ça arriver

Toute personne qui a connecté un outil d'analytique en langage naturel, l'a vu répondre à une question avec assurance et de travers, et s'est demandé si le modèle était mauvais. En général, il ne l'est pas. Et aussi les ingénieurs analytics qui doivent décider quelle part de curation vaut la peine d'être faite avant de déployer un outil.

## Les deux couches, et celle que vous contrôlez

<figure>
  <img
    src="/images/guides/fr/semantic-context-layers.svg"
    alt="Schéma montrant trois types d'information dans une base de données et ce qui franchit la frontière du contexte. La structure — noms, types, clés primaires, clés étrangères déclarées — est lue automatiquement et franchit la frontière. Le sens documenté — descriptions, tables marquées comme tables clés, relations corrigées, colonnes exclues — est ajouté par votre équipe et franchit la frontière. Les valeurs des lignes ne font pas partie du contexte de schéma, avec une exception signalée : les valeurs de réponse sur une seule ligne sont reprises dans les questions suivantes."
    width="900"
    height="470"
    loading="lazy"
    decoding="async"
  />
  <figcaption>La structure est gratuite et automatique. Le sens, c'est la partie que vous fournissez — et celle qui décide de la qualité des réponses.</figcaption>
</figure>

### Couche un : la structure, que vous obtenez gratuitement

L'introspection lit les noms de tables et de colonnes, les types de données, les clés primaires, les clés étrangères déclarées et la nullabilité, sans que personne ait à intervenir. Tous les outils de cette catégorie la lisent : ce n'est donc **pas** de là que viennent les différences de qualité entre outils.

### Couche deux : le sens, que vous devez fournir

Les bases de données ne stockent généralement pas le sens. Il vit dans un wiki, dans un champ `description:` dbt que personne n'a rempli, ou dans la mémoire d'un analyste. Quand il est absent, le modèle fait ce que ferait n'importe quel inconnu compétent devant votre schéma : il devine à partir des noms.

## Ce que coûte l'ambiguïté

Voici les formes d'échec qui reviennent :

| Ambiguïté | Ce que fait le modèle sans contexte | Ce qu'une ligne de contexte corrige |
|---|---|---|
| **Codes de statut** | Filtre sur la valeur qui sonne juste, ou omet entièrement le filtre | `status` : cycle de vie de la commande — `'completed'` signifie payé et expédié ; à utiliser pour le chiffre d'affaires |
| **Plusieurs colonnes de montant** | Choisit `amount` plutôt que `net_amount` parce que le nom est plus simple | `amount` : brut, avant remboursements. Utilisez `net_amount` pour le chiffre d'affaires publié |
| **Tables obsolètes** | Interroge la table au nom le plus propre | `orders` : remplacée en 2024-03 ; utilisez `orders_v2` |
| **Lignes de test et internes** | Les compte | `customers` : contient des comptes de test internes où `is_internal = true` — à exclure du reporting |
| **Chemins de jointure non déclarés** | Déduit une jointure de la convention de nommage ; parfois à tort | Déclarez la relation, ou corrigez celle qui a été déduite |
| **Confusion de granularité** | Somme une colonne qui est déjà un agrégat | `daily_revenue` : pré-agrégé par jour — ne pas sommer à l'intérieur d'une même journée |
| **Horodatages à fuseaux mélangés** | Compare des champs stockés dans des fuseaux différents | `created_at` : UTC. `local_ordered_at` : heure locale du magasin, non comparable |

Aucun de ces cas n'est une défaillance du modèle. Chacun est une question à laquelle le schéma ne répond pas, tranchée par le modèle qui s'arrête sur une lecture.

### Ce qu'une ligne de contexte change vraiment

Prenons la première ligne. La question est « quel a été le chiffre d'affaires le mois dernier ? »,
posée sur le schéma de démonstration d'un distributeur fictif où `orders.status` contient
`'completed'`, `'pending'` et `'cancelled'`.

Sans description sur `status`, rien dans le schéma ne dit que les commandes annulées ne comptent pas
dans le chiffre d'affaires, donc rien ne les filtre :

```sql
SELECT SUM(amount) AS revenue
FROM orders
WHERE ordered_at >= date_trunc('month', now() - interval '1 month')
  AND ordered_at <  date_trunc('month', now());
```

Ajoutez maintenant une ligne de contexte sur `status` : *cycle de vie de la commande ; `'completed'`
signifie payé et expédié, à utiliser pour le chiffre d'affaires.* La même question produit
désormais :

```sql
SELECT SUM(amount) AS revenue
FROM orders
WHERE ordered_at >= date_trunc('month', now() - interval '1 month')
  AND ordered_at <  date_trunc('month', now())
  AND status = 'completed';
```

Les deux requêtes sont du SQL valide et s'exécutent toutes les deux sans erreur. La première inclut
silencieusement les commandes annulées, elle annonce donc un chiffre plus élevé — et rien dans la
réponse n'a l'air faux. C'est tout l'argument en faveur de la curation : le coût d'un contexte
manquant n'est pas un échec, c'est un chiffre plausible.

## Que décrire en premier : la curation par ordre de priorité

Vouloir tout décrire, c'est ainsi que les projets de curation s'enlisent. Classez plutôt :

1. **Toute colonne sur laquelle vous filtreriez.** Statut, type, catégorie, colonnes indicateurs — ce sont elles qui décident des lignes comptées.
2. **Toute colonne qui a une jumelle.** `amount` et `net_amount`, `created_at` et `updated_at`, `user_id` et `account_id`. L'ambiguïté entre colonnes presque identiques est la plus coûteuse.
3. **Tables obsolètes ou doublonnées.** Une ligne disant « ne pas utiliser » évite toute une classe de réponses fausses.
4. **Chemins de jointure qui ne sont pas déclarés en clés étrangères.** Surtout dans les entrepôts comme Snowflake, où les clés sont informatives et souvent jamais déclarées du tout — traité dans [poser des questions à Snowflake en langage naturel](/fr/resources/guides/natural-language-analytics-for-snowflake/).
5. **Marquez vos tables clés.** Tables de faits et dimensions principales. Quand un schéma est assez grand pour que le contexte doive être tronqué, les tables marquées survivent à la coupe : le modèle garde celles qui comptent.

Tout le reste peut attendre. Une description générée automatiquement est un brouillon de départ, pas un texte fini : là où elle ne fait que reformuler le nom de la colonne, elle n'ajoute rien que le modèle ne puisse déjà lire. La valeur vient de l'édition des colonnes de la liste ci-dessus.

## La curation n'est pas un projet de couche sémantique

Une objection courante : « ce n'est qu'une couche sémantique avec des étapes en plus ». Une couche sémantique **calcule** des métriques — elle détient la définition du chiffre d'affaires et la produit de façon cohérente. Le contexte sémantique **décrit** ce qui existe déjà, pour qu'une requête puisse être écrite correctement dessus. Si vous avez une couche sémantique, gardez-la ; la meilleure configuration consiste à pointer l'outil conversationnel vers les marts que produit votre couche sémantique, pour que les questions héritent des définitions au lieu de les redériver. C'est le montage défendu dans [construire une analytique en libre-service sans remplacer votre pile](/fr/resources/guides/self-service-analytics-without-replacing-your-stack/).

Si vous n'en avez pas, la curation n'est pas un substitut — mais elle coûte moins cher : décrire les colonnes sur lesquelles vous filtrez est une tâche par schéma, pas un projet de modélisation.

## Gouvernance du contexte : le garder vrai

Les descriptions se périment plus vite que les schémas, et une description fausse mais assurée est pire que pas de description du tout : elle transforme un tirage à pile ou face en erreur fiable.

- **Gardez une source de vérité relue.** Les descriptions saisies dans un outil sont faciles à changer et faciles à oublier. Gardez la formulation canonique là où vos modèles sont relus — un `description:` dbt, un `COMMENT ON`, un fichier dans le dépôt — pour qu'un changement soit visible par l'équipe, et réappliquez-la quand le schéma bouge. Datarelix n'importe pas aujourd'hui les commentaires de base de données ni les descriptions dbt existantes ; les descriptions sont saisies au niveau de la connexion.
- **Revérifiez à chaque changement de schéma.** Une colonne renommée avec une description périmée est le pire cas.
- **Guettez les contradictions.** Quand une requête générée filtre sur quelque chose qui vous surprend, c'est en général la description qui est fausse.
- **Attribuez une responsabilité par schéma.** Sans propriétaire nommé, les descriptions cessent d'être mises à jour quand le schéma change.
- **Vérifiez périodiquement contre des réponses connues.** Posez des questions dont vous connaissez déjà les réponses ; l'intérêt d'une trace de preuves, c'est que la dérive se voit — la routine est décrite dans [comment vérifier une réponse produite par l'IA](/fr/resources/guides/verify-ai-data-answers/).

## La curation du contexte dans Datarelix

Quand vous connectez une base de données, Datarelix en lit directement la structure — tables, colonnes, types, clés primaires, clés étrangères déclarées, nullabilité. Une **analyse IA du schéma** facultative (comptabilisée par mois — voir la [page tarifs](/fr/pricing/)) propose ensuite des **descriptions** et déduit des relations à partir des conventions de nommage là où aucune clé étrangère n'a jamais été déclarée. Elle travaille uniquement à partir de la structure du schéma ; aucun échantillon de lignes ne lui est montré.

Tout ce qu'elle propose est modifiable, ce qui compte parce que l'inférence se trompe parfois. Sur la page de schéma, vous pouvez réécrire les descriptions, marquer des tables comme tables clés, corriger ou écarter les relations déduites, redéfinir les clés primaires et exclure entièrement des colonnes du contexte. Les très grands schémas n'entrent pas dans une seule requête : le contexte est donc rogné — les tables que vous marquez comme tables clés sont conservées.

Le contexte obtenu est ce qui accompagne chaque question, à côté de la question elle-même. Les lignes n'en font pas partie, avec une exception assumée : une **valeur de réponse sur une seule ligne** peut être reprise dans le contexte des questions suivantes, pour qu'un « et par rapport à l'an dernier ? » ait du sens. Les tables de résultats, non. « Jamais vos données » serait donc une exagération, et c'est pourquoi ce guide ne l'écrit pas. L'ensemble du pipeline est décrit dans [text-to-SQL expliqué](/fr/resources/guides/text-to-sql-explained/), et le volet identifiants dans [comment les identifiants restent hors du modèle](/fr/resources/guides/credentials-away-from-the-model/).

## Ce que la curation ne peut pas corriger

La curation relève le plancher ; elle ne rend pas l'interprétation déterministe. Une question ambiguë sur un schéma parfaitement décrit reste ambiguë — « meilleurs clients » peut toujours signifier chiffre d'affaires ou nombre de commandes — et c'est pourquoi la requête est affichée avec chaque réponse plutôt que masquée derrière un vocabulaire de confiance.

Les descriptions ne réparent pas un modèle réellement cassé. Si deux tables ne s'accordent pas sur ce qu'est un client, aucune quantité de prose ne les réconcilie ; c'est une correction de modélisation. Les très grands schémas seront tronqués, aussi bien décrits soient-ils : restreindre une connexion au schéma qui compte vaut mieux que tout décrire. Et les relations déduites sont des hypothèses — vérifiez les jointures dans les premières réponses avant de faire confiance à un chiffre, surtout sur des schémas que vous n'avez pas modélisés vous-même.

## Notes sur les exemples

Les affirmations produit décrivent Datarelix tel que livré en août 2026 — y compris la divulgation délibérée que des scalaires sur une seule ligne peuvent entrer dans le contexte des questions suivantes, indiquée ici parce que l'absolu inverse serait faux. La [page sécurité](/fr/security/) énonce les limites d'exécution de façon canonique. Les descriptions d'exemple utilisent le schéma d'un distributeur fictif et sont illustratives. Le tableau des ambiguïtés vient de motifs récurrents dans des schémas de production, pas d'une étude publiée ; il est proposé comme une liste de contrôle, pas comme un classement mesuré.

## Décrivez dix colonnes et reposez vos questions

Prenez votre schéma le plus sollicité et décrivez les dix colonnes sur lesquelles vous filtrez le plus. Suivez ensuite le [démarrage rapide](https://docs.datarelix.ai/fr/quickstart/), posez cinq questions dont vous connaissez les réponses, et lisez les clauses `WHERE`. Vos 14 premiers jours s'exécutent aux limites Pro, sans carte bancaire.