Portfolio GraphQL au Maroc : créez un projet concret étape par étape

Choisir un projet adapté à son niveau

GraphQL est un langage de requête pour API : un client peut demander les champs dont il a besoin, et le serveur les résout à partir des sources de données prévues. Pour le portfolio, cette souplesse est intéressante si elle répond à un vrai besoin. Elle ne justifie pas, à elle seule, de choisir GraphQL plutôt qu’une autre approche.

Le projet doit pouvoir être terminé et expliqué. Pour un premier exercice pratique GraphQL, privilégiez une application web modeste, avec un modèle de données compréhensible et un seul scénario principal. Par exemple, créez un catalogue fictif de formations où l’on peut consulter les cours, filtrer par thème et afficher les séances associées. Vous pourrez ensuite ajouter une fonction de gestion des inscriptions simulées.

Choisissez un périmètre compatible avec vos acquis. Si vous débutez en développement web, concentrez-vous sur le schéma, quelques requêtes et une interface simple. Si vous connaissez déjà un langage serveur et une base de données, ajoutez des mutations, la validation des entrées et des tests de permissions. Si vous êtes plus avancé, montrez la pagination, la gestion des erreurs et le contrôle des requêtes coûteuses.

Évitez de multiplier les technologies uniquement pour étoffer le portfolio. Une architecture claire, un cas d’usage terminé et une documentation honnête sont plus parlants qu’une longue liste d’outils peu maîtrisés.

• Vérifiez que vous pouvez expliquer le besoin en deux ou trois phrases.
• Définissez une première version qui tient dans un dépôt et une démonstration courte.
• Retenez des fonctions que vous pouvez tester, pas seulement montrer en capture d’écran.
• Annoncez le niveau de finition : prototype, projet d’apprentissage ou application déployée.

Partir d’un besoin concret

Un projet concret GraphQL peut reproduire un besoin courant sans prétendre représenter les données d’une entreprise réelle. Le catalogue fictif de formations constitue un bon brief : une personne cherche une formation par sujet, consulte son programme et compare les séances proposées.

Vous pouvez aussi adapter le même principe à un catalogue de livres, un inventaire d’équipements fictif ou un répertoire d’événements publics. Choisissez un sujet qui vous intéresse et pour lequel vous pouvez créer ou trouver des données réutilisables. Les exemples marocains sont souvent plus parlants pour le public visé, mais ne reprenez pas pour autant les fichiers internes d’une école, d’une association ou d’une entreprise.

• Brief de projet : construire une API GraphQL pour consulter un catalogue fictif de formations et les séances proposées.
• Objectif : permettre à un utilisateur de trouver une formation par mot-clé ou par catégorie, puis de consulter ses informations principales et ses séances.
• Livrables : schéma GraphQL, serveur exécutable, jeu de données fictif, exemples de requêtes, tests automatisés, documentation et courte démonstration.
• Hors périmètre initial : paiement réel, comptes d’utilisateurs, données personnelles et système de réservation opérationnel.

Préparer les données, fichiers ou ressources

Avant de coder, dessinez les relations entre vos données. Pour l’exemple, une formation possède un identifiant, un titre, une description et une catégorie. Elle peut être associée à plusieurs séances, chacune avec un format et une date fictive. Les dates doivent être présentées comme des exemples, non comme des sessions réellement proposées.

Préparez un petit jeu de données synthétique, suffisamment varié pour tester les recherches et les cas limites. Ajoutez notamment une formation sans séance, une catégorie peu renseignée et des titres proches. Un jeu modeste permet de vérifier le fonctionnement sans confondre volume de données et qualité du projet.

Si vous partez de données publiques, vérifiez leur provenance, leurs conditions de réutilisation et la manière dont elles peuvent être redistribuées. Une donnée visible sur un site n’est pas automatiquement libre de copie. Pour les images, utilisez des ressources que vous avez créées ou dont la licence autorise l’usage envisagé, et conservez l’attribution requise.

Ne copiez pas de données de clients, collègues, apprenants ou utilisateurs. Retirez aussi du dépôt les mots de passe, jetons, clés d’API, fichiers de configuration contenant des secrets, journaux d’activité et extraits de bases internes. Pour la démonstration, les données fictives sont généralement suffisantes.

• Rédigez un petit dictionnaire des champs et de leur sens.
• Choisissez le format de stockage et notez comment réinitialiser les données de démonstration.
• Conservez les fichiers de configuration secrets hors du dépôt public.
• Vérifiez les licences et les autorisations avant de reprendre des données ou des médias.

Réaliser le projet par étapes

Commencez par décrire le parcours de l’utilisateur : il ouvre le catalogue, recherche un thème, consulte une formation, puis affiche les séances disponibles. À chaque étape, demandez-vous quelles données sont nécessaires. Cette réflexion aide à concevoir des types utiles plutôt qu’un schéma calqué sans examen sur les tables de stockage.

Définissez les types principaux et leurs liens, par exemple Formation, Catégorie et Séance. Prévoyez les champs qu’un client peut interroger et rendez explicites les champs obligatoires ou facultatifs. Les noms du schéma doivent être cohérents et compréhensibles pour une personne qui découvre le projet.

Créez ensuite les requêtes de lecture : lister les formations, récupérer une formation par identifiant et filtrer le catalogue. Ajoutez les résolveurs nécessaires pour alimenter ces champs depuis votre jeu de données. Vérifiez qu’une requête ne renvoie pas plus d’informations que le scénario ne le demande.

