Portfolio Java et Spring Boot au Maroc : créez une API de gestion de tâches

Choisir un projet adapté à son niveau

Le meilleur projet de portfolio n’est pas nécessairement le plus vaste. Il doit pouvoir être expliqué en quelques minutes, couvrir plusieurs compétences utiles et rester réalisable avec le temps et le matériel dont vous disposez. Pour un projet Java et Spring Boot débutant, commencez par une seule API et un seul domaine métier : des demandes d’intervention dans un immeuble, une petite entreprise ou une association.

Le projet peut répondre à un scénario simple : un utilisateur signale une panne, une personne responsable consulte les demandes et fait évoluer leur statut. Cette histoire donne un fil conducteur aux choix techniques. Elle permet aussi de démontrer le fonctionnement de l’application au lieu d’aligner des classes sans expliquer à quoi elles servent.

Limitez la première version à trois fonctions : enregistrer une demande, afficher une demande ou une liste, puis changer son statut. Les filtres par priorité ou par statut peuvent venir ensuite. Une interface web complète, des notifications, une application mobile ou une architecture en microservices ne sont pas nécessaires pour prouver que vous savez structurer une API.

Spring propose un guide officiel de création d’un service REST et indique les prérequis techniques de son exemple. Vous pouvez vous en inspirer pour démarrer, tout en construisant un domaine métier différent et en écrivant votre propre explication du projet.

• Pour débuter : API en mémoire ou avec une base embarquée, puis tests des opérations principales.
• Pour un niveau intermédiaire : persistance relationnelle, pagination ou filtres, validation et gestion claire des erreurs.
• Pour approfondir : authentification, rôles, conteneurisation ou déploiement, après validation du besoin de base.

Partir d’un besoin concret

Avant de créer le projet dans votre environnement de développement, rédigez un brief court. Il rend votre exercice pratique Java et Spring Boot lisible pour une autre personne et vous aide à éviter les fonctionnalités ajoutées sans raison.

**Brief de projet — Suivi des demandes d’intervention.** Objectif : permettre à une petite organisation de centraliser des signalements fictifs, de les consulter et de suivre leur traitement. Utilisateurs envisagés : une personne qui signale un problème et une personne qui le prend en charge. Fonction principale : enregistrer une demande avec un titre, une description, une catégorie, une priorité et un statut. Règle métier : le statut doit appartenir à une liste définie, par exemple « nouvelle », « en cours » ou « clôturée ».

Le périmètre minimum comprend la création d’une demande, sa consultation par identifiant, la liste des demandes et la mise à jour de son statut. Une recherche par statut ou une pagination constitue une amélioration facultative. Écrivez aussi ce que le projet ne fait pas : il ne gère pas de vraies interventions, ne promet pas de notifications et ne traite pas de dossiers de clients réels.

Les livrables attendus sont le dépôt de code, un fichier README avec les étapes de lancement, des exemples de requêtes et de réponses, les tests automatisés, une description des principales décisions techniques et quelques captures d’écran de la démonstration. Si vous ajoutez une interface de test, dites clairement si elle est intégrée au projet ou fournie séparément.

• Question métier : qui crée une demande et qui peut modifier son statut ?
• Critère de réussite : une demande valide est enregistrée puis retrouvée par son identifiant.
• Cas à traiter : identifiant inexistant, champ obligatoire manquant et statut non reconnu.
• Hors périmètre initial : données de vrais employés, paiements, géolocalisation précise et intégration à un système d’entreprise.

Préparer les données, fichiers ou ressources

Commencez par un petit modèle de données, décrit avec des mots avant d’être codé. Une demande peut contenir un identifiant, un titre, une description, une catégorie, une priorité, un statut et des dates de création et de mise à jour. Évitez de recueillir des informations personnelles qui ne sont pas nécessaires à la démonstration.

Préparez une dizaine d’exemples inventés : « éclairage en panne », « poignée à réparer » ou « matériel à vérifier ». Utilisez des noms de lieux fictifs, et non des adresses précises. Vous pouvez aussi rédiger un jeu de données à la main. Si vous choisissez un jeu de données trouvé en ligne, vérifiez ses conditions de réutilisation et indiquez sa provenance dans le README.

Pour l’API, préparez une liste d’opérations cohérente, par exemple créer une demande, lister les demandes, consulter une demande et modifier son statut. Le guide Spring consacré aux services REST présente l’approche contrôleur et une réponse JSON ; c’est une référence pour comprendre le mécanisme, pas un modèle à recopier sans l’adapter.

Spring Boot documente l’accès aux bases SQL et l’usage de Spring Data JPA. Pour garder l’exercice abordable, commencez avec une base adaptée au développement local, puis expliquez dans la documentation comment la configuration pourrait changer pour une autre base. Ne publiez jamais de mot de passe, jeton, fichier de configuration contenant des secrets ou export de données réelles.

• À préparer : description du besoin, règles de statut, exemples fictifs, liste des routes et scénarios de test.
• À exclure du dépôt public : données de clients, documents internes, identifiants, clés d’API, mots de passe et captures contenant des informations privées.
• À vérifier : droits de réutilisation des images, jeux de données, bibliothèques et contenus intégrés.

Réaliser le projet par étapes

Créez d’abord le projet avec un gestionnaire de dépendances et un JDK compatibles avec la version de Spring Boot choisie. La page officielle Java d’Oracle présente les versions disponibles ; dans un projet public, précisez la version effectivement utilisée plutôt que d’écrire « dernière version » sans date. Un guide Spring peut également vous aider à initialiser une application avec Spring Initializr.

