Cadrer avant de coder : ce que CRISP-DM m’a appris
La plupart des projets data n’échouent pas sur le modèle. Ils échouent avant : sur la question posée. Pourquoi je passe autant de temps sur le cadrage.
Abraham Anaba · 4 min de lecture
En suivant le cours Data Science Methodology d’IBM, inspiré des travaux de John Rollins, j’ai été frappé par une chose : la méthode consacre ses premières étapes entières à la compréhension du problème métier, bien avant de toucher à la moindre donnée. Elle complète en cela CRISP-DM, le cadre historique de la data science.
Le piège de la donnée disponible
Le réflexe naturel, face à un projet data, est de partir de ce qu’on a : « nous avons ces tables, que peut-on en tirer ? ». C’est le meilleur moyen de produire un tableau de bord que personne n’ouvre.
Je pars dans l’autre sens : quelle décision doit être prise, par qui, et à quelle fréquence ? La donnée vient ensuite, au service de cette décision.
Ma méthode, en quatre étapes
- Comprendre la décision : qui décide quoi, à quel rythme, et avec quels indicateurs de succès.
- Fiabiliser les données : sources, qualité, manques ; une seule version des chiffres.
- Construire avec les utilisateurs : prototyper vite, valider avec les métiers, mettre en production.
- Mesurer l’adoption : suivre les indicateurs convenus, et itérer.
Ce que ça change concrètement
Chez Castor Education, ce cadrage a permis de réduire le nombre d’indicateurs suivis, et d’en faire des déclencheurs d’action plutôt que des chiffres à commenter. Un bon indicateur répond à une question simple : qu’est-ce que je fais différemment s’il bouge ?