Préparation aux Entretiens de Data Scientist : Guide 2026

Pourquoi l'entretien de data scientist ressemble à cela en 2026

Le titre de data scientist en 2026 n'est pas le même emploi qu'il y a cinq ans. Deux changements structurels ont réduit le rôle par les deux extrémités. Du côté de la modélisation, les ingénieurs ML ont absorbé le travail de productionisation — tout ce qui se déploie sur une pile de service est maintenant un emploi d'ingénieur ML, pas un emploi de data scientist. Du côté de l'analyse, les « analytics engineers » ayant de fortes compétences en dbt et entrepôt de données ont absorbé le travail de création de tableaux de bord et de définition des métriques. Ce qui reste au milieu, où se trouvent la plupart des offres d'emploi « data scientist », c'est la product data science — le rôle responsable de l'expérimentation, de la conception des métriques et de la rigueur statistique qui étaye les décisions produit.

C'est important pour la préparation aux entretiens car la boucle d'entretien a évolué avec le rôle. Il y a cinq ans, un entretien de data scientist comportait 60% de modélisation et 40% de SQL. En 2026, c'est plus proche de 60% SQL et expérimentation, 25% sens du produit et des métriques, et 15% modélisation — et la ronde de modélisation, quand elle apparaît, est de plus en plus une « étude de cas » plutôt qu'un problème de codage. En vous trompant sur l'équilibre de votre préparation, vous vous concentrerez trop sur les compétitions de style Kaggle alors que l'entretien réel vous demande de diagnostiquer pourquoi une métrique a baissé.

Il existe une deuxième voie — les rôles de data scientist appliqué au ML dans les entreprises qui font toujours la distinction entre les chercheurs, les ingénieurs ML et les data scientists appliqués (Netflix, Stripe, Anthropic, DeepMind dans les cas limités où ils embauchent sous le titre de data scientist). Ces boucles inversent l'équilibre à environ 50% de profondeur de modélisation, avec la ronde d'étude de cas censée aller trois niveaux plus profonds — conception des caractéristiques, méthodologie d'évaluation, évaluation en ligne — plutôt que d'effleurer la surface. Si vous visez ces rôles, adaptez votre préparation en conséquence ; si vous visez Meta ou Airbnb, ne le faites pas.

L'entretien de data scientist en 2026, étape par étape

Une boucle de data scientist typique en 2026 comprend quatre à six étapes réparties sur trois à cinq semaines. La composition exacte varie d'une entreprise à l'autre et selon la voie, mais la structure reste cohérente.

Entretien avec le recruteur (30 minutes). Principalement de la logistique et des attentes salariales, plus quelques questions de type « parlez-moi de vous ». Le signal ici est de savoir si vous pouvez articuler le type de problèmes sur lesquels vous avez travaillé en langage simple — pas trop de jargon, pas trop modeste. Deux à trois descriptions de projets claires, chacune liée à un résultat commercial mesurable, c'est ce qui vous mène au tour suivant.

Test SQL / codage (45–60 minutes). C'est le filtre technique. Codage en direct sur StrataScratch, DataLemur, Coderpad ou HackerRank — selon l'entreprise. Deux à trois problèmes SQL de niveau moyen plus, occasionnellement, un problème de manipulation de données en Python. Le critère est la correction à la première exécution, un bon nommage des variables, et une explication des cas limites que l'intervieweur n'a pas mentionnés. La pression du temps est réelle ; la plupart des candidats échouent en rendant la jointure trop complexe.

En présentiel ou en virtuel (4–5 rondes, généralement 45 minutes chacune). C'est ici que les boucles divergent selon l'entreprise :

