20 questions fréquemment posées en entretien pour Data Scientist. La data science est un domaine très recherché qui transforme les données produit, client et métier en décisions, expériences, modèles et insights mesurables. Les questions couvrent plusieurs niveaux, et vous pouvez vous entraîner à y répondre à voix haute dans notre simulateur d'entretien.
1How do you explain foundational metrics like conversion rates or statistical significance to non-technical business stakeholders without using technical jargon?
When communicating foundational metrics to non-technical stakeholders, the key is to translate abstract formulas and statistical mechanics into intuitive user stories, decision confidence, and business risk. For conversion rate, rather than presenting a bare ratio or abstract percentage, frame it around concrete user counts: 'Out of every 100 people who landed on the checkout page, 5 completed a purchase.' This grounds the metric directly in observable customer behavior. For statistical significance, avoid formal null hypothesis terminology like alpha levels or rejection regions. Instead, explain it as confidence that an observed uplift is real rather than random noise or lucky timing. For instance: 'A statistically significant result means we are 95% confident this improvement reflects a genuine change in user behavior rather than random fluke. Rolling this out gives us high confidence of a positive outcome instead of reacting to random noise.'
## Experiment Results: New Checkout Flow
- Baseline Conversion: 5.0% (5 out of 100 visitors buy)
- Variant Conversion: 5.8% (5.8 out of 100 visitors buy, a +16% relative lift)
- Decision Confidence: 96% confidence (p = 0.04)
- Business Takeaway: The risk that this lift was just random chance is under 4%. Rolling this out is estimated to bring +$45k in monthly revenue.
2Quelle est la différence conceptuelle entre les jointures inner, left, right et full outer, et comment chaque choix modifie-t-il la population analytique ainsi que la gestion des valeurs NULL dans le calcul des métriques en aval ?
Les jointures inner, left, right et full outer définissent les enregistrements conservés lors de la combinaison de tables sur la base de clés correspondantes :
- Jointure interne (Inner Join) : Ne conserve que les enregistrements pour lesquels la clé de jointure correspond dans les deux tables.
- Jointure externe gauche (Left Outer Join) : Conserve tous les enregistrements de la table de gauche et renseigne les colonnes de la table de droite avec des valeurs NULL lorsqu'il n'y a pas de correspondance.
- Jointure externe droite (Right Outer Join) : Conserve tous les enregistrements de la table de droite et renseigne les colonnes sans correspondance de la table de gauche avec des valeurs NULL.
- Jointure externe complète (Full Outer Join) : Conserve tous les enregistrements des deux tables, en injectant des valeurs NULL d'un côté ou de l'autre en l'absence de correspondance.
Impact sur la population analytique et les métriques en aval :
Le choix de la jointure contrôle directement la cohorte analytique et les dénominateurs utilisés dans le calcul des métriques. Une jointure interne involontaire entre une table d'utilisateurs et une table d'activité/transactions élimine les utilisateurs inactifs, réduisant le dénominateur aux seuls utilisateurs actifs et gonflant artificiellement les taux de conversion ou de rétention. À l'inverse, les jointures externes préservent l'ensemble de la population de référence mais introduisent des valeurs NULL pour les lignes non appariées. Les calculs en aval doivent tenir compte de ces NULL : les agrégations SQL (Structured Query Language) standards telles que `SUM()` ou `AVG()` ignorent les valeurs NULL, `COUNT(colonne)` compte uniquement les entrées non NULL alors que `COUNT(*)` compte toutes les lignes, et les opérations arithmétiques sur des valeurs NULL non traitées (sans `COALESCE`) s'évaluent à NULL.
-- Inner join silently shrinks denominator to purchasers only
SELECT COUNT(o.order_id) * 1.0 / COUNT(u.user_id) AS inner_conv_rate
FROM users u
INNER JOIN orders o ON u.user_id = o.user_id;
-- Left join preserves full user base for accurate metric computation
SELECT COUNT(o.order_id) * 1.0 / COUNT(u.user_id) AS true_conv_rate
FROM users u
LEFT JOIN orders o ON u.user_id = o.user_id;
3In product experimentation, what does randomization achieve that simple before-after comparison usually cannot, and how would you explain the core causal claim an A/B test is designed to support?
In product experimentation, a simple before-after comparison compares metrics across different time periods, which confounds the effect of a feature change with external temporal factors such as seasonality, day-of-week patterns, concurrent marketing campaigns, macro trends, and natural user maturation. Randomization assigns eligible units simultaneously to treatment and control groups, balancing both observed and unobserved confounding variables across groups in expectation. This establishes internal validity. The core causal claim supported by an A/B test relies on counterfactual reasoning: because the control group is subjected to the exact same external conditions over the exact same time window, it serves as an empirical estimate of the counterfactual—what would have happened to the treatment group had they not received the feature. Therefore, any statistically significant difference in outcomes can be causally attributed to the treatment intervention.
# Naive Before-After Comparison:
# Effect_estimate = Metric_t1 (Holiday Launch) - Metric_t0 (Pre-Holiday Baseline)
# Problem: Lift is confounded by holiday shopping surge and marketing spend.
# Randomized A/B Test:
# Effect_estimate = E[Metric_Holiday | Treatment] - E[Metric_Holiday | Control]
# Solution: Both arms experience the exact same external shocks simultaneously.
4Quel est l'objectif habituel de l'analyse exploratoire des données avant la modélisation formelle ou l'expérimentation, et comment distinguer l'EDA (Exploratory Data Analysis) de l'analyse confirmatoire ?
L'EDA (Exploratory Data Analysis) est un processus ouvert visant à comprendre la structure sous-jacente d'un jeu de données, découvrir des tendances, identifier des anomalies ou des problèmes de qualité des données, évaluer les hypothèses distributionnelles et formuler de nouvelles hypothèses avant de construire des modèles statistiques formels ou de mener des expériences. La distinction fondamentale entre l'EDA et l'analyse confirmatoire réside dans leur objectif et leur méthodologie : l'EDA sert à générer des hypothèses, est flexible et exploratoire — s'appuyant sur des statistiques descriptives, des corrélations et des visualisations pour explorer ce que suggèrent les données sans engagements préalables stricts. En revanche, l'analyse confirmatoire (comme les tests d'hypothèses ou l'évaluation de tests A/B) sert à tester des hypothèses, est structurée et inférentielle — conçue pour tester rigoureusement des hypothèses réfutables prédéfinies tout en contrôlant les taux d'erreur statistique (par exemple, l'erreur de type I). Considérer des constats découverts lors de l'EDA comme des conclusions confirmées sur le même jeu de données peut conduire à du dragage de données (p-hacking) et au surapprentissage.
import numpy as np
import pandas as pd
# 1. EDA Phase: Open-ended discovery and hypothesis generation
df = pd.DataFrame({'engagement_score': np.random.normal(50, 10, 1000)})
summary = df['engagement_score'].describe()
# 2. Confirmatory Phase: Testing pre-registered hypothesis on fresh test/experiment data
# (e.g., two-sample t-test with fixed significance level alpha = 0.05)
5Qu'est-ce que la fuite de cible (target leakage) dans un contexte d'apprentissage supervisé, et en quoi diffère-t-elle d'une corrélation forte et légitime entre une variable explicative et la variable cible ?
La fuite de cible (target leakage) se produit lorsqu'une variable explicative incluse dans l'entraînement du modèle contient des informations sur la variable cible qui ne seraient pas légitimement disponibles au moment de l'inférence, lors des prédictions réelles. Cela arrive fréquemment lorsqu'une variable est collectée chronologiquement après l'événement d'intérêt ou constitue une conséquence directe du résultat cible (comme utiliser l'horodatage de résiliation d'un compte ou un identifiant de remboursement pour prédire le désabonnement d'un client). En revanche, une corrélation forte et légitime reflète une relation prédictive ou causale réelle et préexistante, entièrement connue et disponible avant le moment de la prédiction (comme la fréquence de connexion d'un client au cours des 30 derniers jours). Bien que les deux situations se traduisent par une forte importance des variables ou d'excellentes métriques d'évaluation, un modèle affecté par une fuite de cible obtiendra des scores de validation hors ligne irréalistes mais échouera en production car la variable concernée ne peut pas être connue au moment de l'inférence.
# Scenario: Predicting whether a user will cancel their subscription (is_churned)
# LEAKY FEATURE:
# 'cancellation_survey_submitted' -> Occurs after the decision to churn has executed.
# LEGITIMATE FEATURE:
# 'login_count_last_30_days' -> Observed strictly before the prediction cut-off date.
6Quel est l'objectif du partitionnement des données en jeux d'entraînement, de validation et de test, et comment chaque partition doit-elle guider le développement itératif d'un modèle ?
Le partitionnement des données en jeux d'entraînement, de validation et de test permet d'isoler l'ajustement du modèle, le réglage des hyperparamètres et l'évaluation finale afin de garantir la généralisation à des données inédites. - Jeu d'entraînement : Utilisé pour ajuster les paramètres internes du modèle (par exemple, les poids et les biais dans les réseaux de neurones, ou les seuils de division dans les arbres de décision). - Jeu de validation : Utilisé pendant le développement itératif pour la sélection du modèle, le réglage des hyperparamètres, la sélection des variables et la détection du surapprentissage. Il guide les décisions quant à l'architecture ou à la configuration de modèle la plus performante, sans toucher aux données d'évaluation finale. - Jeu de test : Sert d'échantillon strictement réservé représentant les données réelles de production non vues. Il n'est évalué qu'une seule fois à la toute fin du projet pour fournir une estimation non biaisée de l'erreur de généralisation. Réajuster les modèles en fonction des résultats du jeu de test invalide son objectivité et introduit un biais optimiste.
from sklearn.model_selection import train_test_split
from sklearn.datasets import make_classification
X, y = make_classification(n_samples=1000, n_features=10, random_state=42)
# Step 1: Split off final test set (20%)
X_dev, X_test, y_dev, y_test = train_test_split(
X, y, test_size=0.20, random_state=42, stratify=y
)
# Step 2: Split remaining development data into train (75% of dev = 60% total) and validation (25% of dev = 20% total)
X_train, X_val, y_train, y_val = train_test_split(
X_dev, y_dev, test_size=0.25, random_state=42, stratify=y_dev
)
print(f"Train size: {len(X_train)}, Val size: {len(X_val)}, Test size: {len(X_test)}")
7Quelle est la différence entre l'apprentissage supervisé et l'apprentissage non supervisé, et comment la disponibilité des étiquettes ainsi que les objectifs métier déterminent-ils le paradigme à choisir ?
Les algorithmes d'apprentissage supervisé apprennent une fonction mathématique associant des caractéristiques d'entrée (X) à des étiquettes cibles connues (y) à l'aide de données historiques étiquetées afin de prédire des résultats sur de nouvelles observations non observées. L'apprentissage non supervisé analyse des jeux de données ne contenant que des caractéristiques (X) pour découvrir des structures intrinsèques, des regroupements naturels (clustering) ou des représentations réduites sans étiquettes cibles prédéfinies. Le choix entre ces deux paradigmes dépend de la disponibilité des étiquettes et des objectifs métier : si des étiquettes de référence (ground truth) existent ou peuvent être collectées de manière réaliste et que l'objectif métier est une prédiction ciblée (par exemple la détection de fraude, la prédiction d'attrition ou la prévision des prix), l'apprentissage supervisé est approprié. Si les étiquettes de référence n'existent pas, sont trop coûteuses à obtenir ou si l'objectif est une exploration ouverte (par exemple la segmentation client ou la détection d'anomalies sans étiquettes connues), l'apprentissage non supervisé est privilégié.
import numpy as np
from sklearn.linear_model import LogisticRegression
from sklearn.cluster import KMeans
X = np.array([[10, 2], [12, 3], [1, 8], [2, 9]])
y = np.array([0, 0, 1, 1])
# Supervised: Learns mapping X -> y
clf = LogisticRegression().fit(X, y)
# Unsupervised: Discovers clusters directly from X
kmeans = KMeans(n_clusters=2, random_state=42, n_init=10).fit(X)
8Qu'est-ce qu'une North Star Metric (NSM, métrique étoile du Nord) et comment distinguer une North Star efficace d'une métrique de vanité lors de l'évaluation de la santé d'un produit ?
Une North Star Metric (NSM) est la métrique principale qui reflète le mieux la valeur fondamentale qu'un produit apporte à ses clients tout en générant des résultats commerciaux durables (par exemple, le nombre de « nuits réservées » pour Airbnb ou les « heures d'écoute actives hebdomadaires » pour une plateforme musicale). Elle aligne les équipes produit autour de la valeur client à long terme plutôt que d'une croissance superficielle. Pour distinguer une North Star efficace d'une métrique de vanité : 1. Alignement sur la valeur : Une North Star efficace reflète la réelle utilité pour l'utilisateur et un engagement actif, tandis qu'une métrique de vanité mesure un volume superficiel (comme le nombre total d'utilisateurs inscrits, les téléchargements cumulés de l'application ou les pages vues brutes) qui peut croître même si les utilisateurs abandonnent immédiatement le produit. 2. Actionnabilité et corrélation : Une North Star efficace est corrélée à la rétention des utilisateurs, à la santé du produit et à la monétisation, et réagit directement aux améliorations de la qualité du produit. Les métriques de vanité ne peuvent souvent pas être reliées à une véritable rétention ou à la santé de l'activité, et sont sujettes à une inflation artificielle.
Platform: Vacation Rental App
Vanity Metric: Cumulative app downloads (increases continuously even if 95% of users uninstall immediately).
North Star Metric: Nights booked per active user (reflects actual value exchange between guests and hosts).
9Quelle est la distinction pratique entre la dérive des données (data drift) et la dérive de concept (concept drift), et pourquoi est-il essentiel de les catégoriser correctement pour la maintenance d'un modèle après son déploiement ?
La dérive des données (data drift, souvent appelée décalage de covariables ou covariate shift) se produit lorsque la distribution statistique des variables d'entrée P(X) évolue au fil du temps, alors que la relation conditionnelle entre les entrées et la cible P(Y|X) reste inchangée. En revanche, la dérive de concept (concept drift) survient lorsque la relation sous-jacente entre les entrées et la cible P(Y|X) change, ce qui signifie que des valeurs de variables d'entrée identiques correspondent désormais à des comportements ou résultats cibles différents. Les catégoriser correctement est crucial pour la maintenance post-déploiement, car leurs stratégies de remédiation diffèrent fondamentalement. En présence de data drift, les tendances historiques restent valides ; la maintenance se concentre sur l'élargissement de la couverture d'apprentissage sur les nouvelles zones de caractéristiques, la mise à jour du prétraitement ou l'application d'une repondération des échantillons. Avec le concept drift, les étiquettes historiques ne reflètent plus la réalité du terrain ; la maintenance nécessite de collecter de nouvelles données étiquetées, d'écarter les exemples historiques obsolètes et de réentraîner ou reconcevoir le modèle.
# Data Drift (Covariate Shift):
# User demographics or devices change (P(X) shifts),
# but genuine vs fraudulent transaction patterns remain identical (P(Y|X) unchanged).
# Concept Drift:
# Fraudsters adapt tactics to mimic normal shopping patterns;
# identical feature inputs now have a higher probability of fraud (P(Y|X) shifts).
10Quelle est la différence entre un paramètre de population et une statistique d'échantillon, et quel est l'impact de la variabilité d'échantillonnage sur l'interprétation des métriques ?
Un paramètre de population est une caractéristique numérique fixe, généralement inconnue, d'une population entière (comme la vraie moyenne de la population μ ou la proportion p). Une statistique d'échantillon est un résumé numérique calculé à partir de données d'échantillon observées (comme la moyenne d'échantillon x̄ ou la proportion d'échantillon p̂), utilisé pour estimer le paramètre inconnu. La variabilité d'échantillonnage désigne la variation naturelle des statistiques d'échantillon entre différents échantillons aléatoires prélevés dans la même population. En raison de cette variabilité d'échantillonnage, toute métrique issue d'un seul échantillon est soumise à une erreur aléatoire et correspond rarement exactement au véritable paramètre de population. Lors de l'interprétation des métriques, ne pas prendre en compte cette variabilité conduit à confondre du bruit statistique avec une réelle évolution. Les analystes doivent quantifier l'incertitude d'estimation à l'aide d'erreurs types, d'intervalles de confiance ou de tests d'hypothèses avant de conclure qu'une différence observée est réelle.
import numpy as np
# True population parameter (mean = 50, standard deviation = 10)
pop_mean = 50.0
pop_std = 10.0
# Draw multiple independent samples of size n=30
np.random.seed(42)
sample_means = [np.mean(np.random.normal(pop_mean, pop_std, size=30)) for _ in range(5)]
for i, sm in enumerate(sample_means, 1):
print(f"Sample {i} Mean (Statistic): {sm:.2f} | Error: {sm - pop_mean:+.2f}")
11Une partie prenante pose une question ambiguë telle que « La fonctionnalité Y fonctionne-t-elle ? ». Comment reformulez-vous cette demande dans un cadre d'analyse mesurable et exploitable pour la prise de décision ?
Lorsqu'une partie prenante demande « La fonctionnalité Y fonctionne-t-elle ? », je commence par déconstruire l'intention sous-jacente : quel problème la fonctionnalité Y devait-elle résoudre, à qui s'adresse-t-elle, et quelle décision découlera de la réponse (ex. itérer, déployer à plus grande échelle ou déprécier) ?
J'établis ensuite un cadre de mesure à plusieurs niveaux comprenant :
1. **Adoption et engagement :** Les utilisateurs cibles découvrent-ils et utilisent-ils la fonctionnalité comme prévu ?
2. **Valeur directe / Succès de la tâche :** Les utilisateurs mènent-ils à bien le workflow principal permis par la fonctionnalité ?
3. **Impact business en aval :** L'adoption de la fonctionnalité est-elle corrélée à des indicateurs clés globaux (rétention, conversion, chiffre d'affaires) ou les améliore-t-elle ?
4. **Indicateurs de garde-fous (guardrails) :** La fonctionnalité a-t-elle généré des effets secondaires indésirables (augmentation de la latence, hausse des tickets de support, cannibalisation) ?
Enfin, je définis en amont avec la partie prenante les seuils de décision et les critères d'évaluation avant de lancer l'analyse, ce qui garantit un alignement sur ce qui constitue un succès et évite tout déplacement rétrospectif des objectifs.
Feature: Quick Checkout Button
1. Primary Decision: Keep & expand vs. Redesign vs. Deprecate
2. Evaluation Metrics:
- Adoption: % of checkout sessions clicking the quick button (Target: >= 15%)
- Funnel Completion: Checkout completion rate given button click (Target: >= 75%)
- Business Metric: Overall cart conversion lift (Target: +1.5% in A/B test)
- Guardrail: Support tickets for accidental purchases (Threshold: < 0.2% increase)
3. Pre-agreed Action Plan:
- If Target Met: Roll out to 100% and promote to mobile app.
- If Adoption Low but Completion High: Retain, optimize UI discovery.
- If Guardrail Exceeded: Halt rollout, add confirmation step.
12Lors de la préparation d'un jeu de données contenant d'importantes valeurs manquantes, comment choisissez-vous entre l'analyse des cas complets, l'imputation simple, l'ajout d'indicateurs de données manquantes et l'imputation par modèle ?
Le choix d'une stratégie pour les données manquantes dépend principalement du mécanisme de disparition (MCAR, MAR, MNAR), de la proportion de données manquantes, du cas d'usage final (inférence statistique vs modélisation prédictive) et du risque de biais :
1. **Analyse des cas complets (suppression de lignes) :** Appropriée uniquement lorsque les données sont manquantes de manière totalement aléatoire (MCAR, Missing Completely at Random) et que la proportion manquante est faible (ex. < 5 %). Si les données sont manquantes de manière aléatoire (MAR, Missing at Random) ou non aléatoire (MNAR, Missing Not at Random), supprimer des lignes introduit un biais de sélection sévère et réduit la puissance statistique de l'échantillon.
2. **Imputation simple (moyenne/médiane/mode) :** Rapide et pratique pour des modèles prédictifs de référence (baseline), mais risquée pour l'analyse statistique car elle réduit artificiellement la variance des variables, gonfle les statistiques de test et fausse les structures de covariance.
3. **Indicateurs de données manquantes (imputation + indicateur binaire) :** Idéal pour la modélisation prédictive (notamment les algorithmes basés sur des arbres) et les situations où l'absence de valeur est informative (MNAR, comme des champs optionnels non renseignés). Cela préserve le signal apporté par l'absence sans altérer les distributions numériques valides.
4. **Imputation par modèle (KNN, MICE, IterativeImputer) :** Préférée lorsque les données sont MAR, que les corrélations entre variables sont fortes et qu'il est crucial de préserver les relations multivariées ou les erreurs types des paramètres (ex. dans l'inférence par régression). Ses inconvénients sont la complexité de calcul, la charge d'implémentation dans les pipelines de production et le risque de fuite de données (data leakage) si le modèle n'est pas strictement ajusté sur les plis d'entraînement.
from sklearn.impute import SimpleImputer
import pandas as pd
df = pd.DataFrame({'income': [50000, None, 75000, None, 120000]})
# Impute median while tracking missingness pattern
imputer = SimpleImputer(strategy='median', add_indicator=True)
imputed_data = imputer.fit_transform(df)
# Returns: [income_imputed, income_is_missing]
13Une équipe produit compare les utilisateurs ayant volontairement activé une nouvelle fonctionnalité à ceux qui ne l'ont pas fait, et observe un taux de rétention supérieur de 20 %. Comment diagnostiqueriez-vous le biais de sélection et les facteurs de confusion, et comment repenseriez-vous l'évaluation ?
Comparer les utilisateurs ayant volontairement activé une fonctionnalité aux non-utilisateurs introduit un biais d'auto-sélection et des facteurs de confusion (*confounding*). Les utilisateurs qui choisissent d'adopter une nouveauté présentent généralement une intention, un engagement ou une aisance technique plus élevés dès le départ. L'écart de 20 % observé sur la rétention confond donc l'effet causal réel de la fonctionnalité avec la motivation préexistante des utilisateurs.
**Diagnostic du biais :**
1. **Comparaison des covariables pré-traitement :** Comparez les caractéristiques de base entre les deux cohortes avant l'introduction de la fonctionnalité (ex. activité historique, rétention passée, ancienneté, fréquence des transactions, types d'appareils). Des différences significatives confirment la présence de facteurs de confusion.
2. **Vérification des tendances préalables et tests placebo :** Vérifiez si les utilisateurs ayant activé la fonctionnalité présentaient déjà une rétention ou un engagement plus élevés lors des périodes antérieures au lancement.
**Repenser l'évaluation :**
- **Expérimentation aléatoire (standard de référence) :** Mettez en place une incitation randomisée (*Randomized Encouragement Design*) ou un déploiement progressif aléatoire. Tous les utilisateurs éligibles sont assignés aléatoirement au groupe Traitement (exposition/proposition de la fonctionnalité) ou au groupe Contrôle (non exposés). Analysez les résultats en intention de traiter (ITT, Intention-to-Treat) pour mesurer l'impact global de la proposition, puis utilisez les variables instrumentales / doubles moindres carrés (2SLS, Two-Stage Least Squares) avec l'assignation comme instrument pour estimer l'effet moyen du traitement sur les utilisateurs actifs (LATE, Local Average Treatment Effect).
- **Approches quasi-expérimentales (si la randomisation est impossible) :** Utilisez l'appariement sur score de propension (PSM, Propensity Score Matching), les doubles différences (DiD, Difference-in-Differences) ou le contrôle synthétique afin d'ajuster les facteurs de confusion observables et de contrôler les tendances préexistantes.
import statsmodels.formula.api as smf
import pandas as pd
# df columns: ['user_id', 'post_period', 'opted_in', 'retained']
# Interaction term captures causal lift above baseline group differences
model = smf.ols('retained ~ opted_in + post_period + opted_in:post_period', data=df).fit()
print(model.summary().tables[1])
14Comment concevriez-vous les découpages de cohortes pour une analyse d'activation ou de rétention afin de vous assurer que les comparaisons ne soient pas biaisées par des effets de mix (mix shifts) ou la troncature de maturité (maturity truncation) ?
Pour concevoir des découpages de cohortes évitant les effets de mix et la troncature de maturité : 1. **Standardiser les fenêtres d'ancienneté** : Alignez les cohortes selon une ancienneté relative (par exemple, Jour 0, Jour 7, Jour 30 après l'inscription ou l'activation) plutôt que par dates calendaires pour garantir des comparaisons équitables sur le cycle de vie. 2. **Gérer la troncature de maturité (censure à droite)** : N'évaluez que les cohortes ayant atteint leur pleine maturité sur la fenêtre d'observation. Excluez ou signalez explicitement les cohortes récentes qui n'ont pas disposé de la durée complète pour franchir l'étape clé. 3. **Atténuer les effets de mix** : Segmentez les cohortes selon les dimensions de confusion influentes (telles que le canal d'acquisition, la plateforme, le pays ou l'intention de l'utilisateur). Si vous rapportez un chiffre agrégé, utilisez une pondération par standardisation ou post-stratification afin que les variations dans la composition des sources d'acquisition ne faussent pas la tendance de rétention observée.
WITH user_cohorts AS (
SELECT
user_id,
DATE_TRUNC('week', signup_time) AS cohort_week,
signup_time,
acquisition_channel
FROM users
-- Exclude cohorts that have not reached 7 full days of maturity
WHERE signup_time <= CURRENT_DATE - INTERVAL '7 days'
),
user_activity AS (
SELECT DISTINCT
c.user_id,
c.cohort_week,
c.acquisition_channel,
1 AS retained_d7
FROM user_cohorts c
JOIN events e ON c.user_id = e.user_id
WHERE e.event_time >= c.signup_time + INTERVAL '7 days'
AND e.event_time < c.signup_time + INTERVAL '8 days'
)
SELECT
c.cohort_week,
c.acquisition_channel,
COUNT(c.user_id) AS cohort_size,
COUNT(a.user_id) AS d7_active_users,
ROUND(100.0 * COUNT(a.user_id) / COUNT(c.user_id), 2) AS d7_retention_pct
FROM user_cohorts c
LEFT JOIN user_activity a ON c.user_id = a.user_id
GROUP BY 1, 2
ORDER BY 1 DESC, 2;
15Lors de l'évaluation, votre modèle atteint une métrique anormalement élevée comme une AUC (Area Under the Curve) de 0,99, mais les performances s'effondrent lors des tests en miroir (shadow testing). Comment isolez-vous et vérifiez-vous systématiquement une fuite de cible (target leakage) ?
Lorsqu'un modèle obtient une métrique hors ligne irréaliste (ex. AUC de 0,99) qui s'effondre en conditions réelles lors de tests en miroir (shadow testing), la fuite de cible (target leakage) est la cause principale à suspecter. Un workflow systématique d'isolation et de vérification comprend :
1. **Importance et attribution des variables (features) :** Calculez les valeurs SHAP, les gains d'importance ou l'importance par permutation afin d'identifier les variables candidates présentant un pouvoir prédictif disproportionné.
2. **Modèles à variable unique et études d'ablation :** Entraînez des modèles simples à une seule variable (ex. arbres de décision peu profonds ou régression logistique) sur chaque variable suspecte. Si une variable unique permet une classification quasi parfaite, elle contient très probablement une fuite de la cible. Supprimez séquentiellement les variables suspectes (ablation) et mesurez la baisse de performance hors ligne.
3. **Audit de traçabilité temporelle et horodatages :** Vérifiez les horodatages exacts de création et de mise à jour des variables candidates par rapport à l'horodatage de coupure (cutoff) de la prédiction. Vérifiez si la valeur de la variable ne pouvait être connue qu'après la survenue de l'événement cible (ex. `cancellation_reason` ou `refund_status` renseignés uniquement lors d'un désabonnement ou d'un rejet de débit).
4. **Vérification de la traçabilité des données (data lineage) et du pipeline :** Examinez le pipeline de données en amont et la logique de mutation des tables (ex. tables modifiables mises à jour sur place vs journaux immuables en ajout seul) pour vérifier à quel moment précis les champs sont alimentés.
from sklearn.metrics import roc_auc_score
from sklearn.tree import DecisionTreeClassifier
leakage_candidates = {}
for col in X_train.columns:
clf = DecisionTreeClassifier(max_depth=2)
clf.fit(X_train[[col]], y_train)
preds = clf.predict_proba(X_test[[col]])[:, 1]
auc = roc_auc_score(y_test, preds)
if auc > 0.85:
leakage_candidates[col] = auc
print("Candidate Leaky Features:", leakage_candidates)
16Comment choisissez-vous entre la validation croisée K-Fold standard, K-Fold stratifiée (Stratified K-Fold) et K-Fold par groupe (Group K-Fold) lors de l'évaluation de données structurées réelles ?
Le choix entre K-Fold standard, Stratified K-Fold et Group K-Fold dépend de la distribution de la variable cible et de l'indépendance des observations (lignes) :
1. **K-Fold standard** : Divise aléatoirement les données en K blocs (folds) de taille égale. Cette méthode suppose que les observations sont indépendantes et identiquement distribuées (IID, Independent and Identically Distributed) et est généralement utilisée pour des cibles de régression continues ou des jeux de données bien équilibrés.
2. **Stratified K-Fold** : Garantit que chaque bloc conserve la même proportion de classes cibles que l'ensemble du jeu de données. Elle est essentielle pour les tâches de classification, en particulier en présence de classes déséquilibrées, afin d'éviter que certains blocs ne contiennent trop peu ou aucun échantillon de la classe minoritaire.
3. **Group K-Fold** : Garantit que des groupes ou entités distincts (par exemple `user_id`, `patient_id`, `device_id`) n'apparaissent pas simultanément dans les blocs d'entraînement et de validation. Lorsque plusieurs observations proviennent de la même entité, un découpage standard provoque une fuite de données (data leakage) importante, car le modèle mémorise les caractéristiques propres à l'entité au lieu d'apprendre des signaux généralisables. Group K-Fold permet d'évaluer la capacité du modèle à généraliser à des entités totalement inconnues.
17Comment choisir entre la régression logistique, les arbres de décision boostés par gradient (GBDT, Gradient Boosted Decision Trees) et les architectures neuronales non linéaires pour la classification de données tabulaires sous des contraintes de latence et de dérive ?
Le choix entre la régression logistique (LR), les arbres de décision boostés par gradient (GBDT) et les réseaux de neurones (NN) pour la classification tabulaire implique d'arbitrer entre pouvoir prédictif, budget de latence d'inférence, explicabilité et résilience à la dérive des données (data drift).
1. **Régression logistique** : Idéale pour les environnements à très faible latence (<1-5 ms au 99e percentile) et aux budgets de calcul très restreints. Le calcul de score étant un simple produit scalaire, elle est extrêmement rapide et robuste. Face à une dérive des covariables ou à des valeurs hors distribution, les modèles linéaires extrapolent de manière monotone, ce qui peut être prévisible ou dangereux selon la régularisation des pentes, mais ils produisent rarement des comportements erratiques par paliers. Cependant, la LR nécessite une ingénierie des variables (feature engineering) manuelle et poussée (interactions, discrétisation non linéaire) pour rivaliser avec les modèles non linéaires.
2. **GBDT (ex. : XGBoost, LightGBM, CatBoost)** : La référence standard de l'industrie pour les données tabulaires. Ils capturent nativement les interactions non linéaires complexes et gèrent parfaitement les types de données mixtes et les valeurs manquantes. Côté latence, les GBDT optimisés (ou compilés via Treelite/ONNX) respectent facilement des SLA inférieurs à 10 ms. Face à la dérive, les GBDT ne peuvent pas extrapoler au-delà des bornes observées à l'entraînement (les prédictions sont plafonnées sur les feuilles extrêmes), ce qui constitue un garde-fou contre les extrapolations aberrantes mais risque de figer des prédictions si la distribution des variables évolue fortement.
3. **Architectures neuronales (ex. : FT-Transformer, TabNet, MLP)** : À privilégier lorsque les données tabulaires sont multimodales (associées à du texte, des embeddings ou des images) ou dans des contextes d'apprentissage continu en ligne. Cependant, les réseaux de neurones tabulaires purs ont généralement des latences d'inférence plus élevées (nécessitant des multiplications matricielles multicouches ou une accélération GPU), sont plus coûteux à entraîner et restent très sensibles aux entrées non normalisées ainsi qu'à la dérive des covariables.
**En pratique** : Commencez avec un GBDT comme référence de performance ; si des latences de l'ordre de la microseconde ou une explicabilité stricte sont requises, déployez une régression logistique ; réservez les réseaux de neurones aux architectures multimodales ou au transfert d'embeddings.
decision_matrix = {
"Logistic Regression": {"Latency": "<1ms (Ultra-low)", "Drift Behavior": "Linear extrapolation", "Tabular Baseline": "Moderate (needs feature engineering)"},
"GBDT (XGB/LightGBM)": {"Latency": "1-15ms (Fast)", "Drift Behavior": "Leaf clamping (no extrapolation)", "Tabular Baseline": "State of the Art"},
"Tabular Neural Net": {"Latency": "10-50ms+ (Higher)", "Drift Behavior": "Nonlinear extrapolation", "Tabular Baseline": "Competitive / High tuning cost"}
}
for model, traits in decision_matrix.items():
print(f"{model}: Latency={traits['Latency']}, Tabular Perf={traits['Tabular Baseline']}")
18La direction doit décider du lancement ou non d'une fonctionnalité majeure à l'échelle nationale dans un contexte ambigu, caractérisé par des résultats d'expérimentation régionaux mitigés et des fenêtres de lancement fixes. Comment concevez-vous le cadre de recommandation stratégique ?
Pour concevoir une recommandation stratégique face à des résultats d'expérimentation régionaux mitigés et des fenêtres de lancement fixes, il convient de découpler la décision d'un simple choix binaire go/no-go. Tout d'abord, décomposez les résultats agrégés en effets de traitement hétérogènes selon les segments de marché, les cohortes de clients et les environnements d'exploitation afin d'isoler les contextes où la fonctionnalité réussit, stagne ou génère des effets néfastes. Ensuite, concevez une stratégie de déploiement progressif avec couverture du risque (comme un déploiement échelonné par région ou des déploiements canary) qui privilégie les segments à forte confiance tout en isolant le risque extrême négatif. Troisièmement, établissez des métriques de garde-fou explicites et prédéfinies ainsi que des disjoncteurs automatisés ou des seuils de retour arrière pour limiter le risque résiduel le plus défavorable. Enfin, structurez la communication auprès de la direction autour de la valeur attendue, de l'asymétrie du risque de baisse par rapport au coût commercial de manquer la fenêtre fixe, et de plans d'action opérationnels pour pivoter en cours de route.
| Rollout Tier | Target Markets | Launch Exposure | Guardrail Circuit-Breaker | Expected Value / Risk Profile |
|---|---|---|---|---|
| Tier 1: Immediate Launch | Cohorts with stat-sig positive lift (e.g., Regions A, C) | 100% | Rollback if 48h conversion drops > 1.5% | High upside; verified market fit |
| Tier 2: Phased Staging | High-variance / neutral cohorts (e.g., Region B) | 10% -> 25% -> 50% over 14 days | Hold expansion if CSAT drops > 2.0% | Moderate upside; bounded downside |
| Tier 3: Hold & Re-test | Stat-sig negative cohorts (e.g., Region D) | 0% (Holdout / internal testing) | Launch blocked until root-cause resolution | Eliminates primary churn risk |
19Comment concevriez-vous l'architecture d'une couche sémantique centralisée sur un entrepôt de données d'entreprise pour garantir des définitions cohérentes des métriques métier entre différentes équipes d'analytique ?
L'architecture d'une couche sémantique centralisée sur un entrepôt de données d'entreprise nécessite la mise en place d'une couche de définition de métriques déclarative et basée sur le code (comme MetricFlow/dbt Semantic Layer, Cube ou LookML), qui découple la logique métier du stockage physique et des outils de consommation en aval (plateformes de BI, notebooks Python/R, API). L'architecture centrale définit les entités, dimensions, mesures et métriques dérivées dans des dépôts versionnés (Git) afin de fournir une source unique de vérité et d'imposer la cohérence des métriques entre les équipes. Pour prendre en charge le multi-tenant et la gouvernance entre des unités opérationnelles disparates, un modèle de gouvernance fédéré doit être utilisé : les KPI d'entreprise fondamentaux (par exemple, ARR, utilisateurs actifs) sont détenus par une équipe centrale de gouvernance des données, tandis que les métriques spécifiques à un domaine sont gérées par des équipes de domaine décentralisées via des modèles sémantiques isolés avec validation CI/CD. La couche sémantique expose ensuite des interfaces de requête standardisées (SQL, GraphQL, REST) avec un contrôle d'accès unifié basé sur les rôles ainsi que de la mise en cache/pré-agrégation pour maintenir les performances et la cohérence.
semantic_model:
name: orders
node_relation:
alias: fct_orders
dimensions:
- name: order_date
type: time
type_params:
time_granularity: day
- name: country
type: categorical
measures:
- name: total_revenue
expr: revenue_usd
agg: sum
- name: distinct_buyers
expr: user_id
agg: count_distinct
metrics:
- name: average_order_value
description: "Governed metric for AOV across all BI tools"
type: ratio
type_params:
numerator: total_revenue
denominator: distinct_buyers
20Dans une place de marché biface (comme le covoiturage/VTC ou l'e-commerce), comment concevriez-vous une expérience pour évaluer une modification de l'algorithme d'appariement tout en tenant compte de la cannibalisation de l'offre et de la demande ainsi que des interférences spatio-temporelles ?
Dans les places de marché bifaces, l'évaluation des algorithmes d'appariement à l'aide de tests A/B classiques au niveau des utilisateurs enfreint l'hypothèse SUTVA (Stable Unit Treatment Value Assumption). Lorsque les unités de traitement consomment des ressources partagées rares (comme des chauffeurs ou des stocks), elles cannibalisent les unités de contrôle, ce qui entraîne une dégradation artificielle du groupe de contrôle et des effets de traitement surestimés en raison des déplacements de l'équilibre du marché. Pour remédier aux interférences spatiales et temporelles, nous utilisons deux architectures expérimentales principales : la randomisation par grappes (clusters) et les expériences switchback. Dans la randomisation spatiale par grappes, des marchés géographiques ou des sous-régions isolées (par exemple, des zones métropolitaines distinctes ou des cellules spatiales hexagonales partitionnées par graphe) sont assignés de manière aléatoire au traitement ou au contrôle. Cela isole les interactions directes entre l'offre et la demande, bien que cela nécessite des méthodes telles que les contrôles synthétiques ou les doubles différences (difference-in-differences) pour gérer l'hétérogénéité entre marchés. Dans les expériences switchback (par tranches temporelles), des marchés entiers isolés alternent entre les algorithmes de traitement et de contrôle sur des fenêtres temporelles discrètes (par exemple, en alternant toutes les 1 à 2 heures). Les switchbacks maintiennent un équilibre global offre-demande au sein de chaque fenêtre, mais introduisent un biais de rémanence temporelle (carryover bias). Pour atténuer ce biais dans les switchbacks, nous introduisons des périodes tampons de transition ou de purge (washout periods) entre les fenêtres (en ignorant les commandes lors des transitions d'état) et sélectionnons des durées de fenêtre suffisamment longues pour absorber le repositionnement de l'offre tout en restant assez courtes pour préserver la puissance statistique. L'analyse doit prendre en compte les erreurs de séries temporelles corrélées en regroupant les erreurs-types au niveau du bloc temporel/marché ou en utilisant des équations d'estimation généralisées (GEE) / des estimateurs de variance de Newey-West.
import pandas as pd
import numpy as np
def generate_switchback_schedule(n_days=14, window_minutes=60, washout_minutes=15):
total_windows = int((n_days * 24 * 60) / window_minutes)
np.random.seed(42)
treatments = np.random.binomial(1, 0.5, size=total_windows)
schedule = []
for i, trt in enumerate(treatments):
start_min = i * window_minutes
eval_start_min = start_min + washout_minutes
end_min = (i + 1) * window_minutes
schedule.append({
'window_id': i,
'treatment': trt,
'start_min': start_min,
'eval_start_min': eval_start_min,
'end_min': end_min
})
return pd.DataFrame(schedule)