Machine Learning ou statistiques classiques : l'arbre de choix pour l'industrie

Le vrai critère de choix : explicabilité vs performance vs coût données

La première erreur dans un projet data industriel est de poser la question “quel algorithme est le plus précis ?”. La bonne question est : “quel algorithme donne la meilleure réponse utilisable avec les données qu’on a ?” La nuance est décisive.

Un réseau de neurones profond peut atteindre 97 % de précision sur un problème de classification de défauts — mais si le directeur qualité ne comprend pas pourquoi le modèle a classé une pièce en rebut, il ne s’en servira pas. Et il aura raison.

Le choix d’une méthode repose sur un triangle à trois sommets.

Explicabilité. La capacité à expliquer, en langage métier, pourquoi le modèle a donné telle réponse. Un coefficient de régression se lit en une phrase. Un arbre de décision s’imprime sur une feuille A4. Un réseau de neurones à 50 couches ne s’explique qu’avec des outils post-hoc comme SHAP, et même là, l’explication reste approximative.

Performance brute. La précision, le $R^2$, le taux de faux positifs — la métrique qui compte pour le problème donné. Plus le modèle est complexe, plus il peut capturer des relations subtiles dans les données. Mais la complexité n’est pas gratuite : elle coûte en données, en temps de calcul, et en maintenance.

Données nécessaires. Une régression linéaire fonctionne avec 50 observations. Un XGBoost a besoin de 500 à 5000. Un CNN en a besoin de 10 000 à 100 000. En ETI industrielle, 50 observations c’est souvent ce qu’on a. 500, c’est un bon historique. 10 000, c’est exceptionnel sauf en contrôle visuel automatisé.

Cela ne signifie pas qu’il faut toujours choisir le modèle le plus simple. Cela signifie qu’il faut toujours commencer par le plus simple, mesurer sa performance, et ne monter en complexité que si le gain justifie la perte d’explicabilité. Les sections qui suivent parcourent les méthodes par ordre de complexité croissante.

Régression linéaire — le premier réflexe, et souvent le bon

La régression linéaire modélise la relation entre une sortie continue Y et un ensemble de variables explicatives X sous la forme :

$Y = a_1 X_1 + a_2 X_2 + \cdots + b$

Chaque coefficient $a_1$, $a_2$, etc. quantifie l’impact de la variable correspondante sur la sortie, toutes choses égales par ailleurs.

Forces. Ultra-explicable : chaque coefficient se traduit en une phrase métier. Rapide à entraîner, même sur un tableur. Peu de données nécessaires — 30 à 100 observations suffisent si le nombre de variables reste modeste (règle empirique : au moins 10 observations par variable). Le $R^2$ donne une mesure directe de la qualité du modèle.

Faiblesses. Ne fonctionne que si la relation entre les variables et la sortie est linéaire. Sensible aux valeurs aberrantes qui tirent la droite. Nécessite de vérifier des conditions statistiques :

• normalité des résidus
• homoscédasticité (variance constante des erreurs)
• absence de multicolinéarité entre les variables explicatives

Si ces conditions ne sont pas remplies, les coefficients ne sont pas fiables.

Quand l’utiliser. Relation claire entre quelques variables et une sortie continue. Besoin de comprendre l’effet de chaque variable. Peu de données disponibles, typiquement moins de 200 observations. C’est le cas de la majorité des problèmes d’optimisation de paramètres process en PME/ETI.

Exemple. Prédire le temps de cycle d’injection en fonction de 4 paramètres machine : épaisseur pièce, vitesse d’injection, température moule, indice de fluidité matière. 80 observations collectées sur un mois de production. Régression linéaire : $R^2 = 0.87$. Le coefficient de vitesse d’injection indique que chaque mm/s supplémentaire ajoute 0.3 s au temps de cycle. Le coefficient de température moule montre que chaque degré au-dessus de 60 °C réduit le temps de 0.15 s. Le directeur de production lit ces deux chiffres, comprend le compromis, et ajuste ses consignes. Pas besoin de data scientist pour interpréter.

