Comment passer à l'ingénierie de données depuis un autre domaine ?

Le point de départ compte plus que l'intitulé du poste

Ingénieur de données n'est pas une profession réglementée. Il n'y a pas d'ordre professionnel, pas d'examen obligatoire avant de pouvoir s'en réclamer, rien d'équivalent à un statut de membre agréé. Cela semble être une bonne nouvelle, et d'une certaine façon ça l'est : personne ne peut vous exclure sur le papier. Mais cela signifie aussi que la sélection se fait entièrement au bureau du responsable du recrutement, lors de l'entretien et de l'exercice pratique, et ce seuil n'a cessé de monter, pas de baisser, à mesure que les outils gérés comme Fivetran, dbt Cloud et les services d'ingestion natifs cloud absorbent le travail ETL de routine. Ce qui reste à faire pour un ingénieur de données humain est de plus en plus la moitié difficile : concevoir des pipelines qui ne corrompent pas silencieusement les données, gérer les backfills et les événements arrivant en retard, administrer l'orchestration (Airflow, Dagster ou un planificateur cloud), et raisonner sur les coûts et l'échelle dans un système distribué. C'est le poste auquel vous postulez réellement, quelle que soit la formulation de l'annonce.

Ce qui se transfère vraiment

Si vous êtes ingénieur logiciel en transition, la majeure partie de vos acquis se transfère directement : discipline du contrôle de version, tests, revue de code, instinct sur ce qui se passe quand un job échoue à mi-chemin. Ce que vous ajoutez, c'est la modélisation de données (schémas en étoile, dimensions à évolution lente, stratégie de partitionnement) et les modes de défaillance spécifiques des pipelines batch et streaming — idempotence, livraison exactly-once versus at-least-once, dérive de schéma. C'est le chemin le plus court vers le rôle, et les responsables de recrutement le savent ; attendez-vous à devoir concevoir un pipeline au tableau blanc, pas seulement écrire une fonction.

Si vous êtes analyste de données ou développeur BI, votre SQL est probablement solide et votre compréhension de la façon dont l'entreprise utilise réellement les données est un atout réel que la plupart des ingénieurs logiciels purs n'ont pas. Ce qui ne se transfère pas automatiquement, c'est la moitié ingénierie : écrire du Python de production (pas des scripts de notebook), construire et tester des pipelines plutôt que d'interroger des tables que quelqu'un d'autre a remplies, et travailler avec des outils d'orchestration et d'infrastructure. Le rôle d'analytics engineer (construit autour de dbt) se situe entre les deux et constitue un tremplin commun et crédible — ça vaut le coup de le nommer explicitement sur votre CV si c'est le chemin que vous prenez, car c'est maintenant un titre reconnu à part entière, pas un euphémisme.

Si vous êtes administrateur de base de données, la conception de schémas, l'indexation et l'optimisation des performances se transfèrent bien, et les recruteurs prendront votre expérience DBA au sérieux. Ce qui manque généralement, c'est l'aisance avec un langage généraliste de qualité production, et l'expérience avec les outils cloud-natifs à mise à l'échelle horizontale (Spark, BigQuery, Redshift, Snowflake) qui ont largement remplacé l'administration de bases de données monoserveur dans ce type de rôle.

Si vous êtes data scientist, soyez honnête avec vous-même sur le chevauchement : la construction de modèles et l'inférence statistique constituent un ensemble de compétences différent de l'ingénierie de pipelines, et les deux sont plus confondus dans les annonces d'emploi qu'ils ne devraient l'être. Certains data scientists ont écrit beaucoup de code de pipeline de données en production et la transition est réelle ; d'autres ont principalement travaillé dans des notebooks sur des données que quelqu'un d'autre a préparées, et la transition est bien plus mince que ne le suggère l'intitulé du poste.

Si vous venez d'un domaine sans aucun bagage en programmation — opérations, finance, une autre discipline d'ingénierie totalement différente — il n'y a pas de raccourci. La voie existe, mais elle passe d'abord par l'apprentissage de l'écriture et du test de logiciels, généralement via un rôle d'analyste ou d'ingénieur logiciel junior, pas directement vers l'ingénierie de données.

La question de la certification

Il n'y a pas de licence, mais il existe un marché de la certification, et il vaut la peine d'être lucide sur ce qu'elle fait et ne fait pas. AWS Certified Data Engineer – Associate, Professional Data Engineer de Google Cloud, Azure Data Engineer Associate de Microsoft et Data Engineer Associate de Databricks existent tous et sont raisonnablement reconnus. Ils démontrent que vous avez étudié les services d'une plateforme spécifique et que vous pouvez répondre à des questions à choix multiples les concernant en conditions d'examen. Ce qu'ils ne démontrent pas, et ce que la plupart des responsables de recrutement vous diront peser bien moins qu'un certificat, c'est que vous pouvez construire quelque chose qui survive au contact avec de vraies données désordonnées, tardives, dupliquées en production. Considérez une certification comme une preuve que vous pouvez parler couramment d'une plateforme en entretien, pas comme ce qui vous obtient l'entretien. Un dépôt GitHub avec un pipeline réel — ingérant de vraies données, avec des tests, du logging, et une note écrite sur ce qui le fait échouer — fait plus de travail que le certificat placé à côté sur votre CV.

