Feature engineering : les décisions qui façonnent la qualité d’un modèle de ML

Un lundi matin, un nouveau modèle de machine learning passe en production. À l’heure du déjeuner, les analystes croulent sous les faux positifs. Des cas prioritaires passent inaperçus, des cas courants sont remontés et personne n’arrive à expliquer pourquoi la performance du modèle en conditions réelles s’écarte autant de ses résultats de validation.

Le problème ne vient pas forcément de l’algorithme. Peut-être tient-il à la manière dont les données ont été représentées. Peut-être que les montants de transaction ont été utilisés comme valeurs brutes, sans que le modèle voie à quel point un achat était inhabituel pour ce client précis. Ou peut-être que les catégories ont été encodées d’une manière qui a introduit des relations trompeuses. Le modèle a peut-être été entraîné sur des données exactes, mais les signaux contenus dans ces données n’ont pas été correctement traduits.

C’est précisément le rôle du feature engineering : transformer les données brutes en entrées qu’un modèle de machine learning peut réellement exploiter. Il englobe des tâches classiques de préparation des données, comme le traitement des valeurs manquantes, l’encodage des catégories et la mise à l’échelle des champs numériques. Mais il implique aussi des choix de représentation plus profonds sur ce que le modèle doit savoir, et sous quelle forme. Ces choix déterminent la quantité de signal utile qui parvient au modèle, ainsi que son niveau de performance face à des données réelles.

Le feature engineering consiste à utiliser l’expertise métier pour créer, transformer et sélectionner des variables d’entrée, appelées features, à partir de données brutes, afin qu’un modèle de machine learning puisse produire des prédictions plus précises.

Une feature peut être une colonne source utilisée directement, comme le montant d’une transaction ou l’ancienneté d’un compte en jours. Elle peut aussi être dérivée, comme la valeur moyenne des commandes d’un client au cours des 90 derniers jours, le nombre de tentatives d’authentification échouées au cours de la dernière heure, ou un ratio entre deux mesures qui, prises isolément, en disent moins qu’ensemble.

Le feature engineering se situe entre les données brutes et l’entraînement du modèle. Les équipes extraient des signaux des systèmes sources, les transforment en entrées prêtes pour le modèle, évaluent ceux qui améliorent la performance de validation, puis intègrent la logique approuvée dans des pipelines de features ou dans un feature store afin de la réutiliser. Choisir les features dont un modèle a besoin, c’est aussi définir ce que le modèle doit comprendre du domaine.

Le feature engineering exige une collaboration entre data scientists, data engineers et experts métier, car il encode dans le modèle la compréhension que l’équipe a de l’enjeu business. Bien exécuté, il compte parmi les activités à plus fort effet de levier dans le cycle de vie du machine learning.

La qualité d’un modèle est limitée par ses entrées. Aucun choix d’algorithme, aucun réglage d’hyperparamètres ni aucune puissance de calcul ne fera réapparaître un signal qui n’était pas présent dès le départ dans le jeu de features. C’est avec le feature engineering que ce plafond se fixe, et c’est aussi là que les équipes contrôlent plus directement la qualité du modèle qu’à presque tout autre moment du cycle de vie du ML.

Ce plafond se joue notamment dans la représentation. Les mêmes données sous-jacentes, exprimées autrement, donnent au modèle une lecture fondamentalement différente du problème. Prenons un modèle d’attrition bâti sur des données d’utilisation des produits. Le nombre brut de connexions sur les 30 derniers jours indique au modèle le niveau d’activité d’un client. Mais ce qui prédit vraiment l’attrition, c’est souvent l’évolution de cette activité : un client qui se connecte deux fois moins souvent qu’il y a 60 jours n’est pas dans la même situation qu’un client qui s’est toujours connecté à ce rythme. Les données sous-jacentes sont les mêmes. Exprimées sous forme de tendance plutôt que de simple comptage, elles portent un signal que la valeur brute seule ne révèle pas.

L’article fondateur de Pedro Domingos, A Few Useful Things to Know About Machine Learning, présente la représentation comme l’un des problèmes centraux du machine learning. Le constat reste valable : si les features disponibles ne capturent pas la structure du problème, l’algorithme dispose de moins d’informations, quel que soit son réglage.

Le feature engineering influe aussi sur la généralisation. Un modèle entraîné sur des features qui reflètent des motifs réels et durables dans les données a plus de chances de produire des prédictions précises lorsqu’il rencontre de nouveaux clients, de nouveaux produits ou un environnement opérationnel différent. Un modèle entraîné sur des features qui se trouvent corrélées à la cible pendant la période d’entraînement, mais pour des raisons fortuites, se dégradera plus vite en production.

