Projet Docker au Maroc : créez un portfolio concret, étape par étape

Choisir un projet adapté à son niveau

Un bon projet Docker de débutant est assez petit pour être terminé, mais assez complet pour démontrer plusieurs gestes professionnels : préparer un environnement, construire une image, lancer un conteneur, configurer l’application et expliquer comment la reproduire. La valeur du projet ne dépend pas du nombre d’outils utilisés. Elle tient surtout à sa clarté, à sa cohérence et à la qualité de sa présentation.

Une idée adaptée consiste à créer une petite application de liste de tâches. L’utilisateur peut consulter des tâches préremplies et, si vous ajoutez une base de données, en créer ou en modifier. Une version encore plus simple peut seulement afficher des données statiques : vous pourrez alors vous concentrer sur Docker avant d’ajouter des fonctions. Choisissez une technologie web que vous connaissez déjà, plutôt que d’apprendre simultanément un nouveau langage, un framework et la conteneurisation.

Pour que le projet reste faisable, fixez une limite : une application, un service de stockage au maximum et une méthode de lancement. Compose peut servir à décrire plusieurs services lorsqu’il y en a besoin. Kubernetes, la haute disponibilité et le déploiement sur une infrastructure cloud ne sont pas nécessaires pour démontrer les bases d’un projet portfolio Docker.

Avant de commencer, écrivez ce que vous souhaitez prouver. Par exemple : « Une autre personne peut démarrer mon application localement en suivant le README, sans installer directement ses dépendances sur son ordinateur. » Cette phrase donne un critère de réussite vérifiable et vous aide à éviter les ajouts qui ne servent pas le projet.

• Débutant : une application et un Dockerfile, avec des données de démonstration.
• Niveau suivant : application et base de données décrites dans un fichier Compose.
• Pour enrichir le portfolio : ajouter des tests, une configuration par variables d’environnement ou une vérification automatique de construction.

Partir d’un besoin concret

Un exercice pratique Docker gagne en crédibilité quand il répond à un usage compréhensible. Une petite équipe pourrait vouloir tester un outil de suivi de tâches sans installer manuellement le langage, les bibliothèques et la base de données sur chaque poste. Votre projet peut illustrer une réponse à ce besoin : un environnement de démonstration que l’on lance et arrête de manière documentée.

Vous pouvez remplacer la liste de tâches par un autre exemple proche du métier que vous visez : catalogue de produits fictifs pour une petite boutique, suivi de demandes de support ou tableau de bord de données publiques. Gardez un périmètre limité et indiquez clairement ce qui est simulé. Le portfolio doit montrer votre raisonnement et les limites de l’exercice, pas laisser croire qu’il s’agit d’un produit réellement utilisé par une entreprise.

Si vous souhaitez vous former en parallèle, FormaGroup propose notamment une formation Docker et Kubernetes pour DevOps, de niveau intermédiaire, qui porte sur la conteneurisation puis le déploiement, la configuration et la supervision dans Kubernetes. Pour ce projet de portfolio, vous pouvez commencer par les bases Docker et ne retenir que les parties du parcours qui correspondent à votre objectif.

• Besoin fictif : rendre une application de démonstration facile à lancer par un développeur ou un évaluateur.
• Utilisateur visé : une personne qui découvre le dépôt et veut vérifier rapidement son fonctionnement.
• Critère de réussite : elle peut suivre une procédure courte et obtenir le résultat annoncé.

Préparer les données, fichiers ou ressources

Avant d’écrire le Dockerfile, réunissez le code de l’application, les instructions existantes pour la lancer et les dépendances nécessaires. Prévoyez également les fichiers de configuration à versionner et ceux qui doivent rester locaux. Un dépôt propre facilite la compréhension du projet et évite d’intégrer accidentellement des éléments personnels.

