Catalyst vs Great Expectations : lequel choisir ?

Un moniteur hébergé fondé sur les contrats face à un framework Python open source — ce que chacun fait bien, quand chacun est le mauvais choix, et comment des équipes utilisent les deux.

2026-09-10 · 11 min read

Utilisez Great Expectations si votre équipe écrit du Python, si vos contrôles ont leur place à l'intérieur de pipelines que vous orchestrez déjà, et s'il vous faut étendre le framework avec une logique qu'aucun langage de règles ne peut exprimer. Utilisez Catalyst si les personnes qui savent ce que signifie « une bonne donnée » n'écrivent pas de Python, si vous voulez une surveillance planifiée des tables de votre entrepôt sans exploiter de runner, et si vous voulez que les règles soient stockées comme des contrats ODCS portables plutôt que comme du code dans un dépôt. Great Expectations est un framework que vous assemblez ; Catalyst est un produit que vous connectez. Le choix porte avant tout sur qui écrit et possède les règles — pas sur l'outil capable d'exprimer un contrôle de nullité.

Ce qu'est Great Expectations

Great Expectations (souvent « GX ») est un framework Python open source de validation des données. Vous l'installez avec pip, vous le pointez vers une source de données, et vous écrivez des expectations — des assertions déclaratives comme expect_column_values_to_not_be_null ou expect_column_values_to_be_between — regroupées en Expectation Suites. Un Checkpoint exécute une suite sur un lot de données et déclenche des actions en fonction du résultat. Les résultats sont rendus dans les Data Docs, un site HTML statique généré qui décrit ce qui a été exécuté et ce qui a échoué.

Le projet est sous licence Apache, mature, et possède de loin le plus grand catalogue de contrôles intégrés de sa catégorie, ainsi qu'une voie de première classe pour écrire les vôtres en Python. L'entreprise qui le développe commercialise également GX Cloud, une offre hébergée qui superpose une interface managée, des exécutions planifiées et des alertes au moteur open source. À l'heure où nous écrivons, l'API Python a changé de forme plus d'une fois d'une version majeure à l'autre — l'API 1.x n'est pas l'API 0.x — et ces migrations ont historiquement représenté un vrai travail, pas un simple changement de numéro de version.

Ce qu'est Catalyst

Catalyst est un produit hébergé de qualité des données. Vous connectez un utilisateur de base en lecture seule, le produit importe le schéma, et vous construisez les règles dans le navigateur — non-nullité, unicité, plages, motifs, ensembles de valeurs autorisées, fraîcheur, intégrité référentielle, et SQL personnalisé pour tout ce qui sort de l'ordinaire. Chaque règle est stockée comme un contrat Open Data Contract Standard : le constructeur visuel et le YAML sont deux vues du même document, et le YAML fait foi, si bien qu'une règle ajoutée dans l'interface produit un diff d'une ligne que vous pouvez relire.

Les contrôles s'exécutent en SQL sur votre entrepôt, selon une planification. Le jeu de données n'en sort jamais — Catalyst stocke les résultats, le nombre de violations et jusqu'à cinq exemples de lignes en échec par contrôle, capturés au moment où le contrôle s'exécute, jamais le jeu de données lui-même. Connecteurs à l'heure où nous écrivons : PostgreSQL, MySQL, SQL Server, BigQuery, Redshift, Microsoft Fabric, plus l'import de fichiers CSV, JSON et Excel.

Face à face

Mise en place : à quoi ressemble la première heure

Avec Great Expectations, la première heure relève de l'ingénierie. Installer la bibliothèque dans un environnement, créer un Data Context, définir une source et un asset de données, construire une suite, définir un checkpoint, décider où sont stockés les résultats de validation et les Data Docs, puis décider de ce qui déclenchera le tout. Aucune de ces étapes n'est difficile ; elles sont six, elles vivent toutes dans du code, et elles doivent toutes être maintenues. Si vous avez déjà un dépôt Python avec un orchestrateur dedans, l'essentiel de cet échafaudage existe et le coût marginal est faible. Sinon, vous montez un petit service avant d'avoir validé la moindre ligne.

Avec Catalyst, la première heure relève de la configuration. Créez un rôle en lecture seule, collez les paramètres de connexion, choisissez une table. L'import de schéma lit information_schema et propose un contrat de base à partir de ce qu'il trouve — les colonnes obligatoires deviennent des règles de non-nullité, les clés primaires des règles d'unicité, les horodatages des candidats à la fraîcheur — et vous éditez à partir de là. Le guide PostgreSQL donne les instructions GRANT exactes, y compris la ligne ALTER DEFAULT PRIVILEGES que tout le monde oublie.

