Projet de portfolio Apache Spark au Maroc : concevoir une démonstration concrète

Choisir un projet adapté à son niveau

Pour un projet Apache Spark débutant, visez un périmètre limité : quelques fichiers, une question métier précise, trois à cinq indicateurs et un résultat visuel ou tabulaire. Le but n’est pas de simuler un système de production complexe. Il s’agit de faire comprendre votre démarche, depuis les données brutes jusqu’à une conclusion exploitable.

Un projet de portfolio solide permet de voir plusieurs compétences à la fois : lecture de fichiers, exploration avec DataFrames, nettoyage, transformations, agrégations, sauvegarde dans un format adapté et vérification des résultats. PySpark est un choix accessible si vous connaissez déjà Python. Gardez toutefois le code lisible : un notebook peut servir à l’exploration, tandis que les étapes réutilisables gagnent à être placées dans des fonctions ou des fichiers séparés.

Évitez les sujets trop ambitieux, comme reproduire toute l’architecture analytique d’une banque ou traiter des milliards de lignes sur votre ordinateur. Une maquette sur un échantillon peut être pertinente si vous expliquez ce qu’il faudrait changer pour passer à l’échelle. Définissez aussi votre public : un recruteur technique voudra examiner le code et les tests ; un client métier voudra surtout comprendre le problème, les indicateurs et les limites.

• Choisissez un domaine que vous pouvez expliquer : transport, énergie, commerce, tourisme ou activité publique.
• Limitez la première version à une question et à un pipeline de bout en bout.
• Prévoyez un résultat compréhensible sans devoir lire tout le code.
• Si vous débutez, apprenez d’abord les bases de Python et des DataFrames avant d’ajouter l’optimisation distribuée.

Partir d’un besoin concret : brief du projet

Voici un brief réutilisable pour un exercice pratique Apache Spark. Il porte sur l’analyse de trajets, mais la structure s’adapte à d’autres domaines. Ne prétendez pas qu’un jeu de données représente réellement une ville, un opérateur ou une entreprise si vous n’en connaissez pas la provenance. Les données synthétiques conviennent aussi, à condition de l’indiquer clairement.

• Objectif : produire une synthèse des trajets par période et par zone, afin d’illustrer comment des données brutes peuvent aider à repérer des variations d’activité.
• Entrées : fichiers CSV publics dont la licence autorise la réutilisation, ou données générées artificiellement. Les champs peuvent comprendre une date, une zone de départ, une zone d’arrivée et une durée.
• Traitement : vérifier le schéma, traiter les valeurs manquantes, écarter ou signaler les lignes invalides, calculer des agrégats et enregistrer une sortie documentée.
• Résultats : volume de trajets par période, durée moyenne par zone si le champ existe et contrôles sur les valeurs aberrantes. Ne tirez pas de conclusion causale à partir de simples agrégats.
• Livrables : dépôt de code, README, exemples de commandes, tests automatisés, aperçu de résultats agrégés et courte démonstration.
• Critère de réussite : une autre personne peut comprendre les hypothèses et relancer le pipeline avec les données autorisées, sans dépendre de vos chemins locaux.

Préparer les données, fichiers ou ressources

Avant de coder, vérifiez l’origine des données, leur licence, leur date de publication et leur dictionnaire de champs. Un fichier téléchargeable n’est pas automatiquement libre de réutilisation. Lorsque la source est incertaine, remplacez les données par un jeu synthétique ou limitez-vous à un aperçu explicitement autorisé. Archivez la référence de provenance et les conditions d’usage dans la documentation.

Préparez un petit échantillon de développement, un emplacement de données exclu du dépôt si nécessaire, et une configuration qui ne contient aucun secret. Organisez les répertoires de façon simple : documentation, code source, tests et résultats d’exemple. Les résultats publiés doivent être agrégés et ne pas permettre de retrouver des personnes ou des opérations confidentielles.

Si vous utilisez des données d’entreprise dans le cadre d’une mission, demandez une autorisation explicite avant toute réutilisation, même après suppression des noms. Des dates précises, des lieux rares ou des combinaisons d’attributs peuvent rendre des personnes ou des organisations reconnaissables. En cas de doute, ne publiez pas les données : montrez plutôt un schéma fictif et un jeu synthétique.

• Réunir : Python, une installation compatible de Spark, un environnement de développement et un jeu de données autorisé.
• Noter : provenance, licence, définition des colonnes, unités, fuseau horaire éventuel et limites connues.
• Ne pas versionner : données personnelles, fichiers bruts confidentiels, mots de passe, clés, jetons ou informations internes.
• Prévoir : un échantillon réduit reproductible et une instruction claire pour obtenir les données autorisées.

Réaliser le projet par étapes

Commencez par écrire la question métier et les décisions que vos indicateurs pourraient éclairer. Cela évite d’ajouter des graphiques ou des transformations qui ne répondent à aucun besoin. Ensuite, inspectez les fichiers et établissez un schéma attendu. Avec Spark, privilégiez des opérations sur DataFrames et des transformations explicites plutôt que de rapatrier inutilement toutes les lignes sur la machine avec une conversion locale.

Construisez le pipeline par petites étapes nommées : lecture, validation, nettoyage, calcul, écriture. Affichez des informations de contrôle ciblées pendant le développement, mais ne laissez pas le dépôt imprimer des données sensibles. Rendez les chemins et paramètres configurables afin qu’une autre personne puisse exécuter le projet dans son propre environnement.

