Les modèles de maturité MLOps, je les lis à l'envers

L'escalier niveau 0 → niveau 3 décrit bien l'arrivée, et l'ordre des marches est inventé. Le suivre à la lettre, c'est le meilleur moyen d'automatiser un modèle que personne n'utilise. Mon ordre à moi, et le petit calcul qui le justifie.

Chaque éditeur a son modèle de maturité. Niveau 0 : tout à la main. Niveau 1 : entraînement automatisé. Niveau 2 : déploiement automatisé. Niveau 3 : continu, surveillé, auto-réparé. Un bel escalier, avec en général le produit de l'éditeur sur la dernière marche.

Sur la destination, je suis d'accord. C'est l'ordre des marches qui me gêne, et l'ordre est justement la seule chose sur laquelle une équipe peut agir.

Ce qui est juste dans ces modèles

Les capacités listées sont réelles. Entraînement reproductible, déploiement automatisé, monitoring, retour arrière : une équipe qui a tout ça livre plus sereinement qu'une équipe qui n'a rien. La liste ne contient pas de remplissage.

Ils donnent aussi un vocabulaire commun. Dire « on est au niveau 1 » en réunion budget passe mieux qu'un paragraphe de nuances, surtout devant un public non technique.

Et ils rendent visible un travail qui ne se voit pas. Une bonne partie du MLOps ne se démontre pas. Un modèle de maturité est l'un des rares outils pour faire comprendre « on ne sait pas revenir en arrière » à quelqu'un qui ne ressent pas le risque.

Ce qui me gêne

Les niveaux sont présentés comme des prérequis. Ce sont surtout des capacités indépendantes, mises les unes au-dessus des autres par le dessin. Le monitoring ne demande aucun ré-entraînement automatique. Le retour arrière fonctionne très bien sans feature store. À force de les dessiner en marches, on voit des équipes construire l'automatisation du niveau 2 avant d'avoir vérifié que le modèle mérite d'être déployé.

Ils mesurent l'automatisation. Les niveaux comptent la part du pipeline qui tourne sans humain. C'est un indicateur indirect, parfois correct, de ce qui compte vraiment : en combien de temps on voit un problème, et ce que ça coûte de l'annuler.

Figure 1. Les mêmes capacités, classées selon leur coût et le risque qu'elles retirent. En haut à gauche, ce qui coûte peu et change beaucoup. Le ré-entraînement automatique est en bas à droite, et c'est souvent lui que les modèles de maturité mettent en avant.

Ils oublient ce que le modèle sert. Une plateforme niveau 3 qui sert un modèle que personne n'utilise vaut moins qu'un notebook niveau 0 dont des gens dépendent. Les modèles de maturité notent la machinerie, jamais ce qu'elle transporte.

Ils arrangent l'éditeur. Le haut de l'escalier a presque toujours la forme d'un produit. Ça ne le rend pas faux, mais ça explique pourquoi « acheter une plateforme » arrive si tôt dans la séquence.

Les trois questions que je pose à la place

Combien de temps avant de savoir que quelque chose a cassé ? C'est le temps de détection. Si la réponse est « quand un utilisateur se plaint », le reste de la liste attendra.

Combien de temps avant que ce soit réparé ? C'est le temps de rétablissement. En pratique : sait-on revenir en arrière, et l'a-t-on déjà fait pour de vrai.

Combien de temps avant de comprendre pourquoi ? C'est le temps de diagnostic. C'est là que journaliser ce qu'on a réellement servi rapporte, à chaque incident.

N'importe quel ingénieur d'astreinte reconnaît ces questions. Le machine learning n'invente rien de ce côté-là, il ajoute seulement quelques façons d'échouer sans lever d'exception.

L'intuition mathématique : le dommage est une aire

Les trois questions se ramènent à un calcul simple. Pendant un incident, la qualité du service baisse d'un certain impact : une part de réponses fausses, des utilisateurs bloqués. Elle reste basse le temps qu'on s'en rende compte, le temps de détection (TTD), puis le temps de revenir en arrière, le temps de rétablissement (TTR). Sur un graphique de la qualité dans le temps, le dommage est l'aire du creux :

dommage ≈ impact × (TTD + TTR)

et, sur une année : coût ≈ fréquence des incidents × impact × (TTD + TTR).

Animation. La qualité du service chute au début de l'incident et reste basse jusqu'à la détection (TTD), puis remonte pendant le retour arrière (TTR). L'aire rouge, c'est le dommage. Détecter en 1 h et revenir en 15 min la divise par 45.

Exemple : le même incident dure 48 h + 6 h quand l'alerte est un utilisateur qui se plaint, et 1 h + 15 min avec une alerte automatique et un retour arrière déjà répété. L'aire est divisée par 45. Aucun de ces deux facteurs n'apparaît sur l'escalier de maturité.

Automatiser le ré-entraînement peut réduire la fréquence de certains incidents, mais il en crée d'autres, et il ne touche ni au TTD ni au TTR. C'est pour ça que je fais passer la journalisation (elle raccourcit le diagnostic) et le retour arrière répété (il raccourcit le TTR) avant lui.

Mon ordre, testé sur le terrain

Pour une équipe qui livre son premier modèle, à peu près :

Livrer quelque chose qu'un humain utilise, à la main s'il le faut. Tant qu'on ne sait pas si le modèle vaut la peine d'être exploité, le reste est de la spéculation.
Journaliser les entrées servies et les sorties renvoyées. La capacité la moins chère de toutes, et sans elle on ne diagnostique rien.
Rendre le retour arrière réel, et le répéter. Tant qu'on ne l'a jamais exécuté, le retour arrière reste un plan sur papier.
Surveiller la distribution des sorties. On a rarement les étiquettes à temps pour suivre la précision. La forme de ce que le modèle produit bouge avant les métriques.
Rendre l'entraînement reproductible. Données figées, code figé, paramètres enregistrés. Indispensable le jour où il faut expliquer une décision, et ce jour arrive plus tôt qu'on ne pense.
Automatiser le déploiement. Maintenant, parce qu'il y a quelque chose qui mérite d'être déployé souvent.
Automatiser le ré-entraînement. En dernier, et en le décidant vraiment. C'est l'étape la plus capable d'automatiser une erreur à grande échelle, et c'est celle qu'on met sur l'affiche.

Les étapes 2 et 3 sont celles que les équipes sautent. Ce sont aussi celles qui offrent le meilleur rapport entre l'effort et le risque retiré.

Comment je me sers quand même de la courbe

Je la garde comme liste de contrôle, et je la lis en partant du haut.

Je prends la dernière marche et je me demande, pour chaque capacité : que se passe-t-il si on ne la construit jamais ? Parfois, la réponse est « rien, à notre échelle, cette année ». Et ce sont souvent ces capacités-là que l'escalier m'aurait fait construire en troisième.

Lu comme ça, le modèle de maturité redevient ce qu'il est au fond : une liste à peu près complète de ce qui peut faire mal, dessinée dans l'ordre qui arrange celui qui l'a publiée. Je garde la liste, et je choisis l'ordre moi-même.