Banque de questions d’entretien d’embauche

Pouvez-vous m’expliquer le compromis biais-variance, et comment il se manifeste dans un vrai projet ?

Définissez chaque terme en une phrase, puis ancrez-les dans une décision concrète : par exemple, vous avez choisi un modèle de gradient boosting moins profond parce que l’erreur de validation augmentait avec la profondeur alors que l’erreur d’entraînement continuait de baisser. Concluez sur la façon dont vous l’avez diagnostiqué (courbes d’apprentissage, écart en validation croisée) plutôt que de réciter la théorie.

Comment gérez-vous les données manquantes dans un jeu de données ?

Montrez une démarche de décision, pas une astuce unique : quantifiez d’abord les valeurs manquantes et déterminez si elles sont aléatoires (MCAR/MAR/MNAR), puis adaptez le remède — supprimer, imputer (moyenne/médiane, imputation par modèle) ou traiter l’absence elle-même comme une variable. Évoquez la fuite de données : les paramètres d’imputation doivent être appris sur le seul jeu d’entraînement.

Comment évaluez-vous un modèle de machine learning, au-delà de l’accuracy ?

Choisissez les métriques en fonction du coût métier des erreurs : précision/rappel et PR-AUC pour les classes déséquilibrées, calibration quand les probabilités alimentent des décisions, et une comparaison avec une référence (classe majoritaire, heuristique actuelle). Les bonnes réponses ajoutent une analyse par segment — la performance par sous-population, pas seulement le chiffre global.

Racontez-moi une situation où votre analyse a conduit à une vraie décision business.

Utilisez la méthode STAR avec des chiffres : l’enjeu, ce que vous avez fait différemment de l’approche évidente, et le résultat mesuré (« le modèle de churn a priorisé 20 % des comptes, les dépenses de rétention ont baissé de 15 % »). Les recruteurs creusent le suivi : dites comment vous saviez que l’impact était causal (groupe témoin, test A/B, double différence).

Comment expliqueriez-vous un modèle complexe à des interlocuteurs non techniques ?

Montrez au lieu de décrire : prenez un modèle et traduisez-le en direct (« le modèle note chaque client un peu comme un score de crédit ; ce sont ces trois facteurs qui le font le plus bouger »). Citez les outils que vous utilisez vraiment — des résumés SHAP traduits en facteurs explicatifs en langage courant, ou une note de décision d’une page au lieu d’un notebook.

Comment abordez-vous la détection d’anomalies dans un grand jeu de données ?

Structurez ainsi : définissez d’abord ce qui est « normal » (saisonnalité, segments), puis choisissez une méthode adaptée aux étiquettes disponibles — seuils statistiques ou isolation forests sans étiquettes, modèles supervisés quand les incidents sont étiquetés. Dites comment vous maîtrisez le budget de faux positifs, car la lassitude face aux alertes tue ces systèmes.

Comment concevez-vous et analysez-vous un test A/B ?

Couvrez tout le parcours : hypothèse et métrique principale fixées dès le départ, analyse de puissance pour dimensionner l’échantillon, unité de randomisation choisie pour éviter les interférences, et règle d’arrêt définie à l’avance. Les signaux de séniorité, ce sont les pièges — regarder les résultats trop tôt, les comparaisons multiples, l’effet de nouveauté — et un exemple où le résultat d’un test vous a surpris.

Pouvez-vous me décrire votre démarche de feature engineering ?

Ancrez-la dans un projet : comment la connaissance du métier vous a suggéré des variables candidates, comment vous avez traité les variables catégorielles et temporelles (target encoding, décalages, fenêtres), et comment vous avez vérifié qu’une variable méritait sa place (importance plus ablation, pas une simple impression). Évoquez les contrôles de fuite de données : les variables calculées avec des informations futures sont le tueur silencieux classique.

Quand choisissez-vous SQL plutôt que Python ou R ?

Montrez une répartition pragmatique : SQL pour extraire, joindre et agréger à la source (en laissant l’entrepôt de données faire le calcul), Python/R dès qu’il faut des statistiques, de la modélisation ou des graphiques. Les meilleures réponses évoquent un va-et-vient délibéré entre les deux — « je prototype en pandas, puis je renvoie les gros groupby dans SQL » — plutôt que la fidélité à un seul outil.

Comment surveillez-vous un modèle en production ?

Nommez les trois niveaux : la santé du service (latence, erreurs), la dérive des données (distributions en entrée par rapport à l’entraînement) et la dégradation des performances (prédictions comparées à la vérité terrain, qui arrive avec retard). Dites ce qui déclenche un réentraînement et qui reçoit l’alerte. Une histoire concrète — « notre modèle de détection de fraude s’est dégradé après qu’un changement produit a modifié les variables » — vaut mieux qu’un catalogue d’outils de monitoring.

