Qualité des données au Maroc : fiabiliser la BI et l’IA

La qualité des données au Maroc devient un sujet métier dès qu’un tableau de bord, une automatisation ou un modèle d’IA influence une décision. Une donnée peut être techniquement disponible tout en étant trop ancienne, incomplète, dupliquée ou incohérente avec une autre source. Le problème n’est donc pas seulement de stocker davantage : il faut définir ce qui rend chaque donnée utilisable.

Une démarche de Data & Analytics solide associe règles métier, tests automatiques, surveillance, responsables identifiés et procédure de correction. Elle évite que les utilisateurs découvrent les anomalies au moment de présenter un indicateur ou d’exécuter une opération.

Que recouvre la qualité des données ?

La qualité ne se résume pas à l’absence de cellules vides. Elle se mesure par rapport à un usage précis. Une adresse peut être complète pour livrer un document, mais insuffisante pour analyser une zone commerciale. Les dimensions suivantes constituent un point de départ :

• validité : le format et la valeur respectent les règles attendues ;
• complétude : les champs nécessaires à l’usage sont présents ;
• unicité : une entité métier n’est pas dupliquée sans raison ;
• cohérence : les valeurs compatibles racontent la même réalité ;
• fraîcheur : la donnée arrive dans le délai utile ;
• intégrité référentielle : les relations entre clients, commandes ou produits restent valides.

La qualité des données au Maroc doit être définie avec les équipes qui utilisent l’information, pas uniquement par l’équipe technique. Le responsable commercial sait quand un statut d’opportunité devient incohérent ; la finance connaît les règles d’une facture ; les opérations savent quel retard rend un indicateur inutilisable.

Partir des décisions critiques

Il est rarement utile de tester toutes les colonnes avec la même intensité. Commencez par les décisions et processus les plus sensibles : chiffre d’affaires, encaissements, stocks, dossiers clients, droits d’accès ou données qui alimentent un système d’IA. Identifiez ensuite les tables, champs et transformations dont ces usages dépendent.

Cette cartographie complète la gouvernance des données : la gouvernance précise les responsabilités et les politiques ; la qualité vérifie concrètement que les données respectent le niveau attendu.

Créer un contrat de données lisible

Pour chaque jeu critique, documentez son propriétaire, sa source, sa fréquence, son schéma, les règles métier, les seuils d’alerte et les consommateurs connus. Ce contrat ne doit pas rester dans une présentation. Il doit être versionné près du pipeline et compréhensible par les producteurs comme par les utilisateurs.

Une règle utile est observable et actionnable. « Le champ client doit être correct » est trop vague. « Chaque commande doit référencer un client existant » peut être testée, associée à une gravité et attribuée à une équipe.

Tester à plusieurs endroits du pipeline

Un seul contrôle en fin de chaîne arrive souvent trop tard. Les tests doivent couvrir l’entrée, les transformations et les données publiées :

• à l’ingestion, vérifier schéma, types, champs obligatoires et doublons ;
• pendant les transformations, tester relations, calculs et règles métier ;
• avant publication, contrôler fraîcheur, volumes, agrégats et cohérence des indicateurs ;
• après publication, surveiller les tendances et les changements inattendus.

La documentation officielle de dbt sur les data tests décrit des assertions réutilisables comme l’unicité, l’absence de valeurs nulles, les valeurs acceptées et l’intégrité des relations. Elle permet aussi de créer des tests SQL spécifiques aux règles de l’organisation.

Great Expectations formalise la même idée sous forme d’Expectations : une hypothèse vérifiable sur la forme, le contenu ou le comportement d’un jeu de données. L’outil importe moins que la précision de la règle et la capacité à traiter son échec.

Définir gravité, seuil et réaction

Toutes les anomalies ne doivent pas bloquer un pipeline. Une clé primaire dupliquée dans une table de paiements peut justifier un arrêt. Une légère baisse de complétude sur un champ secondaire peut produire un avertissement et ouvrir une investigation.

Pour chaque règle, définissez donc :

• un seuil ou une condition claire ;
• une gravité : information, avertissement ou blocage ;
• le propriétaire de la réponse ;
• le délai attendu ;
• la procédure de correction et de reprise.

