Catalyst vs Soda : comparatif des outils de qualité des données

SodaCL et Soda Core face aux contrats au format Open Data Contract Standard — mise en place, connecteurs, détection d'anomalies, et quand chacun est le mauvais choix.

2026-09-10 · 11 min read

Utilisez Soda si vous voulez une CLI open source qui exécute des contrôles depuis un fichier dans votre propre infrastructure, s'il vous faut des connecteurs que Catalyst n'a pas encore, ou si vous voulez une détection d'anomalies pilotée par apprentissage automatique sur des métriques. Utilisez Catalyst si vous voulez un produit hébergé sans rien à installer, des règles écrites dans un navigateur par des personnes qui n'ouvrent pas de terminal, et des contrats stockés en ODCS — un standard ouvert plutôt que le langage de contrôles propre à un éditeur. Les deux sont déclaratifs, les deux poussent les contrôles en SQL, et les deux sont agréables à lire. La vraie différence est que Soda est un runner que vous exploitez et Catalyst un service que vous connectez.

Ce qu'est Soda

Soda se présente en deux moitiés. Soda Core est une CLI Python open source : vous l'installez avec pip, vous décrivez votre source de données dans un fichier de configuration, vous écrivez des contrôles en SodaCL — le Soda Checks Language, un dialecte YAML — et vous lancez soda scan. La commande se termine avec un code non nul quand un contrôle échoue, ce qui la rend naturelle en CI, dans Airflow ou dans un job dbt.

Soda Cloud est le SaaS commercial qui vient par-dessus : tableaux de bord, historique des contrôles, gestion des incidents, alertes vers Slack et les outils de ticketing, et détection d'anomalies qui apprend la forme normale d'une métrique au lieu de la comparer à un seuil qu'il a fallu deviner. Pour les organisations qui ne peuvent pas laisser un SaaS atteindre directement l'entrepôt, Soda propose un agent auto-hébergé qui s'exécute à l'intérieur de votre réseau et communique vers l'extérieur avec Soda Cloud, de sorte que les scans restent configurables de façon centralisée.

La liste de connecteurs de Soda est large — les entrepôts courants plus Snowflake, Databricks, Athena, Trino, Oracle et d'autres à l'heure où nous écrivons — et SodaCL est l'un des langages de contrôles les plus lisibles de la catégorie. Rendons à César ce qui lui appartient : c'est ce qui se rapproche le plus d'une expérience d'écriture de type contrat en dehors des contrats eux-mêmes.

Ce qu'est Catalyst

Catalyst est un produit hébergé de qualité des données, sans CLI ni bibliothèque. 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 le reste. Les règles sont stockées comme des contrats Open Data Contract Standard — le constructeur visuel et le YAML sont deux vues d'un même document, et le YAML fait foi, si bien qu'une modification faite dans l'interface est un diff d'une ligne.

Les contrôles s'exécutent en SQL à l'intérieur de votre entrepôt, selon une planification. Le jeu de données y reste ; 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

La première heure de Soda Core est une petite tâche d'ingénierie : créer un environnement Python, installer le package correspondant à votre entrepôt, écrire un configuration.yml avec les identifiants, écrire un checks.yml, lancer le scan, puis décider ce qui l'exécutera selon une planification et où iront les résultats. Rien n'est difficile et la documentation est bonne. Il n'en reste pas moins un composant qui vous appartient désormais — un environnement Python à maintenir à jour, des identifiants à placer quelque part en sécurité, et un ordonnanceur à câbler.

Soda Cloud en retire une partie, mais si votre posture de sécurité impose l'agent auto-hébergé, vous avez échangé un pip install contre un déploiement Kubernetes. C'est un arbitrage sensé pour une grande organisation dotée d'une équipe plateforme, et un mauvais arbitrage pour une équipe data de cinq personnes.

La première heure de Catalyst est de la configuration : créer un rôle en lecture seule, coller les paramètres de connexion, choisir une table. L'import de schéma lit le catalogue et propose un contrat de base à partir des types et de la nullabilité qu'il y trouve : vous commencez donc par éditer trente règles générées plutôt que par les saisir. Le guide PostgreSQL donne les droits exacts ; Redshift a ses propres particularités, à lire au préalable.