Variantes utiles. La régression polynomiale ajoute des termes $X^2$ ou $X \cdot Z$ pour capturer des courbes et des interactions — utile quand la relation est légèrement non linéaire mais que les données restent limitées.

Ridge et Lasso ajoutent une pénalisation qui stabilise les coefficients quand le nombre de variables est élevé par rapport au nombre d’observations. Lasso a l’avantage supplémentaire de mettre à zéro les coefficients des variables non pertinentes, ce qui fait office de sélection automatique de variables.

Régression logistique — prédire un oui/non

La régression logistique modélise la probabilité qu’un événement binaire se produise : défaut oui/non, panne oui/non, lot conforme oui/non. Malgré son nom, c’est un modèle de classification, pas de régression. La sortie est une probabilité entre 0 et 1, convertie en décision binaire par un seuil (généralement 0.5, mais ajustable selon le coût relatif des erreurs).

Forces. Explicable via les odds ratios : chaque coefficient se traduit en “cette variable multiplie le risque par X”. Probabiliste : on obtient non pas juste une classe, mais un niveau de confiance. Peu de données nécessaires, typiquement 100 à 500 observations.

Quand l’utiliser. Classification binaire avec peu de données et besoin d’explicabilité. C’est le cas de beaucoup de problèmes qualité en industrie : prédire si une pièce sera conforme ou non, prédire si un lot passera le contrôle final, identifier les conditions process qui mènent à un défaut.

Exemple. Prédire le risque de non-conformité d’aspect sur une pièce injectée à partir de 5 paramètres : température matière, pression de maintien, temps de refroidissement, humidité granulés, vitesse de dosage. Sur 200 pièces historiques avec leur verdict qualité, le modèle identifie que la température matière au-dessus de 242 °C multiplie le risque de défaut par 3.2, et qu’une humidité granulés supérieure à 0.08 % le multiplie par 2.1. Le responsable qualité en tire une règle opératoire : contrôler l’étuvage avant chaque démarrage et baisser la consigne température si l’humidité ambiante dépasse 55 %.

La régression logistique est aussi un excellent outil de tri préliminaire. Avant de lancer un modèle complexe, on fait tourner une logistique pour voir si le signal existe dans les données. Si la logistique est à 50 % d’accuracy (équivalent au hasard), un XGBoost ne fera probablement pas de miracles non plus — sauf si le problème est fortement non linéaire.

Arbres de décision — expliquer des règles métier

Un arbre de décision partitionne les données par une cascade de questions binaires : “La température est-elle supérieure à 75 °C ? Si oui, l’humidité est-elle supérieure à 60 % ? Si oui, le défaut est de type buée avec une probabilité de 87 %.” Le résultat est un arbre qu’on peut littéralement imprimer et afficher à côté de la machine.

Forces. Lisibilité maximale : un opérateur sans formation data peut suivre l’arbre de décision et comprendre la logique. Gère la non-linéarité naturellement, sans avoir besoin de transformer les variables. Pas d’hypothèse sur la distribution des données. Gère les variables catégorielles nativement, sans encoding préalable — un vrai avantage en industrie où les variables “type matière”, “fournisseur”, “équipe” sont omniprésentes.

Faiblesses. Instabilité : un petit changement dans les données d’entraînement peut produire un arbre très différent. C’est le défaut principal. Un arbre construit sur les données de janvier peut ne plus ressembler à celui de mars.

Tendance au sur-apprentissage si on ne limite pas la profondeur : l’arbre apprend les particularités du jeu d’entraînement au lieu de la structure générale. La parade est de limiter la profondeur (max_depth entre 3 et 6) et d’exiger un nombre minimum d’observations par feuille.

Données nécessaires. 200 à 500 observations minimum pour un arbre fiable. Moins, et les splits sont statistiquement fragiles.

