Apprendre GitHub Actions en 30 jours : un plan pratique au Maroc

Définir un résultat mesurable à atteindre

Avant de commencer, choisissez un résultat que vous pourrez vérifier au bout de 30 jours. Un objectif adapté aux bases de GitHub Actions pourrait être : « Je peux créer et expliquer un workflow qui se déclenche lors d’un push ou d’une pull request, exécute une commande de test et affiche clairement son résultat. » Cet objectif est plus utile qu’une intention générale comme « apprendre le DevOps », car il délimite ce qu’il faut étudier et ce qui peut attendre.

GitHub Actions organise l’automatisation autour de workflows, décrits dans des fichiers YAML placés dans le dépôt. Un workflow peut être déclenché par un événement et contenir un ou plusieurs jobs, eux-mêmes composés d’étapes. Pour démarrer, il suffit de comprendre cette structure et de réussir à faire tourner un workflow simple. Il n’est pas nécessaire de commencer par les déploiements complexes, les secrets ou la création d’actions personnalisées.

Faites un point de départ : savez-vous créer un dépôt, modifier un fichier, envoyer un commit et ouvrir une pull request ? Si certaines étapes sont encore difficiles, consacrez du temps à Git et à GitHub avant ou pendant la première semaine. Notez aussi votre temps disponible, votre système de travail et le petit projet qui servira de support : une application d’exercice, un script ou un dépôt de démonstration.

• Résultat mesurable : un workflow fonctionnel qui lance une vérification sur un événement choisi.
• Prérequis conseillés : notions de dépôt, commit, branche et pull request ; bases de YAML utiles, mais apprenables en cours de route.
• À remettre à plus tard : déploiement en production, matrices avancées, actions personnalisées et gestion complexe des permissions.

Semaine 1 : découvrir l’environnement

Objectif de la semaine : repérer où se trouvent les workflows, comprendre leur rôle et lancer un premier exemple. Prévoyez environ 4 à 6 heures, idéalement en trois ou quatre séances. Commencez par explorer l’onglet Actions d’un dépôt de test et observez comment GitHub présente les exécutions, leur statut, les journaux et les étapes qui ont réussi ou échoué.

Ensuite, lisez un exemple de workflow très simple et identifiez ses parties : le nom, l’événement déclencheur, le job, l’environnement d’exécution et les étapes. Ne cherchez pas encore à mémoriser toute la syntaxe YAML. Votre priorité est de pouvoir expliquer, avec vos mots, ce qui déclenche le workflow et ce qu’il fait.

Exercice progressif : créez un dépôt de démonstration, ajoutez un workflow déclenché lors d’un push et faites-lui exécuter une commande qui affiche un message. Envoyez une modification, consultez l’exécution dans l’interface et ouvrez les journaux. Si le workflow échoue, repérez l’étape concernée et le message associé avant de modifier le fichier.

En fin de semaine, faites un premier bilan sans regarder vos notes : pouvez-vous retrouver le fichier de workflow ? Expliquer ce qu’est un événement déclencheur ? Lire le résultat d’une exécution ? Si une réponse manque, refaites la manipulation plutôt que d’ajouter un nouveau sujet.

• Jalon : un workflow simple s’exécute après un push.
• Exercice de lecture : repérer dans le fichier l’événement, le job et les étapes.
• Auto-évaluation : expliquer en une minute comment trouver le journal d’une exécution réussie ou échouée.

Semaine 2 : maîtriser les opérations de base

Objectif de la semaine : modifier et tester un workflow sans recopier aveuglément un exemple. Gardez un budget indicatif de 4 à 6 heures. Choisissez deux événements utiles, par exemple un push sur une branche de travail et l’ouverture ou la mise à jour d’une pull request. Vérifiez le comportement de chaque déclencheur en réalisant réellement l’action dans votre dépôt.

Apprenez à distinguer les étapes d’un job et à lire leur ordre d’exécution. Essayez ensuite une action disponible dans le catalogue GitHub pour préparer l’environnement ou récupérer le code, puis ajoutez une commande de vérification adaptée à votre projet. Notez la différence entre une commande exécutée dans le workflow et une action appelée dans une étape.

Exercices : modifiez le message affiché par votre premier workflow ; ajoutez une étape qui vérifie la présence d’un fichier ; puis provoquez volontairement une erreur dans une commande afin d’observer comment elle apparaît dans les journaux. Corrigez-la et relancez l’exécution. Cette pratique du diagnostic est essentielle : dans un contexte professionnel, savoir trouver la cause d’un échec est souvent plus utile que connaître un grand nombre de fonctionnalités.

