Les ingénieurs de données ne sont pas des catalogues

Les ingénieurs de données ne sont pas des catalogues

Vos données n'ont jamais été aussi accessibles. Et vos analystes n'ont jamais autant deviné.

Il est peu probable que vous trouviez « répondre à quinze messages Teams par semaine pour savoir quelle table utiliser dans ce rapport-là » dans une description de poste d'analyste ou de développeur. Pourtant, ça se passe tous les jours. Les analystes ne sont pas des clairvoyants. Ils ont besoin de données fiables pour faire leur travail et doivent s'abreuver à la bonne source.

Ce décalage-là entre la disponibilité des données et le catalogage n'arrive pas par hasard. C'est le sous-produit de trois pressions en même temps : aller plus vite, décentraliser la donnée par domaine d'affaires ou par département, et bâtir des plateformes de données de plus en plus libre-service.

Le syndrome du V6_Final_RealFinal

Les professionnels de bureau connaissent ça depuis des décennies. Une belle analyse part en circulation. Vingt personnes la reprennent, la retouchent, l'adaptent à leur auditoire. Six mois plus tard, il reste seulement un écho de l'intention de départ, et le fichier qui fait autorité se nomme V6_Final_RealFinal.

La même chose se produit en gestion de données. Tout le monde essaie de bien faire — supporter ses clients internes, sortir des analyses, intégrer de nouvelles sources —, mais tout le monde va vite pour respecter les échéanciers. Un matin, vous levez la tête et vous avez six modèles de données (tables, vues, modèles sémantiques, etc.) quasi identiques, et plus personne ne sait lequel est à jour, ni quel champ utiliser.

Les coûts en pratique sont réels :

• du temps passé à aiguiller les gens vers la bonne source, encore et encore

• une qualité de données qui se dégrade progressivement

• du temps gaspillé à réparer des analyses bâties sur les mauvaises tables

• une confiance qui s'érode dans toute l'organisation

• des bugs et du temps d'indisponibilité de données en hausse

Quand la confiance diminue, les organisations compensent en élargissant leurs marges d'erreur dans leurs prévisions. C'est un réflexe compréhensible, mais coûteux : en période d'incertitude sur la demande et les chaînes d'approvisionnement, une prévision imprécise coûte cher en inventaire, en arrêts de production et en occasions manquées.

×

À gauche, ce qui circule et ce que ça coûte. À droite, la même source publiée une seule fois — avec un nom, un SLA et des responsables.

Concrètement, dans votre entreprise, ça ressemble à quoi ?

Prenez le fichier Excel de suivi de production que trois superviseurs tiennent en parallèle, chacun avec une définition un peu différente d'une heure facturable. La conséquence concrète, c'est que les chiffres de production diffèrent selon le système qu'on interroge : système de pesée, rapport de quart, ERP. On se retrouve avec des coûts de projet qui ne balancent pas entre les rapports de chantier et ce qui a été facturé au client. Pensez aussi au bon de commande qui existe dans le système d'approvisionnement, mais dont personne n'est certain où trouver la version finale approuvée.

Dans une PME de 200 employés, il est rare qu'une personne porte le titre de gestionnaire de données. Au final, ce sont plusieurs personnes différentes qui deviennent le catalogue de données humain de l'entreprise. Bien qu'inefficace, ça fonctionne. Par contre, quand ces personnes quittent l'entreprise ou partent en vacances, c'est là que les vrais problèmes font surface.

Il faut regarder le bon côté des choses : à cette échelle-là, pas besoin d'un gros programme de gouvernance qui prend trois ans à implanter. On a simplement besoin de quelques sources de données validées et officiellement certifiées. C'est l'essentiel du catalogue de données : un répertoire central et accessible qui contient la liste des tables et des sources de données officielles, prêtes à être intégrées dans un rapport, dans un fichier Excel ou interrogées directement à l'aide d'une requête SQL.

