Anatomie d'un pipeline ML

Un modèle qui affiche 95 % de précision dans un notebook sur votre portable n'est pas un produit. Entre ce résultat prometteur et un système auquel vos utilisateurs peuvent se fier s'intercale une série d'étapes que les débutants sous-estiment : obtenir les bonnes données, les nettoyer, les mettre en forme, entraîner, tester, livrer, puis surveiller le modèle une fois en service pour qu'il ne se dégrade pas en silence. Cette série d'étapes s'appelle le pipeline ML, et l'examen attend de vous que vous en nommiez les étapes, que vous sépariez celles qui se ressemblent et que vous compreniez pourquoi il ne s'arrête jamais vraiment. Cette leçon parcourt le chemin complet une fois, de bout en bout.

Gardez un objectif concret en tête pour ancrer chaque étape : une banque veut un modèle qui prédit quels clients sont sur le point de fermer leur compte, afin de les contacter avant leur départ. Nous suivrons ce modèle d'attrition des données brutes jusqu'à la production.

Le pipeline en un coup d'œil

Le pipeline suit un ordre naturel, et cet ordre compte : chaque étape dépend de la précédente, et vous ne pouvez pas sauter en avant.

Lisez-le en trois blocs. D'abord vous préparez les données (collecte, analyse exploratoire, prétraitement, feature engineering). Ensuite vous construisez le modèle (entraînement, réglage, évaluation). Enfin vous l'exécutez en production (déploiement, surveillance). Et la surveillance ramène au début. Reprenons chaque étape avec le modèle d'attrition en main.

Préparer les données

La collecte des données vient en premier, parce qu'un modèle ne peut apprendre que de ce que vous lui donnez. Pour le modèle d'attrition, cela veut dire rassembler l'historique des comptes, les relevés de transactions, les tickets de support et l'activité de connexion, puis les réunir au même endroit. La règle qui gouverne toute cette phase : des données douteuses en entrée donnent un modèle douteux en sortie. Aucune étape ultérieure ne rattrape un modèle entraîné sur des données fausses ou absentes.

L'analyse exploratoire des données (EDA) est l'étape où l'on regarde avant d'agir. Avant de modifier la moindre valeur, vous explorez ce que contiennent réellement les données : combien de comptes vous avez, quels champs sont vides, si le solde est parfois négatif, si les clients partis sont rares (ils le sont presque toujours). L'analyse exploratoire ne transforme rien. Elle construit votre compréhension des données, et cette compréhension oriente toutes les décisions suivantes.

Le prétraitement des données est l'étape de nettoyage. Les données réelles sont désordonnées : valeurs manquantes, lignes en double, formats incohérents (« USA », « U.S. », « États-Unis »), erreurs flagrantes comme un âge de 200 ans. Le prétraitement corrige tout cela pour que les données soient cohérentes et exploitables. Vous complétez ou supprimez les valeurs manquantes, uniformisez les formats et retirez les enregistrements aberrants.

Le feature engineering est l'étape où vous construisez les entrées dont le modèle va apprendre, appelées features. Ce n'est plus du nettoyage, c'est de la création. D'un horodatage brut « dernière connexion », vous pouvez dériver « jours depuis la dernière connexion ». D'une année de transactions, vous pouvez calculer « dépense mensuelle moyenne » et « tendance de dépense sur 3 mois ». De bonnes features séparent souvent un modèle moyen d'un modèle solide, parce qu'elles livrent le signal à l'algorithme sous une forme qu'il sait utiliser.

Ces trois étapes de données sont confondues en permanence, alors fixez la distinction tout de suite. L'analyse exploratoire comprend, le prétraitement nettoie, le feature engineering crée. Prenez une valeur manquante : l'analyse exploratoire la repère, le prétraitement la comble, le feature engineering n'a rien à y voir. Cet exemple minimal sépare les trois.

Construire le modèle

