MLOps : compétence d'appoint ou véritable trajectoire de carrière ?

La question mal posée : « quels outils faut-il connaître ? »

MLOps est souvent réduit à une liste : conteneurs, orchestration, intégration continue, un outil de suivi d'expériences, un registre de modèles. Ces briques existent, elles s'apprennent, et leur maîtrise seule ne suffit ni à obtenir un poste ni à tenir un système en production. Un profil qui récite des outils sans pouvoir expliquer ce qu'il surveille, pourquoi, et ce qu'il fait quand un indicateur se dégrade, ne se distingue pas d'un profil DevOps généraliste.

La question professionnelle est plutôt : de quoi êtes-vous responsable entre le moment où un modèle fonctionne sur un poste de travail et le moment où un service dépend de lui tous les jours ? C'est cet intervalle qui définit le métier, et il n'a pas le même contenu dans toutes les organisations.

Les responsabilités réelles autour du cycle de vie

Reproductibilité et données

Un résultat qu'on ne sait pas reproduire n'est pas un résultat exploitable. Reproduire suppose de savoir quelles données ont été utilisées, dans quel état, avec quelles transformations, quel code et quels paramètres. La partie données est la plus souvent sous-estimée : sans versionnage des jeux et des transformations, un écart entre deux entraînements reste inexplicable, et un incident en production reste indiagnosticable.

Artefacts, versions et déploiement

Un modèle en production est un artefact daté, rattaché à une version de code, à un jeu de données, à un environnement d'exécution et à un contrat d'interface. Le déploiement pose alors des questions classiques mais adaptées : comment passer à une nouvelle version sans interrompre le service, comment comparer l'ancienne et la nouvelle sur du trafic réel, et comment revenir en arrière rapidement. La capacité à revenir en arrière est souvent ce qui rend une équipe capable d'avancer vite.

Tests, monitoring et dérive

Tester un système ML ne se limite pas aux tests unitaires du code. On vérifie aussi la qualité des données en entrée, la cohérence des transformations entre entraînement et service, la stabilité des sorties sur un échantillon de référence, et le comportement en cas de valeurs manquantes ou aberrantes.

• Surveillance technique : disponibilité, latence, taux d'erreurs, saturation. Nécessaire, insuffisante.
• Surveillance des entrées : évolution de la distribution des données reçues par rapport à celles de l'entraînement.
• Surveillance des sorties : distribution des prédictions, taux d'abstention, cas limites, écarts entre segments d'utilisateurs.
• Qualité réelle : lorsque la vérité terrain arrive plus tard — parfois des semaines —, il faut un dispositif pour la rattacher aux prédictions passées.
• Alerte et décision : un indicateur qui se dégrade doit déclencher quelque chose de défini, sinon la surveillance ne sert qu'à constater après coup.

Sécurité, coûts et gouvernance

Accès aux données d'entraînement et aux journaux, données personnelles, cloisonnement des environnements, secrets, traçabilité des décisions automatisées, conservation des éléments permettant d'expliquer une décision passée : ces sujets ne sont pas des formalités administratives, ils déterminent souvent ce qu'il est possible de mettre en production. Les coûts, eux, se pilotent : coût d'entraînement, coût d'inférence, coût de stockage et coût des traces sont des arbitrages qui reviennent régulièrement.

Toutes ces responsabilités ne sont pas toujours portées par la même personne. Dans une petite structure, une seule personne les couvre partiellement ; dans une grande, elles sont réparties entre plusieurs équipes, avec des frontières propres à l'organisation. Décrire ce que vous avez réellement porté est plus utile que revendiquer un périmètre théorique.

Ce que les systèmes GenAI changent

Quand le modèle est appelé via une API externe, une partie du travail classique disparaît — pas d'entraînement, pas de gestion de GPU — et une autre apparaît. La responsabilité se déplace vers ce qui entoure le modèle.

