Read this white paper in English uk-flag

QA et Analytics :
Le Guide Ultime

La Qualité Des Données N’est Plus Suffisante

La qualité des données n’est pas la priorité de tous malheureusement, mais pire encore, la qualité des données traitées par les logiciels de BI et Analytique ne fait pas assez souvent l’objet de plans d’action en entreprise.

Il est évident que la qualité des données doit faire partie de l’approche stratégique de toute organisation, car les résultats en bout de chaîne dépendent évidemment de la qualité en aval. Cependant, elle ne suffit plus. Comme le dit Ted Friedman du Gartner, “ce ne sont pas seulement les données qui nécessitent une gouvernance, mais beaucoup d’autre choses dans le monde de l’Analytique“. 

Pourtant, la réalité sur le terrain c’est que les décideurs prennent action sur la base de données rendues disponibles dans les logiciels décisionnels, jamais sur la base de données brutes. Or ces logiciels sont pour la plupart, non gouvernés et non fiables. A ne pas déployer de politique de qualité à ce niveau, vous négligez le dernier kilomètre de la donnée : la couche analytique, là où les décisions importantes se prennent. 

Les données qui transitent par les plateformes de BI et analytique peuvent être bien gérées, mais le sont-elles toujours lorsqu’elles sont manipulées à des fins d’analyse ? Comment s’assurer du respect des réglementations en matière de données lorsque celles-ci sont largement partagées et modifiées ? Êtes-vous certain d’accorder la même attention et d’effectuer les mêmes contrôles qualité à la couche de données analytiques qu’à la couche de données brutes ? Avez-vous des processus qualité spécifiques à votre patrimoine analytique vous permettant d’assurer ces éléments ?

graphique-dernier-kilometre-donnee

Chacun doit pouvoir faire confiance aux données qu’il consomme, ce qui nécessite de leur garantir, voir de leur prouver qu’ils travaillent avec des données vérifiées. Un processus d’assurance qualité (QA) fournit l’assurance ultime que les données analytiques d’une organisation sont gouvernées, qu’elles ne sont pas à risque et que des décisions peuvent être prises en toute confiance.

“L’idée de la confiance est très importante et fondamentale pour générer toute sorte de valeur à partir des données et de l’analytique”.

Ted Friedman, Gartner.

Chez Wiiisdom, nous avons pour mission de fiabiliser les analytics afin de permettre une meilleure prise de décision axée sur les données . L’analyse de données devrait toujours être votre chemin vers plus de succès, et jamais quelque chose qui met en péril la réputation de votre entreprise. Ce livre blanc présente les facteurs clés de l’assurance qualité de vos analytiques afin que vous n’ayez plus à remettre en question vos données.

 

Un processus de QA pour les Analytics est un projet de long terme

Un processus de QA clair et bien planifié est indispensable au succès de la qualité de l’analytique et devrait être un objectif que toute organisation s’efforce d’atteindre. Un processus d’assurance qualité pour l’analytique permet aux organisations de mesurer les normes de qualité de leurs contenus analytique et décisionnel, ce qui se fait essentiellement par le biais de tests BI, afin de repérer les régressions, les risques potentiels, les possibilités d’amélioration et, surtout, d’éviter que de mauvaises décisions soient prises. Le coût de la publication d’informations erronées est beaucoup trop élevé pour ne pas mettre en place de stratégie digne de ce nom.

 

Un cycle de vie d’Analytics QA se compose généralement de 6 étapes :

1. Analyse des besoins fonctionnels
Cette étape consiste à identifier les éléments importants, ceux nécessitant une qualité importante, par exemple, quel est le temps maximal d’ouverture d’un tableau de bord, ou si un tableau de bord affiche des indicateurs clés de performance valides. Ces exigences seront discutées avec les utilisateurs qui ont la connaissance métier.

