Votre premier recrutement data n'est pas un data scientist : le piège du profil trop avancé pour une startup qui n'a pas de données

Une série A tout juste bouclée, un board qui parle de « devenir data-driven », et un fondateur qui poste une offre de data scientist senior. Trois mois plus tard, la personne recrutée passe ses journées à réparer des exports Stripe cassés et à comprendre pourquoi deux dashboards affichent un MRR différent. Le machine learning attendra.

Ce scénario, je le vois se répéter à chaque cohorte. Le premier recrutement data d’une startup est presque systématiquement mal calibré — non par manque de sérieux, mais parce que le titre du poste est choisi avant d’avoir regardé ce que la personne va réellement faire les six premiers mois.

Le malentendu de départ : « data-driven » ne veut pas dire « data science »

Quand un fondateur dit qu’il veut devenir data-driven, il pense rarement à des modèles prédictifs. Il veut savoir quels clients churnent et pourquoi. Il veut un chiffre d’activation fiable pour la prochaine board meeting. Il veut arrêter de prendre des décisions produit au doigt mouillé. Rien de tout cela n’exige un data scientist — cela exige des données propres, accessibles et cohérentes.

Or c’est précisément ce qui manque à la plupart des startups early-stage. Les événements produit sont trackés à moitié, la source de vérité du revenu oscille entre le CRM, Stripe et un Google Sheet, et personne ne sait dire si « utilisateur actif » signifie connecté ou ayant réalisé une action clé. Recruter un data scientist dans ce contexte, c’est engager un chirurgien pour poser un pansement : la personne est surqualifiée pour le travail réel, sous-outillée pour l’exercer, et frustrée dans les deux cas.

Le premier problème d’une startup n’est jamais un manque d’algorithmes. C’est un manque de plomberie et de définitions partagées.

Les trois profils qu’on confond systématiquement

Il existe trois métiers derrière le mot « data », et ils ne résolvent pas les mêmes problèmes.

Le data analyst répond à des questions business : quel canal d’acquisition a le meilleur payback, quelle cohorte retient le mieux, où fuit le funnel. Il vit dans le SQL et les outils de BI, il parle aux équipes marketing et produit. C’est un profil orienté réponse.

L’analytics engineer construit la couche qui rend ces réponses fiables : il modélise les données brutes en tables propres et documentées, il pose les définitions (qu’est-ce qu’un client actif, comment on calcule le MRR), il met en place la transformation avec des outils comme dbt sur un entrepôt type BigQuery ou Snowflake. C’est un profil orienté fondations. Il n’existait quasiment pas il y a dix ans ; c’est aujourd’hui souvent le meilleur premier recrutement data d’une startup.

Le data scientist conçoit des modèles : scoring, prédiction de churn, recommandation, détection d’anomalies. Son travail n’a de valeur que si les deux couches précédentes existent déjà. Sans données propres et sans historique exploitable, un data scientist passe 80 % de son temps à faire… de l’analytics engineering, mais moins bien et plus cher.

Confondre ces trois profils, c’est comme recruter un architecte pour poser du carrelage. La compétence est réelle, l’affectation est absurde.

Calibrer selon le stade, pas selon l’ambition

En pre-seed et seed, la vérité est inconfortable : vous n’avez probablement pas besoin d’un recrutement data du tout. Le volume de données est faible, les questions changent chaque semaine, et un fondateur ou un premier PM qui maîtrise le SQL et un outil comme Metabase couvre 90 % du besoin. La priorité est d’instrumenter correctement les événements clés et de fixer trois ou quatre définitions non négociables (activation, rétention, revenu). Externaliser un cadrage analytics de quelques jours coûte infiniment moins cher qu’un CDI mal ciblé.

En fin de seed / début de série A, le besoin devient réel mais reste souvent mal nommé. C’est le moment de l’analytics engineer ou d’un data analyst polyvalent capable de mettre les mains dans la modélisation. La bonne question à se poser n’est pas « qui peut faire du ML ? » mais « qui peut faire en sorte que tout le monde dans la boîte regarde les mêmes chiffres et leur fasse confiance ? ». Un chiffre partagé et fiable vaut mille modèles que personne ne consulte.

