i

Description

Un microscope posé sur une paillasse de laboratoire

Source

Tomiwa94 · page d’origine

Licence

CC0 Domaine public

Photo d’origine, non retouchée. L’arrière-plan en est une version stylisée par le site.

Méthodes spécifiques aux projets data

Les méthodes générales (prédictives, agiles et lean) ne disent presque rien de ce qui rend un projet data singulier : la donnée est un matériau instable, son état n'est connu qu'en…

En bref

• Les méthodes générales (prédictives, agiles et lean) ne disent presque rien de ce qui rend un projet data singulier : la donnée est un matériau instable, son état n'est connu qu'en l'ouvrant, et la « vérité » du résultat se négocie avec le métier.
• Vous saurez situer et comparer CRISP-DM, ASUM-DM, TDSP, le cycle de vie Kimball, DataOps, data products / Data Mesh, MLOps/AIOps, DAMA-DMBOK, puis les cinq familles de projets (analytique/machine learning, BI/datamart, migration, gouvernance, qualité).
• Vous saurez choisir : quelle méthode pour un projet BI/datamart, laquelle pour un projet de machine learning, laquelle pour un chantier de qualité.
• Chaque méthode est notée /5 selon les critères du dossier (voir NOTATION) ; les notes sont des appréciations d'expert, contextuelles.
• Les méthodes se combinent : le cas général est « Kimball pour modéliser + Scrum/Kanban pour piloter + DataOps pour industrialiser ».

Sur cette page

1. 1. Pourquoi une méthode spécifique à la data
   1. 🟢 Novice — ce qui change quand le matériau est la donnée
   2. 🟡 Pratique — les cinq familles de projets data
   3. 🔴 Expert — le « cône d'incertitude » déplacé
2. 2. CRISP-DM
   1. 🟢 Novice — le modèle
   2. 🟡 Pratique — comment l'utiliser aujourd'hui
   3. 🔴 Expert — limites et extensions
3. 3. ASUM-DM
   1. 🟢 Novice — une extension d'IBM
   2. 🟡 Pratique — quand la citer
   3. 🔴 Expert — lecture critique
4. 4. TDSP (Team Data Science Process)
   1. 🟢 Novice — la méthode de Microsoft
   2. 🟡 Pratique — ce qu'on peut en reprendre sans l'adopter
   3. 🔴 Expert — limites
5. 5. Le cycle de vie Kimball
   1. 🟢 Novice — la référence de l'entrepôt de données
   2. 🟡 Pratique — les idées qui valent encore
   3. 🔴 Expert — Kimball face aux pratiques modernes
6. 6. DataOps
   1. 🟢 Novice — appliquer l'esprit DevOps aux données
   2. 🟡 Pratique — deux pipelines, deux boucles
   3. 🔴 Expert — mesurer DataOps
7. 7. Data products et Data Mesh
   1. 🟢 Novice — penser « produit »
   2. 🟡 Pratique — ce que ça change pour la conduite de projet
   3. 🔴 Expert — Data Mesh : quand, quand pas
8. 8. MLOps et AIOps en bref
   1. 🟢 Novice — deux sigles, deux sens
   2. 🟡 Pratique — ce qui change dans la conduite de projet
   3. 🔴 Expert — pièges propres
9. 9. DAMA-DMBOK
   1. 🟢 Novice — le référentiel de la gestion des données
   2. 🟡 Pratique — comment s'en servir sans s'y noyer
   3. 🔴 Expert — usage critique
10. 10. La gouvernance des données conduite comme un projet
    1. 🟢 Novice — ce que c'est, ce que ce n'est pas
    2. 🟡 Pratique — la démarrer comme un projet à valeur
    3. 🔴 Expert — pourquoi ça échoue, comment on le sait
11. 11. Le projet de migration de données
    1. 🟢 Novice — pourquoi c'est un projet à part
    2. 🟡 Pratique — phases et contrôles
    3. 🔴 Expert — réconciliation et idempotence
12. 12. Le projet BI / datamart
    1. 🟢 Novice — la forme la plus courante
    2. 🟡 Pratique — une méthode composite recommandée
    3. 🔴 Expert — arbitrages structurants
13. 13. Les projets de qualité des données
    1. 🟢 Novice — corriger la cause, pas seulement le symptôme
    2. 🟡 Pratique — la boucle de qualité
    3. 🔴 Expert — arbitrages
