Ce que j'ai appris en Machine Learning : du jeu de données à la décision robuste

Au cours de ma formation continue en Applied AI & Data Science au MIT, j'ai découvert le Machine Learning non seulement comme une collection d'algorithmes divers. Il a été crucial pour moi de comprendre l'ensemble du processus : d'une problématique commerciale à l'analyse et à la modélisation des données, en passant par l'évaluation, l'interprétation et l'utilisation pratique d'un modèle.

J'ai travaillé sur des problèmes très divers : grouper des pays selon leurs caractéristiques socio-économiques, prévoir les ventes de produits, détecter la rotation du personnel, comparer différents modèles d'ensemble et estimer la production future de pétrole à partir de séries temporelles historiques. Plus tard, l'IA générative et la génération augmentée par récupération (Retrieval-Augmented Generation, RAG) ont ajouté une nouvelle perspective.

La conclusion la plus importante est la suivante : Un algorithme puissant seul ne suffit pas à créer une bonne solution de Machine Learning.

Le Machine Learning ne commence pas avec le modèle

Avant de m'intéresser plus en profondeur au Machine Learning, en tant que développeur de logiciels, mon attention était naturellement très axée sur l'implémentation technique. Dans le contexte du ML, j'ai appris que le travail réel commence beaucoup plus tôt.

Il faut d'abord que ce soit clair :

• Quel problème réel doit être résolu ?
• Quelles données sont disponibles ?
• Qu'est-ce qui doit être prédit ou détecté exactement ?
• Quelle erreur de décision serait particulièrement coûteuse ?
• Comment mesurer le succès du modèle de manière significative ?

Ces questions déterminent si un problème doit être traité comme une régression, une classification, un clustering ou une prévision de séries temporelles. Elles déterminent également quelle métrique d'évaluation est importante.

Pour une prévision de ventes, par exemple, il est intéressant de savoir à quelle distance les valeurs prédites sont des ventes réelles. Pour la prévision de la rotation du personnel, il est crucial de manquer le moins possible d'employés réellement à risque.

J'ai ainsi compris que la modélisation technique doit toujours partir de l'objectif commercial, et non l'inverse.

Comprendre les données avant de les utiliser

Une grande partie du travail dans les notebooks consistait en l'analyse exploratoire des données, le nettoyage des données et la préparation. Ce fut l'une des leçons pratiques les plus importantes pour moi.

J'ai notamment appris à :

• détecter et traiter de manière significative les valeurs manquantes,
• supprimer les identifiants inutilisables et les variables constantes,
• unifier les catégories incohérentes,
• analyser les valeurs aberrantes et les distributions biaisées,
• mettre à l'échelle les variables numériques,
• encoder les variables catégorielles pour les modèles,
• examiner les corrélations,
• éviter les fuites de données entre l'entraînement et le test.

Il est devenu clair que les valeurs manquantes ne devaient pas être simplement remplacées par une moyenne arbitraire de manière générale. Dans le projet BigMart, par exemple, des liens entre les propriétés des produits, des lieux et des magasins ont été utilisés pour compléter les valeurs manquantes de manière plus plausible.

Il était tout aussi important de réaliser que même si les données peuvent montrer une corrélation statistique, celle-ci n'est pas automatiquement causale. Une visibilité élevée d'un produit peut être associée à des ventes plus faibles, car les produits peu performants ont été placés plus en évidence après coup. La visibilité ne doit alors pas être la cause des mauvaises ventes.

Le Machine Learning exige donc non seulement des compétences en programmation, mais aussi une pensée critique.

Unsupervised Learning : Détecter des structures sans variable cible connue

Dans le projet de clustering, j'ai travaillé avec des données socio-économiques de différents pays. Contrairement à une classification, il n'y avait pas de variable cible prédéfinie. Le modèle devait lui-même trouver des groupes de pays similaires en termes de mortalité infantile, de revenu, d'espérance de vie, d'inflation, de dépenses de santé, de fertilité, ainsi que d'importations et d'exportations.

J'ai comparé plusieurs méthodes de clustering :

• K-Means
• K-Medoids
• Gaussian Mixture Models
• Clustering hiérarchique
• DBSCAN

Avant le clustering, les caractéristiques devaient être standardisées. Sans mise à l'échelle, les variables avec de grandes valeurs numériques, par exemple le revenu, auraient influencé davantage le calcul de la distance que les variables avec des plages de valeurs plus petites.

Pour choisir le nombre de clusters, j'ai utilisé la méthode du coude (Elbow-méthode) et le score de silhouette. Le graphique du coude n'ayant pas montré de résultat clair, le score de silhouette a fourni une base de décision supplémentaire. Pour K-Means, trois groupes distincts et significatifs ont été obtenus.