Les utilisateurs actifs quotidiens de notre appli ont baissé. Comment menez-vous l’enquête ?

Structurez d’abord : clarifiez l’ampleur et la période, écartez les bugs de mesure, puis segmentez (plateforme, pays, cohorte, canal d’acquisition) pour isoler l’endroit où se situe la baisse. Seulement ensuite, formulez des hypothèses — une nouvelle version, une pause marketing, la saisonnalité, un concurrent. Terminez par le test le plus rapide pour écarter une hypothèse, pas par une liste exhaustive.

Comment priorisez-vous les fonctionnalités d’une roadmap produit ?

Citez un cadre (RICE, impact/effort), mais montrez aussitôt ses limites : les scores reposent sur des hypothèses, alors dites comment vous les mettez à l’épreuve — des preuves utilisateurs pour la portée, des spikes techniques pour l’effort. Les bonnes réponses incluent une chose à laquelle vous avez délibérément dit non, et la raison stratégique de ce refus.

Parlez-moi d’une décision produit où les données et votre intuition ne disaient pas la même chose.

Cette question évalue votre jugement. Choisissez un cas réel : la métrique disait une chose, les signaux qualitatifs une autre ; expliquez à quoi vous vous êtes fié et pourquoi (la métrique n’était qu’un indicateur indirect, l’échantillon était biaisé, court terme contre long terme). La fin crédible, c’est ce que vous avez fait pour trancher — une expérience peu coûteuse, pas un pari à l’aveugle.

Comment mesurez-vous le succès d’un produit après son lancement ?

Reliez les métriques à l’objectif du lancement : adoption (taux d’activation), profondeur d’usage (fréquence, courbe de rétention) et résultat business (chiffre d’affaires, coûts). Distinguez indicateurs avancés et retardés, fixez un point d’étape avant le lancement et dites quel résultat vous ferait revenir en arrière : s’engager à l’avance, c’est ce qui sépare la rigueur de la justification après coup.

Comment gérez-vous une demande de fonctionnalité qui va à l’encontre de votre vision produit ?

Montrez du respect et de la fermeté : creusez le problème sous-jacent (la demande est une solution proposée, pas le besoin), mesurez qui d’autre le rencontre, puis répondez au besoin d’une façon cohérente avec la vision, ou expliquez le compromis que vous protégez. Faites remonter la question avec des options et une recommandation, jamais avec un non sec.

Comment faites-vous pour garder les équipes techniques et business alignées ?

Des mécanismes concrets valent mieux que des banalités : une source de vérité unique et écrite pour les priorités, des développeurs présents dans les entretiens de discovery pour que le contexte circule tôt, et une traduction dans les deux sens — les demandes business présentées comme des problèmes utilisateurs, les contraintes techniques comme des choix de périmètre et de délai. Donnez un exemple où l’alignement s’est rompu et ce que vous avez changé.

Quelles métriques définiriez-vous pour un tout nouveau produit ?

Structurez selon le cycle de vie : une métrique « North Star » liée à la valeur délivrée, puis des métriques secondaires tout au long du funnel — acquisition, activation (définissez précisément le moment « aha »), rétention — et une métrique garde-fou qui vous empêche de tricher sur les autres. Expliquez pourquoi les métriques de vanité (téléchargements, pages vues) sont exclues, et comment l’ensemble évolue après le product-market fit.

Pouvez-vous estimer la taille du marché pour ce produit ?

Le chiffre compte moins que l’échafaudage : annoncez votre approche (top-down à partir de la population ou bottom-up à partir de l’usage), énoncez vos hypothèses à voix haute, gardez des calculs simples et confrontez le résultat à un repère connu. Terminez en indiquant quelle hypothèse fait le plus varier la réponse — c’est la partie que les recruteurs notent vraiment.

Choisissez un produit que vous trouvez mal conçu. Comment l’amélioreriez-vous ?

Choisissez quelque chose que vous utilisez vraiment — pas le produit de l’entreprise qui vous reçoit. Faites un diagnostic avec un cadre (qui est l’utilisateur, à quel besoin le produit répond pour lui, où il échoue), proposez un ou deux changements ciblés et définissez la métrique qui prouverait que l’amélioration a fonctionné. Une critique sans métrique de succès passe pour une question de goût, pas pour de la réflexion produit.

Comment communiquez-vous les besoins aux développeurs ?

Décrivez votre document écrit (PRD, one-pager) et ce qu’il fixe : le problème, l’utilisateur, les métriques de succès et les contraintes — en laissant volontairement le « comment » à l’équipe technique. Évoquez les boucles de retour qui l’entourent : une revue de lancement où les développeurs cherchent les failles, et des critères d’acceptation assez concrets pour que « terminé » ne soit pas sujet à débat.

Décrivez-moi une campagne marketing réussie que vous avez menée.

