Alimenter : ETL, qualité, RGPD

Le chapitre précédent a construit un modèle cible. Il reste à le remplir, à partir de systèmes qui n'ont pas été conçus pour être lus par d'autres, qui changent sans prévenir, et dont les données contiennent des erreurs que personne n'a jamais eu besoin de corriger jusqu'ici.

Extraire, transformer, charger

Ce qui se fait à chaque étape, et ce qui ne s'y fait pas. À l'extraction, ne rien transformer. La tentation est forte de filtrer ou de convertir au passage, puisque c'est gratuit. C'est une erreur : une transformation faite ici n'est pas rejouable sans redemander la source, et l'erreur qu'elle introduit devient invisible et irrattrapable.

À la transformation, tout rendre explicite. Chaque règle de gestion appliquée doit être une opération nommée, testable et documentée. Une règle enfouie dans une requête de chargement finit par n'être connue de personne.

Au chargement, ne rien décider. Le chargement écrit ce qu'on lui donne. Toute logique métier qui s'y trouve est invisible depuis l'entrepôt et depuis les sources à la fois.

Extraire sans tout relire

Relire intégralement une source à chaque alimentation devient impossible dès que le volume grandit, et pèse sur un système de production qui a autre chose à faire.

Trois stratégies, de la plus simple à la plus juste. Extraction complète. Tout est relu à chaque fois. Simple, fiable, et acceptable jusqu'à quelques millions de lignes. Elle voit les suppressions par construction : une ligne absente de l'extraction a disparu de la source.

Extraction incrémentale. Seules les lignes dont la date de modification dépasse la dernière extraction sont relues. Efficace, et fragile : elle rate toute ligne supprimée, toute ligne modifiée sans que la date le soit, et les états intermédiaires d'une ligne modifiée deux fois entre deux passages.

Capture des changements. Le journal des transactions de la source est lu, ce qui donne chaque insertion, modification et suppression dans l'ordre, sans requête sur les tables. Parmi les stratégies qui ne relisent pas tout, c'est la seule qui voie les suppressions et chaque version d'une ligne. Elle pèse peu sur la source, mais suppose d'avoir accès à son journal, et que celui-ci soit conservé assez longtemps pour être lu.

Charger de façon rejouable

Une alimentation échoue. Le réseau coupe, la source répond mal, une machine redémarre. La question n'est pas d'éviter ces incidents mais de pouvoir relancer sans rien casser.

Alimenter un modèle dimensionnel

L'ordre n'est pas indifférent, et il découle des clés étrangères.

Les dimensions d'abord, les faits ensuite, toujours. Charger ou mettre à jour les dimensions. Chaque ligne source est rapprochée de la dimension par sa clé naturelle. Si elle est nouvelle, une ligne est créée avec une clé de substitution. Si elle a changé, on écrase ou on historise selon la décision prise au chapitre précédent.

Charger les faits. Chaque fait remplace ses clés naturelles par les clés de substitution des dimensions, obtenues par une recherche. Ce remplacement s'appelle la résolution des clés, et c'est l'opération la plus coûteuse de l'alimentation.

Charger les faits avant les dimensions produit des faits qui pointent vers des lignes inexistantes.

La figure suivante confronte les ventes du jour à la dimension client, au moment de résoudre les clés. Deux ventes n'y trouvent personne : l'une porte un code que le référentiel ignore, l'autre n'en porte aucun.

SELECT *
FROM Vente_Jour
INNER JOIN Dim_Client
  ON Vente_Jour.codeClient = Dim_Client.codeClient

Le bloc suivant alimente une table de faits à partir d'une source qui ne connaît que les codes produits : la dimension existe déjà, les faits résolvent leurs clés, et le jour est chargé par remplacement.

Qualifier un jeu de données

Avant d'exploiter des données, il faut savoir ce qu'elles valent. Cela se mesure, et un petit nombre de critères suffit.

