Projet de portfolio Apache Cassandra au Maroc : une idée concrète à réaliser

Choisir un projet adapté à son niveau

Pour un projet Apache Cassandra débutant, choisissez un périmètre que vous pouvez terminer et expliquer. L’objectif n’est pas de reproduire une infrastructure de production, mais de montrer que vous comprenez comment traduire un besoin de consultation en modèle de données Cassandra. Un sujet métier aide un recruteur ou un client à comprendre l’utilité du travail sans devoir déchiffrer uniquement du code.

Le projet proposé consiste à enregistrer des événements de livraison — colis pris en charge, en transit, livré ou signalé — et à retrouver rapidement l’historique d’un colis. Le scénario est assez concret pour définir des requêtes utiles, tout en restant réalisable avec un petit jeu de données fictives. Vous pouvez ajouter une seconde vue, par exemple l’historique récent d’un livreur, seulement si vous avez le temps de la concevoir et de la tester correctement.

Délimitez le projet avant de coder : une application de démonstration en ligne de commande ou une petite API suffit. Cassandra ne doit pas être présentée comme un choix universel. Dans votre portfolio, expliquez que le projet sert à illustrer une modélisation orientée requêtes et qu’un vrai choix de base dépendrait des besoins, des volumes, des contraintes de disponibilité et des compétences de l’équipe.

Un bon projet de niveau débutant comprend au minimum le lancement de l’environnement, la création du keyspace et des tables, l’insertion de données fictives et l’exécution de quelques requêtes définies à l’avance. Une personne plus avancée peut comparer plusieurs stratégies de clé de partition, tester des volumes contrôlés ou ajouter une API. N’ajoutez pas de fonctionnalité simplement pour allonger le projet : chaque élément doit pouvoir être expliqué.

• Périmètre raisonnable : une famille d’événements, une table principale et quelques requêtes métier.
• Résultat visible : scripts exécutables, exemples de requêtes et sortie lisible.
• Critère de réussite : une autre personne peut démarrer le projet et reproduire les démonstrations à partir du README.

Partir d’un besoin concret

Commencez par formuler le besoin en une phrase : « Une équipe de livraison doit consulter, pour un colis donné, les événements de son parcours dans l’ordre chronologique. » Cette phrase fixe le point de départ sans imposer une architecture. Identifiez ensuite l’utilisateur, l’action attendue et les informations nécessaires à l’écran.

Écrivez les requêtes avant le schéma. Par exemple : retrouver tous les événements d’un colis, dans l’ordre prévu ; consulter les événements d’un colis sur une période ; afficher les derniers événements d’un livreur si cette fonction fait partie du périmètre. Pour chaque requête, précisez ses paramètres et les colonnes à restituer. Cette liste guidera la modélisation et vous évitera de construire une table générique en espérant qu’elle réponde facilement à tous les besoins.

Dans Cassandra, on prévoit souvent des tables adaptées aux requêtes qui doivent être exécutées. Il peut donc y avoir des données répétées entre des tables conçues pour des usages différents. Expliquez cette décision simplement dans votre documentation : ici, la priorité est de répondre aux lectures annoncées, et non d’appliquer une normalisation relationnelle classique. Présentez également les compromis : duplication à maintenir, choix des clés et limites des recherches non prévues au départ.

Pour le projet de portfolio, retenez deux ou trois requêtes essentielles. Une table d’historique par colis peut être organisée autour de l’identifiant du colis et d’un élément temporel ordonnable, avec une clé de partition et des colonnes de clustering choisies pour le type de lecture visé. Ne copiez pas un schéma sans expliquer pourquoi ces champs conviennent à vos requêtes et au volume de démonstration.

• Écrivez les requêtes métier en langage courant, puis transformez-les en requêtes Cassandra.
• Pour chaque table, indiquez quelle requête elle sert et comment ses lignes sont réparties.
• Précisez les questions laissées hors périmètre : recherche libre, tableaux de bord complexes ou exigences de production.

Préparer les données, fichiers ou ressources

Préparez un petit fichier de données synthétiques avant de développer l’application. Utilisez des identifiants inventés et des lieux fictifs, ou des zones génériques, sans coordonnées ou renseignements permettant d’identifier une personne. Chaque événement peut comporter un identifiant de colis fictif, une date et heure, un type d’événement, une zone approximative et une note de démonstration. Gardez les valeurs cohérentes : un colis ne peut pas être livré avant sa prise en charge.

