Data Scientist Questions d'entretien & Réponses

Exemple de réponse

Notre équipe marketing dépensait 200 000 € par mois pour l'acquisition d'utilisateurs sur 5 canaux, sans vision claire du ROI par canal. J'ai construit un modèle d'attribution multi-touch basé sur les chaînes de Markov, en analysant 6 mois de données sur les parcours utilisateurs. L'analyse a révélé qu'un canal représentant 30 % des dépenses ne contribuait qu'à 8 % des conversions, tandis que la recherche organique était sous-évaluée d'un facteur 3. J'ai présenté les résultats au directeur marketing avec des visualisations claires. Il a réalloué 60 000 € mensuels depuis le canal sous-performant, ce qui a augmenté le taux de conversion global de 22 % au cours du trimestre suivant.

Exemple de réponse

J'avais construit un modèle de segmentation client qui recommandait de supprimer un niveau d'un programme de fidélité. La vice-présidente de la réussite client a fermement rejeté cette idée : ces clients étaient ses ambassadeurs les plus engagés. Au lieu de défendre le modèle de façon abstraite, j'ai approfondi l'analyse et découvert qu'elle avait en partie raison : ces clients affichaient un NPS élevé mais une contribution au chiffre d'affaires faible. J'ai révisé l'analyse pour intégrer des projections de valeur vie client et des revenus de parrainage liés au bouche-à-oreille. Le modèle mis à jour montrait que ce niveau valait la peine d'être conservé, mais qu'il fallait le restructurer. Nous avons réduit le coût du programme de 40 % tout en fidélisant le segment à fort potentiel d'ambassade. La leçon principale : les modèles capturent ce qu'on mesure, et parfois le responsable sait ce qu'on ne mesure pas encore.

Exemple de réponse

J'ai déployé un modèle de prévision de la demande pour une entreprise e-commerce. Ses performances en backtesting étaient solides, mais il s'est dégradé rapidement trois semaines après la mise en production. La cause : un glissement des données. Les données d'entraînement couvraient des périodes stables, mais nous avons lancé le modèle juste avant qu'un concurrent modifie massivement ses prix, ce qui a bouleversé les comportements d'achat. J'ai mis en place un pipeline de surveillance qui suivait en temps réel la distribution des variables d'entrée et des prédictions du modèle. Lorsque le glissement dépasse un certain seuil, le modèle se réentraîne automatiquement sur les données récentes. J'ai également ajouté un repli vers des heuristiques simples lorsque le niveau de confiance passe sous un seuil défini. Cette expérience m'a appris que déployer un modèle ne représente que la moitié du travail : la surveillance et la dégradation gracieuse constituent l'autre moitié.

Exemple de réponse

L'équipe dirigeante voulait comprendre pourquoi notre moteur de recommandation proposait parfois des produits apparemment aléatoires. Je disposais de 15 minutes lors d'une réunion du conseil d'administration. Plutôt que d'expliquer le filtrage collaboratif par des équations, j'ai utilisé une analogie : « Imaginez un libraire qui se souvient de ce qu'a acheté chaque client. Quand vous entrez, il pense aux clients qui vous ressemblent et vous recommande ce qu'ils ont apprécié. » J'ai ensuite montré 3 exemples réels d'utilisateurs où les recommandations avaient parfaitement du sens une fois visible la logique de similitude. J'ai aussi présenté 2 cas d'échec et expliqué que nous les corrigions avec du filtrage basé sur le contenu pour compléter l'approche. Le conseil d'administration a approuvé un budget supplémentaire pour l'équipe recommandations sur la base de cette présentation.

Exemple de réponse

