MERAKI Group — Présentation du Client
Holding e-commerce multi-marques · 5 marques · CA groupe 140 M€/an
Contexte & Enjeu
MERAKI Group est une holding française qui possède 5 marques e-commerce indépendantes (beauté, sport, maison, mode, électronique), chacune née d'un rachat successif et opérant encore sur son propre système — ERP, plateforme e-commerce, conventions de données — sans aucune intégration entre elles.
Chaque mois, l'équipe finance du groupe passe 12 à 15 jours ouvrés à consolider manuellement les chiffres des 5 marques dans Excel pour produire un reporting groupe, avec un taux d'erreur jugé "préoccupant" par la direction. Le Comité de Pilotage se réunit vendredi pour valider l'approche technique et le budget d'un projet de plateforme data unifiée. Votre équipe est missionnée pour produire la première itération de cette plateforme et défendre une feuille de route crédible.
5 Sources de Données Hétérogènes
Le Vrai Défi : 3 Visions Incompatibles du Projet
Avant d'écrire la première ligne de pipeline, vous devez gérer une tension presque universelle en data engineering : vitesse de livraison, qualité de l'architecture, et gouvernance des données tirent le projet dans trois directions différentes. Voici les trois briefs reçus en réunion de lancement (lundi 9h) :
Le Triangle de Tension
⚡ Vitesse
Livrer vite, sur le périmètre qui compte le plus pour le board financier
🏛️ Robustesse
Construire une architecture qui ne devient pas un fardeau technique dans 6 mois
📚 Gouvernance
Documenter et rendre exploitable par les équipes métier, pas seulement par vous
Le rôle du Chef de Projet est de transformer ce triangle de tension en un choix d'architecture assumé et documenté — par exemple : un MVP solide sur les 2 marques principales (réponse à la DSI ET au CFO sur ce périmètre), avec une feuille de route claire et un schéma de gouvernance documenté pour l'extension aux 3 autres marques (réponse à la Responsable Data). Le choix lui-même compte moins que sa justification explicite via des Architecture Decision Records (ADR) — voir section suivante.
L'Outil Central : l'Architecture Decision Record (ADR)
Un ADR (Architecture Decision Record) est un document court qui fige une décision technique structurante : pourquoi elle a été prise, quelles alternatives ont été écartées, et quelles conséquences elle implique. C'est l'outil que tout data engineer sérieux utilise pour ne pas perdre la mémoire des arbitrages — et pour pouvoir les défendre plus tard devant quelqu'un qui n'était pas dans la pièce.
- Quelles marques intégrez-vous en profondeur cette semaine, et lesquelles restent au stade de plan documenté ?
- Quelle approche de transformation retenez-vous (ELT vs ETL) et pourquoi, dans ce contexte précis ?
- Quel modèle de données cible (schéma en étoile, autre) et pourquoi il répond au besoin du CFO et de la Responsable Data ?
- Comment gérez-vous l'hétérogénéité des catégories produit entre marques (mapping manuel, table de référence, etc.) ?
Les 3 Rôles de l'Équipe
📋 Chef de Projet Data Engineering
- Anime la réunion de lancement (lecture des 3 personas) et rédige la charte de projet
- Arbitre le périmètre des marques traitées cette semaine et rédige les ADR structurants
- Construit le planning, la matrice RACI et le registre des risques techniques
- Anime les points d'avancement quotidiens avec l'équipe
- Pilote la préparation et l'animation de la soutenance devant le Comité de Pilotage
⚙️ Data Engineer Pipeline
- Réalise le mapping des schémas entre les sources hétérogènes des marques traitées
- Développe le pipeline d'ingestion et de transformation (Python/SQL)
- Normalise les formats divergents (dates, devises, catégories produit)
- Produit un rapport de qualité des données (complétude, cohérence, anomalies)
- Priorise son travail selon le périmètre arbitré par le Chef de Projet
🏛️ Data Architect / Modélisation
- Conçoit le modèle de données cible (schéma en étoile : faits ventes/commandes, dimensions marque/produit/date/client)
- Rédige le dictionnaire de données et le catalogue pour chaque table
- Définit les règles de gouvernance (propriétaire des données, fréquence de rafraîchissement, niveaux d'accès)
- Schématise la traçabilité des données (lineage) source → transformation → cible
- Travaille en lien constant avec le Data Engineer pour que le modèle reste implémentable dans le délai
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 Architect (cadrage et modélisation) · Personne B : Data Engineer Pipeline (ingestion et transformation) — 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 dans un tableau comparatif (qui demande quoi, pour quel usage, à quel horizon). Identifiez explicitement les tensions entre les trois (triangle vitesse / robustesse / gouvernance).
- 2Arbitrez et justifiez un périmètre réaliste pour les 5 jours : combien de marques sur les 5 traitez-vous en intégration complète cette semaine ? Quelle feuille de route proposez-vous pour les marques restantes ? Justifiez ce choix par rapport aux 3 personas.
- 3Rédigez au moins 2 Architecture Decision Records (format vu en section précédente) sur des choix structurants : approche ELT/ETL retenue, gestion de l'hétérogénéité des formats, ou choix du modèle de données cible.
- 4Définissez 3 à 5 critères de succès mesurables du projet (ex : "le pipeline ingère et transforme correctement 100% des commandes des 2 marques prioritaires, avec moins de 1% de lignes rejetées").
Une charte qui prétend "intégrer les 5 marques avec une architecture parfaitement scalable et un catalogue complet" en 5 jours sera fortement pénalisée — c'est un déni du problème posé. Le jury attend un choix assumé : par exemple, 2 marques intégrées en profondeur + une feuille de route documentée et crédible pour les 3 autres.
- 1Détaillez le planning des 5 jours avec les tâches précises de chaque rôle par jour, les jalons intermédiaires, et les dépendances (ex : le Data Engineer ne peut charger le modèle cible qu'une fois le schéma validé par le Data Architect).
- 2Construisez une matrice RACI sur au moins 6 activités du projet (mapping schémas, développement pipeline, audit qualité, modélisation, documentation/catalogue, présentation finale). Un seul Accountable par ligne.
- 3Identifiez au moins 6 risques spécifiques à ce projet (ex : un format source diffère de ce qui était documenté, volumétrie réelle plus importante que prévue, désaccord entre rôles sur le schéma cible, accès à une source bloqué techniquement). 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. Un journal qui dit "tout s'est déroulé exactement comme prévu" chaque jour sera questionné en soutenance.
- 1Produisez un tableau de mapping entre les colonnes des sources traitées (selon le périmètre arbitré en L1) et le modèle cible défini par le Data Architect — y compris les règles de conversion (formats de date, devises, catégories produit).
- 2Développez le pipeline d'ingestion et de transformation (script Python ou SQL reproductible) pour les marques dans le périmètre, en respectant les ADR rédigés en L1.
- 3Produisez un rapport de qualité des données : taux de valeurs manquantes, doublons détectés, incohérences identifiées (ex : commandes avec une date de livraison antérieure à la commande), et la stratégie de traitement retenue pour chacune.
- 4Documentez les limites connues de votre pipeline à ce stade (ce qui n'est pas encore géré, ce qui devra être renforcé pour passer en production) — l'honnêteté technique est valorisée.
Si le Chef de Projet a arbitré 2 marques prioritaires en L1, le pipeline ne doit pas en traiter 4 superficiellement à la place — mieux vaut 2 marques solidement intégrées que 5 traitées à moitié. Cette cohérence est explicitement évaluée.
- 1Concevez le modèle de données cible sous forme de schéma en étoile : au minimum une table de faits (commandes/ventes consolidées) et 3 dimensions (marque, produit, date — client en option), avec un diagramme clair.
- 2Rédigez un dictionnaire de données pour chaque table : nom de la colonne, type, description métier, règle de qualité associée. Ce dictionnaire doit être compréhensible par un analyste métier d'une des 5 marques, pas seulement par un data engineer.
- 3Définissez des règles de gouvernance : qui est propriétaire de chaque table, à quelle fréquence elle est rafraîchie, qui peut y accéder et avec quel niveau de droit.
- 4Schématisez la traçabilité des données (lineage) : pour une donnée du modèle cible, montrez de quelle source elle provient et quelles transformations elle a subies.
- 1Préparez une présentation de 15 minutes destinée au Comité de Pilotage (le jury jouera le rôle des 3 commanditaires) : rappel du périmètre arbitré et des ADR clés, démonstration du pipeline fonctionnel, présentation du modèle de données, feuille de route pour la suite.
- 2Assumez explicitement les compromis du triangle de tension devant le comité : si la gouvernance complète n'est pas finalisée pour les 5 marques, dites-le clairement et présentez le plan pour y arriver.
- 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 sur son domaine — 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 prioriser ces 2 marques, voici pourquoi via cet ADR, et voici comment nous étendrions cela aux 3 autres" — bien plus qu'une équipe qui prétend avoir tout résolu en surface. C'est exactement la posture attendue d'un chef de projet data engineering face à un comité de pilotage.
Barème & Critères d'Évaluation
| Livrable | Rôle porteur | Points |
|---|---|---|
| L1 — Charte de projet & ADR | Chef de Projet | 5 |
| L2 — Plan de projet, RACI & risques | Chef de Projet | 3 |
| L3 — Pipeline & rapport de qualité | Data Engineer Pipeline | 5 |
| L4 — Modèle de données & gouvernance | Data Architect | 4 |
| L5 — Présentation finale au Comité | 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 et justifié, ADR qui documentent un vrai compromis dans le triangle de tension. | Périmètre qui prétend tout traiter (5 marques, architecture parfaite, gouvernance complète) sans compromis assumé. |
| Cohérence inter-livrables | Le pipeline (L3) et le modèle (L4) respectent strictement le périmètre et les ADR posés en L1. | Pipeline qui traite des marques hors périmètre, ou modèle de données déconnecté des choix de L1. |
| Rigueur technique (L3, L4) | Pipeline reproductible et documenté, schéma en étoile cohérent, dictionnaire de données compréhensible par un non-technicien. | Script non reproductible, modèle de données sans justification, catalogue incomplet ou trop technique pour le métier. |
| Qualité des ADR | Contexte, alternatives réellement envisagées et écartées avec raison, conséquences anticipées. | ADR qui n'énonce qu'une décision sans alternative ni justification — un simple choix non documenté. |
| Posture de pilotage (L2, soutenance) | Risques anticipés avec mitigation réaliste, capacité à expliquer un arbitrage a posteriori. | Registre de risques générique non lié au contexte MERAKI, incapacité à justifier un choix en soutenance. |
- 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 du pipeline, schémas du modèle de données
- Nommé :
NOM1_NOM2_NOM3_MERAKI.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 ce modèle de données plutôt qu'un autre pour les 3 marques restantes ?"