Projet de portfolio Model Context Protocol (MCP) : une idée concrète au Maroc

Choisir un projet adapté à son niveau

Un bon projet de portfolio Model Context Protocol (MCP) débutant ne se mesure pas au nombre de fonctions. Il doit plutôt permettre à une personne extérieure de comprendre rapidement le problème, le rôle du serveur MCP et la manière dont l’application d’IA utilise les ressources ou les outils proposés. Un périmètre réduit facilite aussi les tests et évite de présenter comme achevé un système difficile à maintenir.

Une idée accessible consiste à créer un assistant qui recherche des réponses dans un petit ensemble de documents de démonstration. Par exemple, l’utilisateur demande où se trouve une consigne dans un guide fictif, et l’assistant peut consulter les ressources exposées par un serveur MCP. Le projet peut commencer en lecture seule : cette limite réduit les risques et rend le comportement plus simple à expliquer.

Avant de coder, vérifiez que le projet tient dans quelques livrables lisibles : une démonstration courte, un dépôt avec des données non sensibles, des instructions d’installation et une documentation expliquant l’architecture. Si vous débutez, concentrez-vous sur une seule connexion et quelques scénarios de test. Si vous avez déjà de l’expérience, vous pouvez comparer les accès aux ressources, ajouter une validation des entrées ou documenter une stratégie de gestion des erreurs.

Évaluez enfin la faisabilité avec trois questions : puis-je obtenir légalement les données de démonstration ? Puis-je expliquer chaque composant ? Puis-je vérifier le résultat sans dépendre d’un accès privé ou d’un service inaccessible au lecteur ? Si une réponse est non, simplifiez le projet.

• Bon périmètre : un besoin, une source de données et un ensemble limité d’actions.
• Bon signal de compétence : expliquer le flux entre l’application, le client MCP, le serveur MCP et la ressource concernée.
• À éviter : accumuler des intégrations sans montrer pourquoi elles sont nécessaires.

Partir d’un besoin concret

Choisissez une situation que l’on peut décrire en une phrase. Dans une petite entreprise, une équipe peut vouloir retrouver rapidement une information dans des procédures internes. Pour une démonstration publique, remplacez ces procédures par des documents fictifs : une politique de retour inventée, un guide de dépannage rédigé pour l’exercice ou des notices dont la réutilisation est autorisée. L’objectif est de démontrer le mécanisme, pas de reproduire les dossiers d’une entreprise réelle.

Un projet concret Model Context Protocol (MCP) pourrait ainsi être intitulé « Assistant de recherche dans un mini-centre d’aide ». L’utilisateur pose une question, l’assistant interroge les ressources prévues, puis formule une réponse en indiquant le document utilisé. Le projet peut aussi montrer une réponse d’incertitude lorsqu’aucun document ne contient l’information. Cette décision est importante : un bon prototype ne doit pas donner l’impression que l’IA sait répondre à tout.

Pour vérifier que le besoin est pertinent, écrivez trois exemples de questions qu’une personne poserait réellement et trois cas où l’assistant devrait refuser de conclure ou demander une précision. Vous obtenez ainsi une base pour la conception et pour les tests. Vous pouvez adapter le vocabulaire au métier visé — support, gestion documentaire, formation ou opérations — sans prétendre que le prototype est prêt à traiter des dossiers de production.

Le brief ci-dessous sert de point de départ. Il est volontairement assez limité pour un exercice pratique Model Context Protocol (MCP), mais assez riche pour présenter la conception, l’implémentation, les contrôles et les choix de confidentialité.

• Objectif : permettre à un utilisateur de retrouver une réponse dans un corpus de démonstration, en rendant visible la ressource consultée.
• Public : recruteur, client ou collègue technique qui souhaite comprendre rapidement le fonctionnement.
• Livrables : dépôt de code, corpus fictif ou réutilisable, schéma d’architecture, instructions de lancement, scénarios de test et vidéo ou captures de démonstration.
• Limites annoncées : prototype pédagogique, corpus restreint, pas d’accès aux données d’une entreprise et pas d’action modifiant des fichiers.

Préparer les données, fichiers ou ressources

Avant de démarrer, constituez un corpus court dont vous pouvez justifier l’origine et l’utilisation. Le plus sûr pour un portfolio est de rédiger vous-même des exemples fictifs ou de choisir des ressources publiques dont les conditions de réutilisation sont compatibles avec votre projet. Notez la provenance et, si nécessaire, la licence ou les conditions applicables. N’utilisez pas de documents récupérés dans un ancien emploi simplement parce que vous y avez eu accès.

