Pourquoi le feature engineering est la discipline la plus impactante du ML
Dans la pratique, un modèle simple (régression logistique, arbre de décision) applique a des features bien construites bat généralement un modèle sophistique (XGBoost, réseau de neurones) applique aux données brutes. Cette observation, vérifiée des centaines de fois dans les competitions Kaggle et les projets industriels, place le feature engineering au coeur de tout workflow ML serieux.
La raison est fondamentale : les algorithmes ML apprennent des patterns dans l'espace des features. Si les features ne capturent pas les bonnes dimensions du problème, même l'algorithme le plus puissant ne pourra rien extraire de pertinent. A l'inverse, des features riches et informatives rendent le problème trivial pour n'importe quel modèle.
Le paradigme data-centric AI vs model-centric AI
La communaute ML a longtemps ete model-centric : le dataset est fixe, on améliore l'algorithme et les hyperparametres. Andrew Ng a popularise en 2021 le paradigme complémentaire, data-centric AI : le modèle est fixe (ou standard), on améliore systématiquement les données et les features. Dans ses benchmarks, des améliorations de 10 a 40 % de précision ont ete obtenues uniquement en ameliorant les features et les labels, sans changer l'algorithme.
En pratique, les deux approches se combinent. Mais la priorité data-centric est particulièrement pertinente pour les projets industriels ou les données sont hétérogènes, ou les bugs viennent souvent de features mal définies plutot que d'un algorithme sous-optimal. Un audit régulier des features (distribution, completude, cohérence avec la cible) est plus rentable que la recherche du meilleur hyperparametre.
Pedro Domingos, dans son article de référence 'A Few Useful Things to Know about Machine Learning', formule ce principe : 'The features used are often more important than the choice of learner.' Andrew Ng l'a reaffirme en 2021 dans son mouvement Data-centric AI, avec des résultats empiriques montrant que l'amélioration des données et des features produisait systématiquement plus de gains que l'amélioration des algorithmes sur des projets industriels réels.
Domingos, P. (2012). A Few Useful Things to Know about Machine Learning. Communications of the ACM, 55(10), 78-87.Les quatre familles de variables
Avant de transformer des données, il faut comprendre leur nature. Chaque type de variable suit une logique de traitement differente et dispose de techniques adaptées.
Variables numeriques : transformations et agrégations
Les variables numeriques (age, revenu, temperature, nombre de clics) sont directement utilisables par la plupart des algorithmes, mais rarement sous leur forme brute. Une distribution très asymetrique (salaires, prix immobiliers, montants de transactions) peut perturber les modèles lineaires et les algorithmes bases sur des distances. Les transformations typiques : logarithme pour réduire l'asymetrie des valeurs positives, racine carrée pour comprimer les grandes valeurs, Box-Cox pour normaliser des distributions arbitraires, quantile transform pour forcer une distribution uniforme ou normale.
Les features d'agrégation par entité sont souvent parmi les plus prédictives : pour un modèle de scoring client, la moyenne des transactions des 30 derniers jours, l'écart-type des montants, le nombre de transactions, le maximum, la somme — calculées par client — capturent le comportement historique bien mieux que les transactions individuelles. Ces agrégations par groupe (groupby) sont le coeur du feature engineering en e-commerce, banque et telecom.
Variables catégorielles : encodage et gestion de la cardinalite
Les variables catégorielles (pays, type de client, catégorie produit) ne peuvent pas être utilisées directement par les algorithmes qui attendent des valeurs numeriques. Pour les variables nominales a faible cardinalite (< 20 catégories), le one-hot encoding créé une colonne binaire par catégorie — simple et interprétable. Pour les variables ordinales (faible/moyen/eleve, Bronze/Argent/Or), l'encodage ordinal préserve la relation d'ordre.
Pour les variables a forte cardinalite (des milliers de valeurs : identifiant produit, code postal, URL), le target encoding remplace chaque catégorie par la moyenne de la variable cible — puissant mais susceptible au data leakage. Solution : always calculer le target encoding inside les folds de validation croisée (ou utiliser le leave-one-out encoding). Le Weight of Evidence (WoE) est une alternative populaire dans le credit scoring : WoE = log(% bons / % mauvais) pour chaque modalite, avec une interprétation probabiliste directe.
Variables temporelles et séries chronologiques
Une date brute n'est généralement pas informative pour un modèle. A partir d'un timestamp, on extrait : le jour de la semaine (forte saisonnalite hebdomadaire pour le commerce), l'heure (comportements très differents matin/midi/soir/nuit), le mois, le trimestre, si c'est un jour ferie, la saison. Ces features cycliques (le lundi et le dimanche sont adjacents) peuvent être encodées avec des fonctions sinus/cosinus pour preserver la cyclicite.
Pour les séries chronologiques, les features de lag (valeur d'il y a N périodes : lag_1, lag_7, lag_30) et les moyennes mobiles (rolling mean sur 7j, 30j) sont fréquemment les plus prédictives. Un achat 7 jours après le dernier achat est une feature de churn bien plus puissante que la date absolue. L'écart depuis le dernier événement, le nombre d'événements dans les N derniers jours, et les tendances (régression lineaire locale sur la fenêtre récente) completent le repertoire standard.
Features textuelles : TF-IDF, n-grams et embeddings
Les données textuelles (commentaires clients, descriptions produits, emails) nécessitent une transformation en vecteurs numeriques. L'approche classique : TF-IDF (Term Frequency - Inverse Document Frequency) pondere chaque mot par sa fréquence dans le document divise par sa fréquence dans le corpus — les mots fréquents dans un document mais rares dans le corpus sont informatifs. Les n-grams (bigrammes, trigrammes) capturent les associations de mots ('machine learning' est plus informatif que 'machine' et 'learning' séparés).
L'approche moderne : les embeddings pre-entraines (Word2Vec, FastText, BERT, sentence-transformers) représentent chaque texte comme un vecteur dense de 300 a 768 dimensions capturant la sémantique. Un embedding BERT d'une description produit capture la similarite sémantique entre 'smartphone' et 'telephone portable' que TF-IDF traite comme totalement differents. Ces embeddings sont directement utilisables comme features pour n'importe quel modèle aval (XGBoost, régression logistique) — c'est le feature engineering moderne pour le NLP.
Techniques de transformation et de creation de features
Au-dela des traitements par type de variable, des techniques transversales permettent de capturer des interactions, des non-linearites ou des connaissances métier.
Normalisation et mise a l'échelle : quand et pourquoi
La mise a l'échelle est critique pour les algorithmes bases sur des distances (KNN, SVM) ou le gradient (régression logistique, réseaux de neurones). Sans normalisation, une variable en euros (ordre 100 000) domine une variable en pourcentage (ordre 0-1), faussant les poids appris et ralentissant la convergence. StandardScaler centre et réduit (moyenne 0, écart-type 1). MinMaxScaler comprime entre 0 et 1. RobustScaler utilise la médiane et l'IQR, résistant aux outliers.
Les méthodes d'ensemble basées sur des arbres (Random Forest, XGBoost, LightGBM) sont invariantes aux transformations monotones des features (normalisation, log, racine carrée) et n'en ont pas besoin. Les appliquer quand même n'est pas une erreur, juste inutile. En revanche, les features textuelles TF-IDF peuvent beneficier d'une normalisation L2 (cosine normalization) pour les modèles de similarite.
Interactions, ratios et features polynomiales
Un modèle lineaire ne capture que des effets additifs. Creer explicitement des features d'interaction (produit de deux variables, ratio, différence) permet de capturer des effets combinatoires sans passer a un modèle non lineaire. Exemples classiques : le ratio 'durée de la session / nombre de pages vues' pour l'engagement, 'montant de la transaction / average des 30 derniers jours' pour la détection de fraude, 'age du compte / nombre de transactions' pour le scoring bancaire.
PolynomialFeatures de scikit-learn génère systématiquement toutes les interactions entre features jusqu'au degré N — utile pour explorer, mais explose la dimensionalite (100 features → 5 050 features au degré 2). En pratique, les interactions pertinentes sont identifiées par la connaissance métier ou par des techniques d'arbre de décision (les splits d'un arbre identifient naturellement les conditions importantes, potentiellement exploitables comme features d'interaction).
Agrégations par groupe : le pattern groupby
Le pattern de feature engineering le plus puissant en pratique pour les données transactionnelles : pour chaque entité (client, produit, vendeur), calculer des agrégations sur ses transactions historiques. Pour un client : nb_transactions_30j, montant_total_30j, montant_moyen_30j, ecart_type_montants, nb_categories_distinctes, jours_depuis_dernier_achat. Pour un produit : nb_vues_7j, taux_ajout_panier, taux_conversion, note_moyenne, nb_retours.
Ces features capturent le comportement et l'historique de l'entité bien mieux que les variables brutes. La difficulte est la point-in-time correctness : lors de l'entraînement, on ne doit utiliser que les transactions antérieures a la date de l'exemple, jamais les données futures. Un feature store avec support temporel resout ce problème systématiquement (voir section Feature Stores).
Le target encoding est susceptible au data leakage si calcule sur l'ensemble du dataset avant le split train/test : les moyennes de la cible calculées sur les exemples de test 'contaminent' le train set. Toujours calculer le target encoding inside les folds de cross-validation (TargetEncoder de scikit-learn 1.3+ le fait automatiquement), ou utiliser le smoothed target encoding (moyenne pondérée avec la moyenne globale selon la taille de la catégorie) qui réduit l'overfitting sur les petites catégories.
Feature sélection : moins de features, meilleur modèle
Ajouter des features redondantes ou non informatives n'améliore pas les performances : cela augmente le bruit, ralentit l'entraînement et peut degrader la généralisation (malediction de la dimensionalite). La feature sélection identifie le sous-ensemble optimal de variables.
Filtres statistiques : screening rapide
Les filtres evaluent chaque feature indépendamment de l'algorithme — rapidite maximale, scalable a des millions de features. La correlation de Pearson mesure la relation lineaire avec la cible numerique. Le test chi-2 evalue l'indépendance entre une variable catégorielle et la cible. L'information mutuelle (mutual information) mesure toute forme de dépendance, lineaire ou non, en se basant sur la théorie de l'information.
Ces méthodes sont rapides mais ignorent les interactions entre features : une variable peut être non informative seule mais très prédictive en combinaison avec une autre. Elles servent d'étape de pre-filtrage pour éliminer les features clairement inutiles (variance proche de zero, correlation nulle avec la cible) avant d'appliquer des méthodes plus coutenses.
Méthodes wrapper : RFE et sélection séquentielle
Les méthodes wrapper evaluent des sous-ensembles de features en entrainant le modèle sur chaque sous-ensemble. RFE (Recursive Feature Elimination) entraine le modèle, élimine la feature la moins importante selon les poids du modèle, repete jusqu'a atteindre le nombre cible de features. RFECV (RFE with Cross-Validation) de scikit-learn selectionne automatiquement le nombre optimal de features par validation croisée.
La sélection séquentielle (forward : ajouter une feature a la fois, backward : en éliminer une a la fois) explore plus systématiquement l'espace, mais est couteuse en temps de calcul (O(n^2) iterations). SequentialFeatureSelector de scikit-learn implementent les deux. Ces méthodes sont adaptées quand le nombre de features candidats est modere (< 500) et qu'on peut se permettre plusieurs heures de calcul.
Méthodes embedded : Lasso, importances d'arbres et SHAP
Les méthodes embedded selectionnent les features durant l'entraînement du modèle. La régularisation L1 (Lasso) pousse les coefficients peu importants exactement a zero, selectionnant ainsi automatiquement les features pertinentes — très efficace pour les modèles lineaires. SelectFromModel de scikit-learn permet d'utiliser n'importe quel estimateur avec un attribut feature_importances_ ou coef_ pour sélectionner les features les plus importantes.
SHAP (SHapley Additive exPlanations) calcule la contribution marginale de chaque feature pour chaque prediction individuelle, puis les agrège pour une importance globale. Contrairement aux importances de Random Forest (biaisées vers les variables a haute cardinalite et fortement correlées entre elles), SHAP est theoriquement fonde (valeurs de Shapley de la théorie des jeux cooperatifs) et fonctionne avec n'importe quel modèle, y compris les réseaux de neurones et les LLM fine-tunes.
Andrew Ng (fondateur de Google Brain, deeplearning.ai) a publie en 2021 le concept de 'data-centric AI' oppose au 'model-centric AI' traditionnel. Dans ses benchmarks sur des projets industriels, améliorer systématiquement les features et les labels — sans changer l'algorithme — produisait des gains de 10 a 40 % de précision. Son programme MLOps consacre plus de temps a la qualité des données et au feature engineering qu'au tuning des modèles.
Ng, A. (2021). A Chat with Andrew on MLOps: From Model-centric to Data-centric AI. DeepLearning.AI.Feature engineering par domaine : e-commerce, fintech et NLP
La connaissance métier est la source la plus puissante de features pertinentes. Des data scientists qui comprennent le domaine extraient des features que l'automatisation ne détecte pas. Voici les patterns caracteristiques des trois domaines les plus courants.
E-commerce et recommandation
Les features les plus prédictives en e-commerce : recence (jours depuis le dernier achat), fréquence (nombre de commandes sur 90 jours), montant (panier moyen, somme totale) — le modèle RFM (Recency-Frequency-Monetary) constitue un socle de features pour le churn et le scoring client. Features de comportement de navigation : durée de session, nombre de pages consultées, taux de rebond, pages visitées dans les 7 derniers jours avant la commande.
Features produit : taux de conversion de la fiche produit, délai de livraison attendu vs réel, taux de retour, note moyenne ponderes par volume, position dans les résultats de recherche. Features contextuelles : device (mobile vs desktop), heure de la commande, jour de la semaine, campagne marketing source. Le feature engineering e-commerce combine des agrégations temporelles a plusieurs granularites (7j, 30j, 90j, 1 an).
Fintech et credit scoring
Le credit scoring est le domaine ou le feature engineering est le plus formalise. Les features classiques du scoring : ratio endettement/revenu (DTI), taux d'utilisation du credit (solde / limite), anciennete du dossier de credit, mix de types de credit (revolving, installment, mortgage), nombre d'enquetes récentes. Chacune est encodée en catégories (tranches) plutot qu'en valeur continue pour capturer les effets de seuil (un DTI de 35 % est categoriquement different de 36 %).
Le Weight of Evidence (WoE) et l'Information Value (IV) sont les outils de référence du scoring bancaire : WoE = ln(distribution_bons / distribution_mauvais) pour chaque tranche de chaque variable, IV = somme des WoE x (distribution_bons - distribution_mauvais). Un IV < 0.02 : feature inutile. 0.02-0.1 : faible predictor. 0.1-0.3 : predictor modere. > 0.3 : fort predictor. L'encodage WoE transforme chaque variable en une valeur continue interprétable en termes de risque relatif.
NLP et classification de texte
Pour les taches de classification de texte (sentiment analysis, categorisation, détection de spam), le pipeline de feature engineering suit une progression de complexité. Niveau 1 — features statistiques : longueur du texte, nombre de mots, nombre de phrases, ratio majuscules/minuscules, presence de ponctuations spécifiques (!, ?, ...). Ces features simples sont souvent très prédictives pour le spam et les avis extremes.
Niveau 2 — TF-IDF avec n-grams : tokenisation + stop-words removal + stemming/lemmatisation + TF-IDF sur unigrams et bigrams. Pipeline standard de scikit-learn avec TfidfVectorizer. Niveau 3 — embeddings pre-entraines : sentence-transformers (all-MiniLM-L6-v2, paraphrase-multilingual-MiniLM) produisent des vecteurs de 384 dimensions encodant la sémantique. Ces vecteurs sont directement utilisables comme features pour XGBoost ou une couche de classification sur un fine-tuning BERT. Les embeddings capturent la sémantique que TF-IDF ignore.
Feature stores : industrialiser le feature engineering
Dans les organisations matures en ML, le feature engineering manuel ad-hoc créé des problèmes : duplication de calcul entre équipes, inconsistance entre entraînement et inference (training-serving skew), impossibilité de réutiliser les features d'un projet a l'autre. Le feature store resout ces problèmes en centralisant la définition, le calcul, le stockage et le serving des features.
Architecture offline / online
Le store offline stocke les features batch dans un data warehouse (BigQuery, Snowflake, Redshift) ou un data lake (Delta Lake, Iceberg). Il est utilise pour l'entraînement des modèles et la creation de datasets historiques. Les calculs sont planifies (toutes les heures, tous les jours selon la fraicheur requise) et les features sont versionnées. Le store online stocke les mêmes features a faible latence (Redis, DynamoDB, Cassandra, Bigtable) pour les servir en temps réel lors des predictions — latence cible < 10ms.
Un catalogue central assure que les features offline et online sont synchronisées et que chaque feature est documentée (définition métier, proprietaire, date de dernière mise a jour, transformations appliquées, version du code de calcul). Quand un Data Scientist entraine un modèle, il récupère les features depuis le store offline avec la même logique de calcul que celle utilisée en production — eliminant une source majeure de bugs silencieux.
Point-in-time correctness : l'invariant de tout feature store
La point-in-time correctness garantit que lors de la creation d'un dataset d'entraînement, les features associées a chaque exemple (client, transaction) correspondent aux valeurs qui etaient disponibles au moment de l'événement — pas les valeurs actuelles, pas les valeurs du lendemain. Sans cette garantie, on calcule des aggregations sur des données du futur : le client avait-il fait 5 transactions au moment de l'achat, ou est-ce qu'on utilise le compte actuel de 47 ?
Les feature stores implementent cette garantie via des requetes temporelles ponctuelles : 'donne-moi les features de l'entité X telles qu'elles existaient a la date T'. Feast supporte le point-in-time join nativement via sa fonction get_historical_features. Sans feature store, reproduire cette garantie manuellement avec des jointures SQL temporelles (WHERE event_timestamp <= label_timestamp) est possible mais error-prone et difficile a auditer de manière systématique.
Feast (open-source, cloud-agnostic, s'intègre avec Redis, BigQuery, Snowflake) pour les équipes qui veulent le contrôle et la portabilite. Tecton (SaaS enterprise, anciennement Uber Michelangelo, AWS et GCP) pour les grandes organisations. Databricks Feature Engineering (intégration native Delta Lake + MLflow + Unity Catalog) pour les équipes deja sur Databricks. Vertex AI Feature Store (GCP managed, sans ops) et SageMaker Feature Store (AWS) pour les équipes cloud-native. Le critère principal : friction d'adoption — le meilleur feature store est celui que les équipes utilisent réellement.
Memoriser le feature engineering avec la répétition espacée
Le feature engineering repose sur une combinaison de concepts statistiques (WoE, TF-IDF, information mutuelle), de reflexes algorithmiques (quand normaliser, quand utiliser target encoding, comment gerer la point-in-time correctness) et de connaissance métier (features RFM pour le retail, DTI pour le credit, embeddings pour le NLP). La quantité de techniques et leur spécificité rendent la memorisation passive inefficace.
memia propose des decks de flashcards couvrant les techniques de feature engineering, la feature sélection et les patterns de production (feature stores). Chaque carte est générée et validée par IA, avec des exemples concrets et des mnemoniques. En ancrant ces concepts par la répétition espacée FSRS, ils deviennent des reflexes utilisables immédiatement sur vos projets.
Les thèmes recurrents : (1) Différence one-hot encoding vs target encoding vs WoE, et quand utiliser chacun. (2) Pourquoi normaliser pour KNN et SVM mais pas pour XGBoost. (3) Qu'est-ce que le data leakage et comment le détecter dans le target encoding. (4) Comment creer des features d'agrégation par entité (pattern groupby). (5) Différence SHAP vs feature importances Random Forest. (6) Qu'est-ce que la point-in-time correctness et pourquoi un feature store en a besoin.
Approfondir le cluster Data & IA
Questions fréquentes sur le feature engineering
Qu'est-ce que le feature engineering ?
Le feature engineering est le processus de transformation de données brutes en variables (features) exploitables par un algorithme ML. Il inclut le nettoyage, la creation de nouvelles variables (agrégations, interactions, extractions temporelles), l'encodage des variables catégorielles, la normalisation et la sélection des features les plus informatives. C'est souvent l'étape qui détermine 80% de la performance d'un modèle.
Pourquoi le feature engineering est-il plus important que le choix d'algorithme ?
Les algorithmes ML apprennent des patterns dans l'espace des features. Des features mal construites = aucun pattern utile a apprendre, quel que soit l'algorithme. Des features riches = tout algorithme fonctionne. Pedro Domingos (2012) et Andrew Ng (2021) ont tous deux documente ce principe : améliorer les features produit systématiquement plus de gains que l'optimisation des algorithmes sur des projets industriels.
Quelle différence entre feature engineering et feature sélection ?
Le feature engineering créé de nouvelles variables a partir des données brutes (transformation, combinaison, extraction, agrégation). La feature sélection choisit parmi les variables existantes celles qui sont les plus informatives. On créé d'abord un maximum de features pertinentes, puis on selectionne celles qui contribuent le plus — les deux sont complémentaires.
Faut-il toujours normaliser ses features ?
Non — ca depend de l'algorithme. Normalisation nécessaire : KNN, SVM, régression logistique, réseaux de neurones (bases sur des distances ou le gradient). Normalisation inutile : Random Forest, XGBoost, LightGBM (arbres, invariants aux transformations monotones). La regule : normaliser pour tous les algorithmes sauf les méthodes d'ensemble basées sur des arbres.
Qu'est-ce que le target encoding et quand l'utiliser ?
Le target encoding remplace chaque modalite d'une variable catégorielle par la moyenne de la variable cible. Idéal pour les variables a haute cardinalite (des centaines ou milliers de catégories) ou le one-hot encoding exploite la dimensionalite. Risque : data leakage si calcule sur tout le dataset. Solution : toujours calculer dans les folds de cross-validation. scikit-learn 1.3+ intègre TargetEncoder qui le fait automatiquement.
Qu'est-ce que le Weight of Evidence (WoE) ?
Le WoE est une technique d'encodage pour le credit scoring : WoE = ln(distribution des bons / distribution des mauvais) pour chaque tranche d'une variable. Il transforme chaque variable en une valeur continue interprétable en termes de risque relatif. L'Information Value (IV) mesure le pouvoir prédictif global de la variable : IV < 0.02 = inutile, 0.1-0.3 = predicteur modere, > 0.3 = fort predicteur.
C'est quoi un feature store et quand en a-t-on besoin ?
Un feature store centralise la définition, le calcul, le stockage et le serving des features ML — offline store (batch, pour l'entraînement) et online store (temps réel, pour l'inference). Il devient nécessaire quand plusieurs équipes partagent des features, quand on observe des inconsistances entre entraînement et production (training-serving skew), ou quand la point-in-time correctness est critique. Outils : Feast, Tecton, Databricks Feature Engineering, Vertex AI Feature Store.
Comment SHAP aide-t-il pour la feature sélection ?
SHAP calcule la contribution de chaque feature a chaque prediction individuelle (théorie des jeux — valeurs de Shapley), puis agrège pour une importance globale. Avantage vs feature importances Random Forest : SHAP n'est pas biaise vers les variables a haute cardinalite, fonctionne pour n'importe quel modèle (boite noire incluse), et produit des explications locales (pourquoi cette prediction spécifique) en plus des importances globales.
Qu'est-ce que la point-in-time correctness ?
La point-in-time correctness garantit que lors de la creation d'un dataset d'entraînement, les features associées a chaque exemple correspondent aux valeurs disponibles au moment de l'événement — pas les valeurs actuelles. Sans cette garantie, on créé du data leakage temporel : les aggregations incluent des données du futur. Un feature store avec requetes temporelles ('features de X au moment T') resout ce problème systématiquement.
Quand utiliser TF-IDF vs embeddings pour les features textuelles ?
TF-IDF (avec n-grams) : rapide, interprétable, fonctionne bien pour les textes courts avec un vocabulaire stable, la classification de spam, la détection de langue. Embeddings (sentence-transformers, BERT) : capturent la sémantique (synonymes, contexte), meilleures performances sur des taches de similarite et de compréhension, robustes aux variations de vocabulaire. En pratique : TF-IDF comme baseline rapide, embeddings pour la performance maximale ou quand le vocabulaire est variable.