• Meta organise une plongée approfondie en SQL, une ronde sur le sens du produit et des métriques, une ronde de test A/B et une ronde comportementale (« Quel est un projet dont vous êtes fier »). La ronde produit est celle qui a le plus de poids.
• Google est plus vaste : SQL, statistiques, une étude de cas ML, une ronde produit et une ronde comportementale sur la culture Google. L'étude de cas ML est plus présente qu'à Meta.
• Amazon est axée sur les Principes de Leadership ; attendez-vous à ce que chaque ronde soit entrelacée d'investigations sur ces principes, en plus du contenu technique. SQL est court ; les statistiques sont courtes ; la ronde spécifique au data scientist porte généralement sur la conception de métriques, formulée dans le cadre des Principes de Leadership.
• Netflix se distingue par son accent mis sur la réflexion stratégique — moins de rondes, un signal attendu plus élevé par ronde, et une importance majeure accordée à la rédaction. Vous pourrez être invité à rédiger un mémo d'une page expliquant votre analyse.
• Airbnb accorde une grande importance aux métriques côté hôte (« Comment mesurez-vous le taux de churn des hôtes ? ») et organise une longue ronde produit.
• Les entreprises axées sur la recherche ML (DeepMind, Anthropic, OpenAI dans les cas limités où ils embauchent du data scientist) organisent une ronde de discussion d'articles et une ronde de modélisation approfondie en plus des rondes standard.

Ronde avec le manager d'équipe (45 minutes). Généralement programmée en dernier, parfois entre les rondes techniques. Moins technique, davantage orientée sur l'ajustement culturel et la façon dont vous structureriez vos 90 premiers jours. Les candidats expérimentés doivent s'attendre à des questions stratégiques — « Quelle est la métrique la plus importante que cette équipe devrait mesurer mais ne mesure pas actuellement ? »

L'investissement temporal global du premier appel du recruteur à l'offre est rarement inférieur à trois semaines, et souvent de cinq à six semaines. Organisez votre calendrier de préparation en fonction de cela, et non en fonction d'une seule journée d'enjeu élevé.

Rounds SQL : ce qui est réellement évalué en 2026

L'épreuve SQL est l'endroit où la plupart des candidats perdent l'offre, et l'écart entre « je connais SQL » et « je peux réussir une épreuve SQL de 60 minutes » est plus large que les candidats ne le réalisent. Trois catégories de problèmes dominent.

Fonctions de fenêtre — presque universellement testées. Les fonctions spécifiques qui reviennent sans cesse : ROW_NUMBER(), RANK(), DENSE_RANK() pour les top-N-par-groupe ; LAG() et LEAD() pour les changements d'une période à l'autre ; SUM() OVER (PARTITION BY ... ORDER BY ...) pour les totaux cumulatifs. Si vous ne pouvez pas écrire une requête top-N-par-groupe sans réfléchir, vous échouerez. Le piège classique est de recourir aux auto-jointures ou aux sous-requêtes corrélées alors qu'une fonction de fenêtre ferait le travail en cinq lignes.

CTE et transformations multi-étapes — le style moderne. Tout ce qui est plus complexe qu'une simple jointure devrait être exprimé comme une chaîne de CTE, nommées clairement, avec chaque étape faisant une seule chose. L'interviewer examine la lisibilité ainsi que la correction ; une chaîne CTE de 40 lignes avec des noms descriptifs bat toujours une solution de sous-requête imbriquée de 12 lignes.

Les quatre schémas canoniques :

1. Top-N par groupe (trouver les 3 premiers clients par dépense dans chaque région) — fonction de fenêtre avec RANK() ou ROW_NUMBER(), filtre sur le rang.

2. Analyse de rétention et de cohorte (quelle fraction des inscriptions de janvier sont revenues en février) — auto-jointure sur user_id avec arithmétique de date, ou fonctions de fenêtre pour les drapeaux de jour actif.

3. Conversion d'entonnoir (inscription → activation → premier achat) — CTE par étapes avec des vérifications LEFT JOIN ou EXISTS, calcul des taux de conversion entre les étapes.

4. Sessionisation (grouper les lignes en sessions où les événements consécutifs se trouvent dans les 30 minutes) — LAG() pour calculer les différences de temps, puis une somme cumulée des drapeaux « nouvelle session ».

L'erreur la plus courante de loin est une granularité incorrecte. Si votre résultat devrait avoir une ligne par utilisateur-jour et que vous produisez accidentellement une ligne par événement, chaque comptage en aval est faux de plusieurs ordres de grandeur. Énoncez toujours à haute voix quelle devrait être la granularité du résultat avant d'écrire la requête, et vérifiez avec un petit SELECT COUNT(*) après.