Structure : objectif → insight sur l’audience → choix du canal → résultat avec attribution. Ce qui fait la différence, c’est l’insight (« nous avons vu que les inscriptions bondissaient sur les recherches comparatives, alors nous avons créé du contenu comparatif ») et l’honnêteté sur ce que vous feriez autrement. Une histoire de campagne sans groupe témoin ni point de référence ne sert que de décor.

Comment mesurez-vous l’efficacité d’une campagne ?

Présentez le funnel que vous avez instrumenté : portée → engagement → conversion → rétention/LTV, avec le KPI principal fixé avant le lancement. Abordez l’attribution de front (rigueur sur les UTM, zones géographiques témoins, tests d’incrémentalité plutôt que dernier clic) : nommer les limites de votre mesure, c’est ce que les recruteurs expérimentés attendent.

Comment menez-vous la segmentation et le ciblage d’un marché ?

Présentez une vraie segmentation : les données sur lesquelles vous avez construit vos groupes (le comportemental l’emporte sur le démographique), comment vous avez vérifié que les segments étaient actionnables (un message, un canal ou un prix différent les fait vraiment réagir), et comment le ciblage a modifié les dépenses. Évitez les réponses en quatre cases tirées d’un manuel, sans données derrière.

Quels outils et plateformes de marketing digital utilisez-vous, et pourquoi ceux-là ?

Regroupez-les par usage plutôt que d’aligner des logos : analytics (GA4 + un outil d’analytics produit), SEO (Search Console + un outil de suivi de positions et de mots-clés), automatisation/CRM et tests de créations. Pour chacun, une phrase sur une décision que l’outil a réellement changée — des outils que vous ne pouvez relier à aucune décision font remplissage de CV.

Comment utilisez-vous les données pour optimiser une campagne qui ne performe pas ?

Montrez l’ordre du diagnostic : vérifiez d’abord le tracking, puis décomposez le funnel pour trouver l’étape défaillante (CTR correct mais conversion faible → la page de destination, pas l’annonce). Décrivez un test structuré que vous avez mené (audience, création ou offre — une seule variable), le résultat et les critères d’arrêt fixés à l’avance.

Comment avez-vous optimisé du contenu pour le référencement naturel ?

Montrez la boucle complète : recherche de mots-clés et d’intention, contenu aligné sur l’intention (pas bourré de mots-clés), hygiène technique (balises title, maillage interne, vitesse des pages) et évolution mesurée des impressions et des positions sur plusieurs mois. Bonus si vous dites ce qui n’a pas marché : les histoires de SEO où tout réussit sonnent comme empruntées.

Comment répartissez-vous le budget entre marketing de marque et marketing de performance ?

Montrez que vous comprenez la tension : la performance est mesurable et à cycle court, la marque produit des effets cumulés mais résiste à l’attribution. Ancrez votre répartition dans le stade de l’entreprise et le calcul du retour sur investissement (en phase de démarrage : surtout de la performance jusqu’à ce que le CAC se stabilise ; puis rééquilibrage à mesure que les canaux saturent). Dites comment vous mesureriez malgré tout la marque — volume de recherches, trafic direct, tests géographiques d’incrémentalité.

Comment construiriez-vous une stratégie de contenu à partir de zéro ?

Présentez les étapes : d’abord la recherche sur l’audience et les intentions, une architecture de sujets resserrée (quelques piliers, pas cinquante articles éparpillés), un rythme de production tenable, une diffusion prévue pour chaque contenu et une boucle de mesure qui élimine ce qui ne marche pas. Ce qui fait la différence, c’est la logique de priorisation — pourquoi ces sujets d’abord — pas la liste des canaux.

Vous avez 10 000 dollars pour le lancement d’un produit. Où les mettez-vous ?

Résistez à l’envie de tout mettre en publicité. Les bonnes réponses répartissent le budget selon l’objectif : une part pour la qualité des créations et de la page de destination, un budget de test sur deux ou trois canaux avec des critères d’arrêt explicites, et une réserve pour miser davantage sur le canal gagnant. Montrez le calcul par canal (CPC attendu → conversions) et ce que vous feriez autrement avec 100 000 dollars.

À quoi ressembleraient vos 90 premiers jours à ce poste ?

Structurez en trois temps : apprendre (auditer les funnels, rencontrer les équipes commerciales et produit, lire les données avant de changer quoi que ce soit), des victoires rapides (une ou deux corrections à l’impact visible — souvent l’hygiène du tracking ou une page peu performante), puis un plan avec des responsables et des métriques. Cette question teste le discernement et l’humilité ; arriver avec un plan d’action rigide ne montre ni l’un ni l’autre.

Expliquez-moi pas à pas comment vous menez une analyse DCF.