Quand l’utiliser. Le besoin est un arbre de décision lisible par un opérateur ou un technicien, pas une prédiction optimale. Les variables sont un mélange de continues et de catégorielles. La relation est non linéaire. Le cas d’usage typique est le diagnostic de cause racine.

Exemple. Diagnostiquer la cause d’un défaut d’aspect sur des profilés aluminium. Trois types de défauts possibles : marque de coulée, rayure, piqûre. L’arbre entraîné sur 300 pièces inspectées dit : “Si humidité atelier > 65 % ET température filière < 480 °C, alors piqûre (probabilité 84 %). Si vitesse de filage > 8 m/min ET pression vérin > 210 bar, alors marque de coulée (probabilité 79 %).” L’opérateur colle l’arbre sur le pupitre de commande. Quand un défaut apparaît, il suit les branches pour identifier la cause probable et corriger. Pas de formation Python nécessaire.

L’arbre de décision est aussi un outil pédagogique redoutable pour faire parler les données devant un comité de direction. Sa lisibilité désarme les réticences habituelles face aux modèles.

Random Forest — l’arbre en mieux, mais moins lisible

La Random Forest construit 100 à 500 arbres de décision sur des sous-échantillons aléatoires des données, puis agrège leurs prédictions par vote majoritaire (classification) ou par moyenne (régression). Cette agrégation corrige les deux faiblesses principales de l’arbre unique : l’instabilité et le sur-apprentissage.

Forces. Robustesse remarquable : peu sensible aux valeurs aberrantes, au bruit, aux variables non pertinentes. Très peu de tuning nécessaire — les paramètres par défaut de scikit-learn donnent souvent un résultat honnête. Produit un classement d’importance des variables qui permet de savoir quels facteurs pèsent le plus.

Faiblesses. Perte de lisibilité. On ne peut plus afficher “l’arbre” parce qu’il y en a 300. Le modèle devient une boîte grise : on sait quelles variables comptent, mais on ne peut plus expliquer chaque prédiction sans recourir à SHAP ou des outils équivalents. Plus lent que l’arbre unique, même si l’entraînement reste raisonnable (quelques minutes sur un laptop pour des jeux de données industriels typiques).

Données nécessaires. 500 à 5000 observations pour des performances solides.

Quand l’utiliser. La précision compte plus que la lisibilité du modèle unitaire. Le nombre de variables est élevé (plus de 10). Les données sont bruitées. On cherche d’abord à identifier les variables qui comptent avant d’approfondir avec un modèle plus simple ou un DOE.

Exemple. Prédire la durée de vie d’un outillage de découpe à partir de 25 paramètres : dureté matière usinée, vitesse de coupe, avance, profondeur de passe, lubrification, géométrie outil, etc. Random Forest entraînée sur 800 observations historiques. $R^2 = 0.91$. L’importance des variables montre que 3 facteurs (vitesse de coupe, dureté matière, géométrie arête) expliquent 70 % de la variance de la durée de vie. On peut ensuite zoomer sur ces 3 facteurs avec un DOE factoriel $2^3$ pour optimiser les consignes, en ignorant les 22 autres paramètres. La Random Forest a servi de filtre avant le DOE — c’est un usage sous-estimé mais très efficace.

SVM — le spécialiste des frontières complexes

Le SVM (Support Vector Machine) cherche la frontière optimale — celle qui maximise la marge — entre deux classes dans un espace potentiellement de très grande dimension. L’astuce mathématique du kernel permet de projeter les données dans un espace où une frontière linéaire sépare ce qui ne l’était pas dans l’espace d’origine.

Forces. Excellent en haute dimension : quand le nombre de variables dépasse le nombre d’observations, le SVM reste performant alors que la plupart des autres méthodes dégénèrent. Robuste aux valeurs aberrantes grâce au principe de la marge maximale. Le kernel RBF (Radial Basis Function) permet de tracer des frontières de forme arbitraire.