Rounds de statistiques et de probabilités

Le round de stats est le plus variable selon les entreprises. Certains sont théoriques (dérivations de Bayes, propriétés de distribution) ; certains sont appliqués (« quel test exécuteriez-vous pour ce scénario ? »). Trois sous-catégories couvrent la plupart de ce qui est demandé.

Probabilité bayésienne / conditionnelle. Le problème de Monty Hall est toujours posé, étonnamment souvent, ainsi que ses variantes — « deux pièces, l'une honnête l'autre truquée, vous lancez et voyez face, quel est P(truquée) ? » — apparaissent dans la plupart des entreprises. La procédure mécanique consiste à écrire le théorème de Bayes, identifier le prior, la vraisemblance et la preuve, puis calculer. Faire cela sur un tableau blanc en parlant est la véritable compétence testée ; obtenir la réponse est nécessaire mais pas suffisant.

Distributions et quand les supposer. Les approximations normales sont utiles mais les candidats les appliquent trop facilement. L'interviewer veut entendre : « Je supposerais normal ici parce que n est assez large pour que le CLT s'applique, mais je vérifierais en vérifiant les résidus ; si les données sous-jacentes ont une queue lourde, je recourais à une distribution t ou à une alternative non-paramétrique. » Nommer l'hypothèse et la vérification est le signal senior.

Test d'hypothèse. Le cadre standard « quel test exécuteriez-vous ? » : identifier le type de métrique (proportion, moyenne, décompte, rapport), vérifier les hypothèses (indépendance, normalité, taille d'échantillon), choisir le test (z-test pour les proportions, t-test pour les moyennes, chi-square pour les catégories, Mann-Whitney pour les données non-normales), énoncer l'hypothèse nulle et l'alternative, définir le niveau de signification et discuter la correction pour comparaisons multiples si applicable. Vous devriez pouvoir parcourir cela en 90 secondes pour n'importe quel scénario.

Intervalles de confiance. Le piège est l'interprétation. « Il y a 95 % de chance que la vraie moyenne soit dans cet intervalle » est faux — les IC fréquentistes ne font pas d'énoncés de probabilité sur les paramètres. L'énoncé correct est : « si je répétais cette expérience plusieurs fois, 95 % des intervalles construits contiendraient la vraie moyenne. » Si vous vous trompez, les interviewers connaissant bien les stats le remarqueront.

Tests A/B et expérimentation : l'essentiel

C'est l'évaluation la plus importante dans les entreprises product-DS (Meta, Airbnb, Uber). Le barème attendu, au minimum :