Cela dépend du contexte du problème et de l'asymétrie des coûts d'erreur. Pour un modèle de détection de fraude où les cas positifs représentent 0,1 % des données, je choisirais d'abord la bonne métrique d'évaluation : l'exactitude n'a aucun sens ici, j'utiliserais l'AUC précision-rappel, le F1, ou une fonction de coût personnalisée qui pondère les faux négatifs selon leur coût métier. Côté données, j'essaierais SMOTE pour le suréchantillonnage synthétique, le sous-échantillonnage aléatoire avec des méthodes d'ensemble (comme EasyEnsemble), ou un échantillonnage stratifié. Côté modèle, j'utiliserais des poids de classe pour pénaliser la mauvaise classification de la classe minoritaire. Des algorithmes comme XGBoost gèrent bien le déséquilibre via le paramètre scale_pos_weight. J'envisagerais aussi des approches de détection d'anomalies : si la classe minoritaire est suffisamment rare, reformuler le problème en détection d'anomalies plutôt qu'en classification peut être plus efficace. L'essentiel est d'évaluer sur un jeu de test qui reflète la distribution des classes dans le monde réel.

Exemple de réponse

Le biais est l'erreur due à des hypothèses trop simplistes : un modèle linéaire qui tente de reproduire une relation quadratique sera toujours dans l'erreur, quelles que soient les données d'entraînement. La variance est l'erreur due à la sensibilité aux fluctuations des données d'entraînement : un polynôme de degré élevé reproduit parfaitement les données d'entraînement, mais échoue sur de nouvelles données. Le compromis : réduire le biais augmente généralement la variance, et réciproquement. En pratique, je commence par un modèle simple (biais élevé, faible variance) et n'augmente la complexité que lorsque les métriques de validation le justifient. Les techniques de régularisation (L1, L2, dropout, arrêt précoce) permettent d'augmenter la capacité du modèle tout en contrôlant la variance. La validation croisée est indispensable pour estimer où l'on se situe sur le spectre biais-variance. Pour les méthodes d'ensemble : le bagging réduit la variance (Random Forest), tandis que le boosting réduit le biais (XGBoost). Je choisis selon que mon modèle de référence sous-ajuste ou sur-ajuste.

Exemple de réponse

Je commence par définir l'hypothèse et la métrique principale. Pour un nouveau tunnel de paiement, l'hypothèse pourrait être : « le nouveau tunnel augmente le taux de finalisation des achats ». La métrique principale est le taux de conversion, avec des métriques de garde-fou comme le revenu par session et le temps de chargement de la page. Ensuite, je calcule la taille d'échantillon grâce à une analyse de puissance : pour une augmentation absolue de 2 % à partir d'une base de 10 %, avec une puissance de 80 % et un niveau de confiance de 95 %, il faut environ 15 000 utilisateurs par groupe. La randomisation se fait au niveau de l'utilisateur (et non de la session) pour éviter des expériences incohérentes. Je lance le test sur au minimum un cycle d'activité complet pour capturer les effets liés au jour de la semaine. Pour l'analyse, j'utilise un test z à deux proportions sur la métrique principale et vérifie les effets de nouveauté en examinant l'évolution de la métrique dans le temps. Je segmente aussi les résultats par cohortes d'utilisateurs clés : le nouveau tunnel peut aider les nouveaux utilisateurs tout en gênant les utilisateurs avancés. Enfin, j'applique des corrections pour comparaisons multiples si plusieurs métriques sont testées simultanément.

Exemple de réponse

La régularisation L1 (Lasso) ajoute la valeur absolue des poids à la fonction de perte, tandis que L2 (Ridge) ajoute le carré des poids. La différence pratique essentielle : L1 pousse les poids exactement à zéro, effectuant ainsi une sélection automatique de variables. L2 réduit les poids vers zéro sans jamais l'atteindre, maintenant toutes les variables avec une influence réduite. J'utilise L1 lorsque je suppose que de nombreuses variables sont non pertinentes et que je veux un modèle parcimonieux et interprétable : c'est courant dans les jeux de données de grande dimension, comme la génomique ou le traitement de texte. J'utilise L2 lorsque la plupart des variables apportent un signal et que je veux éviter qu'une seule variable domine : typique pour des jeux de variables bien construits. L'Elastic Net combine les deux et constitue ma valeur par défaut quand j'hésite : il associe la parcimonie de L1 à la stabilité de L2 pour les variables corrélées. La force de régularisation (lambda) est toujours ajustée par validation croisée.