Écrire les règles

SodaCL est réellement agréable à lire :

checks for orders:
  - missing_count(order_id) = 0
  - duplicate_count(order_id) = 0
  - invalid_count(status) = 0:
      valid values: [pending, paid, shipped, refunded]
  - freshness(created_at) < 24h
  - row_count > 0

Le contrat ODCS équivalent est plus verbeux, et cette verbosité achète quelque chose :

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
        required: true
        primaryKey: true
        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']"
      - name: created_at
        logicalType: timestamp
        quality:
          - rule: freshness
            dimension: timeliness
            severity: error
            mustBe: "<= 24h"

Trois différences comptent. Le contrat porte le schéma en plus des contrôles : il décrit donc le jeu de données au lieu de se contenter d'affirmer des choses à son sujet. Chaque règle porte une dimension, si bien que cent règles se consolident en une matrice de couverture — sommes-nous couverts sur l'actualité, ou seulement sur la complétude ? — plutôt qu'en une liste à plat. Et le format est un standard ouvert développé dans le cadre du projet Bitol de la Linux Foundation, pas le langage d'un éditeur : les règles sont donc portables vers tout runner qui le parle.

En regard : SodaCL est plus compact, et pour un ingénieur qui écrit des contrôles dans un éditeur de texte, la compacité est un vrai atout. Si vos règles ne seront jamais écrites que par des personnes à l'aise dans un dépôt, la structure supplémentaire d'ODCS est un surcoût dont vous n'avez peut-être pas envie.

La détection d'anomalies, et l'honnêteté sur une lacune

La détection d'anomalies de Soda Cloud observe une métrique dans le temps et signale les écarts par rapport au motif qu'elle a appris. Catalyst n'a pas cela. Les contrôles de Catalyst sont des règles déterministes avec des seuils que vous fixez : un nombre de lignes qui doit être supérieur à zéro, une fenêtre de fraîcheur de 24 heures, une plage de valeurs plausibles.

Ce que vous voulez dépend de la défaillance que vous cherchez à attraper. Les règles déterministes attrapent les violations d'une promesse énoncée, et elles ne se déclenchent jamais parce que le mardi a été calme. La détection d'anomalies attrape les défaillances pour lesquelles personne n'avait songé à écrire une règle — une baisse de 40 % du nombre de lignes qui reste techniquement au-dessus de votre seuil > 0 — et elle vous coûte une période de réglage et quelques faux positifs le temps de son apprentissage. Si ce sont les inconnues non anticipées sur le volume et la distribution qui vous préoccupent en premier lieu, c'est une vraie raison de choisir Soda.

Choisissez Soda si…

• Vous voulez un runner open source que vous maîtrisez. Soda Core est sous licence Apache et gratuit ; les contrôles s'exécutent entièrement dans votre infrastructure, sans éditeur sur le chemin.
• Il vous faut un entrepôt que Catalyst ne prend pas encore en charge — Snowflake, Databricks, Athena, Trino et Oracle sont les cas évidents.
• La validation doit faire échouer un pipeline. soda scan renvoie un code de sortie non nul, ce qui est exactement ce qu'attend un job de CI ou une tâche Airflow. Catalyst surveille selon sa propre planification ; il ne bloque pas votre build.
• Vous voulez de la détection d'anomalies, pas seulement des règles à seuil.
• Votre politique interdit qu'un SaaS atteigne votre entrepôt. L'agent auto-hébergé garde la connexion à l'intérieur de votre réseau. 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 la connexion reste entrante depuis un service.
• Vos contrôles vivent à côté de votre projet dbt et vous les voulez versionnés, relus et exécutés dans le même job que les modèles qu'ils couvrent.
• Votre équipe connaît déjà SodaCL. La familiarité vaut plus qu'un format marginalement meilleur.

Choisissez Catalyst si…