Faiblesses. Peu explicable : la frontière de décision n’a pas de traduction simple en langage métier. Le choix du kernel et de ses paramètres (C, gamma) influence fortement le résultat et demande un réglage soigné. Lent sur les gros volumes de données — la complexité d’entraînement croît de manière plus que linéaire avec le nombre d’observations.

Données nécessaires. 100 à 5000 observations. Le SVM est particulièrement pertinent dans la fourchette basse (100-500) quand le nombre de variables est élevé.

Quand l’utiliser. Classification binaire avec peu d’observations mais beaucoup de variables. C’est le cas typique de la spectroscopie (IR, NIR, Raman), de l’analyse vibratoire, ou de tout problème où chaque observation est décrite par un vecteur de grande dimension.

Exemple. Classifier des spectres infra-rouge pour identifier un défaut de composition dans une matière plastique. 150 spectres mesurés, chacun décrit par 200 longueurs d’onde (200 variables). SVM avec kernel RBF : 96 % de précision en validation croisée. La même tâche avec un arbre de décision donne 78 % — l’arbre ne gère pas bien les espaces de grande dimension avec peu d’observations. Le SVM est ici le bon outil, et le seul qui tienne dans ce régime statistique.

Autre cas industriel fréquent : la classification de signaux vibratoires pour distinguer un roulement sain d’un roulement en début de dégradation. Les descripteurs fréquentiels (énergie par bande, harmoniques caractéristiques) donnent un vecteur de 50 à 200 composantes. Le SVM-RBF est l’outil historique de ce domaine, avant que les réseaux de neurones ne prennent le relais sur les très gros volumes de données.

Réseaux de neurones et Deep Learning — le marteau qui a besoin d’un gros clou

Un réseau de neurones empile des couches de neurones artificiels qui apprennent progressivement des représentations de plus en plus abstraites des données. Le Deep Learning désigne les réseaux à plusieurs couches cachées. Les architectures courantes en industrie sont le MLP (réseau dense classique), le CNN (réseau convolutif, spécialisé images), et le LSTM/GRU (réseaux récurrents, spécialisés séries temporelles).

Forces. Peut apprendre n’importe quelle relation entre entrées et sorties, y compris les plus complexes. Excellent sur les données non structurées : images, signaux bruts, texte. Les CNN ont révolutionné le contrôle visuel automatisé en industrie. Les LSTM permettent de modéliser des dépendances temporelles longues dans les séries de capteurs.

Faiblesses. Boîte noire totale sans outillage spécifique. Besoin de beaucoup de données :

• un MLP a besoin de 5000 observations minimum pour un problème tabulaire simple
• un CNN a besoin de 10 000 à 100 000 images labellisées
• un LSTM a besoin de milliers de séquences temporelles

Coût en calcul : l’entraînement d’un CNN sur 50 000 images prend des heures sur GPU. Expertise nécessaire pour le choix d’architecture, le tuning des hyperparamètres (learning rate, batch size, nombre de couches, dropout, régularisation), et le debugging (vanishing gradients, explosion de loss, overfitting silencieux).

Données nécessaires. 5000+ pour MLP sur données tabulaires. 10 000 à 100 000+ pour CNN. Des milliers de séquences pour LSTM/GRU.

Quand l’utiliser.

• Images : contrôle visuel automatisé, détection de défauts d’aspect, lecture de marquages. C’est le cas d’usage roi du Deep Learning en industrie, et souvent le seul où il est vraiment indispensable.
• Séries temporelles longues : maintenance prédictive sur signaux vibratoires ou électriques quand les dépendances temporelles dépassent la capacité du feature engineering manuel.
• Données non structurées : analyse de logs textuels, classification de rapports d’intervention.

Quand ne pas l’utiliser. Moins de 1000 données. Besoin d’explicabilité. Relation entre variables relativement simple. Données tabulaires avec moins de 20 variables. Dans tous ces cas, un XGBoost ou une Random Forest feront mieux avec moins d’effort.