Séparez les éléments publics de la configuration privée. Les clés d’API, mots de passe, jetons d’accès, fichiers de configuration personnels et journaux susceptibles de contenir des données ne doivent pas être ajoutés au dépôt. Préparez un fichier d’exemple sans secret et expliquez comment l’utilisateur fournit ses propres paramètres localement. Vérifiez aussi l’historique du dépôt : supprimer un secret du dernier fichier ne suffit pas s’il demeure dans un commit antérieur.

Définissez clairement quelles capacités MCP sont nécessaires. Pour un premier prototype, des ressources consultables peuvent suffire ; n’ajoutez pas un outil qui modifie, supprime ou envoie des données si le besoin ne l’ex’exige pas. Lorsqu’un projet comporte une action, expliquez ses effets possibles et prévoyez une validation explicite avant son exécution.

Enfin, préparez des données de test variées : une question dont la réponse est présente, une question ambiguë, une question hors périmètre et une ressource mal formée. Ce corpus de test doit être distinct des éventuelles données utilisées pour la démonstration finale. Il vous permettra de reproduire les contrôles après une modification du code.

• À réunir : corpus autorisé, liste des questions de test, configuration d’exemple, schéma simple des composants et instructions de lancement.
• À exclure : données personnelles, informations internes, données client, secrets techniques et contenus protégés sans autorisation.
• À documenter : origine des données, périmètre des accès et comportement prévu en cas d’erreur ou de question sans réponse.

Réaliser le projet par étapes

Commencez par écrire le parcours d’une requête en langage simple : l’utilisateur pose une question, l’application d’IA décide si une ressource MCP est utile, le serveur expose les ressources prévues, puis l’application présente une réponse. Ce schéma évite de confondre le protocole, le modèle d’IA et les données. Il aide aussi un recruteur à voir que vous comprenez les rôles de chaque partie.

Ensuite, construisez le projet dans un ordre qui limite les inconnues. Vérifiez d’abord le fonctionnement minimal de l’environnement, puis ajoutez une seule ressource, et enfin raccordez l’application cliente. Utilisez les exemples et spécifications du projet MCP pour choisir les versions et comportements compatibles avec votre implémentation ; consignez ces choix afin qu’un lecteur puisse les reproduire.

Quand la connexion de base fonctionne, ajoutez seulement les fonctions nécessaires au brief. Par exemple, vous pouvez organiser le corpus par sujets et faire apparaître le nom du document consulté. Ne présentez pas une réponse comme une citation exacte si le système ne garantit pas cette propriété : vérifiez les extraits et indiquez clairement leur origine.

Terminez par une démonstration reproductible sur un environnement propre. Un lecteur doit pouvoir comprendre les prérequis, lancer le projet avec des données d’exemple et essayer les mêmes questions que celles montrées dans votre vidéo. Si une étape requiert un compte ou un service externe, signalez-le et proposez, lorsque c’est possible, des captures ou un scénario sans dépendance à un compte privé.

• Étape 1 : rédiger le brief, le schéma de flux et les critères de réussite.
• Étape 2 : préparer le corpus fictif ou autorisé et la configuration sans secrets.
• Étape 3 : créer le serveur MCP et exposer uniquement les ressources ou outils nécessaires.
• Étape 4 : connecter un client compatible et vérifier une requête simple de bout en bout.
• Étape 5 : traiter les erreurs, les questions hors périmètre et les cas où aucune information pertinente n’est disponible.
• Étape 6 : écrire les tests, nettoyer le dépôt et préparer une démonstration reproductible.

Tester, corriger et documenter

Ne vous contentez pas d’une démonstration qui fonctionne une fois sur votre ordinateur. Une checklist de tests rend votre travail plus crédible, car elle montre ce que vous avez vérifié et ce qui reste hors périmètre. Rejouez les contrôles après les changements importants et notez les résultats de manière concise, sans conserver de données sensibles dans les journaux.

Testez le fonctionnement nominal, mais aussi les erreurs de configuration, l’absence d’une ressource, une entrée inattendue et une question qui dépasse le corpus. Vérifiez que le système ne donne pas une réponse catégorique lorsqu’il ne dispose pas d’éléments suffisants. Contrôlez également les permissions : une ressource en lecture seule ne devrait pas permettre une modification indirecte des données.