La quarantaine est souvent préférable à la suppression. Les enregistrements douteux sont isolés avec le motif du rejet, tandis que le reste du flux continue si le risque métier le permet. Une correction peut ensuite être réinjectée sans perdre la trace d’origine.

Surveiller la qualité comme un produit

Les tests exécutés lors d’un déploiement ne suffisent pas pour des sources qui changent chaque jour. Il faut suivre dans le temps la fraîcheur, le volume, le taux de valeurs manquantes, les doublons, les distributions et les résultats des règles critiques.

Une alerte doit indiquer le jeu concerné, la règle échouée, l’ampleur, le premier moment observé, les usages dépendants et le responsable. Évitez les notifications sans contexte : elles créent du bruit et finissent par être ignorées.

La spécification Data Quality Metrics d’OpenLineage montre comment rattacher des métriques de qualité à un jeu de données dans la traçabilité. Cette liaison aide à comprendre quels tableaux de bord, modèles ou processus sont affectés par une anomalie.

Organiser la correction et l’analyse de cause

La qualité des données au Maroc progresse lorsque les défauts sont corrigés à la source. Modifier silencieusement une valeur dans le data warehouse peut réparer un rapport, mais l’erreur réapparaîtra si le CRM, l’ERP ou le formulaire continue à produire la mauvaise donnée.

Une procédure simple distingue :

• la détection et la qualification de l’anomalie ;
• la protection des usages dépendants ;
• la correction à la source ou dans la règle de transformation ;
• la reprise contrôlée des données ;
• la vérification que le défaut ne se reproduit pas.

Un pipeline de données fiable conserve les identifiants de lot, les horodatages et la lignée nécessaires pour remonter du rapport vers la source. Une intégration API doit également exposer des erreurs explicites plutôt que transformer silencieusement une valeur invalide.

Fiabiliser la Business Intelligence

Pour la BI, les règles les plus utiles portent souvent sur la définition des indicateurs, les périodes, les jointures et la réconciliation avec les systèmes de référence. Deux tableaux de bord peuvent afficher des chiffres différents tout en étant techniquement corrects s’ils n’emploient pas la même définition du client actif ou du revenu reconnu.

Un modèle sémantique partagé, des définitions versionnées et des contrôles de réconciliation renforcent la confiance dans les tableaux de bord. Chaque indicateur important doit avoir un propriétaire et une source clairement indiquée.

Protéger les usages IA

Un modèle d’IA apprend et répond à partir des données qui lui sont fournies. Des doublons, des étiquettes incohérentes, une dérive de distribution ou des documents non autorisés peuvent dégrader ses résultats. La qualité doit donc couvrir les données d’entraînement, d’évaluation et d’exploitation sans les confondre.

Pour un assistant documentaire, contrôlez notamment la version des documents, les droits d’accès, les métadonnées, les fragments vides et les sources devenues obsolètes. L’article sur le RAG au Maroc détaille les contrôles propres à la recherche et aux citations.

Il ne faut pas remplacer l’évaluation du modèle par des tests de données. Les deux sont complémentaires : les tests vérifient que l’entrée respecte le contrat ; l’évaluation mesure la qualité du comportement attendu.

Confidentialité et minimisation

Une plateforme de qualité ne doit pas copier des données personnelles dans chaque rapport d’échec. Stockez seulement les éléments nécessaires au diagnostic, limitez les accès et appliquez les durées de conservation prévues. Les échantillons utilisés en développement doivent être masqués ou synthétiques lorsque le contexte l’exige.

Le catalogue doit préciser la sensibilité de chaque jeu et ses consommateurs autorisés. Cette discipline relie qualité, sécurité et gouvernance au lieu d’en faire trois projets séparés.

Plan de mise en œuvre

1. sélectionner un indicateur ou processus critique ;
2. cartographier ses sources et transformations ;
3. nommer un propriétaire métier et un responsable technique ;
4. définir cinq à dix règles actionnables ;
5. automatiser les tests aux bons points du pipeline ;
6. configurer gravité, alertes, quarantaine et reprise ;
7. suivre les causes récurrentes et corriger à la source.

La qualité des données au Maroc n’est pas un nettoyage ponctuel. C’est une capacité opérationnelle qui rend les décisions, les automatisations et l’IA plus fiables. Pour cadrer un premier périmètre mesurable, contactez Kanteek.