14. 14. Tableau comparatif et notes
15. 15. Pièges et bonnes pratiques
16. 16. Contribution de l'IA
17. 17. Voir aussi

Niveau : 🟢→🔴

1. Pourquoi une méthode spécifique à la data#

🟢 Novice — ce qui change quand le matériau est la donnée#

Dans un projet logiciel classique, on construit une fonction ; on sait à peu près quand elle sera finie. Dans un projet data, on construit un résultat qui dépend d'un matériau qu'on ne contrôle pas : les données sources. Trois différences structurent tout ce dossier.

1. Le matériau est inconnu au départ. Tant qu'on n'a pas profilé les sources (taux de NULL, doublons, domaines de valeurs, cohérence entre systèmes), on ne sait pas si la demande est faisable. L'incertitude est structurelle et se concentre en début de projet.
2. Le résultat est un chiffre, pas une fonctionnalité. Une fonctionnalité est correcte ou non au regard d'une spécification. Un chiffre (« 1 284 visites sur la semaine 38 ») est correct si le métier le reconnaît — ce qui suppose une réconciliation avec une référence parfois elle-même contestable. La recette est donc une négociation de définitions, pas seulement une vérification.
3. Le produit vit après la livraison. Les sources dérivent, les volumes croissent, les définitions métier évoluent. Une livraison « terminée » qui n'est pas exploitée et surveillée se dégrade en quelques mois.

🟡 Pratique — les cinq familles de projets data#

🔴 Expert — le « cône d'incertitude » déplacé#

Les méthodes prédictives supposent une incertitude qui décroît avec l'analyse. En data, une grande part de l'incertitude ne se réduit que par le contact avec la donnée réelle, souvent après la phase « d'analyse » officielle. Conséquences : (a) un spike de profilage (1 à 5 jours) doit précéder tout engagement de date ; (b) l'estimation se fait en fourchettes et se révise après profilage ; (c) les revues de sprint sur un projet data doivent montrer des chiffres réconciliés, pas des maquettes. Ce point est développé dans Scrum et data et mesuré par la matrice 03 Conduite de projet data.

2. CRISP-DM#

🟢 Novice — le modèle#

CRISP-DM (CRoss-Industry Standard Process for Data Mining) est un modèle de processus publié en version 1.0 en 1999-2000 par un consortium industriel (dont SPSS, NCR, Daimler-Chrysler, OHRA). Pendant des années, c'est resté le modèle de processus le plus cité dans les enquêtes de praticiens du data mining ; il n'a jamais eu de successeur officiel unique.

Il comporte six phases, itératives et non strictement séquentielles :

🟡 Pratique — comment l'utiliser aujourd'hui#

CRISP-DM est un cadre de pensée, pas un cadre de management : il ne dit ni qui, ni combien, ni quand. Son intérêt est d'imposer de commencer par le métier et de boucler (les flèches de retour sont le cœur du modèle : on revient souvent de « données » à « métier » parce que l'objectif n'était pas réaliste).

Usage efficace : en faire la trame de chaque cycle d'un backlog agile — chaque épique analytique traverse les six phases, mais en tranches courtes. Un sprint peut couvrir « 2→3 » (profilage + préparation) sur un périmètre restreint.

🔴 Expert — limites et extensions#

• Absence de cycle de vie après déploiement : la surveillance, le réentraînement, la dérive (drift) sont à peine évoqués → d'où MLOps (section 8).
• Absence du travail d'équipe : pas de rôles, pas d'outillage, pas de gestion de version des données et des modèles → d'où TDSP et ASUM-DM.
• Poids de la documentation de la version 1.0 : utile en audit, lourd en itération courte. Adapter : ne produire que les livrables qui servent une décision.
• Pertinence hors ML : la phase 2-3 (compréhension et préparation) est universelle et se retrouve dans tout chantier BI ou migration ; le reste est spécifique à la modélisation prédictive.

Notes (contexte : équipe de 4 à 8 personnes, projet analytique ou ML) :

3. ASUM-DM#

🟢 Novice — une extension d'IBM#

