AI engineer vs ML engineer : entraîner ou construire dessus
Les deux intitulés s’échangent dans les annonces et désignent deux métiers dont les journées n’ont presque rien en commun. L’ingénieur en apprentissage automatique produit le modèle : il collecte, prépare, entraîne, valide, sert, et possède la chaîne qui recommence tout cela quand il le faut. L’AI engineer part d’un modèle qu’il n’a pas produit et construit ce qui l’entoure : la recherche qui va chercher la bonne information, la boucle qui enchaîne les étapes, les garde-fous, l’évaluation, le coût et la latence. La confusion vient de ce que les deux travaillent autour de modèles et emploient parfois les mêmes outils. Elle coûte cher aux candidats, qui postulent au mauvais poste, et aux entreprises, qui décrivent un métier et en recrutent un autre. Le tri est pourtant facile et tient à un seul indice, disponible dans n’importe quelle annonce : le vocabulaire employé pour parler des données.
Le vocabulaire des données, indice fiable
Une offre qui parle de jeux d’entraînement, de distribution, d’étiquetage à grande échelle, de chaîne d’alimentation et de réentraînement décrit un métier où l’on produit le modèle. Le mot qui ne trompe pas est réentraînement : il n’a aucun sens dans l’autre métier.
Une offre qui parle de recherche documentaire, de découpage de sources, de garde-fous, de latence et de coût par requête décrit un métier où l’on construit autour d’un modèle fourni. Le mot qui ne trompe pas est coût par requête : il suppose un appel à un service et non un modèle qu’on possède.
Quand les deux vocabulaires apparaissent, il s’agit généralement d’une petite structure où une personne fait les deux. C’est un poste légitime, exigeant, et qu’il vaut mieux connaître avant de signer plutôt que de découvrir au premier trimestre.
Ce qui a changé ces dernières années
Une part importante des problèmes qui demandaient autrefois un modèle entraîné sur mesure se traite aujourd’hui avec un modèle généraliste et de la recherche documentaire, pour un coût de mise en œuvre sans commune mesure.
Ce déplacement n’a pas supprimé le métier d’entraînement, il l’a concentré sur les cas où il reste irremplaçable : quand la donnée ne peut pas sortir, quand le volume rend un appel externe économiquement absurde, et quand la latence disponible exclut tout service distant.
Il a en revanche créé le second métier, qui n’existait pas sous cette forme il y a quelques années. C’est la raison pour laquelle les annonces sont confuses : un vocabulaire s’est installé plus vite que les fiches de poste ne se sont mises à jour.
Ce qui se transfère, et ce qui ne se transfère pas
Le socle commun est réel : ingénierie logicielle, discipline de mesure, capacité à lire des données et à ne pas se fier à une moyenne. Un bon professionnel de l’un des deux métiers reconnaît un bon professionnel de l’autre.
Ce qui ne se transfère pas, dans un sens, est la maîtrise de la chaîne d’entraînement : reproductibilité, gestion des versions de données, coût de service, validation avant mise en production. Cela s’apprend, en quelques mois et non en quelques jours.
Dans l’autre sens, ce qui manque est l’architecture autour du modèle et la culture du coût par requête. Un ingénieur venu de l’apprentissage automatique apporte en revanche ce qui manque le plus souvent aux équipes qui construisent : une discipline d’évaluation sérieuse, qui se transfère intégralement.
Une semaine ordinaire dans chacun
Le meilleur moyen de choisir n’est pas de comparer des définitions mais de se représenter les journées, qui diffèrent davantage que les compétences.
Chez l’ingénieur en apprentissage automatique, la semaine s’organise autour de cycles longs : préparer un jeu, lancer un entraînement, attendre, comparer, recommencer. Le travail demande de la patience et une rigueur de laboratoire, et la satisfaction arrive par paliers, quand un modèle passe un seuil.
Chez l’AI engineer, la semaine est faite de cycles courts : modifier, mesurer, constater dans l’heure. Le travail ressemble davantage au développement logiciel ordinaire, avec une boucle de retour rapide, et la satisfaction est plus fréquente et plus fragmentée.
Cette différence de rythme convient à des tempéraments différents, et elle prédit mieux la satisfaction à deux ans que n’importe quelle comparaison de contenu technique.
Quel risque chacun porte
Les deux métiers échouent différemment plutôt que l’un étant plus sûr. L’ingénierie IA est exposée à ce que la couche modèle absorbe progressivement le travail qu’on écrit aujourd’hui à la main : une part de ce qui demande du code cette année sera intégrée l’an prochain.
L’apprentissage automatique est exposé au rétrécissement de son terrain, à mesure que les modèles généralistes couvrent des cas qui exigeaient un entraînement. Ce rétrécissement a déjà eu lieu en partie et il n’est pas terminé.
Les deux paris reposent au fond sur la poursuite des dépenses du même secteur, ce qui est le risque réellement partagé et rarement mentionné. La protection, dans les deux cas, consiste à cultiver ce qui ne dépend pas d’une technologie : savoir mesurer, savoir diagnostiquer, et savoir travailler avec des gens dont ce n’est pas le métier.
