Recruter les talents data et la cartographie des compétences

En 2019, Airbnb a publié un constat interne devenu célèbre : l'entreprise comptait environ 100 data scientists, mais l'organisation n'arrivait plus à livrer. Les analystes passaient leur temps à éteindre des incendies de pipelinepipelineL'ensemble des opportunités commerciales actives réparties selon les étapes du processus de vente, avec leur valeur potentielle cumulée et leur probabilité de conclusion.Voir la définition complète →. Des docteurs recrutés pour construire des modèles d'inférenceinférenceLe moment où un modèle d'IA entraîné se met au travail : il reçoit une donnée nouvelle et produit une réponse, une prédiction ou un contenu.Voir la définition complète → causale passaient leurs semaines à écrire du SQLSQLSales Qualified Lead : un prospect que l'équipe commerciale a validé comme prêt pour une prise de contact directe et une proposition, après avoir passé des critères de qualification explicites.Voir la définition complète → pour des dashboards de direction. Le problème n'était ni les effectifs ni la densité de talent, excellents tous les deux. Le problème, c'est qu'Airbnb avait recruté un titre (« data scientist ») au lieu de recruter contre une cartographie des compétences. Tout le monde était généraliste, donc personne ne portait le travail spécialisé qui faisait réellement bouger le business.

C'est exactement le mode d'échec que vous reproduirez si vous abordez le recrutement comme « il nous faut plus de gens de la data ». Le job du CDO n'est pas d'acquérir du talent. C'est de **définir la *forme* de l'équipe avec assez de précision pour que chaque recrutement s'insère dans un système**, puis de recruter pour cette forme sans attendre un candidat mythique cinq-en-un qui n'existe pas et qui, s'il existait, démissionnerait en moins d'un an.

La cartographie des compétences : décomposer l'équipe avant de décomposer la fiche de poste

Avant d'écrire la moindre description de poste, **il vous faut une cartographie des compétences, un modèle à deux dimensions de ce que votre fonction data doit *faire*** et des capacités que cela exige. Ne partez pas des titres. Les titres sont des mensonges en aval ; ils désignent autre chose dans chaque entreprise. Partez du travail.

Une équipe data moderne couvre cinq domaines de capacité. Vous les pondérerez différemment, mais vous ne pouvez en ignorer aucun :

• Engineering, déplacer, modéliser et servir la donnée de façon fiable. Pipelines, orchestration, conception du warehouse/lakehouselakehouseUne architecture hybride qui combine la flexibilité d'un data lake et les capacités analytiques d'un data warehouse, sur une seule couche de stockage.Voir la définition complète →, data contractsdata contractsAccord formel entre l'équipe qui produit les données et celles qui les consomment, fixant structure, sens, qualité et responsabilité en cas de rupture.Voir la définition complète →, SLASLAEngagement formel définissant le niveau de service qu'un fournisseur garantit à un client, avec des objectifs mesurables et des conséquences en cas de manquement.Voir la définition complète → de latence et de coût.
• Analytics, transformertransformerUn Transformer est une architecture de réseau de neurones qui utilise le self-attention pour traiter des séquences en parallèle. Elle est au cœur de la plupart des modèles de langage et d'IA générative actuels.Voir la définition complète → la donnée en décisions. Définition des métriques, expérimentation, business partnering, le travail du « pourquoi le revenu a-t-il chuté ».
• Science, construire des systèmes prédictifs et inférentiels. Modèles de ML, inférence causale, optimisation, prévision.
• Governance, rendre la donnée fiable et conforme *en tant que discipline opérationnelle*, pas comme un classeur de politiques. Lineage, monitoring de la qualité, mise en œuvre du contrôle d'accès, privacy engineering.
• Product, traiter les actifs et plateformes data comme des produits avec des utilisateurs, des roadmaps et des métriques d'adoption. C'est le domaine que la plupart des CDO sous-recrutent et regrettent le plus.

Superposez maintenant la seconde dimension : la séniorité comme fonction de la tolérance à l'ambiguïté, pas des années d'expérience. Une personne senior absorbe l'ambiguïté et la convertit en structure pour les autres. Une personne junior exécute des tâches bien cadrées. L'erreur consiste à recruter trois seniors qui veulent tous définir la stratégie et dont aucun n'écrira les modèles dbt, ou cinq juniors sans personne pour architecturer le système dans lequel ils opèrent.

Le résultat de cet exercice est une grille. En ligne : vos cinq domaines. En colonne : le mix de séniorité dont vous avez réellement besoin compte tenu de votre stade de maturité. Une organisation encore sur tableurs, sans plateforme, a besoin d'une forte pondération engineering-senior et de quasiment aucune science. Une entreprise avec une plateforme solide et des décisions inexploitées a besoin d'analytics et de product. Cartographiez votre réalité, pas l'organigramme du billet de blog FAANG lu la semaine dernière.

De la carte aux rôles : le principe anti-licorne