Si le périmètre le permet, ajoutez une mutation simple, par exemple créer une demande d’intérêt fictive. Validez les entrées et expliquez les règles de cette action. Pour un portfolio débutant, vous pouvez aussi laisser les écritures hors périmètre et justifier ce choix : mieux vaut une lecture bien conçue qu’une mutation incomplète.

Enfin, reliez l’API à une petite interface ou préparez une démonstration reproductible. Montrez une requête qui récupère exactement les champs nécessaires, puis une variante de recherche. Le dépôt doit permettre à une autre personne de lancer le projet sans deviner les étapes.

• 1. Écrire le scénario utilisateur et fixer le périmètre de la première version.
• 2. Définir les types GraphQL, les relations et les champs accessibles.
• 3. Construire les requêtes de lecture et leurs résolveurs.
• 4. Ajouter les filtres et, si cela sert le brief, une mutation avec validation.
• 5. Connecter une interface simple ou préparer des requêtes de démonstration.
• 6. Automatiser les tests, documenter le lancement et faire vérifier le projet par une autre personne.

Tester, corriger et documenter

Les tests doivent couvrir à la fois le résultat attendu et les erreurs. Une API qui répond correctement au scénario idéal peut encore mal gérer un identifiant inconnu, une entrée invalide ou un champ auquel l’utilisateur ne devrait pas accéder. La vérification du contrôle d’accès est particulièrement importante dès que le projet comporte des rôles ou des données privées simulées.

Documentez les choix qui ne sont pas visibles dans une capture : pourquoi certains champs sont obligatoires, comment fonctionnent les filtres, quelles erreurs peuvent apparaître et quelles limites restent à traiter. Indiquez aussi les prérequis, la commande de lancement, la façon de charger les données fictives et quelques requêtes prêtes à essayer.

Vous pouvez vous appuyer sur la documentation officielle de GraphQL pour vérifier les concepts et la syntaxe. Si vous suivez un parcours d’apprentissage en ligne, retenez les exercices qui vous aident à compléter votre propre projet et indiquez clairement ce qui a été réalisé par vous.

• Checklist de tests et de contrôle qualité :
• Le serveur démarre avec les instructions indiquées dans le dépôt.
• Une requête de liste et une requête par identifiant renvoient les champs attendus.
• Les filtres fonctionnent avec des résultats présents et sans résultat.
• Un identifiant inexistant et une entrée invalide produisent un résultat compréhensible.
• Les champs liés, comme les séances d’une formation, sont résolus correctement.
• Les mutations, si elles existent, rejettent les données invalides et respectent les règles prévues.
• Aucun secret, donnée personnelle réelle ou fichier appartenant à un tiers n’est présent dans le dépôt.
• La documentation correspond à l’état réel du projet et la démonstration est reproductible.

Présenter son travail dans un portfolio

Présentez le projet comme une étude de cas courte. Commencez par le besoin, précisez le public visé et délimitez ce que l’application fait. Ajoutez ensuite une vue d’ensemble du schéma, un exemple de requête et une capture de l’interface ou de l’outil utilisé pour interroger l’API.

Un dépôt soigné inclut un fichier d’accueil lisible, les étapes de lancement, les technologies réellement utilisées, les tests disponibles et les limites connues. Si l’application est déployée, expliquez quelles données sont fictives. Si elle ne l’est pas, une démonstration locale claire reste utile. Ne présentez pas un prototype comme un service prêt pour une utilisation en production.

Dans votre commentaire de portfolio ou lors d’un entretien, expliquez un choix concret : pourquoi le schéma contient tel type, comment vous avez traité une recherche ou quel contrôle vous avez ajouté. Cette explication montre votre démarche et aide un recruteur ou un client à distinguer votre travail des éléments repris d’un tutoriel.

Pour préserver la confidentialité, remplacez les noms et les informations réels par des exemples inventés. Vérifiez aussi les captures d’écran, les messages d’erreur, l’historique du dépôt et les métadonnées : des informations sensibles peuvent s’y glisser même si elles ne figurent pas dans le code principal.

• Montrez une capture ou une courte démonstration centrée sur le scénario principal.
• Fournissez des exemples de requêtes et de réponses avec des données fictives.
• Décrivez votre contribution personnelle et les ressources externes utilisées.
• Distinguez les fonctions terminées, celles qui sont simulées et les pistes d’amélioration.

Le parcours, étape par étape

1. 1Cadrer le besoin — Rédigez le brief du catalogue fictif, nommez son utilisateur et limitez la première version à la recherche et à la consultation des formations.
2. 2Préparer le modèle de données — Définissez les types Formation, Catégorie et Séance, leurs relations, les champs requis et un jeu de données synthétique.
3. 3Construire le schéma et les lectures — Écrivez le schéma GraphQL, puis implémentez les requêtes de liste, de recherche et de consultation par identifiant.
4. 4Ajouter les fonctions nécessaires — Mettez en place des filtres et, si le brief le justifie, une mutation simple avec validation des entrées.
5. 5Tester les cas importants — Vérifiez les résultats attendus, les erreurs, les identifiants inconnus, les données liées et les règles d’accès.
6. 6Documenter et présenter — Rendez le lancement reproductible, fournissez des requêtes d’exemple et préparez une démonstration fondée uniquement sur des données autorisées.

Formations et programmes au Maroc

Compétences clés

Questions fréquentes

Sources

1. GraphQL — site officiel graphql.org
2. JobInTech jobintech.academy
3. Formation intra-entreprise — OFPPT ofppt.ma
4. Formation GraphQL — FormaGroup formagroup.ma