Data Engineer, Data Scientist, ML Engineer : ce que la GenAI change vraiment

Les métiers de la donnée ont été redécoupés plusieurs fois en quelques années, et la GenAI relance l'exercice. Le débat public oscille entre deux caricatures : la disparition annoncée des rôles data au profit d'un unique GenAI Engineer, et l'idée inverse que rien ne bouge parce qu'appeler une API ne serait pas un métier.

Cette analyse prend un autre angle. Elle part des responsabilités réellement exercées, montre où les systèmes LLM, RAG et agents en ajoutent, en déplacent ou n'en modifient aucune, et laisse au lecteur le soin de situer son propre poste.

Commencer par les responsabilités, pas par les titres

Un même intitulé recouvre des périmètres très différents selon la taille de l'entreprise, la maturité de sa plateforme et l'organisation de ses équipes. Une liste de responsabilités, en revanche, se compare d'une organisation à l'autre.

• Collecte, transformation, qualité et disponibilité des données.
• Expérimentation et modélisation : hypothèses, protocoles, comparaison d'approches.
• Engineering ML : industrialisation, reproductibilité, packaging, tests.
• Serving : exposition du système, latence, montée en charge.
• Évaluation : définir ce qu'est un bon résultat et le mesurer de façon défendable.
• Observabilité : savoir ce qui se passe en production et détecter une dégradation.
• Intégration applicative : faire entrer le système dans un produit et ses parcours.
• Systèmes LLM / RAG / agents : orchestration, récupération, outils, garde-fous.

Ces responsabilités ne se répartissent pas de la même manière partout. Dans une petite structure, une seule personne peut en porter six ; dans un grand groupe, une seule peut être découpée entre trois équipes.

Data Engineer

La GenAI ajoute une famille de données à un métier qui en traitait déjà beaucoup : les corpus documentaires. Ils arrivent avec leurs propres difficultés, souvent sous-estimées par ceux qui découvrent le sujet par le modèle.

• Sources documentaires hétérogènes : formats, versions, doublons, documents scannés.
• Ingestion et parsing : extraction du texte, structure, tableaux, pièces jointes.
• Métadonnées : origine, date, périmètre, statut de validité, langue.
• Qualité : détection des versions obsolètes, des documents tronqués, des contenus dupliqués.
• Permissions : qui a le droit de voir quoi, question devenue centrale quand un système répond à partir de documents internes.
• Fraîcheur : ce qui doit être réindexé, à quelle fréquence, avec quelle latence acceptable.
• Pipelines pour la récupération : découpage, indexation, mise à jour incrémentale.
• Observabilité des données : savoir ce qui est entré dans l'index et ce qui en a été exclu.

Il serait faux d'en conclure que le Data Engineer devient « celui qui prépare les données pour un LLM ». Les entrepôts, les pipelines analytiques, les contrats de données et la fiabilité des flux existants ne disparaissent pas : ils restent la base sur laquelle repose le reste, y compris les usages GenAI.

Data Scientist

C'est le rôle dont la valeur est la plus souvent mal comprise dans les projets GenAI, parce qu'on l'associe à l'entraînement de modèles, alors que l'essentiel de sa compétence porte sur la méthode.

• Expérimentation : comparer deux approches dans des conditions où la comparaison a un sens.
• Formulation d'hypothèses : dire ce qu'on croit et comment on saurait qu'on a tort.
• Métriques : choisir ce qui doit être mesuré et ce que la mesure ne dit pas.
• Évaluation : construire un jeu de test représentatif, y compris des cas difficiles.
• Analyse d'erreurs : classer les échecs par cause plutôt que par symptôme.
• Données de test : les constituer avec les experts métier, les maintenir dans le temps.
• Compréhension du comportement du système : où il est stable, où il ne l'est pas.

Ces compétences se transfèrent bien : un système RAG ou un agent se juge exactement comme un modèle, avec un protocole, un jeu de test et une analyse des erreurs. La différence est que la sortie est du texte ou une action, ce qui rend la définition du « bon résultat » plus difficile à formaliser et rend d'autant plus utile quelqu'un qui sait le faire.

Cela ne signifie pas que tout Data Scientist doive devenir AI Engineer. Rester sur la modélisation, l'analyse et la décision est une trajectoire complète, et beaucoup de problèmes n'ont aucune raison d'être traités avec un LLM.

ML Engineer

Le ML Engineer travaille là où un système cesse d'être une démonstration. Ce périmètre est peu affecté dans sa nature par la GenAI, mais il s'étend à de nouveaux objets.

• Intégration dans une application et dans une chaîne existante.
• Serving, latence, montée en charge, comportement en cas de pic.
• Déploiement, versionnement, retour arrière.
• Monitoring et alerte sur des signaux qui ont un sens pour le système.
• Reproductibilité : pouvoir refaire, expliquer et retrouver un résultat.
• Fiabilité : dégradation contrôlée, gestion des erreurs, dépendances externes.
• Coût : arbitrage entre qualité, latence et dépense par requête.
• Infrastructure et évaluation en production, distincte de l'évaluation hors ligne.

