Projet de portfolio MariaDB au Maroc : créer une base de données concrète

Choisir un projet adapté à son niveau

Un projet de portfolio doit permettre de juger votre démarche, pas seulement le nombre de tables ou la longueur d’un script. Pour un projet MariaDB débutant, choisissez un sujet que vous pouvez décrire en quelques phrases, avec des personnes ou objets clairement identifiables et des opérations simples à vérifier. La gestion de réservations d’un espace de coworking convient bien : un client réserve une salle, à une date et pour une durée données, puis la réservation peut être confirmée, annulée ou marquée comme payée.

Gardez un périmètre réduit. Une première version peut comprendre les clients, les espaces, les réservations et les paiements. Évitez au départ les comptes utilisateurs, les notifications, la facturation réglementaire, les paiements réels et les tableaux de bord complexes. Ces éléments peuvent être présentés comme des évolutions possibles, plutôt que comme des fonctions que votre projet prétend déjà assurer.

Choisissez un projet que vous êtes en mesure de construire, mais aussi de démontrer. Vous devriez pouvoir expliquer pourquoi chaque table existe, comment les tables sont reliées, quelles règles évitent des données incohérentes et comment vous avez vérifié les requêtes. Si vous débutez, un petit modèle relationnel bien contraint est plus convaincant qu’une application très ambitieuse dont les données ou les résultats ne sont pas maîtrisés.

Avant de commencer, formulez votre résultat attendu en une phrase : « permettre à un responsable de consulter les réservations d’une période et de repérer les conflits de salle ». Cette phrase sert de filtre. Si une fonctionnalité ne contribue pas à cet objectif, reportez-la.

• Débutant : créer les tables, ajouter des clés primaires et étrangères, insérer des données fictives et écrire des requêtes SELECT.
• Niveau intermédiaire : ajouter des contraintes, des index justifiés, des vues ou des transactions simples, puis comparer les résultats avant et après.
• À faire ressortir dans tous les cas : raisonnement, cohérence des données, tests reproductibles et capacité à expliquer les limites.

Partir d’un besoin concret

Pour transformer l’idée en projet concret MariaDB, partez d’un scénario métier plutôt que d’une liste de fonctions SQL. Dans le cas du coworking, un responsable doit savoir quelles salles sont réservées, par qui, à quel moment et si le paiement est enregistré. Il doit aussi éviter qu’une même salle soit réservée deux fois pour des périodes qui se chevauchent. Le projet montre ainsi comment une base de données peut soutenir une activité quotidienne.

Rédigez un bref cahier des charges avant de créer les tables. Définissez les utilisateurs concernés, les informations nécessaires et les questions auxquelles la base doit répondre. Par exemple : afficher les réservations d’une journée, consulter l’historique d’un client, calculer le nombre de réservations par salle ou signaler les réservations sans paiement enregistré. Distinguez les règles métier des choix techniques : « une réservation doit concerner une salle existante » est une règle de cohérence ; le nom d’une colonne ou le type SQL choisi relève de l’implémentation.

Établissez ensuite les limites du projet. Cette base de démonstration ne traite pas nécessairement les paiements, ne garantit pas à elle seule la disponibilité d’un service en production et ne constitue pas un outil de facturation. Indiquer ces limites dans votre portfolio rend votre présentation plus précise : vous montrez ce que vous avez réalisé, sans faire croire que le prototype est un produit prêt à être déployé.

• Brief de projet — objectif : concevoir une base MariaDB qui enregistre des réservations fictives et permet de consulter l’occupation des salles.
• Périmètre : clients, salles, réservations et paiements simulés ; pas de paiement réel ni de données personnelles véritables.
• Livrables : diagramme ou schéma relationnel, scripts de création et d’insertion, fichier de requêtes de démonstration, checklist de tests et README expliquant l’installation et les limites.
• Critère de réussite : une personne qui découvre le projet peut créer la base, charger les données d’exemple et reproduire les requêtes sans avoir à deviner les étapes.

Préparer les données, fichiers ou ressources

Avant de coder, listez les entités, leurs attributs et leurs relations. Un modèle possible comprend une table clients, une table salles, une table réservations et une table paiements. Une réservation se rattache à un client et à une salle ; un paiement simulé se rattache à une réservation. Déterminez quelles informations sont indispensables à la démonstration, puis évitez d’ajouter des champs simplement parce qu’ils pourraient être utiles un jour.