N’utilisez pas d’export de votre employeur, de données de clients, de noms, de numéros de téléphone, d’adresses privées ou de données récupérées sans autorisation. Même un jeu de données qui semble anonyme peut contenir des détails sensibles. Pour un portfolio public, privilégiez des données entièrement générées pour le projet et indiquez-le explicitement.

Réunissez les ressources de travail : une installation ou un environnement local Cassandra compatible avec votre configuration, un client de requêtes, les scripts CQL, un générateur ou fichier de données, et éventuellement un langage d’application que vous connaissez déjà. Notez les versions réellement utilisées et les étapes de lancement. Évitez de rendre le projet dépendant d’un service payant ou d’un compte externe si une démonstration locale suffit.

Séparez les fichiers de configuration des secrets. Ne publiez ni mot de passe, ni jeton, ni chaîne de connexion privée. Si vous utilisez un fichier d’environnement, ajoutez un exemple sans secret et excluez le fichier réel du dépôt. Un portfolio destiné à un recruteur doit être partageable sans divulguer les paramètres de votre machine ou de votre organisation.

• À réunir : liste des requêtes, schéma initial, scripts de création et jeu d’essai fictif.
• À contrôler : cohérence chronologique des événements et présence de valeurs manquantes prévues.
• À protéger : données personnelles, informations commerciales, identifiants et secrets techniques.

Réaliser le projet par étapes

Avancez dans un ordre reproductible. Commencez par écrire le brief et les requêtes attendues, puis dessinez les tables. Avant de développer une interface, vérifiez que Cassandra permet d’exécuter les lectures du périmètre avec les clés prévues. Pour un projet débutant, une démonstration en CQL peut constituer un premier résultat complet.

Créez ensuite l’environnement et les scripts d’initialisation. Définissez le keyspace selon l’environnement de démonstration, puis les tables nécessaires. Choisissez les types des colonnes en fonction de leur usage. Expliquez le rôle de la clé de partition et des colonnes de clustering ; évitez de présenter leur choix comme optimal pour tous les cas.

Insérez un jeu de données réduit, puis exécutez chaque requête prévue. Si vous ajoutez une API ou une interface, gardez-la simple : un endpoint ou un écran peut afficher l’historique d’un colis avec les filtres réellement pris en charge. Ne masquez pas les erreurs de base de données ; prévoyez des réponses compréhensibles lorsqu’un identifiant n’existe pas ou que les paramètres sont invalides.

Enfin, rendez le lancement reproductible. Ajoutez les commandes nécessaires, les prérequis et un exemple de résultat. Si vous utilisez une configuration multi-nœuds pour illustrer la distribution, documentez précisément ce qui a été lancé et ce qui a été observé. Ne confondez pas une démonstration locale avec une validation de haute disponibilité en production.

• Brief et requêtes : définir le besoin, les acteurs et les lectures à servir.
• Modèle : créer une table par usage nécessaire, puis justifier les clés retenues.
• Implémentation : automatiser création, chargement des données et exécution des requêtes.
• Démonstration : fournir un parcours court montrant les entrées, la requête et le résultat.
• Reproductibilité : vérifier que les instructions fonctionnent depuis un environnement propre.

Tester, corriger et documenter

La qualité du projet se voit aussi dans les contrôles réalisés. Testez le cas nominal, un colis inconnu, des événements ayant la même valeur temporelle si votre modèle peut les rencontrer, des paramètres invalides et un jeu de données vide. Vérifiez que l’ordre affiché correspond bien à la convention retenue. Si vous avez créé plusieurs tables pour des lectures différentes, testez chacune séparément.

Ajoutez une checklist au dépôt et cochez uniquement les contrôles réellement exécutés. Pour les performances, indiquez le contexte du test : environnement, quantité de données, requêtes et méthode de mesure. Un résultat obtenu sur un petit ordinateur ou un jeu d’essai ne permet pas de promettre une capacité de production. Il vaut mieux documenter une limite connue que transformer une observation ponctuelle en garantie.

Le README doit permettre à une personne extérieure de comprendre le projet rapidement : problème traité, périmètre, schéma simplifié, requêtes principales, prérequis, étapes de lancement, jeu de démonstration et résultat attendu. Ajoutez une courte section « choix et limites » qui explique pourquoi vous avez organisé les tables de cette façon, ce que vous n’avez pas testé et quelles évolutions seraient envisageables.

