Les ingénieurs en machine learning construisent les systèmes qui automatisent le travail des autres. La question de la récursivité — « l'IA remplace-t-elle les ingénieurs ML qui entraînent l'IA ? » — c'est la question qu'on pose à chaque ingénieur ML au dîner. C'est surtout la mauvaise question. La véritable lecture de l'exposition pour l'ingénierie ML est plus intéressante : le rôle se situe en territoire augmenté par l'IA, le coût opérationnel de l'IA pour les tâches d'ingénierie ML est exceptionnellement élevé, et le travail Human-critical se concentre dans une bande plus étroite que pour les ingénieurs logiciels.
Les six tâches d'ingénierie ML que nous avons modélisées
L'ingénierie ML est un rôle hybride — mi-ingénieur logiciel, mi-scientifique appliqué, mi-ingénieur plateforme. Notre corpus v1 modélise des tâches représentatives du rôle : entraîner un modèle sur un jeu de données étiqueté, évaluer les performances d'un modèle, mettre en production un modèle entraîné, déboguer des régressions de modèle en production, concevoir le pipeline d'entraînement (données → features → entraînement → évaluation → déploiement), et proposer de nouvelles approches de modélisation.
La lecture au niveau des cellules
Entraîner un modèle sur un jeu de données étiqueté est AI-augmented dans notre amorce v1 — la partie mécanique (lancer les jobs d'entraînement, suivre les hyperparamètres, changer un taux d'apprentissage) relève d'une forte capacité, et les outils d'AutoML grignotent cette couche du travail depuis trois ans. Ce qui maintient la tâche en AI-augmented et non en Replaceable, ce sont les décisions que les ingénieurs ML gardent : quelle version du jeu de données utiliser pour l'entraînement, quel régime de holdout est honnête pour le déploiement, si une régression sur un segment compte. Ces décisions ne sont pas automatisables, et elles se logent sur la même tâche dans notre matrice.
Évaluer les performances d'un modèle et rédiger le rapport d'évaluation est AI-augmented. Produire le tableau de métriques est mécanique. Décider quelle métrique compte pour la décision de déploiement relève du jugement. L'IA excelle sur le tableau, elle est médiocre sur la conclusion.
Mettre en production un modèle entraîné derrière une API est AI-augmented. Le code standard (handler FastAPI, batching, monitoring) relève d'une forte capacité. Les décisions hors standard — budget de latence, politique de retry, stratégie de rollback de version — sont du côté humain. La cellule se situe solidement dans la bande médiane.
Déboguer les régressions de modèle en production descend en Human-led + AI-assisted, et c'est là que le coût opérationnel de l'IA du rôle grimpe en flèche. L'axe de fiabilité est ici mauvais : l'IA diagnostique à tort les régressions avec assurance, et un mauvais diagnostic entraîne simultanément un coût de supervision et un coût d'erreur en aval. Les minutes de supervision par session de débogage sont élevées. Les heures de tâche sont peu nombreuses, mais le poids en dollars par heure est important.
Concevoir le pipeline d'entraînement se situe en Human-led + AI-assisted dans la partie profonde. L'IA peut ébaucher un DAG de pipeline ; l'IA ne peut pas décider que le rafraîchissement des données doit se terminer avant minuit UTC parce que le décideur européen lit le tableau de bord à 7 h CET, que le SLA de l'entrepôt en amont est à 2 h UTC, et que la logique de tampon doit donc être de trois heures et non les 30 minutes du manuel. Axe de contexte élevé. Ambiguïté élevée.
Proposer de nouvelles approches de modélisation est la tâche Human-critical du rôle. La capacité de l'IA est moyenne — l'IA peut suggérer des architectures plausibles. La fiabilité est mauvaise — les suggestions sont des recombinaisons de motifs du corpus d'entraînement qui peuvent ne pas correspondre au problème réel. L'axe d'ambiguïté se situe au sommet de l'échelle de valeur irréductible : décider quel problème attaquer, c'est ce qui définit la séniorité de l'ingénieur ML. L'IA n'a aucun intérêt dans l'orientation de recherche de l'entreprise.
Grosso modo sur une semaine type
Pour un ingénieur ML de niveau intermédiaire à senior dans une entreprise qui déploie des modèles (pas un laboratoire de modèles fondation — c'est une autre cellule), la distribution de base v1 sur les tâches modélisées est : zéro Replaceable, environ la moitié en AI-augmented (entraînement, rapports d'évaluation, déploiement d'API de production), le reste réparti entre Human-led + AI-assisted (débogage de régressions, conception de pipeline) et Human-critical (décisions d'approche de modélisation). Le pill principal est territoire augmenté par l'IA.
Cela ressemble à la lecture de l'ingénierie logicielle — et c'est le cas, en surface. La différence apparaît sur l'axe du coût opérationnel de l'IA, où les tâches d'ingénierie ML affichent les chiffres de minutes-de-supervision-par-sortie les plus élevés de tout notre corpus. Déboguer une régression demande des heures d'attention humaine par diagnostic suggéré par l'IA. Le coût opérationnel n'est donc pas dominé par l'inférence — il est dominé par le temps du relecteur au salaire chargé d'un ingénieur ML senior. Le schéma Klarna s'applique différemment ici : un assistant IA à forte capacité qui nécessite la supervision d'un ingénieur ML fait de l'arbitrage salarial contre le pool de relecteurs le plus coûteux de l'équipe.
La question de la récursivité
La version dîner mondain : « L'IA remplacera-t-elle les ingénieurs ML qui entraînent l'IA ? » La réponse honnête de la lecture v1 est : pas d'ici 2027. Les deux cellules qui semblent les plus automatisables — l'entraînement et la production de tableaux d'évaluation — sont déjà largement automatisées, et le sont depuis l'AutoML. Le travail restant de l'ingénieur ML se concentre sur la conception de pipeline, le débogage de régressions et les choix de modélisation — trois cellules où l'écart capacité-fiabilité est le plus grand et où le coût opérationnel de l'IA est le plus élevé.
La lecture structurelle est que l'ingénierie ML est l'un des rares rôles où la montée en capacité augmente réellement la demande salariale pour le travail human-critical restant, parce qu'une capacité plus élevée sur les tâches de la moitié inférieure libère des heures d'ingénieur ML pour le travail d'orientation de recherche à fort effet de levier qui se capitalise contre les actifs de modèle défendables de l'entreprise. Le cadre de levier sans permission de Naval s'applique : les ingénieurs ML qui utilisent l'assistance de l'IA pour couvrir la couche mécanique tirent davantage des mêmes heures, pas moins.
Ce que nous ne modélisons pas — la cellule du laboratoire de modèles fondation
Notre corpus v1 modélise l'ingénieur ML appliqué typique dans une entreprise qui déploie des modèles. Nous ne modélisons pas l'ingénieur ML de laboratoire de modèles fondation (Anthropic, OpenAI, DeepMind, Mistral, etc.). Ce rôle a une forme différente — la part Human-critical est bien plus élevée, la part AI-augmented est plus faible, et la couche financière est sensiblement différente parce que la production du rôle EST le substitut mesuré. Nous l'ajouterons dans une extension de corpus v1.5. Pour l'instant, traitez cet article comme la lecture de l'ingénieur ML appliqué, pas celle du laboratoire de modèles fondation.
Quoi faire de tout ça
Le geste économiquement calme pour un ingénieur ML appliqué en 2026 est de laisser l'IA produire les rapports d'évaluation et les handlers d'API, et de consacrer les heures libérées au muscle du débogage de régressions et au jugement de conception de pipeline. Ce sont les cellules où la séniorité se capitalise. La reconnaissance de motifs pour les régressions en production est le genre de compétence qui s'affûte avec les répétitions et qui est difficile à transférer ; les choix de modélisation qui semblent bons dans un notebook et échouent en production enseignent une forme de rigueur opérationnelle que l'IA ne peut pas répéter à votre place.
Calculez votre Wagecard spécifique sur wagecore.ai/start. Si vous êtes dans un laboratoire de modèles fondation, la correspondance la plus proche dans notre corpus est le rôle machine-learning-engineer avec des surcharges manuelles ; nous le préciserons sur la page de résultats. Lecture dérivée de la matrice sur /roles/machine-learning-engineer, lecture inter-cellules en direct sur /insights/machine-learning-engineer. Méthodologie ouverte sur /methodology.