Questions d'entretien Gestionnaire de données

Je commence par un périmètre restreint et à forte valeur plutôt que d'essayer de tout gouverner d'un coup. J'identifie les trois ou quatre jeux de données qui pèsent le plus sur les décisions importantes, en général les données clients, revenus et usage produit, et je construis la gouvernance autour d'eux en premier : propriété claire, définition partagée de chaque métrique clé, et un dictionnaire de données tenu à jour dans la durée plutôt que rédigé une fois puis oublié. J'anime un court groupe de travail avec les propriétaires métier de chaque jeu de données pour que les règles reflètent l'usage réel, pas seulement ce qui paraît propre sur le papier. J'évite volontairement un document de politique lourd que personne ne lit. Je préfère intégrer les règles dans les outils déjà utilisés, comme des conventions de nommage appliquées dans l'entrepôt de données et des contrôles de validation dans le pipeline d'ingestion. Je traite ce cadre comme quelque chose de vivant : je le révise chaque trimestre et je retire les règles qui se sont révélées inutiles.

Je commence par confirmer l'ampleur de l'erreur avant de dire quoi que ce soit : quels chiffres sont faux, de combien, et quelles décisions ont pu s'appuyer dessus. J'ai constaté qu'une alerte rapide mais vague fait plus de dégâts qu'une alerte légèrement plus lente mais précise. Une fois les faits établis, j'informe directement le propriétaire du rapport et les destinataires de la direction, avec les chiffres corrigés et une explication claire de la cause racine, pas seulement des excuses. Dans un cas, un tableau de bord de churn comptait deux fois les comptes réactivés, gonflant le taux de rétention d'environ 6 points sur deux trimestres. J'ai remonté jusqu'à une condition de jointure qui ne tenait pas compte des comptes churnés puis revenus sur la même période, corrigé la requête, ajouté un contrôle de réconciliation avec le système de facturation, et informé la direction à la fois de la correction et de la mesure prise pour éviter que cela ne se reproduise silencieusement.

Je commence par établir quel système fait autorité pour chaque champ, car vouloir rendre chaque système également autoritaire est précisément ce qui crée des doublons. Pour l'identité client, je désigne généralement le CRM comme référence pour les données de contact et de relation, et le système comptable comme référence pour les données de facturation et d'entité juridique, puis je construis une clé de correspondance, souvent une combinaison du numéro d'immatriculation et du nom normalisé, pour relier les fiches entre les deux systèmes. Je lance un dédoublonnage sur un calendrier régulier, pas une seule fois, car de nouveaux doublons apparaissent chaque fois que quelqu'un saisit manuellement un client sans vérifier au préalable. Pour les cas que la correspondance automatique ne peut pas résoudre avec confiance, je les envoie à un relecteur humain avec les deux fiches candidates côte à côte plutôt que de les fusionner automatiquement, car une fusion automatique erronée est plus difficile à défaire qu'une correspondance manquée.

Je suis un petit nombre d'indicateurs concrets plutôt qu'un score de maturité unique, car un score unique tend à masquer où se trouvent les problèmes. Je regarde le nombre d'incidents qualité par mois et si cette tendance baisse, le pourcentage de jeux de données critiques avec un propriétaire nommé et une définition à jour, le temps nécessaire pour répondre à une nouvelle demande de données, car un délai long signifie souvent que les gens ne font pas assez confiance aux données existantes pour se servir seuls, et la fréquence à laquelle la même question est posée deux fois parce que la réponse n'a été documentée nulle part de facilement trouvable. Je prête aussi attention à un signal plus subtil : est-ce que les gens en réunion citent directement les chiffres du tableau de bord, ou les recalculent discrètement dans un tableur au préalable, car cette habitude est le signe le plus clair que la confiance dans les données n'a pas encore été gagnée.

Un responsable des opérations commerciales voulait charger directement une liste de contacts achetée dans le CRM avant le lancement d'une campagne, en sautant l'étape habituelle de validation et de dédoublonnage pour tenir un délai fixé à vendredi. Je n'ai pas simplement refusé. J'ai expliqué le risque précis : la liste n'avait fait l'objet d'aucune vérification par rapport à notre liste de suppression existante, donc nous risquions de contacter des personnes ayant déjà refusé les communications, ce qui est un vrai problème de conformité, pas seulement une question de propreté des données. J'ai proposé une version compressée du processus de validation, environ quatre heures au lieu des deux jours habituels, en ne lançant que les contrôles liés à un risque légal réel et en reportant le nettoyage cosmétique. La campagne a été lancée avec environ une demi-journée de retard sur le plan initial. Par la suite, le responsable m'a demandé de faire de ce parcours compressé une option standard pour les campagnes urgentes, ce qui est aujourd'hui documenté comme notre processus de revue accéléré.