Pour les données, privilégiez des exemples inventés ou des jeux de données ouverts dont les conditions de réutilisation sont claires. N’incluez pas de données de clients, de collègues ou d’utilisateurs, même si vous retirez leurs noms : d’autres détails peuvent permettre de les reconnaître. N’ajoutez pas non plus de mots de passe, de clés d’accès, de jetons ou de fichiers de configuration contenant des secrets au dépôt public.

Un fichier d’exemple peut montrer les variables nécessaires sans révéler de valeur confidentielle. Ajoutez une règle d’exclusion adaptée pour les fichiers locaux sensibles et vérifiez l’historique avant de publier le dépôt. Si un secret a été commis, le supprimer du dernier fichier ne suffit pas nécessairement à l’effacer de l’historique : traitez-le comme exposé et remplacez-le.

Préparez enfin un court brief qui sert de contrat avec vous-même. Il fixe le résultat attendu, la portée et les livrables. Il vous permettra ensuite de décider si une fonctionnalité est essentielle ou si elle relève d’un ajout facultatif.

• Code source minimal et instructions de lancement initiales.
• Données fictives ou ouvertes, avec leur origine et les conditions d’usage lorsqu’elles s’appliquent.
• Fichier d’exemple de configuration sans identifiant ni secret réel.
• Dossier de documentation et emplacement prévu pour les captures d’écran.

Réaliser le projet par étapes

Travaillez dans un ordre qui permet d’isoler les problèmes. D’abord, vérifiez que l’application fonctionne selon sa méthode habituelle. Ensuite, construisez son image et lancez un conteneur. Une fois cette première version stable, ajoutez les réglages nécessaires, puis seulement les services complémentaires. Cette progression vous aide à savoir si un incident vient du code, de la construction de l’image ou de la configuration d’exécution.

Le brief peut tenir sur une page. Il n’a pas besoin d’imiter un document d’entreprise : quelques phrases précises suffisent. Pour une version débutante, le livrable central est une application accessible localement, accompagnée d’instructions reproductibles. Pour une version plus avancée, ajoutez un service de base de données et indiquez comment les données de démonstration sont initialisées.

• Brief — Objectif : permettre à un tiers de démarrer localement une application de suivi de tâches sans installer directement ses dépendances. Périmètre : application web simple et données de démonstration ; base de données facultative. Public : recruteur
• Étape 1 : faire fonctionner l’application hors conteneur et noter les dépendances indispensables. Cela vous donne une référence pour comparer la version conteneurisée.
• Étape 2 : rédiger le Dockerfile pour construire une image à partir du code et des dépendances. Évitez d’y copier des secrets ou des fichiers qui ne sont pas utiles à l’exécution.
• Étape 3 : construire l’image et lancer un conteneur. Vérifiez que l’application écoute sur le port prévu et qu’elle est accessible depuis votre machine.
• Étape 4 : rendre la configuration modifiable sans changer le code. Décrivez dans le README les variables attendues et fournissez uniquement des valeurs fictives dans l’exemple.
• Étape 5 : si le besoin le justifie, décrire l’application et sa base de données avec Compose. Expliquez comment démarrer et arrêter les services et ce qui arrive aux données de démonstration.
• Étape 6 : ajouter des tests ou une vérification automatisée de construction. La formation FormaGroup GitLab CI/CD et automatisation des déploiements peut compléter un parcours qui inclut la construction, les tests et les contrôles qualité d’un pipeline.

Tester, corriger et documenter

La documentation doit permettre à une personne qui ne vous connaît pas de comprendre le résultat et de le reproduire. Commencez le README par une description en langage simple, puis indiquez les prérequis, les commandes et le résultat attendu. Ajoutez une section de dépannage pour les erreurs probables, sans prétendre couvrir tous les environnements possibles.

Expliquez les choix que vous avez faits : pourquoi vous avez conteneurisé l’application, comment la configuration est fournie, et ce que votre projet ne fait pas encore. Si vous utilisez une base de données, précisez comment les données sont conservées ou réinitialisées. Une limite présentée honnêtement vaut mieux qu’une promesse de sécurité ou de disponibilité que le projet ne vérifie pas.