La comparaison des algorithmes a été particulièrement intéressante pour moi. K-Means forme des clusters autour de moyennes calculées. K-Medoids utilise des points de données réels existants comme centres et peut donc être plus robuste aux valeurs extrêmes. Les Gaussian Mixture Models considèrent l'appartenance à un groupe de manière probabiliste, tandis que DBSCAN détecte les régions denses et peut marquer les points atypiques comme du bruit ou des valeurs aberrantes.

La leçon la plus importante ici a été : Il n'y a pas d'algorithme de clustering intrinsèquement meilleur. Le choix dépend de la structure des données, des valeurs aberrantes présentes et de l'objectif métier. Dans cet exemple concret, K-Medoids a fourni des groupes de pays particulièrement bien délimités.

Régression : prédire des valeurs numériques et expliquer des corrélations

Dans le projet BigMart, l'objectif était de prévoir le chiffre d'affaires d'un produit dans un magasin spécifique. Pour cela, une régression linéaire multiple a été développée.

J'ai appris qu'une régression linéaire est bien plus que l'appel d'une fonction fit(). Un modèle de régression robuste suppose diverses hypothèses statistiques.

Celles-ci incluent notamment :

• une relation suffisamment linéaire,
• des erreurs indépendantes,
• une variance d'erreur aussi constante que possible,
• des résidus distribués de manière significative,
• pas de multicolinéarité problématique entre les variables d'entrée.

Pour étudier la multicolinéarité, le facteur d'inflation de la variance (Variance Inflation Factor) a été utilisé. Les variables non significatives ou fortement redondantes ont été supprimées progressivement. Cela a rendu le modèle plus simple et plus interprétable, sans perdre sa principale capacité de prédiction.

L'analyse des résidus a été particulièrement instructive. Le premier modèle a montré un motif reconnaissable dans les erreurs. Les conditions préalables à la régression linéaire n'étaient donc pas remplies de manière satisfaisante. Une transformation logarithmique de la variable de chiffre d'affaires a permis de réduire considérablement ce problème.

Simultanément, le coefficient de détermination est passé d'environ 0,56 à environ 0,72. Le modèle pouvait ainsi expliquer une proportion beaucoup plus importante des différences de chiffre d'affaires.

Pour l'évaluation, j'ai utilisé différentes métriques :

• R² pour mesurer la variance expliquée,
• MSE pour l'évaluation moyenne des erreurs quadratiques,
• RMSE pour représenter l'erreur dans une unité plus facilement interprétable,
• Validation croisée pour vérifier la capacité de généralisation.

La valeur R² similaire lors de la validation croisée a montré que le modèle final ne fonctionnait pas seulement sur les données d'entraînement.

J'ai appris que les transformations, les diagnostics statistiques et l'analyse des résidus ne sont pas des sujets académiques secondaires. Ils déterminent si les résultats d'un modèle peuvent être interprétés de manière fiable.

Classification : toutes les erreurs ne sont pas égales

Dans le projet sur la rotation du personnel, il s'agissait de prédire quels employés étaient susceptibles de quitter l'entreprise.

Le jeu de données était déséquilibré : seulement environ 16 % des observations appartenaient à la classe des employés démissionnaires. Un modèle qui classerait presque toutes les personnes comme loyales pourrait donc atteindre une précision (Accuracy) élevée tout en étant sans valeur commerciale.

J'ai appris ici à évaluer les types d'erreurs d'une classification d'un point de vue métier.

Un faux positif (False Positive) signifie qu'un employé loyal est classé à tort comme à risque. L'entreprise pourrait lui offrir inutilement des mesures ou des incitations.

Un faux négatif (False Negative) est plus critique dans ce scénario : le modèle ne détecte pas un employé réellement à risque. L'entreprise risque de perdre un professionnel précieux sans pouvoir réagir à temps.

C'est pourquoi le rappel (Recall) de la classe positive a été choisi comme métrique cible centrale.

J'ai commencé à travailler avec :

• un modèle factice (Dummy-Modell) comme ligne de base,
• la régression logistique,
• les K-plus proches voisins (K-Nearest Neighbors),
• l'analyse discriminante linéaire (Linear Discriminant Analysis),
• l'analyse discriminante quadratique (Quadratic Discriminant Analysis).

Le modèle factice était important car un vrai modèle ne doit pas être juste « un peu bon », mais doit prouver qu'il dépasse une valeur de départ simple.

Avec K-Nearest Neighbors, j'ai également appris l'influence de la mise à l'échelle et des hyperparamètres. Le nombre de voisins, la mesure de distance et la pondération ont été optimisés, entre autres, avec GridSearchCV.

