Questions d'entretien Data scientist

L'apprentissage supervisé utilise des données étiquetées pour entraîner un modèle à prédire une sortie à partir de features d'entrée. Je l'utilise quand j'ai une variable cible claire et suffisamment d'exemples étiquetés : prédiction du churn, estimation de prix, classification d'images. L'apprentissage non supervisé trouve des structures dans les données sans étiquettes. Je l'utilise quand je veux découvrir des patterns que je n'ai pas définis à l'avance : segmentation client avec k-means, modélisation de sujets avec LDA, ou détection d'anomalies quand je n'ai pas d'exemples étiquetés de fraude. En pratique, beaucoup de projets combinent les deux : j'utilise un clustering non supervisé pour identifier des segments clients, puis je construis un classifieur supervisé pour affecter les nouveaux clients à ces segments en temps réel. La décision part toujours de la question métier et des données disponibles.

Je commence par une analyse exploratoire des données avant de toucher au moindre code de modélisation. Je vérifie la structure et le schéma, puis j'examine les taux de valeurs manquantes par colonne et décide si je les impute, les supprime ou les signale. J'analyse les distributions des features numériques : asymétrie, valeurs aberrantes, et différences d'échelle entre colonnes. Pour les features catégorielles, je vérifie la cardinalité et si certaines catégories n'apparaissent que dans le jeu de test. J'examine tôt la distribution de la variable cible : le déséquilibre des classes change presque toutes les décisions en aval. Je croise les features clés avec la cible pour construire une intuition du signal disponible avant d'écrire la moindre ligne de sklearn. Je documente mes observations au fur et à mesure.

Le surapprentissage se produit quand un modèle apprend si précisément les données d'entraînement qu'il capture le bruit plutôt que le pattern sous-jacent, et ses performances se dégradent sur de nouvelles données. Je le détecte en comparant les métriques d'entraînement et de validation côte à côte : un écart important entre une précision d'entraînement de 97 % et une précision de validation de 81 % est un signal clair. Pour le prévenir, j'utilise la validation croisée plutôt qu'un simple découpage train-test, ce qui donne une estimation plus fiable de la généralisation. Pour les modèles à base d'arbres, j'ajuste la profondeur maximale et le nombre minimum d'échantillons par feuille. Pour les réseaux de neurones, j'applique le dropout et surveille la perte de validation. La régularisation L1 ou L2 aide pour les modèles linéaires.

J'ai construit un modèle de prédiction du churn pour un produit par abonnement et j'ai dû présenter les résultats à l'équipe de direction marketing et customer success. Le modèle utilisait un classifieur à gradient boosting avec une quarantaine de features, ce qui n'aurait rien signifié pour eux. J'ai complètement retiré les détails techniques des slides. Je me suis concentré sur trois choses : ce que le modèle prédit, la confiance que nous pouvons avoir en lui d'après la précision et le rappel sur les données de test, et surtout ce que cela signifiait pour leurs décisions. J'ai présenté les cinq principaux facteurs de risque de churn en langage clair : les clients qui ne s'étaient pas connectés depuis 21 jours et n'avaient pas utilisé la fonctionnalité de reporting étaient 4,2 fois plus susceptibles de churner dans les 30 jours. Les questions ont porté sur la stratégie, pas sur la méthodologie.

J'ai construit un modèle de propension pour prédire quels utilisateurs du niveau gratuit passeraient à un abonnement payant dans les 60 jours. Après entraînement sur six mois de données, l'AUC sur le jeu de validation était de 0,71, ce qui semblait raisonnable. Mais lors d'un test en direct sur quatre semaines, la précision était bien inférieure à ce qu'on attendait : nous signalions trop de faux positifs. J'ai fait un post-mortem et identifié deux problèmes. D'abord, les données d'entraînement avaient un problème de fuite de label : une des features incluait un clic sur une invite de mise à niveau dans l'application qui se produisait juste avant la conversion, donc le modèle avait appris d'un signal indisponible au moment de la prédiction. Ensuite, le déséquilibre des classes était plus sévère dans la population réelle. J'ai reconstruit le modèle après avoir supprimé la feature problématique et rééquilibré avec SMOTE. L'AUC est passé à 0,79 et la précision sur le premier décile est passée de 31 % à 58 %.