2. Planification des tests
C’est ici que l’équipe d’assurance qualité décide de ce qui sera testé sur la base des exigences identifiées, de la manière dont ils seront testés, par qui et quelles ressources seront nécessaires.

3. Développement du/des cas de test
La troisième étape consiste à créer des cas de test dans l’environnement choisi, qu’il s’agisse de test en phase de développement ou en phase de production, ce qui inclut également l’intégration des résultats attendus afin que les testeurs puissent clairement identifier si les tests réussissent ou échouent et prévoir les actions en conséquence.

4. Exécution du test
Il est temps que la magie opère et que les tests soient lancés.

5. Analyse du résultat
Une fois les tests terminés, l’équipe d’assurance qualité analyse les résultats et détermine si certains tests ont échoué. Si c’est le cas, elle les corrige et les teste à nouveau jusqu’à ce que tous les tests soient réussis.

6. Automatisation du test
L’équipe d’assurance qualité peut automatiser tous ses tests à l’aide de solutions telles que Wiiisdom Ops, afin de supprimer les risques et les difficultés liés aux tests manuels, chronophages et sources d’erreurs.

Ce qu’il faut retenir, c’est qu’un processus de QA Analytique est un processus continu. L’automatisation permettra d’exécuter les cinq étapes en continu afin de garantir le plus haut niveau de qualité à tout moment. 

 

De Qui Est Composée Une Équipe Assurance Qualité en BI et Analytique ?

Pour construire un système, il faut des personnes, des processus et des technologies. Pour qu’un processus de QA Analytique soit réussi, les organisations doivent d’abord avoir les bonnes personnes.

Il y a trois rôles principaux dans une équipe de QA Analytique :

  • Gestionnaire Qualité Analytique :il travaille en étroite collaboration avec les départements métier afin d’avoir une compréhension complète de l’activité et des exigences des clients, il supervise l’équipe d’assurance qualité pour garantir l’agilité des processus.
  • Analyste Qualité Analytique : il exécute et évalue le système, en documentant les tests et l’état général pour l’ingénieur QA. Dans la plupart des cas, ils sont le principal point de contact avec la ligne métier qui consomme les données. Ils jouent un rôle important en faisant du test un élément central du processus qualité.
  • Ingénieur Qualité Analytique : il crée des tests en fonction des métiers et de ses exigences, et teste les rapports, datasets et autres tableaux de bord pour détecter les problèmes potentiels, assurer la conformité aux exigences, tout en travaillant dans un environnement agile avec les technologies mises à sa disposition.

 

Comme tout rôle, il s’accompagne de défis et chaque membre d’une équipe QA y sera confronté :

  • Gestionnaire Qualité Analytique
    • Pas d’objectifs clairs en matière de QA
    • Silos analytiques au sein de l’entreprise
  • Analyste Qualité Analytique
    • Modifications de dernière minute des exigences
    • Produits bogués
    • Nouvelles fonctionnalités à la dernière minute
  • Ingénieur Qualité Analytique
    • Environnement instable nécessitant le redémarrage du serveur avant les tests
    • Délais serrés

 

Quelles sont les principales causes de problèmes de qualité dans les analytiques

“Mes données sont contrôlées avant d’arriver dans mon application décisionnelle, pourrait ne le seraient-elles plus en sortie ?”

Prenons une analogie, et imaginez vous faire tous les jours le même trajet pour vous rendre au bureau sans problème et que soudain, un jour, le trafic est beaucoup plus dense et vous arrivez en retard à une réunion importante, il en va de même pour vos données. Tout peut fonctionner parfaitement et un jour, le client pense voir des problèmes dans ses tableaux de bord, ce qui l’amène à douter de la qualité. Ne vous est-il jamais arrivé de douter d’une donnée présente dans un rapport ou tableau de bord ? N’avait vous jamais téléchargé la donnée brute en local pour la vérifier vous-même ?

 

