Projet de portfolio GitLab CI/CD au Maroc : de l’idée à la démonstration

Choisir un projet adapté à son niveau

Pour un projet de portfolio GitLab CI/CD débutant, choisissez un périmètre assez petit pour aboutir, mais assez complet pour raconter une démarche professionnelle. Une application complexe n’est pas indispensable : ce qui compte est de rendre visibles les étapes automatisées et d’expliquer pourquoi elles existent. GitLab définit les pipelines dans le fichier .gitlab-ci.yml ; ils s’appuient sur des jobs exécutés par des runners, regroupés éventuellement en stages successifs.

Le projet proposé est un mini-site statique qui présente un tableau de bord d’incidents fictifs : titre, catégorie, statut et date de mise à jour. À chaque modification du code ou des données, le pipeline contrôle la structure des fichiers, construit le site, exécute quelques tests puis publie le résultat avec GitLab Pages. Le sujet est compréhensible par une personne non spécialiste et laisse place à des améliorations graduelles.

Ajustez l’ambition à vos acquis. Si vous débutez, servez-vous de HTML, CSS et d’un petit fichier JSON, avec des commandes de contrôle simples. Si vous êtes plus à l’aise, ajoutez des tests automatisés, une vérification de liens, une analyse de dépendances ou un environnement de prévisualisation. N’ajoutez pas un outil uniquement pour allonger la liste de technologies : chaque élément doit répondre à un besoin expliqué.

• Un objectif observable : une modification déclenche une chaîne de contrôles.
• Un périmètre livrable : une page, un jeu de données fictif et un pipeline lisible.
• Un résultat consultable : le dépôt contient les sources et, si le projet est public et configuré pour cela, le site publié.
• Une démonstration honnête : indiquez ce qui est automatisé, ce qui reste manuel et ce qui n’est pas couvert.

Partir d’un besoin concret

Dans une petite équipe, une liste d’incidents ou de demandes peut être difficile à partager si elle reste dans un fichier local ou change sans vérification. Le projet simule ce besoin sans prétendre remplacer un outil de gestion opérationnel. Son objectif est de rendre visible un résumé fictif et de réduire le risque de publier une page cassée après une modification.

Brief de projet — Objectif : automatiser la validation, la construction et la publication d’un mini-site de suivi d’incidents fictifs avec GitLab CI/CD. Public visé : un responsable technique, un recruteur ou un client qui souhaite comprendre le processus en quelques minutes. Livrables : dépôt GitLab, fichier .gitlab-ci.yml commenté, données d’exemple non sensibles, tests, site publié ou instructions locales, documentation, captures du pipeline et note sur les limites.

Définissez un critère de réussite avant de commencer : une modification valide doit pouvoir traverser les contrôles et produire une version publiable ; une modification volontairement erronée doit faire échouer le contrôle correspondant avec un message compréhensible. Ce scénario d’échec rend le projet plus parlant qu’une capture montrant seulement une exécution réussie.

• Question métier simulée : comment partager un état de suivi simple sans manipuler de données réelles ?
• Réponse technique : une page statique reconstruite et publiée automatiquement à partir du dépôt.
• Critère de qualité : une erreur de structure est détectée avant la publication.

Préparer les données, fichiers ou ressources

Avant d’écrire le pipeline, réunissez les éléments minimaux : un dépôt GitLab, un petit site statique ou un générateur de site, un fichier de données d’exemple, une commande de test reproductible et un runner disponible pour exécuter les jobs. Notez les versions des outils utilisées et les commandes permettant de lancer le projet localement. Commencez avec une pipeline minimale, puis ajoutez un contrôle à la fois.

Préparez un jeu de données entièrement inventé : par exemple, quelques incidents fictifs, des dates génériques et des statuts simples. N’utilisez ni export d’entreprise, ni nom de client, ni adresse, ni identifiant, ni capture provenant d’un environnement de travail. Vérifiez également les métadonnées des images et les exemples copiés dans les journaux de commande.

Si le pipeline exige un jeton ou un mot de passe pour une étape facultative, ne l’inscrivez jamais dans le dépôt, un exemple de configuration, une capture ou un journal. Utilisez les paramètres de variables CI/CD adaptés et limitez leur portée. Le masquage réduit le risque d’affichage accidentel, mais GitLab précise qu’il ne garantit pas à lui seul la protection contre un script malveillant. Pour ce projet public, privilégiez une publication sans secret lorsque c’est possible.

• Structure possible : README.md, .gitlab-ci.yml, src/ ou public/, tests/ et données fictives.
• Identifiez les droits nécessaires pour les images, icônes, polices et dépendances réutilisées.
• N’incluez pas de fichier de configuration local contenant des accès ou des variables privées.
• Avant de rendre le dépôt public, inspectez l’historique Git : supprimer un secret du dernier commit ne l’efface pas forcément des commits antérieurs.

Réaliser le projet par étapes

1. Créez le dépôt et faites fonctionner le site localement. Gardez une première version simple : une page d’accueil, un tableau fictif et quelques styles. Un lecteur doit comprendre le résultat sans devoir installer toute une plateforme.

2. Ajoutez une pipeline minimale dans .gitlab-ci.yml. Commencez par un job qui affiche son exécution et vérifiez qu’un push déclenche bien un pipeline. Les jobs exécutent des commandes sur un runner ; leur journal doit permettre de comprendre ce qui s’est passé.

3. Organisez les étapes dans un ordre cohérent, par exemple contrôle, construction, puis publication. Les étapes peuvent regrouper des jobs et s’exécuter en séquence ; les jobs d’une même étape peuvent, selon la configuration, fonctionner en parallèle. Nommez les jobs selon leur fonction, plutôt que d’utiliser des libellés vagues comme « étape 1 ».