• Dépendance fournisseur : versions de modèles qui évoluent ou sont retirées, comportements qui changent sans modification de votre code, limites de débit, indisponibilités. Prévoir une solution de repli est une décision d'architecture, pas un détail.
• Prompts et configurations : ce sont des artefacts versionnés, testés et déployés comme du code, pas des chaînes modifiées directement en production.
• Évaluation : à la place d'une métrique unique, des séries de cas rejouées à chaque changement, incluant les cas d'échec connus.
• Traces : requête, contexte fourni, sortie, coût, latence. Sans elles, aucune analyse d'incident n'est possible, et leur conservation pose elle-même des questions de confidentialité.
• Garde-fous : filtrage des entrées et des sorties, limitation des actions autorisées, comportement de repli quand un contrôle bloque une réponse.
• Coût et latence : ils deviennent des indicateurs de production à part entière, à surveiller par usage et non seulement globalement.

Le point commun avec le ML classique est la démarche : mesurer, versionner, surveiller, savoir revenir en arrière. Ce qui change, ce sont les objets surveillés et le fait qu'une partie du système est hors de votre contrôle.

DevOps, ML Engineering, MLOps, opérations GenAI

Ces termes se recouvrent, et les frontières varient d'une entreprise à l'autre. Les distinctions ci-dessous sont des repères utiles pour une conversation, pas des définitions officielles.

1. 1

   DevOps

   repère

   Chaîne de livraison, infrastructure, fiabilité, observabilité applicative. Le déterminant est le code et son exécution. Les données ne sont pas un objet de premier plan.

2. 2

   ML Engineering

   repère

   Concevoir et industrialiser la partie modèle : préparation des données, entraînement, optimisation, mise en service. L'accent est mis sur la construction du système, avec une composante logicielle forte.

3. 3

   MLOps

   repère

   Rendre et maintenir ces systèmes exploitables : reproductibilité, versionnage des données et des modèles, déploiement, surveillance, dérive, rollback, coûts, conformité. L'accent est mis sur la durée de vie du système, pas seulement sur sa mise en service.

4. 4

   LLMOps / opérations GenAI

   repère

   Même démarche appliquée à des systèmes s'appuyant sur des modèles souvent externes : versionnage des prompts et configurations, évaluation par séries de cas, traces, garde-fous, gestion des dépendances fournisseurs, pilotage du coût par requête.

Dans les faits, beaucoup d'offres utilisent un intitulé pour un contenu différent. C'est une raison de plus de poser des questions précises en entretien : qui déploie, qui est appelé en cas d'incident, qui décide d'un retour arrière, qui surveille la qualité et à quelle fréquence.

Compétence d'appoint ou trajectoire de carrière ?

Les deux existent réellement, et la question ne se tranche pas dans l'absolu. Dans une équipe réduite, MLOps est une compétence d'appoint portée par des personnes dont le titre est autre : la capacité à mettre en production fait alors la différence entre un projet qui aboutit et un projet qui reste au stade de démonstration. Dans une organisation qui exploite plusieurs systèmes en parallèle, la fonction devient un poste à part entière, avec une responsabilité de plateforme et des interlocuteurs multiples.

Deux signaux permettent de savoir si l'on se dirige vers une trajectoire : le travail porte-t-il sur un système ou sur les moyens communs à plusieurs systèmes ? Et le rôle consiste-t-il à livrer, ou à décider comment on livre ? Passer du premier au second est ce qui transforme une compétence en trajectoire.

Ce qu'un profil MLOps doit savoir expliquer en entretien

Plutôt qu'une liste de technologies, voici les questions auxquelles il faut pouvoir répondre à partir d'une expérience réelle. Une bonne réponse décrit un contexte, une décision et une conséquence.

• Comment reproduisez-vous un résultat obtenu il y a six mois ? Que vous faut-il pour cela ?
• Que surveillez-vous une fois le système en service, et qu'est-ce qui déclenche une action ?
• Comment savez-vous qu'un modèle se dégrade lorsque la vérité terrain arrive tardivement, ou jamais ?
• Comment déployez-vous une nouvelle version, et combien de temps prend un retour arrière ?
• Qu'est-ce qui a déjà cassé en production, et qu'avez-vous changé après ?
• Comment évitez-vous qu'une transformation diffère entre l'entraînement et le service ?
• Que coûte votre système, et quel poste domine ?
• Sur un système GenAI : comment testez-vous un changement de prompt ou de version de modèle avant de le déployer ?
• Quelles données sont conservées dans vos traces, et pour combien de temps ?

Ces questions ne demandent pas de connaître un outil particulier. Elles vérifient que vous avez exercé une responsabilité dans la durée, ce qui est exactement l'objet du métier.

• MLOps
• Production
• Évaluation