01
Introduction Technique
GitHub Actions est la plateforme d'automatisation CI/CD native intégrée à GitHub. Elle permet de définir, dans des fichiers YAML versionnés au sein même du dépôt, des workflows répondant à tout événement GitHub : push, pull request, release, planification, ou déclenchement manuel. Les workflows s'exécutent sur des runners — machines éphémères hébergées par GitHub ou auto-hébergées — qui orchestrent des séquences de jobs composés de steps.
L'architecture événementielle de GitHub Actions élimine tout serveur CI externe. La définition des pipelines est colocalisée avec le code source, assurant une traçabilité totale, une revue de code des pipelines eux-mêmes, et une cohérence entre le cycle de vie du code et celui des automatisations.
◉GitHub Actions facture à la minute d'exécution sur runners hébergés. Les runners Linux sont 2× moins chers que Windows, et les runners macOS 10× plus chers. Les dépôts publics bénéficient de minutes illimitées gratuites.
⬡Modèle Événement → Workflow → Job → Step
┌────────────────────────────────────────────────────────────────────┐
│ MODÈLE ÉVÉNEMENT → WORKFLOW → JOB → STEP │
└────────────────────────────────────────────────────────────────────┘
DÉPÔT GIT
┌─────────────────────────────────────────────────────────────────┐
│ git push origin main │
│ → Event: push (ref: refs/heads/main) ① │
└──────────────────────────┬──────────────────────────────────────┘
│
▼
WORKFLOW (.github/workflows/ci.yml)
┌─────────────────────────────────────────────────────────────────┐
│ on: push │
│ branches: [main] │
│ ② N Jobs instanciés │
│ ┌─────────────────┐ ┌─────────────────┐ ┌──────────────┐ │
│ │ Job: build │ │ Job: test │ │ Job: deploy │ │
│ │ (runs-on: │ │ (needs: build) │ │ (needs: test)│ │
│ │ ubuntu-latest) │ │ │ │ │ │
│ └────────┬────────┘ └────────┬────────┘ └──────┬───────┘ │
└───────────┼──────────────────────┼──────────────────┼──────────┘
│ ③ Runner │ │
▼ ▼ ▼
┌───────────────────┐ ┌───────────────────┐ ┌────────────────┐
│ Runner Ubuntu │ │ Runner Ubuntu │ │ Runner Ubuntu │
│ ④ Steps : │ │ ④ Steps : │ │ ④ Steps : │
│ 1. checkout │ │ 1. checkout │ │ 1. checkout │
│ 2. setup-node │ │ 2. npm test │ │ 2. deploy.sh │
│ 3. npm install │ │ 3. upload report │ │ │
│ 4. npm run build │ │ │ │ │
│ 5. upload artifact│ │ │ │ │
└───────────────────┘ └───────────────────┘ └────────────────┘
Jobs build et test : PARALLÈLES (pas de needs commun)
Job deploy : SÉQUENTIEL (needs: [test])
Légende — ① Événement déclenche le workflow → ② Le workflow instancie N jobs → ③ Chaque job s'exécute sur un runner → ④ Les steps s'enchaînent séquentiellement dans le job
02
Architecture Conceptuelle
GitHub Actions s'articule autour de quatre couches : la couche événementielle (triggers), la couche d'orchestration (workflows/jobs), la couche d'exécution (runners), et la couche d'actions (composants réutilisables). Ces couches interagissent via l'API GitHub et le protocole de communication runner.
⬡Architecture Globale GitHub Actions — Couches et Interactions
┌────────────────────────────────────────────────────────────────────┐
│ ARCHITECTURE GITHUB ACTIONS │
└────────────────────────────────────────────────────────────────────┘
GITHUB PLATFORM
┌────────────────────────────────────────────────────────────────┐
│ │
│ ① Events ② Actions Service │
│ ┌─────────────────┐ ┌─────────────────────────────────┐ │
│ │ push │────►│ Workflow Engine │ │
│ │ pull_request │ │ ┌────────────────────────────┐ │ │
│ │ schedule │ │ │ Parser YAML │ │ │
│ │ workflow_dispatch│ │ │ DAG resolver (needs:) │ │ │
│ │ release │ │ │ Matrix expansion │ │ │
│ │ repository_dispatch│ │ │ Context injection │ │ │
│ └─────────────────┘ │ └────────────────────────────┘ │ │
│ └────────────┬────────────────────┘ │
│ │ ④ Job dispatch │
│ ⑤ Storage │ │
│ ┌─────────────────┐ ▼ │
│ │ Artifacts store │ ┌──────────────────────────────────┐ │
│ │ Cache store │◄───│ Runner Registration Service │ │
│ │ (S3-like) │ │ ③ runners poll via HTTPS │ │
│ └─────────────────┘ └──────────────────────────────────┘ │
└────────────────────────────────────────────────────────────────┘
│
┌─────────────────────┼─────────────────────┐
▼ ▼ ▼
┌──────────────────┐ ┌──────────────────┐ ┌──────────────────┐
│ GitHub-Hosted │ │ Self-Hosted │ │ Larger Runners │
│ Runner │ │ Runner │ │ (4-64 cores) │
│ ubuntu-latest │ │ On-premise │ │ GPU-enabled │
│ windows-latest │ │ Cloud (EC2/GKE) │ │ Custom images │
│ macos-latest │ │ Kubernetes │ │ Private network │
└──────────────────┘ └──────────────────┘ └──────────────────┘
│ │
└──────────┬──────────┘
│ ⑥ Status + Logs
▼
┌──────────────────────┐
│ GitHub UI / API │
│ Actions tab │
│ PR checks │
│ Deployment API │
└──────────────────────┘
Légende — ① Events API → ② Workflow engine (Actions service) → ③ Runner registration → ④ Job dispatch → ⑤ Artifacts/Cache store → ⑥ Status reporting
⬡Cycle de Vie d'un Workflow Run — États et Transitions
┌────────────────────────────────────────────────────────────────────┐
│ CYCLE DE VIE D'UN WORKFLOW RUN │
└────────────────────────────────────────────────────────────────────┘
Event triggered
│
▼
┌──────────┐ ① ┌──────────────┐ ② ┌────────────────┐
│ Queued │─────────►│ In Progress │──────────►│ Completed │
└──────────┘ └──────────────┘ │ │
│ ✅ success │
│ runner offline │ ❌ failure │
▼ │ ⚠ cancelled │
┌──────────────┐ │ ⏭ skipped ④ │
│ Waiting ⑤ │ └────────────────┘
│ (env review) │
└──────────────┘
CONCLUSION D'UN JOB :
─────────────────────────────────────────────────────────────────
result → success | failure | cancelled | skipped
outcome → idem (avant continue-on-error)
conclusion → idem (après continue-on-error)
ÉTATS D'UN STEP :
─────────────────────────────────────────────────────────────────
✅ success → step exécuté sans erreur (exit code 0)
❌ failure → step échoué (exit code ≠ 0)
⏭ skipped → condition if: évaluée false
⏱ cancelled → workflow annulé pendant l'exécution
ENCHAÎNEMENT CONDITIONNEL :
─────────────────────────────────────────────────────────────────
if: success() → défaut, step précédent OK
if: failure() → exécuter si échec précédent
if: always() → toujours exécuter (cleanup)
if: cancelled() → si workflow annulé
if: steps.build.outcome == 'success' → état step précis
Légende — ① Queued → ② In Progress → ③ Completed (success/failure/cancelled) | ④ Skipped si condition if: false | ⑤ Waiting si environment protection rule
03
Concepts Fondamentaux
La compréhension approfondie de GitHub Actions repose sur six primitives : les Workflows, les Jobs, les Steps, les Actions, les Contexts et les Secrets/Variables. Leur interaction structure l'intégralité des pipelines CI/CD.
.github/workflows/ci-cd.yml — Workflow complet annoté
▋⬡Stratégie Matrix — Parallélisation Multi-Combinaisons
┌────────────────────────────────────────────────────────────────────┐
│ STRATÉGIE MATRIX — PARALLÉLISATION │
└────────────────────────────────────────────────────────────────────┘
DÉFINITION ①
┌──────────────────────────────────────────────────────────────┐
│ strategy: │
│ fail-fast: false │
│ matrix: │
│ os: [ubuntu-latest, windows-latest, macos-latest] │
│ node: [18, 20, 22] │
│ exclude: │
│ - os: windows-latest │
│ node: 18 │
│ include: │
│ - os: ubuntu-latest │
│ node: 22 │
│ experimental: true │
└──────────────────────────────────────────────────────────────┘
│
▼ ② Expansion automatique (8 jobs)
┌──────────────────────────────────────────────────────────────┐
│ │
│ ubuntu / node18 ──► ✅ ubuntu / node20 ──► ✅ │
│ ubuntu / node22 ──► ✅ windows / node20 ──► ✅ │
│ windows / node22 ──► ✅ macos / node18 ──► ✅ │
│ macos / node20 ──► ✅ macos / node22 ──► ✅ │
│ │
│ ③ Exécution en PARALLÈLE sur runners indépendants │
└──────────────────────────────────────────────────────────────┘
│
▼ ④ Agrégation
┌──────────────────────────────────────────────────────────────┐
│ Job parent attend completion de tous les jobs matrix │
│ needs: [test-matrix] │
│ → success si tous success (ou fail-fast: false) │
└──────────────────────────────────────────────────────────────┘
Légende — ① Définition de la matrix → ② Expansion en N jobs → ③ Exécution parallèle → ④ Agrégation des résultats | fail-fast: true arrête tout si un job échoue
⬡Contextes GitHub Actions — Variables et Scopes
┌────────────────────────────────────────────────────────────────────┐
│ CONTEXTES GITHUB ACTIONS │
└────────────────────────────────────────────────────────────────────┘
① CONTEXTES DISPONIBLES
──────────────────────────────────────────────────────────────────
github.* Métadonnées du run et du dépôt
┌──────────────────────────────────────────────────────────────┐
│ github.sha → commit SHA (abc123...) │
│ github.ref → refs/heads/main │
│ github.event_name → push | pull_request | ... │
│ github.actor → username déclencheur │
│ github.repository → org/repo │
│ github.run_id → ID unique du run │
└──────────────────────────────────────────────────────────────┘
env.* Variables d'environnement (workflow/job/step)
secrets.* Secrets chiffrés (masqués dans les logs)
vars.* Variables de configuration (non sensibles)
inputs.* Inputs workflow_dispatch / workflow_call
steps.<id>.* Sorties des steps précédents
② EXPRESSION SYNTAX
──────────────────────────────────────────────────────────────────
{{github.sha }} → valeur simple
{{secrets.DOCKER_PASSWORD }} → secret injecté
{{env.NODE_VERSION }} → variable env
{{steps.build.outputs.version }} → output d'un step
{{matrix.os }} → valeur matrix courante
③ PRIORITÉ (du plus spécifique au plus général)
──────────────────────────────────────────────────────────────────
Step env → Job env → Workflow env → Repository vars
Légende — ① Contextes disponibles dans les expressions ${{ }} → ② Priorité de résolution → ③ Scopes d'accès selon la position dans le YAML
Reusable Workflow — Définition et appel
▋04
Architecture Technique Détaillée
L'infrastructure d'exécution de GitHub Actions repose sur des runners qui établissent une connexion HTTPS longue durée (long-polling) avec le service Actions de GitHub. Le runner récupère les jobs via ce canal, les exécute dans un environnement isolé, et remonte les logs en temps réel.
⬡Runners GitHub-Hosted — Spécifications et Environnements
┌────────────────────────────────────────────────────────────────────┐ │ RUNNERS GITHUB-HOSTED — SPÉCIFICATIONS │ └────────────────────────────────────────────────────────────────────┘ TYPE OS IMAGE vCPU RAM STOCKAGE ────────────────────────────────────────────────────────────────── ubuntu-latest Ubuntu 24.04 LTS 2 7 GB 14 GB SSD ubuntu-22.04 Ubuntu 22.04 LTS 2 7 GB 14 GB SSD windows-latest Windows Server 2022 2 7 GB 14 GB SSD macos-latest macOS 14 Sonoma 3 14 GB 14 GB SSD macos-13 macOS 13 Ventura 3 14 GB 14 GB SSD PLUS GRANDS RUNNERS (GitHub Team/Enterprise) ────────────────────────────────────────────────────────────────── ubuntu-4-cores 4 vCPU 16 GB 100 GB ubuntu-8-cores 8 vCPU 32 GB 100 GB ubuntu-16-cores 16 vCPU 64 GB 100 GB ubuntu-64-cores 64 vCPU 256 GB 2000 GB OUTILS PRÉ-INSTALLÉS (ubuntu-latest) ────────────────────────────────────────────────────────────────── ① Docker Engine (BuildKit activé) ④ Node.js (NVM) ① kubectl, helm ④ Python, Java, Go, .NET ① aws-cli, azure-cli, gcloud ④ git, jq, curl, wget ② Réseau : IP publique éphémère ⑤ ~500 outils courants ISOLATION ③ ────────────────────────────────────────────────────────────────── Chaque job → VM fraîche (image snapshot restaurée) Durée max → 6h (standard) / 35 jours (self-hosted) Workspace → /home/runner/work/<repo>/<repo>/ Nettoyage → automatique post-job (aucune persistance)
Légende — ① Image de base préconfigurée → ② Réseau isolé éphémère → ③ Filesystem nettoyé après chaque job → ④ 2 vCPU / 7GB RAM (standard)
⬡Self-Hosted Runners — Architecture et Modes de Déploiement
┌────────────────────────────────────────────────────────────────────┐ │ SELF-HOSTED RUNNERS — ARCHITECTURE │ └────────────────────────────────────────────────────────────────────┘ MODE VM / BARE METAL ┌────────────────────────────────────────────────────────────────┐ │ ① Runner Agent (./run.sh) │ │ │ │ │ │ HTTPS long-polling → api.github.com/actions/runner │ │ │ │ │ ▼ ② Job assigné (JITC = Just-In-Time Config) │ │ ┌──────────────────────────────────────────────────────────┐ │ │ │ Worker process │ │ │ │ → télécharge actions depuis github.com │ │ │ │ → exécute steps dans le répertoire workspace │ │ │ │ → stream logs vers GitHub │ │ │ └──────────────────────────────────────────────────────────┘ │ └────────────────────────────────────────────────────────────────┘ MODE KUBERNETES — Actions Runner Controller (ARC) ⑤ ┌────────────────────────────────────────────────────────────────┐ │ ┌─────────────────────────────────────────────────────────┐ │ │ │ ARC Controller (Deployment) │ │ │ │ Watches RunnerSet CRD │ │ │ └─────────────────────┬───────────────────────────────────┘ │ │ │ crée │ │ ▼ │ │ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ │ │ │ Runner │ │ Runner │ │ Runner │ │ Runner │ │ │ │ Pod 1 │ │ Pod 2 │ │ Pod 3 │ │ Pod N │ │ │ │(ephémère)│ │(ephémère)│ │(ephémère)│ │ auto- │ │ │ └──────────┘ └──────────┘ └──────────┘ │ scale │ │ │ └──────────┘ │ │ Autoscaling : 0 → N pods selon la charge de la queue │ └────────────────────────────────────────────────────────────────┘ LABELS RUNNERS (ciblage dans workflows) ────────────────────────────────────────────────────────────────── runs-on: [self-hosted, linux, x64, gpu] runs-on: [self-hosted, production, high-memory]
Légende — ① Runner agent poll GitHub → ② Job assigné via JITC → ③ Exécution dans l'environnement local → ④ Résultats postés → ⑤ Kubernetes Actions Runner Controller (ARC)
05
Mise en Place
Premier workflow — CI Node.js de référence
▋Self-hosted runner — Installation sur Ubuntu
▋06
Configuration
Environments — Protection rules et déploiement contrôlé
▋⬡Gestion des Secrets — Hiérarchie et Scopes
┌────────────────────────────────────────────────────────────────────┐
│ HIÉRARCHIE DES SECRETS ET VARIABLES │
└────────────────────────────────────────────────────────────────────┘
ORGANISATION (github.com/org)
┌─────────────────────────────────────────────────────────────────┐
│ ② Secrets d'organisation │
│ DOCKER_HUB_TOKEN, NPM_TOKEN, SLACK_WEBHOOK │
│ Visibilité : tous repos | repos sélectionnés | repos privés │
│ │
│ ┌──────────────────────────────────────────────────────────┐ │
│ │ REPOSITORY (github.com/org/repo) │ │
│ │ │ │
│ │ ① Secrets de repository │ │
│ │ KUBE_CONFIG_DEV, API_KEY_STG │ │
│ │ │ │
│ │ ┌────────────────────────────────────────────────────┐ │ │
│ │ │ ENVIRONMENT: production │ │ │
│ │ │ │ │ │
│ │ │ ③ Secrets d'environnement │ │ │
│ │ │ KUBE_CONFIG_PROD (surcharge le secret repo) │ │ │
│ │ │ DB_PASSWORD_PROD │ │ │
│ │ │ │ │ │
│ │ │ Protection rules : │ │ │
│ │ │ • Required reviewers (2 personnes min) │ │ │
│ │ │ • Wait timer: 5 minutes │ │ │
│ │ │ • Allowed branches: main, release/* │ │ │
│ │ └────────────────────────────────────────────────────┘ │ │
│ └──────────────────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────────────┘
ACCÈS DANS LES WORKFLOWS :
{{secrets.DOCKER_HUB_TOKEN }} → org ou repo
{{secrets.KUBE_CONFIG_PROD }} → environment (si job dans env production)
{{vars.NODE_VERSION }} → variable non sensible (visible dans logs)
Légende — ① Secret repo → accessible par tous les workflows du repo ② Secret org → partageable entre repos ③ Secret environment → limité à un environnement déploiement
07
Cas d'Usage Professionnels
⬡Pipeline CI/CD Complet — Build, Test, Scan, Push, Deploy
┌────────────────────────────────────────────────────────────────────┐
│ PIPELINE CI/CD PRODUCTION — GITHUB ACTIONS │
└────────────────────────────────────────────────────────────────────┘
TRIGGER: push to main / tag v*.*.*
────────────────────────────────────────────────────────────────
┌──────────────────────────────────────────────────────────────┐
│ JOB: build ① │
│ docker buildx build --platform linux/amd64,linux/arm64 │
│ → ghcr.io/org/app:{{github.sha }} │
└──────────────────────────────────┬───────────────────────────┘
│ needs: build
┌─────────────────────┼─────────────────────┐
▼ ▼ ▼
┌────────────────────┐ ┌────────────────────┐ ┌────────────────────┐
│ JOB: unit-tests ②│ │ JOB: integration ②│ │ JOB: security-scan③│
│ npm test │ │ docker compose up │ │ trivy image │
│ --coverage │ │ npm run test:int │ │ docker scout cves │
│ Upload: Codecov │ │ │ │ SARIF → GitHub │
└──────────┬─────────┘ └──────────┬──────────┘ └─────────┬──────────┘
└─────────────────┬─────┘ │
needs: [unit-tests, integration, │
security-scan] │
└──────────────────────────────┘
│
▼
┌──────────────────────┐
│ JOB: push-registry ④│
│ docker push │
│ cosign sign │
│ sbom attest │
└──────────┬────────────┘
│
┌──────────▼────────────┐
│ JOB: deploy-staging ⑤│
│ helm upgrade staging │
│ environment: staging │
└──────────┬────────────┘
│
┌──────────▼────────────┐
│ JOB: smoke-tests ⑥ │
│ curl health endpoints │
│ playwright e2e subset │
└──────────┬────────────┘
│ only on tag v*
┌──────────▼────────────┐
│ JOB: deploy-prod ⑦ │
│ environment: production│
│ ⏳ Manual approval │
│ helm upgrade prod │
└───────────────────────┘
Légende — ① Build multi-arch → ② Tests parallèles → ③ Scan sécurité → ④ Push registry → ⑤ Deploy staging → ⑥ Smoke tests → ⑦ Deploy production (avec review)
OIDC — Authentification AWS sans secret statique
▋08
Bonnes Pratiques Professionnelles
🔒
Épingler les actions par SHA
Référencer les actions par commit SHA plutôt que par tag. Les tags mutables (v3, @main) exposent aux attaques de supply chain.
🪪
OIDC plutôt que secrets statiques
Utiliser les tokens OIDC éphémères pour AWS, Azure, GCP. Élimine la rotation manuelle des credentials long-lived.
🎯
Permissions minimales
Définir permissions: au niveau workflow et job. Principe du moindre privilège : contents: read par défaut.
♻️
Reusable Workflows
Centraliser les pipelines communs en workflows réutilisables. Évite la duplication YAML et uniformise les pratiques CI/CD.
⚡
Cache des dépendances
Utiliser actions/cache ou le cache intégré de setup-node/setup-python. Réduit le temps de build de 50-80% sur les dépendances.
🔐
Concurrency groups
Définir concurrency: par branche/PR pour annuler les runs obsolètes. Évite les déploiements concurrents sur le même environnement.
Bonnes pratiques — SHA pinning + permissions + concurrency
▋09
Anti-patterns et Erreurs Fréquentes
⬡Anti-patterns GitHub Actions — Catalogue de Référence
┌────────────────────────────────────────────────────────────────────┐
│ ANTI-PATTERNS GITHUB ACTIONS — RÉFÉRENCE │
└────────────────────────────────────────────────────────────────────┘
❌ CRITIQUE — Risques Sécurité
┌──────────────────────────────────────────────────────────────┐
│ 1. Actions tierces sans SHA pinning │
│ Risque : compromission de la chaîne de supply │
│ Fix : uses: actions/checkout@<SHA_COMPLET> │
├──────────────────────────────────────────────────────────────┤
│ 2. Script injection via github.event inputs │
│ # ❌ VULNÉRABLE : │
│ run: echo "{{github.event.pull_request.title }}" │
│ # ✅ SÉCURISÉ : │
│ env: │
│ PR_TITLE: {{github.event.pull_request.title }} │
│ run: echo "$PR_TITLE" │
├──────────────────────────────────────────────────────────────┤
│ 3. permissions: write-all (ou absentes = write par défaut) │
│ Risque : compromission totale du repo si runner compromis │
│ Fix : permissions explicites et minimales │
├──────────────────────────────────────────────────────────────┤
│ 4. Secrets affichés dans les logs (echo $SECRET) │
│ Risque : exposition dans l'historique des runs │
│ Fix : GitHub masque automatiquement — ne pas exporter │
└──────────────────────────────────────────────────────────────┘
⚠ MAJEUR — Maintenabilité et Performance
┌──────────────────────────────────────────────────────────────┐
│ 5. Duplication YAML entre workflows (no reuse) │
│ Fix : Reusable Workflows + Composite Actions │
├──────────────────────────────────────────────────────────────┤
│ 6. Pas de cache pour les dépendances │
│ Impact : +3-10 min par run sur npm install / pip install │
│ Fix : actions/cache ou cache: intégré de setup-* │
├──────────────────────────────────────────────────────────────┤
│ 7. Secrets statiques AWS/GCP en lieu de OIDC │
│ Impact : rotation manuelle, risque de fuite long-lived │
│ Fix : aws-actions/configure-aws-credentials + OIDC │
└──────────────────────────────────────────────────────────────┘
⚡ OPÉRATIONNEL
┌──────────────────────────────────────────────────────────────┐
│ 8. Absence de timeout-minutes → run bloqué 6h │
│ 9. Pas de continue-on-error sur steps non critiques │
│ 10. Artifacts sans retention-days → stockage illimité │
│ 11. Pas de concurrency → déploiements simultanés conflictuels│
└──────────────────────────────────────────────────────────────┘
Légende — Rouge = risque sécurité critique | Orange = maintenabilité/performance | Jaune = fiabilité opérationnelle
10
Sécurité
⬡Modèle de Sécurité GitHub Actions — Défense en Profondeur
┌────────────────────────────────────────────────────────────────────┐
│ SÉCURITÉ GITHUB ACTIONS — DÉFENSE EN PROFONDEUR │
└────────────────────────────────────────────────────────────────────┘
① GITHUB_TOKEN — PERMISSIONS
┌──────────────────────────────────────────────────────────────┐
│ Token éphémère généré par GitHub pour chaque run │
│ │
│ Scope Lecture Écriture │
│ ────────────────────────────────────────── │
│ contents ✅ ❌ (par défaut read-only) │
│ pull-requests ✅ ❌ │
│ packages ✅ ❌ │
│ id-token ❌ ❌ (à activer explicitement)│
│ │
│ Bonne pratique : permissions: { contents: read } au minimum│
└──────────────────────────────────────────────────────────────┘
② SUPPLY CHAIN — Actions tierces
┌──────────────────────────────────────────────────────────────┐
│ SHA pinning : uses: owner/action@<SHA40> │
│ Dependabot pour les mises à jour d'actions │
│ OpenSSF Scorecard : audit automatisé des dépendances │
└──────────────────────────────────────────────────────────────┘
③ OIDC — Authentification sans secrets statiques
┌──────────────────────────────────────────────────────────────┐
│ GitHub émet un JWT signé → présenté au cloud provider │
│ AWS / Azure / GCP / Vault acceptent via OIDC federation │
│ Token TTL : 1h maximum, non réutilisable │
│ Condition : repo + environment + branch dans le claim │
└──────────────────────────────────────────────────────────────┘
④ ENVIRONNEMENTS PROTÉGÉS
┌──────────────────────────────────────────────────────────────┐
│ Required reviewers (approbation manuelle) │
│ Wait timer (délai de déploiement) │
│ Deployment branches (branches autorisées) │
│ Custom deployment protection rules (webhooks) │
└──────────────────────────────────────────────────────────────┘
⑤ AUDIT
┌──────────────────────────────────────────────────────────────┐
│ GitHub Audit Log : toute action sur secrets/environments │
│ SARIF upload : résultats scan → Security tab GitHub │
│ CodeQL Analysis : SAST intégré nativement │
└──────────────────────────────────────────────────────────────┘
Légende — ① Permissions GITHUB_TOKEN → ② Supply chain (SHA pinning + Dependabot) → ③ OIDC (sans secrets statiques) → ④ Environnements protégés → ⑤ Audit log
Dependabot — Mise à jour automatique des actions
▋11
Observabilité et Exploitation
⬡Observabilité des Workflows — Métriques, Logs et Alertes
┌────────────────────────────────────────────────────────────────────┐
│ OBSERVABILITÉ GITHUB ACTIONS — PRODUCTION │
└────────────────────────────────────────────────────────────────────┘
① LOGS NATIFS
┌──────────────────────────────────────────────────────────────┐
│ Rétention : 90 jours (public) / 400 jours (Enterprise) │
│ Download : Actions API /repos/{owner}/{repo}/actions/runs/ │
│ Debug logging : ACTIONS_STEP_DEBUG=true (secret) │
│ Runner diagnostic : ACTIONS_RUNNER_DEBUG=true │
└──────────────────────────────────────────────────────────────┘
② RAPPORTS SÉCURITÉ (SARIF)
┌──────────────────────────────────────────────────────────────┐
│ - name: Upload SARIF │
│ uses: github/codeql-action/upload-sarif@v3 │
│ with: │
│ sarif_file: trivy-results.sarif │
│ → Visible dans Security > Code scanning alerts │
└──────────────────────────────────────────────────────────────┘
③ MÉTRIQUES VIA API REST
┌──────────────────────────────────────────────────────────────┐
│ GET /repos/{owner}/{repo}/actions/runs │
│ → status, conclusion, created_at, updated_at │
│ → billing: GET /repos/{owner}/{repo}/actions/billing │
│ │
│ Métriques clés à monitorer : │
│ • workflow_run.duration_ms (temps de build) │
│ • workflow_run.conclusion (success rate) │
│ • billing.total_minutes_used (coût CI) │
└──────────────────────────────────────────────────────────────┘
④ NOTIFICATIONS — Intégration Slack
┌──────────────────────────────────────────────────────────────┐
│ - name: Notify Slack on failure │
│ if: failure() │
│ uses: slackapi/slack-github-action@v1.27.0 │
│ with: │
│ channel-id: 'C0123456789' │
│ slack-message: App deployment failed │
└──────────────────────────────────────────────────────────────┘
⑤ OPENTELEMETRY — Traces de pipeline
┌──────────────────────────────────────────────────────────────┐
│ uses: inception-health/otel-export-trace-action@v0.1.0 │
│ → Envoie les traces vers Jaeger/Tempo/Honeycomb │
│ → Visualisation du pipeline comme distributed trace │
└──────────────────────────────────────────────────────────────┘
Légende — ① Logs natifs GitHub → ② SARIF Security reports → ③ Metrics via API → ④ Notifications (Slack/Teams) → ⑤ OpenTelemetry (otel-export-trace)
12
Intégration dans l'Écosystème DevOps
⬡GitHub Actions dans la Chaîne DevOps Complète
┌────────────────────────────────────────────────────────────────────┐
│ GITHUB ACTIONS DANS L'ÉCOSYSTÈME DEVOPS │
└────────────────────────────────────────────────────────────────────┘
① CODE ② CI (GitHub Actions) ③ REGISTRY
───────── ───────────────────────── ──────────────
┌─────────┐ push ┌──────────────────────────┐ ┌─────────────┐
│ Dev │───────►│ Workflow CI/CD │──►│ GHCR / ECR │
│ PR │ │ 1. lint + test │ │ Harbor │
└─────────┘ │ 2. docker buildx │ │ cosign sign │
│ 3. trivy scan │ └──────┬──────┘
│ 4. push + sign │ │
└──────────────────────────┘ │
│ ④ ArgoCD poll
INTÉGRATIONS NATIVES : ▼
───────────────────────────────────────────── ┌──────────────┐
│ ArgoCD │
Terraform → hashicorp/setup-terraform │ (GitOps CD) │
Ansible → workflow_dispatch + SSH └──────┬───────┘
Docker → docker/build-push-action │
Kubernetes → azure/k8s-deploy ▼
Helm → azure/setup-helm ┌──────────────┐
AWS → aws-actions/configure-aws │ Kubernetes │
Azure → azure/login │ Cluster │
GCP → google-github-actions/auth └──────┬───────┘
Vault → hashicorp/vault-action │
Slack → slackapi/slack-github-action ⑥ Observabilité
Sonar → SonarSource/sonarcloud-github │
Snyk → snyk/actions Prometheus / Grafana
Codecov → codecov/codecov-action Loki / Jaeger
ACTIONS MARKETPLACE :
─────────────────────────────────────────────────────────────────
> 21 000 actions disponibles sur marketplace.github.com
Critères de sélection : Verified creator + SHA pinning + Stars
Légende — ① Code → ② GitHub Actions CI → ③ Registry (GHCR/ECR/Harbor) → ④ ArgoCD (GitOps) → ⑤ Kubernetes → ⑥ Observabilité
13
Exercices Pratiques
Débutant
- ▸Créer un workflow CI Node.js avec lint, test et coverage
- ▸Configurer une stratégie matrix pour 3 versions de Node
- ▸Mettre en place le cache npm avec actions/cache
- ▸Publier une image Docker sur GHCR depuis un workflow
Intermédiaire
- ▸Créer une Composite Action réutilisable pour le build Docker
- ▸Implémenter un Reusable Workflow de déploiement multi-env
- ▸Configurer des environnements protégés avec reviewers obligatoires
- ▸Mettre en place l'authentification OIDC vers AWS (sans secrets)
Avancé
- ▸Déployer Actions Runner Controller (ARC) sur Kubernetes
- ▸Construire un pipeline complet avec SBOM, cosign et SLSA Level 3
- ▸Implémenter OpenTelemetry sur les workflows GitHub Actions
- ▸Auditer et corriger une supply chain compromise (SHA pinning + Scorecard)
14
Résumé Technique
⬡Synthèse GitHub Actions — Référence Ingénieur
┌────────────────────────────────────────────────────────────────────┐
│ RÉSUMÉ TECHNIQUE GITHUB ACTIONS │
└────────────────────────────────────────────────────────────────────┘
PRIMITIVES
─────────────────────────────────────────────────────────────────
Workflow → Fichier YAML dans .github/workflows/
Event → Déclencheur (push, PR, schedule, dispatch...)
Job → Ensemble de steps sur un runner
Step → Action ou commande run (séquentiel dans le job)
Runner → Machine d'exécution (GitHub-hosted ou self-hosted)
Action → Composant réutilisable (uses:)
Context → Variables d'exécution ({{github.* }})
Secret → Variable chiffrée ({{secrets.* }})
Environment → Cible de déploiement avec protection rules
Artifact → Fichier persisté inter-jobs ou pour download
EVENTS PRINCIPAUX
─────────────────────────────────────────────────────────────────
push → commit poussé
pull_request → PR ouverte/mise à jour/mergée
schedule → CRON (ex: '0 2 * * *')
workflow_dispatch → déclenchement manuel avec inputs
workflow_call → appelé depuis un autre workflow
release → publication d'une release
repository_dispatch → webhook externe
SÉCURITÉ — CHECKLIST PRODUCTION
─────────────────────────────────────────────────────────────────
✅ SHA pinning sur toutes les actions tierces
✅ permissions: explicites et minimales (contents: read)
✅ OIDC pour AWS/Azure/GCP (0 secret statique cloud)
✅ Script injection évité (variables env intermédiaires)
✅ Environments protégés avec reviewers (production)
✅ Dependabot pour les mises à jour des actions
✅ SARIF upload pour les résultats de scan
✅ concurrency: défini par branche/PR
✅ timeout-minutes défini sur chaque job
✅ Secrets d'environnement séparés des secrets de repo
Légende — Référence rapide production
15
Glossaire
Workflow
Processus automatisé défini dans un fichier YAML sous .github/workflows/, déclenché par des événements GitHub.
Job
Ensemble de steps s'exécutant sur un même runner, en parallèle ou séquentiellement par rapport aux autres jobs.
Step
Unité atomique d'exécution au sein d'un job : appel d'une action ou commande shell.
Action
Composant réutilisable encapsulant une tâche spécifique, distribué via le GitHub Marketplace.
Runner
Machine (GitHub-hosted ou self-hosted) exécutant les jobs d'un workflow.
Event
Déclencheur de workflow : push, pull_request, schedule, workflow_dispatch, release, etc.
Artifact
Fichier ou ensemble de fichiers produits par un workflow et persistés pour téléchargement ou utilisation inter-jobs.
Context
Ensemble de variables fournissant des informations sur l'exécution : github, env, secrets, runner, job, steps.
Expression
Syntaxe ${{ }} permettant d'évaluer des contextes, fonctions et opérateurs dans les fichiers YAML.
Secret
Variable chiffrée stockée au niveau repository, organisation ou environnement, injectée dans les workflows.
Environment
Cible de déploiement nommée avec ses propres secrets, variables et règles de protection.
Matrix
Stratégie de parallélisation générant automatiquement plusieurs combinaisons de jobs.
Reusable Workflow
Workflow pouvant être appelé depuis d'autres workflows via workflow_call, favorisant la réutilisabilité.
Composite Action
Action combinant plusieurs steps en un composant réutilisable défini par action.yml.
OIDC Token
Token JWT éphémère émis par GitHub pour l'authentification sans secret statique vers les fournisseurs cloud.
Concurrency
Mécanisme de contrôle d'exécution simultanée : annulation ou mise en attente des runs concurrents.