Cas d'usage › Koesio

Création d'un modèle de prédiction des départs clients pour un distributeur IT

Koesio

Services et distribution IT

4
semaines du cadrage au modèle déployé
3
familles de signaux croisées
Prod
déployé, en validation terrain

Un client de services informatiques ne prévient pas qu'il part. Il commande un peu moins, ouvre des tickets un peu différents, répond un peu plus tard. Puis il ne renouvelle pas.

Type de projet Produits IA
Durée 4 semaines
Expertises Modélisation prédictive
Préparation de données
Mise en production et surveillance de modèle
Technos Python
XGBoost
Scikit-learn
Pipeline de données

Contexte et enjeux

Un contrat de services se reconduit par défaut, ce qui masque le désengagement jusqu'au jour de la non-reconduction. Ce jour-là, la discussion commerciale est déjà perdue.

Les signaux existaient pourtant, éparpillés entre l'historique de commandes, les tickets de support et l'activité sur les différents canaux. Aucun ne dit grand-chose seul, et personne n'avait le temps de les recouper client par client.

L'enjeu n'était pas de produire un indicateur de plus. C'était de donner à l'équipe commerciale une liste courte de comptes à rappeler pendant qu'il est encore temps.

Ce qu'on a fait

Croiser trois familles de signaux plutôt qu'une

Approche : le désengagement se voit dans la combinaison

Historique d'achat et rythme de consommation, contenu et fréquence des tickets de support, engagement multi-canal. Pris ensemble, ces signaux distinguent un client calme d'un client qui s'en va.

Construire le pipeline avant le modèle

Technologies : Python, collecte, nettoyage, préparation des variables

La qualité d'un modèle de churn se joue dans la préparation des données, pas dans le choix de l'algorithme. Le pipeline est reproductible de la collecte jusqu'aux variables.

Entraîner et valider sans se mentir

Technologies : XGBoost, Scikit-learn, validation croisée

Modèle optimisé par validation croisée et réglage des hyperparamètres. Un modèle de churn qui n'est pas validé correctement produit surtout de la confiance mal placée.

Déployer avec la surveillance qui va avec

Focus : un modèle qui vieillit doit se voir

Mise en production accompagnée d'un suivi des performances. Les comportements clients bougent, et un modèle laissé sans surveillance dérive en silence.

Conclusion

Le modèle est déployé et en phase de validation sur le terrain. Il sort déjà une liste de comptes à risque que l'équipe commerciale peut travailler.

Nous ne publions pas de gain chiffré tant que la validation terrain n'est pas terminée. Un taux de rétention annoncé trop tôt est une promesse, pas un résultat.

La suite se joue côté commercial : un score n'a de valeur que s'il déclenche une action définie à l'avance. C'est le chantier qui reste à mener avec les équipes.

Ce qu'une équipe commerciale attend d'un modèle, c'est un nom à rappeler lundi matin.

Ce que ça a changé

L'équipe commerciale sait où concentrer ses efforts de rétention avant qu'il soit trop tard, au lieu de découvrir un départ au moment du renouvellement.

Détails techniques

Pipeline de données Python complet : collecte, nettoyage, préparation des variables.
Modèle XGBoost optimisé par validation croisée et réglage des hyperparamètres avec Scikit-learn.
Déploiement en production avec suivi des performances du modèle.

Un projet similaire ?

Discutons de vos enjeux et voyons ce qui pourrait vous faire gagner du temps chez vous.