Projet Ruby au Maroc : créez un portfolio concret, étape par étape

Choisir un projet adapté à son niveau

Un bon projet Ruby débutant est assez petit pour être terminé, mais assez riche pour faire apparaître votre façon de raisonner. Le lecteur doit pouvoir comprendre le problème, essayer ou examiner le résultat, puis repérer les compétences mobilisées. Il est préférable de livrer une application simple et cohérente plutôt qu’une longue liste de fonctions inachevées.

Avant de choisir votre sujet, évaluez votre niveau réel. Si vous débutez, vous pouvez créer un programme en ligne de commande qui enregistre des éléments, les affiche, les recherche et les modifie. Si vous maîtrisez déjà les conditions, les boucles, les méthodes et les collections, ajoutez la sauvegarde dans un fichier ou une base de données. Si vous connaissez les bases du web, envisagez une application Ruby on Rails avec des pages, des formulaires et une persistance des données.

Gardez un périmètre clair. Une première version pourrait permettre de créer une demande de maintenance, de consulter les demandes et de modifier leur statut. Évitez d’ajouter immédiatement les notifications, les paiements, plusieurs rôles complexes ou une application mobile. Vous pourrez les présenter comme des pistes d’évolution, sans laisser croire qu’elles sont déjà réalisées.

Vérifiez aussi que le sujet vous intéresse et qu’il peut être expliqué sans données d’une entreprise réelle. Un projet inspiré d’une situation courante — organiser des réservations, suivre des tâches ou répertorier du matériel — donne un contexte crédible sans nécessiter l’accès à des informations confidentielles.

• Débutant : un outil en ligne de commande, quelques opérations et des données fictives.
• Niveau intermédiaire : persistance des données, validations et tests automatisés.
• Niveau web : pages et formulaires avec Rails, puis tests des principaux parcours.
• Dans tous les cas : une première version terminable, lisible et montrable.

Partir d’un besoin concret

Pour donner une utilité à votre exercice pratique Ruby, imaginez un petit atelier, une association ou une équipe qui doit suivre des demandes de maintenance. Aujourd’hui, les demandes arrivent par différents canaux et il devient difficile de savoir lesquelles sont nouvelles, en cours ou terminées. Votre application rassemble ces demandes dans une liste consultable.

Le scénario est volontairement générique : il permet de travailler sur une situation professionnelle familière sans prétendre reproduire l’outil d’une organisation particulière. Vous pouvez adapter le vocabulaire à un métier ou à un secteur que vous connaissez au Maroc, tout en gardant des données inventées.

Écrivez un brief d’une dizaine de lignes avant de coder. Il doit préciser qui utilisera l’outil, ce que cette personne cherche à accomplir, les fonctions prévues pour la première version et ce qui ne sera pas traité. Définissez également ce qui permettra de dire que le projet est terminé. Par exemple, un utilisateur doit pouvoir créer une demande avec un titre et une description, retrouver cette demande dans la liste et la faire passer à un statut valide.

Ce brief rend votre portfolio Ruby plus intéressant qu’une simple démonstration de syntaxe : il explique pourquoi vous avez choisi ces fonctions et comment vous avez limité le projet.

• Objectif : centraliser des demandes de maintenance fictives et suivre leur état.
• Utilisateurs visés : une petite équipe qui doit enregistrer et retrouver des demandes.
• Fonctions de la première version : création, affichage, recherche simple et changement de statut.
• Livrables : code source, instructions d’installation, tests, captures d’écran et courte présentation du projet.
• Hors périmètre : comptes réels, données d’entreprise, notifications et intégrations avec des services externes.

Préparer les données, fichiers ou ressources

Avant de commencer, choisissez une méthode de stockage compatible avec votre niveau. Pour un premier exercice, un jeu de données en mémoire peut suffire. Vous pourrez ensuite utiliser un fichier local ou une base de données si l’objectif pédagogique comprend la sauvegarde durable. Avec Rails, les modèles et migrations permettent de structurer les données d’une application web.

Préparez quelques demandes fictives avec un titre, une description courte, un statut et une date créée pour les besoins de la démonstration. Ne reprenez pas des noms de clients, des adresses, des coordonnées, des numéros de dossier ou des descriptions internes. Remplacer seulement le nom d’une personne ne garantit pas toujours l’anonymat si d’autres détails permettent de l’identifier.

Organisez les fichiers avant de multiplier les fonctions : code source, tests, documentation et éventuelles captures d’écran doivent être faciles à retrouver. Si vous utilisez Git, ne placez pas dans le dépôt les mots de passe, clés d’API, fichiers de configuration locaux ou données personnelles. Préparez un fichier d’exemple sûr lorsque le projet a besoin de données pour démarrer.

Notez les outils dont vous avez réellement besoin : Ruby, éventuellement Rails, un éditeur de code, Git et un mécanisme de tests. Vérifiez les versions installées dans votre environnement et consignez les prérequis exacts dans le guide d’installation plutôt que de supposer que le lecteur possède la même configuration.

• Données de démonstration inventées, suffisamment variées pour tester les cas courants.
• Aucun identifiant, secret d’accès, document interne ou donnée personnelle réelle dans le dépôt.
• Un fichier d’exemple réutilisable, distinct de toute configuration privée.
• Une liste précise des prérequis et commandes nécessaires pour lancer le projet.

Réaliser le projet par étapes

Commencez par une version minimale qui répond au besoin principal. Si vous choisissez la ligne de commande, créez un point d’entrée clair, puis séparez les opérations en méthodes compréhensibles : ajouter une demande, afficher la liste et mettre à jour un statut. Utilisez des structures de données adaptées et évitez de tout concentrer dans un long bloc de code.