Regardez cette vidéo pour découvrir comment simplifier le feature engineering avec le ML agentique :

Le feature engineering part généralement du problème de prédiction, puis remonte jusqu’aux données. Une équipe qui construit une prévision de la demande a besoin de signaux différents de ceux d’une équipe qui classe des tickets de support, par exemple, même si les deux utilisent des données client, produit et de séries temporelles.

Un processus efficace comprend généralement les étapes suivantes :

1. comprendre les données et le problème : définissez la cible de prédiction, la décision que le modèle soutiendra et les contraintes liées à la latence, à l’explicabilité et à l’accès aux données.
2. Explorer et analyser les données brutes : examinez les distributions, les valeurs manquantes, les anomalies, les corrélations, la cardinalité des catégories et les schémas temporels.
3. Créer et transformer des features : dérivez des mesures comme des ratios, des fenêtres glissantes, des comptages, des indicateurs, des interactions et des valeurs normalisées.
4. Évaluer la pertinence des features : utilisez des tests statistiques, des mesures d’importance fondées sur le modèle, une revue par des experts métier et les résultats de validation pour identifier les features qui portent un signal utile.
5. Valider par les performances du modèle : entraînez et testez des modèles au moyen d’expériences contrôlées, en surveillant les fuites d’informations, le surapprentissage et la dérive entre les données d’entraînement et les données de production.

Le processus est itératif. Un data scientist peut dériver des ratios, des comptages, des agrégats glissants, des features de décalage, des indicateurs, des encodages catégoriels ou des termes d’interaction, puis tester si ces entrées améliorent la performance sur des données mises de côté. Certaines features se révèlent utiles immédiatement. D’autres sont écartées parce qu’elles provoquent une fuite d’informations liée à la feature, varient trop d’une période à l’autre ou dépendent de données indisponibles au moment de l’inférence.

Le processus exige de la rigueur, car la logique des features peut se disperser et diverger. Un calcul testé dans un notebook, reformulé dans un pipeline d’entraînement puis réécrit une troisième fois pour un service de scoring en temps réel peut produire trois valeurs légèrement différentes pour le même concept sous-jacent. Les pipelines de features reproductibles et les feature stores existent pour prévenir ce type de dérive, en conservant les définitions utilisées pendant l’entraînement et en les rendant disponibles de façon cohérente pour l’inférence en batch ou en temps réel.

Le feature engineering s’appuie sur un large éventail de techniques. Certaines préparent les données brutes à la modélisation. D’autres construisent de nouveaux signaux à partir de champs existants. La bonne combinaison dépend du type de données, de la famille de modèles et de la décision que le modèle doit soutenir.

Imputation et traitement des anomalies

Les valeurs manquantes doivent être interprétées avant d’être traitées. Un champ vide peut indiquer qu’une valeur était inconnue, facultative, retenue, indisponible au moment de la collecte ou réellement absente. L’imputation comble les lacunes au moyen de méthodes comme la moyenne, la médiane, le mode, des valeurs constantes ou des estimations fondées sur le modèle. Dans de nombreux cas, les équipes ajoutent aussi un indicateur binaire de valeur manquante, ce qui permet au modèle d’apprendre si l’absence d’une valeur apporte elle-même de l’information, et c’est souvent le cas.

Les anomalies exigent elles aussi du discernement. Une transaction exceptionnellement élevée peut correspondre à une fraude, à un achat légitime d’entreprise ou à une erreur de saisie des données. Les équipes peuvent plafonner les valeurs à un seuil, appliquer une transformation qui réduit l’asymétrie, supprimer les enregistrements manifestement erronés ou conserver les valeurs extrêmes lorsqu’elles reflètent un comportement significatif que le modèle doit détecter. Le traitement des anomalies est un choix de représentation, car il définit la version de la réalité sur laquelle le modèle s’entraîne.

Mise à l’échelle et normalisation

La mise à l’échelle ajuste la plage des features numériques afin que les écarts de grandeur ne créent pas de différences artificielles dans le comportement du modèle. La mise à l’échelle min‑max projette les valeurs dans un intervalle fixe. La standardisation par Z‑score exprime les valeurs par rapport à la moyenne et à l’écart type de la distribution. La mise à l’échelle robuste s’appuie sur la médiane et l’écart interquartile, une approche moins sensible aux anomalies que les méthodes fondées sur la moyenne.

