Qu'est-ce qu'un langage de requête ?

Qu'est-ce qu'un langage de requête ?

Un langage de requête (query language) est un langage spécialisé pour poser une question à un système de données : quels enregistrements correspondent, dans quel ordre, avec quels champs. Vous décrivez le résultat voulu, et le moteur (une base de données, un serveur d'API, une plateforme de recherche ou de logs) détermine comment le produire.

C'est pourquoi les langages de requête sont généralement plus courts que la boucle équivalente en Python ou en Java, et pourquoi les moteurs peuvent appliquer des index, une planification des requêtes et une exécution parallèle sans que vous les écriviez. Presque toutes les couches d'une pile moderne en ont un : SQL pour les bases relationnelles, GraphQL pour les API, les requêtes JSON de MongoDB pour les bases documentaires, KQL, SPL et LogQL pour les logs.

Les principaux langages de requête

SQL, pour les données relationnelles et analytiques

Le langage de requête structuré (SQL) est le standard des bases relationnelles comme PostgreSQL, MySQL, SQL Server, Oracle et SQLite, et il est aussi utilisé par des moteurs analytiques comme BigQuery, Snowflake et Athena. Son modèle de tables, de lignes, de jointures et d'agrégations correspond à la plupart des données métier.

SELECT u.name, COUNT(o.id) AS order_count
FROM users u
LEFT JOIN orders o ON o.user_id = u.id
WHERE u.created_at > '2026-01-01'
GROUP BY u.id, u.name
HAVING COUNT(o.id) > 5
ORDER BY order_count DESC
LIMIT 100;

GraphQL, pour les API

GraphQL permet au client de nommer exactement les champs dont il a besoin et de récupérer des objets liés en une seule requête, ce qui évite les données superflues et les allers-retours supplémentaires. Voir l'entrée GraphQL pour le côté API.

query {
  user(id: "123") {
    name
    orders(last: 10) {
      id
      total
    }
  }
}

Requêtes MongoDB, pour les bases documentaires

Les requêtes MongoDB ont la forme de JSON. Les filtres utilisent des opérateurs comme $eq, $gt, $in et $regex, et les agrégations s'exécutent comme un pipeline d'étapes. Si le format vous est nouveau, lisez l'entrée JSON.

db.orders.find({
  status: "shipped",
  total: { $gt: 100 }
}).sort({ total: -1 }).limit(10);

Query DSL d'Elasticsearch et OpenSearch, pour la recherche

Un langage basé sur JSON, construit autour du score de pertinence. Il combine recherche plein texte, filtres, agrégations et tri.

KQL, pour les logs et les séries temporelles

Kusto Query Language est le langage de Microsoft en forme de tubes, utilisé dans Azure Monitor, Application Insights et Microsoft Sentinel. Chaque ligne transforme la sortie de la précédente.

requests
| where timestamp > ago(1h)
| where resultCode >= 500
| summarize count() by name, bin(timestamp, 5m)
| order by timestamp desc

SPL, LogQL et PromQL, pour les données d'observabilité

SPL est le langage de recherche de Splunk. LogQL (Grafana Loki) filtre les logs et reprend des idées de PromQL, le langage de Prometheus pour les métriques. Tous trois fonctionnent en pipeline ou en expression, adaptés aux données ordonnées dans le temps.

Cypher et GQL, pour les graphes

Cypher (Neo4j) décrit des motifs de graphe avec une syntaxe en art ASCII comme (person)-[:KNOWS]->(friend). GQL, publié sous la référence ISO/IEC 39075 en avril 2024, est le premier nouveau langage de requête pour bases de données de l'ISO depuis SQL et repose sur les mêmes idées de graphe de propriétés. Gremlin est l'alternative de parcours des bases compatibles TinkerPop.

Style déclaratif ou en pipeline

La plupart des langages de requête sont déclaratifs : vous indiquez le résultat et le moteur choisit le plan d'exécution. D'autres fonctionnent comme un pipeline d'étapes.

• Déclaratifs : SQL, GraphQL, find de MongoDB, Query DSL d'Elasticsearch.
• Pipeline : KQL, SPL, LogQL, pipelines d'agrégation MongoDB. Chaque étape prend la sortie de la précédente.
• Procéduraux : procédures stockées et fonctions définies par l'utilisateur, pour une logique qui ne tient pas dans une seule requête, comme des boucles avec état.

Préférez la forme déclarative quand elle peut exprimer votre besoin : elle se lit mieux et le moteur peut l'optimiser. Ne passez au code procédural que lorsque le flux de contrôle l'exige.

Ce qui se passe quand vous exécutez une requête

Le moteur analyse le texte, le vérifie par rapport au schéma, construit un plan d'exécution puis l'exécute. Le plan décide s'il faut utiliser un index ou parcourir toutes les lignes, et dans quel ordre joindre les tables. En SQL, EXPLAIN affiche ce plan, et c'est le premier endroit à regarder quand une requête est lente.

Erreurs fréquentes

• L'injection SQL. Ne construisez jamais une requête en concaténant une saisie utilisateur. Utilisez des requêtes paramétrées (requêtes préparées), qui séparent les données du texte de la requête. Les paramètres ne remplacent pas un nom de table ou de colonne : faites-les correspondre à une liste autorisée.
• Le motif N+1. Un ORM qui charge une liste puis exécute une requête de plus par élément transforme une requête en centaines. Utilisez des jointures, le chargement anticipé ou un outil de regroupement comme DataLoader.
• Les index manquants. Sans index utile, le moteur lit toute la table. Examinez le plan d'exécution de toute requête lente.
• Les requêtes GraphQL sans limite. Les requêtes très imbriquées peuvent coûter très cher. Fixez des limites de profondeur et de complexité, ainsi que des délais maximaux.
• Croire que NULL se comporte partout pareil. Le NULL de SQL se compare autrement que null dans MongoDB ou GraphQL. Lisez les règles du langage utilisé.
• Faire confiance au client pour le contrôle d'accès. Appliquez les droits là où la requête s'exécute (sécurité au niveau des lignes, résolveurs de champs, rôles), pas en filtrant les résultats dans le navigateur.

Langages de requête, tests de charge et surveillance

Les requêtes lentes n'apparaissent souvent que sous trafic concurrent : index manquants, motifs N+1 et pools de connexions saturés passent inaperçus avec un seul utilisateur. Un test de charge sur votre API reproduit ce trafic et donne les percentiles de temps de réponse et les erreurs. En production, la surveillance d'API suit le temps de réponse de chaque point de terminaison depuis plusieurs régions, ce qui permet de repérer une régression de requête peu après sa mise en ligne (voir surveillance d'API). Le cache aide quand la même requête revient souvent : le cache d'API explique comment, et optimiser les pools de connexions à la base de données traite le côté pool. Pour la sécurité, voir sécurité des bases de données.

Questions fréquentes : langages de requête

Vaut-il encore la peine d'apprendre SQL ?

Oui. Même quand un outil génère les requêtes pour vous, il faut SQL pour vérifier le résultat, lire un plan d'exécution et raisonner sur les index et les jointures.

Quelle différence entre les langages de requête SQL et NoSQL ?

SQL travaille sur des tables à schéma fixe et gère les jointures. Les langages de requête NoSQL épousent leur modèle de données : documents, colonnes, paires clé-valeur ou graphes. Beaucoup d'applications utilisent les deux.

GraphQL remplace-t-il REST ?

Pas de manière générale. GraphQL convient aux clients qui ont besoin de données flexibles et imbriquées. REST reste courant pour les API simples et publiques, et beaucoup d'équipes utilisent les deux.

Quel langage de requête pour les séries temporelles ?

PromQL pour Prometheus, InfluxQL ou Flux pour InfluxDB et KQL pour Azure Monitor sont courants. Ils combinent une plage de temps avec une agrégation par intervalles.

Un seul langage de requête peut-il couvrir tous les types de données ?

Non. SQL s'en approche le plus, et des bases comme PostgreSQL ajoutent JSON, plein texte et fonctions géographiques, mais le parcours de graphes, l'analyse de logs et la recherche vectorielle ont toujours leurs langages dédiés.