ASUM-DM (Analytics Solutions Unified Method for Data Mining/Predictive Analytics) est une méthode publiée par IBM (2015) qui étend CRISP-DM. Elle conserve les phases analytiques de CRISP-DM et leur ajoute une couche de gestion de projet et d'exploitation. Elle est moins répandue que CRISP-DM et plutôt associée à l'écosystème IBM ; à vérifier pour son statut de maintenance actuel, car sa documentation publique est devenue difficile à localiser.

Ce qu'elle apporte, en esprit :

• des phases supplémentaires en amont et en aval : conception, mise en œuvre, exploitation (operations), au-delà du simple déploiement ;
• une dimension projet : gouvernance, gestion des risques, rôles ;
• l'idée que les phases analytiques (comprendre, préparer, modéliser, évaluer) sont réalisées de façon agile et itérative, tandis que la couche projet reste pilotée de manière plus classique.

🟡 Pratique — quand la citer#

Dans un dossier de réponse ou de cadrage pour un client grand compte, ASUM-DM rassure : elle montre que le cycle ne s'arrête pas au déploiement. En pratique, une équipe qui combine CRISP-DM et un backlog agile avec des phases d'exploitation explicites obtient le même résultat sans adopter formellement ASUM-DM.

🔴 Expert — lecture critique#

Le vrai intérêt est conceptuel : séparer la boucle analytique (courte, itérative) de la boucle projet (longue, pilotée par jalons). C'est la même séparation qu'un hybride « agile dans le prédictif » (voir choisir et hybrider). Si votre contexte n'est pas IBM, retenez la séparation, pas le nom.

4. TDSP (Team Data Science Process)#

🟢 Novice — la méthode de Microsoft#

Le Team Data Science Process est une méthodologie publiée par Microsoft pour des équipes de science des données. Elle propose un cycle de vie proche de CRISP-DM, une structure de dépôt standardisée, des rôles, et un lien avec l'outillage Azure (Azure DevOps pour le suivi des tâches et du code). Son cycle de vie comporte cinq étapes : compréhension métier, acquisition et compréhension des données, modélisation, déploiement, acceptation par le client.

Sa singularité n'est pas le cycle, mais l'industrialisation de l'équipe : un modèle de projet (structure de dossiers, gabarits de rapports), un backlog lié au dépôt, des conventions de nommage. L'état de maintenance de la documentation TDSP est à vérifier : la page de référence existe sur Microsoft Learn mais l'accent de Microsoft s'est déplacé vers MLOps et les approches Fabric/Azure Machine Learning (état 2026-10, non revérifié en détail).

🟡 Pratique — ce qu'on peut en reprendre sans l'adopter#

• Une arborescence standard de projet : data/ (brut, nettoyé), code/, models/, reports/, docs/. Elle évite que chaque projet réinvente son rangement.
• Un rapport de qualité des données standardisé à l'étape 2 (profilage reproductible, pas un copier-coller de captures).
• Une définition de « terminé » incluant l'acceptation par le client : le modèle n'est livré que lorsque le client l'a accepté sur critères écrits.

🔴 Expert — limites#

TDSP suppose une équipe de data science avec des notebooks, des expérimentations, une infrastructure de calcul : un cadre plus lourd que nécessaire pour une équipe de 2 développeurs BI. Le cycle d'acceptation est précieux mais ne traite pas la dérive après livraison — il faut lui adjoindre MLOps.

5. Le cycle de vie Kimball#

🟢 Novice — la référence de l'entrepôt de données#

Ralph Kimball et ses coauteurs ont décrit dans The Data Warehouse Lifecycle Toolkit (« le Kimball Toolkit », 2e éd. 2008) un cycle de vie de projet d'entrepôt dimensionnel. C'est la méthode historique de la BI : elle est centrée sur le métier, la modélisation dimensionnelle (faits et dimensions) et la livraison incrémentale par processus métier.

Trois voies parallèles (technologie, données, applications BI) convergent vers le déploiement ; l'ensemble est cadré par la planification et la collecte des besoins, et suivi d'un cycle de croissance.

🟡 Pratique — les idées qui valent encore#

🔴 Expert — Kimball face aux pratiques modernes#

