Créer un portfolio Apache Airflow au Maroc : un projet concret, étape par étape

Choisir un projet adapté à son niveau

Pour un projet de portfolio, mieux vaut un workflow court et maîtrisé qu’une architecture ambitieuse dont les étapes restent inachevées. Le lecteur doit pouvoir comprendre rapidement le besoin, suivre le flux des données et vérifier le résultat. Un projet Apache Airflow débutant peut se limiter à quelques tâches : récupérer un fichier, contrôler son format, produire une synthèse et enregistrer un résultat daté.

Le périmètre doit permettre de montrer plusieurs notions propres à l’orchestration : les dépendances entre tâches, une planification, le traitement d’une erreur et une reprise contrôlée. Il n’est pas nécessaire de déployer un système complexe ni de prétendre reproduire une plateforme de production. Dites clairement ce que le projet démontre et ce qu’il ne couvre pas.

Avant de choisir le sujet, vérifiez que vous pourrez obtenir des données licites, reproduire l’exécution sur un ordinateur standard et expliquer chaque composant. Pour un premier exercice pratique Apache Airflow, privilégiez un jeu de données réduit, stable et public, ou des données entièrement synthétiques. Évitez les dépendances à des comptes personnels, à des accès internes ou à des services dont les conditions d’utilisation ne sont pas claires.

• Un objectif que l’on peut résumer en une phrase.
• Un nombre limité de sources et de tâches.
• Un résultat mesurable : par exemple, un fichier de synthèse ou un rapport de qualité.
• Une exécution reproductible, avec des instructions accessibles.
• Un niveau de difficulté cohérent avec vos connaissances actuelles de Python, SQL et des données.

Partir d’un besoin concret

Le sujet peut s’inspirer d’une situation rencontrée dans une entreprise : recevoir régulièrement des fichiers, vérifier leur qualité et préparer une synthèse destinée à une équipe. Pour rester indépendant d’un contexte professionnel réel, construisez une démonstration à partir d’un jeu de données public autorisé ou d’un jeu synthétique. Vous pouvez, par exemple, simuler un suivi quotidien d’indicateurs publics : le workflow récupère un fichier, vérifie les colonnes et les valeurs, calcule une synthèse et signale les anomalies.

Le projet doit répondre à une question métier précise. Exemple de brief : « Chaque jour, préparer une synthèse reproductible à partir de données publiques, détecter les fichiers incomplets et conserver une trace des traitements. » Ce brief donne un fil conducteur au DAG sans vous obliger à créer un service en temps réel. Pour un portfolio Apache Airflow, cette clarté compte autant que le choix des outils.

Définissez les critères de réussite avant de coder. Par exemple : le workflow s’exécute avec le jeu de données de démonstration, une colonne obligatoire manquante provoque un échec explicite, une nouvelle exécution ne duplique pas le résultat final et les étapes sont visibles dans l’interface Airflow. Ces critères rendent le projet évaluable par un recruteur ou un client.

• Objectif : automatiser un traitement périodique simple et traçable.
• Entrée : un fichier de démonstration public ou synthétique.
• Traitement : validation, nettoyage élémentaire et calcul d’une synthèse.
• Sortie : un fichier de résultats et un résumé des contrôles réalisés.
• Livrables : code, DAG, tests, documentation, schéma et démonstration sans données sensibles.

Préparer les données, fichiers ou ressources

Commencez par inventorier les ressources nécessaires : environnement Python, version d’Airflow choisie, fichier d’entrée, scripts éventuels, configuration locale et documentation. Relevez les prérequis d’installation dans la documentation officielle de la version utilisée et consignez-les dans le projet. Les dépendances évoluent : indiquez les versions testées plutôt que de laisser le lecteur deviner comment reproduire votre environnement.

Pour les données, vérifiez leur provenance, leur licence, les conditions de réutilisation et la présence éventuelle d’informations personnelles. Un fichier accessible en ligne n’est pas automatiquement libre de réutilisation. Si le jeu réel contient des données protégées, ne le copiez pas dans le dépôt, ne le montrez pas dans des captures d’écran et n’en publiez pas d’extraits. Remplacez-le par des données synthétiques qui conservent la structure nécessaire à la démonstration.

Séparez les paramètres des scripts : chemins de fichiers, identifiants et mots de passe ne doivent pas être inscrits en dur dans le code. Pour le portfolio, fournissez plutôt un exemple de configuration sans secret, accompagné d’instructions pour créer une configuration locale. Vérifiez aussi que les journaux d’exécution ne révèlent ni jeton, ni adresse privée, ni information sensible.

• Un dépôt organisé avec un dossier pour les DAG, un pour le code de traitement et un pour les tests.
• Un petit fichier d’exemple autorisé, ou un script qui génère des données synthétiques.
• Une configuration d’exemple sans identifiants réels.
• Une liste des prérequis et des versions effectivement testées.
• Un fichier d’instructions qui précise les licences et les limites connues des données.

Réaliser le projet par étapes

Un DAG Airflow décrit des tâches et leurs dépendances. Il orchestre leur exécution ; il ne remplace pas nécessairement les scripts de traitement, le stockage ou les outils d’analyse. Gardez les tâches compréhensibles et découpez le travail selon les étapes du besoin. Un DAG trop chargé en logique métier est plus difficile à tester et à expliquer.

