Quel projet Red Hat OpenShift réaliser pour son portfolio au Maroc ?

Choisir un projet adapté à son niveau

Le bon projet Red Hat OpenShift débutant est assez petit pour être terminé, mais assez complet pour rendre visibles plusieurs compétences. Une application web simple, composée d’une interface et d’une API, convient bien : vous pouvez montrer comment le code est construit en image conteneur, déployé dans un projet OpenShift, exposé à travers une route et contrôlé après mise en service.

Évitez de commencer par une architecture à nombreux microservices, une chaîne d’intégration complexe ou une infrastructure de production. Ces sujets multiplient les dépendances et risquent de détourner l’attention de votre démarche. Pour une première réalisation, une application avec un ou deux composants suffit. Vous pourrez ensuite ajouter une base de données ou une automatisation si vous avez le temps et un environnement adapté.

Définissez dès le départ un périmètre observable. À la fin, une personne doit pouvoir comprendre ce que fait l’application, comment elle est déployée et comment vous avez vérifié son fonctionnement. Le projet peut être réalisé sur un cluster de formation, un environnement fourni par une organisation ou un environnement de test disponible pour vous. Les commandes et options peuvent différer selon la configuration du cluster : consignez celles que vous avez réellement utilisées.

• Un objectif fonctionnel compréhensible en une phrase.
• Un nombre limité de composants et de fonctionnalités.
• Des fichiers de configuration adaptés à l’environnement de test, sans identifiants secrets.
• Des preuves de fonctionnement : tests, journaux pertinents et captures non sensibles.
• Une documentation qui distingue ce qui a été fait de ce qui resterait à améliorer.

Partir d’un besoin concret

Un projet de portfolio gagne en crédibilité lorsqu’il répond à une situation plausible. Vous pouvez imaginer une petite équipe qui souhaite centraliser les demandes de maintenance d’un espace de travail : une personne crée une demande, consulte son statut et reçoit une réponse de démonstration. Le but n’est pas de construire un produit commercial complet, mais de montrer un parcours utilisateur simple et un déploiement OpenShift maîtrisé.

Formulez le besoin du point de vue de l’utilisateur : « Une personne doit pouvoir soumettre une demande et vérifier qu’elle a bien été enregistrée. » Ensuite, délimitez ce qui ne sera pas inclus : authentification avancée, notifications réelles, intégration à un outil d’entreprise ou traitement de données personnelles. Énoncer ces limites évite de laisser penser que le prototype est prêt pour une utilisation en production.

Choisissez quelques critères de réussite vérifiables. Par exemple : l’application répond à une requête prévue, l’API reçoit et traite une demande de démonstration, les composants démarrent dans l’environnement choisi et les ressources restent dans les limites configurées. Définissez aussi le public de votre présentation : un recruteur technique voudra voir les choix de déploiement, tandis qu’un client potentiel voudra d’abord comprendre le problème résolu et les limites du prototype.

• Besoin : enregistrer et consulter des demandes fictives.
• Utilisateurs : un demandeur et, éventuellement, une personne chargée du suivi.
• Fonctionnalités minimales : créer une demande, afficher une liste et montrer un statut.
• Indicateurs : réponses attendues, état des pods et résultats des tests prévus.
• Limites annoncées : données de démonstration, périmètre réduit et absence de garantie de production.

Préparer les données, fichiers ou ressources

Avant de déployer, réunissez le code source de l’application, les fichiers nécessaires à sa construction et les manifestes ou modèles OpenShift que vous avez choisis. Prévoyez un fichier README, une description des variables de configuration et des commandes de vérification. Si l’application utilise une base de données, indiquez clairement si elle est éphémère ou persistante dans votre environnement de démonstration ; ne promettez pas une conservation durable sans l’avoir configurée et testée.

Pour rendre le projet partageable, utilisez des données entièrement fictives. N’importez pas de fichiers de clients, de collègues ou d’employeurs, même pour quelques essais. Ne placez pas dans le dépôt des mots de passe, jetons, clés privées, fichiers de configuration contenant des secrets ou journaux qui révèlent des informations internes. Les secrets doivent être gérés hors du code et de la documentation publique, selon les mécanismes de l’environnement utilisé.

Vérifiez également les droits associés au code, aux images, aux polices, aux jeux de données et aux captures que vous souhaitez montrer. Si vous partez d’un exemple ou d’un dépôt existant, indiquez la source et les modifications apportées. Préparez une version de démonstration qui ne dépend pas de ressources internes indisponibles pour le lecteur.

• Code source et instructions de lancement.
• Configuration de déploiement et paramètres non sensibles.
• Données synthétiques, créées pour le projet.
• Une liste des composants utilisés et de leurs rôles.
• Une vérification des secrets, des droits de réutilisation et des informations personnelles avant publication.

Réaliser le projet par étapes

Commencez par créer une application minimale et vérifiez qu’elle fonctionne avant d’ajouter des éléments liés au cluster. Cette première vérification permet de séparer un défaut du code d’un problème de déploiement. Ajoutez ensuite les fichiers nécessaires à la construction ou à l’exécution du conteneur et décrivez la méthode retenue.

Déployez dans un espace de test isolé, en suivant les consignes de l’environnement OpenShift auquel vous avez accès. Configurez les ressources nécessaires au fonctionnement de l’application, son exposition réseau et les paramètres de santé adaptés à ses points d’entrée. N’appliquez pas aveuglément des exemples trouvés ailleurs : vérifiez que les noms, images, ports et paramètres correspondent réellement à votre application et au cluster.