• Agile et Kimball sont compatibles : un lot Kimball se découpe en histoires (une dimension, un fait, un rapport). Le risque agile classique est de ne livrer que des rapports sans la dimension conforme — la dette de modèle s'accumule. Gardez la matrice de bus comme carte de route.
• ELT / lakehouse : l'argument technique de Kimball (modèle optimisé pour un moteur relationnel) reste valable pour la couche de présentation ; la modélisation dimensionnelle se retrouve dans le modèle sémantique Power BI. Ce qui change : le stockage (parquet, Delta) et le moment de la transformation.
• Data Vault et Inmon : approches concurrentes ou complémentaires (Inmon : entrepôt normalisé d'abord ; Data Vault : modélisation d'auditabilité et de flexibilité des sources). Un schéma fréquent : Data Vault ou zone normalisée en intégration, étoile Kimball en présentation.
• Historisation : dimensions à évolution lente (SCD type 1, 2…), à décider par attribut avec le métier — pas par défaut. Voir thème modélisation de la matrice data.

6. DataOps#

🟢 Novice — appliquer l'esprit DevOps aux données#

DataOps désigne un ensemble de pratiques qui appliquent à la chaîne de production de données les idées d'Agile, de DevOps et du contrôle statistique de processus (Lean manufacturing). L'objectif est de raccourcir le délai entre une demande de donnée et sa mise à disposition fiable, tout en réduisant les erreurs en production. Le terme est popularisé vers 2014-2015 ; un Manifeste DataOps est publié ensuite, avec 18 principes.

Le manifeste (à lire sur dataopsmanifesto.org) énonce des valeurs et des principes. Les plus structurants, reformulés avec mes mots :

Le fait de versionner les données ou leurs échantillons et de créer des environnements jetables distingue DataOps de DevOps classique : la donnée, contrairement au code, a un volume, une sensibilité et un état.

🟡 Pratique — deux pipelines, deux boucles#

Un cadre mental fécond : une chaîne de données comporte deux pipelines qui s'entrecroisent.

• Le pipeline de valeur (production) : sources → transformations → modèle → rapports, exécuté tous les jours. Il doit être robuste, supervisé, rejouable.
• Le pipeline d'innovation (développement) : idée → développement → test → déploiement. Il doit être court et automatisé.

Les deux boucles de contrôle : qualité en production (tests de données à chaque exécution, alertes) et qualité en développement (tests automatisés à chaque modification, intégration continue). Le détail technique est dans CI/CD pour la data.

🔴 Expert — mesurer DataOps#

Indicateurs pertinents (à adapter) : délai de mise en production d'une évolution ; fréquence des déploiements ; taux d'incidents données par mois ; temps de détection puis de correction ; part du temps consacrée au travail non planifié (reprises, corrections). Ils prolongent les métriques DORA (voir CI/CD) avec des mesures propres à la donnée, que développe le thème 06 de la matrice data.

7. Data products et Data Mesh#

🟢 Novice — penser « produit »#

Un produit de données (data product) est un jeu de données — ou un service qui en fournit — conçu, maintenu et offert comme un produit à des consommateurs : avec un propriétaire, une documentation, un niveau de service, une qualité mesurée. L'idée centrale est de passer de « un projet qui livre des tables » à « une équipe responsable d'un produit dans la durée ».

Data Mesh est un paradigme décrit par Zhamak Dehghani (articles 2019-2020, livre Data Mesh en 2022) qui propose, face aux limites d'un entrepôt central, quatre principes :

1. Propriété par domaine : les équipes métier qui produisent la donnée en sont responsables ;
2. Données comme produit : chaque domaine publie des produits fiables et découvrables ;
3. Plateforme en libre-service : une équipe plateforme fournit l'outillage commun ;
4. Gouvernance fédérée et calculée : des règles globales, appliquées automatiquement, décidées collectivement.

🟡 Pratique — ce que ça change pour la conduite de projet#

