Great Expectations en 2026 : Validation de la Qualité des Données et Questions d'Entretien

Great Expectations (GX) constitue le framework open-source de référence pour la validation de la qualité des données dans les pipelines Python. La version 1.22, publiée en août 2026, consolide les changements d'API introduits dans GX 1.0 et ajoute le support expérimental de Python 3.14. Pour les data engineers construisant des pipelines de production, cet outil représente un élément indispensable de l'infrastructure moderne.

Les Problèmes Résolus par Great Expectations dans les Pipelines de Données

Les pipelines de données échouent silencieusement. Un changement de schéma en amont, une valeur nulle là où aucune ne devrait exister, un format de date qui passe d'ISO à Unix timestamp : ces problèmes atteignent souvent les dashboards ou les modèles de machine learning avant que quiconque ne les remarque. Great Expectations traite les données comme du code, appliquant des assertions (appelées Expectations) qui s'exécutent automatiquement aux points de contrôle du pipeline.

Le framework s'intègre avec Apache Airflow, Databricks, Snowflake, et les services de stockage cloud comme AWS S3 et Azure Blob Storage. Chaque validation produit des Data Docs, des rapports HTML que les parties prenantes non techniques peuvent consulter.

Concepts Fondamentaux : Data Context, Data Sources et Expectations

GX 1.22 organise la validation autour de quatre composants : le Data Context, les Data Sources, les Data Assets et les Expectation Suites.

Le Data Context représente l'objet de configuration central. Il stocke les métadonnées pour les Data Sources, les Expectation Suites, les Checkpoints et l'historique des Validation Results. Dans la plupart des projets, un seul répertoire gx/ contient les fichiers de configuration YAML et les Data Docs générés.

Une Data Source représente une connexion à une base de données, un data warehouse ou un système de fichiers. Un Data Asset constitue une collection logique d'enregistrements dans cette source, similaire à une table ou au résultat d'une requête.

# gx_setup.py
import great_expectations as gx

# Initialize or load an existing Data Context
context = gx.get_context()

# Add a Pandas Data Source for local files
data_source = context.data_sources.add_pandas("local_files")

# Define a Data Asset pointing to a specific CSV pattern
data_asset = data_source.add_csv_asset(
    name="user_events",
    filepath_or_buffer="data/user_events_*.csv"  # Glob pattern
)

Cette configuration permet à GX de valider tout CSV correspondant au pattern user_events_*.csv dans le répertoire data/.

Construction d'une Expectation Suite pour la Validation des Colonnes

Une Expectation Suite représente une collection d'assertions contre un Data Asset. Chaque Expectation déclare une condition qui devrait être vraie pour les données, comme "la colonne user_id ne doit jamais être nulle" ou "la colonne age doit contenir des valeurs entre 0 et 120."

# build_suite.py
import great_expectations as gx

context = gx.get_context()

# Create or retrieve an Expectation Suite
suite = context.suites.add(
    gx.ExpectationSuite(name="user_events_suite")
)

# Add Expectations to the suite
suite.add_expectation(
    gx.expectations.ExpectColumnToExist(column="user_id")
)
suite.add_expectation(
    gx.expectations.ExpectColumnValuesToNotBeNull(column="user_id")
)
suite.add_expectation(
    gx.expectations.ExpectColumnValuesToBeBetween(
        column="age",
        min_value=0,
        max_value=120
    )
)
suite.add_expectation(
    gx.expectations.ExpectColumnValuesToMatchRegex(
        column="email",
        regex=r"^[\w.-]+@[\w.-]+\.\w+$"
    )
)

# Save the suite to the Data Context
context.suites.save(suite)

GX 1.0+ utilise une API basée sur les classes pour les Expectations. L'ancienne syntaxe basée sur les dictionnaires (expect_column_to_exist) reste disponible mais l'approche basée sur les classes offre une meilleure autocomplétion IDE et une sécurité de typage.

Exécution des Validations avec les Checkpoints

Un Checkpoint relie un Data Asset, une Expectation Suite et des Actions optionnelles qui se déclenchent lorsque la validation réussit ou échoue. Les Checkpoints représentent le point d'entrée principal pour la validation automatisée en production.

# run_checkpoint.py
import great_expectations as gx

