---
title: "Text-to-SQL ou SQL manuel : quelle méthode choisir ?"
description: "Comparez le text-to-SQL et le SQL manuel sur un même rapport de ventes : définition, génération, vérification, modification et réutilisation."
summary: "Choisissez comment produire votre prochain rapport en comparant le travail avant et après l’écriture du SQL."
canonical: https://datarelix.ai/fr/resources/guides/text-to-sql-vs-manual-sql/
publishDate: 2026-09-10
updatedDate: 2026-09-22
lastVerified: 2026-09-10
---

# Text-to-SQL ou SQL manuel : quelle méthode choisir ?

Choisissez comment produire votre prochain rapport en comparant le travail avant et après l’écriture du SQL.

Le **text-to-SQL** produit une requête SQL à partir d’une question écrite ; [comment le text-to-SQL génère les requêtes](/fr/resources/guides/text-to-sql-explained/) en explique le mécanisme. **Écrire du SQL manuellement** produit le même type d'instruction, en choisissant directement sa syntaxe. Les deux approches demandent un accès à la base, une définition de la mesure et une méthode de vérification.

Si vous connaissez la question métier sans maîtriser SQL, le text-to-SQL peut fournir une première requête et un résultat. Pour un calcul complexe, l'écriture manuelle donne à l'analyste un contrôle direct sur chaque expression. Les deux méthodes peuvent se combiner.

## Comparer le même rapport

Vous devez calculer le montant des commandes payées par région pour août 2026. La source contient une ligne par commande, une date, une région, un statut et un montant en euros.

| Étape | Avec text-to-SQL | Avec SQL manuel |
|---|---|---|
| Définir la question | Décrire période, devise, statut et regroupement | Définir les mêmes éléments avant d'écrire |
| Trouver les données | Fournir l'accès et les descriptions pertinentes | Examiner le schéma, les champs et les relations |
| Produire le SQL | Examiner la requête générée | Écrire filtres, regroupement et agrégation |
| Exécuter | Utiliser le parcours d'exécution autorisé | Exécuter dans un client SQL avec le compte approuvé |
| Vérifier | Comparer les définitions et un total connu ; faire relire le SQL si nécessaire | Contrôler les mêmes définitions, totaux et jointures |
| Modifier | Préciser la demande puis examiner le nouveau SQL | Modifier directement les expressions |
| Réutiliser | Enregistrer réponse ou graphique selon l'outil | Enregistrer le script ou l'intégrer au reporting |

La configuration, la complexité du schéma et votre maîtrise de SQL influencent l'effort.

## Comprendre le calcul

Exemple PostgreSQL :

```sql
SELECT region, SUM(total_eur) AS paid_order_value_eur
FROM orders
WHERE status = 'paid'
  AND ordered_at >= DATE '2026-08-01'
  AND ordered_at < DATE '2026-09-01'
GROUP BY region
ORDER BY paid_order_value_eur DESC;
```

L’**intervalle semi-ouvert** inclut août et exclut le 1er septembre. Il suppose que `total_eur` est un montant par commande. Il ne déduit pas les remboursements enregistrés ailleurs. Présenter ce résultat comme un chiffre d'affaires net serait incorrect, quelle que soit la méthode de rédaction du SQL.

Si le résultat indique North à 1 200 EUR et South à 800 EUR, le total est de 2 000 EUR. Comparez-le à un rapport approuvé ou à un échantillon vérifié séparément. Le graphique doit conserver ces valeurs et préciser qu'elles sont avant remboursements.

## Quand utiliser chaque approche ?

Le text-to-SQL convient lorsque vous savez décrire le rapport et souhaitez de l'aide pour produire une première requête. Datarelix affiche le [SQL exécuté et les sources](/fr/features/#trust-title) avec le résultat ; un graphique vérifié peut rejoindre un tableau de bord privé. La source doit être prise en charge et joignable. L'actualisation est manuelle et chaque tableau de bord utilise une seule connexion.

L'écriture manuelle convient lorsque vous avez besoin de contrôler des jointures complexes, une fonction propre au moteur ou un script suivi avec d'autres développements. Les modifications de données ou de structure demandent un outil et des autorisations adaptés : les requêtes de reporting Datarelix restent **en lecture seule**.

Si vous utilisez déjà un éditeur SQL, examinez ses fonctions d'IA. Le choix peut dépendre autant des graphiques, de la réutilisation et du public du rapport que de la génération du SQL.

## Associer SQL généré et revue par l'analyste

Un analyste peut utiliser le text-to-SQL pour préparer un rapport familier, examiner les hypothèses, puis continuer dans un éditeur SQL lorsqu'un contrôle direct est utile. Dans l'exemple régional, vérifiez si `region` est enregistrée sur la commande ou provient de l'adresse actuelle du client. Ces choix peuvent produire des rapports historiques différents malgré les mêmes filtres de dates ; consignez la réponse comme [contexte du schéma et définitions métier](/fr/resources/guides/why-semantic-context-matters/) pour que la question suivante en reparte.

Pour limiter le rapport aux grossistes, décidez si le segment correspond à la date de commande ou à aujourd'hui. Vérifiez l'unicité de la clé côté client, puis rapprochez une région avant d'enregistrer le résultat. La demande exprime l’intention ; la requête permet d’examiner sa mise en œuvre.

Pour une analyse récurrente, gardez définition et SQL réussi ensemble. Un graphique personnel peut réutiliser un calcul enregistré ; une vue maintenue peut convenir si plusieurs rapports emploient la même règle. SQL écrit à la main ou généré demande cette même décision de maintenance.

## Vérifier une modification

Ajoutez « uniquement les clients grossistes ». Cette demande peut nécessiter une jointure avec la table clients. Vérifiez que chaque commande n'apparaît qu'une fois et que le segment correspond à la définition attendue. Un total plus faible et plausible ne suffit pas.

Consultez le [guide de vérification](/fr/resources/guides/verify-ai-data-answers/), puis l'exemple de [rapport de ventes hebdomadaire](/fr/resources/guides/weekly-sales-report/). Vous pouvez aussi [connecter une source](https://docs.datarelix.ai/fr/quickstart/) et poser une question dont vous connaissez la réponse.