C'est ici que la plupart des CDO se sabotent. Après avoir construit une cartographie riche, ils la réduisent à une seule fiche de poste qui exige tout. La parodie devenue classique : « Recherche data scientist avec statistiques niveau doctorat, expérience Spark en production, mamaUtiliser un logiciel pour automatiser les tâches et campagnes marketing répétitives, afin de personnaliser à grande échelle sur des canaux comme l'email, le web et le social.Voir la définition complète →îtrise de dbt, gestion des parties prenantes et Kubernetes. » Cette personne existe à un taux de peut-être 1 sur 5 000 dans votre fourchette de rémunération, et la recruter crée une dépendance à bus factor de un que vous passerez des années à défaire.

Le principe anti-licorne : un rôle doit exiger une force profonde dans un domaine, une compétence opérationnelle dans un domaine adjacent, et une littératie sur le reste. Profond-adjacent-littéré, le « T-shape » que tout le monde cite mais que peu appliquent.

Concrètement, cela signifie qu'un analytics engineer est *profond* en modélisation/transformation, *compétent* en analytics (il comprend les questions) et *littéré* en governance (il sait pourquoi le lineage compte). Vous ne lui demandez pas de construire des modèles de ML. Si votre fiche de poste comporte trois exigences « profondes », vous avez écrit un job pour deux personnes, et le marché vous punira par six mois de poste vacant.

Le test à appliquer avant de publier : pour chaque « must-have », demandez-vous si un bon candidat pourrait l'apprendre en 90 jours sur le poste. Si oui, c'est un nice-to-have. Déplacez-le. La plupart des fiches de poste meurent d'obésité de must-have : chaque partie prenante ajoute sa compétence fétiche et le candidat composite devient imaginaire.

Concevoir les rôles concrets

Avec la carte et le principe anti-licorne en main, la plupart des équipes modernes se résolvent en un petit ensemble d'archétypes de rôles durables. **Votre job est de décider lesquels vous sont nécessaires *maintenant* et dans quel ratio.**

Analytics Engineer, sans doute le recrutement à plus fort levier des cinq dernières années et celui qui a résolu la crise d'Airbnb. Se situe entre la donnée brute et les analystes, porte la couche de transformation (dbt, modèles sémantiques), et transforme des tables de warehouse chaotiques en data products fiables, documentés et testés. Recruter ce rôle libère vos scientists du travail de conciergerie SQL et vos engineers des demandes BI. Si vous avez des data scientists qui écrivent de la logique de transformation en production, c'est votre premier recrutement.

Data Engineer, porte l'ingestion, l'orchestration et la fiabilité de la plateforme. Profond en systèmes, compétent sur les arbitrages coût/performance. C'est votre colonne vertébrale d'infrastructure ; sous-recrutez ici et tout l'aval devient peu fiable.

Analyste / Analytics partner, profond dans le domaine métier et l'expérimentation, embarqué dans une fonction (growth, finance, ops). Ce qui distingue un bon analyste d'un excellent n'est pas l'outillage ; c'est la capacité à reformuler une question floue de dirigeant en une question traitable et répondable.

