Cette formation vous amène du premier workflow à une chaîne d'approvisionnement vérifiable : écrire un workflow, gérer des secrets, épingler les actions tierces, remplacer les clés cloud par OIDC, signer ce que vous publiez, choisir et durcir vos runners. Elle s'adresse aux développeurs et aux équipes DevOps ou DevSecOps qui partent de zéro ou qui héritent de pipelines écrits à la va-vite. Sa particularité tient en une phrase : la sécurité n'est pas un chapitre final, elle contraint chaque exemple dès le premier workflow.
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@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1 - 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 est gratuit dans deux situations qui couvrent une bonne part des usages : les dépôts publics sur les runners standard, et les runners self-hosted, quelle que soit la visibilité du dépôt. Le reste consomme un quota mensuel inclus, puis se facture à la minute.
| Plan | Minutes incluses par mois |
|---|---|
| GitHub Free | 2 000 |
| GitHub Pro | 3 000 |
| GitHub Team | 3 000 |
| GitHub Enterprise Cloud | 50 000 |
Au-delà du quota : un tarif par machine
Section intitulée « Au-delà du quota : un tarif par machine »L'ancien modèle des multiplicateurs (une minute Windows comptée double, une minute macOS comptée dix fois) a disparu de la documentation GitHub au profit d'une grille de prix par SKU. Chaque type de runner porte désormais son propre tarif à la minute :
| Runner standard | Tarif à la minute |
|---|---|
| Linux 2 cœurs (x64) | 0,006 $ |
| Linux 2 cœurs (arm64) | 0,005 $ |
| Windows 2 cœurs (x64) | 0,010 $ |
| macOS 3 ou 4 cœurs | 0,062 $ |
L'ordre de grandeur ne change pas, une minute macOS coûte toujours environ dix fois une minute Linux. Ce qui change, c'est la lecture : le prix se lit directement, et la même grille couvre les larger runners (4 cœurs et plus) et les runners GPU, facturés nettement plus cher.
La sortie de secours : les runners self-hosted
Section intitulée « La sortie de secours : les runners self-hosted »Les runners self-hosted (machines que vous gérez vous-même) ne consomment aucune minute du quota GitHub, et l'usage d'Actions y est gratuit. C'est l'option économique pour les gros volumes ou les besoins spécifiques (GPU, réseau interne). La contrepartie n'est pas financière mais sécuritaire : vous héritez de l'isolation, du durcissement et du cycle de vie de ces machines, sujet traité dans le module consacré aux runners.
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.
Écrire son premier workflow
C'est quoi un workflow ? Où le mettre ? Comment ça marche ?
La structure des fichiers YAML, les événements déclencheurs, la gestion des secrets, et les premiers réflexes de sécurité posés dès le départ.
Concevoir des workflows dynamiques
Contexts, conditions, matrices, workflows réutilisables
Tester sur plusieurs versions en parallèle, factoriser une CI qui s'adapte à la branche et à l'événement, créer des actions composites.
Défendre la chaîne d'approvisionnement
Le cœur de la formation
Attaques réelles, épinglage SHA, zizmor et poutine, permissions minimales, OIDC, attestations de provenance et durcissement du runner.
Lab : un pipeline durci de bout en bout
Cinq ateliers sur un dépôt public reproductible
Bootstrap gouverné, CI à zéro finding, build attesté SLSA signé Cosign, ruleset de branche, puis note OpenSSF Scorecard décortiquée.
Livrer : environnements et déploiements
Une CI verte n'autorise pas à déployer
Environnements, approbation humaine, promotion d'un artefact par digest, releases et images GHCR, rollback et concurrence.
Accélérer, puis choisir ses runners
Cache, artefacts, concurrency, puis l'infrastructure d'exécution
Diagnostiquer un pipeline lent, couper les exécutions inutiles, puis arbitrer entre runners hébergés et auto-hébergés, jusqu'aux runners éphémères.
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/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.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.@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.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.ubuntu-latest 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.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.${{ secrets.NOM_DU_SECRET }}. GitHub masque automatiquement les secrets dans les logs avec ***.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).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.pull_request_target contourne cette protection et doit être utilisé avec précaution.