L'entretien de data scientist est devenu sans bruit l'un des parcours les plus larges de la tech. Vous pouvez être un excellent modélisateur et couler quand même sur une fonction de fenêtrage SQL, ou cartonner sur le code et vous effondrer dès qu'on vous demande pourquoi le résultat de votre test A/B pourrait être un faux positif. En 2026, l'exigence porte moins sur des algorithmes appris par coeur que sur votre capacité à raisonner d'une question business brouillonne jusqu'à un chiffre défendable.
Ce que les entretiens de data scientist évaluent vraiment en 2026
Les managers recruteurs ne cherchent pas quelqu'un capable de réciter la formule de la descente de gradient. Ils veulent quelqu'un à qui confier une question floue ("est-ce que cette fonctionnalité a bougé la rétention ?") en sachant qu'il saura la cadrer, sortir les données, choisir une méthode solide, quantifier l'incertitude et expliquer le résultat sans jargon.
Le métier s'est scindé en deux. Certains intitulés "data scientist" recouvrent en réalité des postes d'analyse, très SQL, inférence causale et communication avec les parties prenantes. D'autres se rapprochent du machine learning appliqué, très modélisation et mise en production. Lisez l'offre d'emploi à la loupe, parce que les deux voies ne pondèrent pas les mêmes étapes. Les deux insistent sur la conception d'expériences (les tests A/B sont désormais un minimum), sur l'aisance avec les limites des grands modèles de langage, et sur le réflexe de vérifier la cohérence d'un résultat avant de lui faire confiance.
Le processus d'entretien
La plupart des processus en data science comptent quatre à six étapes, avec une régularité remarquable d'une entreprise à l'autre, quelle que soit sa taille.
- Préqualification par le recruteur. Logistique, fourchette de salaire, et quelques invitations du type "parlez-moi d'un projet". Faible enjeu, mais on vérifie que vous savez décrire un travail technique en langage clair.
- Test technique (SQL et/ou code). En général dans un éditeur partagé. Attendez-vous à du SQL intermédiaire à avancé (jointures, fonctions de fenêtrage, agrégation) et souvent à une question Python autour de pandas ou d'algorithmes de base. Certaines équipes remplacent ça par un exercice à emporter.
- Étape statistiques et machine learning. De la profondeur conceptuelle sur les probabilités, l'inférence, les tests A/B et le compromis biais-variance, plus des décisions concrètes de modélisation. C'est là qu'une connaissance superficielle se voit tout de suite.
- Étude de cas ou étape produit. Un problème business ouvert ("comment mesureriez-vous le succès de cette fonctionnalité ?"). On veut votre structure, vos métriques et vos hypothèses, pas une réponse unique.
- Étape comportementale et parties prenantes. Souvent avec un partenaire d'une autre équipe, qui sonde la collaboration, la gestion du flou, et la façon dont vous communiquez vos résultats à des non-techniciens.
Les processus senior et staff ajoutent du design de système ou de ML ("concevez un pipeline de recommandation") et creusent davantage l'influence et la priorisation.
Les questions
De vraies questions que rencontrent les data scientists, regroupées par étape, chacune avec une note courte sur la façon de l'aborder.
SQL et code
1. Trouvez le deuxième salaire le plus élevé de chaque service.
Comment l'aborder : sortez une fonction de fenêtrage (DENSE_RANK() partitionnée par service), pas une sous-requête imbriquée bancale. Dites pourquoi vous avez choisi DENSE_RANK plutôt que RANK ou ROW_NUMBER, puisque le piège, ce sont les ex aequo.
2. Calculez un cumul du chiffre d'affaires quotidien, plus une moyenne mobile sur 7 jours.
Comment l'aborder : SUM() OVER (ORDER BY date) et AVG() OVER (... ROWS BETWEEN 6 PRECEDING AND CURRENT ROW). Commentez la clause de fenêtre à voix haute, parce que la plupart des candidats se trompent sur les bornes.
3. À partir d'une table d'événements utilisateur, calculez la rétention à J+1 et à J+7. Comment l'aborder : auto-jointure, ou différence de dates par rapport à la première date vue pour chaque utilisateur. Clarifiez d'abord la définition : "revenu exactement le jour 7" et "revenu au plus tard le jour 7" ne donnent pas la même requête.
Statistiques et expérimentation
4. Expliquez la p-value à une partie prenante non technique. Comment l'aborder : oubliez la définition du manuel. Essayez "si la fonctionnalité n'avait vraiment aucun effet, la p-value est la probabilité d'observer un résultat aussi fort par simple hasard". Ajoutez ensuite ce qu'elle ne veut pas dire (ce n'est pas la probabilité que l'hypothèse soit vraie).
5. On a lancé un test A/B, il atteint la significativité au bout de 3 jours, on peut déployer ? Comment l'aborder : c'est un piège au peeking et à l'effet de nouveauté. Signalez qu'arrêter tôt gonfle le taux de faux positifs, que la taille d'échantillon se fixe à l'avance, et que les premiers utilisateurs ne se comportent pas comme la population en régime stable.
6. Qu'est-ce que le compromis biais-variance, et comment se manifeste-t-il en pratique ? Comment l'aborder : définissez les deux, puis ancrez-le dans le concret. Un arbre profond surapprend (variance élevée), un modèle linéaire sur des données non linéaires sous-apprend (biais élevé). Reliez ça à une solution comme la régularisation ou la validation croisée.
7. Comment détecteriez-vous et traiteriez-vous un paradoxe de Simpson dans vos résultats ? Comment l'aborder : expliquez qu'une tendance agrégée peut s'inverser à l'intérieur des sous-groupes, puis dites que vous segmenteriez par la variable de confusion et vérifieriez si la relation tient.
8. L'AUC hors ligne de votre modèle est excellente, mais la conversion en ligne n'a pas bougé. Que s'est-il passé ? Comment l'aborder : passez en revue les suspects habituels : décalage entre entraînement et production, une variable qui fuite, une métrique hors ligne mal alignée, ou une surface produit qui ignore le score. Ça récompense un débogage structuré plutôt qu'une intuition unique.
Machine learning et modélisation
9. Comment gérez-vous un problème de classification très déséquilibré (1% de positifs) ? Comment l'aborder : ne sautez pas sur SMOTE. Commencez par la métrique (précision-rappel, pas l'exactitude), puis les poids de classes et le réglage du seuil, et seulement ensuite le rééchantillonnage. C'est le coût business d'un faux négatif face à un faux positif qui doit guider le choix.
10. Comment choisiriez-vous entre une régression logistique et un arbre boosté par gradient pour un modèle de churn ? Comment l'aborder : posez-le comme un arbitrage entre interprétabilité et besoins des parties prenantes d'un côté, performance brute de l'autre, plus le volume de données et les interactions entre variables. Les bonnes réponses commencent par une référence établie avec le modèle le plus simple.
11. Comment évitez-vous les fuites de données dans un pipeline ? Comment l'aborder : citez des fuites concrètes (ajuster un scaler avant de découper le jeu de données, utiliser de l'information future, une fuite de la cible via une variable postérieure au résultat). Dites que vous ajustez les transformations à l'intérieur des plis de validation croisée.
12. Quand utiliseriez-vous un LLM dans un workflow de data science, et quels sont les risques ? Comment l'aborder : un incontournable de 2026. Bons usages : extraction, classification de texte, rédaction de premiers jets. Risques : hallucination, coût, latence, et la tentation d'en coller un là où un classifieur bon marché suffirait. Montrez du jugement, pas de l'emballement.
Étude de cas et produit
13. Comment mesureriez-vous le succès d'une nouvelle fonctionnalité "enregistrer pour plus tard" ? Comment l'aborder : clarifiez l'objectif, proposez une métrique principale et des garde-fous (l'engagement monte, mais l'achat ou le churn bougent-ils ?), et esquissez une expérience. La structure vaut mieux que l'astuce.
14. Les utilisateurs actifs quotidiens ont chuté de 8% la semaine dernière. Comment enquêtez-vous ? Comment l'aborder : segmentez méthodiquement (plateforme, zone géographique, nouveaux contre existants, une date de mise en production) et distinguez une vraie baisse d'un bug de logging. Verbalisez vos embranchements ; c'est votre démarche de diagnostic qui est notée.
Comportemental
15. Parlez-moi d'une fois où votre analyse a changé une décision produit. Comment l'aborder : utilisez une structure serrée situation-action-résultat, chiffrez l'impact, et insistez sur la façon dont vous l'avez communiquée pour emporter l'adhésion.
16. Décrivez un projet où les données étaient plus sales que prévu. Comment l'aborder : montrez votre jugement dans le flou : ce que vous avez nettoyé, ce que vous avez écarté, et comment vous avez communiqué les limites honnêtement.
Les erreurs courantes qui coulent les candidats data scientist
- Sauter sur un modèle avant d'avoir clarifié la question. Le signal le plus fort dans une étude de cas, c'est le cadrage. Les candidats qui demandent "qu'est-ce que le succès veut dire ici ?" font mieux que ceux qui dégainent XGBoost tout de suite.
- Réciter des définitions sans application. N'importe qui sait définir une p-value. Peu de gens savent l'expliquer à un PM puis dire ce qu'elle ne veut pas dire. C'est la seconde partie qui fait la différence.
- Ignorer la qualité des données et les fuites. Vos interlocuteurs posent exprès des pièges de données sales et de fuites, et passer à côté se lit comme un manque d'expérience.
- Compliquer inutilement la référence de départ. Sortir un réseau de neurones quand une régression logistique suffirait trahit un mauvais jugement. Annoncez d'abord la référence simple.
- Mal communiquer l'incertitude. Une estimation ponctuelle sans intervalle de confiance ni réserve est le moyen le plus rapide de rater un processus senior.
Comment se préparer (et où un copilote en direct aide)
Construisez une base, puis entraînez-vous sous pression. Martelez les fonctions de fenêtrage et les jointures SQL jusqu'à ce qu'elles deviennent automatiques, parce que cette étape se joue à la vitesse. Redémontrez les statistiques de base (tests d'hypothèses, théorème central limite, mécanique des tests A/B) pour pouvoir les enseigner, pas seulement les réciter. Tenez un document vivant avec trois ou quatre projets aux résultats chiffrés pour les étapes comportementales. Puis enchaînez des entretiens blancs à voix haute avec quelqu'un qui vous coupe la parole, parce que la vraie compétence testée, c'est de penser à voix haute malgré les interruptions.
Le décalage que ressentent la plupart des candidats, c'est entre connaître la matière au calme et la retrouver pendant qu'un inconnu regarde un curseur clignoter. C'est là qu'un copilote en direct gagne sa place. GhostPilot écoute l'audio de l'entretien et fait apparaître des repères structurés en temps réel : le bon motif de fonction de fenêtrage quand une question SQL tombe, ou un cadre propre pour une étude de cas produit. Il tourne dans le panneau latéral de Chrome, donc quand vous partagez un seul onglet du navigateur, il ne fait pas partie de ce qui est capturé, et l'application de bureau Windows optionnelle est invisible à la capture d'écran sous Windows 10 (build 2004 ou ultérieur) et Windows 11. Bien utilisé, il vous garde structuré au lieu de vous souffler un texte à lire, puisque lire comme un robot est exactement ce que repère un interlocuteur affûté. Voyez comment ça marche sur ghostpilotai.com.
FAQ
Quelles questions pose-t-on dans un entretien de data scientist ? Un mélange de SQL (jointures, fonctions de fenêtrage, requêtes de rétention), de statistiques et de tests A/B, de concepts de machine learning (biais-variance, données déséquilibrées, fuites), d'études de cas produit ouvertes, et de questions comportementales. La pondération dépend de l'orientation du poste, plutôt analyse ou plutôt ML appliqué.
Comment se préparer à un entretien de data scientist en 2026 ? Travaillez le SQL jusqu'au réflexe, redémontrez les statistiques de base pour savoir les expliquer simplement, préparez trois ou quatre récits de projets chiffrés, et entraînez-vous aux études de cas à voix haute. La conception d'expériences et une communication claire de l'incertitude sont ce qui compte le plus cette année.
Le SQL compte-t-il encore dans les entretiens de data science ? Absolument. Le SQL est la compétence la plus systématiquement testée dans les processus de data science, et c'est en général une étape éliminatoire précoce. On attend un niveau intermédiaire à avancé, en particulier sur les fonctions de fenêtrage.
Les études de cas en data science sont-elles difficiles ? Difficiles précisément parce qu'il n'y a pas de réponse unique. Elles récompensent la structure : clarifier l'objectif, choisir des métriques et des garde-fous sensés, expliciter ses hypothèses, et proposer une expérience. Un raisonnement clair vaut mieux qu'un modèle malin.
Pose-t-on désormais des questions sur les grands modèles de langage aux data scientists ? De plus en plus, oui. Attendez-vous à des questions sur les cas où un LLM est le bon outil, sur la façon dont vous évalueriez ses sorties, et sur les risques (hallucination, coût, latence). Un jugement mesuré vaut mieux que de l'enthousiasme affiché.
Essayez GhostPilot AI
Les entretiens de data science s'étalent du SQL aux statistiques, à la modélisation et au raisonnement produit ouvert : beaucoup de choses à tenir sous pression. GhostPilot vous donne un filet en temps réel qui garde vos réponses structurées pendant que vous parlez. Commencez gratuitement avec des sessions en direct de 10 minutes et des réponses IA illimitées, prenez un Session Pass à $29 (trois entretiens complets de deux heures, paiement unique, sans abonnement), ou passez en Pro à $59/mois ou $192/an ($16/mois en facturation annuelle).