Déroulez la mécanique dans l’ordre — projeter les flux de trésorerie disponibles, choisir un taux d’actualisation (le WACC et la façon dont vous l’avez construit), la valeur terminale (croissance perpétuelle ou multiple de sortie), actualiser et additionner — puis montrez votre jugement : à quelle hypothèse la valorisation est la plus sensible, et comment vous la recoupez avec des multiples. La mécanique sans analyse de sensibilité sonne comme apprise par cœur.

Comment analysez-vous les états financiers pour évaluer la santé d’une entreprise ?

Reliez les trois états au lieu d’aligner des ratios : la tendance de la rentabilité (compte de résultat), la conversion en trésorerie (flux de trésorerie face au résultat net — un écart entre les deux est le signal d’alarme classique) et l’endettement/la liquidité (bilan). Citez les 3 ou 4 ratios par lesquels vous commencez vraiment, et une fois où un ratio racontait une histoire trompeuse.

Parlez-moi de votre expérience en budget et en prévisions.

Décrivez le rythme dont vous étiez responsable (budget annuel, prévisions glissantes), votre méthode (une approche par les inducteurs vaut mieux qu’une extrapolation ligne à ligne) et votre précision : les analyses d’écarts que vous avez menées, votre plus grosse erreur et le changement de processus qu’elle a entraîné. Les recruteurs cherchent à savoir si vos prévisions ont nourri de vraies décisions ou seulement des présentations.

Décrivez-moi un problème business complexe que vous avez analysé. Quelle a été votre démarche ?

Choisissez un problème réellement ambigu. Montrez les étapes : définir précisément la question, la décomposer en facteurs, rassembler les données (et traiter honnêtement leurs lacunes), tester l’hypothèse principale et aboutir à une recommandation que quelqu’un a mise en œuvre. La phrase à mériter : « voici ce sur quoi je me serais trompé sans les données ».

Comment garantissez-vous la justesse et la fiabilité de vos analyses ?

Citez des habitudes concrètes : rapprocher les totaux d’une source indépendante, intégrer des contrôles de cohérence dans les modèles (contrôles d’équilibre, tests d’ordre de grandeur), versionner et documenter les hypothèses, et faire casser votre modèle par quelqu’un d’autre avant de le livrer. Reconnaître une erreur repérée tardivement — et le contrôle ajouté depuis — passe mieux que de prétendre n’en faire aucune.

Quels outils utilisez-vous pour vos analyses, et comment les choisissez-vous ?

Adaptez l’outil à la tâche : Excel pour les modèles que d’autres doivent auditer, SQL pour extraire et remodeler les données à la source, Python/R quand l’analyse demande des statistiques ou de l’automatisation, un outil de BI (Tableau/Power BI) pour les vues récurrentes en libre-service. Une histoire de migration (« j’ai passé un reporting Excel hebdomadaire en SQL + tableau de bord, et économisé N heures ») le prouve.

Décrivez-moi la requête SQL la plus complexe que vous ayez écrite.

Choisissez-en une qui a une vraie structure — CTE en plusieurs étapes, fonctions de fenêtrage ou dédoublonnage délicat — et racontez la question business à laquelle elle répondait, pas seulement la syntaxe. Expliquez une décision de performance (pourquoi vous avez filtré tôt, ce que coûtait l’ordre des jointures) et comment vous avez vérifié le résultat par rapport à un total connu. La complexité sans vérification est un signal d’alerte, pas un exploit.

Expliquez-moi en détail une analyse d’écarts que vous avez menée.

Montrez votre rigueur de décomposition : réel contre budget, ventilé en effets prix, volume et mix (ou les inducteurs équivalents dans votre domaine), en isolant la contribution de chaque facteur. Puis la couche de jugement : quels écarts relevaient du bruit et lesquels étaient un vrai signal, et quelle décision l’analyse a changée. Terminez par la façon dont le processus a amélioré le cycle de prévision suivant.

Comment construisez-vous un tableau de bord de KPI que la direction utilise vraiment ?

Partez des décisions, pas des données : interrogez votre public sur les trois questions qu’il se pose chaque semaine, mettez-les en haut avec des objectifs et des tendances, et reléguez tout le reste dans des vues détaillées. Évoquez la partie opérationnelle — la fraîcheur des données, un responsable unique par définition de métrique, et la suppression des graphiques que personne n’ouvre. L’adoption est la métrique de succès du tableau de bord lui-même.

Parlez-moi d’une fois où votre analyse était fausse.

Choisissez une erreur aux conséquences réelles, expliquez comment elle est passée (mauvaise jointure, biais du survivant, hypothèse périmée) et — c’est la partie notée — comment elle a été repérée et quel contrôle existe aujourd’hui grâce à elle. Assumer l’erreur et institutionnaliser la correction fait senior ; prétendre n’avoir jamais livré un chiffre faux montre un manque de recul.

Parlez-moi de vous.