Ce qui ramène la question centrale : à mesure que la donnée devient accessible, comment un consommateur en aval sait-il ce qui a été préparé, transformé et approuvé ? Comment s'assurer qu'une base commune de standards, de propriété et de communication tient debout d'un bout à l'autre de l'organisation ?

Pour bien des équipes, la réponse s'appelle la certification.

Certifier ses données

La certification, c'est le processus par lequel une source de données est approuvée pour usage dans toute l'organisation, après avoir satisfait des SLA convenus mutuellement sur la qualité, l'observabilité, la propriété, la résolution d'incidents et la communication.

Comme la validation ou la vérification, elle superpose des processus qui alignent les personnes, les cadres et la technologie sur les politiques d'affaires. Les exigences varient selon les besoins du métier, la capacité de l'équipe et la disponibilité des données, mais on y retrouve généralement : des tests automatisés de fraîcheur, de volume, de schéma et de distribution ; des SLA de livraison avec un taux de disponibilité défini ; des propriétaires imputables des alertes ; un routage automatique des alertes vers Teams ou des boîtes courriel ; et un processus de communication fixé d'avance en cas de panne.

Sept étapes pour bien positionner l'entreprise

Un bon programme de certification doit pouvoir grandir naturellement avec l'entreprise et le volume de données. Pour y arriver, il doit appliquer la même approche gagnante à travers chaque domaine d'affaires. Voici les sept règles de base qui sous-tendent une pratique de certification de données solide et pérenne dans le temps.

1. Commencer avec l'observabilité. Impossible de certifier ce qu'on ne voit pas. Ça prend une base de référence sur la performance actuelle, plus une approche systémique de bout en bout pour détecter, alerter et trier les événements. En général, un tableau de bord d'incidents fait remonter automatiquement les anomalies, les changements de schéma, les tables supprimées et autres bris. Quand quelque chose casse dans le pipeline (ça va casser, promis), vous le savez avant même que les consommateurs des données s'en rendent compte.

2. Nommer des propriétaires. Chaque source de données certifiée doit avoir une personne responsable de son cycle de vie en entier, de l'ingestion jusqu'à la couche analytique. Les outils modernes de métadonnées permettent d'assigner un propriétaire directement sur la table, à côté des autres étiquettes. L'implémentation concrète peut varier selon les besoins et les outils disponibles. Certaines équipes déploient une matrice RACI entière ; d'autres se contentent de nommer le propriétaire dans des procédures écrites.

3. Définir ce que « bon » veut dire. En posant à vos parties prenantes les questions qui, quoi, quand, où et pourquoi, vous découvrez ce que la qualité veut dire pour eux et quelles données comptent vraiment. De là sortent des indicateurs concrets : fraîcheur (« rafraîchi avant 8 h, tous les jours »), distribution (« cette colonne-là ne doit jamais être vide »), volume, schéma, temps d'arrêt, vitesse de requête, etc. C'est aussi ce qui permet de configurer des alertes utiles, calibrées sur ce qui compte pour l'entreprise.

4. Écrire des SLA spécifiques. « Avoir des données fiables en tout temps » est trop vague pour être utile. Un bon SLA est précis et détaillé : il documente pourquoi c'est important pour chaque domaine ou métier, quelles sont les attentes, quand elles doivent être satisfaites, comment, où vit la donnée et qui sont les parties prenantes. Il détermine également une marche à suivre claire en cas d'échec. « La table X est rafraîchie tous les jours avant 8 h » devient : « L'équipe Z garantit le rafraîchissement avant 8 h. Dans les deux heures suivant une alerte d'anomalie, elle vérifie, communique aux parties touchées et amorce l'analyse de la cause racine. En moins d'un jour ouvrable, un billet est créé et l'équipe est informée de la progression. »

Notez que ça comprend deux promesses différentes, et il faut les séparer. La première, c'est la cible : les données sont rafraîchies à 8 h. La deuxième, c'est la fréquence à laquelle vous la tenez : 99 % du temps, ce qui signifie concrètement qu'on se permet de rater le rafraîchissement environ trois matins par année.

Nul besoin de commencer en essayant de tout couvrir. Commencez avec les cinq tables ou sources de données les plus utilisées.