Pour rester concret, construisez d’abord la chaîne de traitement avec des fonctions que vous pouvez tester séparément. Reliez ensuite ces opérations dans le DAG et ajoutez les paramètres de planification. Faites une première exécution manuelle sur les données de démonstration avant de vérifier le comportement planifié. Le lecteur doit pouvoir distinguer les étapes, leurs entrées et leurs sorties.

• 1. Décrire le besoin, les entrées, les sorties et les critères de réussite.
• 2. Préparer un jeu de données public autorisé ou synthétique et documenter sa structure.
• 3. Écrire des contrôles simples : présence des colonnes requises, format des dates et valeurs attendues.
• 4. Construire les fonctions de nettoyage et de synthèse en dehors du DAG, puis les tester.
• 5. Créer le DAG avec des tâches distinctes pour la préparation, le contrôle, le traitement et la production du résultat.
• 6. Définir les dépendances et la planification en fonction du cas d’usage, sans créer une fréquence artificiellement élevée.
• 7. Ajouter un comportement explicite en cas d’échec et vérifier comment relancer le traitement sans produire de doublons.
• 8. Exécuter le workflow, examiner son état et ses journaux, puis corriger les erreurs observées.
• 9. Préparer un schéma, des exemples de sortie non sensibles et une démonstration reproductible.

Tester, corriger et documenter

Les tests doivent couvrir autant le résultat que le comportement du workflow. Une exécution réussie avec un seul fichier ne prouve pas que le DAG gère correctement une entrée invalide, un fichier vide ou une relance. Ajoutez des cas de test adaptés à la taille du projet et expliquez ce que chacun vérifie.

Présentez la documentation comme un mode d’emploi pour une personne qui ne vous connaît pas. Elle doit indiquer le problème traité, le fonctionnement général, les prérequis, la façon de lancer les tests et les résultats attendus. Distinguez les faits vérifiés des pistes d’amélioration. Ne donnez pas à une démonstration locale le statut d’un système prêt pour une exploitation réelle.

• Le DAG est-il chargé correctement et ses dépendances correspondent-elles au schéma annoncé ?
• Le cas nominal produit-il le résultat attendu avec les données de démonstration ?
• Un fichier vide, incomplet ou au mauvais format est-il détecté avec une erreur compréhensible ?
• Les fonctions de transformation sont-elles testées indépendamment du DAG ?
• Une nouvelle exécution produit-elle un résultat cohérent, sans doublon involontaire ?
• Les échecs et les reprises sont-ils observables dans les journaux et dans l’interface ?
• La configuration d’exemple est-elle dépourvue de secrets et de données personnelles ?
• Les instructions ont-elles été suivies depuis un environnement propre ?

Présenter son travail dans un portfolio

La page de présentation doit commencer par le problème et le résultat, pas par une longue liste de technologies. Ajoutez un schéma lisible du workflow, un aperçu du DAG et quelques captures d’écran expurgées. Si une capture affiche des chemins privés, des noms de clients, des identifiants ou des données réelles, remplacez-la par une version de démonstration. Vérifiez également que les journaux visibles ne contiennent aucun secret.

Dans votre dépôt, rendez accessibles le code, les tests, les consignes d’installation, un exemple de configuration et la documentation. Décrivez la provenance des données et les limites de leur usage. Un lecteur doit savoir ce qui est public, ce qui est synthétique et ce qui n’est volontairement pas inclus. Ne téléversez pas de fichier confidentiel sous prétexte qu’il facilite la reproduction.

Pour la démonstration, montrez une exécution nominale puis, si possible, un cas d’entrée invalide et la manière dont il est signalé. Expliquez vos choix : pourquoi ces tâches sont séparées, comment le workflow réagit à un échec et ce qui serait nécessaire avant une mise en production. Une présentation honnête des limites inspire davantage confiance qu’une promesse de robustesse non testée.

• Une phrase d’accroche décrivant le besoin et le résultat.
• Un schéma du DAG et des captures expurgées.
• Une courte démonstration reproductible ou des étapes pour la réaliser.
• Des tests et des exemples de sorties non sensibles.
• Une section « limites et améliorations possibles » rédigée sans exagération.
• Aucun secret, donnée client, donnée personnelle ou fichier dont la licence interdit la publication.

Le parcours, étape par étape

1. 1Définir le cas d’usage — Écrivez le besoin, le public visé, les entrées et les sorties. Limitez le périmètre à un workflow démontrable.
2. 2Vérifier les ressources — Choisissez des données autorisées ou synthétiques, contrôlez leur licence et consignez les versions des outils utilisées.
3. 3Construire et tester le traitement — Développez les contrôles et transformations dans des fonctions distinctes, puis testez les cas normaux et les entrées invalides.
4. 4Orchestrer avec Airflow — Créez un DAG lisible, définissez les dépendances, la planification et le comportement en cas d’échec ou de reprise.
5. 5Vérifier la reproductibilité — Suivez les instructions depuis un environnement propre, examinez les journaux et confirmez que les résultats correspondent aux critères de réussite.
6. 6Publier et présenter — Ajoutez code, tests, schéma, documentation et captures expurgées. Expliquez les limites et ne publiez aucune donnée confidentielle.

Formations et programmes au Maroc

Compétences clés

Questions fréquentes

Sources

1. Formation — Ingénierie des pipelines de données avec Apache Airflow, FormaGroup formagroup.ma
2. Technologie Apache Airflow, FormaGroup formagroup.ma
3. JobInTech jobintech.academy
4. Formation intra-entreprise, OFPPT ofppt.ma
5. Documentation officielle Apache Airflow airflow.apache.org