Créer un projet de portfolio avec Microsoft Visual Studio au Maroc

Choisir un projet adapté à son niveau

Un projet de portfolio Microsoft Visual Studio débutant doit être assez petit pour être terminé, mais assez riche pour illustrer plusieurs compétences. Évitez de commencer par une plateforme complète avec comptes utilisateurs, paiement, notifications et application mobile. Une seule fonctionnalité bien réalisée et expliquée apporte davantage qu’une longue liste de fonctions inachevées.

Définissez d’abord votre niveau et votre objectif. Si vous débutez en C#, réalisez une application en ligne de commande ou une petite application web avec un stockage simple. Si vous connaissez déjà les bases de .NET, ajoutez une interface, une base de données et des tests automatisés. Si vous avez davantage d’expérience, montrez aussi la séparation entre les différentes parties de l’application, la gestion des erreurs et une procédure de lancement reproductible.

Un projet est présentable si une autre personne peut comprendre son utilité, le lancer ou en voir une démonstration, vérifier les principales fonctions et lire une documentation concise. Choisissez un cas assez proche d’une activité professionnelle, sans emprunter les informations d’un employeur ou d’un client. Un outil fictif de suivi de demandes, de réservation de salles ou de gestion de matériel peut faire l’affaire.

Délimitez le résultat avant d’ouvrir l’éditeur. Notez les fonctions indispensables, celles qui seraient utiles mais facultatives, et celles que vous ne ferez pas. Cette dernière liste est importante : elle évite que le projet s’étende sans fin et vous permet de présenter vos limites avec honnêteté.

• Projet réalisable : une personne peut effectuer les principales actions sans explication orale permanente.
• Périmètre clair : quelques fonctions essentielles plutôt qu’une multitude de fonctionnalités incomplètes.
• Valeur démontrable : le projet répond à un besoin et permet de montrer vos décisions techniques.
• Données maîtrisées : des exemples fictifs ou anonymisés remplacent les informations réelles.

Partir d’un besoin concret

Imaginez une petite entreprise qui reçoit des demandes d’intervention pour du matériel partagé : ordinateur, imprimante ou équipement de bureau. Les demandes arrivent de plusieurs façons et il devient difficile de savoir lesquelles sont nouvelles, en cours ou terminées. Votre application doit apporter une réponse simple à ce problème, sans prétendre remplacer un système professionnel complet.

Avant de coder, écrivez le brief ci-dessous et adaptez-le à votre niveau. Il précise le résultat attendu et donne au projet une limite vérifiable.

• Brief de projet — objectif : créer une application permettant d’enregistrer et de suivre des demandes d’intervention fictives.
• Utilisateur visé : une personne qui saisit une demande, puis une personne chargée de la traiter.
• Fonctions indispensables : créer une demande avec un titre, une catégorie, une description et une date ; afficher la liste ; consulter le détail ; modifier le statut parmi « Nouvelle », « En cours » et « Terminée ».
• Règles de base : le titre et la description sont obligatoires ; une demande terminée reste consultable ; les données affichées sont fictives.
• Livrables : code source organisé ; fichier README avec instructions de lancement ; quelques données d’exemple ; tests des règles principales ; captures d’écran ou courte démonstration ; liste honnête des limites et améliorations envisagées.

Préparer les données, fichiers ou ressources

Avant de créer le projet, choisissez une version et un type d’application compatibles avec votre environnement et vos objectifs. Microsoft Visual Studio propose des modèles pour différents types de projets .NET. Un modèle de projet web convient si vous voulez montrer une interface dans un navigateur ; une application en ligne de commande peut être un meilleur premier exercice pour apprendre la logique C# sans ajouter immédiatement la complexité d’une interface.

Préparez vos exemples de données dans un tableau ou un fichier dédié. Vous pouvez inventer des demandes telles que « Imprimante bloquée » ou « Vérifier le poste de réunion ». Ne reprenez ni noms de clients, ni adresses électroniques, ni numéros de téléphone, ni références de tickets provenant d’un contexte réel. Même une capture d’écran peut révéler des informations visibles en arrière-plan.