A nouveau, il ne suffit pas d’avoir des données de qualité. Elles peuvent être fiables et gouvernées, mais elles ne le resteront pas longtemps. Les données passent par trois autres étapes avant d’être affichées dans un tableau de bord : 

  1. La préparation des données analytiques (par exemple Tableau Prep, Power BI Query),
  2. la création et le rafraîchissement des datasets et des cubes de données,
  3. et enfin la conception du tableau de bord. 

Au cours de ces trois étapes, les données peuvent encore être modifiées, en particulier dans un contexte de libre-service, ce qui a un impact sur la qualité des données sur leur dernier kilomètre.

graphique-qualite-donnee-dernier-kilometre

La mauvaise qualité de l’analytique crée un effet domino dans toute organisation ; manque de confiance, manque d’adoption par les utilisateurs, risque de mauvaise prise de décision, l’éventail de facteurs qui peuvent causer une défaillance de l’analytique aujourd’hui est très large. Outre les risques liés aux manipulations de données dans la couche analytique, il existe de nombreuses raisons pour lesquelles la qualité des données peut être impactée. Nous vous expliquons ici les 6 causes principales responsables de problèmes de qualité analytique que vous devez connaître et traiter :

 

1. L’accélération de la BI en libre-service

Il est vrai que l’analyse en libre-service est formidable, mais les fournisseurs de BI modernes qui en font la promotion ont ouvert la boîte de pandor à des non-initiés, ce qui augmente le risque d’injecter des données non contrôlées et de qualité inférieure sur la plateforme. Contrairement à l’époque où c’était la fonction IT/BI qui créait le contenu analytique utilisé pour la prise de décision, aujourd’hui n’importe qui peut le faire, qu’il soit qualifié ou non, mais avec un processus de validation moins rigoureux. Il est nécessaire d’encadrer cette pratique sans pour autant casser l’esprit du libre-service. Un processus de vérification et de certification doit être mis en place pour assurer à l’organisation dans son ensemble de ne pas utiliser de mauvaises données pour la prise de décision.

 

2. Les problèmes liés aux données

C’est évident: si les données entrantes dans votre plateforme analytique sont de mauvaise qualité, alors les analyses ne pourront être que fausses. Cette situation est particulièrement risquée dans les secteurs réglementés tels que les organisations financières, où les entreprises traitent des informations sensibles pour lesquelles il n’y a pas de place pour l’erreur.

La première étape consiste bien sûr à se connecter à la source de données. Il s’agit d’une étape critique, car toute erreur commise ici aura des conséquences au moment de prendre des décisions. Une mauvaise compréhension de la manière dont les sources de données ont été construites, des erreurs lors de la fusion avec d’autres sources, la connexion à des données non certifiées ou des erreurs lors de l’étape de préparation des données peuvent avoir de graves conséquences.

Par ailleurs, ce n’est pas parce que la donnée dans l’entrepôt de donnée est gouvernée, qu’il ne peut jamais y avoir d’erreur en aval. C’est pourquoi des tests de réconciliation des données entre les tableaux de bord et la donnée dans l’entrepôt de données permettent de certifier la validité des données de bout en bout.

 

3. Évolutions des logiciels et mises à jour

Toute modification apportée par le fournisseur de la plateforme de BI et Analytique peut augmenter le risque qu’un nouvel élément soit introduit ou modifié et induire de nouveaux risques. Ces modifications peuvent en effet avoir un impact direct sur les tableaux de bord que vous avez créés et publiés. Pour vous assurer que la qualité de vos analytiques n’est pas compromise, des tests doivent être effectués après toute mise à jour de votre logiciel décisionnel, quelle que soit son importance.

 

4. Tester uniquement au niveau de la préparation des données

Certaines organisations pensent que les tests au niveau de la préparation des données (création d’un dataset analytique) suffisent à garantir la qualité des données. Or, il existe encore de nombreuses possibilités de transformation des données. Le parcours de vos données est plus long et plus périlleux que vous ne le pensez ! Entre ce que vous voyez dans les graphiques de votre solution de BI préférée et les données à leur source (disons ici dans votre entrepôt de données), il y a de nombreuses étapes où les données sont acquises, transformées, connectées et souvent modifiées à nouveau. De même, tout test au niveau de la préparation des données est souvent effectué manuellement, ce qui est très propice aux erreurs.

