Go to content

Data : attention à la panne de sens !

Big Data, Data analysis, Data vizualisation, Open Data, Data science … sont les représentants d’une révolution qui touche tous les acteurs du monde digital (du S.I. des entreprises aux traces numériques que chacun laisse).

On nous promet donc la révolution. Mais derrière celle-ci se cache un profond travail et un instant magique qu’on a tendance à négliger, voire ignorer, et qui sans cela conduit à de profonds déboires.

Les éditeurs des nouvelles solutions de Data analysis nous le promettent, les annonces autour du Big Data et de la Data science également : les données parlent d’elles-mêmes, les données sont libérées, « Avec X, vous pouvez combiner toutes vos sources de données et obtenir instantanément des réponses à toutes vos questions », « Chacun peut analyser les données grâce à des fonctionnalités intuitives par glisser-déplacer »…

La réalité n’est pas exactement celle-là. Ces promesses ne valent qu’une fois un ensemble de conditions respectées, que l’on peut résumer en : les données sont prêtes, on en connait le sens et la façon de les interpréter.

Préparer les données

Beaucoup s’accordent sur le fait que l’immense majorité (80% … 90%) du temps passé par un Data scientist, à son grand désespoir, consiste à préparer les données avant d’effectuer son travail d’analyse.

Dans cette préparation, l’ambiguïté, l’erreur de sens guette à tout moment : choux ou carottes, choux de 2014 ou de 2015, choux de Bretagne ou du Nord, choux-fleurs ou choux de Bruxelles… ?

Laissez 30 secondes un interlocuteur métier – même avancé dans la connaissance du S.I. – face aux données brutes extraites d’un ERP et vous comprendrez tout de suite devant son regard à quels risques on s’expose.

Interpréter les données

Attribuer un sens correct et précis à une donnée n’est pas immédiat. Il faut retrouver : sa définition initiale, sa définition lorsqu’elle est utilisée (qui peut être différente), les règles de gestion mises en œuvre, le contexte associé (les objets en relation)… le tout permettant la bonne interprétation de la donnée et donc son sens.

Exemple :

  • domaine métier : une entreprise gère un réseau (de transport, de distribution d’énergie…). Ce réseau fait l’objet d’un service de surveillance que l’on veut mesurer (via la donnée : « kilomètres de réseau surveillés »).
  • définition initiale de la donnée : nombre de kilomètres de réseau, en absolu, ayant fait l’objet d’au moins une opération de surveillance (je veux connaître la part du réseau surveillée sous ma responsabilité)
  • définition d’usage de la donnée : nombre de kilomètres de réseau ayant fait l’objet d’une opération de surveillance (dérive de la définition initiale : je veux connaître le cumul du réseau surveillé – mise en avant du service réalisé sous ma responsabilité – chaque kilomètre d’une opération de surveillance est alors comptabilisé même si ce même kilomètre a déjà fait l’objet d’une opération précédente de surveillance)
  • contexte associé – objet lié : intervention de type opération de surveillance (autre type : opération d’entretien)
  • ambiguïtés possibles : incohérence de mesure des kilomètres surveillés – en cumul à chaque opération de surveillance ou en absolu, les opérations d’entretien appartiennent ou non à la catégorie des opérations de surveillance – les kilomètres entretenus sont comptabilisés ou non (risques d’écarts entre différentes mesures).

L’erreur sémantique est la mère de toutes les erreurs. Elle conduit à classer, projeter, regrouper les données dans de mauvaises catégories, avec pour conséquence des mesures, des indicateurs, des corrélations, des classements, des enrichissements, des ascriptions à un schéma donné… erronés, mettant à mal les décisions, les raisonnements, les jugements que l’on peut faire à partir de ces résultats.

Définir, attribuer un sens à une donnée est par nature une activité humaine. À un moment donné dans le processus de définition d’une chaîne de production et d’exploitation des données, il va falloir passer d’un domaine informel (le contexte, le langage, le vocabulaire d’un domaine métier – « notre engagement de service consiste à assurer la surveillance de votre réseau »), à une représentation formelle (au sens interprétable par une machine – sous forme d’une donnée « = nombre de kilomètres de réseau en absolu ayant au moins fait l’objet d’une surveillance »). C’est ce qu’on peut appeler l’instant magique et, pour le moment, nul algorithme n’est à même (ne sera à même ?) de réussir cela sans une part humaine : « les machines ne sont pas sémantiques » J. Searle1

Adopter une méthode

On est donc face à une activité clé qui même (et surtout) si elle manipule le langage nécessite une certaine expertise. Cette expertise est trompeuse, après tout définir le sens d’une donnée, ce n’est qu’une histoire de langage et de définition accessible à tout un chacun. En réalité ce n’est pas aussi simple que cela et un minimum de rigueur et de structure est nécessaire. Rares sont les méthodes qui s’aventurent sur ce terrain.

La plus avancée en la matière est Praxeme qui a fait de l’aspect sémantique son cœur méthodologique avec un ensemble de procédés de définition et de modélisation : procédé de terminologie (produire la définition d’un terme donné – première étape de la définition du sens d’une donnée), guide de l’aspect sémantique (modélisation sémantique : lien avec le langage naturel, expression formelle des termes dans un modèle de classes d’objets … supports aux données – étape suivante de formalisation du sens des données au sein d’un modèle). D’autres approches proposent, dans un cadre de gouvernance, la description d’activités autour de la définition de données, exemples : Mike2.0taxonomy design, ou encore l’activité de « Data modeling » dans la mouvance du DMBOK (« Develop the Enterprise Data Model »).

Définir une gouvernance

Pour revenir aux promesses des solutions « Data » (data analysis / data vizualisation / data discovery…), oui, elles apportent de la performance, oui, elles permettent plus d’autonomie des utilisateurs (idée de self BI), oui, il est possible de repousser la standardisation des données à l’usage et non a priori (idée de rapidité pour les expérimentations/laboratoires autour des données), oui, elles facilitent les démarches agile, oui, elles ouvrent le champ à de nouvelles capacités d’exploitation des données (l’exploration visuelle des données est le meilleur exemple)… mais non, elles ne donnent pas du sens aux données (au mieux elles implémentent la définition d’une couche sémantique garante d’une meilleure « lisibilité » des données sources ou brutes sous forme de concepts/objets métier compréhensibles).

Pour finir et en conclusion, lorsqu’on manipule des données, définir le sens d’une donnée est une étape clé. Cette définition n’est pas instantanée. C’est une activité humaine qui a besoin de méthode. La gouvernance de cette activité ne doit pas être négligée (qui et comment : produire un dictionnaire des données, identifier les axes de référence sur lesquels on peut projeter les données, définir un modèle sémantique qui met en relation les données … et quelles sont les responsabilités, les propriétaires associés…).

Sans gardien du sens … la panne de sens guette.

1 Pour ceux que cela intéresse, de nombreux débats ont lieu sur la position de J. Searle – exemple : https://francoisloth.wordpress.com/2007/04/19/largument-de-la-chambre-chinoise/

Auteur : Joël Bizingre (billet et illustration)