Exemple. Détection de micro-fissures sur des photos de pièces métalliques en sortie de fonderie. 15 000 images labellisées (OK / NOK), collectées sur 6 mois de production avec une caméra haute résolution en bord de ligne. CNN de type ResNet-18 fine-tuné : 98.3 % de détection avec 1.2 % de faux positifs. Déployé sur une carte GPU embarquée (Jetson Nano), le modèle traite une image en 45 ms, soit compatible avec la cadence de la ligne. Le gain : remplacement de deux postes de contrôle visuel humain, réduction du taux d’échappement de 4.5 % à 0.8 %. C’est un investissement lourd (caméra, GPU, labellisation, maintenance du modèle) mais le ROI est mesurable et rapide sur une ligne à fort volume.

Le transfer learning réduit considérablement le besoin en données. Un ResNet pré-entraîné sur ImageNet s’adapte à un problème de détection de défaut industriel avec 2000 à 5000 images au lieu de 50 000. C’est ce qui a rendu le Deep Learning accessible aux ETI.

XGBoost et Gradient Boosting — le couteau suisse du terrain

Le Gradient Boosting construit une séquence d’arbres de décision, chaque arbre apprenant à corriger les erreurs résiduelles des arbres précédents. XGBoost (eXtreme Gradient Boosting) est l’implémentation la plus répandue, avec LightGBM comme alternative plus rapide sur très gros volumes.

Forces. Performance souvent supérieure à toutes les autres méthodes sur données tabulaires — c’est la méthode qui gagne la majorité des compétitions Kaggle sur ce type de données, et les résultats se confirment en pratique industrielle. Gère les valeurs manquantes nativement, sans imputation préalable. Rapide à entraîner. Produit un classement d’importance des variables. Hyperparamètres nombreux mais les défauts raisonnables fonctionnent déjà bien.

Données nécessaires. 500 à 50 000 observations. Performant dès 500 si le nombre de variables reste modéré, atteint son plein potentiel entre 5000 et 50 000.

Quand l’utiliser. Prédiction sur données tabulaires — le format classique en industrie (lignes = observations, colonnes = variables). C’est le format des MES, des historiques process, des bases qualité. Si le problème est tabulaire, que la précision compte, et qu’on a au moins 500 observations, XGBoost est le premier modèle à essayer après la baseline régression/logistique.

Exemple. Prédire le taux de rebut d’un lot de production en fonction de 15 paramètres process (températures, pressions, vitesses, temps de cycle) et 5 paramètres matière (indice de fluidité, taux d’humidité, lot fournisseur, couleur, charge). 3000 lots historiques. XGBoost donne une MAE (erreur absolue moyenne) de 1.2 % contre 2.8 % pour la régression linéaire et 1.8 % pour la Random Forest. L’importance des variables montre que le temps de refroidissement et l’indice de fluidité matière dominent. Le modèle est intégré dans un dashboard de pilotage : pour chaque lot en cours, il affiche le taux de rebut prédit et alerte si la prédiction dépasse 5 %.

L’association XGBoost + SHAP est devenue un standard de facto. XGBoost fournit la performance, SHAP fournit l’explicabilité post-hoc. Ce tandem permet d’utiliser un modèle puissant tout en répondant aux questions “pourquoi” du directeur qualité. Ce n’est pas aussi transparent qu’une régression linéaire, mais c’est un compromis souvent acceptable.

Le grand tableau de choix

Méthode	Données min	Linéarité requise	Explicabilité	Gère catégoriel	Cas d’usage type
Régression linéaire	30-100	Oui	Maximale	Non (encoding)	Optimisation paramètres process
Régression logistique	100-500	Oui (log-odds)	Forte (odds ratio)	Non (encoding)	Prédiction défaut oui/non
Arbre de décision	200-500	Non	Maximale	Oui	Diagnostic cause racine
Random Forest	500-5000	Non	Moyenne (importance)	Oui	Sélection de variables, prédiction robuste
SVM	100-5000	Non (kernel)	Faible	Non (encoding)	Spectroscopie, signaux haute dimension
XGBoost	500-50000	Non	Moyenne (SHAP)	Oui (LightGBM)	Prédiction tabulaire, taux de rebut
MLP (réseau dense)	5000+	Non	Faible	Non (encoding)	Relations complexes, données massives
CNN	10000+	Non	Faible	N/A	Contrôle visuel, images
LSTM/GRU	5000+ séq.	Non	Faible	N/A	Séries temporelles longues