Imaginez que vous ayez un DWH contenant toutes les données financières de votre entreprise, mais que vous souhaitiez fournir des analyses pour l’année en cours et pour les pays européens uniquement. Après avoir vérifié que tout est correct (par exemple, confirmer que seuls 27 pays sont sur la liste, et non 28, et que les données ne concernent que l’année 2022), et avoir traité les doublons et les nuls, etc., vous partagez ensuite cet ensemble de données préparées pour être utilisées pour créer des visualisations. La création de visualisations à partir d’un ensemble de données offre toujours plusieurs possibilités à l’utilisateur final d’apporter des transformations supplémentaires aux données qui ont été “validées” en premier lieu. La connexion à plusieurs ensembles de données, la suppression de données à l’aide de filtres, les erreurs de codage dans les formules, la liste est longue.

 

5. Sécurité de bas niveau

La sécurité au niveau des lignes permet aux organisations de restreindre certaines données à des groupes d’individus spécifiques afin que ceux-ci n’accèdent qu’aux lignes de données qui les concernent. Toutefois, cela peut également poser des problèmes de qualité. Imaginons qu’un utilisateur ait accès aux informations sur les ventes en France, mais qu’il déménage ensuite au Royaume-Uni et qu’il ne voit que les informations sur les ventes au Royaume-Uni alors qu’il a besoin des deux. Comment peut-il garantir la fiabilité de l’analyse des informations sur les ventes en France s’il ne peut plus accéder aux données ?

 

6. Customisation du SQL

Une requête SQL est utilisée pour connecter l’entrepôt de données et le niveau de préparation des données dans le logiciel décisionnel, mais elle peut être personnalisée. Cette personnalisation augmente le risque lié à la qualité des données lorsqu’elles sont utilisées pour l’analyse, ce qui souligne encore plus le fait que les problèmes de qualité de l’analyse peuvent survenir à n’importe quel stade du parcours des données.

 

Quelques bonnes pratiques pour des analytiques de haute qualité

Il n’y a pas de processus QA analytique standard, chaque organisation décide de la manière dont elle gère cela à sa façon, mais pour que cela soit plus efficace, l’établissement d’une culture de test en matière BI doit être une priorité. Pour vous aider à définir un processus de QA Analytique, il existe quelques bonnes pratiques reconnues dans le monde de la qualité dont on peut s’inspirer. Voici une liste non exhaustive de bonnes pratiques que vous pourriez envisager :

 

Collaborez avec l’équipe BI

L’équipe d’assurance qualité doit travailler en étroite collaboration avec l’équipe BI pour comprendre comment les produits fonctionnent et, surtout, comment les clients les utilisent. De même, l’équipe d’assurance qualité doit être informée des prochaines versions afin de disposer du temps et des ressources nécessaires pour mettre en œuvre les tests nécessaires.

 

Automatisez, automatisez, automatisez

Les tests de BI représentant une part importante du rôle d’une équipe d’assurance qualité, l’automatisation est une évidence. L’utilisation de solutions de test automatisés pour votre plateforme de BI/A atténuera les risques, réduira les erreurs humaines, permettra d’effectuer les tests plus rapidement et à plus grande échelle, réduira le coût total de possession et, enfin, garantira une qualité élevée des analytiques.

Un de nos clients a automatisé son processus de QA analytique et a économisé jusqu’à 2 jours de travail au total. Grâce à son processus d’assurance qualité automatique, le nombre de tickets  (créés par les utilisateurs finaux pour des dashboards Tableau déjà développés) a été réduit de 40 %.

 

Il vaut mieux commencer rapidement