• Les personnes qui connaissent les règles métier n'utilisent pas de terminal. Un analyste ou un responsable métier peut ajouter une règle sans pull request, sans environnement Python et sans revue de code de l'équipe plateforme.
• Vous voulez des règles dans un standard ouvert. Les contrats ODCS s'exportent sous forme de fichier et s'importent dans tout ce qui parle la spécification. SodaCL est lisible, mais il appartient à Soda.
• Vous voulez que l'ensemble soit un seul produit. Planification, historique, couverture et exploration détaillée arrivent configurés plutôt qu'assemblés à partir d'une CLI, plus un compte cloud, plus un agent, plus un orchestrateur.
• La gouvernance fait partie du besoin. RBAC, journal d'audit et SSO sont dans le produit dès le premier jour.
• Vous voulez voir les lignes en échec. Un contrôle en échec renvoie directement vers un échantillon des enregistrements fautifs, ce qui est en général la première chose que l'on demande.
• Vous voulez des tarifs modestes et prévisibles. Starter est gratuit pour une connexion et un jeu de données (PostgreSQL et MySQL) ; Team est à 29 € par utilisateur et par mois.

Peuvent-ils coexister ?

Oui, et le partage est net. Soda dans le pipeline, comme barrière : des assertions rapides qui arrêtent un mauvais chargement avant qu'il n'atterrisse, exécutées par le job qui a construit la table. Catalyst au-dessus du pipeline, comme couche de contrats et de surveillance : les promesses durables portant sur les jeux de données dont dépendent vos consommateurs, versionnées en ODCS, vérifiées selon une planification quel que soit le pipeline qui les a écrites aujourd'hui, avec l'historique d'exécutions et la vue de couverture que veulent les personnes qui doivent faire confiance aux chiffres — plutôt qu'un log de job.

Migrer de SodaCL vers ODCS est manuel à l'heure où nous écrivons — il n'existe pas d'importateur — mais les contrôles courants se correspondent presque un pour un (missing_count vers nullCount, duplicate_count vers duplicateCount, invalid_count avec valid values vers validValues, freshness vers freshness), et commencer par importer le schéma génère l'essentiel du contrat avant même toute traduction. Si vous en êtes encore à décider ce qu'il faut contrôler, commencez par le guide de la validation des données.

Questions fréquentes

Soda est-il gratuit ?

Soda Core, la CLI open source, est gratuite sous licence Apache 2.0 et vous pouvez l'exécuter en production sans payer qui que ce soit. Soda Cloud — les tableaux de bord hébergés, les alertes, la gestion des incidents et la détection d'anomalies — est un produit commercial avec sa propre tarification ; consultez le site de Soda pour les conditions en vigueur. L'essentiel de ce que l'on imagine en disant « Soda » correspond à la moitié cloud.

Catalyst nécessite-t-il Python ou une CLI ?

Non. Catalyst est une application web. Vous connectez un utilisateur de base en lecture seule, les règles se construisent dans le navigateur ou s'écrivent en YAML ODCS dans l'éditeur, et les exécutions se planifient dans le produit. Il n'y a rien à installer, pas d'environnement à maintenir et pas de commande de scan à ordonnancer.

Quelle est la différence entre SodaCL et ODCS ?

SodaCL est le langage de contrôles propre à Soda : compact, lisible, et compris par les runners de Soda. ODCS est l'Open Data Contract Standard, une spécification ouverte développée dans le cadre du projet Bitol de la Linux Foundation, qui décrit le schéma, la responsabilité, les niveaux de service et les règles de qualité d'un jeu de données dans un seul document YAML versionné, exécutable par tout outil compatible. La différence pratique tient à la portabilité — un contrat ODCS survit à un changement d'éditeur.

Catalyst fait-il de la détection d'anomalies ?

Pas à l'heure où nous écrivons. Catalyst exécute des règles déterministes par rapport à des seuils que vous définissez, enregistre un historique pass/warn/fail et affiche les tendances dans le temps. S'il vous faut spécifiquement un suivi statistique qui apprend la plage normale d'une métrique, Soda Cloud l'a et Catalyst non.

Puis-je utiliser Soda et Catalyst ensemble ?

Oui. Un montage courant consiste à utiliser Soda Core comme barrière de build à l'intérieur du pipeline et Catalyst comme couche de contrats et de surveillance sur les tables qui atterrissent : les échecs de pipeline arrêtent les données fausses tôt, tandis que les contrats donnent aux consommateurs une promesse versionnée et relisible, avec sa propre planification et son propre historique d'exécutions.