Pour le dire honnêtement : le coût de mise en place de GX vous achète un framework généraliste capable de valider tout ce qu'un processus Python peut lire. Celui de Catalyst est plus faible parce que son périmètre est plus étroit — des tables dans un entrepôt, contrôlées sur place.

Écrire les règles

Voici à peu près à quoi ressemble une suite dans l'API Python actuelle de GX :

import great_expectations as gx

context = gx.get_context()
suite = context.suites.add(gx.ExpectationSuite(name="orders"))

suite.add_expectation(
    gx.expectations.ExpectColumnValuesToNotBeNull(column="order_id")
)
suite.add_expectation(
    gx.expectations.ExpectColumnValuesToBeInSet(
        column="status",
        value_set=["pending", "paid", "shipped", "refunded"],
    )
)

Et les mêmes expectations sous forme de contrat ODCS :

apiVersion: v3.0.0
kind: DataContract
info:
  title: orders
  version: 1.0.0
  owner: data-platform
schema:
  - name: orders
    physicalType: table
    properties:
      - name: order_id
        logicalType: string
        quality:
          - rule: nullCount
            dimension: completeness
            severity: error
            mustBe: "0"
      - name: status
        logicalType: string
        quality:
          - rule: validValues
            dimension: conformity
            severity: error
            mustBe: "['pending', 'paid', 'shipped', 'refunded']"

Ni l'un ni l'autre n'est manifestement meilleur en tant que texte. La différence tient à qui peut l'écrire, et à ce qui se passe quand la règle est fausse. La version Python peut faire des choses dont le YAML est incapable — appeler un modèle, comparer avec un second système, calculer une statistique sur une fenêtre glissante — parce que c'est un programme. La version YAML peut être lue et modifiée par un analyste, un data steward ou un responsable métier qui n'ouvrira jamais un terminal, et elle porte une dimension, si bien que cent règles se consolident en une vue de couverture plutôt qu'en une liste.

La bibliothèque d'expectations de GX est réellement vaste, et s'il vous faut expect_column_kl_divergence_to_be_less_than, utilisez GX, parce que Catalyst ne l'a pas et ne prétendra pas le contraire. Catalyst couvre les contrôles qui attrapent l'écrasante majorité des incidents réels, et bascule sur du SQL personnalisé pour le reste.

Où vivent les règles

C'est la partie qui survit au choix de l'outil. Les Expectation Suites de GX sont au format de GX : lisibles, mais écrites pour un seul runner, et logées dans le dépôt Python qui possède le pipeline. C'est très bien tant que GX est la réponse, et c'est une réécriture si GX cesse de l'être.

Catalyst stocke les contrats en ODCS, une spécification ouverte développée dans le cadre du projet Bitol de la Linux Foundation. Le contrat décrit la promesse du jeu de données indépendamment de qui la fait respecter, s'exporte sous forme de fichier, et s'importe dans tout ce qui parle ce standard. Si vous quittez Catalyst, les règles partent avec vous — ce qui est une chose curieuse à mettre en avant pour un éditeur, et la principale raison de faire confiance à ce format.

Choisissez Great Expectations si…

• Votre équipe écrit du Python et exploite déjà un orchestrateur. GX s'insère dans Airflow, Dagster ou Prefect comme une tâche. C'est son habitat naturel et il y excelle.
• Il vous faut une logique personnalisée qu'aucun langage de règles déclaratif n'exprime — dérive de distribution, tests statistiques, réconciliation inter-systèmes, contrôles qui appellent un modèle. Les expectations personnalisées en Python n'ont pas de plafond.
• Vous validez des dataframes, pas seulement des tables. GX contrôle les données en cours de pipeline, dans pandas ou Spark, avant que quoi que ce soit n'atterrisse. Catalyst valide ce qui se trouve déjà dans l'entrepôt et ne voit pas un dataframe.
• La validation doit faire échouer un build. Un checkpoint qui se termine avec un code non nul bloque un DAG ou un job de CI. C'est un autre métier que la surveillance, et GX le fait nativement.
• Votre budget est nul mais pas votre temps d'ingénierie. Apache 2.0, pas de sièges, pas d'éditeur.
• Vous utilisez un entrepôt que Catalyst ne prend pas encore en charge. Snowflake et Databricks sont les exemples évidents ; via SQLAlchemy, GX les gère dès aujourd'hui.
• Votre politique interne interdit qu'un service externe détienne des métadonnées d'entrepôt. Catalyst est hébergé en Europe et ne stocke que les résultats, le nombre de violations et jusqu'à cinq exemples de lignes en échec par contrôle, mais l'auto-hébergement reste l'auto-hébergement.