Ce tableau est un point de départ, pas un verdict. Chaque case mérite une nuance. Mais en première approximation, il oriente correctement 80 % des décisions.

L’arbre de décision du choix de méthode

Suivre les questions dans l’ordre. La première réponse qui correspond donne la direction.

1. Combien de données ?

• Moins de 100 observations : régression linéaire (sortie continue) ou régression logistique (sortie binaire). Pas le choix. Les méthodes complexes n’ont pas assez de matière pour apprendre.
• 100 à 500 : arbre de décision ou SVM. L’arbre si l’explicabilité est critique. Le SVM si les variables sont en grande dimension (spectres, signaux).
• 500 à 5000 : Random Forest ou XGBoost. Le Random Forest si on veut un premier filtre robuste sans trop de tuning. XGBoost si on cherche la meilleure performance possible sur données tabulaires.
• Plus de 5000 : le Deep Learning devient envisageable, mais reste optionnel. XGBoost reste compétitif et souvent préférable sur données tabulaires même à 50 000 observations.

2. La relation est-elle linéaire ?

• Oui, ou probablement oui (la physique du processus le suggère) : régression linéaire. Vérifier avec un graphe résidus vs prédictions.
• Non, ou relation inconnue : arbre, Random Forest, XGBoost.
• Complexe et haute dimension : SVM avec kernel RBF, ou réseau de neurones.

3. L’explicabilité est-elle critique ?

• Critique (audit, certification, opérateur non formé) : régression linéaire ou arbre de décision. Pas de discussion.
• Importante mais pas bloquante : Random Forest + analyse d’importance des variables, ou XGBoost + SHAP.
• Pas nécessaire (le modèle tourne en autonome, sans décision humaine en aval) : XGBoost, réseau de neurones, ce qui donne la meilleure métrique.

4. Les données sont-elles des images ou des signaux bruts ?

• Images : CNN. C’est le seul outil qui fonctionne à ce jour pour de la vision industrielle à grande échelle. Transfer learning recommandé pour réduire le besoin en données.
• Séries temporelles longues (vibration, courant moteur, séries multi-capteurs) : LSTM/GRU si la dépendance temporelle est longue (plus de 50 pas). XGBoost + features lag si la dépendance est courte (moins de 10 pas) — souvent équivalent en performance et beaucoup plus simple.
• Données tabulaires classiques (lignes/colonnes, paramètres process, mesures qualité) : méthodes tabulaires, pas de Deep Learning.

---

Erreurs classiques en industrie

Cinq erreurs reviennent dans la majorité des projets data industriels. Elles ne sont pas techniques — elles sont méthodologiques.

Commencer par le Deep Learning quand on a 200 données. C’est la plus fréquente. L’effet de mode pousse à vouloir un réseau de neurones dès le premier projet. Avec 200 observations, un réseau de neurones va sur-apprendre le jeu d’entraînement et donner des résultats catastrophiques en production.

Une régression linéaire ou un arbre de décision sur ces 200 données donneront un modèle honnête, interprétable et déployable. La complexité viendra plus tard, quand le volume de données le justifiera.

Ignorer la régression linéaire parce que “c’est trop simple”. La régression linéaire a 200 ans. Elle n’est pas glamour. Et pourtant, sur un problème linéaire avec 80 observations, elle bat tout le reste. Pas parce qu’elle est meilleure en théorie, mais parce qu’elle est la seule à être statistiquement fiable avec si peu de données.