Le contrat de données (schéma, sémantique, fraîcheur, qualité attendue, règles d'évolution) est l'objet qui formalise la relation producteur-consommateur. Il se traite comme une interface d'API : toute rupture de contrat est un changement de version majeur annoncé.

🔴 Expert — Data Mesh : quand, quand pas#

Data Mesh résout un problème d'échelle organisationnelle (des dizaines de domaines, un goulot central). Il échoue quand l'organisation n'a pas les compétences data dans les domaines, pas de plateforme, ou pas d'appétit pour la gouvernance fédérée. Pour une équipe BI unique de quelques personnes, adopter le vocabulaire « produit » (propriétaire, contrat, SLO) a du sens ; adopter l'architecture Data Mesh n'en a pas. Les notes ci-dessous valent pour une organisation moyenne (200 à 2 000 personnes).

8. MLOps et AIOps en bref#

🟢 Novice — deux sigles, deux sens#

• MLOps : pratiques pour industrialiser un modèle de machine learning : versionner données, code et modèle ; automatiser entraînement, validation, déploiement ; surveiller la performance et la dérive ; réentraîner. C'est le « DevOps du modèle ».
• AIOps : terme ambigu. Dans son sens d'origine (Gartner), l'utilisation d'IA/ML pour opérer l'informatique (corrélation d'alertes, détection d'anomalies, automatisation d'incidents). Ne pas le confondre avec « opérer des systèmes d'IA » (qui relève de MLOps, et, pour l'IA générative, d'appellations comme LLMOps).

🟡 Pratique — ce qui change dans la conduite de projet#

Un modèle n'est pas « fini » : son comportement dépend des données du moment. D'où :

• un budget de run explicite (surveillance, réentraînement) dès le cadrage ;
• une recette en deux temps : performance hors-ligne, puis performance en production (mode « ombre » ou pilote) ;
• un registre de modèles (version, données d'entraînement, métriques, responsable) ;
• des seuils d'alerte de dérive (population, distribution des variables, performance mesurée quand le résultat réel est connu).

🔴 Expert — pièges propres#

Pour un développeur BI, le point d'entrée raisonnable est modeste : un score produit par un job planifié, stocké dans une table, consommé dans un rapport, avec sa version et sa date d'entraînement exposées. C'est déjà du MLOps minimal. Voir aussi l'IA et les outils.

9. DAMA-DMBOK#

🟢 Novice — le référentiel de la gestion des données#

Le DMBOK (Data Management Body of Knowledge), publié par DAMA International, est le référentiel de la discipline de gestion des données. Sa 2e édition (DMBOK2, 2017) structure le domaine en onze domaines de connaissance, souvent représentés en « roue » avec la gouvernance des données au centre :

1. Gouvernance des données
2. Architecture des données
3. Modélisation et conception des données
4. Stockage et opérations sur les données
5. Sécurité des données
6. Intégration et interopérabilité des données
7. Gestion des documents et contenus
8. Données de référence et données maîtres
9. Entrepôts de données et business intelligence
10. Gestion des métadonnées
11. Qualité des données

Ce n'est pas une méthode de projet : c'est un vocabulaire et une cartographie (qui fait quoi, quelles activités, quels livrables, quels rôles). Il sert de grille d'audit et de langage commun, notamment avec la direction.

🟡 Pratique — comment s'en servir sans s'y noyer#

• Évaluer l'organisation sur chaque domaine (grille de maturité) pour décider où investir, non pour tout couvrir.
• Nommer des rôles (propriétaire de donnée, responsable de données, gestionnaire de données/data steward, architecte) : l'apport le plus concret.
• Aligner le vocabulaire : « donnée de référence », « donnée maître », « métadonnée » ne se confondent pas.

🔴 Expert — usage critique#

Le DMBOK est descriptif, pas prescriptif : il ne dit pas dans quel ordre, ni avec quel budget. Il est utile à un responsable data ou architecte, peu opérationnel pour une équipe de développement. Les matrices de maturité du dossier (projet data, BI) opérationnalisent une partie de ces domaines sous forme de jalons vérifiables. Détail sur gouvernance et organisation.

10. La gouvernance des données conduite comme un projet#

🟢 Novice — ce que c'est, ce que ce n'est pas#

La gouvernance des données est l'exercice de l'autorité et du contrôle (planification, suivi, application) sur la gestion des actifs de données. En clair : qui décide, de quoi, avec quelles règles, et qui en répond. Ce n'est pas un outil (le catalogue n'est qu'un support) ni un comité de plus.

🟡 Pratique — la démarrer comme un projet à valeur#

Un programme de gouvernance échoue quand il est « top-down, exhaustif, sans bénéfice visible ». Il réussit quand il part d'un irritant concret.

🔴 Expert — pourquoi ça échoue, comment on le sait#

• Pas de sponsor capable d'arbitrer entre deux directions : la gouvernance n'est qu'un arbitrage institutionnalisé.
• Rôles sans temps : « data steward » ajouté à une fiche de poste sans décharge est un rôle fictif. Indicateur : combien d'heures par semaine, nommées dans un planning ?
• Documentation sans contrôle : un glossaire que rien ne vérifie vieillit en six mois. Lier chaque définition à un test automatisé ou à une revue datée.
• Conformité subie : RGPD, secteurs régulés — obligation légitime, mais à traiter comme contrainte de conception, pas comme afterthought (voir le thème sécurité, confidentialité, conformité).

Notes de la gouvernance comme approche (contexte : organisation de 500+ personnes, sponsor identifié) : prévisibilité 2/5, adaptation 3/5, maîtrise du risque 4/5, légèreté 2/5, adoption 2/5, visibilité 5/5, qualité des livrables 4/5. Le principal déterminant est la présence ou non d'un sponsor : sans lui, tout descend d'un point.

11. Le projet de migration de données#

🟢 Novice — pourquoi c'est un projet à part#

Migrer, c'est déplacer des données d'un système à un autre en préservant le sens. Deux erreurs sont fréquentes : croire que c'est un simple « copier-coller technique » et le sous-estimer ; sous-estimer le nettoyage et la validation métier. La date de bascule est souvent ferme (fin de contrat, arrêt de l'ancien système) : le projet est plus prédictif qu'exploratoire.

🟡 Pratique — phases et contrôles#

Les répétitions à blanc sont le levier de risque n° 1 : elles transforment l'inconnu (« combien de temps ? ») en mesuré et révèlent les cas limites (caractères spéciaux, dates hors plage, clés orphelines).

🔴 Expert — réconciliation et idempotence#

Une réconciliation robuste combine trois niveaux : comptage (nombre de lignes par table, par partition), agrégats (sommes de colonnes numériques, min/max de dates), empreintes (somme de contrôle des lignes ou d'un sous-ensemble). Exemple T-SQL de somme de contrôle comparable sur deux bases :

SELECT COUNT(*)                         AS nb_lignes,
       SUM(CAST(montant AS decimal(19,4))) AS somme_montant,
       CHECKSUM_AGG(BINARY_CHECKSUM(*)) AS empreinte
FROM   dbo.Commande
WHERE  date_commande >= '2026-01-01';

(CHECKSUM_AGG/BINARY_CHECKSUM ont des collisions possibles : bien pour détecter un écart, insuffisant pour prouver l'égalité ; prévoir un contrôle complémentaire ciblé.)

Le migrateur doit être idempotent : le rejouer sur la même entrée donne le même résultat sans doublon. Technique : clé naturelle + MERGE ou INSERT … WHERE NOT EXISTS, journal des lots traités. Voir CI/CD pour la data.

12. Le projet BI / datamart#

🟢 Novice — la forme la plus courante#

Un projet BI construit un datamart (modèle dimensionnel pour un domaine métier) et des rapports qui le consomment. Il enchaîne : besoins → modèle → chargement → rapports → recette → exploitation. C'est un projet à moitié ingénierie logicielle, à moitié enquête sur la donnée.

🟡 Pratique — une méthode composite recommandée#

Séquence type d'un lot (3 à 8 semaines) :

1. Besoin et indicateurs : liste des décisions à éclairer, des indicateurs, de leurs définitions écrites.
2. Profilage des sources (spike) : faisabilité, qualité, volumétrie.
3. Modèle dimensionnel : grain, faits, dimensions, historisation décidée avec le métier.
4. Chargement : transformations rejouables, tests de données.
5. Modèle sémantique et rapports : mesures, sécurité (RLS), traductions.
6. Recette métier : rapprochement avec une référence.
7. Livraison : kit versionné, notes de version, formation légère.
8. Exploitation : supervision, support, collecte des retours.

🔴 Expert — arbitrages structurants#

• Où mettre la logique : transformation en SQL (réutilisable par tous les outils) plutôt que dans le modèle sémantique (verrouillé dans un outil). Les mesures, elles, vivent dans le modèle. Détail : modèle sémantique et couche données et ETL.
• Livrer vite sans dette de modèle : un lot rapide qui contourne une dimension conforme crée une dette qui se paiera au lot suivant.
• Versions : un rapport consommé par des clients externes ou des filiales impose de ne pas casser les noms de colonnes et mesures — traiter le modèle comme une API (voir versionnement et industrialisation des rapports).
• Reporting Power BI : les architectures cibles sont détaillées dans 04 Reporting Power BI.

13. Les projets de qualité des données#

🟢 Novice — corriger la cause, pas seulement le symptôme#

Un projet de qualité des données vise à mesurer puis améliorer la fiabilité des données. L'erreur courante : nettoyer une fois (un « grand ménage ») puis constater que les défauts reviennent. La qualité est un processus — on remonte à la cause (saisie, interface, règle de gestion, intégration) et on met un contrôle durable.

🟡 Pratique — la boucle de qualité#

Une boucle inspirée du DMAIC (Définir, Mesurer, Analyser, Améliorer, Contrôler) :

Dimensions usuelles (vocabulaire de la littérature qualité de données, à définir localement) : exactitude, complétude, cohérence, unicité, fraîcheur/actualité, validité (conformité au format/domaine), intégrité référentielle.

🔴 Expert — arbitrages#

• Bloquer ou laisser passer : une donnée de mauvaise qualité doit-elle empêcher le chargement ? Règle pratique : bloquer pour les défauts qui rendent les agrégats faux (clé nulle, doublon de fait) ; laisser passer en signalant pour les défauts descriptifs (libellé manquant), avec un membre « inconnu » dans la dimension.
• Quarantaine : écrire les lignes rejetées dans une table d'exceptions exploitable par le métier, pas dans un journal technique.
• Mesure du coût : le calcul de la valeur est approximatif (temps de correction, décisions retardées) ; mieux vaut une estimation honnête et ordonnée qu'un chiffre précis inventé.
• Lien avec la matrice : thème qualité des données pour les niveaux de maturité.

14. Tableau comparatif et notes#

Synthèse (appréciations d'expert, contextuelles : équipe de 3 à 10 personnes, projet data de 3 à 12 mois ; voir NOTATION). Les approches ne sont pas toutes de même nature — certaines sont des processus, d'autres des référentiels ou des philosophies — donc la comparaison est indicative. Comparatif complet avec les méthodes générales : 08 Comparatif des méthodes.

(Notes sur 5, la colonne « Prévis. » = prévisibilité, etc.)

Lecture :

• Kimball et DataOps sont les deux piliers d'un projet BI, et se complètent (modèle + flux) ; on obtient le meilleur du Kimball + Scrum/Kanban + DataOps.
• CRISP-DM est le meilleur point d'entrée pour un projet analytique ; MLOps prend le relais après le déploiement.
• DAMA-DMBOK et Data Mesh relèvent de l'organisation ; ils ne remplacent pas une méthode de projet.
• Aucune méthode ne couvre à la fois la modélisation, le flux, la gouvernance et la recette métier : l'art est d'assembler (choisir et hybrider).

Arbre de décision rapide :

15. Pièges et bonnes pratiques#

Les 40+ pièges et 30+ bonnes pratiques transverses sont regroupés dans 13 Pièges et bonnes pratiques. Ceux qui concernent spécifiquement ce fichier :

16. Contribution de l'IA#

Prompt d'exemple (à exécuter sur un échantillon anonymisé) :

Voici le schéma d'une table SQL Server (colonnes, types, 20 lignes d'exemple anonymisées).
1) Propose 10 contrôles de qualité en T-SQL (unicité, complétude, validité, cohérence de dates).
2) Pour chacun, indique la sévérité (bloquant/avertissement) et la question à poser au métier.
3) N'invente aucune règle métier : signale ce qui est une hypothèse.

Ce que l'IA ne remplace pas : l'arbitrage de définition entre deux directions, la responsabilité d'un chiffre publié, la connaissance du contexte (pourquoi cette règle étrange existe).

17. Voir aussi#

• Fondamentaux et cadres : 01 Fondamentaux · 05 Méthodes prédictives · 06 Agile et Lean · 08 Comparatif · 09 Choisir et hybrider
• Livraison : 10 CI/CD · 11 CI/CD pour la data · 13 Pièges et bonnes pratiques
• Matrices : Conduite de projet data · Développement BI
• Outils : GDS et données SQL/BI · Métriques et reporting de projet
• Transverse : Glossaire · Bibliographie et ressources · Synthèse IA

✻ Rédigé par Claude Sonnet 5.5