Présent → passé → futur, en 90 secondes : ce que vous faites aujourd’hui (une phrase avec votre périmètre), les deux ou trois expériences qui ont forgé la compétence dont ce poste a besoin, et pourquoi ce poste est la suite logique. Adaptez la partie centrale à l’offre d’emploi ; ne récitez pas votre CV dans l’ordre chronologique.

Rédigez la vôtre à partir de votre CV avec le générateur gratuit →

Parlez-moi d’un échec que vous avez connu.

Choisissez un vrai échec, avec de vrais enjeux (pas « je travaille trop »), assumez votre part précise, et consacrez l’essentiel de la réponse au système que vous avez changé ensuite. Le recruteur teste si vous savez transformer un échec en méthode : terminez par une réussite ultérieure qui s’appuie sur cette nouvelle méthode.

Racontez-moi un conflit avec un collègue, et comment vous l’avez résolu.

Restez sur un désaccord professionnel, pas sur un drame personnel. Montrez que vous avez d’abord cherché à comprendre son raisonnement, trouvé l’objectif commun et opté pour un moyen de trancher (des données, un essai, une décision claire soumise à la hiérarchie). Ne faites jamais de l’autre personne le méchant de l’histoire : le recruteur s’imagine à la place de ce collègue.

Pourquoi voulez-vous travailler chez nous ?

Deux niveaux : quelque chose de précis sur l’entreprise que vous ne pouvez savoir qu’en vous étant renseigné (orientation produit, un lancement, un article de l’équipe technique), relié à votre propre parcours. Les compliments génériques (« super culture d’entreprise ») trahissent une candidature envoyée en masse ; la précision fait toute la différence.

Racontez-moi une situation où vous avez su entraîner les autres sans autorité hiérarchique.

Choisissez une situation transverse : vous avez repéré le manque, créé l’adhésion en facilitant les objectifs des autres (et non en faisant d’abord remonter le problème) et livré un résultat chiffrable. Cette question évalue votre capacité d’influence : COMMENT vous avez convaincu compte plus que le résultat.

Où vous voyez-vous dans cinq ans ?

Montrez un cap sans script rigide : la compétence que vous voulez approfondir, le périmètre vers lequel vous voulez évoluer, et en quoi ce poste vous en rapproche. Les entreprises évaluent le risque de départ et votre lucidité sur vous-même, pas une prédiction précise de l’organigramme.

Quel est votre plus grand défaut ?

Choisissez un vrai défaut qui ne soit pas rédhibitoire (et pas une qualité déguisée), puis consacrez les deux tiers de la réponse à la façon dont vous le gérez : l’habitude ou la méthode concrète que vous avez mise en place, et un signe mesurable que cela fonctionne. La question teste la lucidité et la capacité à progresser — « je suis perfectionniste » échoue sur les deux tableaux.

Parlez-moi d’une fois où vous n’étiez pas d’accord avec votre manager.

Montrez un désaccord constructif : vous n’étiez pas d’accord sur le fond, vous avez défendu votre point de vue avec des preuves, en privé, puis — quelle que soit l’issue — vous avez pleinement soutenu la décision. Incluez un cas où vous aviez tort et l’avez reconnu. Les recruteurs cherchent à la fois du caractère et de l’ouverture au feedback ; les histoires avec un méchant échouent.

Racontez-moi une situation où vous avez dû livrer dans des délais très serrés.

La compétence évaluée, c’est l’arbitrage du périmètre, pas l’héroïsme. Expliquez comment vous avez réduit le travail à l’essentiel, communiqué tôt sur les compromis et livré ce qui comptait — puis ce que vous avez remis au propre ensuite. Les histoires de nuits blanches sans décision de priorisation passent pour un manque d’organisation, pas pour du dévouement.

Pourquoi quittez-vous votre poste actuel ?

Tournez-vous vers l’avenir : une phrase honnête et neutre sur la limite que vous avez atteinte (périmètre, évolution, orientation), puis passez à ce que ce poste offre et que l’actuel ne peut pas offrir. Ne dénigrez jamais votre employeur : le recruteur projette tout ce que vous dites sur la façon dont vous parlerez un jour de son entreprise. Restez sous les trente secondes.

Présentez-moi un système que vous avez conçu de bout en bout. Que changeriez-vous aujourd’hui ?

Commencez par la contrainte qui a guidé la conception (profil du trafic, budget de latence, taille de l’équipe, échéance), pas par la liste des technologies. Le signal de séniorité : une chose qui a cassé en production et ce qu’elle vous a appris, plus une frontière précise que vous traceriez autrement aujourd’hui.

Parlez-moi du bug le plus difficile que vous ayez eu à corriger.

La valeur est dans la méthode, pas dans le symptôme : comment vous avez circonscrit le problème (bisection, logs, reproduction fiable) et quelle hypothèse s’est révélée fausse. Terminez par ce que vous avez changé pour que ce type de bug se repère plus vite la prochaine fois.

