Intro
Un système d’information est un ensemble de ressources dédié à la collection, le stockage, le traitement et la diffusion des informations dont une organisation a besoin pour bien fonctionner.
La data est donc au cœur de l’organisation et fait partie des actifs de l’entreprise. C’est avec les données que nous pouvons générer, par exemple, des rapports, des constats et des évaluations et c’est avec ces rapports que nous prenons des décisions pour faire tourner un business.
Dans le contexte de l’architecture d’un système d’information, la couche data est souvent représentée verticalement pour préciser qu’elle est transverse et qu’elle couvre l’ensemble des autres couches du SI (métier, fonctionnelle, applicative, technique). Cela s’explique par le simple fait que les données sont des éléments essentiels qui relient toutes les couches du SI et que chaque couche traite la donnée à son propre niveau.
Dans cet article, je vais te partager une vision concrète de la validation de la donnée avec des exemples tangibles que tu pourras considérer lors de la mise en place de ta stratégie de qualité de données. Tout d’abord, je vais expliquer comment une donnée est exploitée. Ensuite, et en se basant sur les différentes exploitations de la donnée, je vais préciser comment valider la donnée dans chaque contexte d’exploitation. Enfin, je survolerai plusieurs caractères de la donnée à tester pour valider celle-ci.
I- On distingue 3 catégories de données :
- Objets métier
- Connaissances & Knowledge management
- BigData
I-1 Les objets métier
Les objets métier peuvent être à leur tour répartis en 3 :
- Opérationnels :
Ce sont des données ayant une temporalité courte et qui sont spécifiques au métier.
Exemple : commande, achat, facture, etc
- Référentiels (master data) :
Ce sont des données plus stables et partagées entre plusieurs métiers.
Exemple : Produit, client, collaborateur, contrat, nomenclatures, organisation, règles métier.
- Décisionnels :
C’est un mélange entre données opérationnelles et référentiels et c’est ce qui permet de faire les Dashboard, définir les KPIs et prendre les décisions.
I-2 Connaissance & Knowledge management (gestion du savoir)
Elle regroupe le savoir-être et le savoir-faire de l’entreprise, la matrice des compétences, les documentations techniques ou fonctionnelles, les processus opérationnels, les bonnes pratiques.
L’objectif est de capitaliser sur la connaissance de l’entreprise.
I-3 Big Data
Cette catégorie regroupe tout ce qui est de l’ordre des données massives, les dashboards et les rapports, tout ce qui s’exploite par la data science et le data mining. Ces données sont également celles utilisées par l’IA pour développer le machine learning.
II- Par rapport à quoi une donnée est-elle validée ?
Valider une donnée consiste à vérifier si elle est cohérente, fiable et complète en accord avec les besoins métier et l’exploitation de la donnée.
Nous distinguons 3 façons d’exploiter une donnée :
- Exploitation opérationnelle
- ETL / ELT
- Migration/reprise de donnée
II-1 Validation de la donnée de l’exploitation opérationnelle
Cette validation est faite à travers l’exploitation des données de test dans le cadre d’un test fonctionnel classique exécuté manuellement ou automatiquement.
C’est une validation technique de la donnée et pas forcément une validation logique ou métier.
Exemple : Je valide que la date de naissance du client A est bien visible sur son compte au bon endroit, mais je ne valide pas que c’est la bonne date de naissance.
PS : Rien n’empêche d’ajouter des scénarios de tests permettant de valider la donnée d’un point de vue métier si mon test ne le fait pas déjà.
Exemple : Vérifier que la quantité totale de ma commande = quantité produit 1 + produit 2 + etc
Parmi les notions assez importantes dans le contexte de la validation d’une donnée exploitée opérationnellement, c’est la notion CRUD (Create/ Read / Update / Delete). Celle-ci consiste tout simplement à valider la possibilité de Créer, Lire, Mettre à jour et Supprimer une donnée correctement dans son contexte métier.
II- 2 Validation de la donnée dans le cadre d’un ETL/ELT
En guise de rappel, ETL et ELT sont les acronymes de Extract, Transform, Load et Extract, Load, Transform. Ce sont des opérations qui consistent à extraire, transformer le format, le type, la représentation de la donnée et la charger dans la destination voulue. L’ordre entre le chargement et la transformation de la donnée peut varier en fonction de la méthode et du besoin et de la destination.
Valider la donnée dans ce contexte consiste à confirmer que les actions d’extraction, de transformation et de chargement ont été réalisées conformément aux attentes.
Exemples :
- Nouveau data warehouse avec des données de sources différentes
- Une application A qui prend en entrée une donnée de l’application B mais sous un format diffèrent.
II-3 Validation de la donnée dans le cadre d’une reprise ou d’une migration de donnée
Dans ce contexte, la validation consistera à confirmer que les données du système source correspondent exactement à celles du système de destination et sont utilisées de la même manière, voire mieux, conformément aux spécifications métier.
Exemple :
Migration de l’hébergeur GCP à AWS qui implique plusieurs couches :
- Réseau
- Application
- Migrer mes données sur une nouvelle base de données.
III- Qu’est-ce qu’on teste pour valider la donnée ?
Il est important de comprendre les différentes catégories de données et les différentes méthodes à travers lesquelles une donnée est exploitée et par rapport à quoi on valide cette donnée. Mais concrètement comment tester et quoi tester pour valider la donnée ?
Les tests pour valider la donnée doivent nous permettre de vérifier et valider des caractères spécifiques à cette donnée.
Parmi ces caractères nous pouvons mentionner
L’uniformité de la donnée
Tester l’uniformité de la donnée permet de vérifier que la valeur actuelle d’une donnée est égale partout où elle est représentée
- Dans le même schéma :
Exemple : Les productId qui sont dans la table orderDetails doivent être obligatoirement parmi les productId de la table Products.
- Dans des schémas différents
Exemple : Les productId qui sont dans la table Products de la base de données A doivent obligatoirement être égaux aux productId qui sont dans la table Products de la base de données B.
Le MCD (Modèle conceptuel de donnée) / MLD (Modèle logique de donnée)
Tester le MCD/MLD c’est vérifier la présence et cohérence entre les tables, les champs et les clefs primaires et secondaires.
Par exemple : Vérifier que la table ‘Category’ est bien présente avec les champs respectifs :
- categoryId/categoryName/Description/categoryValue
- Avec categoryId en clef primaire.
La précision de la donnée
Tester la précision de la donnée sert à vérifier que les formats et les valeurs de la donnée correspondent aux spécifications techniques et fonctionnelles
Deux méthodes pour tester la précision de la donnée.
- Méthode non numérique :
Vérifier le format de l’email, le code PIN, le code postal, numéro de téléphone, etc.
Exemple : le format de l’email doit être : anything@provider.com
- Méthode d’Analyse de domaine
- Basée sur une liste de valeurs
Créer une liste de valeurs possibles pour mon champ et valider que mes données sont dans cette liste de valeurs.
Exemple : Les valeurs du champ ‘Genre’ doivent être F ou M
- Basée sur un intervalle
Ma valeur doit être entre une valeur Minimale et une valeur Maximale.
Exemple : Les valeurs du champ ‘Age’ doivent être entre 18 et 120
- Basée sur un fichier de référence
Comparer ma donnée à un fichier de référence.
Exemple : Les valeurs du champ CodePays ne sortent pas de la liste des code Pays recensés dans le fichier de référence.
La metadata
Tester la metadata veut dire tester la data de la data. Comme le fait de vérifier que le modèle de données correspond à l’attendu surtout suite à un changement au niveau de l’architecture de données.
Exemples :
- Le type de la donnée
- Exemple : Vente est en décimal
- Longueur de la donnée
- Exemple : champ adresse à 500 charactères
- Indexation de la donnée
- Exemple : la donnée est bien indexée (clientId/orderId)
- MultiEnvironnement
- Exemple : MetaData identique sur tous les environnements (QA, PPROD, PROD)
- Capacité de traitement de la donnée
- Exemple : Architecture du processeur de la bdd est de 32 ou 64 bits
Il faut penser aussi à tester les changements qui ont eu lieu au niveau d’un système source pendant une migration (en mi-chemin) et qui n’avaient pas encore été pris en considération.
Exemple : Nouveau champ (Profession) ajouté à la table ‘Clients’ au niveau de la bdd du système source après avoir créé la table client au niveau du système destination.
Intégrité de la donnée
Tester l’intégrité de la donnée c’est s’assurer que je n’ai pas perdu de la donnée.
Je peux le faire de deux façons différentes :
- Compte d’enregistrement :
Comparer le compte total des enregistrements d’une même table entre un système source et un système cible
Exemple : Automatiser un sanity test exécutable suite au lancement du job ETL ou de migration qui compare les comptes, si les comptes ne sont pas égaux cela doit envoyer une alerte.
- Profilage des données :
Dans le cas de données volumineuses nous pouvons créer des segments logiques de données et les comparer et comparer leurs comptes.
Exemple : Comparer le nombre des valeurs « NULL » d’une colonne importante d’une table importante entre la source et la destination.
Unicité ou duplicata de la donnée
Tester l’unicité ou le duplicata de la donnée consiste à vérifier que, par rapport aux règles de gestion, les données qui sont censées être uniques le sont et celles censées être dupliquées le sont aussi.
Exemple : vérifier que nous n’avons pas un même numéro de téléphone pour 2 clients différents.
La transformation de la donnée
Tester la transformation de valider l’opération ETL ou ELT en validant que la transformation de la donnée se fait conformément aux spécifications
Exemple : Tester la réjection des données invalides par le code ETL, l’intégrité des données transformées, le nouveau format de la donnée après transformation (Date en format JJMMAAAA bien transformée en format MMJJAAAA)
Le caractère obligatoire de la donnée
Tester que par rapport aux règles de gestion, les données obligatoires ont des valeurs non « NULL » ou des valeurs par défaut.
Exemple : Si la DateFacture n’a pas été renseignée elle sera donc égale à la date du jour.
Les données NULL
Valider que la valeur NULL est autorisée pour les données qui sont égale à NULL et que je n’ai pas de champs (obligatoires) avec une valeur égale à NULL.
Rapport de la donnée avec le temp
Vérifier que la donnée respecte les règles de gestions liées aux temps
Exemple :
- DiscountProduit est applicable pendant 15j alors que la règle de gestion précise que le discount n’est valable que pour 7j, cela veut dire que j’ai une erreur au niveau de ma donnée qui peut sembler correcte.
- Une offre à terme qui est censée être activée pendant la saison de Noël mais qui reste toujours activée pendant le mois de Juin, erreur.
Les caractères métiers
Valider les règles métiers à travers la donnée
Exemples :
- DateLivraion < ou = DateCommande
- FromDate < ou = ToDate pour une réservation
Les fonctions d’agrégation de la donnée
Valider que les formule utilisant en entrée des données, sont bien exécutée et envoient en sortie les bonnes données aussi.
Exemples :
- Quantité totale commande = quantité produit 1 + quantité produit 2 + etc
- Pourcentage de quantité emballée = quantité emballée / quantité commandée x 100
Le data mapping
Vérifier que les champs du UI ou des JSON (si ce sont des API) sont toujours bien mappés avec leurs champs respectifs en base de données.
Exemples :
- Toute action effectuée via API ou UI de type CRUD a bien eu sa conséquence sur la base de données et vice versa.
- Création de commande via l’UI ou l’API doit générer une nouvelle ligne avec la nouvelle commande dans la bdd.
Conclusion
Pour conclure, tester l’intégration de la donnée est indispensable pour garantir une qualité de donnée irréprochable. Les caractères que nous avons cité dans cet article ne regroupent pas forcément la totalité des possibilités. Quelques autres techniques notamment de test boîte noire sont mentionnées dans le syllabus de l’ISTQB et qui peuvent servir à valider la donnée. Comme les partitions d’équivalence et les analyse des valeurs limites. Je t’invite à te référer à l’ISTQB et aux articles dédiés pour les approfondir.
Je t’invite aussi à découvrir d’autres notions comme les propriété ACID (Atomicité, Cohérence, isolement et durabilité) et les principes ALCOA (Attribuable, Lisible, Contemporaine, Originale et Accurate/Exacte) qui traitent de la qualité de l’intégration de la donnée.
Et toi ? Comment assures-tu la qualité de tes données ?
Un grand merci à Marc Hage Chahine pour sa revue de l’article.