J'ai managé une équipe de trois data stewards, chacun responsable d'un domaine métier différent : clients, produit et finance. J'ai vite remarqué que l'un d'eux était excellent en documentation technique mais évitait les conversations avec les parties prenantes nécessaires pour résoudre les conflits de propriété des données, ce qui laissait les problèmes de son domaine non résolus plus longtemps que les autres. Plutôt que de contourner le problème, je l'ai associé au steward le plus à l'aise avec ces conversations pour une session commune sur un conflit précis, puis je l'ai laissé mener la suivante seul, sous mon observation. En deux mois, il menait ces conversations en autonomie. Je tiens des points individuels mensuels centrés spécifiquement sur ce qui bloque leur domaine, pas des mises à jour générales, car c'est là que mon aide compte le plus, et j'ai constaté que les blocages précis et actuels se résolvent bien plus vite que ce qui est soulevé dans un point d'équipe général.

Un prestataire externe avait reçu un accès à une base de données clients plus large que ce que son projet exigeait, et nous l'avons découvert lors d'une revue d'accès de routine, trois semaines après l'octroi de l'accès, sans preuve d'utilisation abusive. J'ai traité ce cas avec la même rigueur qu'un incident réel : j'ai documenté la chronologie, révoqué l'accès excédentaire immédiatement, et travaillé avec l'IT pour confirmer, via les journaux et les exports, qu'aucune donnée n'était sortie du système. La cause racine était qu'un seul responsable approuvait les demandes d'accès sans second contrôle sur le principe du moindre privilège. J'ai introduit une validation à deux personnes pour tout accès au-delà de la simple lecture, et ajouté une revue d'accès trimestrielle spécifique aux prestataires plutôt que de l'intégrer à la revue annuelle générale, car les accès des prestataires changent bien plus souvent que ceux des employés.

Je pars des flux de données concrets, pas du texte réglementaire, car les manquements à la conformité surviennent généralement dans un processus que personne n'a cartographié plutôt que dans une politique que personne n'a écrite. Je tiens un registre des activités de traitement qui liste quelles données personnelles nous détenons, pourquoi, où elles sont stockées et qui peut y accéder, et je le mets à jour dès qu'un nouveau système ou une nouvelle intégration est ajouté, pas seulement une fois par an. Pour les demandes de droit d'accès ou de suppression, j'ai construit une checklist couvrant chaque système contenant des données personnelles, y compris ceux qu'on oublie facilement, comme les sauvegardes et les outils analytiques tiers, car une suppression techniquement correcte dans la base principale qui laisse des données dans un ancien export reste un manquement. Je fais aussi passer une revue de confidentialité légère avant l'intégration de tout nouvel outil ou fournisseur, en vérifiant leur accord de traitement des données et où ils stockent les données, plutôt que de laisser cela uniquement au service juridique.

Je recherche trois choses : la facilité avec laquelle des utilisateurs non techniques peuvent chercher et comprendre un jeu de données sans solliciter quelqu'un de l'équipe data, la qualité du suivi de la traçabilité pour pouvoir remonter un chiffre d'un rapport jusqu'à ses tables sources, et la charge de maintenance manuelle requise, car un catalogue nécessitant un étiquetage manuel constant tend à devenir obsolète en quelques mois. J'ai utilisé Collibra, ainsi qu'une configuration open source plus légère construite sur la documentation et le graphe de traçabilité de dbt pour une équipe plus réduite qui n'avait pas besoin des fonctionnalités complètes de gouvernance. Cette configuration légère fonctionnait mieux pour cette équipe précisément parce que l'adoption dépendait du fait que l'outil soit presque invisible : les ingénieurs documentaient les choses dans le cadre de leur travail habituel plutôt que comme une tâche de gouvernance séparée, ce qui maintenait la documentation à jour de façon constante.

Je raisonne en termes de risque et de coût du retard plutôt que de traiter la gouvernance comme intrinsèquement secondaire par rapport à l'infrastructure, ce qui est l'hypothèse par défaut dans beaucoup d'organisations. Une panne de pipeline qui bloque un rapport quotidien est visible et urgente, mais une faille de gouvernance, comme un jeu de données non documenté alimentant un rapport réglementaire, peut coûter tout aussi cher si elle apparaît lors d'un audit, elle est simplement moins visible au quotidien. Je travaille avec le responsable data engineering pour noter les deux types de travaux sur la même échelle : impact business si rien n'est fait, et effort nécessaire, puis je séquence le backlog ensemble plutôt que de laisser gouvernance et engineering gérer deux listes concurrentes séparées. Quand les deux entrent en conflit direct pour la même capacité de sprint, je privilégie celui dont l'échec serait le plus difficile à expliquer après coup à un régulateur ou à un dirigeant, ce qui rend l'arbitrage concret plutôt qu'abstrait.