Comment arbitrez-vous entre livrer vite et bien faire les choses ?

Répondez avec un vrai compromis que vous avez fait et le critère de réversibilité derrière : une décision irréversible mérite la semaine de plus, une décision réversible en général non. Dites si le nettoyage promis a vraiment eu lieu — reconnaître que non est plus crédible que de faire semblant.

Parlez-moi d’une revue de code où vous n’étiez pas d’accord avec l’auteur.

Montrez que vous séparez le goût du fond. Appuyez-vous sur quelque chose d’extérieur — une catégorie de bugs, un contrat, un benchmark — plutôt que sur une préférence, et dites comment le désaccord s’est réglé : un test qui a tranché, une session en binôme, ou le fait que vous ayez cédé.

Comment abordez-vous les tests sur du code que vous n’avez pas écrit ?

D’abord des tests de caractérisation pour figer le comportement actuel, puis de la couverture sur les chemins qui portent réellement un risque. Dites ce que vous avez décidé de NE PAS tester : traiter la couverture comme un budget plutôt que comme un objectif, c’est la réponse d’une personne expérimentée.

Parlez-moi d’un incident de production dont vous étiez responsable.

Donnez la chronologie, montre en main : détection, atténuation, cause racine, prévention. Les recruteurs vérifient si vous avez arrêté l’hémorragie avant d’avoir entièrement compris la cause — c’est généralement le bon ordre — et si une action de prévention a bien été livrée.

Comment évitez-vous qu’un gros refactoring s’enlise ?

Décrivez comment vous le gardez livrable à chaque étape : migrer une tranche derrière une interface, faire tourner les deux chemins, supprimer l’ancien. Nommez la métrique qui vous a montré que ça fonctionnait et la partie que vous avez délibérément laissée non migrée.

Quelle décision technique de votre équipe ne partagez-vous pas ?

Choisissez-en une vraie et présentez honnêtement l’autre point de vue, y compris la raison pour laquelle l’équipe l’a retenue. Terminer par l’expérience qui permettrait de trancher fait meilleure impression que la certitude.

Comment validez-vous un jeu de données que vous n’avez jamais vu ?

Donnez la check-list que vous suivez vraiment : nombre de lignes comparé à la source, unicité des clés, couverture des dates, profil des valeurs nulles et aberrantes, puis rapprochement avec un chiffre auquel quelqu’un fait déjà confiance. La vraie compétence, c’est ce que vous faites quand le rapprochement échoue : dites-le à voix haute.

Un indicateur du tableau de bord a chuté de 20 % du jour au lendemain. Racontez-moi votre première heure.

Vérifiez l’instrumentation avant le business : une panne de pipeline et une vraie baisse se ressemblent trait pour trait sur un graphique. Ensuite, segmentez — plateforme, région, nouveaux ou anciens utilisateurs — et confrontez le tout au calendrier des mises en production et des campagnes. Évoquer d’abord l’hypothèse d’un bug de tracking, c’est ce qui trahit l’expérience.

Comment choisissez-vous la métrique qui doit compter pour une équipe ?

Reliez-la à une décision qu’elle fera changer. Une bonne réponse nomme la métrique, la façon dont on peut la manipuler, et la métrique garde-fou que vous lui associez pour que personne n’optimise l’entreprise jusque dans une impasse.

Racontez-moi une situation où votre analyse a fait changer quelqu’un d’avis.

Utilisez la méthode STAR et gardez la résistance dans l’histoire : qui n’était pas d’accord, quelle preuve précise l’a fait changer d’avis, et ce que vous auriez fait si cela n’avait pas suffi. Une analyse qui n’a rencontré aucune friction a rarement compté.

Comment expliquez-vous l’incertitude statistique à un interlocuteur non technique ?

Traduisez-la en langage de décision — en gros, quelle fourchette de résultats, et ce que vous feriez à chaque extrémité — au lieu de mettre une p-value sur une slide. Dites explicitement ce qu’un résultat nul signifierait pour le plan.

Une requête qui tournait en quelques secondes prend maintenant plusieurs minutes. Que faites-vous ?

Lisez le plan d’exécution avant de réécrire quoi que ce soit : filtrer tôt, indexer les colonnes sur lesquelles vous filtrez, réduire le nombre de lignes avant les jointures et matérialiser ce qui tourne chaque jour. Mentionnez le cas où la bonne correction se trouvait en amont, dans le modèle de l’entrepôt de données, plutôt que dans la requête.

Comment gérez-vous une demande à laquelle les données ne peuvent pas répondre ?

Dites-le tôt, puis proposez la question la plus proche à laquelle les données peuvent répondre, ainsi que le coût pour répondre à la vraie — de l’instrumentation, une enquête, un groupe témoin. Livrer discrètement un indicateur de substitution trompeur, c’est l’échec typique ici.

Parlez-moi d’un rapport que vous avez créé et que personne n’a utilisé.