La sensibilité à la mise à l’échelle varie selon le type de modèle. Les modèles linéaires, les réseaux neuronaux et les algorithmes fondés sur la distance sont davantage affectés par des features qui ne sont pas mises à l’échelle. Les modèles fondés sur des arbres de décision sont généralement moins sensibles, même si les équipes peuvent standardiser le prétraitement lorsque le même ensemble de features alimente plusieurs modèles ou systèmes en aval.

Encodage des variables catégorielles

La plupart des modèles de ML exigent que les valeurs catégorielles soient exprimées sous forme numérique. L’encodage one‑hot crée une colonne d’indicateur binaire pour chaque catégorie, une approche simple lorsque la cardinalité est faible. L’encodage ordinal préserve un ordre porteur de sens, par exemple faible, moyen et élevé. L’encodage des étiquettes (label encoding) attribue des identifiants entiers aux catégories, mais peut suggérer par inadvertance un ordre qui n’existe pas.

Les champs à forte cardinalité, tels que les identifiants de marchands, les SKU produits ou les codes géographiques, demandent plus d’attention. Une catégorie qui compte des milliers de niveaux rend l’encodage one‑hot impraticable. L’encodage par la cible (target encoding) et l’encodage par la moyenne (mean encoding) peuvent aider en remplaçant les étiquettes de catégories par des statistiques dérivées de la cible de prédiction. En revanche, ces approches nécessitent une validation rigoureuse afin d’éviter toute fuite de données provenant du jeu de données de validation.

Transformation, regroupement en intervalles et discrétisation

Les transformations ajustent la distribution d’une feature ou sa relation avec la cible. Une transformation logarithmique peut réduire l’influence des valeurs situées dans la longue traîne d’une distribution, comme le chiffre d’affaires, la durée des sessions ou le solde d’un compte. Box-Cox et les transformations associées peuvent rendre les features numériques plus adaptées aux modèles qui reposent sur des hypothèses de distribution, même si Box-Cox exige des valeurs strictement positives.

Le regroupement en intervalles (binning) regroupe les valeurs continues en intervalles discrets. Un modèle peut recevoir des tranches d’âge au lieu de l’âge brut, des tranches d’ancienneté au lieu du nombre exact de jours depuis l’inscription, ou des niveaux de dépenses au lieu des montants de transaction. Le regroupement en intervalles peut rendre certains schémas plus faciles à apprendre et, dans les contextes réglementés, plus simples à expliquer. Lorsque des seuils de domaine comptent déjà, par exemple des seuils réglementaires, des limites de niveaux de produit ou des plages cliniques, les intervalles qui s’y alignent produisent souvent des features plus pertinentes que les valeurs numériques brutes.

Création de features

La création de features est l’étape où la connaissance du domaine produit l’impact le plus direct. Pour la prévision de la demande, un retailer peut avoir besoin de features sur le rythme récent des ventes, le niveau des stocks, le calendrier des promotions et la proximité d’événements locaux. Un modèle de sécurité peut avoir besoin de la fréquence des échecs de connexion, de scores de nouveauté des appareils, d’indicateurs de déplacement impossible et d’écarts comportementaux par rapport à la référence propre au compte. Un modèle de santé client peut avoir besoin des tendances d’engagement produit, des schémas d’interactions avec le support et des changements de statut contractuel.

Le croisement de features combine des champs pour capturer les interactions : catégorie de produit par région, segmentation client par canal, type d’appareil par moment de la journée. Les features polynomiales aident certaines familles de modèles à représenter des relations non linéaires. Les features temporelles extraient la structure des horodatages : heure de la journée, jour de la semaine, temps écoulé depuis le dernier événement, moyennes glissantes, valeurs décalées et encodages cycliques pour les schémas récurrents.

Réduction de la dimensionnalité

Lorsqu’un jeu de données est vaste, bruité ou fortement corrélé, les méthodes de réduction de la dimensionnalité peuvent condenser l’espace des features tout en préservant les informations utiles. L’analyse en composantes principales projette des features numériques corrélées dans un ensemble plus restreint de composantes. Les autoencodeurs et méthodes similaires peuvent apprendre des représentations compactes à partir d’entrées plus complexes.

Le compromis se joue sur l’interprétabilité. Une représentation réduite peut améliorer l’efficacité du modèle et parfois sa performance, mais les composantes obtenues peuvent ne correspondre à rien qu’un expert métier puisse interpréter. Pour les cas d’usage à fort enjeu ou réglementés, cette perte de transparence a des conséquences réelles, et les équipes doivent mettre en balance le bénéfice obtenu et ce qu’elles abandonnent.