• 1. Créer le dépôt et le README initial : objectif, périmètre, environnement et provenance prévue des données.
• 2. Charger un échantillon en déclarant le schéma attendu. Vérifier que les dates et les nombres sont interprétés correctement.
• 3. Explorer les données : compter les lignes, examiner les valeurs manquantes et les catégories, repérer les doublons et les formats inattendus.
• 4. Écrire des règles de qualité explicites : par exemple, durée positive, date valide et zones présentes. Mesurer les lignes rejetées au lieu de les supprimer silencieusement.
• 5. Construire les transformations PySpark : normaliser les champs utiles, filtrer selon des règles documentées et calculer les agrégats par période et zone.
• 6. Enregistrer les résultats dans un format documenté, puis relire la sortie pour contrôler qu’elle contient les champs et les valeurs attendus.
• 7. Ajouter les tests, un exemple de commande d’exécution et une démonstration courte présentant le besoin, le pipeline et les résultats.

Tester, corriger et documenter

Un portfolio Apache Spark est plus convaincant lorsque les contrôles sont visibles. Les tests peuvent utiliser de petites données construites pour vérifier des cas connus : ligne valide, valeur manquante, date mal formée, doublon et durée impossible. Vérifiez les résultats attendus sur ces cas avant de lancer le traitement sur le jeu complet.

Documentez les règles plutôt que de simplement affirmer que les données sont propres. Si vous excluez certaines lignes, dites pourquoi et indiquez la manière dont vous les comptez. Expliquez aussi les choix techniques importants : format d’entrée, type de sortie, hypothèses sur les dates et raisons d’un éventuel regroupement. N’annoncez pas un gain de performance sans mesure reproductible et comparaison équitable.

• Checklist de tests et de contrôle qualité :
• Le pipeline démarre à partir d’un environnement neuf en suivant les instructions du README.
• Le schéma lu correspond aux types prévus ; les dates, nombres et valeurs nulles sont contrôlés.
• Les doublons et les lignes invalides sont détectés ou traités selon des règles indiquées.
• Les totaux et agrégats obtenus sur un petit jeu de test correspondent à des résultats calculés à l’avance.
• Le nombre de lignes en entrée, rejetées et conservées peut être expliqué.
• La sortie se relit correctement et ne contient pas de colonnes confidentielles inutiles.
• Les chemins, paramètres et dépendances ne sont pas codés en dur avec des informations personnelles ou des secrets.
• La documentation distingue faits mesurés, hypothèses et limites ; elle ne surinterprète pas les résultats.

Présenter son travail dans un portfolio

Présentez d’abord le problème en quelques phrases, puis montrez le parcours de la donnée : entrée, contrôles, transformations et sortie. Une capture d’écran d’un tableau de résultats agrégés ou d’un schéma du pipeline peut aider, mais elle ne remplace pas le code ni les instructions de reproduction. Ajoutez une courte démonstration enregistrée seulement si elle n’affiche aucune information sensible.

Votre README doit répondre aux questions d’un tiers : à quoi sert le projet, quelles données sont utilisées, comment l’installer, comment le lancer, comment exécuter les tests et comment interpréter le résultat ? Ajoutez une section « limites et suites possibles ». Vous pouvez y mentionner l’usage d’un stockage distribué ou une orchestration future, sans prétendre que ces composants ont été implémentés.

Pour documenter sans exposer de données confidentielles, partagez des résultats synthétiques ou agrégés, masquez les chemins locaux, retirez les identifiants et examinez les captures avant publication. Faites aussi un contrôle de l’historique du dépôt : supprimer un secret du dernier fichier ne garantit pas qu’il a disparu des anciennes versions. Si une donnée confidentielle a été publiée, retirez l’accès et suivez la procédure adaptée à sa source.

• À montrer : brief, architecture simple, extraits de code représentatifs, tests et résultats agrégés.
• À expliquer : ce qui a été réalisé par vous, les choix de nettoyage, les hypothèses et les limites.
• À éviter : données brutes non autorisées, secrets, captures de systèmes internes et promesses de performance non mesurées.
• Pour un entretien : préparez une explication courte du problème, une démonstration reproductible et un exemple de défaut que vos contrôles savent repérer.

Le parcours, étape par étape

1. 1Cadrer le besoin — Choisissez une question métier précise et fixez des livrables limités. Définissez ce que le projet permettra d’observer, sans promettre une décision que les données ne peuvent pas justifier.
2. 2Sécuriser les ressources — Vérifiez la provenance et les droits d’usage. Préparez un échantillon public autorisé ou synthétique, et gardez les informations confidentielles hors du dépôt.
3. 3Construire le pipeline — Chargez les données avec un schéma, contrôlez-les, appliquez des transformations PySpark documentées, calculez les agrégats et écrivez une sortie reproductible.
4. 4Valider et corriger — Ajoutez des tests sur des cas connus, vérifiez les volumes et les résultats, puis corrigez les erreurs de types, les doublons ou les règles métier ambiguës.
5. 5Publier une démonstration claire — Rédigez le README, ajoutez des résultats non sensibles et présentez honnêtement les limites. Entraînez-vous à expliquer le projet à un profil technique comme à un interlocuteur métier.

Formations et programmes au Maroc

Compétences clés

Questions fréquentes

Sources

1. Apache Spark — site officiel du projet spark.apache.org
2. Formation intra-entreprise — OFPPT ofppt.ma
3. JobInTech jobintech.academy
4. Traitement distribué des données avec Apache Spark et PySpark — FormaGroup formagroup.ma
5. Apache Spark — FormaGroup formagroup.ma