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.
Les incidents de 2025-2026 le démontrent mieux qu'un argument. La compromission
de tj-actions/changed-files, une action utilisée par plus de 23 000 dépôts,
a recopié les secrets des workflows qui l'exécutaient dans leurs logs
publics. GhostAction a volé 3 325 secrets dans 817 dépôts. Shai Hulud
v2 s'est propagé à 796 paquets npm. Et dans la nuit du 1er mars 2026, le dépôt
de Trivy a été vidé après qu'un bot IA autonome a exploité un workflow
vulnérable.
Aucune de ces attaques n'a eu besoin d'une faille inconnue (zero-day). Elles
sont passées par des portes que vous contrôlez : un pull_request_target mal
sécurisé, des tags mutables, des permissions trop larges, une injection de
commande et une sortie réseau sans contrôle. Le détail de chaque cas est dans
l'analyse des attaques.
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.
À retenir
Section intitulée « À retenir »Ce que cette page installe est moins une liste de fonctionnalités qu'une priorité : la sécurité s'apprend dès le premier workflow, parce que c'est là que les incidents commencent.
- Un workflow est un fichier YAML de
.github/workflows/qui dit quand s'exécuter, quoi faire et où. - Les dépôts publics et les runners self-hosted tournent gratuitement ; tout le reste puise dans un quota mensuel.
- Les attaques de 2025-2026 n'ont utilisé aucune zero-day : elles sont passées par des portes que vous contrôlez.
- Ces portes sont
pull_request_target, les tags mutables, les permissions larges, l'injection de commande et la sortie réseau libre. - Le premier geste le plus rapide est la checklist sécurité : quinze minutes sur vos propres workflows.
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.