Maman j’ai perdu les données : data lineage et data observability (épisode 1)

Last updated on 11 avril 2023

Facebook et les données personnelles : un cas révélateur

Cela avait déjà été évoqué en avril ici et cela revient en ce moment par la publication début juillet de la transcription d’audiences (d’août 2020, de janvier 2022 et de mars 2022) rendues publiques entre des ingénieurs de Facebook et un expert mandaté par la magistrate en charge de la plainte de plusieurs personnes en lien avec la récupération de leurs données personnelles auprès de Facebook. En raccourci accrocheur (cf. les différents articles de presse à ce sujet), Facebook n’aurait aucune idée de ce que deviennent les données des personnes dans ses systèmes. D’où potentiellement la difficulté :

A se conformer aux différentes réglementations liées à la protection des données personnelles (répondre aux différents régulateurs)
A fournir de façon exhaustive toutes les données en sa possession pour une personne donnée et de détailler leur circulation (origine, diffusion et accès) avec des tiers parties (répondre à ses utilisateurs).

La lecture de la transcription des échanges entre l’expert et les ingénieurs de Facebook est révélatrice de problématiques data que le contexte Facebook exacerbe mais qui ne lui sont pas propre et que l’on retrouve dans d’autres contextes.

En préambule les échanges transcrits rappelleront à beaucoup de personnes (du S.I. et des métiers), les efforts systématiques de « rétro-engineering » visant à comprendre comment est construit le S.I. en charge des données, comment ces données circulent. Pas un atelier sur un sujet data qui ne commence pas par ces efforts de compréhension, de récupération de documentations, d’appels à des sachants, de dessins/cartographies/schémas préalables au traitement du sujet data (besoin d’exposer des nouvelles données, alimenter un système décisionnel avec les bonnes données, vérifier le respect des règles de péremption du stockage de données, dans le cas de Facebook comment est constitué le service DYI – Download Your Information, etc.).

La lecture détaillée des échanges entre les ingénieurs Facebook et l’expert mériterait un article à elle toute seule sur de nombreux sujets data (comment construire une vue 360° des données d’une personne, rôle des ID des personnes et de leur circulation dans les systèmes, anonymisation, construction du S.I. en silos de données reflet de l’organisation qui les ont construits, duplication des données, rôle et exécution de pipelines de données, gestion des backups, présence des données personnelles dans les logs, dans les caches, gestion des métadonnées, gestion des accès aux données, etc.).

En annexe de cet article vous trouverez quelques extraits de ces échanges qui ont justifié les titres accrocheurs de la presse « Facebook engineers : we have no idea where we keep all your personal data », « Ingénieurs de Facebook : « Nous n’avons aucune idée de l’endroit où nous conservons toutes vos données personnelles » ».

En synthèse quelques éléments en première lecture expliquant cela :

Absence de documentation, voire d’un référentiel des systèmes, a minima en vision globale (d’architecture) et en vision locale : le code est la documentation (voir la justification en annexe !)
Une multiplication et un essaimage des données par construction rendant difficile la maîtrise d’ensemble :
- Une approche par silos de services, ayant chacun leur support de données et leur équipe de développement (55 sous-systèmes, une multitude d’instances de stockage : bases mySQL, dont 500 tables Hive porteuses de données personnelles, des fichiers de traces, des bases analytiques, des bases archives, amenant la dissémination des données et la multiplication de réplicas / de duplications de données)
- Une multitude de points d’échange et de circulation des données avec transformations (plusieurs milliers d’API actives construites par plus de 500 équipes, des millions de pipelines exécutés par jour, des échanges de messages, des changements d’ID – ou assimilés comme l’adresse IP et un timestamp suivant le système concerné)

Tout cela pour introduire rapidement deux « concepts » data : data lineage et data observability.

Le monde de la data n’échappe pas à la réinvention et à la prolifération de concepts. Au travers de ces deux concepts on va reconnaître le besoin de référencer le S.I. (ambition des référentiels de description des systèmes – exemples MEGA mais aussi LeanIX) et de monitorer son fonctionnement.

Ces deux concepts apparaissent comme une réponse de surface (et non structurelle) à la problématique Facebook, à savoir :

Disposer de la documentation descriptive (vision statique) de comment les données circulent dans ses systèmes et qui fait quoi sur ces données : le data lineage,
Et disposer de la vision dynamique de la circulation et du traitement des données dans ses systèmes : la data observability.

Le tout avec l’ambition d’une vision de bout en bout, institutionnelle et non pas limitée à un système, une application donnée.

A suivre dans les épisodes à venir, un zoom sur ces deux concepts (à quoi cela ressemble, est-ce une réponse viable, à quel cout, pour quel ROI … ?).

Annexe

Références :

Je conseille la lecture à partir de la page 83 de la transcription de la séance de janvier 2022 (page 413 du pdf). Ci-après quelques extraits sur le sujet de la documentation (le plus simple à comprendre). A lire également la transcription des échanges à partir de la page 557 du pdf. Pour des sujets techniques, voir par exemple ce qui est dit sur les pipelines de données (plate-forme nommée Dataswarm chez Facebook) « Approximately five million Dataswarm tasks were run on February 15 ».

…

…

…