context = gx.get_context()

# Create a Checkpoint
checkpoint = context.checkpoints.add(
    gx.Checkpoint(
        name="user_events_checkpoint",
        validation_definitions=[
            gx.ValidationDefinition(
                name="validate_user_events",
                data=context.data_sources.get("local_files")
                    .get_asset("user_events")
                    .build_batch_request(),
                suite=context.suites.get("user_events_suite")
            )
        ],
        actions=[
            gx.checkpoint.UpdateDataDocsAction(name="update_docs"),
        ]
    )
)

# Run the Checkpoint
result = checkpoint.run()

# Check overall success
if result.success:
    print("All validations passed")
else:
    print("Validation failures detected")
    for validation_result in result.run_results.values():
        for expectation_result in validation_result.results:
            if not expectation_result.success:
                print(f"  Failed: {expectation_result.expectation_config}")

Lorsque le Checkpoint s'exécute, GX charge le batch, applique chaque Expectation et met à jour les Data Docs. Les validations échouées peuvent déclencher des notifications Slack, des alertes PagerDuty ou l'arrêt du pipeline selon les Actions configurées.

Intégration de GX avec les DAGs Apache Airflow

La plupart des pipelines de données en production utilisent un orchestrateur comme Apache Airflow. GX fournit une intégration officielle Airflow qui encapsule l'exécution des Checkpoints dans un opérateur.

# dags/user_events_pipeline.py
from airflow import DAG
from airflow.operators.python import PythonOperator
from datetime import datetime
import great_expectations as gx

def validate_user_events():
    """Run GX Checkpoint for user events data."""
    context = gx.get_context(context_root_dir="/opt/airflow/gx")
    checkpoint = context.checkpoints.get("user_events_checkpoint")
    result = checkpoint.run()
    
    if not result.success:
        # Raise exception to fail the Airflow task
        raise ValueError("Data validation failed. Check Data Docs for details.")

with DAG(
    dag_id="user_events_pipeline",
    start_date=datetime(2026, 1, 1),
    schedule_interval="@daily",
    catchup=False
) as dag:
    
    validate_task = PythonOperator(
        task_id="validate_user_events",
        python_callable=validate_user_events
    )
    
    # Downstream tasks depend on validation passing
    # transform_task >> load_task

Placer la validation avant les tâches de transformation empêche les mauvaises données de se propager en aval. Ce pattern, parfois appelé "shift-left testing", détecte les problèmes à l'ingestion plutôt qu'après l'achèvement des jobs de calcul coûteux.

Questions d'Entretien Courantes sur Great Expectations

Les entretiens en data engineering en 2026 incluent fréquemment des questions sur les outils de qualité des données. Voici les questions qui apparaissent dans les entretiens techniques, avec les réponses qui distinguent les candidats expérimentés des juniors.

"Comment implémenteriez-vous des contrôles de qualité des données dans un pipeline de production ?"

Les bonnes réponses mentionnent l'intégration de la validation comme une étape du pipeline, pas comme un dashboard séparé. Spécifiquement :

• La validation de schéma à l'ingestion détecte immédiatement les problèmes structurels, par exemple une chaîne apparaissant là où un entier était attendu
• La validation de logique métier vérifie les contraintes de domaine comme les prix positifs et les plages de dates
• Les alertes automatisées notifient les ingénieurs d'astreinte lorsque la validation échoue, prévenant la corruption silencieuse des données
• Les tests dbt gèrent les contrôles de la couche transformation tandis que GX gère la validation d'ingestion et de sortie

"Quelle est la différence entre une Expectation Suite et un Checkpoint ?"

Une Expectation Suite contient les assertions elles-mêmes : quelles colonnes doivent exister, quelles plages de valeurs sont acceptables, quels patterns regex doivent correspondre. Elle définit ce qu'il faut vérifier.

Un Checkpoint définit quand et comment exécuter ces contrôles. Il connecte un Data Asset spécifique (les données à valider), une Expectation Suite (les règles à appliquer) et des Actions (ce qui se passe après la validation).

"Comment gérer les Expectations qui varient selon l'environnement ?"

Les données de production ont souvent des caractéristiques différentes des données de staging. Deux approches :