Préparez un petit jeu de données cohérent et entièrement fictif : quelques clients aux noms inventés, plusieurs salles avec des capacités différentes, des réservations sur différentes dates et plusieurs états de paiement. Incluez aussi des cas qui permettent de tester les règles : réservation annulée, salle encore disponible, paiement absent ou dates qui se chevauchent. Les données de test doivent aider à vérifier les comportements attendus, pas seulement remplir les tables.

Rassemblez les fichiers dans une structure simple : un script de création des tables, un script d’insertion des exemples, un fichier pour les requêtes de démonstration et une documentation de lancement. Si vous choisissez d’utiliser un outil de modélisation, indiquez son rôle, mais assurez-vous que les scripts SQL restent compréhensibles et reproductibles.

N’utilisez pas de fichiers internes d’une entreprise, de listes de clients, d’adresses, de numéros de téléphone ou d’identifiants réels sans autorisation explicite. Pour un portfolio public, le choix le plus sûr est de générer des données synthétiques. Si vous partez d’un jeu de données existant, vérifiez sa licence et ses conditions d’utilisation ; retirez ou transformez les éléments qui pourraient identifier une personne. Ne publiez jamais de mots de passe, de clés d’accès, de sauvegardes de production ou d’informations confidentielles dans vos scripts ou captures.

• Prévoir des noms de tables et de colonnes explicites, cohérents et documentés.
• Choisir des types de données adaptés aux valeurs attendues et définir les clés primaires et étrangères.
• Créer un fichier de données de démonstration séparé du script de structure.
• Vérifier les droits d’utilisation des ressources externes et conserver leur attribution si elle est requise.

Réaliser le projet par étapes

Commencez par écrire les règles de gestion en langage courant. Par exemple : chaque réservation concerne une salle et un client ; son début précède sa fin ; une réservation annulée ne doit pas être comptée comme une occupation active. Certaines règles peuvent être exprimées par des contraintes SQL ; d’autres, comme la détection de chevauchements entre périodes, nécessitent une logique de vérification adaptée. Dans votre documentation, précisez où chaque règle est contrôlée.

Dessinez ensuite le modèle relationnel. Pour chaque table, notez son rôle, sa clé primaire et ses relations. Vérifiez que les informations répétées ne provoquent pas de contradictions : les détails d’une salle doivent appartenir à la table des salles, plutôt que d’être recopiés différemment dans chaque réservation. La modélisation n’a pas besoin d’être sophistiquée, mais elle doit être justifiable.

Créez les tables dans MariaDB, ajoutez les contraintes prévues et insérez vos données fictives. Exécutez les scripts dans un ordre documenté afin qu’une autre personne puisse reproduire l’installation. Utilisez ensuite des requêtes lisibles pour répondre aux questions du brief. Pensez à montrer quelques opérations de lecture, d’ajout ou de mise à jour si elles font partie du périmètre, en gardant les exemples réversibles ou fondés sur les données de démonstration.

Terminez par un scénario de démonstration court : créer la base, charger les exemples, afficher les réservations à venir, repérer une situation à vérifier et présenter le résultat. Une démonstration organisée autour d’un besoin aide le recruteur à comprendre l’utilité du travail et les compétences mobilisées.

• Étape 1 — définir les règles métier, les utilisateurs visés et les questions auxquelles le projet doit répondre.
• Étape 2 — concevoir les tables, les relations, les clés et les contraintes ; consigner les choix importants.
• Étape 3 — écrire les scripts SQL de création, puis insérer un jeu d’essai fictif couvrant les cas ordinaires et les cas limites.
• Étape 4 — préparer les requêtes de consultation et de contrôle correspondant au brief ; expliquer le résultat attendu de chacune.
• Étape 5 — rejouer l’installation depuis une base vide, corriger les erreurs et préparer une démonstration reproductible.

Tester, corriger et documenter

Un exercice pratique MariaDB devient plus crédible lorsque vous montrez comment vous avez vérifié vos résultats. Ne vous contentez pas de constater qu’une requête s’exécute : contrôlez aussi que son résultat correspond au scénario et que les données restent cohérentes après les opérations prévues. Utilisez des cas positifs et négatifs, notamment des identifiants inexistants, des dates invalides ou une réservation qui entre en conflit avec une autre.

La documentation doit permettre à un tiers de comprendre le problème, de reproduire le projet et d’évaluer votre contribution. Présentez le contexte, le périmètre, le modèle, les étapes d’installation, quelques requêtes représentatives et les résultats attendus. Expliquez les choix qui ont un effet sur la cohérence ou les performances, sans prétendre avoir optimisé une base de production si vous n’avez pas réalisé ces mesures.