La documentation doit répondre aux questions d’un tiers : à quoi sert le projet ? Comment les composants communiquent-ils ? Comment l’installer ? Quelles données sont utilisées ? Comment reproduire un test ? Quelles limites ou risques avez-vous identifiés ? Pour un portfolio, une page claire vaut mieux qu’une longue description qui masque les choix techniques.

Pour protéger la confidentialité, publiez uniquement des données conçues pour la démonstration ou dont la diffusion est autorisée. Masquez les noms, identifiants, adresses et détails métier dans les captures. Si vous montrez un projet réalisé pour une entreprise, obtenez l’autorisation avant de partager le code, les écrans ou les résultats ; sinon, recréez une version autonome avec des exemples fictifs et expliquez qu’il s’agit d’une démonstration.

• Checklist de qualité : installation reproductible ; connexion client-serveur vérifiée ; ressources attendues accessibles ; erreurs compréhensibles ; questions hors périmètre traitées prudemment ; absence de secrets dans les fichiers et l’historique ; données
• Contrôle de sécurité : limiter les capacités exposées, éviter les permissions inutiles et tester qu’une demande ne déclenche pas une action imprévue.
• Contrôle documentaire : chaque prérequis, commande et résultat montré doit correspondre à l’état réel du projet.

Présenter son travail dans un portfolio

Présentez le projet en commençant par le besoin, pas par une liste de technologies. En quelques lignes, dites qui rencontre le problème, ce que le prototype permet de faire et comment MCP intervient. Ajoutez ensuite un schéma compact du flux, une courte démonstration et un accès au code si vous pouvez le publier. Le lecteur doit distinguer facilement ce qui est opérationnel de ce qui est une piste d’évolution.

Les captures d’écran doivent montrer un scénario utile : question initiale, ressource consultée et réponse obtenue. Évitez les écrans remplis de code illisible ou les captures qui exposent des noms de clients, des données internes ou des identifiants. Une vidéo brève peut aider, mais elle ne remplace pas les instructions permettant de reproduire l’essai.

Dans votre bilan, indiquez les choix effectués et les limites connues. Par exemple : corpus réduit, absence de connexion à un système réel, tests effectués uniquement sur les scénarios fournis, ou besoin d’une revue de sécurité avant une mise en production. Cette transparence n’affaiblit pas le projet : elle permet au recruteur ou au client d’évaluer exactement votre contribution.

Pour viser un poste au Maroc, adaptez la présentation au secteur ou au métier recherché et décrivez vos décisions avec des mots simples. Un projet bien expliqué peut montrer votre capacité à cadrer un besoin, à relier une application à des ressources, à tester des résultats et à respecter les contraintes de confidentialité. Le portfolio ne garantit pas une embauche, mais il donne des éléments concrets à discuter en entretien.

• À montrer : objectif, architecture, parcours de démonstration, tests, documentation et limites.
• À retirer : données confidentielles, secrets, captures non autorisées et affirmations non vérifiées.
• À préparer pour l’entretien : pourquoi avoir limité le périmètre, comment les tests ont été choisis et quelles améliorations seraient prioritaires.

Le parcours, étape par étape

1. 1Cadrer un besoin — Choisissez une tâche réelle mais limitée, comme retrouver une information dans un mini-centre d’aide fictif. Écrivez l’objectif, le public, les cas d’usage et les limites.
2. 2Préparer un corpus sûr — Rédigez des documents de démonstration ou utilisez des ressources dont la réutilisation est autorisée. Écartez les données personnelles, les documents d’entreprise et les secrets.
3. 3Définir l’architecture MCP — Dessinez le rôle de l’application cliente, du serveur MCP et des ressources. Commencez par un accès en lecture et n’exposez que les capacités utiles au besoin.
4. 4Construire une version minimale — Faites fonctionner une requête simple de bout en bout avant d’ajouter des fonctions. Gardez les choix de versions, prérequis et configuration dans la documentation.
5. 5Tester les cas utiles et les erreurs — Vérifiez une réponse présente dans le corpus, une question ambiguë, une question hors périmètre, une ressource absente et une configuration invalide. Confirmez que les permissions restent limitées.
6. 6Publier une démonstration propre — Nettoyez le dépôt et son historique, ajoutez des instructions reproductibles, un schéma et des captures anonymisées. Décrivez honnêtement les limites et les améliorations possibles.

Formations et programmes au Maroc

Compétences clés

Questions fréquentes

Sources

1. Model Context Protocol — site officiel modelcontextprotocol.io
2. Formation intra-entreprise — OFPPT ofppt.ma
3. JobInTech jobintech.academy
4. FormaGroup — technologie Model Context Protocol formagroup.ma