Après avoir construit un modèle de détection de fraude en temps réel en Python, j'ai travaillé avec deux ingénieurs backend pour le mettre en production. Le premier défi était que j'avais construit le modèle dans un environnement Jupyter et que le pipeline d'ingénierie des features n'était pas reproductible en dehors. J'ai passé deux jours à refactoriser le code de prétraitement en un module Python propre avec des tests unitaires. Nous avons convenu d'un contrat d'API : le modèle recevrait un payload JSON et renverrait un score entre 0 et 1 avec un temps de réponse inférieur à 50 ms. J'ai conteneurisé le modèle avec Docker et nous avons utilisé un déploiement en shadow pour acheminer 10 % du trafic réel vers le nouveau modèle. Nous avons surveillé la distribution des prédictions et la latence pendant deux semaines avant de basculer complètement. La période shadow a révélé un cas limite où un champ manquant causait une prédiction nulle.

Je commence par me demander quel est le coût de chaque type d'erreur dans le contexte métier, car la précision globale ne raconte presque jamais toute l'histoire. Pour la détection de fraude, un faux négatif (fraude manquée) est bien plus coûteux qu'un faux positif, donc je pondère fortement le rappel. Pour un modèle de scoring de leads où la capacité commerciale est limitée, la précision compte davantage : je veux que les leads que nous appelons soient de haute qualité. Quand les classes sont déséquilibrées, la précision globale est particulièrement trompeuse. J'utilise la courbe AUC-ROC pour comparer les modèles de façon indépendante du seuil, et la courbe précision-rappel quand la classe positive est rare. Pour le seuil opérationnel final, j'examine le score F-beta et je choisis un beta qui reflète le compromis métier. Je surveille aussi la calibration : un modèle qui dit "70 % de probabilité" doit avoir raison environ 70 % du temps.

L'ingénierie des features est souvent là où la plus grande valeur est créée, et je la traite comme un processus continu plutôt qu'une étape unique. Je commence par la connaissance du domaine : qu'est-ce qu'un expert humain pense prédire le résultat ? Cela me donne un ensemble de départ rapide. Ensuite j'examine les features brutes et crée des features dérivées : ratios, moyennes glissantes sur différentes fenêtres temporelles, temps écoulé depuis le dernier événement, et termes d'interaction entre features dont la logique métier suggère qu'elles pourraient agir ensemble. Pour les données textuelles, j'utilise TF-IDF ou des embeddings selon que la tâche nécessite une similarité sémantique. Je valide chaque feature en mesurant son importance dans un modèle de référence et en effectuant des tests de permutation. Je vérifie aussi la multicolinéarité : des features très corrélées peuvent déstabiliser certains modèles.

L'écart entre un notebook fonctionnel et un modèle de production fiable est important et mérite d'être anticipé dès le départ. Je commence par écrire le pipeline de features en Python propre et testable plutôt qu'en cellules de notebook, afin que le même code de prétraitement s'exécute de façon identique à l'entraînement et à l'inférence. Cela prévient le skew entraînement-service, l'une des sources les plus courantes de dégradation silencieuse du modèle. Je versionne l'artefact du modèle et le pipeline de features ensemble avec MLflow ou un outil similaire. Je définis les exigences de surveillance avant le lancement : je veux suivre les distributions des features d'entrée, les distributions des scores de sortie, et les performances réelles versus prédites sur les données de feedback étiquetées. Je configure des seuils d'alerte pour la dérive des données avec des tests statistiques comme le test de Kolmogorov-Smirnov.