Contrôlez également ce que vous publiez. Relisez les scripts, les fichiers de configuration, les captures d’écran et l’historique des fichiers que vous partagez. Remplacez les données réelles par des données fictives avant toute publication et masquez les identifiants ou secrets. Si un exemple provient d’une expérience professionnelle, décrivez le problème de façon générale et ne révélez ni le nom du client ni des détails réservés.

• Checklist de tests et de contrôle qualité :
• Les scripts de création s’exécutent depuis une base vide et dans l’ordre indiqué.
• Les clés étrangères empêchent l’ajout d’une réservation liée à un client ou une salle inexistants.
• Les champs obligatoires refusent les valeurs absentes lorsque la règle métier l’exige.
• Les dates de début et de fin sont vérifiées ; les cas limites prévus dans le brief ont été testés.
• Les requêtes de démonstration renvoient des résultats vérifiés sur le jeu d’essai.
• Les mises à jour et suppressions prévues ne laissent pas de données incohérentes.
• Les exemples couvrent les états utiles : réservation confirmée, annulée, à venir ou sans paiement simulé.
• Les erreurs rencontrées et leurs corrections sont notées ; les limites restantes sont indiquées.
• Aucun nom, contact, identifiant, mot de passe ou fichier confidentiel n’est exposé.

Présenter son travail dans un portfolio

Présentez le projet comme une étude de cas courte et structurée. Commencez par le besoin et l’objectif, puis montrez le modèle de données, les scripts disponibles, quelques requêtes et les résultats obtenus. Ajoutez des captures lisibles du schéma ou de la sortie des requêtes, en veillant à ce que toutes les données visibles soient fictives. Une capture seule ne prouve pas que le projet est reproductible : accompagnez-la des fichiers et des consignes nécessaires.

Dans votre description, nommez précisément les tâches que vous avez réalisées : modélisation relationnelle, création de tables, intégrité référentielle, écriture de requêtes et tests. Si vous avez utilisé un outil complémentaire, indiquez-le clairement. Si le projet a été réalisé en groupe, distinguez votre contribution de celle des autres. Une présentation honnête donne au recruteur une base concrète pour vous interroger.

Ajoutez une démonstration brève, par exemple le parcours d’une réservation depuis son insertion jusqu’à son affichage dans une requête de consultation. Terminez par les limites et les améliorations envisageables : gestion de plusieurs fuseaux horaires, contrôles de chevauchements plus avancés, rôles et permissions, ou interface applicative. Présentez-les comme des pistes, non comme des fonctions déjà réalisées.

Enfin, faites relire votre portfolio par une personne qui ne connaît pas le projet. Si elle peut comprendre le besoin, lancer les scripts et retrouver les résultats annoncés, votre présentation est suffisamment claire pour servir de support à une candidature ou à un échange avec un client.

• À montrer : le brief, un schéma lisible, quelques requêtes expliquées, les résultats et la checklist de tests.
• À fournir : scripts SQL organisés, instructions reproductibles et données fictives.
• À préciser : votre contribution personnelle, les choix techniques, les limites et les évolutions possibles.
• À exclure : données personnelles ou confidentielles, secrets d’accès, affirmations de performance non mesurées et fonctions non réalisées.

Le parcours, étape par étape

1. 1Cadrer le besoin — Définissez le scénario de réservation, les utilisateurs concernés, les questions à résoudre et les limites du prototype.
2. 2Modéliser les données — Identifiez les entités, leurs attributs, leurs relations et les règles d’intégrité que vous souhaitez appliquer dans MariaDB.
3. 3Préparer des exemples fictifs — Créez des données de démonstration couvrant les situations normales et les cas limites, sans reprendre de données confidentielles.
4. 4Écrire les scripts SQL — Séparez la création des tables, l’insertion des exemples et les requêtes de démonstration ; indiquez l’ordre d’exécution.
5. 5Tester les règles et les requêtes — Rejouez l’installation depuis une base vide, vérifiez les contraintes et comparez les résultats aux attentes du brief.
6. 6Documenter et présenter — Rédigez un README, ajoutez des captures anonymes, décrivez votre contribution et indiquez clairement les limites du projet.

Formations et programmes au Maroc

Compétences clés

Questions fréquentes

Sources

1. Formation intra-entreprise — OFPPT ofppt.ma
2. JobInTech jobintech.academy
3. Formation MariaDB — FormaGroup formagroup.ma