Ces termes apparaissent souvent ensemble, car ils sont très proches dans le workflow de ML. Voici un bref aperçu de chacun.

Feature engineering

Le feature engineering désigne la pratique générale qui consiste à préparer les entrées d’un modèle à partir de données brutes. Il englobe la création de features, la transformation des valeurs, la gestion des données manquantes, l’encodage des catégories, l’application de la réduction de dimensionnalité et l’identification des features à utiliser pour l’entraînement. Les autres activités ci-dessous sont des sous-ensembles de ce travail plus large, ou viennent le compléter.

Sélection de features

La sélection de features détermine quelles features de l’ensemble disponible doivent entrer dans le modèle. Les équipes écartent les features redondantes, instables, faiblement corrélées à la cible, difficiles à expliquer en production ou indisponibles au moment de l’inférence.

La sélection peut réduire le surapprentissage et améliorer l’efficacité du modèle. Elle présente aussi des avantages opérationnels. Un modèle fondé sur un nombre restreint de features dont le comportement est stable et bien compris est généralement plus facile à surveiller en production et à auditer qu’un modèle qui s’appuie sur de nombreuses entrées peu informatives ou redondantes. Parmi les approches courantes figurent les méthodes de filtrage statistique, les méthodes wrapper qui évaluent des sous-ensembles de features par rapport à la performance du modèle, et les méthodes intégrées qui s’appuient sur les mécanismes internes du modèle, comme les coefficients de régularisation et les scores d’importance fondés sur les arbres de décision, pour identifier les features qui pèsent réellement.

Extraction de features

L’extraction de features fait émerger une structure à partir de données brutes ou complexes. Un horodatage peut fournir le jour de la semaine, le mois ou le temps écoulé depuis un événement de référence. Un champ de texte libre peut produire des fréquences de termes, des scores d’opinion ou des représentations vectorielles denses (embeddings, ou parfois plongements). Un modèle d’image peut extraire des contours, des textures ou des représentations apprises à partir de couches intermédiaires du réseau.

En pratique, l’extraction recoupe largement la création de features. La distinction tient surtout à l’angle d’approche : l’extraction vise à faire émerger une structure des entrées brutes, tandis que le feature engineering couvre le workflow plus large de préparation de ces entrées pour la modélisation.

Feature stores

Un feature store est un référentiel géré pour les définitions de features, les valeurs de features calculées et les métadonnées associées. Il aide les équipes à réutiliser les features entre projets, à réduire la logique de pipeline dupliquée et à maintenir des définitions de features homogènes entre l’entraînement et l’inférence.

L’augmentation des données élargit les données d’entraînement en générant des versions modifiées d’exemples existants. Elle est surtout utilisée en vision par ordinateur et en traitement du langage naturel, où certaines modifications peuvent accroître la diversité de l’ensemble d’entraînement sans changer l’étiquetage.

Pour les images, l’augmentation peut inclure des retournements, des rotations, des recadrages, des ajustements de luminosité ou de légères translations. Pour le texte, elle peut inclure la substitution de synonymes, la paraphrase ou des perturbations contrôlées. Pour les données tabulaires présentant un déséquilibre de classes, des techniques comme SMOTE génèrent des exemples synthétiques pour les classes sous-représentées.

La question clé, dans toute décision d’augmentation, est de savoir si l’exemple modifié représente toujours la même chose. Faire pivoter l’image d’un produit peut préserver le label dans une tâche de classification e-commerce. Dans un modèle de détection des défauts pour le secteur de l’industrie, l’orientation peut porter une information sur le type de défaut. L’augmentation est utile lorsqu’elle reflète une variation face à laquelle le modèle doit rester robuste ; elle devient contre-productive lorsqu’elle détruit le signal.

Les embeddings sont des représentations vectorielles denses qui encodent les relations dans les données. Ils sont courants dans les workflows de texte, d’image, de recommandation et de catégories à forte cardinalité, lorsque les valeurs brutes exigent une forme numérique plus riche que ce que les schémas d’encodage peuvent fournir.

Par exemple, un ID produit a peu de signification intrinsèque en tant qu’entier brut, mais un embedding peut positionner ce produit près de produits similaires en fonction des descriptions, des comportements d’achat conjoint, des attributs visuels ou des habitudes de navigation. Un embedding de texte peut placer des expressions sémantiquement liées à proximité les unes des autres dans l’espace vectoriel, ce qui le rend utile pour la recherche, la classification, la recommandation et la génération augmentée de récupération (RAG).