La complétude compte les valeurs absentes, elle ne dit pas lesquelles. Supprimer les lignes incomplètes, ou remplacer chaque valeur manquante par la moyenne des valeurs connues, ne fausse rien quand le manque frappe au hasard. Dès que la probabilité qu'une valeur manque dépend de la valeur elle-même, les deux remèdes faussent la mesure, et dans le même sens. Un terminal de livraison qui, la plupart du temps, n'enregistre pas le délai d'une livraison de plus de deux heures perd précisément les retards : les lignes qui restent décrivent un service plus rapide que le vrai.

Les lignes complètes donnent un délai moyen de 76,3 minutes et 4,7 % de livraisons de plus de deux heures, quand la réalité est de 94,7 minutes et 17,9 %. Remplacer les manques par la moyenne n'arrange rien : la moyenne reste à 76,3, puisque c'est elle qui a été recopiée, et la part des retards tombe à 3,9 %, les 350 lignes complétées étant toutes rangées sous les deux heures. Perdre autant de lignes au hasard, en revanche, ne déplace presque rien : 94,8 minutes et 18,0 %. Ce n'est pas le nombre des manques qui fausse la mesure, c'est leur cause.

Aucun calcul sur les seules valeurs connues ne révèle ce biais, puisque les valeurs qui le montreraient sont celles qui manquent. Il se cherche dans la façon dont le manque se produit : la part des délais absents selon une colonne toujours renseignée, la distance ou le livreur par exemple, ou un échantillon de livraisons suivi par un autre moyen, comme pour l'exactitude. Un rapport de qualité donne donc la part des manques et l'hypothèse faite sur leur cause, pas un taux de complétude seul.

Alimenter une base NoSQL

Charger une base de documents ou une base clé-valeur reprend les trois étapes, mais la transformation change de nature. Il ne s'agit plus de ranger chaque fait à sa place dans des tables : il faut construire, à partir de sources normalisées, l'objet que l'accès prévu lira d'un coup, la commande avec ses lignes et le libellé de ses produits, comme dans le chapitre sur les familles NoSQL. La transformation est une dénormalisation, décidée par les accès et non par les tables sources.

Le chargement, lui, se simplifie. Sans clé étrangère, aucun ordre n'est imposé entre ce qui décrit et ce qui est décrit. Et l'écriture se fait par clé : un document déjà présent est remplacé, jamais doublé, ce qui rend le chargement idempotent sans autre précaution, à condition que la clé se calcule toujours de la même façon à partir de la source.

Deux chargements par clé laissent deux documents ; la même alimentation faite par ajout en laisse quatre, et la commande 17 existe alors en deux exemplaires. Le prix est recopié au moment du chargement : une correction ultérieure du catalogue ne le touchera pas, et c'est voulu, puisque c'est le prix payé.

Les données personnelles

Le RGPD pose à son article 5 six principes, et y ajoute la responsabilité : le responsable du traitement doit être en mesure de démontrer qu'il les respecte. Deux des six, la minimisation et la limitation de la conservation, ont des conséquences techniques immédiates.

Licéité, loyauté, transparence. Un traitement n'est licite que s'il repose sur l'une des six bases de l'article 6 : le consentement de la personne, l'exécution d'un contrat auquel elle est partie, une obligation légale, la sauvegarde des intérêts vitaux d'une personne, une mission d'intérêt public, ou l'intérêt légitime du responsable ou d'un tiers. Les personnes concernées doivent être informées du traitement.

Limitation des finalités. Les données sont collectées pour des finalités déterminées, explicites et légitimes, et ne sont pas traitées ensuite d'une manière incompatible avec elles. Un traitement ultérieur à des fins statistiques ou de recherche n'est pas réputé incompatible, à condition d'appliquer les garanties de l'article 89.

Minimisation. Seules les données adéquates, pertinentes et nécessaires à la finalité sont traitées. Cela contredit frontalement le réflexe du domaine, qui est de tout garder au cas où.

Exactitude. Les données inexactes sont effacées ou rectifiées sans tarder.

Limitation de la conservation. Les données ne restent sous une forme identifiante que le temps nécessaire à la finalité. À l'échéance, elles sont effacées ou anonymisées, y compris dans les sauvegardes et les copies dérivées : extractions, tables de l'entrepôt, fichiers du lac. Une conservation plus longue n'est admise qu'à des fins d'archivage dans l'intérêt public, de recherche ou de statistique, avec les garanties de l'article 89.