Ajoutez ensuite les règles métier. Une demande ne devrait pas être enregistrée avec un titre vide, et son statut devrait appartenir à une liste de valeurs prévues. Gérez les entrées inattendues avec des messages utiles plutôt qu’avec une fermeture brutale du programme.

Si vous choisissez Rails, construisez d’abord le modèle de données et les règles de validation, puis les routes, les actions et les vues nécessaires aux parcours retenus. Le principe reste le même : un formulaire permet de créer une demande, la liste permet de la retrouver et une action permet de changer son état. Gardez l’interface sobre et faites en sorte que les erreurs de saisie soient compréhensibles.

Travaillez par petites étapes et vérifiez le résultat après chaque changement important. Enregistrez les versions stables avec Git et donnez à vos changements des messages qui indiquent ce qui a été ajouté ou corrigé. Si un point bloque, réduisez le problème à un cas reproductible et notez ce que vous avez vérifié.

Terminez par le parcours de démonstration : ajouter une demande fictive, la consulter, retrouver un élément et modifier son statut. Cette séquence constitue le fil conducteur de vos tests et de la présentation.

• Étape 1 : créer le squelette du projet et documenter comment le lancer.
• Étape 2 : représenter une demande et afficher des données de démonstration.
• Étape 3 : ajouter la création et vérifier les champs obligatoires.
• Étape 4 : ajouter la consultation, la recherche ou le filtrage prévu au brief.
• Étape 5 : mettre à jour le statut en refusant les valeurs non prévues.
• Étape 6 : écrire les tests, corriger les défauts et préparer une démonstration reproductible.

Tester, corriger et documenter

Les tests montrent que vous ne vous êtes pas contenté de faire fonctionner le cas idéal sur votre ordinateur. Écrivez des tests pour les règles essentielles et les erreurs possibles. Selon le format retenu, vérifiez les méthodes Ruby, les validations du modèle, les actions web ou les parcours principaux. Le but n’est pas de revendiquer une couverture parfaite, mais de rendre visibles les contrôles réellement effectués.

Rejouez les mêmes actions que votre futur lecteur : démarrer le projet, créer une demande, consulter la liste et changer un statut. Testez aussi un titre manquant, une valeur de statut inconnue et une liste vide. Corrigez les résultats surprenants, puis relancez les tests après les modifications.

Dans la documentation, expliquez le problème traité, le contenu de la première version, la façon de lancer le projet, les commandes utiles et la manière d’exécuter les tests. Résumez ensuite vos choix : pourquoi avoir choisi Ruby seul ou Rails, comment les données sont organisées et quelles difficultés vous avez résolues. Un lecteur doit pouvoir comprendre le projet sans vous demander des explications sur chaque fichier.

Restez transparent sur les limites. Si l’application ne comporte pas d’authentification, ne présentez pas les fonctions comme sécurisées pour des utilisateurs réels. Si les données ne sont pas conservées après fermeture, dites-le clairement. La franchise sur le périmètre renforce la crédibilité de la démonstration.

• Checklist de tests et de contrôle qualité :
• Le projet démarre en suivant les instructions écrites.
• Une demande valide peut être créée, affichée et retrouvée.
• Les champs obligatoires vides provoquent un retour compréhensible.
• Les statuts acceptés sont limités aux valeurs prévues.
• Les listes vides et les données inattendues sont traitées sans erreur bloquante.
• Les tests automatisés disponibles s’exécutent et leur résultat est indiqué.
• Les captures, exemples et fichiers publiés ne révèlent aucune donnée confidentielle.
• Les limites connues et les fonctions non réalisées sont clairement signalées.

Présenter son travail dans un portfolio

La présentation doit permettre à un recruteur ou à un client de saisir rapidement le contexte et votre contribution. Commencez par un résumé : le problème choisi, le public visé, la solution réalisée et les principales technologies. Ajoutez ensuite quelques captures montrant les écrans ou, pour une application en ligne de commande, une exécution représentative avec des données fictives.

Accompagnez les captures d’une légende. Expliquez l’action montrée, le résultat attendu et le détail intéressant, par exemple la validation d’un formulaire ou le traitement d’une entrée incorrecte. Si une démonstration est possible, préparez un scénario bref et reproductible, sans dépendre de données privées ou d’un accès qui pourrait expirer.

Mettez le code en valeur par sa structure et sa documentation, pas par sa seule taille. Donnez un accès clair aux instructions de démarrage, aux tests et aux décisions techniques. Vous pouvez ajouter une courte section « Ce que j’améliorerais ensuite » : elle distingue les pistes futures des fonctions réellement livrées.

Avant de partager le projet, vérifiez le dépôt et les images une dernière fois. Retirez les données réelles, secrets, captures d’écrans privées et commentaires internes. Si le projet s’inspire d’une expérience professionnelle, décrivez le type de besoin de façon générale et ne laissez pas entendre que vous avez publié le code ou les informations d’une organisation sans autorisation.

• À montrer : brief, fonctionnalités livrées, captures légendées, tests et instructions d’installation.
• À expliquer : votre contribution personnelle, les principaux choix Ruby et les limites du projet.
• À éviter : les données confidentielles, les affirmations de performance non mesurées et les fonctions annoncées mais absentes.
• À préparer : une démonstration courte qui suit le parcours principal de bout en bout.

Formations et programmes au Maroc

Compétences clés

Questions fréquentes

Sources

1. FormaGroup — technologie Ruby formagroup.ma
2. Ruby — site officiel ruby-lang.org
3. Ruby on Rails — guides officiels guides.rubyonrails.org
4. Formation intra-entreprise — OFPPT ofppt.ma
5. JobInTech jobintech.academy