Quelle est la différence entre l'apprentissage supervisé et non supervisé, et quand utiliseriez-vous chacun ?

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.

Comment abordez-vous un nouveau jeu de données avant de construire un modèle ?

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.

Qu'est-ce que le surapprentissage, et quelles techniques utilisez-vous pour le détecter et le prévenir ?

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.

Parlez-moi d'une fois où vous avez dû expliquer un modèle ou ses résultats à un public non technique.

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.

Décrivez un modèle que vous avez construit qui n'a pas fonctionné aussi bien que prévu. Qu'avez-vous fait ?

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 %.

Parlez-moi d'une fois où vous avez travaillé avec une équipe d'ingénierie pour déployer un modèle en production.

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.

Comment choisissez-vous les métriques d'évaluation pour un problème de classification ?

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.

Expliquez-moi comment vous abordez l'ingénierie des features.

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.

Comment pensez-vous à la mise en production d'un modèle, du notebook au système réel ?

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.

Data scientist

Les entretiens pour un poste de data scientist vont bien au-delà du SQL et des tableaux de bord. Les recruteurs attendent que vous parliez de sélection de modèles, d'ingénierie des features, de métriques d'évaluation et de ce qui se passe après la construction d'un modèle. Ce guide couvre les questions les plus fréquentes avec des réponses concrètes pour vous préparer.

Pour des conseils généraux de préparation aux entretiens, consultez notre guide sur les questions d'entretien courantes.

Questions d'entretien courantes pour Data scientist

Questions comportementales pour les postes Data scientist

Questions techniques pour les candidats Data scientist

Ce que les recruteurs recherchent pour un poste Data scientist

Ce que les recruteurs cherchent vraiment chez les candidats data scientist :

Une mentalité production, pas seulement de notebook. Les candidats qui comprennent le skew entraînement-service, la surveillance et le versionnage des modèles se distinguent de ceux qui s'arrêtent à la précision du modèle.
Une gestion honnête de l'échec et de l'incertitude. Les meilleurs data scientists parlent clairement des modèles qui n'ont pas fonctionné et de ce qu'ils ont changé. Les candidats qui ne décrivent que des succès sont un signal d'alerte.
Le contexte métier avant tout. Les bons candidats relient chaque choix technique (sélection des métriques, ingénierie des features, seuil de décision) à un résultat métier, pas seulement à un score de benchmark.
La communication avec les parties prenantes non techniques. La capacité à traduire les sorties d'un modèle en décisions actionnables pour une équipe marketing ou finance distingue les data scientists à fort impact de ceux qui vivent uniquement dans des notebooks.
La conscience des problèmes de qualité des données. Les candidats qui mentionnent la fuite de label, le déséquilibre des classes et la dérive des données d'entraînement dès le début de leurs réponses ont travaillé sur de vraies données de production.

Questions à poser à votre interlocuteur

→À quoi ressemble le processus de déploiement des modèles ici : qui est responsable de la mise en production, l'équipe data science ou l'engineering ?
→Quelle est la maturité de l'infrastructure de données ? Avez-vous un feature store, ou l'ingénierie des features se fait-elle projet par projet ?
→Quel est le processus de feedback pour les modèles déjà en production : comment surveillez-vous la dérive et la dégradation ?
→Quel est l'équilibre entre la construction de nouveaux modèles et la maintenance et l'amélioration des modèles existants ?
→Comment l'équipe data science collabore-t-elle avec les parties prenantes produit et métier pour définir les prochains sujets ?

Entrainez-vous sur ces questions avant votre entretien

Le simulateur d'entretien construit une session de pratique autour d'une offre d'emploi spécifique et de votre parcours, pour que vous répétiez les questions les plus susceptibles d'être posées.

Commencer l'entrainement

Gratuit pendant la beta. Sans engagement.

Métiers similaires