Selon une récente étude, la correction d’un bogue après la sortie d’un produit coûte 4 à 5 fois plus cher que sa correction pendant le processus de QA, ce qui ne fait que souligner, encore plus, l’importance de cette étape dès le début d’un projet. Si les organisations souhaitent obtenir une qualité analytique élevée, un process qualité doit être mis en place rapidement.

 

Testez chaque correction ou changement

Une haute qualité des analytics ne peut être obtenue qu’en testant chaque correction ou changement dans votre plateforme. Cela peut être divisé en deux groupes : les projets planifiés et les changements inopinés.

Les projets planifiés comprennent les montées de versions, les migrations de données (par exemple, Teradata vers Snowflake) ou les modifications de votre ETL. Les changements inopinés sont les correctifs de navigateur comme les mises à niveau soudaines du fournisseur SaaS (plateforme d’analyse, ETL ou base de données).

Pour les changements imprévus, il est essentiel de mettre en œuvre des tests de régression continus, notamment là où se trouvent vos données sensibles pour s’assurer que vos tableaux de bord affichent toujours les mêmes informations. De plus, tout changement doit être documenté afin que l’équipe d’assurance qualité puisse tester des scénarios pour s’assurer qu’il n’y a pas d’impact négatif en aval.

Notre client a utilisé la solution de test de régression de Wiiisdom Ops lors de ses récents projets de mise à niveau et de migration de serveurs pour s’assurer que les tableaux de bord sur les différents serveurs continuaient à fonctionner correctement.

Bonnes pratiques dans l’industrie : Selon une étude menée dans le secteur des services financiers, “79 % des équipes bancaires exécutent leurs tests au moins quotidiennement” pour garantir la qualité de leurs analyses.

Préparer et écrire les cas de test

Ce n’est peut-être pas la partie la plus excitante du process de QA mais c’est un élément fondamental car il permet à l’équipe de réfléchir de manière critique à ce qu’elle va tester et comment elle va tester chaque fonctionnalité. La première chose à faire est donc de définir vos objectifs et les exigences fonctionnelles. Pour ce faire, il faut collaborer avec le métier ou projet qui sera le futur client interne. Pour aider à déterminer les exigences, il est également utile d’examiner l’utilisation de votre plateforme afin de prioriser les tests. Par exemple, les fonctionnalités critiques telles que l’ouverture des visualisations et l’interaction avec le tableau de bord doivent figurer en tête de liste. Les cas de test sont également précieux pour les tests de régression à la fin d’un projet afin de vérifier que les résultats sont conformes aux attentes.

“La mise en place des cas de test dans Wiiisdom Ops peut prendre du temps en fonction de la complexité du tableau de bord, mais une fois que c’est fait, cela nous a fait gagner plus de temps que le temps qu’il fallait pour les mettre en place. Nous sommes en mesure de tout tester de bout en bout, ce qui est formidable.”

Un acteur de la santé.

Instaurez un process de développement piloté par les tests (TDD)

La méthode du Test-driven development (TDD) implique d’écrire des cas de test, puis d’écrire le code – ici, développer le tableau de bord ou le rapport – de sorte que le test passe, et de continuer à répéter ces étapes sur une base régulière. Cela permet à l’équipe d’assurance qualité de trouver les problèmes le plus tôt possible et de les résoudre avant la mise en production. N.B. Le TDD est rendu possible dans Tableau avec Wiiisdom Ops.

 

Effectuez des tests basés sur les risques

Si votre équipe d’assurance qualité a du mal à identifier les ressources à tester, une bonne piste serait de se baser sur le niveau de criticité de celles-ci. Par exemple, les rapports contenant des données sensibles ou personnelles (PII), ceux utilisés par les cadres supérieurs ou la direction, ceux servant à la gestion des risques ou la finance, ou encore ceux destinés à exposer la donnée à public externe.

