Audit des données – regardons ce qui compte vraiment !

Les données sont souvent présentées comme un « nouvel eldorado », l’actif « le plus important » dont disposent les entreprises 2.0. Si le «big data » et l’analyse prédictive constituent sans aucun doute des leviers important de création de valeur (certains de ces leviers présentant toutefois quelques risques en matière d’éthique, réglementaire voire de propriété intellectuelle), il ne faudrait pas toutefois que le développement de ces activités relèguent au second plan la gestion de la qualité des données (le Data Quality Management ou DQM). En effet, disposer de beaucoup de données, c’est bien ; être capable de s’assurer que ces données sont exhaustives, exactes, comparables, pertinentes, intelligibles… c’est mieux !  Si cela peut paraître au premier abord évident, je suis souvent consterné par la quantité de données produites par les organisations qui sont au mieux inutilisées, au pire totalement inutiles. Au regard de la question des données, les auditeurs internes adoptent le plus souvent une approche focalisée sur leur exactitude, leur exhaustivité, leur disponibilité et leur confidentialité, aux détriments d’autres variables (parfois plus importantes), telles que leur gouvernance, leur degré d’utilisation, leur adéquation par rapport aux objectifs poursuivis… De mon point de vue, les auditeurs internes devraient se focaliser d’abord sur quelques règles simples, détaillées ci-dessous, lorsqu’ils sont amenés à effectuer un audit de données. Ces quelques règles peuvent paraître triviales, mais leur mise en œuvre est souvent un vrai challenge, notamment du fait du non-respect fréquent par les organisations du fameux principe de Pareto.

• Toute demande de création/modification d’un champ de données dans les systèmes d’information doit faire l’objet d’un processus d’information et d’approbation formalisé, impliquant au minimum la direction financière qui se doit de procéder à une évaluation préalable des besoins (qui, quand, pourquoi…). Il est également important de vérifier au préalable que cette information n’existe pas déjà…
• Tout champ de donnée qui est configuré dans une logique de "au cas où" (avec une probabilité < X %) ne doit pas faire l’objet d’une mise en œuvre dans les systèmes d’information,
• Tout champ de données doit faire l’objet d’un processus d’évaluation périodique, afin de déterminer s’il est utilisé ou non. L’accent doit être mis sur les champs obligatoires.
• Lorsque l’utilisateur se voit proposer des options, et si ces dernières ne sont pas imposées par la réglementation, le maximum des options proposées ne doit pas dépasser un nombre donné,
• Toute liste d’options doit comporter une catégorie "autre" accompagnée d’un champ de saisie obligatoire,
• Lorsqu’une catégorie "autre" a été configurée, des rapports périodiques du pourcentage qu’elle représente doivent être émis. Si ce pourcentage dépasse un certain seuil, les utilisateurs doivent en être alertés individuellement et procéder au "nettoyage" des données,
• Quand cela est pertinent, une option par défaut doit être cochée (exemple : si transactions identiques dans plus de 90 % des cas),
• Pour chaque champ de donnée, une définition précise des données doit être disponible, et facilement accessible par les utilisateurs,
• Les champs obligatoires doivent être clairement identifiés. Pour les champs non obligatoires, une évaluation périodique de la pertinence de leur présence doit être réalisée (ils polluent potentiellement le système et sont source de lourdeur),
• Quand cela est possible, les informations qu’il est demandé de saisir à l’utilisateur doivent être présentées de la plus importante à la moins importante,
• Essayez de temps en temps de ne pas envoyer un rapport/compléter certaines informations demandées et attendez de voir ce qu’il se passe (vous serez sans doute surpris !),
• « Last but not least », il est fondamental de limiter au maximum les doubles (voire triples) saisies dans des systèmes différents (cela exaspère les opérationnels…), ce qui implique un fort niveau de coordination dans la définition de l’architecture des SI.

Je suis convaincu que le respect de ces quelques règles simples permet :

• de réduire les coûts,
• de maximiser l’utilisation des investissements effectués (dans les SI),

de limiter le risque de « data burn out » que je rencontre très fréquemment.