5. Formaliser la communication et la gestion d'incidents. Qui reçoit les alertes ? Comment les prochaines étapes sont-elles communiquées, à l'interne comme à l'externe ? Ça peut sembler élémentaire, mais une communication claire et transparente, c'est la fondation d'une culture d'imputabilité. Bien des équipes tiennent alertes et triage dans Teams ou Slack. Ça permet une coordination rapide et une visibilité complète pour l'équipe élargie. Prévoyez aussi le cas de la panne majeure — qui annonce quoi au reste de l'entreprise, où, et à quelle fréquence.

6. Choisir le mécanisme d'étiquetage. Vous avez maintenant des SLA mesurables, de la transparence, des processus de communication et des attentes claires de résolution. Il reste maintenant à rendre disponibles les sources de données approuvées. L'entreprise doit décider une fois pour toutes ce que « approuvé » veut dire : les engagements, le responsable nommé, le délai de réponse. Ensuite, c'est chaque département qui décide lesquelles de ses tables méritent l'étiquette. Personne n'a à faire approuver sa décision par un comité.

Le marquage lui-même n'a pas besoin d'être sophistiqué. Ça peut être une étiquette dans votre outil de rapports, un préfixe dans le nom de la table, ou une simple page SharePoint qui liste les tables approuvées avec le nom du responsable à côté. Ce qui compte, c'est que la personne qui utilise les données puisse savoir qu'elles sont certifiées sans avoir à demander.

7. Former les équipes et les consommateurs. L'étiquette n'est pas magique en soi. Quelqu'un va inévitablement continuer d'ouvrir l'ancienne table, parce qu'elle est dans ses favoris depuis deux ans, ou parce qu'elle contient une colonne que la nouvelle table n'a pas, ou parce que son rapport fonctionne déjà et qu'il n'a pas envie de le refaire. Ce sont de bonnes raisons. Écoutez-les : souvent, il manque quelque chose à la table approuvée. Quand il ne manque rien, dites-le clairement — celle-là, on l'abandonne, et voici la date.

Assurez-vous également d'ajuster le volume d'alertes. Recevoir de temps en temps une alerte qui ne demande aucune action, c'est normal. Ce ne sont pas toutes les alertes qui indiquent un réel problème. Il y aura toujours une composante de bruit à gérer.

Cela dit, les alertes peuvent rapidement causer une fatigue si elles comportent trop de bruit. Si l'équipe commence à les ignorer, c'est le signe qu'il faut les resserrer ou séparer les canaux pour que seul l'important ressorte.

Et avec les gens qui utilisent vos données, ne soyez pas gênés. Vous venez de bâtir quelque chose de solide pour eux. Aidez-les à passer du « j'ai l'impression que les chiffres sont croches » à quelque chose de mesurable. Donnez-leur les mots pour faire partie de la solution.

×

Les sept étapes d'un programme de certification, en trois temps : voir et nommer, convenir, opérer et diffuser.

Le résultat

Lorsque les sept étapes sont bien exécutées, c'est beau à voir aller. L'ingénieur étiquette la table comme certifiée, y attache son propriétaire, l'expose dans l'entrepôt de données. L'analyste la prend et l'utilise dans son tableau de bord. Les questions et le temps d'indisponibilité sont minimisés.

Ce qu'il faut surtout retenir, c'est qu'en l'absence des bons processus et d'une bonne culture de données, certifier la fiabilité et bâtir la confiance dans l'organisation devient extrêmement difficile. Bien qu'elle aide sérieusement, la technologie ne remplacera jamais une bonne hygiène de données ou une bonne culture de gouvernance.

Les premiers pas commencent rarement par un gros outil ou une plateforme technologique super sophistiquée. Ça commence par choisir les cinq tables qui comptent vraiment pour l'entreprise et leur assigner une étiquette de qualité.

Adapté des idées du livre Data Quality Fundamentals (Barr Moses, Lior Gavish et Molly Vorwerck, O'Reilly, 2022).