Avant de publier, recherchez les données personnelles et les secrets dans le code, les fichiers de configuration, les captures et l’historique du dépôt. Remplacez les exemples réels par des valeurs fictives. Si un projet a été réalisé pour une entreprise, obtenez l’autorisation nécessaire avant de présenter son nom, son architecture, ses écrans ou ses chiffres ; à défaut, créez une version indépendante avec des données synthétiques.

• Checklist de tests et de contrôle qualité :
• Le projet démarre en suivant les instructions du README.
• Les scripts créent le keyspace et les tables sans étape cachée.
• Le chargement des données peut être relancé sans produire de résultats incohérents.
• Chaque requête du brief a un exemple d’exécution et un résultat vérifié.
• Les cas absent, vide et invalide sont traités ou explicitement documentés.
• Les dates, l’ordre des événements et les types de colonnes sont cohérents.
• Aucun secret ou renseignement confidentiel n’apparaît dans le dépôt ou les captures.
• Les limites de l’environnement et les tests non réalisés sont annoncés honnêtement.

Présenter son travail dans un portfolio

Présentez le projet comme une étude de cas courte. Commencez par le besoin, poursuivez avec les requêtes et le modèle, puis montrez une démonstration du résultat. Quelques captures lisibles du schéma, de l’exécution d’une requête et de l’application suffisent. Recadrez-les pour qu’aucun nom de compte, chemin privé, secret ou donnée confidentielle ne soit visible.

Joignez les livrables utiles : README, scripts CQL, données synthétiques, code de démonstration et checklist. Une courte vidéo ou une démonstration en direct peut compléter le dépôt, mais elle ne remplace pas les instructions écrites. Dans votre présentation, distinguez ce que vous avez construit, ce que vous avez testé et ce que vous envisagez seulement comme amélioration.

Si vous avez travaillé en équipe, indiquez précisément votre contribution : conception des tables, préparation des données, tests, API ou documentation. Si le travail vient d’une formation, mentionnez le contexte sans suggérer qu’il s’agit d’un système déployé en entreprise. Un recruteur peut vous demander de justifier une clé de partition ou une décision de modèle : préparez une réponse concrète à partir de vos requêtes et des limites observées.

Pour progresser avant de réaliser ce projet, une formation peut vous aider à structurer les bases et à obtenir un retour sur votre modèle. Au Maroc, comparez le contenu, les travaux pratiques, le format et l’accompagnement proposés, puis choisissez une suite adaptée à votre niveau. Les ressources officielles d’Apache Cassandra peuvent compléter l’exercice pour vérifier les notions et approfondir la documentation.

• Dans le résumé du portfolio : besoin, rôle personnel, technologie, résultat et limite principale.
• Dans la démonstration : une requête métier, son exécution et le résultat obtenu.
• Dans le dépôt : instructions reproductibles, schéma, exemples fictifs et tests.
• À ne pas revendiquer : une disponibilité, une performance ou une capacité non mesurée.

Le parcours, étape par étape

1. 11. Définir le brief — Choisissez le suivi d’événements de livraison et formulez le besoin en une phrase. Fixez un périmètre court, un utilisateur cible et deux ou trois requêtes à démontrer.
2. 22. Écrire les requêtes avant les tables — Décrivez les lectures attendues, leurs paramètres et leur résultat. Associez chaque table à un usage précis et notez les recherches qui ne seront pas prises en charge.
3. 33. Préparer les données fictives — Générez des colis, dates, types d’événements et zones de démonstration inventés. Vérifiez leur cohérence et excluez toute donnée réelle ou confidentielle.
4. 44. Construire le modèle Cassandra — Créez keyspace et tables, puis justifiez la clé de partition et les colonnes de clustering au regard des requêtes. Expliquez les compromis et les limites du modèle.
5. 55. Implémenter et démontrer — Automatisez l’initialisation et le chargement. Exécutez les requêtes en CQL ; ajoutez une API ou une interface seulement si elle sert la démonstration.
6. 66. Tester et publier — Suivez la checklist, corrigez les incohérences, documentez les conditions de test et les limites. Vérifiez les fichiers et captures avant de publier le dépôt.

Formations et programmes au Maroc

Compétences clés

Questions fréquentes

Sources

1. FormaGroup — Apache Cassandra formagroup.ma
2. Apache Cassandra — site officiel cassandra.apache.org
3. JobInTech jobintech.academy
4. Formation intra-entreprise — OFPPT ofppt.ma