En même temps, le projet a montré qu'un rappel élevé ne signifie pas automatiquement un modèle parfait. Le modèle KNN optimisé a atteint un fort rappel, mais a montré des signes de surapprentissage (Overfitting). Un tel résultat doit être nommé de manière transparente et étudié plus en détail.

IA explicable avec SHAP

Un modèle ne devrait pas seulement fournir une prévision. Surtout pour les décisions concernant des personnes, il doit être compréhensible quelles caractéristiques ont influencé la prévision.

Pour cela, j'ai utilisé SHAP. Avec les valeurs SHAP, j'ai pu analyser à la fois l'importance globale des caractéristiques et les raisons des prévisions individuelles.

Dans le modèle d'attrition, les facteurs importants comprenaient notamment :

• les heures supplémentaires,
• l'état matrimonial,
• la satisfaction à l'égard de l'environnement de travail,
• l'équilibre vie professionnelle/vie privée (Work-Life-Balance),
• le revenu,
• l'expérience professionnelle et l'implication dans le travail.

Les heures supplémentaires se sont révélées être un facteur particulièrement fort de la rotation prévue. Une très grande satisfaction à l'égard de l'environnement de travail, en revanche, a réduit la probabilité de démission.

Il était important pour moi de comprendre que l'importance des caractéristiques (Feature Importance) et les valeurs SHAP ne prouvent pas la causalité. Elles expliquent comment le modèle prend ses décisions. Elles ne montrent pas automatiquement qu'une caractéristique est la cause réelle d'un comportement.

Néanmoins, de telles explications sont cruciales pour examiner les modèles, en discuter techniquement et les rendre transparents auprès des parties prenantes.

Arbres de décision, Random Forest et Boosting

L'étape suivante a consisté à étudier le problème d'attrition avec des méthodes basées sur les arbres.

Un arbre de décision unique est facile à comprendre. Il fait des prédictions grâce à une séquence de règles compréhensibles. En même temps, un grand arbre illimité a une forte tendance au surapprentissage (Overfitting) : il peut presque apprendre par cœur les données d'entraînement, mais généralise moins bien aux nouvelles données.

J'ai donc appris à réguler les arbres de décision en utilisant, entre autres, les paramètres suivants :

• profondeur maximale de l'arbre,
• nombre minimal d'observations par feuille,
• critère de division,
• poids des classes.

Ensuite, différentes méthodes d'ensemble ont été comparées :

• Random Forest
• Extra Trees
• AdaBoost
• Gradient Boosting
• XGBoost

Random Forest combine de nombreux arbres de décision entraînés sur différentes sélections de données et de caractéristiques. Cela réduit la dépendance à un seul arbre instable.

Le Boosting suit une approche différente : les modèles sont construits progressivement, les nouveaux modèles réagissant particulièrement aux erreurs des modèles précédents.

Les résultats ont montré que le Random Forest optimisé et XGBoost atteignaient les combinaisons les plus fortes de rappel (Recall), précision (Precision) et exactitude (Accuracy). Le Random Forest optimisé a obtenu le rappel le plus élevé, tandis que XGBoost a atteint une performance de détection très similaire avec une précision et une exactitude élevées.

La leçon décisive pour moi n'a cependant pas été que Random Forest ou XGBoost sont fondamentalement « meilleurs ». J'ai appris à comparer systématiquement les modèles et à évaluer leurs forces en fonction de l'objectif commercial concret.

Un modèle plus complexe n'est un progrès que si son utilité supplémentaire justifie la perte de simplicité et d'interprétabilité.

Séries temporelles : le passé n'est pas un simple jeu de données normal

Lors de la prévision de la production de pétrole, j'ai découvert une forme de modélisation complètement différente.

Les données de séries temporelles ont un ordre naturel. Par conséquent, les données d'entraînement et de test ne doivent pas être mélangées au hasard. Le modèle doit être entraîné avec le passé et testé sur des points temporels ultérieurs.

J'ai abordé :

• la tendance et la décomposition des séries temporelles,
• la stationnarité,
• le test d'Augmented Dickey-Fuller,
• la différenciation (Differencing),
• l'autocorrélation,
• les diagrammes ACF et PACF,
• les modèles AR, MA, ARMA et ARIMA.

La série temporelle originale n'était pas stationnaire. Son comportement statistique changeait au fil du temps. Ce n'est qu'après une différenciation de troisième ordre qu'un p-value suffisamment faible a été atteint dans le test ADF.

À l'aide des ACF et PACF, il a été possible d'étudier à quel point les valeurs actuelles sont liées aux observations précédentes ou aux erreurs précédentes. Sur cette base, différentes combinaisons des paramètres ARIMA p, d et q ont été testées.

Pour l'évaluation du modèle, l'AIC et le RMSE ont été comparés. Les deux métriques poursuivent des objectifs différents :