1. Hypothèse — que pensez-vous qu'il se passera et pourquoi ? À rattacher à un mécanisme comportemental, et non pas simplement « on pense que ce sera bien ».
2. Métrique — métrique de succès principal, métriques secondaires, métriques de garde-fou. Les candidats expérimentés précisent toujours les garde-fous avant qu'on ne les demande.
3. Calcul de puissance — combien d'échantillons pour détecter une augmentation de X % avec une puissance de 80 %, une significativité de 5 % ? Vous devriez pouvoir estimer cela sans calculatrice en utilisant la règle n ≈ 16 × σ² / δ² par bras.
4. Unité de randomisation — utilisateur, session, appareil ? L'intervieweur approfondira ce point ; choisissez délibérément.
5. Garde-fous et vérification SRM — l'inadéquation du ratio d'échantillon (le fractionnement réel s'écarte du 50/50 prévu) est le signal le plus courant d'une expérience défaillante, et les candidats expérimentés le vérifient avant de rapporter les résultats.
6. Analyse — estimation ponctuelle, intervalle de confiance, valeur p (avec correction pour comparaisons multiples si applicable), et la distinction entre significativité pratique et statistique.
7. Décision — lancer, ne pas lancer ou itérer, en rendant explicite le compromis.

Les pièges que l'intervieweur examinera :

• Effets de nouveauté. Le traitement semble excellent la première semaine et diminue à la troisième semaine parce que les utilisateurs explorent simplement la nouvelle fonctionnalité.
• Effets de réseau. Le piège classique de Facebook News Feed — si le traitement change qui voit quoi, vous ne pouvez pas randomiser par utilisateur car le groupe de contrôle est contaminé par le comportement des utilisateurs traités. L'intervieweur énoncera parfois cela comme « et si nous testions un changement du classement du marché ? » et il souhaite entendre une analyse basée sur les interférences réseau.
• Dilution. Si seulement 10 % des utilisateurs voient la fonctionnalité, l'augmentation sur la population entière est l'augmentation sur les 10 % multipliée par 10 %. Oublier cela transforme une « augmentation de 5 % » en une affirmation marketing qui ne résiste pas à un second examen.
• Compromis entre métrique principale et garde-fous. « Et si le revenu augmente mais que la DAU diminue ? » La réponse d'un candidat expérimenté implique l'élasticité du garde-fou et une question d'horizon — une augmentation de revenu à court terme qui coûte de l'engagement long terme n'en vaut rarement la peine.

Un parcours d'exemple concret — concevoir l'expérience pour un nouveau fil d'actualité de la page d'accueil — devrait prendre environ 8 à 10 minutes. Pratiquez jusqu'à ce que ce soit automatique.

Études de cas ML (l'angle product-DS)

Quand le ML apparaît dans une boucle product-DS, il apparaît comme une étude de cas, pas comme un exercice de codage. Le cadrage est toujours une variante de « concevoir un système de classement pour X » — classement des fils, résultats de recherche, recommandations, sélection d'annonces. La structure attendue :

1. Objectif commercial — qu'optimisons-nous réellement ? L'engagement, le revenu, la rétention à long terme ? Le signal d'un candidat expérimenté est de nommer l'objectif à long terme même quand la métrique proxy est à court terme.
2. Labels — quelles sont les classes positives et négatives ? Comment les labels sont-ils générés, et quels biais cela introduit-il ? (Biais de position, biais de sélection, le problème du démarrage à froid.)
3. Caractéristiques — trois à cinq catégories : caractéristiques utilisateur, caractéristiques d'élément, caractéristiques contextuelles, caractéristiques d'interaction, et (pour les modèles sensibles à la séquence) caractéristiques d'historique récent.
4. Classe de modèle — arbres boostés au gradient comme choix par défaut, apprentissage profond quand les données et le signal le justifient. Le candidat expérimenté énonce le compromis — interprétabilité, coût d'entraînement, latence de service en ligne — plutôt que de choisir ce qui est à la mode.
5. Évaluation hors ligne — AUC-ROC pour la classification, NDCG pour le classement, RMSE pour la régression. Le piège est de s'arrêter ici ; les métriques hors ligne corrèlent faiblement avec les métriques commerciales en ligne, et le candidat expérimenté le mentionne.
6. Évaluation en ligne — conception d'un test A/B, métriques principales et garde-fous, la boucle de retour à la ronde d'expérimentation.

La profondeur attendue en toute honnêteté par niveau : au niveau L4 (junior), vous pouvez décrire chaque étape. Au niveau L5 (intermédiaire), vous pouvez argumenter les compromis à chaque étape. Au niveau L6 (senior), vous pouvez identifier les deux ou trois étapes où cette étude de cas est inhabituelle — ce qui la rend plus difficile que le cadre théorique — et proposer comment vous la géreriez.

Rondes produit/métrique : la chute de la DAU

L'évaluation produit caractéristique, posée dans presque toutes les entreprises qui font des entretiens product-DS, est une variante de : « La DAU a chuté de 5 % semaine après semaine. Expliquez-moi comment vous diagnostiqueriez. »

Le cadre attendu, exécuté en direct :

1. Validez d'abord les données. La métrique est-elle réellement en baisse, ou est-ce un problème d'instrumentation ? Vérifiez le pipeline de journalisation, vérifiez les changements en amont, cherchez les données de jour partiel.
2. Segmentez. Par géographie, plateforme, système d'exploitation, pays, cohorte utilisateur, canal d'acquisition. La chute n'est rarement uniforme ; trouver le segment localise la cause.
3. Décomposez par comportement. DAU = nouveaux utilisateurs + utilisateurs de retour. L'inscription des nouveaux utilisateurs a-t-elle baissé ? La rétention des utilisateurs de retour a-t-elle baissé ? Ces deux ont des causes complètement différentes.
4. Décomposez par entonnoir. Dans chaque groupe de comportement : les ouvertures d'application ont-elles baissé ? Le taux de conversion d'ouverture à engagement a-t-il baissé ? Chaque étape a des causes en amont différentes.
5. Recoupez avec les événements externes. Lancements de produits (les vôtres et ceux des concurrents), cycles d'actualité, jours fériés, changements de marketing payant, incidents d'infrastructure.
6. Formez une hypothèse, concevez une vérification. Une fois que vous avez une explication candidate, quelles données la réfuteraient ?

Chez Meta et Google, la sortie attendue est un « arbre métrique » — une décomposition visuelle de la métrique montrant chaque entrée et l'ampleur relative de sa variation. Le candidat expérimenté dessine l'arbre avant de parler, puis le parcourt ; le candidat junior parle d'abord et n'arrive jamais à l'arbre.

Où un assistant IA en temps réel aide les épreuves DS — et où il ne le fait pas

Soyez honnête à ce sujet. La boucle DS compte des épreuves où l'aide de l'IA peut vous mener la plupart du chemin, et des épreuves où elle vous fait sonner comme un fraudeur. Le tableau ci-dessous est ce que nous disons à nos propres utilisateurs.

Feature	SQL	Statistiques	Tests A/B	Étude ML	Produit / métrique	Comportemental
Qualité de l'aide IA	Excellent	Bonne	Forte	Forte	Modérée	Forte
Exigence de latence	< 200 ms (codage en direct)	Conversationnelle	Conversationnelle	Conversationnelle	Conversationnelle	Conversationnelle
Exigence de discrétion	Élevée (partage d'écran)	Moyenne	Moyenne	Moyenne	Moyenne	Moyenne
Confort éthique	Contesté	Confortable	Confortable	Confortable	Confortable	Appel personnel
Mode d'utilisation recommandé	Script proche du verbatim	Aide à la réflexion	Prompt de cadre	Esquisse + vous complétez	Brainstorm ; défendez-vous	Esquisse uniquement — dites-le de votre voix

Le résumé honnête : les épreuves SQL sont l'endroit où l'assistance IA est la plus proche de prendre le travail à sa charge — la syntaxe est rigide, la distance d'édition entre le prompt et la requête fonctionnelle est faible, et les bons assistants comme Acedly lisent directement l'éditeur. Lors des épreuves de statistiques et de tests A/B, l'IA est extrêmement utile pour mettre en évidence le bon cadre et le bon test, mais vous devez toujours défendre votre réponse quand l'enquêteur creuse. Lors des épreuves produit/métrique, l'IA est un partenaire de brainstorm mais ne peut pas défendre la réponse pour vous — l'enquêteur vous demandera « pourquoi ce segment, pas celui-ci ? » et vous avez besoin d'avoir une opinion. Lors des épreuves comportementales, l'IA peut produire une structure (situation-tâche-action-résultat) mais le contenu doit être le vôtre, de votre voix, sinon cela sonnerait préparé.

Acedly lors d'une épreuve DS en direct

Acedly est conçu pour les entretiens humains en direct où vous contrôlez votre transparence. Spécifiquement, pour les épreuves de data scientist, trois choses importent :

Latence. La latence de bout en bout médiane est d'environ 98 ms — mesurée de la fin de l'énoncé au premier token rendu. Ce budget est particulièrement important dans l'épreuve SQL, où l'écart entre « l'IA aide » et « l'IA est trop lente pour aider » est la différence entre écrire votre propre réponse et copier la sienne.

Lecture de l'éditeur de plateforme de codage. La plupart des épreuves SQL DS s'exécutent sur Coderpad ou HackerRank — deux surfaces vérifiées où Acedly lit l'énoncé du problème, le schéma et la requête partielle écrite par le candidat, et les utilise tous trois comme contexte d'ancrage. Un copilote qui n'écoute que l'audio ignore le schéma, ce qui signifie des suggestions SQL moins bonnes.

Routage multi-modèle. Les questions SQL sont acheminées vers DeepSeek pour la génération de code ; les questions de stats et de probabilité sont acheminées vers Claude pour la qualité du raisonnement ; les épreuves produit/métrique sont acheminées vers GPT pour le contexte commercial plus large. Le routeur sélectionne par question, pas par session.

Huit plateformes vérifiées. Zoom, Microsoft Teams, Google Meet, Webex, Lark/Feishu, Amazon Chime, Coderpad, HackerRank. Ensemble, elles couvrent environ 95% des surfaces d'entretien DS professionnelles en 2026.

12+ langages de programmation, y compris SQL. Python, R, SQL (dialectes PostgreSQL, MySQL, BigQuery, Snowflake), Scala, Java, JavaScript/TypeScript, Go, Rust, C++, Julia, MATLAB, Bash. La détection du dialecte SQL est importante car la syntaxe de la fonction fenêtre diffère légèrement entre Postgres et MySQL.

Un plan de préparation d'entretien DS sur quatre semaines

Si vous avez quatre semaines, le calendrier ci-dessous est une allocation viable. Ajustez la pondération si vous visez une voie non standard.

Semaine 1 — Entraînement SQL. Deux heures par jour. Cinquante problèmes sur StrataScratch ou DataLemur, privilégiant les fonctions de fenêtre, les patterns de rétention/cohorte et les requêtes d'entonnoir. Chaque problème obtient un post-mortem d'une phrase : quel pattern, quelle fonction de fenêtre, quelle était la granularité. À la fin de la semaine, vous devriez être capable de reconnaître top-N-per-group dès la première phrase.

Semaine 2 — Statistiques, probabilités et test A/B. Une heure de théorie (révision des distributions, test d'hypothèse, Bayes), une heure de pratique — travaillez sur dix invites de test A/B classiques (taille d'échantillon, effets de nouveauté, effets de réseau, dilution). Pratiquez la rubrique en sept étapes à haute voix jusqu'à ce qu'elle devienne automatique. Lecture : Trustworthy Online Controlled Experiments de Kohavi, Tang, Xu couvre presque tout ce qui est demandé.

Semaine 3 — Cas de pratique produit et métrique. Trois cas de pratique par jour, 30 minutes chacun, sur une variété de métriques. La baisse du DAU, le déclin de l'engagement, la baisse du taux de conversion, le pic de churn. Utilisez le framework métrique-arborescence à chaque fois. Enregistrez-vous ; rejouez-le ; les trois premiers sont mauvais, le dixième est automatique.

Semaine 4 — Spécifique à l'entreprise. Si vous visez Meta, entraînez-vous sur les cas de produit de la voie Decode and Conquer. Si vous visez Google, élargissez sur les cas SQL, stats et ML. Si vous visez Amazon, préparez un portfolio mappé LP de deux histoires par principe. Les dernières 48 heures : repos. Problèmes plus légers, sommeil, le rafraîchissement mental de reconnaître que vous avez fait le travail.

L'habitude à plus haut effet de levier, chaque semaine : écrivez un post-mortem d'une phrase pour chaque problème que vous résolvez. Après 50 problèmes, vous aurez un tableau roulant de votre propre historique de reconnaissance de patterns. Après 100, vous diagnostiquerez les chutes de DAU dans votre sommeil.

Questions fréquemment posées

Combien de temps dois-je me préparer pour un entretien de data scientist ?

Dois-je connaître le deep learning pour obtenir une offre DS en 2026 ?

SQL vs Python : lequel est testé davantage dans les entretiens DS ?

Quelle est la différence entre les entretiens product DS et ML-applied DS ?

Puis-je utiliser un assistant IA lors d'une session SQL en direct ?

Quelles entreprises embauchent encore DS en 2026 ?