1. Expectations Paramétrées : Utiliser des variables d'environnement ou des paramètres runtime pour ajuster les seuils. Par exemple, min_value=int(os.getenv("AGE_MIN", 0)).

2. Suites Multiples : Maintenir des suites séparées pour staging et production. Le staging peut autoriser les nulls dans les champs optionnels pour tester les flux de données incomplets.

"Que se passe-t-il quand un Checkpoint échoue dans un pipeline planifié ?"

Le Checkpoint retourne un CheckpointResult avec success=False. Le comportement du pipeline dépend de la façon dont l'orchestrateur gère l'échec :

• Dans Airflow, lever une exception marque la tâche comme échouée, bloquant les tâches en aval
• Dans Databricks, le notebook peut sortir avec un statut d'erreur
• Les Actions attachées au Checkpoint peuvent envoyer des messages Slack, créer des tickets Jira ou déclencher des procédures de rollback

Expectations Personnalisées pour la Validation Spécifique au Domaine

GX inclut plus de 300 Expectations intégrées, mais les règles spécifiques au domaine nécessitent souvent des implémentations personnalisées. Une Expectation personnalisée étend la classe de base et implémente la logique de validation.

# custom_expectations/expect_valid_iso_country_code.py
from great_expectations.expectations import Expectation
from great_expectations.core import ExpectationConfiguration
import pycountry

class ExpectValidIsoCountryCode(Expectation):
    """Expect column values to be valid ISO 3166-1 alpha-2 country codes."""
    
    column: str
    
    @classmethod
    def _prescriptive_template(cls) -> str:
        return "Column {column} values must be valid ISO country codes"
    
    def _validate(self, metrics, runtime_configuration=None, execution_engine=None):
        column_values = metrics.get("column_values")
        valid_codes = {c.alpha_2 for c in pycountry.countries}
        
        invalid_values = [
            v for v in column_values 
            if v is not None and v not in valid_codes
        ]
        
        return {
            "success": len(invalid_values) == 0,
            "result": {
                "observed_value": len(invalid_values),
                "unexpected_list": invalid_values[:10]  # Sample
            }
        }

Les Expectations personnalisées s'enregistrent en les plaçant dans le répertoire great_expectations/plugins/ ou en ajoutant le module au plugins_directory dans great_expectations.yml.

Data Docs : Communiquer la Qualité aux Parties Prenantes

Les Data Docs sont des sites HTML statiques générés à partir des résultats de validation. Chaque exécution produit une page montrant quelles Expectations ont réussi ou échoué, avec des détails sur les valeurs inattendues.

# Generate and open Data Docs
context = gx.get_context()
context.build_data_docs()
context.open_data_docs()  # Opens browser

Pour les systèmes de production, les Data Docs peuvent être hébergés sur S3, GCS ou Azure Blob Storage avec des contrôles d'accès appropriés. La plateforme GX Cloud offre des Data Docs hébergés avec des fonctionnalités de collaboration d'équipe.

Migration GX 1.0 : Changements Majeurs depuis 0.x

Les équipes mettant à niveau depuis GX 0.x font face à des changements d'API. Les principales différences :

Le guide de migration officiel couvre chaque changement. Pour les grandes bases de code, la migration incrémentale utilisant des shims de compatibilité réduit les risques.

Points Clés pour la Qualité des Données avec GX 1.22

• Great Expectations 1.22 (août 2026) supporte Python 3.10 à 3.13, avec un support expérimental de 3.14 via la variable d'environnement GX_PYTHON_EXPERIMENTAL
• Les Expectation Suites définissent ce qu'il faut valider, les Checkpoints définissent quand et comment
• Intégrer les Checkpoints comme étapes de pipeline dans les DAGs Airflow ou les notebooks Databricks pour détecter les mauvaises données à l'ingestion
• Les Expectations personnalisées gèrent les règles spécifiques au domaine que les Expectations intégrées ne peuvent pas couvrir
• Les Data Docs fournissent des rapports HTML lisibles par les parties prenantes ; les héberger sur le stockage cloud pour l'accès en production
• Les réponses d'entretien doivent mettre l'accent sur la qualité des données comme étape de pipeline intégrée, pas comme un dashboard ajouté après coup