Qu’est-ce que GitHub Actions ?
Section intitulée « Qu’est-ce que GitHub Actions ? »GitHub Actions est la plateforme d’automatisation CI/CD (Continuous Integration / Continuous Delivery) intégrée nativement à GitHub. Lancée en 2019, elle permet d’exécuter automatiquement du code en réponse à des événements sur votre repository.
Concrètement, GitHub Actions vous permet de :
- Automatiser les tests — À chaque push ou pull request, vos tests s’exécutent automatiquement
- Construire et publier — Compilez votre code, créez des images Docker, publiez sur npm ou PyPI
- Déployer — Déployez automatiquement sur AWS, Azure, GCP, Kubernetes, ou votre propre infrastructure
- Maintenir votre code — Vérifiez le formatage, analysez la sécurité, mettez à jour les dépendances
- Orchestrer des tâches — Planifiez des actions récurrentes, réagissez aux issues ou aux releases
Comment ça fonctionne ?
Section intitulée « Comment ça fonctionne ? »Tout repose sur des workflows : des fichiers YAML placés dans le dossier
.github/workflows/ de votre repository. Chaque workflow définit :
- Quand s’exécuter (push, pull request, schedule, manuellement…)
- Quoi faire (une série de tâches appelées jobs et steps)
- Où le faire (sur des machines virtuelles appelées runners)
# Exemple minimal d'un workflowname: Tests
on: [push, pull_request]
jobs: test: runs-on: ubuntu-24.04 steps: - uses: actions/checkout@v4 - run: npm testQuand vous poussez du code, GitHub détecte automatiquement les workflows, provisionne une machine virtuelle, exécute vos tâches, et vous affiche les résultats dans l’interface.
Le Marketplace : un écosystème d’actions
Section intitulée « Le Marketplace : un écosystème d’actions »Une des forces de GitHub Actions est son Marketplace : des milliers d’actions prêtes à l’emploi créées par la communauté et les éditeurs. Plutôt que de réécrire la logique pour “déployer sur AWS” ou “envoyer une notification Slack”, vous utilisez une action existante.
Mais attention : utiliser une action, c’est exécuter du code tiers avec accès à vos secrets. La sécurité de votre pipeline dépend de la confiance que vous accordez à ces actions. C’est pourquoi la formation insiste sur l’épinglage SHA et la vérification des sources.
Combien ça coûte ?
Section intitulée « Combien ça coûte ? »GitHub Actions propose un modèle gratuit avec quotas qui convient à la majorité des projets :
| Type de repository | Quota mensuel gratuit | Au-delà |
|---|---|---|
| Public | Illimité | — |
| Privé (compte gratuit) | 2 000 minutes | Facturation à la minute |
| Privé (Team) | 3 000 minutes | Facturation à la minute |
| Privé (Enterprise) | 50 000 minutes | Facturation à la minute |
Ce qui consomme des minutes
Section intitulée « Ce qui consomme des minutes »Les minutes sont comptées différemment selon le type de runner :
| Runner | Multiplicateur | Exemple : 10 min réelles |
|---|---|---|
| Linux (ubuntu-*) | ×1 | 10 minutes facturées |
| Windows | ×2 | 20 minutes facturées |
| macOS | ×10 | 100 minutes facturées |
Comment suivre sa consommation ?
Section intitulée « Comment suivre sa consommation ? »Allez dans Settings → Billing and plans → Plans and usage pour voir votre consommation actuelle. Vous pouvez aussi configurer des alertes pour éviter les surprises.
Pour les projets open source, tout est gratuit et illimité. C’est une des raisons pour lesquelles GitHub Actions est devenu le standard de facto pour la CI/CD des projets open source.
Pourquoi cette formation ?
Section intitulée « Pourquoi cette formation ? »Vous avez un projet GitHub. À chaque modification, vous lancez les tests à la main, vous déployez en copiant des fichiers, vous vérifiez manuellement que rien n’est cassé. Ce temps perdu s’accumule, et les erreurs humaines finissent par passer.
GitHub Actions résout ce problème. Mais GitHub Actions ne se résume pas à “lancer les tests automatiquement”. C’est un outil puissant qui, mal maîtrisé, peut devenir une source de dette technique, de failles de sécurité, et de workflows impossibles à maintenir.
Cette formation vous amène du premier workflow à une CI/CD sécurisée de niveau professionnel. Pas de raccourcis, pas de copier-coller aveugle : vous comprendrez chaque concept pour prendre les bonnes décisions.
Prérequis
Section intitulée « Prérequis »Pour suivre cette formation, vous devez avoir un compte GitHub (gratuit), connaître les bases de Git (clone, commit, push, branches, pull requests), et être à l’aise avec la ligne de commande.
Aucune expérience préalable en CI/CD n’est requise. Nous partons de zéro et nous construisons progressivement.
Ce que vous saurez faire à la fin
Section intitulée « Ce que vous saurez faire à la fin »Au terme de cette formation, vous serez capable de :
Construire des workflows — Vous maîtriserez la syntaxe YAML, les événements déclencheurs, les conditions d’exécution, et les stratégies de parallélisation. Vos workflows seront lisibles, maintenables et adaptés à vos besoins réels.
Sécuriser vos pipelines — C’est le cœur de la formation. Vous apprendrez à configurer les permissions minimales, épingler les actions par SHA, utiliser OIDC pour éviter les secrets statiques, et comprendre les risques des PRs de forks. Vous saurez auditer un workflow existant et identifier les failles.
Optimiser les performances — Vous saurez utiliser le cache intelligemment, partager des artefacts entre jobs, et réduire le temps d’exécution de vos pipelines de plusieurs minutes. Chaque seconde compte quand vous attendez le feedback de vos tests.
Gérer les runners — Vous comprendrez la différence entre runners GitHub-hosted et self-hosted, quand utiliser chaque option, et comment sécuriser votre infrastructure d’exécution. Vous saurez mettre en place des runners éphémères pour les environnements sensibles.
Le parcours de formation
Section intitulée « Le parcours de formation »La formation suit une progression logique. Chaque module s’appuie sur les précédents pour construire vos compétences pas à pas.
Module 1 · Fondations
C’est quoi un workflow ? Où le mettre ? Comment ça marche ?
Vous découvrirez la structure des fichiers YAML, les événements déclencheurs, la gestion des secrets, et les premiers réflexes de sécurité.
Module 2 · Workflows avancés
Matrix, workflows réutilisables, actions composites
Testez sur plusieurs OS en parallèle, factorisez votre code, et créez des patterns réutilisables dans toute votre organisation.
Module 3 · Sécurité
Le module le plus important de la formation
Permissions minimales, épinglage SHA, OIDC, risques des forks, framework SLSA. Transformez vos workflows amateurs en pipelines professionnels.
Module 4 · Optimisation
Divisez par 5 le temps de vos pipelines
Cache intelligent, artefacts, concurrency, debug local avec act.
Chaque seconde compte quand toute l’équipe attend le feedback CI.
Module 5 · Runners
Maîtrisez votre infrastructure d’exécution
Runners hosted vs self-hosted, runners éphémères, scaling avec ARC sur Kubernetes. Pour les cas d’usage avancés.
Conclusion
Section intitulée « Conclusion »GitHub Actions est bien plus qu’un outil pour “lancer des tests automatiquement”. C’est une plateforme puissante qui, bien maîtrisée, transforme votre façon de livrer du logiciel.
Cette formation vous donne les clés pour :
- Gagner du temps — Automatisez les tâches répétitives et concentrez-vous sur ce qui compte : écrire du bon code
- Réduire les erreurs — Les machines ne font pas d’erreurs d’inattention, et vos déploiements deviennent prévisibles
- Sécuriser votre supply chain — Dans un monde où les attaques sur les pipelines CI/CD explosent, vous saurez vous protéger
- Travailler en équipe — Des workflows lisibles, maintenables, et que tout le monde peut comprendre et faire évoluer
La documentation officielle GitHub et le Marketplace sont vos ressources complémentaires. Mais rien ne remplace la pratique : expérimentez, cassez des choses, comprenez pourquoi ça casse. C’est comme ça qu’on apprend vraiment.
FAQ : Questions Fréquentes
Section intitulée « FAQ : Questions Fréquentes »GitHub Actions est une plateforme d'automatisation CI/CD intégrée à GitHub. Elle permet d'exécuter automatiquement du code (tests, builds, déploiements) en réponse à des événements sur votre repository : push, pull request, release, ou planning horaire.
GitHub Actions est gratuit pour les repositories publics. Pour les repositories privés, GitHub offre un quota mensuel gratuit (2000 minutes/mois pour les comptes gratuits), au-delà duquel des frais s'appliquent. Les runners self-hosted sont gratuits en illimité.
Les workflows doivent être placés dans le dossier .github/workflows/ à la racine de votre repository. Les fichiers doivent avoir l'extension .yml ou .yaml. GitHub détecte automatiquement tous les fichiers de ce dossier.
Un job est une unité de travail qui s'exécute sur une machine virtuelle dédiée (runner). Les steps sont les tâches individuelles à l'intérieur d'un job. Les jobs s'exécutent en parallèle par défaut, tandis que les steps s'exécutent séquentiellement sur la même machine.
Les bonnes pratiques essentielles sont : déclarer les permissions minimales avec permissions:, épingler les actions par SHA complet plutôt que par tag, ne jamais stocker de secrets dans le code, utiliser les environnements avec approbation pour la production, et éviter pull_request_target sauf si vous comprenez les risques.
Les tags comme @v4 sont mutables : le mainteneur peut les modifier à tout moment. Si l'action est compromise, votre workflow exécutera du code malveillant. Un SHA complet comme @11bd71901bbe5b1630ceea73d27597364c9af683 pointe vers une version exacte et immuable du code.
Utilisez les actions actions/upload-artifact et actions/download-artifact. Chaque job s'exécute sur une machine différente, donc les fichiers ne sont pas partagés automatiquement. Les artifacts persistent pendant 90 jours par défaut.
Un runner est la machine virtuelle qui exécute vos jobs. GitHub propose des runners hébergés (Ubuntu, Windows, macOS) prêts à l'emploi. Vous pouvez aussi configurer des runners self-hosted sur votre propre infrastructure pour des besoins spécifiques (GPU, réseau interne, conformité).
Les alias comme ubuntu-24.04 pointent vers une version qui change sans prévenir quand GitHub met à jour ses runners. Un jour votre workflow fonctionne, le lendemain il casse. Utilisez une version explicite comme ubuntu-24.04 pour des builds reproductibles.
Ajoutez le déclencheur workflow_dispatch dans la section on: de votre workflow. Cela ajoute un bouton 'Run workflow' dans l'interface GitHub Actions. Vous pouvez aussi définir des inputs pour passer des paramètres au lancement.
Les secrets se créent dans Settings → Secrets and variables → Actions. Dans le workflow, utilisez la syntaxe ${{ secrets.NOM_DU_SECRET }}. GitHub masque automatiquement les secrets dans les logs avec ***.
Les secrets sont chiffrés, masqués dans les logs, et ne peuvent jamais être relus après création. Utilisez-les pour les tokens, mots de passe et clés API. Les variables sont en clair, visibles dans les logs, et servent à la configuration publique (versions, URLs, flags).
Utilisez l'outil act qui simule l'exécution de GitHub Actions sur votre machine avec Docker. Attention : toutes les fonctionnalités ne sont pas supportées (notamment les secrets GitHub, certains événements, et les runners macOS/Windows).
Utilisez le cache pour les dépendances (actions/cache), exécutez les jobs en parallèle quand c'est possible, filtrez les déclencheurs avec paths: pour éviter les exécutions inutiles, et configurez concurrency pour annuler les runs obsolètes.
Non, par défaut les workflows déclenchés par des PRs venant de forks n'ont pas accès aux secrets du repository cible. C'est une protection de sécurité importante. Le déclencheur pull_request_target contourne cette protection et doit être utilisé avec précaution.