# Construire une base de données cloud pour analyser les chaînes de traction de véhicules électriques HTML canonique: https://dsti.school/fr/techblog/base-donnees-cloud-analyse-chaines-traction-electriques Cette version Markdown est générée par le même build du site statique DSTI que la page HTML canonique. Elle est destinée à la lisibilité machine et à une consultation concise. [DSTI TechBlog](https://dsti.school/fr/techblog) / Étudiants Étudiants Data engineering · intelligence de marché automobile Une base de ventes automobiles peut indiquer combien de véhicules ont été vendus. À elle seule, elle ne dit pas quels composants de la chaîne de traction équipent chaque modèle, qui les fournit, comment les prix évoluent avec la puissance et la tension, ni quelles opportunités sont accessibles à des fournisseurs concurrents. Nicolas Len a conçu un workflow Google Cloud pour relier ces questions. NL Nicolas Len Étudiant en Data Engineering à DSTI au moment du projet 23 juin 2026 12 min de lecture Projet étudiant de 2024 google-cloud bigquery data-engineering vehicules-electriques analyse-marche projet-etudiant ## Une question de marché, plusieurs couches de données Google Sheets Value List, schedules, fournisseurs, prix Cloud Storage Fichiers d’entrée et intermédiaires contrôlés Colab Enterprise Un notebook maître et neuf notebooks de traitement BigQuery Tables fusionnées de prix et de marché adressable Looker Studio Analyse accessible aux équipes 4 niveaux de hiérarchie des composants 4 éléments de données maintenus par les métiers 1 notebook maître 9 notebooks de traitement 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. NL Un projet étudiant de Data Engineering Nicolas a développé ce projet pendant ses études en Data Engineering à DSTI. Le dépôt public contient les notebooks d’orchestration et de transformation, tandis que la présentation fournie documente le workflow métier visé et les objectifs d’analyse. Les données commerciales sous-jacentes ne sont pas publiées. Le résultat utile n’est pas simplement « une base dans le cloud ». C’est une chaîne reproductible de contrats de données, de transformations et de couches d’analyse qui maintient l’expertise métier au cœur du workflow d’ingénierie. ## 01 La 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. ## 02 Modé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. Niveau 1 Type de tension Familles basse et haute tension. Niveau 2 Type de produit La principale famille de composants. Niveau 3 Sous-type de produit Une classification technique plus précise. Niveau 4 Rang du produit Sa position dans la chaîne de traction et la logique de prix. ## 03 Maintenir 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. VL Value List Architectures de véhicules et composants attendus dans chacune. PS Power Schedule Formules de calcul de la puissance pour la tarification et le dimensionnement. SD Supplier Dictionary Correspondances fournisseurs et concurrents adressables par modèle et composant. PL Price List Prix reliés à la puissance du composant et à la tension du système. ### Trois contrats de données derrière le workflow Maintenable par les experts métier Google Sheets conserve des entrées accessibles aux équipes. Transfert contrôlé Cloud Storage sépare les fichiers de travail des tables analytiques. Transformation reproductible L’ordre et le code des notebooks rendent chaque étape inspectable. ## 04 Rendre 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. Orchestration maître `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.ipynb` Les noms de fichiers et l’ordre d’exécution sont conservés tels qu’ils apparaissent dans le dépôt fourni. 01 Cleaning Standardiser les fichiers sources. 02 PIHS + VL Ajouter les architectures de composants aux modèles. 03 + Power Schedule Calculer la puissance des composants. 04.1 + fournisseurs EMOT Appliquer les règles des moteurs électriques. 04.2 + fournisseurs OBC Appliquer les règles des chargeurs embarqués. 05 Transformation Réorganiser les composants par année et supprimer les champs redondants. 06 Prix LV Remodeler les prix basse tension. 07 Prix HV Remodeler les prix haute tension. 08 Part de marché Préparer la couche finale d’analyse de marché. ## 05 Utiliser 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. Google Sheets Value lists, schedules, fournisseurs et prix maintenus par les métiers. Cloud Storage Fichiers d’entrée, intermédiaires et de sortie. Colab Enterprise Notebooks Python et pandas de transformation. BigQuery Tables de prix, d’adressabilité et d’analyse. Looker Studio Exploration et reporting pour les équipes. ### Questions rendues possibles par la couche combinée Volumes et chiffre d’affaires Comparer les volumes et chiffres d’affaires totaux et adressables. Répartition régionale Étudier la variation de la demande et des positions fournisseurs selon les régions. Parts de marché fournisseurs Analyser les répartitions par produit, fournisseur et architecture véhicule. ## 06 Ce 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é. ## 07 Les 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. 01 Modéliser le domaine en premier Une hiérarchie partagée évite que les services cloud remplacent la modélisation des données. 02 Séparer les entrées modifiables des sorties gouvernées Les équipes métier maintiennent les connaissances sans modifier directement les tables analytiques. 03 Orchestrer des étapes visibles Un notebook maître rend explicites l’ordre des traitements et leurs dépendances. 04 Énoncer la limite des preuves Le code ouvert peut démontrer l’architecture sans exposer de données propriétaires ni exagérer le statut du déploiement. ## 08 Dossier 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 ![Portrait de Nicolas Len](https://media.dsti.school/wp-content/uploads/2024/11/20150451/Nikolai-LinkedIn-Photo.avif) ### 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. [GitHub](https://github.com/nicolas-len)[LinkedIn](https://www.linkedin.com/in/niclen/)[Project](https://github.com/nicolas-len/gcp-bigquery-market-database) 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.