Ne placez pas de mot de passe ou de jeton directement dans le fichier YAML. Pour ce parcours débutant, contentez-vous de comprendre qu’une donnée confidentielle ne doit pas être écrite en clair dans un dépôt. N’introduisez pas de secret réel dans le projet d’exercice.

• Jalon : deux déclencheurs testés, avec des résultats compris.
• Exercice : ajouter une vérification simple, provoquer un échec, lire le journal et corriger la cause.
• Auto-évaluation : pouvez-vous expliquer pourquoi une étape échoue et montrer où vous avez trouvé l’information ?

Semaine 3 : appliquer les acquis à un cas réel

Objectif de la semaine : remplacer les exercices isolés par un scénario proche d’un usage professionnel. Comptez encore environ 4 à 6 heures. Choisissez un dépôt adapté à votre niveau : une petite application avec tests, un site statique ou un script. Le dépôt doit rester assez simple pour que vous compreniez ce que le workflow vérifie.

Construisez un workflow qui se lance lors d’un push ou d’une pull request, récupère le code et exécute une commande de contrôle déjà disponible dans le projet. Si votre application possède des tests, lancez-les. Sinon, définissez une vérification adaptée, comme contrôler qu’un fichier attendu existe ou qu’une commande de validation du projet se termine correctement. Le but est d’automatiser une tâche répétable, pas d’ajouter une étape décorative.

Travaillez avec une branche distincte et une pull request. Observez si le workflow s’exécute au bon moment, si le résultat est visible pour la revue et si un échec permet de repérer le problème. Testez aussi une modification qui doit réussir et une autre qui doit échouer. Documentez brièvement le rôle du workflow dans le dépôt.

Si le projet contient plusieurs tâches indépendantes, vous pouvez examiner la notion de plusieurs jobs, mais n’ajoutez cette complexité que si vous savez expliquer pourquoi elle est utile. Évitez d’ajouter une matrice, un déploiement ou des permissions avancées simplement pour rendre le fichier plus long.

• Jalon : une pull request déclenche une vérification pertinente pour le projet.
• Exercice : réaliser une modification qui passe les tests, puis une qui échoue, et comparer les résultats.
• Auto-évaluation : un autre apprenant pourrait-il comprendre ce que le workflow vérifie à partir du fichier et de sa documentation ?

Semaine 4 : finaliser et vérifier son résultat

Objectif de la semaine : consolider le workflow, vérifier sa fiabilité et présenter le résultat. Prévoyez environ 4 à 6 heures. Relisez le fichier YAML et supprimez les étapes inutiles. Vérifiez que le déclencheur correspond bien au besoin, que les commandes sont compréhensibles et que les noms des jobs et des étapes aident à lire le résultat.

La réalisation finale peut être un dépôt de démonstration comportant une application ou un script, un workflow de vérification et un court fichier explicatif. Le workflow doit s’exécuter dans au moins un scénario réussi et un scénario d’échec contrôlé. Présentez ce qu’il automatise, quand il se lance et comment vous avez diagnostiqué un problème. Ne revendiquez pas un déploiement ou une sécurisation que vous n’avez pas réellement mis en œuvre.

Faites une auto-évaluation à partir de preuves : le fichier existe au bon emplacement ; le workflow a été exécuté ; vous savez ouvrir les journaux ; les tests ou contrôles sont pertinents ; le dépôt ne contient pas de secret en clair ; la documentation explique l’usage. Si un point ne passe pas, corrigez-le et relancez le workflow. Une exécution réussie après correction est plus instructive qu’un fichier simplement copié.

Enfin, demandez à une autre personne de lire le dépôt ou expliquez votre démarche à voix haute. Les questions qu’elle pose révèleront les notions à revoir. Gardez une trace des erreurs rencontrées et des solutions trouvées : ce journal devient une première ressource de révision et une preuve concrète de votre progression.

• Réalisation finale : dépôt documenté, workflow fonctionnel et vérifications visibles.
• Jalon final : réussite confirmée, échec contrôlé compris, puis correction validée.
• Critère de qualité : être capable de modifier le workflow et d’expliquer l’effet attendu avant de relancer.

Adapter le rythme et poursuivre après 30 jours

