Vous bichonnez moins vos données que votre voiture

Hervé Rincent -

J'ai récemment découvert l'existence d'un groupe Européen dédié à l'analyse des risques de l'utilisation d'Excel.

Il se nomme l'EuSpRig (European Spreadsheet Risk Interest Group).

Le recherches menées par ces joyeux lurons d'Irlande et de Grande-Bretagne dévoilent une proportion alarmante de feuilles Excel buggées dans les entreprises. Elles servent pourtant tous les jours, pour faire tourner la boutique. Et parfois même pour répondre à des obligations légales.

Pour illustrer le propos, ils ont collecté une liste de perles des bugs Excel : les "horror stories" (je mets le lien à la fin, ne le lisez pas trop vite, c'est démoralisant).

Et encore, j'imagine que c'est seulement la partie visible de l'iceberg : personne n'aime afficher publiquement combien de boulettes s'expliquent par un Excel corrompu.

Le dernier exemple date d'Octobre 2020 : "Data not controlled, 16000 UK Covid-19 test results lost for a week".

L'auteur du rapport, Patrick O’Beirne, explique comment 16000 résultats de tests Covid ont disparu d'une feuille Excel du Public Health England (PHE), l'agence du ministère de la santé Britannique.

L'explication technique n'a rien de complexe :

  • le laboratoire d'analyse a envoyé ses résultats dans un format texte CSV.
  • Le PHE traitait ces données par une macro Excel, qui créé plusieurs lignes pour chaque résultat.
  • Le fichier Excel du PHE était dans une version obsolète d'Excel, bridée à 65000 lignes !

Résultat : pleins de cas contact de personnes positives ont été ignorés, conduisant à aggraver la propagation de l'épidémie.

Quand le data-driven devient le bullshit-driven

Alors on peut toujours incriminer Excel.

Dire que tout est la faute de l'outil.

Mais je pense que le problème se situe avant ça. Il prend naissance lorsqu'une entreprise se dote d'un logiciel pour gérer ses données, dans le but de prendre des décisions ou de satisfaire à des exigences réglementaires.

Donc, dès le début.

Comme on a Excel sous la main, c'est une sorte de choix "par défaut". Mais le problème existe aussi avec d'autres outils.

Avec le temps et la croissance, la quantité de données devient énorme. La data est abondante, son stockage ne coute rien.

Mais comment s'assurer que c'est fiable ? Comment vérifier que nos superbes analyses présentées sous forme d'histogrammes en 3D à partir d'hypercubes à franges ne sont pas un monument d'erreurs cumulées ?

Il y a globalement 3 types d'erreur qui peuvent affecter la qualité de vos données :

  • les doublons,
  • les données manquantes,
  • des données erronées (pas le bon chiffre dans la bonne case).

Quel est votre plan pour vous éviter ça ?

Dans la plupart des projets, cette question du contrôle de la qualité des données n'est pas abordée directement.

On peut s'appuyer sur les tests de comportement du logiciel pour se rassurer : si les traitements appliqués sont conformes, alors la qualité des données sera maintenue.

Sauf que les tests sont rarement fait en "grandeur nature".

On les applique sur un (petit) jeu de test qui n'est pas représentatif du volume réel. Or des effets d'échelle (ex : le dépassement des 65000 lignes) apparaissent plus tard, lorsque le système en production prend de l'ampleur.

Il faut donc trouver un autre moyen.

Les règles métier

Pour préserver la qualité des données, il faut commencer par définir les principes qu'elles doivent absolument respecter.

Par exemple :

il ne peut pas y avoir 2 transactions de même numéro pour un même compte bancaire.

Voila une règle simple, anti doublon.

Pour la coder, on peut créer un identifiant unique. Il sera construit comme ça : <numéro de compte>-<numéro de transaction>. Exemple : 123456789-987654321.

Cet identifiant ne correspond pas à une vraie donnée. Il ne va pas remplacer le numéro de transaction ni le numéro de compte.

C'est un truc en plus. Il permet juste d'interdire d'avoir 2 fois le même identifiant dans le système, et donc d'éviter un doublon.

Mais comment faire pour des oublis ? Pour des lignes modifiées ou effacées ?

Et bien, il existe un moyen élégant inventé par un italien en 1494.

Oui, c'est pas tout jeune.

En 1494, Luca Pacioli écrit "Summa de arithmetica, geometria, de proportioni et de proportionalita".

Ça lui vaut d'être considéré comme l'inventeur de la comptabilité à double entrée (je ne sais pas si des comptables font des pèlerinages à Borgo Sansepolcro pour lui rendre hommage, mais ce serait un bon prétexte).

Toute l'astuce de la méthode à double entrée consiste à décrire une transaction avec plusieurs lignes au lieu d'une seule.

Par exemple, si dans votre fichier Excel "liste de facture.xls" vous avez la ligne suivante (prestation de 1000€ HT soumise à un taux de TVA de 20%) :

Libellé Date Prix HT TVA
Etude SEO pour l'Oréal 31/07/2021 1000 200

Elle devient en comptabilité à double entrée :

Compte Date Libellé Débit Crédit
L'Oréal 31/07/2021 Etude SEO pour l'Oréal 0000 1200
Mes prestations 31/07/2021 Etude SEO pour l'Oréal 1000 0000
TVA à 20% 31/07/2021 Etude SEO pour l'Oréal 200 0000

L'intérêt est de pouvoir alors appliquer une règle métier qui doit toujours être vraie : les débits et les crédits doivent s'équilibrer (1000 + 200 = 1200).

Si l'une des trois lignes est supprimée, ou qu'un chiffre est modifié, on voit immédiatement surgir le défaut de qualité. L'équilibre est rompu.

Alors on a décrit la transaction de façon plus verbeuse (3 lignes au lieu d'une, duplication du libellé de la transaction), mais on a un système en béton armé pour pister la moindre erreur.

Les données sont le patrimoine de votre boîte, prenez-en soin.

Des données fiables, ce sont des analyses fiables. Et de meilleures décisions pour votre business.

Alors vos données méritent mieux qu'une feuille Excel buggée.

Elle méritent un système qui, par conception, assure à chaque création/modification/suppression que vos règles métiers restent vérifiées.

Le moyen le plus courant est d'ajouter un peu de redondance. De mettre un peu plus de données que celles strictement nécessaires à décrire l'information qu'on stocke.

Un peu comme un checksum, dont la valeur est calculée à partir d'autres valeurs afin d'éviter la corruption d'une zone mémoire ou d'un fichier.

Grâce à ce petit supplément de donnée, on repère facilement les erreurs.

Et on évite d'oublier 16000 résultats de tests Covid.

Références :