Réunissez uniquement les ressources nécessaires : description des fonctions, quelques cas d’usage fictifs, éventuelles icônes libres d’utilisation et notes de conception. Vérifiez les conditions d’utilisation des images, polices et bibliothèques que vous ajoutez. Si le projet est inspiré d’une situation rencontrée au travail, transformez suffisamment le scénario et les exemples pour ne pas exposer de méthodes internes ou de données confidentielles.

Créez un dossier de travail propre et, si vous utilisez Git, vérifiez ce qui sera partagé avant chaque publication. Un fichier de configuration peut contenir des mots de passe, des chaînes de connexion ou des clés d’accès : gardez les secrets hors du dépôt public. Utilisez des paramètres fictifs et décrivez, dans la documentation, comment configurer localement les éléments requis.

• À préparer : objectifs, fonctions, règles de validation, données fictives, outils et livrables.
• À exclure : informations personnelles réelles, fichiers internes, secrets techniques et contenus dont vous ne détenez pas les droits.
• Avant de publier : relire le dépôt et les captures, supprimer les secrets et vérifier que les exemples ne permettent pas d’identifier une personne ou une entreprise.

Réaliser le projet par étapes

Dans Microsoft Visual Studio, créez un projet à partir d’un modèle adapté à votre niveau. Donnez-lui un nom explicite, puis lancez immédiatement la version initiale pour vérifier que l’environnement fonctionne. Cette première exécution simple vous aide à repérer tôt les problèmes de configuration.

Avancez par petites étapes. Après chaque ajout, relancez le projet et vérifiez le comportement. Un projet maintenu en état de fonctionnement est plus facile à corriger qu’un grand ensemble de changements ajoutés d’un seul coup.

• 1. Formaliser les usages : décrivez le parcours d’une demande, de sa création à sa clôture. Définissez les champs et les statuts possibles.
• 2. Créer le projet : sélectionnez le modèle .NET voulu, vérifiez qu’il se lance et repérez les fichiers de démarrage et de configuration.
• 3. Construire le modèle : représentez une demande avec des champs adaptés. Donnez des noms explicites et empêchez les valeurs obligatoires d’être vides.
• 4. Ajouter les fonctions : commencez par créer une demande et afficher la liste ; ajoutez ensuite le détail et le changement de statut.
• 5. Choisir le stockage : pour un exercice très simple, commencez par un stockage temporaire ou un fichier local ; si votre niveau le permet, ajoutez une base de données et documentez son initialisation.
• 6. Ajouter des contrôles : refusez les saisies invalides et affichez un message compréhensible plutôt qu’une erreur technique destinée aux développeurs.
• 7. Vérifier dans Visual Studio : lancez l’application, placez des points d’arrêt si nécessaire et utilisez le débogueur pour comprendre le cheminement d’une action.
• 8. Organiser et finaliser : séparez les responsabilités si le projet grandit, exécutez les tests, corrigez les défauts et préparez les fichiers de présentation.

Tester, corriger et documenter

Tester signifie vérifier des cas normaux, mais aussi les erreurs prévisibles. Pour chaque fonction, demandez-vous ce qui se passe avec une saisie vide, une valeur inattendue, une liste sans élément ou une action répétée. Les tests automatisés peuvent contrôler les règles importantes ; les essais manuels restent utiles pour vérifier le parcours complet et la lisibilité de l’interface.

La documentation doit permettre à un tiers de comprendre le projet sans vous demander de lui raconter chaque détail. Dans le README, indiquez le besoin traité, les fonctions disponibles, les outils et versions nécessaires si vous les connaissez, puis les étapes de lancement. Décrivez la façon de charger les données d’exemple et la commande ou procédure de test. N’inscrivez pas de secret ni de valeur réelle dans cette documentation.

Expliquez également ce que le projet ne fait pas. Par exemple, vous pouvez préciser qu’il s’agit d’une démonstration, qu’il n’y a pas de gestion de comptes ou que les données sont locales. Cette précision évite de laisser croire qu’un exercice de portfolio est prêt à être utilisé en production.