Data Scientist / ML Engineer, recrutez *étroitement*. Soyez honnête sur le besoin : inférence (causale, design d'expérimentation) ou ML en production (modèles dans le chemin de serving) ? Ce ne sont pas les mêmes personnes. Les confondre est la raison pour laquelle tant de « data scientists » sont malheureux : recrutés pour faire des stats, on leur demande du MLOps.

Data Product Manager, porte la plateforme et les actifs data clés comme des produits. Définit les métriques d'adoption, priorise la roadmap, gère la relation avec le client interne. Dans une organisation mature, ce rôle est ce qui empêche votre plateforme de devenir un cimetière de tables inutilisées.

Governance / Data Quality Engineer, opérationnalise la confiance. Porte le monitoring de la qualité, l'outillage de lineage, la mise en œuvre des accès. Pas un compliance officer : un ingénieur qui fait tourner la governance automatiquement.

Le ratio compte plus que la liste. Une heuristique de départ utile pour une organisation à maturité intermédiaire : **pour 4 à 5 personnes qui *produisent* de l'insight (analystes, scientists), il vous en faut environ 2 à 3 qui le *rendent possible*** (engineers, analytics engineers) et au moins 1 qui le *produitise et le gouverne*. Les équipes 100 % productrices s'effondrent sous leur propre dette technique en moins de 18 mois.

Rédiger des fiches de poste et un screening qui prédisent réellement la performance

Une fois les rôles définis, la description de poste devient un filtre, et la plupart sont de très mauvais filtres. Réduisez la vôtre à trois sections : **le *problème que cette personne porte* (pas des « responsabilités », le résultat concret dont elle est comptable)**, la *compétence profonde* requise, et la *littératie* attendue. Supprimez la liste de courses. Une description de poste qui se lit comme un cahier des charges signale une équipe qui ne sait pas ce qu'elle veut.

Pour le screening, abandonnez les énigmes d'algorithmes au tableau pour les rôles data : elles ne prédisent rien. Utilisez des work-sample tests qui reflètent le vrai travail. Pour un analytics engineer, donnez-lui un schéma en désordre et demandez-lui de concevoir et documenter un modèle. Pour un analyste, donnez-lui une vraie question métier ambiguë (anonymisée) et un jeu de données, et évaluez la façon dont il la cadre, pas seulement la réponse. **Le signal que vous cherchez est le *jugement en situation d'ambiguïté*, précisément ce qu'une énigme élimine**.

Une façon propre d'encoder les attentes de compétences pour un rôle, qui vous force aussi à être honnête sur profondeur vs littératie :

role: analytics_engineer
owns: "trusted, tested transformation layer feeding all BI"
skills:
  data_modeling:      deep       # non négociable
  sql:                deep
  testing_ci:         competent
  business_context:   competent
  governance_lineage: literate
  ml:                 none       # explicitement non requis

Écrire cela ainsi, rôle par rôle, produit deux effets : ça tue l'obésité de must-have, et ça devient la grille exacte sur laquelle vos interviewers notent. Quand chaque interviewer évalue les mêmes dimensions sur la même échelle, vous éliminez le biais du « je l'ai bien aimé » qui produit des équipes homogènes.

Acheter, construire, et la réalité du marché

Même une cartographie parfaite se heurte à un marché du travail. Le data engineer senior que vous avez spécifié coûte 220 K$ et plus sur les marchés compétitifs, et part au bout de 2 à 3 ans. La carte est donc aussi un outil de décision build-vs-buy.

Pour chaque case de votre grille, demandez : cette compétence est-elle *rare et durable* (acheter du senior, payer le prix, retenir fort) ou *apprenable et abondante* (recruter junior, faire grandir en interne) ? La compétence en analytics engineering, par exemple, est très apprenable par un bon analyste maîtrisant SQL, donc il est souvent moins coûteux et plus durable de la développer que de l'acheter. L'infrastructure ML profonde est rare et coûteuse à développer en interne : achetez-la. Passer chaque domaine au crible de cet axe rare/apprenable transforme votre plan de recrutement en *portefeuille* : quelques ancres seniors coûteuses qui créent de la structure, entourées de talents développables qui resteront parce que vous êtes l'endroit qui les a fait grandir.

Cela recadre entièrement le problème de la licorne. Vous n'avez pas besoin d'une personne qui a tout. Vous avez besoin d'une *équipe* dont la cartographie des compétences couvre tout en agrégé, avec une redondance délibérée sur les compétences porteuses pour qu'aucun départ isolé ne vous paralyse. L'unité de complétude est l'équipe, jamais l'individu.

Sourcer au-delà du vivier évident

Les candidats qui collent parfaitement à votre fiche de poste sont ceux que tous les autres CDO poursuivent aussi. Deux mouvements élargissent le vivier sans baisser le niveau.

Recrutez sur la compétence profonde et la trajectoire, et éliminez sur les lacunes de littératie véritablement non enseignables. Le contexte métier (comprendre votre business) s'apprend. L'intuition statistique est difficile à enseigner. Donc un scientist brillant venu d'un autre secteur est un meilleur pari qu'un scientist médiocre venu du vôtre, l'inverse de la plupart des instincts de recrutement.

Deuxièmement, construisez le pipeline depuis les rôles adjacents que vous employez déjà. Vos meilleurs analytics engineers sont souvent vos analystes frustrés qui ont appris dbt tout seuls. Vos meilleurs data PM sont souvent des analystes qui gravitaient naturellement vers la question « qui utilise réellement ça ? ». Nommer ces parcours explicitement, et financer les transitions, est moins cher, plus rapide et produit une meilleure rétention que n'importe quelle fiche de poste externe. Cela envoie aussi à toute votre équipe le signal que la progression est possible ici, ce qui fait plus pour la rétention que n'importe quel ajustement de rémunération.

Le CDO qui traite le recrutement comme une transaction isolée sera toujours en retard. Celui qui le traite comme une construction de portefeuille adossée à une cartographie des compétences vivante, en achetant les ancres rares, en faisant grandir le socle apprenable et en sourçant dans les adjacences, construit une équipe qui capitalise au lieu de tourner.

Points clés

• Construisez la cartographie des compétences avant l'organigramme. Décomposez le travail en cinq domaines (engineering, analytics, science, governance, product) croisés avec vos besoins réels de séniorité, et pondérez selon *votre* stade de maturité, pas celui d'un billet de blog.
• Appliquez profond-adjacent-littéré à chaque rôle. Une compétence profonde, une adjacence compétente, de la littératie ailleurs. Passez chaque « must-have » au test des 90 jours et supprimez ceux qu'un bon recrutement pourrait apprendre sur le poste.
• Recrutez l'analytics engineer tôt. Si vos scientists et analystes font du travail de conciergerie sur la transformation, ce seul rôle débloque la productivité pour laquelle vous pensiez avoir besoin de plus d'effectifs.
• Traitez le recrutement comme une construction de portefeuille. Classez chaque compétence en rare-et-durable (acheter du senior, retenir fort) ou apprenable-et-abondante (faire grandir en interne). L'unité de complétude est l'équipe, jamais la licorne individuelle.
• Screenez avec des work samples, pas des énigmes, et notez tout le monde sur la même grille de rôle. Le jugement en situation d'ambiguïté est le signal ; une grille partagée est votre défense contre des équipes homogènes façonnées par les biais.