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 distinction pratique faites-vous entre dérive des données et dérive du concept, et pourquoi importe-t-elle pour maintenir un modèle après lancement ?
La dérive des entrées est un changement de P(X). Le décalage pur des covariables suppose en plus P(Y|X) inchangé ; constater le premier ne prouve pas cette hypothèse. La dérive du concept modifie au contraire la relation P(Y|X), donc les mêmes valeurs de variables correspondent désormais à d'autres comportements ou résultats. Les deux peuvent coexister et demander des réponses différentes. Sous un décalage pur des covariables, les relations conditionnelles historiques restent valides là où le support existe ; on élargit la couverture d'entraînement, ajuste le prétraitement ou repondère les observations. Avec dérive du concept, certaines relations historiques perdent leur pertinence. Examiner les étiquettes récentes et segments concernés avant de choisir repondération, réentraînement, refonte ou changement de politique. Une dérive n'implique pas automatiquement une perte de performance significative.
# 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.
12Face à beaucoup de valeurs manquantes, comment choisissez-vous cas complets, imputation simple, indicateurs d'absence ou imputation par modèle ?
Choisir selon la quantité cible à estimer, mécanisme, couverture et déploiement ; l'observé seul ne prouve généralement pas un mécanisme d'absence aléatoire conditionnellement aux données observées (MAR) plutôt qu'un mécanisme non aléatoire (MNAR). Les cas complets sont valides sous absence complètement aléatoire (MCAR) et certaines hypothèses plus faibles spécifiques, avec perte de précision, sans seuil universel de cinq pour cent. Moyenne/médiane/mode servent de référence prédictive mais déforment variance et covariance, pas de solution générale d'inférence. Les indicateurs aident si le manque informe, sans corriger MNAR ni préserver la distribution. Ajuster tous les procédures d'imputation dans les plis d'entraînement et vérifier stabilité en production. Pour inférence sous MAR plausible, utiliser imputation multiple bien spécifiée avec plusieurs tirages et incertitude combinée. Une imputation par les k plus proches voisins (KNN) ou une imputation itérative unique ne donne pas automatiquement d'erreurs-types valides ; IterativeImputer scikit-learn produit une seule imputation par défaut. Tester sensibilité MNAR et publier hypothèses sans présenter l'imputé comme observé.
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]
13Les utilisateurs ayant volontairement activé une nouveauté ont une rétention supérieure de 20 %. Comment diagnostiquez-vous sélection/confusion et repensez-vous l'évaluation ?
Le choix d'adopter dépend souvent d'intention, engagement ou aisance technique : l'écart mélange effet et motivation préalable. Comparer activité, rétention, ancienneté, transactions et appareils prétraitement ; les différences soutiennent la sélection, mais doivent être liées à l'issue pour établir un chemin de confusion précis. Examiner aussi tendances et placebos avant lancement. Préférer encouragement randomisé ou déploiement aléatoire : l'analyse en intention de traiter (ITT) estime l'effet de l'offre. Une analyse par variable instrumentale (IV) utilisant les moindres carrés en deux étapes (2SLS), avec l'affectation comme instrument, estime l'effet moyen local du traitement (LATE) chez les utilisateurs dont l'adoption change grâce à cette affectation, pas tous les adopteurs, sous pertinence, exclusion d'effet direct du prompt, monotonie et non-interférence adaptées. Sans randomisation, envisager l'appariement sur score de propension (PSM), les différences de différences (DiD) ou contrôle synthétique pour les confusions observées et tendances préexistantes parallèles sous leurs hypothèses.
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 K-fold standard, stratifié et par groupes pour des données réelles structurées ?
Selon distribution cible et indépendance. Le standard répartit en plis approximativement égaux ; scikit-learn KFold ne mélange pas par défaut, l'activer si approprié. Il vise des observations indépendantes et identiquement distribuées (IID), souvent régression ou données équilibrées. Le stratifié garde les proportions de classes pour éviter trop peu ou aucune minoritaire. Group K-fold empêche user_id, patient_id ou device_id de figurer dans entraînement et validation à la fois. Un partage par ligne d'entités répétées donne une estimation optimiste pour de nouvelles entités en mémorisant leurs particularités. Group K-fold mesure cette généralisation. Pour le futur d'entités connues, choisir la chronologie de ce déploiement ; combiner temps et groupes si les deux s'imposent.
17Comment choisissez-vous régression logistique, arbres boostés ou réseaux non linéaires pour du tabulaire sous contraintes de latence et dérive ?
Comparer sur validations temporelles/groupées représentatives et matériel réel. La logistique score peu cher et donne des coefficients transparents mais demande encodages/interactions adaptés ; elle peut extrapoler avec confiance à tort sous dérive. Les arbres de décision à renforcement de gradient (GBDT) fonctionnent souvent bien, mais catégories et manquants natifs dépendent de l'implémentation. Les feuilles constantes extrapolent mal hors support, sans garantie de sécurité. Les réseaux aident pour multimodal, représentations vectorielles ou volume suffisant, avec latence/dérive dépendant de l'architecture. Comparer les latences aux 95e et 99e percentiles (p95/p99) de bout en bout, y compris la récupération des variables, calibration, mémoire, maintenance, segments et robustesse. Aucune famille ne garantit universellement la milliseconde ni la résistance à la dérive.
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)