4. Ajoutez des vérifications adaptées au projet : présence des fichiers requis, validité du JSON, tests de rendu ou vérification des liens. Faites échouer le job en cas d’erreur, avec un message qui aide à la corriger. Évitez d’affirmer qu’un test garantit l’absence de défauts : il ne couvre que les cas prévus.

5. Construisez le site et conservez les fichiers générés comme artefacts si une étape suivante doit les utiliser ou si vous voulez pouvoir examiner le résultat. Les artefacts sont des fichiers de sortie attachés aux jobs et peuvent servir à transmettre le résultat d’un job à un autre.

6. Configurez GitLab Pages pour publier le site statique. Vérifiez les conditions de publication et l’emplacement des fichiers produits. Faites un déploiement de test, puis documentez le chemin pour consulter le site. Si la publication n’est pas activée ou si le dépôt n’est pas accessible, fournissez au minimum une procédure locale reproductible et des preuves du pipeline.

• Montrez un pipeline réussi après une modification normale.
• Montrez aussi un échec volontaire et la correction qui le résout.
• Ajoutez les scans de sécurité seulement si vous pouvez expliquer ce qu’ils analysent et leurs limites.
• Conservez une configuration courte, lisible et cohérente avec votre niveau.

Tester, corriger et documenter

Une pipeline verte est un indice que les contrôles configurés ont réussi, pas une garantie que le projet est exempt de défauts. Testez donc le site dans le navigateur et relisez les journaux des jobs. Pour chaque contrôle, décrivez ce qu’il vérifie, à quel moment il intervient et quelle action entreprendre lorsqu’il échoue. La documentation GitLab rappelle que les jobs peuvent notamment construire, tester ou déployer du code et que leurs journaux rendent leur exécution consultable.

• Le dépôt se récupère et les instructions d’installation fonctionnent sur un environnement propre.
• Une modification valide déclenche le pipeline attendu.
• Une donnée mal formée est détectée avant la publication.
• La construction produit les fichiers au bon emplacement.
• Les artefacts attendus sont disponibles lorsqu’ils sont configurés.
• Le site publié s’ouvre et ses liens principaux fonctionnent.
• Aucun secret, identifiant personnel ou donnée confidentielle n’apparaît dans le code, l’historique, les artefacts, les journaux ou les captures.
• Le README décrit les prérequis, les commandes, les étapes du pipeline, le résultat attendu et les limites.

Présenter son travail dans un portfolio

Rédigez une présentation courte qui suit le fil du projet : le besoin simulé, votre choix de périmètre, les étapes automatisées, les contrôles ajoutés et le résultat. Ajoutez une capture du graphe du pipeline, une capture du site publié et, si possible, un exemple d’échec volontaire avec sa résolution. Masquez ou recadrez les identifiants personnels et toute information qui ne doit pas être diffusée.

Dans le dépôt, privilégiez un README avec une table des matières, une architecture simple et un schéma du pipeline. Ajoutez les versions des outils testées, les commandes exactes pour reproduire le résultat et un lien vers la démonstration s’il est disponible. Une courte vidéo ou une démonstration en direct peut compléter le dépôt, mais ne remplace pas des instructions de reproduction.

Présentez les limites sans les dissimuler : données fictives, absence d’intégration à un système d’incidents réel, contrôles limités aux tests décrits, éventuelle publication non adaptée à des données privées. Pour un échange avec un recruteur ou un client au Maroc, préparez une explication de deux minutes : quel problème avez-vous simulé, pourquoi ces étapes, comment le pipeline échoue-t-il utilement et que feriez-vous ensuite ?

• Mettez en avant votre contribution personnelle et distinguez-la clairement des composants ou modèles réutilisés.
• Évitez les captures qui montrent des variables, des jetons, des URL internes ou des noms de projets confidentiels.
• Expliquez la différence entre un contrôle automatisé et une revue humaine.
• Terminez par deux améliorations possibles, classées selon leur utilité plutôt que par leur complexité.

Le parcours, étape par étape

1. 1Cadrer — Choisissez le mini-site d’incidents fictifs, fixez un résultat minimal et écrivez les livrables ainsi que les critères de réussite.
2. 2Préparer — Créez le dépôt, préparez des données inventées, choisissez les commandes de test et vérifiez que le site fonctionne localement.
3. 3Automatiser — Ajoutez le fichier .gitlab-ci.yml et construisez progressivement les jobs de contrôle, de construction et de publication.
4. 4Valider — Testez une modification correcte et une erreur volontaire ; examinez les logs, les fichiers produits, les artefacts et le site.
5. 5Documenter — Rédigez les instructions de reproduction, expliquez les choix et indiquez les limites sans publier de données ou secrets.
6. 6Présenter — Ajoutez des captures expurgées, le lien de démonstration s’il existe et un résumé compréhensible pour un recruteur ou un client.

Formations et programmes au Maroc

Compétences clés

Questions fréquentes

Sources

1. CI/CD pipelines — GitLab Docs docs.gitlab.com
2. CI/CD Jobs — GitLab Docs docs.gitlab.com
3. Tutorial: Create a complex pipeline — GitLab Docs docs.gitlab.com
4. Job artifacts — GitLab Docs docs.gitlab.com
5. Create a GitLab Pages deployment for a static site — GitLab Docs docs.gitlab.com
6. CI/CD variables — GitLab Docs docs.gitlab.com
7. GitLab Education Services about.gitlab.com
8. Maîtriser CI/CD avec GitLab pour l’Automatisation des Déploiements — INNOV MAROC innov-maroc.com
9. GitLab CI/CD et automatisation des déploiements — FormaGroup formagroup.ma
10. DevSecOps et sécurité des pipelines CI/CD — FormaGroup formagroup.ma