Soyez honnête, puis faites le diagnostic : pas de responsable, mauvaise fréquence, ou il répondait à une question sur laquelle personne n’est évalué. La meilleure version se termine par ce que vous avez supprimé, ou par ce qui l’a remplacé.

Parlez-moi d’un projet qui a pris du retard. Qu’avez-vous fait ?

Dites quand vous l’avez su, qui vous avez prévenu et ce que vous avez retiré du périmètre. Alerter tôt en proposant des options vaut mieux qu’un sauvetage héroïque à la fin, et les recruteurs écoutent lequel des deux vous avez fait.

Comment rédigez-vous un point d’avancement que les gens lisent vraiment ?

Les décisions d’abord, les risques avec un responsable nommé et une date, puis ce qui a changé depuis la dernière fois. Dites comment vous restez honnête quand les nouvelles sont mauvaises : un statut qui reste vert jusqu’au jour où il passe au rouge apprend aux gens à l’ignorer.

Deux équipes ont besoin du même développeur au prochain sprint. Que faites-vous ?

Portez l’arbitrage à la personne qui fixe les priorités, avec chaque option chiffrée en dates plutôt qu’en adjectifs. Évitez la non-réponse qui consiste à parler aux deux parties en espérant que ça s’arrange.

Comment gérez-vous une partie prenante qui n’arrête pas d’élargir le périmètre ?

Rendez l’arbitrage visible au lieu de refuser : « oui, et voici la nouvelle date que cela implique — que préférez-vous ? ». Mentionnez le journal écrit des changements qui évite que la même conversation se répète.

Parlez-moi d’un risque que vous avez repéré avant qu’il ne devienne un problème.

La façon dont vous l’avez repéré compte : cartographie des dépendances, pre-mortem, ou un développeur discret que vous avez mis en confiance pour qu’il ose parler. Puis la mesure d’atténuation et ce qu’elle a coûté.

Comment savez-vous qu’un projet est vraiment dans les temps ?

Préférez les indicateurs avancés — dépendances ouvertes, délai de relecture, variations du périmètre — aux couleurs de statut, et rappelez qu’une démo qui fonctionne vaut mieux qu’un pourcentage d’avancement.

Racontez-moi une situation où vous avez dû annoncer une mauvaise nouvelle à la direction.

Structure : le message principal, la cause, les options avec leur coût, votre recommandation. Dites comment vous avez évité de l’enterrer en slide quatorze.

Comment clôturez-vous un projet ?

Des critères d’acceptation vérifiés, un responsable désigné pour la suite, et un retour d’expérience qui a changé exactement une chose. Les projets jamais clôturés, c’est ainsi que les équipes accumulent du travail invisible.

Racontez-moi une affaire que vous avez perdue, et pourquoi.

Donnez la vraie raison plutôt que le prix, qui n’est généralement que le symptôme. La version crédible se termine par ce que vous avez changé dans votre qualification pour que la même perte ne se reproduise pas.

Comment qualifiez-vous une opportunité ?

Utilisez votre méthode comme une check-list, pas comme un script : qui signe, ce qui casse si le client ne fait rien, et la date qui impose une décision. Dites quelles affaires vous avez disqualifiées et combien de temps cela vous a fait gagner.

Un prospect ne donne plus de nouvelles après une très bonne démo. Que faites-vous ?

Partez du principe que ses priorités ont changé, plutôt que d’y voir de l’impolitesse. Décrivez comment vous multipliez les contacts en allant vers un deuxième interlocuteur, une relance vraiment utile, et la relance de clôture honnête — demander s’il faut clore le dossier obtient souvent une réponse.

Comment répondez-vous à l’objection « vous êtes trop cher » ?

Recadrez par rapport au coût du statu quo, chiffré avec les données du client, et n’accordez jamais de remise sans obtenir quelque chose en échange. Citer une affaire à laquelle vous avez renoncé rend votre réponse crédible.

Parlez-moi de votre négociation la plus difficile.

Distinguez la position de votre interlocuteur de son véritable intérêt, puis dites quelle concession vous avez échangée et laquelle vous avez refusée. Les recruteurs veulent savoir si vous avez préservé à la fois la relation et la marge.

Comment construisez-vous un pipeline sur un territoire entièrement nouveau ?

Segmentez, choisissez l’angle d’attaque où vous gagnerez le plus vite, puis organisez vos séquences de prospection. Donnez vos vrais chiffres — nombre de contacts, taux de réponse, rendez-vous obtenus — car les réponses vagues sur l’activité équivalent à une absence de réponse.

À quoi ressemblent vos 30 premiers jours sur un nouveau produit ?

Lisez les cinq dernières affaires gagnées et perdues, apprenez le moment de la démo qui fait mouche, et trouvez un binôme technique. Dites ce que vous seriez capable de faire seul au bout de 30 jours.