Ce que votre candidature doit surmonter

Trois choses, précisément, et ce ne sont pas celles que les conseils génériques de CV vous diront de corriger.

Premièrement, le problème des outils nommés. Les annonces d'emploi en ingénierie de données sont inhabituellement précises sur l'outillage — Airflow, dbt, Kafka, Spark, l'entrepôt de données d'un cloud particulier — parce que les équipes recrutent quelqu'un qui peut être productif rapidement sur leur stack existante. Si votre expérience porte sur un ensemble d'outils différents, un système de suivi des candidatures ou un premier lecteur rapide vous filtrera avant que quiconque ne lise le paragraphe sur les compétences transférables. La solution n'est pas de prétendre à des outils que vous n'avez pas utilisés ; c'est d'avoir construit quelque chose de réel avec les outils les plus souvent nommés dans les rôles que vous visez, même à petite échelle, et de dire exactement ce que vous avez construit avec eux.

Deuxièmement, l'écart production-versus-tutoriel. Les recruteurs qui ont déjà fait ce recrutement peuvent généralement faire la différence entre un pipeline construit en suivant un tutoriel avec un jeu de données public et un où le candidat a dû réfléchir à ce qui se passe quand un système source envoie un enregistrement malformé à 3 heures du matin. Si vos projets portent tous sur des données d'échantillon propres et bien comportées, attendez-vous à ce qu'on vous demande ce que vous feriez différemment pour la production — ayez une vraie réponse, idéalement parce que vous avez déjà rencontré le problème une fois et l'avez corrigé.

Troisièmement, la question « pourquoi maintenant », posée plus crûment en ingénierie de données que dans certains domaines car le rôle est encore relativement jeune et les équipes ont été échaudées par des reconvertis qui ont survalorisé un bootcamp de deux semaines. Ayez une vraie réponse spécifique sur ce qui vous a attiré vers les pipelines et l'infrastructure plutôt que vers l'analyse ou le logiciel en général — l'enthousiasme vague se lit comme du vague.

Combien de temps ça prend vraiment

Il n'y a pas de chiffre unique honnête, mais il y a des fourchettes honnêtes selon votre point de départ.

Depuis l'ingénierie logicielle, avec une maîtrise existante de Python et SQL : trois à six mois de concentration délibérée — apprendre la modélisation de données correctement, choisir un outil d'orchestration et un entrepôt de données cloud, et construire deux ou trois projets de pipelines — est réaliste avant d'être compétitif pour des rôles d'ingénieur de données junior à intermédiaire.

Depuis le travail d'analyste ou de BI, avec un SQL solide mais une pratique limitée de l'ingénierie logicielle : six à douze mois, parce que vous construisez une nouvelle compétence (codage de qualité production, tests, orchestration) plutôt que d'étendre une existante. Les rôles d'analytics engineer sont souvent accessibles plus tôt que les rôles d'ingénieur de données depuis ce point de départ, et peuvent servir de véritable pont plutôt que de lot de consolation.

Depuis un domaine non technique : douze à vingt-quatre mois est la fourchette réaliste, généralement via un rôle intermédiaire plutôt qu'un saut direct. Méfiez-vous de tout ce qui promet plus rapide que ça ; les personnes qui y arrivent en trois mois depuis le point de départ sans historique de codage sont l'exception commercialisée comme la règle.

Là où le parcours est vraiment difficile, dites-le-vous maintenant plutôt qu'après six candidatures rejetées : si vous ne pouvez pas encore écrire et déboguer de manière indépendante un script qui fait quelque chose de non trivial avec des données, vous n'êtes pas prêt pour un entretien d'ingénieur de données, et la prochaine étape honnête est de devenir compétent à cela d'abord, dans quel que soit le rôle qui vous y amène le plus rapidement.

Que faire ensuite

Choisissez une plateforme cloud et un outil d'orchestration et engagez-vous sur eux plutôt que d'en échantillonner cinq. Construisez un pipeline de bout en bout sur une vraie source de données publique désordonnée — ingestion, transformation, tests, et une note écrite sur les modes de défaillance — et mettez-le quelque part où un responsable de recrutement regardera réellement. Ensuite, parcourez les annonces d'emploi spécifiques que vous voulez, pas les génériques, et vérifiez que votre projet couvre vraiment les outils qu'elles nomment ; là où ce n'est pas le cas, c'est la prochaine chose à construire, pas le prochain modèle de CV à télécharger. jobmarket.pro lit les annonces d'emploi complètes par rapport à votre expérience réelle et vous dit, outil par outil, où un rôle spécifique d'ingénierie de données correspond et où il ne correspond pas, avant que vous ne passiez la soirée à rédiger une candidature pour un poste qui n'aurait jamais marché.