Choisissez Catalyst si…

• Les personnes qui connaissent les règles métier n'écrivent pas de Python. C'est de loin la raison la plus fréquente qui amène les équipes ici. Des règles écrites par la personne qui comprend les données valent mieux que des règles écrites par celle qui comprend le framework.
• Vous voulez de la surveillance, pas seulement des assertions. Exécutions planifiées, historique pass/warn/fail et courbes de tendance arrivent configurés plutôt qu'à assembler.
• Vous voulez un format de règles ouvert. Les contrats ODCS sont relisibles en pull request et portables d'un outil à l'autre.
• Personne n'a envie de posséder un service de validation. Pas d'environnement à mettre à jour, pas de bucket pour les Data Docs, pas de montées de version de dépendances, pas de migration quand l'API change de forme.
• Il vous faut des rôles, du SSO et une traçabilité. RBAC et journal d'audit sont dans le produit, pas dans un projet à mener.
• Vos données vivent à des endroits hétérogènes, dont BigQuery, un Postgres principal et le tableur occasionnel, et vous voulez une vue unique sur l'ensemble.

Utiliser les deux

Ces outils ne s'excluent pas, et un nombre non négligeable d'équipes font tourner les deux délibérément. Le partage qui fonctionne : GX à l'intérieur du pipeline, comme barrière — les contrôles qui doivent bloquer un build avant que des données fausses n'atterrissent, plus les expectations statistiques exotiques. Catalyst au-dessus du pipeline, comme moniteur — les promesses durables et relisibles portant sur les tables dont dépendent les consommateurs, exécutées selon une planification quel que soit le job qui les a écrites aujourd'hui, avec l'historique qu'un log d'échec de CI ne vous donne pas.

Si vous avez déjà des suites GX, la migration n'est pas automatique — il n'existe pas d'importateur à l'heure où nous écrivons — mais la traduction est mécanique pour les expectations courantes, et commencer par importer le schéma fait générer pour vous l'essentiel du contrat. Pour une vision plus large de ce qu'il faut contrôler et pourquoi, commencez par le guide de la validation des données.

Questions fréquentes

Great Expectations est-il gratuit ?

La bibliothèque Python Great Expectations est open source sous licence Apache 2.0 et libre d'utilisation, y compris à des fins commerciales. GX Cloud, le produit hébergé de la même entreprise, est une offre commerciale avec sa propre tarification — consultez leur site pour les conditions en vigueur. « Gratuit » au sens open source signifie toujours que vous payez le calcul sur lequel l'outil tourne et le temps d'ingénierie nécessaire pour l'exploiter.

Catalyst nécessite-t-il Python ?

Non. Catalyst se connecte à votre base via un utilisateur en lecture seule et les règles se construisent dans le navigateur ou s'écrivent en YAML ODCS. Il n'y a rien à installer et aucun code à exécuter. Le SQL est facultatif, et seulement pour des règles personnalisées que les types intégrés ne couvrent pas.

Puis-je utiliser Great Expectations et Catalyst ensemble ?

Oui, et c'est une architecture raisonnable. Utilisez Great Expectations comme barrière de pipeline — des assertions qui font échouer un build avant que des données fausses n'atterrissent — et Catalyst comme couche de surveillance et de contrats sur les tables déjà atterries, avec des exécutions planifiées et un historique pass/warn/fail. Les deux lisent les mêmes données et répondent à des questions différentes.

Catalyst peut-il valider des dataframes pandas ou Spark ?

Non. Catalyst valide les données au repos — tables et vues d'un entrepôt connecté, plus les fichiers CSV, JSON et Excel importés. Les dataframes en mémoire à l'intérieur d'un job Python en cours d'exécution sont exactement le cas d'usage pour lequel Great Expectations existe.

Lequel convient le mieux à une petite équipe data ?

Si l'équipe est constituée d'un ou deux ingénieurs qui vivent dans Python et exploitent déjà un orchestrateur, Great Expectations ne coûte rien et s'intègre au flux de travail existant. Si l'équipe compte des analystes ou des responsables métier qui devraient être les auteurs des règles, ou si personne ne veut maintenir un service de plus, un outil hébergé l'emporte sur le temps total passé. L'offre Starter de Catalyst est gratuite pour une connexion et un jeu de données (PostgreSQL et MySQL), ce qui suffit à tester l'hypothèse avant de s'engager.