• Checklist de tests et de contrôle qualité :
• Le projet démarre depuis une installation ou un dossier propre, en suivant les consignes.
• Une demande valide peut être créée et apparaît dans la liste.
• Les champs obligatoires vides ou invalides sont refusés avec un message compréhensible.
• Le détail affiché correspond à la demande sélectionnée.
• Le statut peut être modifié et reste cohérent après rechargement si le stockage le prévoit.
• Une demande terminée reste consultable et ne disparaît pas sans action prévue.
• Les cas sans demande et les données erronées ne provoquent pas une erreur non expliquée.
• Les tests automatisés disponibles s’exécutent et leur résultat est vérifié.
• Les captures ne montrent aucune donnée sensible ; le dépôt ne contient pas de mot de passe, clé ou fichier confidentiel.

Présenter son travail dans un portfolio

Votre présentation doit commencer par le problème, pas par une liste de technologies. En quelques phrases, expliquez qui utiliserait l’application, quelle difficulté elle traite et ce que vous avez réellement construit. Montrez ensuite un parcours simple : création d’une demande fictive, affichage dans la liste, consultation et changement de statut.

Ajoutez des captures lisibles qui illustrent les principales fonctions. Une courte démonstration peut compléter les images si elle montre le fonctionnement sans exposer d’informations personnelles. Le code source, le README, les tests et les données d’exemple constituent des livrables complémentaires ; choisissez ceux que vous pouvez partager légalement et proprement.

Dans une présentation destinée à un recruteur ou à un client, distinguez clairement votre contribution personnelle des éléments réutilisés. Mentionnez les choix que vous avez faits, les difficultés rencontrées et les améliorations possibles. Ne prétendez pas avoir traité un besoin de production si votre application est un prototype, et ne revendiquez pas une technologie que vous n’avez pas réellement utilisée.

Pour que l’exercice pratique Microsoft Visual Studio témoigne de votre progression, mettez à jour le projet après les retours reçus : corrigez un défaut, clarifiez une instruction ou améliorez un test. La qualité de l’explication compte autant que le nombre de fonctionnalités. Un petit outil terminé, vérifiable et bien documenté donne au lecteur une base concrète pour discuter de vos compétences.

• À montrer : le besoin, le parcours utilisateur, les fonctions réalisées et une démonstration avec des données fictives.
• À fournir : captures utiles, code partageable, README, tests et limites connues.
• À dire honnêtement : ce qui fonctionne, ce qui reste à faire et ce que vous avez personnellement réalisé.
• À protéger : noms, coordonnées, données de clients, documents d’entreprise, secrets et éléments soumis à des droits.

Le parcours, étape par étape

1. 11. Cadrer le besoin — Rédigez le brief, identifiez l’utilisateur et fixez un périmètre limité : créer, consulter et mettre à jour des demandes fictives.
2. 22. Préparer un environnement de travail — Choisissez un modèle de projet adapté dans Microsoft Visual Studio, créez le projet et vérifiez que sa version initiale démarre.
3. 33. Construire une première fonction — Représentez une demande et réalisez sa création et son affichage avant d’ajouter les fonctions complémentaires.
4. 44. Ajouter les règles et le stockage — Validez les champs, gérez les erreurs prévisibles et choisissez un stockage proportionné à votre niveau. Documentez ce choix.
5. 55. Tester et déboguer — Vérifiez les parcours normaux et les saisies invalides, exécutez les tests disponibles et utilisez le débogueur pour corriger les défauts.
6. 66. Documenter et présenter — Préparez un README, des captures ou une démonstration avec des données fictives, puis décrivez clairement les limites du projet.

Formations et programmes au Maroc

Compétences clés

Questions fréquentes

Sources

1. Formation sur mesure Microsoft Visual Studio — FormaGroup formagroup.ma
2. Microsoft Learn learn.microsoft.com
3. JobInTech jobintech.academy
4. Formation intra-entreprise — OFPPT ofppt.ma