Organisez ensuite le code en responsabilités compréhensibles. Le contrôleur reçoit les requêtes HTTP et formule les réponses ; la couche de service porte les règles métier ; le dépôt s’occupe de l’accès aux données ; les objets de transfert servent à définir ce que l’API accepte et renvoie. Le découpage peut rester simple : l’objectif est de faciliter la lecture et les tests, pas de multiplier les couches inutilement.

Définissez le modèle de demande et les valeurs autorisées pour le statut et la priorité. Implémentez une première route, testez-la, puis ajoutez les autres une par une. Une réponse adaptée en cas d’identifiant inconnu et des erreurs de validation explicites rendent la démonstration plus crédible qu’une API qui ne fonctionne que pour les saisies idéales.

Ajoutez la persistance lorsque les opérations de base sont stables. Avec Spring Data JPA, les dépôts permettent de structurer l’accès aux données relationnelles. Gardez les paramètres de connexion hors du dépôt public et séparez les paramètres locaux de ceux utilisés pour une éventuelle démonstration hébergée.

Enfin, documentez les opérations. Une description OpenAPI permet de présenter les routes, paramètres et réponses d’une API de manière lisible par des personnes et des outils. Commencez par expliquer ce que fait chaque opération et fournissez des exemples fictifs.

• Étape 1 — Initialiser le projet, vérifier le lancement et consigner les versions utilisées.
• Étape 2 — Écrire le modèle métier et les règles de validation.
• Étape 3 — Construire les routes de création et de consultation ; vérifier les réponses JSON.
• Étape 4 — Ajouter la modification du statut et les cas d’erreur.
• Étape 5 — Ajouter la persistance, puis une recherche ou une pagination si elles servent le besoin.
• Étape 6 — Écrire les tests, documenter l’API et préparer une démonstration reproductible.

Tester, corriger et documenter

Un portfolio Java et Spring Boot convaincant ne se limite pas à un dépôt qui compile sur votre ordinateur. Il doit permettre à une autre personne de comprendre comment lancer le projet, ce qui a été vérifié et ce qui reste à faire. Spring Boot fournit des outils et des annotations dédiés aux tests ; sa documentation distingue notamment les tests du code et ceux qui démarrent le contexte de l’application.

Testez les règles métier indépendamment des requêtes HTTP, puis vérifiez au moins quelques échanges complets avec l’application. Pour chaque route, indiquez une entrée valide, le résultat attendu et un cas d’erreur. Rejouez les tests après chaque changement important et assurez-vous que le README correspond à la version réellement publiée.

Expliquez les choix sans prétendre que le projet est prêt pour un usage réel si ce n’est pas le cas. Par exemple, vous pouvez écrire que l’application utilise des données fictives, que l’authentification n’est pas incluse et que le déploiement n’a pas été éprouvé dans un contexte de production. Une limite bien formulée montre que vous savez distinguer une démonstration d’un système opérationnel.

• Checklist de tests et de contrôle qualité :
• □ L’application démarre à partir des instructions du README.
• □ La création d’une demande valide renvoie une réponse compréhensible.
• □ Les champs obligatoires manquants sont refusés avec une erreur lisible.
• □ Une demande existante peut être consultée par identifiant.
• □ Un identifiant inconnu produit une réponse d’erreur cohérente.
• □ Seuls les statuts prévus sont acceptés.
• □ La mise à jour ne modifie pas des champs non concernés.
• □ Les tests automatisés s’exécutent et leur résultat est indiqué.
• □ Aucun secret ou jeu de données confidentiel n’est présent dans les fichiers publiés.

Présenter son travail dans un portfolio

Présentez le projet en commençant par le problème, puis montrez le parcours d’une demande : création, consultation et changement de statut. Une capture d’écran de la documentation ou une courte démonstration peut compléter le code, mais ne remplace pas des instructions de lancement reproductibles.

Dans le README, placez en premier une description en quelques phrases, les fonctionnalités réellement terminées, la stack et les prérequis. Ajoutez ensuite les commandes de lancement, la configuration attendue, les exemples de requêtes, la procédure de test et les limites connues. Si le projet comporte une interface, montrez aussi l’état vide, un résultat valide et un message d’erreur utile.

Ne montrez pas un écran d’entreprise, un fichier client ou un dépôt professionnel sans autorisation explicite. Utilisez des captures nettoyées et des données fictives. Si vous vous inspirez d’un besoin rencontré en stage ou en emploi, reformulez-le de façon générique et retirez les noms, chiffres, règles internes et détails permettant d’identifier l’organisation.

Pour un entretien ou une proposition de mission, préparez une présentation courte : le besoin choisi, une décision technique, un problème rencontré, la manière dont vous l’avez testé et une amélioration envisagée. Distinguez ce que vous avez fait vous-même de ce qui provient d’un tutoriel ou d’une bibliothèque, et ne revendiquez pas des fonctionnalités absentes du dépôt.

• À montrer : dépôt lisible, README, routes principales, tests et exemples fictifs.
• À expliquer : choix de conception, erreurs traitées, limites et prochaine amélioration.
• À éviter : captures contenant des données privées, promesses de disponibilité ou de sécurité non vérifiées, et fonctionnalités présentées comme terminées alors qu’elles sont simulées.

Formations et programmes au Maroc

Compétences clés

Questions fréquentes

Sources

1. Building a RESTful Web Service — Spring spring.io
2. Testing — Spring Boot Reference Documentation docs.spring.io
3. SQL Databases — Spring Boot Reference Documentation docs.spring.io
4. OpenAPI Specification & Swagger Tools swagger.io
5. Java Downloads oracle.com
6. Java Spring Boot et API — FormaGroup formagroup.ma
7. Technologie Java — FormaGroup formagroup.ma