La plupart des équipes partent du principe que si leurs données sont en désordre, c'est que quelque chose s'est mal passé. Un client a envoyé un mauvais fichier. Un partenaire a exporté le mauvais format. Une intégration a dérivé sans que personne ne s'en aperçoive. La réaction par défaut est de trouver la source du désordre et de la corriger.
Cette réaction est généralement inappropriée. Des données en désordre ne sont pas le résultat d'une défaillance. C'est l'état naturel des données qui proviennent de plus d'une source.
Les données viennent rarement d'un seul endroit
Vos données proviennent de clients, de partenaires, de fournisseurs, d'outils internes, de systèmes historiques, et parfois de tous en même temps. Chacune de ces sources a sa propre structure, ses propres conventions de nommage, et ses propres contraintes. Elles ont été construites à des moments différents, par des équipes différentes, pour des objectifs différents.
Quand les données de toutes ces sources arrivent dans votre système, le désordre que vous percevez n'est pas un bug. C'est le reflet fidèle d'un monde dans lequel aucun système ne s'accorde avec un autre sur la façon de représenter la même chose.
L'hypothèse : les données devraient être standardisées
La plupart des logiciels reposent sur une hypothèse implicite : les données arriveront dans un format défini. Il y a un template, ou un schéma API, ou une structure documentée, et tout ce qui s'y conforme sera traité correctement.
Cette hypothèse est raisonnable pour les données internes, où vous contrôlez le système en amont. Elle s'effondre pour les données externes, où le système en amont est contrôlé par quelqu'un d'autre, qui ne l'a pas conçu pour correspondre à votre format.
La réalité : les données varient toujours
Même quand toutes les parties font des efforts, la variation s'infiltre. Les templates sont modifiés. Les API sont implémentées légèrement différemment par différentes équipes. Les champs sont interprétés de manières que la documentation n'avait pas anticipées.
Ce que vous recevez est rarement propre. Ce que vous recevez, ce sont des données « presque correctes », avec des champs manquants ici, un nommage incohérent là, des valeurs formatées de manière proche de votre standard mais pas tout à fait identique. Les expéditeurs font des efforts. Les données sont quand même en désordre.
Ce qui crée réellement des données en désordre
Les données en désordre ne sont pas aléatoires. C'est l'accumulation de petites variations à travers de multiples sources, au fil du temps. Chaque variation prise isolément est inoffensive. Un format de date légèrement différent. Un champ appelé « email » au lieu de « email_address ». Une valeur optionnelle manquante. Individuellement, vous pourriez corriger n'importe laquelle en une minute.
Le problème est que ces variations n'arrêtent jamais d'arriver, et qu'elles se combinent de manières difficiles à anticiper. Dix clients produisent des dizaines de petites variations. Cent clients en produisent des centaines. C'est la multiplication des formats, et c'est la cause profonde de ce que vous appelez des données en désordre.
Pourquoi essayer de « corriger les données » ne fonctionne pas
L'instinct est de nettoyer le désordre à la source. Publier des templates plus stricts. Améliorer la documentation. Demander aux clients de suivre les règles plus attentivement. Former les partenaires. Parfois cela aide à la marge. Cela n'élimine jamais le problème.
La raison est que le problème n'est pas du côté du client. Le problème est le décalage entre ce que votre système attend et ce que le monde réel produit. Demander aux utilisateurs de correspondre plus strictement à votre format, c'est leur demander de compenser un choix de conception de votre système. Certains le feront. Beaucoup ne le feront pas, ou le feront de manière incohérente, et le cycle recommence.
Le vrai problème est le décalage
Prenez du recul et regardez ce qui se passe réellement. Votre système attend les données dans une certaine forme. Le monde réel produit des données sous de nombreuses formes. Chaque fichier qui arrive doit être réconcilié avec cette attente, soit par l'expéditeur qui fait un effort supplémentaire pour se conformer, soit par votre équipe qui fait un effort supplémentaire pour nettoyer.
Ni l'un ni l'autre n'est une bonne réponse. Les clients ne devraient pas avoir à adapter leurs systèmes au vôtre avant de pouvoir utiliser votre produit. Votre équipe ne devrait pas avoir à traiter chaque fichier à la main. La bonne réponse est de changer la façon dont votre système gère les données entrantes, pour que la variation cesse d'être un problème que quelqu'un doit absorber.
La meilleure approche : accepter et s'adapter
Au lieu d'essayer d'éliminer la variation, acceptez qu'elle existe et intégrez l'adaptation dans votre système. Laissez les données entrantes arriver dans la forme qu'elles ont. Interprétez la structure automatiquement. Mappez les champs vers votre format attendu en utilisant des patterns et le contexte, pas des correspondances exactes. Transformez les valeurs de manière cohérente, quel que soit leur formatage d'origine.
C'est ce pour quoi les systèmes modernes d'import de données sont conçus. Ils prennent des entrées en désordre et produisent des sorties structurées, sans exiger de l'expéditeur qu'il change quoi que ce soit, ni de votre équipe qu'elle nettoie quoi que ce soit. Les données ne deviennent pas propres parce que quelqu'un les a corrigées. Les données deviennent propres parce que le système absorbe la variation au passage.
Les données en désordre, c'est normal
Si vos données sont en désordre, rien n'est cassé. Vous n'échouez pas en matière de qualité des données. Vous faites face à des entrées du monde réel provenant de sources du monde réel. Le désordre est une caractéristique de la réalité, pas le signe que quelque chose doit être corrigé en amont.
Ce que vous pouvez changer, c'est la façon dont votre système y répond.