Une fois le premier déploiement opérationnel, effectuez une modification simple et montrez comment elle est mise en service. Vous pouvez ensuite présenter la configuration des ressources, les contrôles de santé et les journaux utilisés pour diagnostiquer un problème simulé. Gardez une trace des changements et des résultats. Le portfolio doit permettre de distinguer vos contributions personnelles des composants fournis par l’environnement ou réutilisés depuis une documentation.

• Étape 1 — préciser le besoin, les utilisateurs et les critères de réussite.
• Étape 2 — développer puis tester l’application localement ou dans l’environnement de développement choisi.
• Étape 3 — préparer l’image et les fichiers de déploiement.
• Étape 4 — créer l’espace de travail et déployer les composants sur OpenShift.
• Étape 5 — configurer l’accès à l’application, les paramètres et les contrôles de santé adaptés.
• Étape 6 — tester le parcours utilisateur, examiner l’état des ressources et corriger les erreurs.
• Étape 7 — préparer la documentation, les captures et une courte démonstration.

Tester, corriger et documenter

Une démonstration convaincante ne se limite pas à une page d’accueil qui s’affiche. Testez le parcours prévu de bout en bout et conservez les preuves utiles sans exposer d’informations confidentielles. La documentation doit permettre à une autre personne de comprendre comment lancer le projet, ce qu’elle doit observer et quelles limites s’appliquent.

Décrivez les erreurs rencontrées et votre méthode de diagnostic, sans transformer le README en journal exhaustif. Par exemple, expliquez quel symptôme vous avez observé, quel contrôle vous a permis de l’isoler et quelle correction vous avez appliquée. Si une vérification n’a pas été menée, indiquez-le clairement au lieu de laisser entendre qu’elle est réussie.

• L’application répond-elle sur le chemin prévu, et le résultat correspond-il à la requête ?
• Les composants attendus démarrent-ils et restent-ils disponibles pendant la démonstration ?
• Les contrôles de santé correspondent-ils aux points d’entrée réellement fournis par l’application ?
• Les ressources et paramètres configurés sont-ils documentés et cohérents avec l’usage de test ?
• Une modification du projet peut-elle être déployée et vérifiée selon les étapes décrites ?
• Le README précise-t-il les prérequis, les commandes utiles, les résultats attendus et les limites ?
• Le dépôt, les captures et les journaux sont-ils exempts de secrets et de données personnelles ?
• Les composants tiers et les ressources réutilisées sont-ils attribués lorsque nécessaire ?

Présenter son travail dans un portfolio

Présentez le projet comme une étude de cas : besoin, périmètre, architecture, réalisation, tests, résultats et limites. Ajoutez un schéma simple indiquant les principaux composants et leurs échanges. Une capture de l’application, une vue de l’état des ressources et une courte démonstration peuvent compléter le dépôt, à condition qu’elles ne révèlent pas de noms internes, de comptes, de routes privées ou de données réelles.

Pour un entretien ou une présentation client, préparez une démonstration courte et répétable. Expliquez d’abord le besoin, puis montrez le parcours principal et enfin les éléments OpenShift qui témoignent de votre travail. Gardez une solution de repli, comme une vidéo enregistrée sans données sensibles ou des captures préparées, au cas où l’environnement ne serait pas accessible le jour de la présentation.

Soyez précis sur votre contribution : indiquez ce que vous avez développé, configuré, testé et documenté. Mentionnez les choix que vous avez faits et les compromis du prototype. Une limite expliquée avec honnêteté est plus utile qu’une promesse de disponibilité, de sécurité ou de montée en charge qui n’a pas été vérifiée.

• README clair et dépôt organisé.
• Schéma de l’architecture et description des composants.
• Captures ou démonstration utilisant uniquement des données fictives.
• Résultats de tests et explication d’un exemple de diagnostic.
• Section « limites et améliorations possibles ».
• Description exacte de votre rôle et des éléments réutilisés.

Le parcours, étape par étape

1. 1Cadrer un besoin limité — Choisissez un problème métier plausible, formulez un objectif observable et excluez explicitement les fonctions qui ne seront pas traitées.
2. 2Préparer l’application et les ressources — Réunissez le code, la configuration et les instructions. Utilisez uniquement des données fictives et contrôlez les droits associés aux ressources réutilisées.
3. 3Construire et déployer — Vérifiez l’application, préparez son conteneur, puis déployez-la dans un environnement OpenShift de test en adaptant les paramètres au cluster disponible.
4. 4Vérifier et améliorer — Testez le parcours utilisateur et le fonctionnement des composants, examinez leur état et leurs journaux, puis consignez les corrections apportées.
5. 5Documenter et présenter — Publiez les étapes reproductibles, les résultats, les limites et des preuves non sensibles. Préparez une démonstration courte avec une solution de repli.

Formations et programmes au Maroc

Compétences clés

Questions fréquentes

Sources

1. Formation Administration et sécurisation de Kubernetes avec OpenShift — FormaGroup formagroup.ma
2. Technologie Red Hat OpenShift — FormaGroup formagroup.ma
3. JobInTech jobintech.academy
4. Formation intra-entreprise — OFPPT ofppt.ma