La difficulté centrale du projet n’était pas de choisir un service cloud. Elle consistait à traduire une question de marché automobile en modèle de données, puis à rendre explicite chaque transformation entre les fichiers sources et les résultats d’analyse.
01La question de marché dépassait les ventes de véhicules
Le point de départ était une base tierce contenant les volumes mondiaux de ventes de véhicules. Cette source répondait à une question importante — combien de véhicules ont été vendus — mais elle ne décrivait ni les composants de la chaîne de traction présents dans chaque modèle, ni leurs fournisseurs, ni leurs prix indicatifs, ni la part du marché potentiellement accessible à des concurrents.
Le projet devait donc réunir des vues commerciales, techniques et organisationnelles du même marché. Les volumes et chiffres d’affaires totaux et adressables devaient être analysés par type d’électrification et par région. Le chiffre d’affaires des composants devait être relié au type de produit, à l’architecture du véhicule et à la position des fournisseurs. Ces questions ne peuvent pas être traitées de manière fiable si les données sur les véhicules, les composants, les fournisseurs et les prix restent dispersées dans des feuilles de calcul distinctes.
02Modéliser la chaîne de traction avant de choisir la plateforme
Avant l’architecture cloud, le projet a défini une hiérarchie à quatre niveaux pour les composants de la chaîne de traction. Le niveau 1 identifie le type de tension. Le niveau 2 correspond au type de produit. Le niveau 3 affine le sous-type. Le niveau 4 indique le rang ou la position du produit dans la chaîne de traction — une distinction qui peut influencer le prix.
Cette hiérarchie constitue l’ossature conceptuelle de la base. Elle attribue à chaque composant une place dans un modèle partagé, afin que les jointures ultérieures ne dépendent pas uniquement des noms de colonnes ou de libellés ad hoc. En data engineering, le projet commence donc par établir le modèle métier avant de sélectionner les services qui l’implémenteront.
Familles basse et haute tension.
La principale famille de composants.
Une classification technique plus précise.
Sa position dans la chaîne de traction et la logique de prix.
03Maintenir l’expertise métier au plus près des données
Quatre éléments maintenus par les métiers capturent des connaissances absentes d’une source générique de ventes automobiles. La Value List décrit les architectures possibles et les composants associés. Le Power Schedule contient les formules de calcul de la puissance. Les Supplier Dictionaries relient les fournisseurs et concurrents adressables aux modèles et composants. La Price List relie les prix à la puissance et à la tension.
Le dispositif conserve ces entrées dans Google Sheets afin que les spécialistes marketing puissent les maintenir dans une interface familière. Les fichiers mis à jour sont copiés dans Cloud Storage par API, tandis que la base automobile tierce est chargée séparément. Les experts métier gardent ainsi la maîtrise des entrées sans avoir à modifier directement le code des notebooks ou les tables BigQuery.
Architectures de véhicules et composants attendus dans chacune.
Formules de calcul de la puissance pour la tarification et le dimensionnement.
Correspondances fournisseurs et concurrents adressables par modèle et composant.
Prix reliés à la puissance du composant et à la tension du système.
Trois contrats de données derrière le workflow
04Rendre explicite la chaîne de transformation
Le dépôt présente un notebook maître et neuf notebooks de traitement. Le notebook maître installe les packages nécessaires, s’authentifie auprès de Google Cloud, récupère les entrées depuis Cloud Storage et utilise Papermill pour exécuter les autres notebooks dans l’ordre. Cette séquence rend les dépendances visibles au lieu de les enfermer dans un script monolithique.
La chaîne nettoie les fichiers entrants ; fusionne la base véhicule avec la Value List ; ajoute le Power Schedule ; applique des règles distinctes de correspondance fournisseurs pour les moteurs électriques et les chargeurs embarqués ; transforme la structure fusionnée ; remodèle les prix basse et haute tension ; puis prépare les résultats de parts de marché. Les artefacts intermédiaires sont réécrits dans le stockage cloud ou interrogés via BigQuery au fil du workflow.
00 Master.ipynb → 01 Cleaning.ipynb → 02 PIHS VL.ipynb → 03 PIHS VL PS.ipynb → 04.1 / 04.2 supplier mapping → 05 Transformation.ipynb → 06 / 07 prices → 08 MARKETSHARE.ipynbLes noms de fichiers et l’ordre d’exécution sont conservés tels qu’ils apparaissent dans le dépôt fourni.
05Utiliser BigQuery comme couche d’analyse
Après les transformations, les sorties CSV préparées sont chargées dans BigQuery. Des requêtes SQL ajoutent les informations de prix et de marché adressable à la structure véhicule-composant transformée. La base résultante peut ensuite être reliée à Google Sheets et Looker Studio pour l’analyse et le reporting.
Cette séparation est essentielle. Google Sheets reste la couche d’entrée modifiable par les métiers. Cloud Storage conserve les fichiers contrôlés. Les notebooks Colab Enterprise implémentent la logique de transformation. BigQuery devient la couche analytique structurée. Looker Studio fournit l’interface de consultation. Chaque service a une responsabilité distincte, sans dupliquer la même logique à plusieurs endroits.
Questions rendues possibles par la couche combinée
Comparer les volumes et chiffres d’affaires totaux et adressables.
Étudier la variation de la demande et des positions fournisseurs selon les régions.
Analyser les répartitions par produit, fournisseur et architecture véhicule.
06Ce que démontre le dépôt public — et ce qu’il ne démontre pas
Le dépôt public constitue une preuve solide du workflow d’ingénierie : l’orchestration des notebooks, l’authentification Google Cloud, l’accès au stockage, les transformations pandas et les requêtes BigQuery sont inspectables. La présentation consigne aussi le modèle de données, l’automatisation visée et les objectifs d’analyse métier.
Il ne publie pas les jeux de données commerciaux, les correspondances fournisseurs, les prix ni les tableaux de bord opérationnels. Le dossier public n’établit pas non plus, à lui seul, des niveaux de service de production ou des résultats métier. L’article documente donc l’architecture et l’approche d’implémentation sans transformer un projet étudiant en affirmation non étayée de déploiement industriel.
Ce qui est démontré
- Le dépôt contient le workflow de notebooks et les intégrations cloud.
- La présentation documente la hiérarchie des données et les entrées métier.
- Le code montre le nettoyage, les fusions, les transformations et les opérations BigQuery.
Ce qui reste hors du dossier public
- Les données commerciales d’entrée ne sont pas publiées.
- Les résultats métier et tableaux de bord ne sont pas reproductibles à partir du seul dépôt.
- Les éléments publics n’établissent pas de certification de production ou de sécurité.
07Les enseignements de data engineering du projet
Le projet illustre un principe récurrent : l’architecture cloud est utile lorsqu’elle clarifie les responsabilités. Le modèle métier doit être exprimé dans des structures explicites. Les experts métier ont besoin de moyens contrôlés pour maintenir les entrées. Les étapes de transformation doivent suivre un ordre observable. Les résultats analytiques ont besoin d’une couche stable pouvant alimenter plusieurs interfaces.
Il montre aussi pourquoi « automatiser » ne désigne pas une seule fonction. Copier les fichiers mis à jour, sélectionner la source la plus récente, exécuter les notebooks, charger les tables et rafraîchir l’analyse sont des transitions distinctes. Les traiter séparément facilite le diagnostic des pannes et l’évolution du workflow.
Une hiérarchie partagée évite que les services cloud remplacent la modélisation des données.
Les équipes métier maintiennent les connaissances sans modifier directement les tables analytiques.
Un notebook maître rend explicites l’ordre des traitements et leurs dépendances.
Le code ouvert peut démontrer l’architecture sans exposer de données propriétaires ni exagérer le statut du déploiement.
08Dossier du projet
Le dépôt contient le notebook maître, neuf notebooks de traitement, le README du projet et la présentation de haut niveau. Ensemble, ils constituent une trace publique concise de l’architecture et de la séquence de transformation.
Nicolas Len est crédité comme auteur du projet. Ses profils publics et le dépôt sont liés ci-dessous pour les personnes souhaitant examiner les notebooks ou suivre la suite de son parcours.
Ressources du projet
Nicolas Len
Nicolas Len a développé ce projet pendant ses études en Data Engineering à DSTI. Il associe modélisation du marché automobile, architecture de données cloud, notebooks Python, BigQuery et analyse destinée aux métiers.
Sources et note éditoriale: Article élaboré à partir de la présentation du projet, du README et de l’instantané du dépôt fournis. Les noms de produits, fichiers de notebooks et identifiants techniques sont conservés. L’article décrit l’architecture publique et les éléments d’implémentation sans divulguer ni inférer les données sources propriétaires.