Qualité des données : préparer un projet IA
La qualité des données ne se résume pas à un nettoyage. Elle se construit dans les définitions, les responsabilités et la gestion des exceptions.
Publié le · À propos des dates
Mis à jour le
Le point de vue Spark
Attendre des données parfaites peut immobiliser un projet. Accepter des données sans critères explicites peut produire un résultat inutilisable. La bonne exigence se définit à partir de l’usage, des erreurs tolérables et de la façon de traiter les exceptions.
- Choisir un usage et un périmètre avant de lancer un nettoyage général.
- Associer chaque contrôle à une conséquence et à un responsable.
- Prévoir le comportement du service lorsque les données ne conviennent pas.
1. Une donnée fiable pour quel usage ?
Une adresse peut suffire à regrouper des ventes par région sans permettre une livraison. Un montant peut être correctement stocké tout en restant inutilisable si sa devise ou sa période ne sont pas connues. Qualifier la donnée demande donc de préciser la décision ou l’opération qu’elle doit soutenir.
Le cadre britannique de qualité des données retient une logique d’adéquation à l’usage et distingue notamment complétude, unicité, cohérence, actualité, validité et exactitude. Ces dimensions aident à décrire le problème ; elles ne fixent pas un seuil unique valable pour tous les projets. Consulter le Government Data Quality Framework.
Notre recommandation : remplacer « améliorer la qualité de la base » par une question vérifiable. Par exemple : peut-on identifier la version de la documentation applicable au produit pour lequel un utilisateur demande de l’aide ? Cette formulation rapproche directement le travail data du service attendu.
2. Transformer une exigence générale en contrôles utiles
Pour chaque information nécessaire, préciser une règle, le moment du contrôle et la réponse à l’échec. Un contrôle qui alimente un tableau de bord sans déclencher aucune action ne suffit pas à rendre le processus fiable.
| Besoin | Contrôle proposé | Réponse à prévoir |
|---|---|---|
| Identifier le produit | Référence présente et reconnue. | Écarter ou faire qualifier les documents non rattachés. |
| Retrouver la bonne version | Version et statut d’application renseignés. | Demander une validation en cas d’ambiguïté. |
| Éviter les contradictions | Repérer les documents concurrents sur un même périmètre. | Faire arbitrer la source de référence. |
| Maintenir l’information | Responsable de mise à jour identifié. | Affecter le traitement des informations obsolètes. |
Cette grille est illustrative. Les critères exacts doivent être décidés avec les utilisateurs et les responsables des données. Un format valide ne prouve pas qu’une valeur est correcte ; un document récent ne prouve pas qu’il s’applique au bon produit.
3. Exemple : préparer les données d’un assistant interne
Cet exemple ne garantit pas la fiabilité d’un assistant. La qualité de ses sources est un élément du travail ; le comportement du système, ses accès et ses réponses doivent faire l’objet d’une évaluation distincte. Une base documentaire organisée ne constitue pas, à elle seule, une validation de l’IA.
4. Distribuer les responsabilités sans diluer la décision
Le consultant data peut rendre les contrôles reproductibles, documenter les transformations et suivre les anomalies. Il ne peut pas décider seul de la signification métier d’un champ ou de la procédure qui fait autorité.
Nous proposons de distinguer trois responsabilités, même lorsqu’elles sont tenues par une petite équipe :
- Le responsable de l’usage décrit ce que le service doit permettre et les conséquences d’une erreur.
- Le responsable de la donnée arbitre les définitions et organise la correction à la source.
- L’équipe d’ingénierie implémente les règles, trace les traitements et rend les exceptions visibles.
Le point de passage entre ces rôles mérite d’être explicite. Qui reçoit une anomalie ? Qui peut l’accepter provisoirement ? Quand bloque-t-elle le traitement ? L’enjeu est de construire une boucle de résolution, pas seulement une collection d’indicateurs.
5. Commencer petit, avec un résultat observable
Choisissez un usage, les sources nécessaires et un ensemble de situations représentatives. Incluez des cas incomplets, contradictoires ou hors périmètre : ils révèlent les décisions que le fonctionnement nominal laisse invisibles.
- Usage : quelle opération doit être rendue possible ?
- Périmètre : quelles données sont nécessaires, et lesquelles ne le sont pas ?
- Définition : qui confirme le sens et la source de référence ?
- Acceptation : quelles erreurs empêchent l’usage, lesquelles sont tolérables ?
- Exception : que se passe-t-il si une règle échoue ?
- Suivi : comment détecter une dégradation et qui intervient ?
Mesurez d’abord une situation de départ. Choisissez ensuite des indicateurs associés au besoin : anomalies bloquantes non résolues, fraîcheur des informations utilisées ou demandes pour lesquelles aucune source applicable n’est trouvée. Les seuils se discutent selon le risque et l’usage ; nous ne proposons pas de taux universel.
Cette approche donne un périmètre concret à un renfort en data engineering : construire un flux, intégrer un contrôle, documenter une transformation ou organiser le suivi des exceptions. Le projet peut progresser sans attendre une remise à niveau générale de tout le patrimoine.
Source et périmètre de ce point de vue
Le cadre public cité étaye la définition de la qualité selon l’usage. Les contrôles, la répartition des rôles et le scénario d’assistant sont des propositions éditoriales de Spark, à adapter au contexte ; aucun résultat client n’est revendiqué.
Retrouvez nos prochains points de vue Cloud, Data et Pilotage sur la page LinkedIn Spark Conseil.
