Des règles simples qui évitent des catastrophes coûteuses
Une ETI logistique découvre qu'elle a facturé 120 000 euros en double sur un trimestre. La cause : des doublons dans la table commandes de l'ERP, créés par un import mal configuré 4 mois plus tôt. Une simple règle d'unicité sur le numéro de commande — vérifiée automatiquement à chaque import — aurait détecté le problème dès le premier jour. Un plan de contrôle qualité, c'est un ensemble de règles automatisées qui surveillent vos données 24h/24 : complétude, unicité, format, fraîcheur et cohérence. Coût de mise en place : 2 à 4 semaines. Coût d'un incident évité : 10 000 à 500 000 euros.
Le problème
Dans une PME typique, la qualité des données est gérée « au feeling ». Quelqu'un remarque une anomalie dans un rapport, lance une investigation, corrige manuellement et passe à autre chose. Aucune règle formelle, aucun contrôle automatisé, aucun suivi dans le temps. Les mêmes problèmes reviennent mois après mois.
Les types d'erreurs les plus coûteux :
- Complétude manquante — 15 % des fiches clients dans le CRM n'ont pas d'adresse e-mail. Le service marketing envoie une campagne à toute la base et obtient un taux de délivrabilité catastrophique de 72 %. Les 3 500 clients sans e-mail ne reçoivent jamais les communications — et personne ne le sait. Résultat : 45 000 euros de chiffre d'affaires perdu sur des clients « oubliés ».
- Doublons non détectés — Le même fournisseur est créé 3 fois dans l'ERP avec des orthographes légèrement différentes (« Dupont SAS », « DUPONT S.A.S. », « dupont sas »). Les commandes sont réparties sur 3 comptes. Résultat : les conditions de remise par volume ne s'appliquent pas, et l'entreprise paie 12 % de plus que négocié. Perte annuelle estimée : 35 000 euros.
- Données périmées — La table des prix produits n'a pas été mise à jour depuis 6 mois pour 200 références. Le site e-commerce affiche les anciens prix. Des clients commandent à des prix obsolètes. L'entreprise doit honorer les commandes ou risquer un litige. Perte : 8 000 euros sur un trimestre.
- Incohérences inter-systèmes — Un produit est marqué « en stock » dans l'ERP mais « rupture » sur le site web. Les clients commandent un produit indisponible. Le service client gère 150 réclamations par mois liées à ce problème. Coût en temps de traitement et en image de marque : inestimable.
Tous ces incidents auraient été détectés par des règles de qualité basiques — mais personne ne les avait définies ni automatisées. Consultez notre offre observabilité et traçabilité pour passer à l'action.
La solution IA
Un plan de contrôle qualité s'organise autour de 5 dimensions. L'IA renforce chaque dimension en détectant des anomalies que les règles statiques ne couvrent pas.
Règles de complétude et unicité
Vérification automatique que les champs obligatoires sont remplis (e-mail client, numéro de commande, code produit) et que les clés primaires sont uniques. L'IA va plus loin : elle détecte les « quasi-doublons » par fuzzy matching (« Dupont SAS » vs « DUPONT S.A.S. ») et les valeurs par défaut suspectes (ex : « [email protected] » dans 200 fiches clients). Exemples : email NOT NULL, UNIQUE(order_id), fuzzy_match(supplier_name) > 0.85.
Règles de format et de cohérence
Vérification que les données respectent les formats attendus : e-mail valide (regex), code postal à 5 chiffres, SIRET à 14 chiffres, montants positifs, dates dans le futur pour les livraisons. L'IA ajoute des règles de cohérence croisée : « si le pays est France, le code postal doit commencer par 0-9 et avoir 5 chiffres », « le montant TTC = montant HT × (1 + taux TVA) ± 0,01 euro ».
Règles de fraîcheur et de volume
Vérification que les données sont mises à jour dans les délais attendus : la table commandes doit recevoir de nouvelles lignes chaque jour ouvré, les prix produits doivent être mis à jour au moins une fois par mois, les données RH doivent être synchronisées dans les 24h après un mouvement de personnel. L'IA apprend les patterns de volume historiques et alerte si le volume du jour s'écarte de plus de 2 écarts-types.
Mise en oeuvre
Le plan de contrôle qualité se déploie en trois phases sur 2 à 4 semaines.
Identification des tables et règles critiques (semaine 1)
Sélectionnez vos 5 à 10 tables les plus critiques (clients, commandes, produits, factures, fournisseurs). Pour chacune, définissez 3 à 5 règles couvrant les 5 dimensions : complétude (champs NOT NULL), unicité (clés primaires), format (regex), fraîcheur (timestamp) et cohérence (foreign keys, règles métier). Documentez chaque règle avec son seuil d'acceptabilité et sa criticité (critique/majeur/mineur).
Implémentation et tests (semaines 2-3)
Codez les règles dans l'outil choisi (dbt tests, Great Expectations ou Soda). Exécutez-les une première fois pour mesurer l'état initial de la qualité. Ne soyez pas surpris : la première exécution révèle souvent 5 à 15 % d'anomalies sur les tables critiques. Corrigez les problèmes les plus graves. Ajustez les seuils pour éviter les faux positifs (ex : passer de 100 % de complétude à 98 % si certaines valeurs nulles sont légitimes).
Automatisation et rituel de suivi (semaine 4)
Planifiez l'exécution automatique des règles (quotidienne ou à chaque chargement de données). Configurez les alertes Slack/e-mail par niveau de criticité. Créez un dashboard de qualité avec les métriques clés : taux de conformité par table, tendance sur 30 jours, nombre d'incidents ouverts. Instaurez un rituel hebdomadaire de 15 minutes avec le Data Steward pour revoir les alertes et prioriser les corrections.
Résultats
Voici les résultats constatés chez nos clients après 3 mois de plan de contrôle qualité opérationnel.
Questions fréquentes
Qu'est-ce qu'un plan de contrôle qualité des données ?
C'est un document (ou un ensemble de tests automatisés) qui définit pour chaque table ou jeu de données les règles de qualité à respecter : complétude (pas de valeurs nulles sur les champs obligatoires), unicité (pas de doublons sur les clés primaires), conformité de format (e-mails valides, codes postaux à 5 chiffres), fraîcheur (données mises à jour dans les 24h) et cohérence inter-tables (chaque commande a un client existant). Chaque règle a un seuil d'acceptabilité et une action en cas de dépassement.
Combien de règles de qualité faut-il définir par table ?
Commencez par 3 à 5 règles par table critique, en couvrant les dimensions essentielles : une règle de complétude, une d'unicité, une de format et une de fraîcheur. Ajoutez des règles métier spécifiques si nécessaire (ex : « le montant d'une commande doit être positif »). Au total, visez 30 à 50 règles pour couvrir vos 10 tables les plus importantes. Ne dépassez pas 100 règles au démarrage — le risque est de générer trop d'alertes et de perdre la capacité de réaction.
Comment prioriser les règles de qualité ?
Priorisez par impact métier. Une donnée erronée qui affecte la facturation (impact financier direct) est plus critique qu'une donnée manquante dans un champ de commentaire. Classez vos règles en 3 niveaux : critique (blocage du pipeline si violation), majeur (alerte immédiate) et mineur (rapport hebdomadaire). Commencez par les règles critiques et ajoutez les autres progressivement.
Quels outils utiliser pour automatiser les contrôles qualité ?
Les trois outils les plus utilisés : Great Expectations (Python, open source, très flexible), dbt tests (intégré au pipeline SQL, idéal si vous utilisez déjà dbt) et Soda (langage déclaratif SodaCL, interface no-code disponible). Pour les équipes non techniques, Soda Cloud ou Atlan offrent une interface graphique pour définir et monitorer les règles sans coder. Tous s'intègrent avec Slack, Teams et PagerDuty pour les alertes.
Pour les profils tech
Exemples de règles par outil
Règles intégrées au pipeline SQL
Tests natifs : unique, not_null, accepted_values, relationships (foreign key). Tests custom en SQL : SELECT COUNT(*) FROM orders WHERE amount < 0 doit retourner 0. Package dbt-expectations pour les règles avancées : expect_column_values_to_match_regex, expect_table_row_count_to_be_between. Exécution à chaque dbt build, résultats dans le terminal et dans Elementary.
Framework Python de validation
Bibliothèque de 300+ expectations prédéfinies : expect_column_values_to_not_be_null, expect_column_values_to_be_unique, expect_column_values_to_match_regex. Génération automatique de rapports HTML (Data Docs). Profiling automatique qui suggère des expectations basées sur vos données. S'intègre avec Airflow, Prefect et Dagster.
20 règles essentielles
Comparatif des outils de contrôle qualité
| Critère | dbt tests + Elementary | Great Expectations | Soda Cloud |
|---|---|---|---|
| Coût | Gratuit (open source) | Gratuit (open source) | 500-2 000 €/mois |
| Langage | SQL + YAML | Python | SodaCL (déclaratif) |
| Interface no-code | Via Elementary Cloud | Non | Oui (native) |
| Intégration pipeline | Native (dbt build) | Airflow, Prefect, Dagster | CI/CD, Airflow, dbt |