L’adage est bien connu en informatique : “garbage in, garbage out” (aka GIGO). C’est-à-dire que si les données en entrée d’un programme sont de mauvaise qualité, alors le résultat du programme sera de mauvaise qualité. Si cette idée semble évidente, elle est néanmoins à interpréter avec nuance.
Data in, information out
En 2015, AlphaGo était le premier ordinateur à battre un joueur professionnel de jeu de Go. Pour ce faire, les différents réseaux de neurones qui composaient son algorithme de jeu avaient été entrainés avec des exemples de parties de Go de haut niveau. À l’évidence, si on les avait entrainés avec des parties d’échecs, fussent-elles de très haut niveau, jamais AlphaGo n’aurait battu un professionnel de Go. On aurait été face à un cas GIGO, dans une compréhension assez triviale. Néanmoins, entrainé de la sorte avec des parties d’échecs, c’eût probablement été un redoutable adversaire sur 64 cases… On voit bien sûr avec ce cas très simple que la qualité des données en entrée est une notion éminemment dépendante de l’objectif, c’est-à-dire de l’information que l’on veut obtenir en sortie.
Blockchain, véracité des données et supply chain
Lorsque l’on parle de blockchain et de traçabilité des supply chains, vient rapidement la question de la « véracité des données ». Comme une donnée enregistrée dans une blockchain ne peut a priori pas être modifiée (voir notre article sur le sujet), il est courant d’entendre qu’il faut être certain que les données enregistrées soient toujours vraies, sans quoi (garbage in) toute la traçabilité serait gâchée (garbage out). Pourtant cette apparente évidence ne veut pas dire grand-chose…
Dans ce contexte, l’apport de blockchain est de fournir une trace inaltérable de qui a déclaré quoi et quand. Autrement dit, c’est la validité de la donnée qui est garantie (origine, intégrité, temporalité) mais en aucun cas sa véracité. Il se trouve que dans le cas des crypto-monnaies les deux notions se recouvrent : mais c’est un cas particulier lié au fait que la crypto-monnaie n’existe pas en dehors de son réseau blockchain. Dans le cas de la traçabilité de supply chain, les données présentes dans une blockchain sont une représentation numérique du monde physique : la cohérence des deux ne peut pas être garantie absolument en dehors de cas triviaux.
En effet, la traçabilité des supply chains fait face à plusieurs enjeux complexes :
- la grande fragmentation des chaines industrielles modernes : jusqu’à plusieurs dizaines d’intermédiaires, avec un faible niveau d’intégration et même de connaissance entre intermédiaires à 2 ou 3 rangs de distance;
- la volumétrie des flux physiques et des données qui nécessite un traitement à l’échelle;
- l’hétérogénéité des points de captures de données en terme de nature (ERP, IoT, Excel, papier, saisie manuelle, scan de SSCC, etc) mais aussi de cycle de vie.
- les erreurs, les pannes ou les fraudes qui sont une réalité opérationnelle constatée, et assez évidente finalement si l’on est pragmatique.
Avec ces contraintes, il est donc illusoire de chercher à garantir tout le temps, et partout, la véracité des données que l’on capte. Si un capteur IoT est en panne, il peut envoyer de la donnée fausse ; s’il y a une erreur de saisie dans un ERP la donnée sera fausse ; si un intermédiaire fraude, par définition il fournira des données fausses, etc.
En réalité, une fois la donnée collectée, il faut savoir lui donner vie et la faire parler, qu’elle soit vraie ou pas. La connaissance que nous pourrons en tirer dépend de fait de l’angle de lecture choisi, et donc du type d’information recherchée. Modifier légèrement son angle de lecture suffit parfois à déduire d’une donnée « qui ne parle pas » une information neuve et exploitable.
Je doute donc j’analyse…
La validité des données permet de définir un mécanisme d’analyse, de compréhension et d’amélioration continu de la supply chain. En effet, des données valides permettent de construire une image stable du processus, que l’on va ensuite pouvoir analyser et améliorer.
Prenons par exemple la destruction d’un produit en rappel dans un entrepôt. Blockchain garantit que la destruction a été déclarée, mais ne garantit pas la destruction elle-même. Quelle est dès lors la qualité de la donnée qui décrit la déclaration de la destruction ? Si la destruction n’a pas eu lieu mais que la donnée de déclaration prétend qu’elle a eu lieu, est-ce que cette donnée est pour autant de mauvaise qualité (garbage in) ?
En pratique, on va utiliser différents algorithmes pour construire des indices de confiance sur les données : comparaison de sources de données indépendantes pour vérifier leur cohérence, application de modèles attendus à chaque source (modèle statistique de comportement temporel ou cahier des charges, par exemple), identification des « outliers » dans les données. En fonction de l’indice de confiance, on identifie les anomalies potentielles et on les qualifie : elles peuvent concerner une source de données, l’évaluation de l’indice de confiance ou le processus de destruction. En corrigeant chaque anomalie, on va améliorer soit le processus, soit son contrôle. Cette approche peut se voir comme un processus pragmatique d’amélioration continue de la supply chain.
La validité des données, et notamment le fait qu’elles ne puissent pas être modifiées, est une pierre angulaire de cette approche. Si la validité des données pouvait être compromise, aucune amélioration ne serait possible puisque toute analyse pourrait être remise en question suite à une modification des données de base : on ne bâtit pas des fondations sur des sables mouvants.
Faire un pas de côté
Garbage in, garbage out induit la transformation de données en information. La qualité de cette transformation s’analyse à l’aune de l’information que l’on veut obtenir : le in et le out ne sont ni absolus ni indépendants, tout dépend de l’adéquation entre données d’entrée et information recherchées en sortie. Pourtant en conséquence de cet adage, on a tendance à empiler les promesses sur les données d’entrée et leur « véracité », sans adapter l’information recherchée. C’est particulièrement vrai dans différentes approches de blockchain. On peut aussi faire un pas de côté, adopter un autre angle de vue, et s’interroger sur l’information que l’on peut effectivement extraire d’un ensemble de données.
Matthieu HUG, cofondateur et CEO de Tilkal