Exemple de réponse

Je résiste d'abord à l'envie de commencer la modélisation. Je consacre les 2 à 3 premiers jours à l'exploration des données : profilage de chaque variable pour les taux de valeurs manquantes, les distributions, les valeurs aberrantes et les incohérences. Je documente mes observations et les présente au propriétaire des données : souvent, il peut expliquer des anomalies qui auraient nécessité des semaines d'investigation. Pour les valeurs manquantes, mon approche dépend du mécanisme : si elles sont entièrement aléatoires, l'imputation (médiane pour les variables numériques, mode pour les variables catégorielles, ou imputation par modèle) fonctionne. Si elles ne sont pas aléatoires, l'absence elle-même est informative et je l'encode comme variable. Je mets en place des contrôles de validation des données (Great Expectations ou équivalent) pour détecter les problèmes de qualité à l'ingestion. Ce n'est qu'après avoir établi un jeu de données propre et bien compris que je commence la modélisation, en restant simple pour établir une base de référence avant d'ajouter de la complexité.

Exemple de réponse

Je ne dirais pas simplement « non », ni ne compromettrais silencieusement la qualité. Je décomposerais le travail en couches de valeur. D'ici vendredi, je pourrais déployer un modèle simple de filtrage collaboratif basé sur les interactions utilisateur-article : ce ne sera pas parfait, mais il surpassera les suggestions aléatoires actuelles. Je présenterais cela comme une Phase 1 avec des limitations clairement documentées. La Phase 2 (semaines 2 à 3) ajouterait des variables basées sur le contenu et gérerait le problème du démarrage à froid pour les nouveaux utilisateurs. J'indiquerais l'amélioration de performance attendue pour chaque phase avec des métriques estimées. Cette approche délivre une valeur réelle immédiatement tout en fixant des attentes pour la solution complète. Je signalerais également que précipiter le modèle complet pour vendredi signifie passer outre l'évaluation hors ligne et les tests A/B, ce qui revient à déployer sans savoir si le modèle aide réellement les utilisateurs.

Exemple de réponse

Je signalerais le problème immédiatement, sans attendre le déploiement ni un bilan rétrospectif. Je documenterais la préoccupation avec des preuves montrant la corrélation par proxy (par exemple, la correspondance entre code postal et données démographiques) et je la présenterais au responsable technique et à un responsable métier. Je testerais ensuite les performances du modèle avec et sans cette variable. Souvent, supprimer la variable proxy a un impact minimal sur la précision globale, mais réduit significativement l'impact différentiel. Si la variable est véritablement nécessaire aux performances, j'explorerais des techniques de modélisation tenant compte de l'équité : post-traitement à égalité des chances, débiaisage adversarial, ou calibration selon les groupes protégés. Je recommanderais aussi d'intégrer des métriques d'équité dans le pipeline d'évaluation du modèle : non seulement la précision, mais aussi la parité démographique et l'égalité des chances. Le risque métier d'un modèle discriminatoire (juridique, réputationnel, éthique) dépasse largement le gain marginal en précision.

Exemple de réponse

Je prends « ça ne semble pas correct » au sérieux : les experts du domaine détectent souvent des problèmes que les métriques ne voient pas. Je demanderais d'abord des exemples précis de prédictions qui semblent erronées et chercherais des patterns. Causes fréquentes : le modèle optimise la mauvaise métrique (haute précision mais mauvaise calibration), le jeu de test ne reflète pas la distribution réelle, ou le modèle capture des patterns statistiques qui violent la logique métier. J'examinerais les prédictions du modèle sur leurs exemples spécifiques avec SHAP ou LIME pour expliquer les prédictions individuelles. Si le modèle est techniquement correct mais viole les attentes métier, il peut être nécessaire d'ajouter des contraintes de règles métier ou d'ajuster la fonction de perte pour pénaliser davantage certains types d'erreurs. Je vérifierais aussi les fuites de données : un score de test anormalement élevé combiné à un scepticisme métier est un signal classique de fuite de données.