Questions d'entretien Analyste de données

Je commence par comprendre la question business derrière la demande, pas seulement la question de données. Souvent ce que quelqu'un demande et ce dont il a vraiment besoin sont légèrement différents, et une courte conversation en amont évite beaucoup de reprises. Une fois que je comprends l'objectif, je clarifie le périmètre : quelle période, quels segments, quel niveau de précision est nécessaire. Ensuite j'explore les données avant de construire quoi que ce soit, en vérifiant les nulls, les doublons, les valeurs aberrantes et les distributions inattendues. Je construis l'analyse de façon incrémentale, en validant les résultats intermédiaires. Avant de présenter les conclusions, je me demande : si c'est exact, que devons-nous faire ? Je présente les résultats dans le format le plus simple qui soutient la décision.

Je commence par le résultat, pas la méthode. Les parties prenantes veulent savoir ce que disent les données et ce qu'il faut faire : elles n'ont pas besoin de comprendre la logique JOIN qui m'y a conduit. Je structure les présentations avec une conclusion principale, deux ou trois points de soutien et une recommandation claire. J'utilise des graphiques simples plutôt que des tableaux dans la mesure du possible, car les visualisations permettent de saisir les relations instantanément. Je traduis aussi les métriques en langage business : au lieu de "le taux de rétention à 30 jours a baissé de 4 points de pourcentage", je dis "nous avons perdu environ 400 clients ce mois que nous aurions conservés le mois dernier".

Ma première hypothèse est que j'ai commis une erreur, pas que les données me disent quelque chose de surprenant. Je reviens vérifier la logique de la requête, les filtres appliqués, les plages de dates et si la table sous-jacente a des problèmes de qualité de données connus. Je cherche aussi une version plus simple de la même question : si je supprime une variable à la fois, le résultat semble-t-il toujours incorrect ? Si le résultat tient après cette vérification, je cherche des facteurs externes qui pourraient l'expliquer. Ce n'est qu'après avoir éliminé les erreurs et trouvé une explication plausible que je présente le résultat, en signalant qu'il était inattendu et en décrivant les vérifications effectuées.

L'IA a changé ma façon de gérer plusieurs parties de mon flux de travail. Pour SQL, je l'utilise pour générer des premières ébauches de requêtes complexes avec des jointures ou des fonctions fenêtre : elle obtient généralement la structure correcte, bien que je vérifie toujours la logique attentivement avant d'exécuter quoi que ce soit sur des données de production. Pour les scripts Python, je décris ce dont j'ai besoin et j'obtiens un point de départ fonctionnel en secondes. Pour présenter les résultats, j'utilise l'IA pour aider à rédiger le commentaire qui accompagne les graphiques : avec les chiffres et le contexte, elle génère des options pour raconter l'histoire que je façonne ensuite. Je la trouve aussi utile pour les tâches de nettoyage de données où la logique est claire mais le code est fastidieux. Là où je ne m'y fie pas, c'est pour l'interprétation finale : le rôle de l'analyste est de comprendre quels patterns comptent vraiment pour le business, et cela nécessite un contexte que le modèle n'a pas. Je ne mets jamais non plus de données sensibles ou propriétaires dans des interfaces IA grand public.

On m'a demandé d'enquêter sur la baisse du taux de conversion trial vers payant sur deux trimestres. J'ai construit une analyse de funnel segmentée par canal d'acquisition et constaté que la conversion depuis la recherche payante avait chuté fortement, tandis que la conversion organique était stable. En creusant, j'ai découvert que la recherche payante amenait des utilisateurs avec des titres de poste très différents de notre ICP principal. Le coût par acquisition avait baissé, mais la qualité aussi. J'ai présenté cela à l'équipe growth avec une recommandation d'ajouter un signal d'intention au ciblage. Ils l'ont testé et la conversion a retrouvé ses niveaux précédents en six semaines.

J'ai hérité d'un dataset de reporting legacy construit en fusionnant trois tables sources avec des schémas d'ID incohérents. Environ 12 % des lignes avaient des valeurs nulles dans une colonne de jointure clé, et il y avait des événements en double causés par un bug de logging. Plutôt que d'ignorer les problèmes, je les ai documentés, estimé l'impact de chacun sur les métriques nécessaires, et fait des choix explicites sur la façon de traiter chaque cas. J'ai aussi signalé les problèmes de qualité à l'équipe engineering, ce qui a conduit à une correction dans le pipeline. Chaque analyse produite depuis ce dataset incluait une note sur la qualité des données.

En construisant un rapport hebdomadaire de routine, j'ai remarqué que les utilisateurs mobiles complétaient notre flux principal à environ la moitié du taux des utilisateurs desktop. Personne ne m'avait demandé de regarder cela. J'ai réalisé une analyse de cohorte rapide et constaté que l'écart s'était élargi sur les huit semaines précédentes, coïncidant avec une refonte de la navigation sur mobile uniquement. J'ai signalé cela au chef de produit avec les données et une hypothèse. Le correctif ultérieur a amélioré les taux de complétion mobile de 28 %.

C'est une agrégation simple, mais je clarifie toujours quelques points : "chiffre d'affaires" signifie-t-il brut ou net ? Incluons-nous les commandes remboursées ? Le filtre de date est-il sur la date de commande ou de paiement ? En supposant une table orders avec customer_id, order_date et revenue, la requête serait : SELECT customer_id, SUM(revenue) AS total_revenue FROM orders WHERE order_date >= CURRENT_DATE - INTERVAL '90 days' GROUP BY customer_id ORDER BY total_revenue DESC LIMIT 5. En pratique, je vérifierais aussi les valeurs de chiffre d'affaires négatives (remboursements) et joindrais une table clients pour obtenir le nom pour la lisibilité.

Ma première étape est de comprendre si une valeur aberrante est une erreur de données ou une vraie valeur extrême, car le traitement est différent. Pour la détection, j'utilise l'inspection visuelle (scatter plots, box plots), des méthodes statistiques (valeurs au-delà de 3 écarts-types, ou limites basées sur l'IQR) et des vérifications de connaissance métier. Une fois identifiées, les erreurs de données sont corrigées ou exclues avec une note ; les vraies valeurs extrêmes sont généralement conservées mais traitées avec soin. Pour les statistiques descriptives, je rapporte souvent la médiane en plus de la moyenne quand il y a des valeurs aberrantes significatives, car la moyenne peut être fortement distordue.

Un inner join retourne uniquement les lignes qui ont des valeurs correspondantes dans les deux tables. Un left join retourne toutes les lignes de la table gauche et les lignes correspondantes de la table droite : là où il n'y a pas de correspondance, les colonnes de droite sont null. J'utilise un inner join quand je ne m'intéresse qu'aux enregistrements existant dans les deux tables. J'utilise un left join quand je dois conserver tous les enregistrements de la table principale : par exemple, joindre les utilisateurs aux commandes pour trouver les utilisateurs qui n'ont jamais passé de commande. Une erreur courante est d'utiliser un inner join quand un left join est nécessaire, ce qui supprime silencieusement des enregistrements et peut fausser les métriques.