Vous ne commencez pas par le modèle. Vous commencez par une décision que quelqu’un prendra autrement si la prédiction existe. Tant que cette phrase n’est pas écrite, vous n’avez pas un problème de machine learning : vous avez une envie de tableau de bord, ou une demande floue.
Le cadrage tient en cinq questions, dans cet ordre. L’algorithme n’apparaît nulle part.
Que vous savez refuser de modéliser trop tôt. Un candidat qui sort XGBoost à la première minute a déjà perdu la question. Un candidat qui reformule la demande en décision, grain, action, mesure, risque a déjà le niveau.
Le piège classique : confondre prédire et expliquer. « Pourquoi les clients partent » est une question d’analyse. « Quels clients relancer la semaine prochaine » est une question d’apprentissage. Les deux se valent ; elles ne se cadrent pas pareil, et elles ne se livrent pas pareil.
« Le métier veut juste un modèle de churn. »
Vous traduisez. Churn pour une campagne de rétention à J-30, sur les contrats encore actifs, avec un budget de N appels, et un succès mesuré au taux de conservation à 90 jours. Si cette traduction est impossible, le sujet n’est pas mûr.
« On n’a pas encore les données. »
C’est une information de cadrage, pas un obstacle à ignorer. Vous posez ce qui devrait exister pour que la décision soit possible : la cible, sa date de constat, les variables disponibles à l’instant de prédire. Souvent, le cadrage révèle qu’il manque l’étiquette, pas l’algorithme.
La phrase qui montre l’expérience : un projet ML bien cadré a l’air d’un projet métier avec une prédiction dedans, pas d’un concours de scores.