Le RMSE évalue l'ampleur des erreurs de prévision. L'AIC tient également compte de la complexité du modèle et pénalise les modèles inutilement compliqués.

Dans le notebook, ARIMA(2,3,2) a donné le meilleur résultat sur la base du RMSE. Auto-ARIMA, en revanche, a proposé un autre modèle, car il optimisait principalement l'AIC.

Ce fut une découverte particulièrement précieuse : Même la sélection automatisée de modèles n'est pas objectivement détachée de l'objectif. Le résultat dépend de la métrique que le processus de recherche optimise.

Du Machine Learning classique à l'IA générative et au RAG

Le notebook d'IA générative a complété les sujets classiques du Machine Learning par trois applications pratiques :

• Classification des avis d'hôtel,
• Création de résumés médicaux adaptés aux patients,
• Développement d'un assistant basé sur le RAG pour les politiques de ressources humaines.

Aucun modèle classique n'a été entraîné à partir de zéro. Au lieu de cela, un grand modèle linguistique (Large Language Model) existant, l'ingénierie des prompts (Prompt Engineering), les embeddings et une base de données vectorielle ont été utilisés.

Pour l'assistant RH, j'ai mis en œuvre un pipeline RAG complet en Python :

1. Lecture de documents PDF,
2. Division du texte en sections chevauchantes basées sur les jetons (tokens),
3. Génération d'embeddings,
4. Stockage persistant des vecteurs dans Chroma,
5. Récupération des sections de texte pertinentes par similarité sémantique,
6. Passage du contenu trouvé au LLM comme contexte,
7. Génération d'une réponse basée exclusivement sur ces sources.

De plus, les sources ou identifiants de bloc (Chunk-IDs) ont été renvoyés. Si l'information n'était pas présente dans le document, le système devait expressément indiquer qu'il ne connaissait pas la réponse.

J'ai pu transférer beaucoup de choses du Machine Learning classique : la qualité des données, l'évaluation, les résultats reproductibles, l'analyse des erreurs et la nécessité d'une ligne de base ne disparaissent pas avec l'IA générative. Elles deviennent même encore plus importantes, car les sorties des LLM sont probabilistes et pas toujours fiables.

Le contrôle des coûts a également joué un rôle pratique. J'ai travaillé avec des limites de jetons (Token-Limits) strictes, des formats de sortie clairement définis et des paramètres contrôlés. Pour les classifications, le modèle devait, par exemple, ne produire qu'une seule étiquette (label) valide. Des réponses structurées, des longueurs de sortie limitées et un contexte spécifiquement composé réduisent à la fois les coûts et les sources d'erreurs.

Ce qui a changé dans ma façon de penser grâce à ces projets

Grâce à ces projets, j'ai acquis une connaissance pratique d'un flux de travail ML complet :

• Traduire des problèmes commerciaux en tâches analysables,
• Examiner et nettoyer les données,
• Choisir des familles de modèles appropriées,
• Construire des lignes de base,
• Diviser correctement les données en entraînement et test,
• Optimiser les hyperparamètres,
• Détecter le surapprentissage (Overfitting) et le sous-apprentissage (Underfitting),
• Choisir les métriques appropriées,
• Expliquer les résultats,
• Traduire les résultats techniques en recommandations d'action.

Mon expérience en développement logiciel et en assurance qualité a fortement influencé ma vision du Machine Learning. Je ne vois pas un modèle comme un notebook isolé, mais comme faisant partie d'un système plus vaste. Cela inclut les tests, la validation des données, le versionnement, les pipelines reproductibles, la gestion des erreurs, la surveillance, la documentation et une intégration contrôlée dans les applications existantes.

Un modèle avec un bon score est loin d'être un système prêt pour la production.

Mon bilan honnête

Je ne dirais pas que quelques mois de formation continue remplacent plusieurs années d'expérience spécialisée en production en tant que Data Scientist ou ML Engineer. Ce ne serait ni crédible ni techniquement correct.

Cependant, ce que j'ai bâti est une base solide et testée en pratique. Je peux classer différents problèmes de ML, analyser des données, implémenter et comparer plusieurs classes de modèles, évaluer les résultats de manière critique et reconnaître les limites d'un modèle.

Surtout, j'ai appris à ne pas considérer le Machine Learning comme une boîte noire magique. Derrière chaque bonne solution se trouvent des hypothèses claires, des données propres, des décisions conscientes et une évaluation honnête.

Pour moi, cela relie mon parcours en tant que développeur de logiciels, spécialiste QA, chef de projet et Product Owner à une nouvelle compétence : la capacité non seulement à implémenter techniquement des solutions basées sur les données et l'IA, mais aussi à les évaluer en termes de qualité, de bénéfices, de risques et de maintenabilité à long terme.