Parlez-moi d’une prévision que vous avez ratée.

Expliquez comment vous distinguez les affaires engagées du meilleur scénario, quel signal vous avez surpondéré et quelle discipline vous avez ajoutée ensuite. L’honnêteté des prévisions, c’est l’essentiel du métier.

Parlez-moi d’un client mécontent que vous avez réussi à reconquérir.

Reconnaissez le problème, prenez la responsabilité du calendrier, puis dites ce qui a réellement changé — un correctif, un avoir, un processus. Ce qui intéresse le plus les recruteurs, c’est le suivi une fois l’incendie éteint.

Comment priorisez-vous quand cinq tickets sont tous urgents ?

L’impact multiplié par l’étendue des dégâts, au regard des engagements contractuels. Dites qui vous avez prévenu pour les tickets que vous avez fait passer après, car une dépriorisation silencieuse transforme une file d’attente en réclamation.

Un client demande une fonctionnalité qui ne sera jamais développée. Que lui dites-vous ?

Soyez direct plutôt que de donner de faux espoirs, puis répondez au besoin de fond avec ce qui existe déjà. Consignez la demande avec son impact business, pour que l’équipe produit voie une tendance plutôt qu’un souhait.

Comment repérez-vous un client sur le point de résilier ?

Baisse de l’usage au niveau des administrateurs, départ de votre allié chez le client, changement de ton dans les tickets, revues annulées. Décrivez ensuite une intervention qui a vraiment fonctionné et une qui n’a pas marché.

Racontez-moi une situation où vous avez tenu tête à votre propre entreprise pour défendre un client.

Exposez l’argumentaire interne et les preuves que vous avez apportées, ainsi que ce que vous avez promis au client tant que rien n’était réglé. Ne rien promettre que vous ne pouviez maîtriser, c’est la version mature.

Comment menez-vous une revue de compte qui apporte vraiment quelque chose au client ?

Commencez par les résultats sur lesquels le client est évalué, pas par votre liste de fonctionnalités. Apportez une recommandation et une demande — une réunion sans demande n’est qu’un point d’avancement.

Parlez-moi d’une erreur qui vous a coûté la confiance d’un client.

Ce que vous lui avez dit, à quelle vitesse, et ce que vous avez changé dans le processus ensuite. La rapidité avec laquelle vous l’avez informé, c’est toute la réponse.

Comment gérez-vous un problème que vous ne pouvez pas régler aujourd’hui ?

Un délai honnête ou l’aveu honnête que vous n’en avez pas, une solution de contournement, et un rythme de points convenu que vous respectez. On perd des comptes à cause du silence bien plus souvent qu’à cause des bugs.

Parlez-moi d’une décision de design qui s’est révélée mauvaise.

Dites comment vous l’avez découvert — recherche, analytics, file du support —, ce que vous avez changé et en combien de temps. Les histoires de portfolio où rien n’échoue jamais sonnent comme de la fiction.

Comment décidez-vous de ce qu’il faut étudier avant de concevoir ?

Choisissez l’hypothèse la plus risquée et adaptez-y la méthode : cinq entretiens pour un « pourquoi », de l’analytics pour un « combien », un questionnaire pour une distribution. Dites ce que vous auriez livré sans cette recherche.

Une partie prenante veut quelque chose qui nuit à l’utilisabilité. Que faites-vous ?

Reformulez son objectif, proposez une alternative qui l’atteint, et suggérez un test peu coûteux plutôt qu’un débat sur les goûts. Dites à quel moment vous faites remonter la question si le désaccord persiste.

Comment recevez-vous les retours lors d’une critique de design ?

Séparez la réaction du diagnostic, et demandez le problème plutôt que la solution proposée. Décrivez comment vous menez une critique quand c’est vous qui donnez les retours.

Comment savez-vous si un design a fonctionné ?

Associez une métrique comportementale à une mesure de réussite de la tâche ou d’effort, et dites ce que vous feriez si le chiffre bougeait pour la mauvaise raison — plus de clics, ce n’est pas toujours mieux.

Racontez-moi une situation où vous avez dû concevoir avec une forte contrainte technique.

Nommez la contrainte, les options que vous avez sacrifiées, et où vous avez délibérément investi la marge de manœuvre qui vous restait. C’est dans les contraintes que le recruteur voit vos priorités.

Comment évitez-vous qu’un design system devienne une camisole de force ?

Des règles qui disent quand on peut s’en écarter, un circuit de contribution réellement utilisé, et un audit qui repère les dérives avant qu’elles ne forment un second système.

Que signifie l’accessibilité dans votre travail au quotidien ?

Soyez concret : contraste, ordre de focus, taille des cibles, libellés exploitables par un lecteur d’écran, et une chose que vous avez repérée en revue le mois dernier. Un engagement vague trahit que rien ne se passe vraiment.