Intégrité et confidentialité. Une sécurité appropriée : chiffrement, contrôle d'accès, traçabilité des accès.

La responsabilité, enfin, se prouve par écrit. Le registre des activités de traitement (article 30) indique pour chaque traitement sa finalité, les catégories de personnes et de données concernées, leurs destinataires et, autant que possible, le délai prévu pour leur effacement.

Ce que le règlement impose à une architecture de données. Les données sensibles. Les données qui révèlent l'origine raciale ou ethnique, les opinions politiques, les convictions religieuses ou philosophiques ou l'appartenance syndicale, les données génétiques, les données biométriques servant à identifier une personne, et celles qui concernent la santé, la vie sexuelle ou l'orientation sexuelle forment des catégories particulières : leur traitement est interdit par principe (article 9), sauf dans les cas que l'article énumère, comme le consentement explicite de la personne.

L'analyse d'impact. Un traitement susceptible d'engendrer un risque élevé pour les personnes exige, avant sa mise en œuvre, une analyse d'impact relative à la protection des données (article 35). Le règlement la requiert en particulier pour le traitement à grande échelle de catégories particulières, et pour la surveillance systématique à grande échelle d'un lieu accessible au public : un lac qui conserve les images des caméras de toutes les stations d'un réseau de transport en relève.

Les droits des personnes. Chacun peut demander l'accès à ses données (article 15), leur rectification (article 16), leur effacement (article 17), la limitation de leur traitement (article 18), la portabilité de celles qu'il a fournies (article 20), et s'opposer à certains traitements (article 21). Une demande d'effacement doit atteindre toutes les copies, ce qui suppose de savoir où chaque donnée a été recopiée : le catalogue du lac et la traçabilité des alimentations servent aussi à cela.

Les sanctions. Méconnaître les principes, les bases légales, les règles des données sensibles ou les droits des personnes expose à une amende pouvant atteindre 20 millions d'euros ou, pour une entreprise, 4 % de son chiffre d'affaires annuel mondial, le montant le plus élevé étant retenu ; manquer aux obligations de sécurité (article 32) ou d'analyse d'impact, jusqu'à 10 millions d'euros ou 2 % (article 83). En France, la loi Informatique et Libertés du 6 janvier 1978 modifiée complète le règlement, et la CNIL en contrôle l'application.

Mesurer le risque de réidentification

La généralisation réduit le risque, et détruit de l'information. Le bloc montre l'effet de chaque élargissement : retirer le mois, remplacer le code postal par le département, l'année par une tranche. La part des personnes seules de leur combinaison passe de près des trois quarts à 2 %, puis à zéro, et k, la taille du plus petit groupe, monte de 1 à 21, puis à 211.

C'est la mécanique du k-anonymat : exiger que chaque combinaison de quasi-identifiants soit partagée par au moins k personnes. Un jeu où k vaut 1 n'est pas anonyme, quel qu'ait été le soin apporté à retirer les noms. La réciproque est fausse : un k élevé empêche seulement d'isoler une personne. Les autorités de protection européennes demandent deux choses de plus avant de parler d'anonymat : qu'on ne puisse pas relier le jeu à un autre pour retrouver quelqu'un, et qu'on ne puisse pas en déduire, de façon quasi certaine, une information sur une personne. Isoler, relier, déduire : un jeu n'est anonyme que s'il résiste aux trois.

Et c'est aussi la limite de l'exercice. Chaque généralisation supprime de l'information réelle : une analyse par tranche de dix ans ne répond plus aux questions qui portaient sur l'année. L'anonymisation n'est pas gratuite, elle s'achète en précision.

Mettre en pratique

Une alimentation se juge sur deux nombres : le volume qu'elle déplace à chaque exécution, et la part de données qu'elle laisse passer sans les qualifier.

La dernière question n'a pas de piège de calcul, elle a un piège de lecture : le lot est déjà sous le seuil, à 98 %. Aucune ligne supplémentaire n'est nécessaire pour le faire basculer, il l'est avant même qu'on ait commencé à compter. Un critère de qualité ne sert à rien s'il n'est pas confronté à la mesure avant le chargement.