Le calendrier est indicatif. Si vous disposez de peu de temps, répartissez le même parcours sur six ou huit semaines au lieu de sauter les exercices. Si vous avez déjà automatisé des tests, passez plus vite sur la découverte et consacrez davantage de séances à la lecture des journaux, aux déclencheurs et à la qualité de la vérification. Une séance courte et régulière aide à garder le fil, mais le temps nécessaire dépend notamment de votre aisance avec Git, YAML et les commandes du projet.

Pour progresser rapidement en GitHub Actions, approfondissez les sujets dans l’ordre où ils deviennent utiles : d’abord les déclencheurs et les jobs, ensuite les données confidentielles et les permissions, puis la réutilisation de workflows et les stratégies de tests. Avant chaque nouvelle notion, formulez un besoin précis. Par exemple : « Je veux éviter de répéter les mêmes étapes dans plusieurs dépôts. » Cela vous aidera à choisir une fonctionnalité au lieu d’accumuler des exemples sans objectif.

Au Maroc, un parcours peut se faire en autonomie, en formation à distance ou en présentiel selon l’offre disponible et le contexte professionnel. Les ressources officielles de GitHub permettent de travailler sur un dépôt de pratique ; une formation accompagnée peut aider à structurer les exercices, obtenir des retours et relier les manipulations à un projet. Pour les dispositifs de montée en compétences, vérifiez directement les modalités d’admission, le contenu et le format proposés par l’organisme concerné.

• Si vous débutez avec Git : consolidez d’abord les opérations de dépôt, branches, commits et pull requests.
• Si vous maîtrisez déjà les bases : améliorez la lisibilité, le diagnostic des échecs et la pertinence des contrôles.
• Après le parcours : choisissez un besoin réel, ajoutez une seule fonctionnalité à la fois et testez-la dans un dépôt non critique.

Ressources et formats de formation au Maroc

Une ressource d’apprentissage est plus utile si elle accompagne une manipulation réelle. Utilisez les tutoriels et la documentation GitHub pour vérifier la syntaxe et comprendre les éléments rencontrés pendant les exercices. Les ressources de montée en compétences au Maroc peuvent également aider à identifier un parcours adapté, mais les détails d’un programme précis sont à confirmer auprès de son organisme.

Pour choisir une formation, demandez si les participants manipulent eux-mêmes un dépôt, s’ils construisent un workflow de bout en bout et s’ils apprennent à lire les journaux d’échec. Vérifiez aussi le niveau requis, le temps consacré à la pratique, le format, les modalités d’accompagnement et le livrable final. Une formation pertinente devrait vous permettre de repartir avec une réalisation que vous comprenez et pouvez expliquer.

• Privilégiez un programme qui comprend des exercices exécutés dans GitHub, pas uniquement des démonstrations.
• Vérifiez que le niveau Git demandé correspond à votre expérience.
• Choisissez un projet final proportionné : une vérification automatisée est un bon premier livrable.

Le parcours, étape par étape

1. 1Avant le jour 1 — cadrer le parcours — Choisissez un dépôt d’exercice, vérifiez vos bases Git et écrivez votre objectif mesurable : automatiser une vérification sur un push ou une pull request. Bloquez environ 4 à 6 heures de pratique par semaine.
2. 2Semaine 1 — comprendre et lancer — Explorez l’onglet Actions, repérez la structure d’un workflow YAML et faites tourner un premier workflow déclenché par un push. Apprenez à consulter les journaux.
3. 3Semaine 2 — modifier et diagnostiquer — Testez deux événements, ajoutez une commande de vérification et provoquez un échec contrôlé. Lisez son journal, corrigez la cause et vérifiez le résultat.
4. 4Semaine 3 — automatiser un cas utile — Dans une branche de travail, créez un workflow qui lance les tests ou un contrôle pertinent lors d’une pull request. Vérifiez un cas qui réussit et un cas qui échoue.
5. 5Semaine 4 — finaliser et présenter — Nettoyez et documentez le workflow, vérifiez son comportement, puis terminez un dépôt de démonstration que vous pouvez expliquer. Notez ce qui reste à apprendre.

Formations et programmes au Maroc

Compétences clés

Questions fréquentes

Sources

1. FormaGroup — Technologie GitHub Actions formagroup.ma
2. GitHub Skills — Hello GitHub Actions github.com
3. GitHub Docs — GitHub Actions docs.github.com
4. JobInTech jobintech.academy
5. Ministère de la Transition Numérique et de la Réforme de l’Administration — Upskilling et reskilling mmsp.gov.ma