La simplicité n’est pas un défaut — c’est un avantage opérationnel. Un modèle que le chef de ligne comprend en 30 secondes a plus de chances d’être utilisé qu’un modèle qui nécessite un data scientist pour être interprété.

Ne pas valider sur des données que le modèle n’a jamais vues. Tout modèle ML doit être évalué sur un jeu de test séparé, jamais vu pendant l’entraînement. Cela s’appelle le train/test split. C’est une règle de base, et pourtant elle est violée régulièrement.

Le symptôme : un modèle à 95 % de précision en développement qui tombe à 72 % en production. Le cas est aggravé sur des données temporelles : un k-fold classique mélange passé et futur, ce qui revient à entraîner le modèle sur des informations qu’il n’aurait pas en temps réel. La validation temporelle (TimeSeriesSplit) est obligatoire pour toute donnée séquentielle.

Oublier que les bonnes variables comptent plus que le bon algorithme. Le feature engineering — la construction de variables pertinentes à partir des données brutes — détermine souvent plus la performance finale que le choix de l’algorithme. Un XGBoost avec de mauvaises variables sera battu par une régression linéaire avec les bonnes.

Les “bonnes variables” sont celles qui capturent la physique du processus : des ratios (débit / section), des différences (température amont - température aval), des agrégats temporels (écart-type de la pression sur les 30 dernières secondes). Cette connaissance vient du terrain, pas du laptop.

Déployer sans plan de maintenance du modèle. Un modèle ML entraîné sur les données de janvier fonctionne en janvier. En juin, les conditions ont changé : nouveau fournisseur matière, recalibration d’un capteur, modification de gamme. Le modèle dérive silencieusement.

Sans monitoring de la performance en production (tracking de la métrique sur données réelles, détection de data drift), le modèle finit par donner des prédictions fausses que personne ne remarque parce que “le modèle tourne”. Le plan de maintenance minimum : un dashboard qui compare les prédictions aux observations réelles chaque semaine, et une alerte quand l’écart dépasse un seuil. Ce n’est pas de l’IA, c’est de la métrologie appliquée au modèle.

---

En synthèse

Le meilleur algorithme est celui qui répond au problème avec les données qu’on a et les contraintes qu’on subit. En ETI industrielle, ces contraintes favorisent systématiquement la simplicité : peu de données, besoin d’explicabilité, pas de data scientist à demeure pour maintenir un modèle complexe.

Le parcours type d’un projet data industriel bien mené : régression linéaire d’abord, pour voir si le signal existe et si la relation est linéaire. Si les résidus montrent une structure non linéaire, passer à un arbre ou une Random Forest. Si la performance n’est toujours pas suffisante et que les données le permettent, essayer XGBoost avec SHAP. Le Deep Learning n’intervient que pour les images ou les séries temporelles massives — et dans ce cas, c’est un projet à part entière, pas un ajout en fin de course.

La montée en complexité doit être justifiée par un gain mesurable. Si un $R^2$ passe de 0.85 à 0.87 en passant d’une régression à un XGBoost, le gain ne justifie probablement pas la perte d’explicabilité et le coût de maintenance. Si le $R^2$ passe de 0.65 à 0.91, la discussion est différente.

Le choix de méthode n’est pas un choix technique isolé. C’est un choix d’ingénierie au sens large : performance, coût, maintenabilité, compréhension par les équipes, intégration dans les processus existants. Les algorithmes sont des outils. La valeur est dans le problème bien posé.

---

Vidéos associées

Arbre de décision — partitionnement récursif de l’espace des variables.

K-Means clustering — regroupement automatique de données en clusters.

Descente de gradient — l’optimisation au cœur de l’apprentissage automatique.

Pour aller plus loin

• Tests statistiques : le guide de choix — les fondations avant d’envisager le ML
• Normalité, linéarité, hypothèses — comprendre pourquoi le ML n’a pas besoin de ces hypothèses
• Plans d’expérience (DOE) — la méthode classique avant le ML pour optimiser un processus
• Cartes de contrôle SPC — combiner SPC et ML pour le monitoring