L'entraînement du modèle est l'étape que la plupart des gens imaginent quand ils pensent au machine learning, alors que vous voyez maintenant qu'elle n'est qu'une étape parmi d'autres. Vous donnez les données préparées à un algorithme, et il apprend les motifs qui relient les features au résultat, ici les features à « parti ou resté ». Le produit de sortie est un modèle entraîné.

Le réglage des hyperparamètres ajuste les paramètres qui contrôlent la façon dont l'entraînement se déroule. Ces paramètres ne sont pas appris des données, c'est vous qui les fixez : le nombre de couches d'un réseau, ou la vitesse à laquelle le modèle se corrige pendant l'entraînement. Le réglage teste différentes combinaisons pour trouver celles qui produisent le meilleur modèle, souvent automatiquement. Vous tournez les boutons du processus d'entraînement, pas ceux des données.

L'évaluation est le contrôle d'honnêteté. Vous mesurez le modèle sur des données qu'il n'a jamais vues pendant l'entraînement, un jeu de test mis de côté, parce qu'un modèle qui a mémorisé ses données d'entraînement peut sembler parfait et échouer sur de vrais clients. Si le modèle d'attrition ne détecte que 40 % des clients qui partent réellement, c'est l'évaluation qui vous l'apprend avant vos utilisateurs. La leçon sur les métriques creusera ce point ; retenez pour l'instant que l'évaluation est la porte entre « entraîné » et « digne de confiance ».

Exécuter en production

Le déploiement met le modèle au travail. Vous le rendez accessible pour que les autres systèmes de la banque puissent lui envoyer un client et récupérer un score d'attrition, soit via un endpoint toujours actif qui répond en temps réel, soit via un traitement nocturne qui score tous les comptes d'un coup. La leçon suivante détaille ces choix de déploiement.

La surveillance est l'étape que les débutants oublient, et c'est là que les modèles échouent en silence. Un modèle d'attrition entraîné sur le comportement de l'an dernier peut perdre lentement en précision à mesure que les clients changent, que l'économie bouge ou que la banque lance de nouveaux produits. On appelle cela la dérive. La surveillance suit le modèle en service, donc vous détectez la dégradation et vous agissez, en général en collectant des données fraîches et en réentraînant. C'est la flèche qui revient au début.

Voici l'idée fausse à écarter : croire que livrer le modèle est la ligne d'arrivée. Ce n'est pas le cas. Un modèle déployé est un actif périssable. Le pipeline est une boucle, pas une ligne, parce que le monde que le modèle décrit continue de bouger, et un modèle jamais réentraîné est un modèle qui se périme lentement.

Conseils pour l'examen

• Connaissez l'ordre des étapes et sachez y placer une activité. « Tracer des distributions pour comprendre les données » est de l'analyse exploratoire, « compléter les valeurs manquantes » du prétraitement, « créer un champ jours depuis le dernier achat » du feature engineering.
• Le piège le plus fréquent consiste à mélanger analyse exploratoire, prétraitement et feature engineering. Fixez les verbes : comprendre, nettoyer, créer. Un énoncé qui décrit un nettoyage désigne le prétraitement, même s'il emploie le mot « préparer ».
• « La précision du modèle a chuté trois mois après le lancement » décrit un scénario de surveillance et de dérive, et la réponse est le réentraînement, pas le redéploiement du même modèle.
• Méfiez-vous des réponses qui traitent le déploiement comme la dernière étape. La surveillance vient après, et le pipeline reboucle vers les données.

Emportez une seule image de cette leçon : les données entrent, le modèle sort, la production tourne, et on revient aux données. Chaque service AWS des prochaines leçons se branche sur l'une de ces étapes, et le MLOps, plus loin dans ce sujet, est la discipline qui fait tourner toute cette boucle de façon fiable et répétable. Vous allez maintenant voir d'où viennent ces modèles et comment vous les mettez concrètement en production.