Les tests ne se limitent pas à constater que la page s’affiche sur votre ordinateur. Rejouez les instructions depuis un état propre, et vérifiez que les étapes sont suffisantes. Si vous ne pouvez pas tester sur un autre poste, indiquez précisément l’environnement utilisé et n’affirmez pas une compatibilité que vous n’avez pas vérifiée.

• La construction de l’image se termine sans erreur.
• Le conteneur démarre et l’application répond sur l’adresse et le port documentés.
• Les fonctions principales annoncées dans le brief sont vérifiées.
• Une configuration absente ou incorrecte provoque un comportement compréhensible plutôt qu’un échec silencieux.
• Les données persistent ou sont réinitialisées conformément à ce que la documentation annonce.
• Les journaux ne révèlent ni secret ni donnée personnelle.
• Les instructions sont rejouées depuis un environnement propre ou, à défaut, l’environnement de test est décrit.
• Le dépôt ne contient pas de fichiers temporaires, de secrets, de données confidentielles ou de captures révélant des informations privées.

Présenter son travail dans un portfolio

Un portfolio Docker doit permettre de saisir rapidement le problème, le résultat et votre contribution. Présentez le dépôt avec un titre explicite, une courte description et une capture de l’application. Ajoutez, si possible, une démonstration courte qui montre le lancement et le fonctionnement, en prenant soin de masquer les noms d’utilisateur, les chemins personnels et les identifiants visibles.

Faites apparaître les éléments utiles à l’évaluation : Dockerfile, éventuel fichier Compose, tests et README. Une vue d’ensemble de l’architecture peut aider, à condition qu’elle corresponde à ce qui existe vraiment. Décrivez ce que vous avez fait vous-même, les outils employés et les points que vous souhaiteriez améliorer. Ne confondez pas une image construite localement avec un déploiement en production.

Dans un CV ou un échange avec un recruteur au Maroc, présentez le projet comme un exercice personnel s’il s’agit d’un exercice personnel. Expliquez le besoin choisi, le problème rencontré et la façon dont vous l’avez résolu. Vous pouvez ensuite adapter l’exemple à un poste visé : mise en place d’un environnement reproductible, automatisation de tests ou préparation d’un déploiement.

• Une phrase sur le besoin et le résultat obtenu.
• Une capture ou une démonstration sans données confidentielles.
• Un lien vers le dépôt et une procédure de lancement facile à trouver.
• Une liste courte des fonctionnalités réellement terminées.
• Une section « limites et prochaines étapes » qui distingue les faits des améliorations envisagées.

Le parcours, étape par étape

1. 1Définir la preuve à apporter — Choisissez une application familière et formulez un objectif vérifiable : une autre personne doit pouvoir la lancer en suivant vos instructions.
2. 2Préparer un dépôt propre — Réunissez le code, les dépendances et des données fictives. Séparez la configuration d’exemple des fichiers locaux pouvant contenir des secrets.
3. 3Conteneuriser progressivement — Vérifiez d’abord l’application seule, construisez l’image, lancez un conteneur et ajoutez Compose uniquement si plusieurs services sont réellement nécessaires.
4. 4Vérifier le résultat — Rejouez les commandes depuis un état propre, testez les fonctions annoncées et contrôlez les journaux, la configuration et les données.
5. 5Publier et expliquer — Rédigez le README, ajoutez une démonstration sans information confidentielle et présentez le projet comme un exercice si c’en est un.

Formations et programmes au Maroc

Compétences clés

Questions fréquentes

Sources

1. FormaGroup — Docker et Kubernetes pour DevOps formagroup.ma
2. FormaGroup — GitLab CI/CD et automatisation des déploiements formagroup.ma
3. FormaGroup — DevSecOps et sécurité des pipelines CI/CD formagroup.ma
4. JobInTech jobintech.academy
5. OFPPT — Formation intra-entreprise ofppt.ma