Un modèle d'attrition qui se dégrade en un trimestre ressemble à un problème d'algorithme. Ce n'est presque jamais le cas. Les caractéristiques qui l'alimentent ont été créées une seule fois, pour un instantané de données donné, et rien dans le pipeline ne les reconstruit à l'identique lors de l'exécution suivante.
Préparer les données pour un pipeline de machine learning n'est pas une simple tâche de nettoyage effectuée avant le début de la modélisation. Il s'agit d'une discipline structurelle qui détermine si le modèle reste précis à chaque actualisation des données. Une enquête Gartner de 2025 menée auprès de 1203 responsables de la gestion des données a révélé que 63 % ne disposent pas des bonnes pratiques de gestion des données pour l'IA ou ne savent pas s'ils en disposent, et Gartner prévoit que les entreprises abandonneront 60 % des projets d'IA non étayés par des données prêtes pour l'IA d'ici 2026.
Cet article détaille la discipline en quatre étapes permettant de maintenir les données d'entraînement prêtes pour les modèles, les aspects où cette discipline montre ses limites dans la pratique, et la manière de commencer à la mettre en place sans devoir reconstruire tout un pipeline d'un coup. Les analystes comme les responsables de l'analytique sont tous deux concernés : l'analyste maintient le pipeline au jour le jour, et le responsable est celui qui doit en fin de compte expliquer pourquoi un modèle qui fonctionnait au T1 a cessé de fonctionner au T3.
Le résultat : des données qui restent prêtes pour les modèles, et non des données nettoyées une seule fois
Un jeu de données nettoyé une seule fois n'est pas l'objectif. Un processus qui produit le même schéma, les mêmes types, et les mêmes définitions de caractéristiques à chaque actualisation l'est.
Prêt pour les modèles désigne quelque chose de précis et d'opérationnel : schéma identique, types identiques, gestion des valeurs nulles identique et définitions des caractéristiques identiques, à chaque exécution du pipeline. Le travail de préparation des données qui ne satisfait à ce critère qu'une seule fois n'est pas terminé ; il s'agit d'un instantané que la prochaine actualisation contredira.
La différence est importante, car le risque lié à un pipeline défaillant est silencieux, et non manifeste. Le pipeline fonctionne toujours et continue de produire des résultats ; seule une métrique en aval, une file d'attrition anormale ou une prévision erronée finit par révéler qu'un changement est survenu en amont.
L'étape située le plus en aval, où un modèle est ajusté aux données, est généralement la plus sensible à ce type de modification en amont. Une colonne renommée ou une règle de gestion des valeurs nulles différente peut modifier les résultats sans qu'aucune erreur n'apparaisse jamais dans le pipeline.
Quatre étapes permettent de maintenir les données d'entraînement prêtes pour le modèle à chaque actualisation : verrouiller la cohérence du schéma, détecter la dérive avant qu'elle n'atteigne le modèle, créer les caractéristiques une fois et les réutiliser, et valider les données avant qu'elles ne soient scorées. Chacune d'entre elles bloque une façon spécifique dont les pipelines se dérèglent en toute discrétion.
La méthode : un processus en quatre étapes pour maintenir les données d'entraînement prêtes pour le modèle
Cette séquence s'applique, qu'un pipeline s'exécute dans un workflow visuel, Python ou SQL et dbt. L'outil change ; la rigueur sous-jacente ne change pas. Sauter l'une de ces quatre étapes casse rarement un pipeline sur-le-champ ; cela compromet plutôt une future actualisation, de manière suffisamment discrète pour qu'il soit difficile d'en retrouver la cause.
Verrouiller la cohérence du schéma avant toute chose
La cohérence des schémas signifie que chaque actualisation produit les mêmes noms de colonnes, types et ordre sur lesquels le modèle a été entraîné. Cette garantie ne se produit pas d'elle-même ; quelque chose doit l'imposer.
C'est aussi là que les pipelines ont tendance à connaître une défaillance sans prévenir. Un système source ajoute un champ, en renomme un ou modifie un type, et aucune erreur n'est générée. Le modèle reçoit simplement des inputs différents et renvoie des résultats différents, inexpliqués.
La solution pratique se situe immédiatement après l'ingestion, avant l'exécution de toute transformation : une étape de validation de type qui vérifie le schéma entrant par rapport à ce qu'attend le modèle. Attribuez des types de données explicites par champ au lieu de vous fier par défaut à la détection automatique des types de champs, car la détection automatique est un élément de confort et non une protection contre un système source qui modifie discrètement sa structure. Un champ qui contenait auparavant des nombres entiers et contient désormais des décimales, ou une colonne qui est discrètement passée de la position quatre à la position sept, est exactement le type de changement que cette étape est conçue pour intercepter avant qu'il n'atteigne quoi que ce soit en aval.
Détecter et gérer la dérive avant qu'elle n'atteigne le modèle
La dérive des données correspond au phénomène qui se produit lorsque les propriétés statistiques des données entrantes s'écartent de celles sur lesquelles le modèle a été entraîné. Si elle n'est pas contrôlée, elle dégrade la précision sans qu'aucun événement particulier ne marque le moment où le phénomène s'est produit.
Deux types sont importants ici. La dérive des caractéristiques se produit lorsque les distributions des inputs changent, par exemple lorsqu'une catégorie qui apparaissait auparavant 5 % du temps apparaît soudainement 20 % du temps. La dérive de concept est différente : la relation entre les caractéristiques et le résultat lui-même change, de sorte que le même input ne prédit plus le même résultat.
La technique pratique repose sur une comparaison avec une référence : vérifiez les statistiques récapitulatives, le taux de valeurs nulles, le décompte par catégorie et les moyennes pour chaque actualisation par rapport à un profil de référence stocké, et signalez les écarts avant l'exécution du scoring. C'est précisément pourquoi des données préparées une seule fois finissent par échouer avec le temps, puisque la dérive s'accumule de façon invisible, actualisation après actualisation, jusqu'à ce que les conditions d'entraînement et les conditions actuelles soient suffisamment divergentes pour affecter les résultats. Un modèle d'attrition entraîné sur un an de comportement de facturation, par exemple, peut continuer à attribuer des scores en toute confiance alors même que la base de clients sous-jacente évolue.
Créez des caractéristiques une fois, réutilisez-les à chaque exécution
Créer une caractéristique consiste à dériver un champ, un âge à partir d'une date de naissance, un calcul d'ancienneté à partir de deux dates, qui apporte à un modèle un signal que les champs bruts ne véhiculent pas à eux seuls. Cette discipline, l'ingénierie des caractéristiques, mérite d'être comprise avant de décider de la façon de l'encoder.
Le mode de défaillance ici est une dérive silencieuse de la logique elle-même. Les calculs de caractéristiques recréés manuellement à chaque actualisation ont tendance à s'écarter de leur définition d'origine, une règle de limite de date étant calculée légèrement différemment d'une exécution à l'autre, jusqu'à ce que deux exécutions de la « même » caractéristique ne soient plus comparables.
La solution consiste à encoder la transformation sous la forme d'une étape de pipeline réutilisable et versionnée, plutôt que comme un calcul ponctuel réexécuté de mémoire ou à partir d'un ancien script. Dès lors que la logique d'une caractéristique réside à un seul endroit, chaque actualisation la calcule de la même manière, et toute modification apportée à cette logique devient un changement délibéré plutôt qu'un accident. Cela donne également à toute personne auditant le modèle ultérieurement une définition unique à vérifier, plutôt qu'une série de formules de feuille de calcul légèrement différentes réparties dans une douzaine de dossiers mensuels.
Validez avant que les données n'atteignent le modèle, et non après
La validation est le contrôle qui s'exécute après la préparation et avant le scoring, confirmant que les données correspondent au format et aux plages attendus par le modèle. L'ignorer ne supprime pas le risque ; cela ne fait que déplacer le risque en aval vers quiconque consulte les résultats du modèle.
Les nouvelles données transmises à un modèle entraîné doivent correspondre au format utilisé pour l'entraîner. Une incompatibilité non annoncée de schéma ou de type génère silencieusement des prédictions erronées plutôt qu'un message d'erreur, de sorte que rien dans le pipeline ne signale d'anomalie avant qu'une décision ne soit prise sur la base de résultats incorrects.
Une porte de validation, des seuils de taux de valeurs nulles, des listes de catégories attendues, des contrôles de plage, devraient interrompre le pipeline plutôt que de laisser passer des données douteuses. Lorsque l'écart ne concerne qu'une poignée de valeurs manquantes dans un champ numérique, l'imputation peut les remplacer par une moyenne, une médiane, ou un mode plutôt que de laisser une valeur nulle fausser les résultats du modèle.
Il s'agit de la même sensibilité mentionnée précédemment : l'étape d'ajustement du modèle réagit davantage aux modifications en amont que toute autre étape. C'est exactement pourquoi la validation a sa place juste avant, et non plus en amont où davantage d'éléments peuvent encore changer par la suite.
Les limites en pratique : la défaillance silencieuse d'un modèle d'attrition
Le modèle d'attrition d'une équipe analytique des opérations de souscription est devenu aveugle à sa cohorte de clients la plus récente et à la croissance la plus rapide pendant deux trimestres entiers, et le modèle lui-même n'a jamais été le problème.
L'équipe a constitué ses données d'entraînement mensuelles en fusionnant trois systèmes : Chargebee pour les données de facturation et de relance, Zendesk pour le volume de tickets d'assistance et le sentiment, et un export CRM pour l'ancienneté des comptes. Chaque système a apporté sa propre part à l'ensemble : l'historique des échecs de paiement de Chargebee, la fréquence des tickets et les scores de sentiment de Zendesk, et l'ancienneté issue du CRM. Une caractéristique résultante, days_since_last_invoice_failure, a été créée à partir de l'historique des relances de Chargebee et actualisée avec tout le reste chaque mois.
Après la migration d'un système de facturation, ce champ est resté figé silencieusement à sa valeur pré-migration pour chaque compte créé après la date de migration. Ces comptes plus récents ont continué à rapporter indéfiniment le même nombre de « jours depuis la défaillance », et le modèle a interprété ce chiffre figé comme un comportement de paiement systématiquement sain.
Le coût n'apparaissait nulle part à proximité du pipeline lui-même. Pendant deux trimestres, le modèle d'attrition était structurellement aveugle à sa cohorte la plus récente et à la croissance la plus rapide, non pas parce que le modèle avait fait une mauvaise prédiction, mais parce que ses données d'entraînement donnaient à l'ensemble de cette cohorte l'apparence d'un risque uniformément faible. Il s'agit d'un angle mort important : l'intelligence de l'expérience client pilotée par l'IA peut identifier les clients présentant jusqu'à 5 fois plus de risques d'attrition lorsque le signal sous-jacent est intact, ce qui correspond précisément à l'avantage qu'un champ figé efface discrètement.
Un analyste a fini par remarquer que la file d'attente des risques d'attrition de l'équipe de rétention était étrangement vide de toute personne inscrite au cours des deux derniers trimestres, et a fait remonter cet écart au champ figé. Un contrôle de dérive comparant les distributions de valeurs par cohorte d'inscription, du type décrit ci-dessus, aurait immédiatement signalé le problème : le fait que chaque compte d'une cohorte partage une seule et même valeur immuable est une anomalie qu'une comparaison par cohorte détecte, même si elle disparaît au sein d'une moyenne agrégée.
Grâce aux étapes de cohérence des schémas et de détection des dérives en place, le même type d'événement lié à la migration de la facturation est détecté en un seul cycle d'actualisation au lieu de deux trimestres. Le travail préparatoire ci-dessus, schéma verrouillé, dérive vérifiée, caractéristiques versionnées, constitue précisément le point de départ ; un aperçu étape par étape pour y parvenir l'explique plus en détail.
À quoi ressemble un pipeline finalisé, prêt pour le modèle
Un pipeline finalisé et prêt pour le modèle exécute les quatre étapes ensemble : schéma verrouillé lors de l'ingestion, dérive surveillée par rapport à une base de référence stockée, caractéristiques versionnées et réutilisées plutôt que reconstruites, et une porte de validation placée avant le scoring. Tout s'exécute selon une planification récurrente, de sorte que les données d'entraînement s'actualisent sans que personne n'ait à les recréer manuellement.
Un pipeline encore vérifié manuellement à chaque exécution n'est pas automatisé. C'est une tâche planifiée associée à un inspecteur non rémunéré, et cet inspecteur est la première personne blâmée lorsque quelque chose change discrètement en amont.
Une version de cette démarche s'est concrétisée avec l'équipe analytique de McGraw Hill Education, qui a transformé des analystes métier en personnes créant leurs propres modèles prédictifs sans écrire de code. « Cela nous a permis de transformer des analystes métier en data scientists sans écrire une seule ligne de code », a déclaré Fabio Italiano, VP Analytique et gestion de l'information de l'entreprise, en décrivant un workflow de prédiction de l'attrition développé sur Alteryx One.
C'est la même séquence que parcourt la Modélisation assistée de bout en bout : sélection de la cible, confirmation du type de données, nettoyage des valeurs manquantes, évaluation des caractéristiques et comparaison des algorithmes dans un classement, sans nécessiter d'expertise approfondie en data science. Il s'exécute dans Designer pour les équipes des éditions Professionnelle ou Entreprise disposant d'un accès Utilisateur complet, dans le cadre du module complémentaire distinct Intelligence Suite.
L'étape d'ajustement du modèle à la fin de cette séquence est explicitement documentée comme étant sensible aux modifications en amont, cette même sensibilité contre laquelle l'ensemble de ce processus s'est prémuni dès la première étape. Les nouvelles données scorées ultérieurement doivent toujours correspondre au format utilisé pour entraîner le modèle, la même logique de contrôle de validation que précédemment, simplement appliquée à l'étape de scoring au lieu de l'étape de préparation.
Rien de tout cela ne nécessite de renoncer à la visibilité sur ce qui a changé ou quand. Les workflows versionnés et planifiés pour s'exécuter automatiquement conservent également un historique indiquant qui a modifié quoi et quand une actualisation donnée s'est exécutée, offrant ainsi le type d'auditabilité dont un pipeline reproductible a besoin, quel que soit l'outil sous-jacent. Cette traçabilité relève de la gouvernance générale de la plateforme, et non d'une affirmation relative à une supervision spécifique aux modèles, mais c'est tout de même ce qui permet à une équipe de répondre à la question « qu'est-ce qui a changé depuis le mois dernier » sans devoir reconstituer la réponse de mémoire.
Quand un pipeline axé sur le code est le mieux adapté
Une équipe disposant d'une fonction d'ingénierie ML dédiée qui gère déjà des feature stores en Python ou dbt n'a pas besoin d'ajouter un deuxième outil pour réaliser l'une des quatre étapes ci-dessus. La discipline, les vérifications de schéma, les caractéristiques versionnées, les jalons de validation importent plus que l'outil qui les applique.
Les fonctionnalités de test intégrées de dbt appliquent déjà deux de ces étapes au sein d'un workflow axé sur SQL que les équipes d'ingénierie utilisent déjà au quotidien. Les tests de non-nullité, les tests de valeurs acceptées et les tests de relations couvrent la cohérence et la validation des schémas, sans avoir à quitter la couche de transformation que ces équipes connaissent déjà.
Les pipelines basés sur Python, construits sur pandas et scikit-learn, offrent un contrôle total sur la logique de caractéristiques personnalisées et les seuils de détection de dérive qu'un outil visuel peut ne pas exposer. Pour les ingénieurs à l'aise avec la maintenance de ce code, c'est souvent la voie la plus flexible.
Le compromis s'opère réellement dans les deux sens. Les pipelines basés sur le code nécessitent une personne capable de lire et de maintenir ce code, ce qui représente un coût réel lorsque cette personne s'en va ou change d'équipe. Un workflow visuel troque une partie de cette flexibilité contre un pipeline que n'importe quel analyste de l'équipe peut ouvrir, lire et auditer sans avoir à demander à un ingénieur de le guider.
La règle de décision est simple. Si les ingénieurs assurent déjà la maintenance de ce pipeline dans dbt ou Python, cette voie est généralement déjà privilégiée, et l'ajout d'un deuxième outil ne fait qu'ajouter de la surcharge. Si le pipeline réside actuellement dans la mémoire de quelqu'un et dans un dossier d'exports de feuilles de calcul, un outil guidé comble cette lacune plus rapidement que le développement de capacités d'ingénierie à partir de zéro, en particulier pour une équipe qui ne dispose pas d'un ingénieur dédié à affecter au projet.
Comment commencer à petite échelle
Ne reconstruisez pas tout le pipeline en une seule fois. Choisissez l'unique caractéristique qui est le plus souvent reconstruite de mémoire et encodez-la d'abord sous la forme d'une étape réutilisable et versionnée ; ce simple changement élimine généralement la source la plus courante de dérive silencieuse.
Ajoutez ensuite un contrôle de validation : un seuil de taux de valeurs nulles sur le champ le plus susceptible d'échouer silencieusement, le genre de valeur gelée ou manquante qui semblait correcte dans le scénario d'attrition ci-dessus jusqu'à ce que quelqu'un en retrouve l'origine. Une règle appliquée vaut mieux qu'une douzaine de règles planifiées qui ne sont jamais créées.
Établissez un profil de référence du jeu de données d'entraînement actuel avant de modifier quoi que ce soit d'autre : le nombre de lignes, les taux de valeurs nulles et la distribution des catégories tels qu'ils se présentent aujourd'hui. Cette référence est ce à quoi la prochaine actualisation est comparée, et sans elle, la détection de dérive n'a aucun élément de comparaison.
Planifiez la plus petite version fonctionnelle du pipeline pour qu'elle s'exécute automatiquement une fois, même avant que chaque étape ne soit automatisée. Cette unique exécution constitue le véritable test pour vérifier si la cohérence d'une actualisation à l'autre est maintenue, et non un plan sur papier.
Considérez ce premier rafraîchissement automatisé réussi comme la preuve de faisabilité, et non comme le pipeline finalisé. Développez à partir de là, une caractéristique, une règle de validation, un contrôle de dérive à la fois, jusqu'à ce que l'ensemble du pipeline d'entraînement se comporte de la même manière à chaque exécution.
Alteryx One propose un essai gratuit aux équipes qui souhaitent essayer de créer ce type de pipeline, de la préparation des données à la Modélisation assistée, avant de s'engager dans un déploiement complet. Essai gratuit.