PulseFit — Présentation du Client
Chaîne de salles de sport · 60 clubs en France · Application mobile de réservation
Contexte & Enjeu
PulseFit est une chaîne de 60 salles de sport présentes dans 25 villes françaises, comptant environ 85 000 abonnés actifs. Le modèle repose sur des abonnements mensuels avec accès à des cours collectifs réservables via une application mobile.
Depuis 12 mois, le taux de désabonnement mensuel est passé de 4% à 6,5%, ce qui représente une perte de chiffre d'affaires significative. La Direction Générale a décidé de présenter une stratégie de rétention au Conseil d'Administration vendredi prochain — dans 5 jours. Votre équipe est missionnée pour produire l'analyse data qui fondera cette présentation.
Données Disponibles
PulseFit met à votre disposition trois sources de données : un fichier abonnés (profil, ancienneté, statut churn), un fichier de fréquentation des cours (réservations, présences, annulations sur 6 mois), et un fichier clubs (taille, ville, capacité, effectifs). Les données sont anonymisées et conformes RGPD.
Comme souvent en mission réelle, les données contiennent des incohérences et valeurs manquantes à traiter — leur qualité fait partie intégrante du défi du projet, pas un détail secondaire.
Le Vrai Défi : 3 Commanditaires, 3 Demandes Différentes
Avant même de toucher aux données, vous devez gérer une réalité très courante en mission data : trois dirigeants attendent trois choses différentes, et votre périmètre de 5 jours ne permet pas de tout traiter en profondeur. Voici les trois briefs reçus en réunion de lancement (lundi 9h) :
Ce n'est pas un piège sans solution : c'est un test de gestion de projet réelle. Le rôle du Chef de Projet Data est précisément de transformer ces trois demandes contradictoires en un périmètre cohérent et justifié, qui apporte une réponse substantielle à chaque commanditaire sans tout faire au même niveau de profondeur. Le choix du périmètre (livrable 1) sera évalué sur sa pertinence et son argumentation, pas sur le fait de "satisfaire tout le monde à 100%" — ce qui est impossible et serait un signal d'alerte, pas une qualité.
Les 3 Rôles de l'Équipe
📋 Chef de Projet Data
- Anime la réunion de lancement (lecture des 3 personas) et rédige la charte de projet
- Arbitre le périmètre IN/OUT et le justifie auprès des 3 commanditaires
- Construit le planning, la matrice RACI et le registre des risques
- Anime les points d'avancement quotidiens avec l'équipe
- Pilote la préparation et l'animation de la soutenance finale
📊 Data Analyst
- Réalise l'analyse exploratoire des données abonnés et fréquentation
- Construit la segmentation des abonnés (clustering ou règles métier)
- Effectue des tests statistiques pour valider les facteurs de churn
- Développe un modèle prédictif simple de risque de désabonnement
- Priorise ses analyses selon le périmètre arbitré par le Chef de Projet
🛠️ Data Engineer / BI
- Audite la qualité des 3 fichiers fournis (doublons, NaN, incohérences)
- Construit un pipeline de préparation reproductible (Python/SQL)
- Développe le dashboard de restitution (Power BI, Tableau, ou Python Dash/Streamlit)
- Documente les choix techniques pour qu'un tiers puisse reprendre le travail
- Alimente l'Analyst avec des données propres et fiables tout au long de la semaine
Consolidation des Rôles selon la Taille de l'Équipe
| Taille équipe | Répartition recommandée |
|---|---|
| 3 personnes | Un rôle par personne — répartition standard décrite ci-dessus |
| 2 personnes | Personne A : Chef de Projet + Data Analyst (cadrage et analyse) · Personne B : Data Engineer / BI (données et restitution) — ou l'inverse selon les appétences |
| 1 personne (solo) | Vous endossez les 3 rôles successivement dans la semaine — le planning ci-dessous reste valable, en solo chaque journée demande simplement plus de discipline de priorisation |
Quelle que soit la taille de l'équipe, les 5 livrables restent obligatoires et le barème ne change pas. Une équipe plus petite doit simplement gérer sa charge de travail avec d'autant plus de rigueur dans l'arbitrage du périmètre — ce qui est en soi une compétence évaluée.
Planning de la Semaine
Chaque jour, l'équipe doit consacrer 10 minutes à un mini-point d'avancement (façon stand-up) noté dans un journal de projet : ce qui a été fait, ce qui bloque, ce qui change au planning. Ce journal sera demandé en annexe du Livrable 2 — il permet d'évaluer le pilotage réel du projet, pas seulement le résultat final.
Livrables & Consignes Précises
- 1Synthétisez les 3 demandes des commanditaires en un tableau comparatif (qui demande quoi, à quel niveau de détail, pour quel usage final). Identifiez explicitement les points de tension entre les trois demandes.
- 2Arbitrez et justifiez un périmètre réaliste pour les 5 jours : que traitez-vous en profondeur, que traitez-vous partiellement, qu'excluez-vous explicitement du périmètre ? Chaque exclusion doit être justifiée (pas seulement "manque de temps" — expliquez le compromis fait et pourquoi ce choix est défendable).
- 3Définissez 3 à 5 critères de succès mesurables du projet, qui permettront de juger si la mission a atteint ses objectifs — pas uniquement "le board a été convaincu" mais des critères vérifiables (ex : "au moins 3 segments d'abonnés identifiés avec un taux de churn différencié de plus de 3 points").
- 4Précisez les contraintes du projet : délai (5 jours fixes), qualité des données (à vérifier, pas garantie), disponibilité limitée des commanditaires pour des questions complémentaires (un seul point de clarification possible par commanditaire, à utiliser judicieusement).
Une charte qui prétend "répondre aux 3 demandes en profondeur" sans aucun arbitrage sera fortement pénalisée — c'est un déni du problème posé, pas une solution. Le jury attend un choix assumé et argumenté, pas une tentative de tout faire à moitié.
- 1Détaillez le planning des 5 jours avec les tâches précises de chaque rôle par jour (au-delà du planning indicatif fourni), les jalons intermédiaires, et les dépendances entre tâches (ex : l'Analyst ne peut commencer la segmentation qu'une fois les données nettoyées par l'Engineer).
- 2Construisez une matrice RACI sur au moins 6 activités du projet (cadrage, nettoyage données, segmentation, modèle prédictif, dashboard, présentation finale). Un seul Accountable par ligne.
- 3Identifiez au moins 6 risques spécifiques à ce projet (ex : données de qualité insuffisante découverte tardivement, désaccord entre rôles sur le périmètre, un membre indisponible un jour, modèle prédictif peu performant). Pour chacun : probabilité, impact, mesure de mitigation concrète.
- 4Tenez un journal de projet quotidien (3-4 lignes par jour) : avancement réel vs prévu, blocages rencontrés, décisions prises en cours de route. Ce journal doit être honnête — un journal qui dit "tout s'est déroulé exactement comme prévu" chaque jour est peu crédible et sera questionné en soutenance.
- 1Réalisez l'analyse exploratoire des données abonnés et fréquentation (distributions, corrélations, comparaison churn/non-churn sur les variables disponibles : âge, ancienneté, fréquence d'usage, ville, type d'abonnement).
- 2Testez statistiquement au moins 2 hypothèses de facteurs de churn (ex : "les abonnés qui réservent moins de 2 cours/mois ont un taux de churn significativement plus élevé"), avec démarche H0/H1 complète et conclusion en langage métier.
- 3Construisez une segmentation des abonnés (clustering K-Means ou règles métier justifiées) en cohérence avec le périmètre arbitré en L1 — si la segmentation fine n'est pas dans le périmètre prioritaire, une segmentation simplifiée mais bien expliquée est acceptable et doit être justifiée comme telle.
- 4Développez un modèle prédictif simple du risque de désabonnement (régression logistique ou arbre de décision), avec évaluation (matrice de confusion, métriques adaptées) et identification des 3 facteurs les plus déterminants.
Si le Chef de Projet a arbitré que la segmentation fine pour le Marketing est secondaire cette semaine, l'Analyst ne doit pas y consacrer 2 jours en contradiction avec cet arbitrage. La cohérence entre ce que dit la charte (L1) et ce que fait réellement l'Analyst (L3) est explicitement évaluée.
- 1Produisez un rapport de qualité des données reçues : taux de valeurs manquantes par colonne et par fichier, doublons détectés, incohérences (ex : dates de désabonnement antérieures à la date d'inscription), et les décisions de traitement prises pour chacune.
- 2Documentez le pipeline de préparation des données (script Python/SQL reproductible) : étapes de nettoyage, jointures entre les 3 fichiers, calcul des variables dérivées utilisées par l'Analyst (ex : fréquence de visite sur 3 mois).
- 3Construisez un dashboard de restitution (Power BI, Tableau, ou Python Dash/Streamlit) présentant les indicateurs clés du churn par segment, par club et par période, navigable par un non-technicien (le board).
- 4Rédigez une note technique courte expliquant les choix d'architecture du pipeline et du dashboard, pour qu'un autre data engineer puisse reprendre le travail sans vous.
- 1Préparez une présentation de 15 minutes destinée au "board" (le jury jouera le rôle des 3 commanditaires) : rappel du périmètre arbitré et pourquoi, résultats clés issus du Livrable 3, démonstration du dashboard, 3 recommandations concrètes.
- 2Assumez explicitement les choix de périmètre devant le board : si une demande n'a pas été traitée en profondeur, dites-le clairement et expliquez le compromis — ne tentez pas de masquer ce qui n'a pas été fait.
- 3Après la présentation, chaque persona posera une question en lien avec sa demande initiale. Chaque membre de l'équipe doit être capable de répondre, pas seulement le Chef de Projet — la répartition des réponses entre rôles fait partie de l'évaluation.
Le jury valorisera une équipe capable de dire "nous avons choisi de ne pas approfondir X cette semaine, voici pourquoi, et voici ce que nous recommandons pour la suite" — bien plus qu'une équipe qui prétend avoir tout traité en surface. C'est exactement la posture attendue d'un vrai chef de projet data face à un board.
Barème & Critères d'Évaluation
| Livrable | Rôle porteur | Points |
|---|---|---|
| L1 — Charte de projet & arbitrage du périmètre | Chef de Projet | 5 |
| L2 — Plan de projet, RACI & risques | Chef de Projet | 3 |
| L3 — Analyse statistique & segmentation | Data Analyst | 5 |
| L4 — Dashboard & pipeline de données | Data Engineer / BI | 4 |
| L5 — Présentation finale au board | Collectif | 3 |
| Total | / 20 — Note individualisée selon le rôle réellement porté + L5 commune à toute l'équipe | |
| Critère | Ce qui est valorisé | Ce qui est pénalisé |
|---|---|---|
| Réalisme de l'arbitrage (L1) | Périmètre clair, justifié, qui apporte une vraie réponse à chaque commanditaire sans prétendre tout traiter. | Périmètre qui ignore un commanditaire sans l'expliquer, ou qui prétend satisfaire les 3 demandes à 100%. |
| Cohérence inter-livrables | L3 et L4 respectent le périmètre arbitré en L1. Le journal de L2 reflète honnêtement la semaine réelle. | L3/L4 qui traitent des sujets exclus du périmètre, ou journal de projet artificiellement lisse. |
| Rigueur technique (L3, L4) | Tests statistiques correctement menés, pipeline reproductible, dashboard réellement navigable. | Analyses non interprétées, pipeline non documenté, dashboard statique non interactif. |
| Posture de pilotage (L2, soutenance) | Risques anticipés avec mitigation réaliste, capacité à expliquer des arbitrages a posteriori. | Registre de risques générique non lié au contexte PulseFit, incapacité à justifier un choix en soutenance. |
| Répartition des rôles en soutenance | Chaque membre répond sur son domaine de responsabilité, démontrant une vraie répartition du travail. | Un seul membre répond à toutes les questions, signe d'un travail non réellement partagé. |
- Un dossier PDF unique avec les 5 livrables dans l'ordre, page de garde avec les rôles de chaque membre
- Annexe : journal de projet quotidien, scripts de pipeline, fichier dashboard ou lien
- Nommé :
NOM1_NOM2_NOM3_PulseFit.pdf - Dépôt avant vendredi 16h, juste avant la soutenance
- 15 minutes de présentation collective
- 10 minutes de questions — une par persona jouée par le jury, plus des questions transverses
- Chaque membre de l'équipe doit prendre la parole sur son domaine de responsabilité
- Question type : "Pourquoi avez-vous choisi de ne pas approfondir la segmentation marketing cette semaine ?"