---
title: "Concepts clés"
description: "Les concepts derrière Datarelix : connexions, contexte de schéma, plans, validation en lecture seule, exécutions et preuves jointes à chaque réponse."
canonical: https://docs.datarelix.ai/fr/concepts/
---

# Concepts clés

## Exécutions

Une **exécution** (*run* dans l'API) est l'unité de travail centrale de Datarelix. Quand vous posez une question, vous créez une exécution qui :

1. Planifie la stratégie d'exécution à l'aide du LLM
2. Exécute des requêtes SQL et du code Python
3. Produit une réponse finale

### États d'une exécution

| État | Description |
|-------|-------------|
| `pending` | Exécution créée, en attente de démarrage |
| `planning` | Le LLM génère le plan d'exécution |
| `executing` | Les étapes sont en cours d'exécution |
| `success` | Toutes les étapes se sont terminées correctement |
| `partial` | Certaines étapes ont échoué, mais des résultats partiels sont disponibles |
| `failed` | L'exécution n'a pas pu aboutir |

## Étapes

Chaque exécution comporte une ou plusieurs **étapes** (*steps*). Les étapes sont les opérations élémentaires :

### Étapes SQL

Exécutent des requêtes SQL sur votre base de données :
- Validées avant leur exécution (analyse en arbre syntaxique complet pour les dialectes SQL ; validateurs dédiés pour KQL et ES|QL)
- Limitées aux instructions SELECT
- LIMIT appliqué automatiquement
- Protection par délai d'expiration

### Étapes bac à sable

Exécutent du code Python à des fins d'analyse :
- Environnement d'exécution isolé
- Accès à pandas, numpy, matplotlib
- Peuvent produire des artefacts (graphiques, fichiers)
- Limites de mémoire et de temps

## Le plan structuré

Au lieu d'exécuter des outils directement, le modèle renvoie un plan structuré. Celui-ci décrit les étapes à exécuter :

```json
{
  "version": "1",
  "blocks": [
    {
      "type": "sql",
      "id": "query_1",
      "sql": "SELECT * FROM customers LIMIT 100",
      "description": "Get customer data",
      "output_var": "customers_data"
    },
    {
      "type": "sandbox",
      "id": "analysis_1",
      "code": "result = customers_data.groupby('country').size()",
      "description": "Count customers by country",
      "inputs": ["customers_data"],
      "outputs": ["result"]
    }
  ]
}
```

Cette approche :
- Garantit que toutes les opérations sont validées avant leur exécution
- Autorise une reprise automatique, dans des limites strictes
- Rend le plan d'exécution transparent

## Connexions

Les **connexions** conservent les identifiants de votre base de données :

- Mots de passe chiffrés au repos par chiffrement symétrique Fernet
- Pool de connexions pour les performances
- Prise en charge de SSL/TLS

## Artefacts

Les **artefacts** sont les fichiers produits pendant l'exécution :

- Graphiques et visualisations (PNG, SVG)
- Exports de données (CSV, JSON)
- Stockés de manière sécurisée, avec des URL signées

## Système de budgets

Datarelix utilise un **système de budgets** pour encadrer la consommation de ressources :

- Nombre maximal de blocs SQL par plan
- Nombre maximal de tentatives de reprise
- Limites de tokens pour les appels au LLM
- Limitation du débit, par clé d'API ou par utilisateur connecté

Cela évite les exécutions incontrôlées et assure un usage équitable des ressources. Les limites de formule — questions mensuelles, connexions actives, analyses IA du schéma — sont distinctes ; voir [Facturation et formules](/fr/guides/billing/) et les [réponses de formule et de quota](/fr/api/errors/).

## Contexte de schéma

Le **contexte de schéma** rassemble les métadonnées de votre base qui aident le LLM à écrire des requêtes justes :

- Noms et commentaires des tables
- Types et descriptions des colonnes
- Relations de clés étrangères

Le contexte de schéma est mis en cache et rafraîchi périodiquement.