Les extensions liées à la GenAI sont concrètes : appels à des modèles externes soumis à des quotas et à des variations de comportement, chaînes de récupération à surveiller, agents dont les actions doivent être limitées et tracées, systèmes hybrides où un modèle classique et un LLM coexistent. La compétence de fond — tenir un système en production — reste la même.

AI / GenAI Engineer

C'est le rôle le plus difficile à décrire, parce qu'il n'a pas de définition stabilisée. Selon les organisations, il recouvre des responsabilités existantes, il les complète, ou il se spécialise sur un objet précis.

• Recouvrement : dans une petite équipe, il fait le travail d'un ML Engineer sur des systèmes GenAI.
• Complément : à côté d'une équipe data existante, il prend l'intégration applicative, l'orchestration et l'évaluation des systèmes à base de LLM.
• Spécialisation : récupération, agents, outillage, garde-fous, qualité de sortie, coût.

Chercher une définition universelle de ce métier est une perte de temps. Lire une offre en identifiant les responsabilités décrites est beaucoup plus informatif que se fier au titre.

Comparatif qualitatif des responsabilités

Le tableau ci-dessous est volontairement nuancé : il indique des tendances, pas des cases fermées. Dans une organisation donnée, la répartition peut être différente sans être anormale.

• Ingestion et qualité des données — Data Engineer : souvent central. Data Scientist : collaboration fréquente. ML Engineer : dépend du contexte. AI/GenAI Engineer : dépend du contexte.
• Permissions et fraîcheur des corpus — Data Engineer : souvent central. Data Scientist : rare. ML Engineer : collaboration fréquente. AI/GenAI Engineer : fréquent.
• Expérimentation et hypothèses — Data Engineer : rare. Data Scientist : souvent central. ML Engineer : fréquent. AI/GenAI Engineer : fréquent.
• Définition des métriques et jeux de test — Data Engineer : collaboration fréquente. Data Scientist : souvent central. ML Engineer : fréquent. AI/GenAI Engineer : fréquent.
• Serving, latence, montée en charge — Data Engineer : dépend du contexte. Data Scientist : rare. ML Engineer : souvent central. AI/GenAI Engineer : fréquent.
• Observabilité et évaluation en production — Data Engineer : collaboration fréquente. Data Scientist : collaboration fréquente. ML Engineer : souvent central. AI/GenAI Engineer : fréquent.
• Orchestration LLM, RAG, agents — Data Engineer : dépend du contexte. Data Scientist : dépend du contexte. ML Engineer : fréquent. AI/GenAI Engineer : souvent central.
• Intégration produit et parcours utilisateur — Data Engineer : rare. Data Scientist : dépend du contexte. ML Engineer : fréquent. AI/GenAI Engineer : souvent central.
• Coût par requête et arbitrages techniques — Data Engineer : dépend du contexte. Data Scientist : collaboration fréquente. ML Engineer : souvent central. AI/GenAI Engineer : souvent central.

Une même personne peut occuper plusieurs colonnes selon les projets. L'objectif du tableau n'est pas de ranger les gens, mais de rendre visible ce qui doit être couvert par quelqu'un.

Comment savoir où se positionner

La question « quel métier choisir » se pose mal. Une meilleure question est : quelles responsabilités ai-je envie de porter, et à quel niveau de profondeur ?

1. 1

   Ce que vous aimez résoudre

   point de départ

   Un problème de fiabilité, un problème de mesure, un problème de modélisation et un problème d'intégration ne procurent pas la même satisfaction. C'est le critère le plus stable dans le temps.

2. 2

   Profondeur software

   exigence

   Tenir un système en production demande du logiciel : tests, versions, dépendances, incidents. Certains y trouvent leur terrain, d'autres le subissent.

3. 3

   Profondeur data

   exigence

   Comprendre d'où viennent les données, ce qu'elles valent et ce qu'elles ne couvrent pas reste déterminant, y compris sur des systèmes GenAI.

4. 4

   Expérimentation ou production

   arbitrage

   Chercher ce qui marche et faire tenir ce qui marche sont deux métiers voisins mais distincts, avec des rythmes différents.

5. 5

   Interaction produit

   orientation

   Certains rôles vivent au contact des utilisateurs et des arbitrages produit ; d'autres travaillent en amont, sur la plateforme.

6. 6

   Responsabilité souhaitée

   niveau

   Contribuer, décider, tenir en production ou arbitrer sur l'architecture ne sont pas les mêmes engagements.

Aucun de ces axes ne désigne un meilleur métier. Ils permettent seulement de reconnaître, dans une offre ou dans un poste actuel, ce qui vous conviendra durablement.

• LLM
• RAG
• AI Engineering