Il est également impératif de le faire pour les industries qui doivent suivre des réglementations très strictes en raison du niveau de sensibilité des données avec lesquelles elles travaillent. Par exemple, les organisations soumises à HIPAA pour le secteur de la santé, FISMA pour le secteur fédéral ou encore SOX pour le secteur financier. Ils ne peuvent tout simplement pas se permettre de prendre des risques de conformité, c’est pourquoi les tests de conformité basés sur les risques sont indispensables pour s’assurer que leurs solutions logicielles répondent aux exigences du secteur.

Documentez les erreurs efficacement

La communication joue un rôle important dans l’obtention d’une qualité élevée des analytics et il est recommandé de mettre en place des processus pour signaler toute erreur dans vos données afin qu’elles puissent être corrigées le plus rapidement possible. L’utilisation de solutions de messagerie instantanée comme Slack ou Microsoft Teams est un excellent moyen d’y parvenir.

NB: Wiiisdom Ops vous permet d’intégrer les rapports de test avec Teams, Slack ou toute autre solution de messagerie compatible webhook.

 

Actualisez régulièrement vos routines de test

La création de plans de test marque le point de départ de tout projet de test pour identifier ce qui doit être testé et par qui, mais il est également important de ne pas oublier de mettre à jour ces plans à chaque étape importante afin que les tests continuent à s’aligner sur les objectifs et les besoins de l’entreprise.

 

Simulez le parcours de l’utilisateur final

Les utilisateurs finaux s’attendent à ce que tout fonctionne parfaitement lorsqu’ils interagissent avec leurs logiciels analytique. Il est donc essentiel que l’équipe d’assurance qualité communique avec les utilisateurs finaux pour comprendre leurs besoins, puis qu’elle simule leurs parcours pour s’assurer que tout fonctionne correctement et trouver tout problème potentiel avant eux.

 

Proposez la mise en place d’accords de service (SLA) pour l’analytique

Dans le monde de la BI et de l’analytique, l’informatique et l’entreprise sont souvent cloisonnées, mais pour briser ce clivage et s’assurer que les données fournies à l’entreprise sont de la plus haute qualité, des accords de service analytique peuvent être mis en place. Il s’agit d’un engagement contractuel bilatéral contenant des indicateurs clés de performance sur lesquels chacun est attendu. Ces SLA Analytiques peuvent être définis avec plusieurs objectifs tels que le niveau de performance attendu, le niveau de disponibilité, la couverture de test, le taux d’erreur remonté, le nombre de plainte, etc.

 

Intégrez vos processus d’assurance qualité analytique à un pipeline CI/CD plus large.

Un processus de QA digne de ce nom accélère la livraison et le déploiement grâce à la réalisation de tests BI réguliers. Cela s’intègre parfaitement dans le pipeline CI/CD qui se concentre sur le développement et les tests continus pour garantir la qualité des analyses. Il permet également à l’équipe d’assurance qualité de surveiller plus facilement les tableaux de bord et de trouver les erreurs éventuelles avant les utilisateurs.

 

La Qualité Des Analytics Ne Doit Plus Attendre

La qualité des analytics joue un rôle crucial sur le dernier kilomètre du parcours des données et permet de garantir la bonne prise de décision. Ce n’est pas parce que les données sont de bonne qualité en entrée qu’elles le seront en sortie de vos logiciels décisionnels. Différents facteurs sont à l’origine des problèmes de qualité des analytiques, mais en suivant les bonnes pratiques décrites dans ce livre blanc, vous serez sur la bonne voie pour protéger votre organisation contre les risques qu’elle encoure.

Chez Wiiisdom, nous transformons votre paysage analytique en un lieu fiable pour prendre chaque jour de meilleures décisions, en toute confiance, et maximiser votre patrimoine de donnée. Wiiisdom Ops, développé par Wiiisdom, est une solution de gouvernance analytique agile qui permet à nos clients de rationaliser leurs opérations de qualité grâce à des tests automatisés.

Auteur : Ailsa Cartledge