En série A confirmée, avec un produit qui génère des interactions à fort volume et un cas d’usage clair — un moteur de recommandation, un scoring de leads, une tarification dynamique — le data scientist trouve enfin sa place. Mais il arrive alors sur des fondations préparées, avec un entrepôt structuré et des définitions stables. Il crée de la valeur au lieu de creuser des tranchées.

Le fil rouge : ne recrutez pas le profil dont vous rêvez, recrutez celui qui résout le problème que vous avez ce trimestre.

La conséquence architecture qu’on oublie

Ce recrutement n’est pas qu’une décision RH, c’est une décision d’architecture. Un analytics engineer va introduire un entrepôt de données, un pipeline d’ingestion (Fivetran, Airbyte ou des exports maison), une couche de transformation et un outil de visualisation. Ces choix conditionnent la vitesse de toutes les équipes pendant des années.

Le piège inverse existe aussi : surdimensionner la stack data comme on surdimensionne parfois l’infra. Monter un data lake, un orchestrateur Airflow et un cluster Spark pour analyser dix mille lignes d’événements par jour, c’est du premature scaling appliqué à la donnée. À votre échelle, un entrepôt managé, un outil d’ingestion clé en main et dbt suffisent largement — et libèrent votre recrutement pour faire de l’analyse plutôt que de l’exploitation d’infra.

Il y a enfin un angle réglementaire qu’on néglige au démarrage. Dès que vous centralisez des données utilisateurs dans un entrepôt, vous étendez votre surface RGPD : finalité, durée de conservation, minimisation, localisation de l’hébergement. Un analytics engineer sérieux intègre ces contraintes dès la modélisation — pseudonymisation, tables de purge, séparation des données sensibles — plutôt que de les découvrir lors d’une due diligence ou d’un deal B2B qui exige un DPA carré.

Ce qu’il faut vraiment faire

Commencez par le besoin, pas par le titre. Écrivez les cinq questions auxquelles la boîte doit pouvoir répondre en autonomie dans six mois. Si ce sont des questions du type « où fuit le funnel » ou « quelle cohorte retient », votre besoin est analyse et fondations, pas science.

Fixez vos définitions avant de recruter. Activation, utilisateur actif, MRR, churn : mettez-les par écrit, faites-les valider par le produit et la finance. Sans cela, la première mission de votre recrue sera d’arbitrer des désaccords politiques déguisés en problèmes techniques.

Privilégiez la polyvalence au premier recrutement. Le meilleur profil early-stage est celui qui sait modéliser proprement ET répondre à une question business, pas le spécialiste pointu d’un seul des trois métiers. La spécialisation viendra avec la deuxième et la troisième recrue.

Gardez la stack sobre. Un entrepôt managé, un connecteur d’ingestion, dbt, un outil de BID accessible aux non-tech. Vous pourrez tout complexifier plus tard ; vous ne récupérerez jamais les mois perdus à opérer une infra data trop lourde pour votre volume.

Et si le doute persiste, faites un audit court avant de recruter : quelques jours pour cartographier vos sources, vos trous d’instrumentation et vos définitions vous diront précisément quel profil embaucher — et parfois qu’il est encore trop tôt.

Pour conclure

Le premier recrutement data d’une startup échoue rarement à cause de la personne. Il échoue parce qu’on a demandé un métier pour en faire un autre. La donnée ne devient un actif que lorsqu’elle est fiable et partagée — et ce chantier-là ressemble davantage à de la plomberie de précision qu’à de la magie prédictive.

La vraie question n’est donc pas « quel data scientist recruter ? », mais « qui, dans notre équipe, fait aujourd’hui autorité sur la définition d’un client actif ? ». Si personne ne peut répondre, vous savez par où commencer — et ce n’est pas par une offre d’emploi mal calibrée.