Les embeddings occupent une place intéressante par rapport au feature engineering. Ils peuvent servir de features apprises, transmises aux modèles en aval, au même titre que les features conçues manuellement. Ils représentent aussi un autre mode de développement de features : les représentations y sont apprises à partir de grands ensembles de données, plutôt que définies par une analyse métier. En pratique, de nombreux systèmes de ML en production combinent les deux : des embeddings appris pour les features de contenu ou d’identité, et des features conçues pour les signaux comportementaux, temporels et contextuels.

Le feature engineering automatisé utilise des logiciels pour générer et mettre à l’échelle des features candidates à partir de données brutes. Des outils comme Featuretools utilisent des méthodes, notamment Deep Feature Synthesis, pour créer systématiquement des features dans des tables liées. Les systèmes AutoML peuvent générer des transformations, des encodages et des features d’interaction dans le cadre d’un workflow plus large de développement de modèles.

L’automatisation est particulièrement utile lorsque l’espace de recherche est vaste ou que les transformations candidates sont répétitives. Un système peut générer des agrégats glissants, des champs dérivés de dates, des encodages catégoriels et des synthèses au niveau des tables plus vite qu’une équipe ne peut écrire chaque feature manuellement.

La connaissance du domaine doit toutefois continuer à gouverner le travail : la revue experte, la validation et la gouvernance déterminent quelles features peuvent être utilisées.

Le feature engineering en production ne se résume pas au code de transformation. Les équipes ont besoin d’un accès gouverné aux données source, d’une capacité de traitement évolutive pour les grands ensembles de données, de définitions de features réutilisables, d’une fraîcheur fiable des features et d’un chemin clair entre les données d’entraînement et le modèle déployé.

Snowflake prend en charge ce workflow avec Snowflake ML, un ensemble intégré de fonctionnalités de ML de bout en bout reposant sur des données gouvernées, qui couvre le feature engineering, l’entraînement des modèles et l’inférence.

Avec Snowpark, les équipes peuvent écrire des transformations de features en Python ou SQL et les exécuter au plus près des données, sans les déplacer vers un environnement externe. Le Snowflake Feature Store fournit des définitions de features et des vues de fonctionnalités (ou feature views) gérées, ce qui permet aux équipes de créer, matérialiser, récupérer et gérer des pipelines de features dans Snowflake. Les feature views peuvent encapsuler des pipelines Python ou SQL qui transforment les données brutes en features prêtes pour le modèle, et les feature views gérées par Snowflake peuvent s’actualiser automatiquement selon un calendrier défini.

Les Dynamic Tables prennent en charge les pipelines de features incrémentaux lorsque les transformations définies en SQL doivent rester à jour. Snowflake gère les Dynamic Tables comme un pipeline, suit les dépendances et coordonne les actualisations afin que les tables en aval reflètent un instantané concordant de leurs entrées. Les Dynamic Tables prennent également en charge le délai cible, qui spécifie le niveau de fraîcheur attendu des données, ainsi que l’actualisation incrémentielle pour les modèles de transformation pris en charge.

Pour le ML en production, le Snowflake Feature Store peut être utilisé avec le Registre des modèle de Snowflake. Le registre stocke et gère les versions, les métriques et les métadonnées des modèles ; prend en charge l’inférence via Python, SQL ou des points de terminaison d’API REST ; et gère l’accès aux modèles via le contrôle d’accès basé sur les rôles (RBAC).

On présente parfois le feature engineering comme un travail de préparation réalisé avant le vrai début de la modélisation. Mais cette vision sous-estime son importance, ainsi que ce qu’il recouvre vraiment. Chaque décision sur la manière de représenter une variable, de traiter une valeur manquante, d’encoder une catégorie ou de construire une feature de décalage détermine ce que le modèle peut comprendre du domaine dans lequel il opère.

À l’échelle de la production, les décisions de représentation se multiplient. Les features sont réutilisées entre les modèles, reconstruites par différentes équipes et recalculées dans différents environnements. Maintenir ces définitions homogènes, de l’exploration à l’entraînement puis à l’inférence, a un impact direct sur la qualité du modèle.

C’est pourquoi le feature engineering et le MLOps sont étroitement liés. Le feature engineering détermine à partir de quoi le modèle apprend, tandis que le MLOps aide à garantir que ces définitions de features restent homogènes, observables et fiables lorsque les modèles passent du développement à la production.