GitHub Actions : workflows réutilisables multi-repo

À la fin de ce tutoriel, vous saurez distinguer reusable workflows (workflow_call) et composite actions, centraliser les pipelines dans org/platform-workflows, appeler un workflow avec inputs / secrets / outputs, appliquer le least privilege permissions, utiliser secrets: inherit, pinner les refs, et esquisser un job OIDC AWS en ca-central-1. Angle DevOps Elastic Hayway (DEH) : DRY multi-repo, zéro secret en clair, lab à ~0 €.

Niveau : Intermédiaire · Temps estimé : 55–75 min · Versions cibles : GitHub Actions 2026 · workflow_call · composite actions · OIDC AWS · AWS CLI v2 · Dernière vérification : 2026-09-11 · Region : ca-central-1

Slug : wow-github-actions-reusable · Série : WOW (37/50) · Mot-clé SEO : github actions reusable workflows · Publish : READY

← Précédent : GitLab CI avancé (WOW 36) · → Suivant : Buildkite agents (WOW 38) · Aussi : GHA OIDC AWS · DevSecOps pipeline · Platform Engineering 2026

Prérequis

Coût estimé : ~0 € (minutes GitHub Free / org ; IAM OIDC = 0 $ ; pas d’EC2, NAT, RDS).

export AWS_PROFILE=lab
export AWS_DEFAULT_REGION=ca-central-1
aws sts get-caller-identity

Ce que nous allons construire

GitHub Actions reusable (WOW 37/50) — ca-central-1
  ├── Reusable workflow_call vs composite actions
  ├── Repo central org/platform-workflows
  ├── Caller : uses + inputs / secrets / outputs
  ├── permissions least privilege + secrets: inherit
  ├── Pinning SHA / tags immuables
  ├── Sketch OIDC AWS job (ca-central-1)
  └── Anti-patterns + quiz + FAQ + maillage

(Schéma — alt : « App repos appellent un reusable central org/platform-workflows ; OIDC assume un rôle AWS en ca-central-1 ».)

Étape 1 — Pourquoi des workflows réutilisables en 2026 ?

Copier le même .github/workflows/ci.yml dans 40 repos crée du toil : drift de versions, permissions trop larges, secrets dupliqués, scans oubliés. Les orgs matures traitent la CI comme un produit plateforme — même esprit que Platform Engineering 2026.

Les reusable workflows (on: workflow_call) exposent un contrat versionné : inputs typés, secrets, outputs, jobs complets. Les app teams appellent ; la plateforme maintient.

Pression Réponse DEH
Drift multi-repo Un repo platform-workflows
Minutes / coûts Path lint/test/build standard
Sécu permissions + OIDC
Compliance Pinning + CODEOWNERS
Onboarding Un uses: au lieu de 200 lignes

Étape 2 — Reusable workflow vs composite action

Deux outils, deux portées.

Critère Reusable workflow Composite action
Déclencheur on: workflow_call runs: using: composite
Unité Jobs (voire plusieurs) Steps dans un job
Environments / concurrency Oui Non
Cas idéal Pipeline lint→test→deploy Setup Node, checkout+cache

Règle DEH : composite pour un bloc de steps ; reusable pour un pipeline multi-repo. Souvent les deux : le reusable appelle des composites internes. Évitez un unique monolithe YAML : un golden path = un fichier workflow_call versionné.

Étape 3 — Pattern org : org/platform-workflows

Dépôt privé recommandé :

org/platform-workflows
  ├── .github/workflows/
  │     ├── ci-node.yml
  │     └── deploy-s3-lab.yml
  ├── actions/setup-node-deh/action.yml
  ├── README.md
  └── CODEOWNERS

Settings → Actions → General → Access → « Accessible from repositories in the organization ». Sans ça, uses: org/platform-workflows/... échoue. CODEOWNERS sur .github/workflows/ : toute PR CI centrale passe par la plateforme.

Étape 4 — Lab YAML : reusable workflow_call

# org/platform-workflows/.github/workflows/ci-node.yml
name: reusable-ci-node

on:
  workflow_call:
    inputs:
      node-version:
        type: string
        default: "22"
      run-tests:
        type: boolean
        default: true
      working-directory:
        type: string
        default: "."
    secrets:
      NPM_TOKEN:
        required: false
    outputs:
      artifact-name:
        description: "Artefact produit"
        value: ${{ jobs.build.outputs.artifact-name }}

permissions:
  contents: read

jobs:
  build:
    runs-on: ubuntu-latest
    outputs:
      artifact-name: ${{ steps.meta.outputs.name }}
    defaults:
      run:
        working-directory: ${{ inputs.working-directory }}
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: ${{ inputs.node-version }}
          cache: npm
          cache-dependency-path: ${{ inputs.working-directory }}/package-lock.json
      - run: npm ci
        env:
          NODE_AUTH_TOKEN: ${{ secrets.NPM_TOKEN }}
      - run: npm run lint --if-present
      - name: Test
        if: ${{ inputs.run-tests }}
        run: npm test --if-present
      - id: meta
        run: echo "name=app-${{ github.sha }}" >> "$GITHUB_OUTPUT"

Inputs typés, permissions restrictives dès le reusable, outputs remontés via jobs.<id>.outputs.

Étape 5 — Caller applicatif

# org/demo-payments/.github/workflows/ci.yml
name: ci
on:
  push:
    branches: [main]
  pull_request:

permissions:
  contents: read

jobs:
  call-ci:
    uses: org/platform-workflows/.github/workflows/ci-node.yml@v1
    with:
      node-version: "22"
      run-tests: true
      working-directory: "."
    secrets: inherit

secrets: inherit vs nommés

  • secrets: inherit : tous les secrets du caller (repo / org / environment). Simple en lab.
  • Nommés : secrets: { NPM_TOKEN: ${{ secrets.NPM_TOKEN }} } — moindre surface. DEH : inherit en lab privé ; mapping explicite pour deploy-* prod.

Consommer un output

jobs:
  call-ci:
    uses: org/platform-workflows/.github/workflows/ci-node.yml@v1
    secrets: inherit
  notify:
    needs: call-ci
    runs-on: ubuntu-latest
    steps:
      - run: echo "Artifact ${{ needs.call-ci.outputs.artifact-name }}"

Étape 6 — Least privilege permissions

Déclarez permissions au caller et au reusable.

Besoin Permission
Checkout contents: read
Commentaire PR pull-requests: write
GHCR packages: write
OIDC AWS id-token: write + contents: read

Anti-pattern : write-all « pour que ça marche ». Ouvrez au fur et à mesure et documentez chaque élargissement dans le README du central.

Étape 7 — Pinning

# Fragile
uses: org/platform-workflows/.github/workflows/ci-node.yml@main
# Mieux : tag semver
uses: org/platform-workflows/.github/workflows/ci-node.yml@v1.4.0
# Max supply-chain : SHA
uses: org/platform-workflows/.github/workflows/ci-node.yml@a1b2c3d4e5f678901234567890abcdef1234567

DEH : tags v1 / v1.4.0 + changelog ; repos prod SHA ou tag patch ; Renovate sur les callers. Jamais @main pour un deploy production.

Étape 8 — Sketch OIDC AWS ca-central-1

Détails IAM dans github-actions-oidc-aws. Version reusable minimale :

# org/platform-workflows/.github/workflows/deploy-s3-lab.yml
name: reusable-deploy-s3-lab
on:
  workflow_call:
    inputs:
      bucket:
        type: string
        required: true
      role-arn:
        type: string
        required: true

permissions:
  contents: read
  id-token: write

jobs:
  deploy:
    runs-on: ubuntu-latest
    environment: lab
    steps:
      - uses: actions/checkout@v4
      - uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: ${{ inputs.role-arn }}
          aws-region: ca-central-1
      - run: aws sts get-caller-identity
      - run: echo "aws s3 sync ./dist s3://${{ inputs.bucket }}/ --delete"

Caller :

jobs:
  deploy-lab:
    uses: org/platform-workflows/.github/workflows/deploy-s3-lab.yml@v1
    with:
      bucket: "lab-gha-oidc-REPLACE"
      role-arn: "arn:aws:iam::123456789012:role/gha-lab-site-deploy"

Trust IAM bornée (sub / repository / environment:lab) — pas de *. Aucune access key dans Secrets. Le lab reste un dry-run (sts get-caller-identity) sauf si vous avez un bucket jetable déjà provisionné.

Étape 9 — Composite (complément) et check-list

# org/platform-workflows/actions/setup-node-deh/action.yml
name: setup-node-deh
inputs:
  node-version:
    default: "22"
runs:
  using: composite
  steps:
    - uses: actions/checkout@v4
    - uses: actions/setup-node@v4
      with:
        node-version: ${{ inputs.node-version }}
        cache: npm
    - run: npm ci
      shell: bash

Appel : uses: org/platform-workflows/actions/setup-node-deh@v1. Utile dans un reusable pour factoriser sans multiplier les workflows.

Anti-patterns : @main partout ; clés AWS longues ; write-all ; reusable monstre sans inputs ; contournements locaux non documentés ; accès org oublié ; region us-east-1.

Check-list DEH : repo central + Access OK · workflow_call + caller @vX · permissions minimales · inherit lab / mapping prod · pinning tag/SHA · OIDC ca-central-1 · CODEOWNERS · coût ~0 €.

Erreurs fréquentes

Erreur Impact Correction
uses vers repo inaccessible Job rouge Access org / visibility
Composite vs reusable confondus Pas d’environments workflow_call pour pipelines
OIDC sans id-token: write Assume-role refuse Ajouter la permission
Secrets non transmis Registry 401 inherit ou mapping
@main en prod Drift supply-chain Tag / SHA + Renovate
Region us-east-1 Drift FinOps DEH Forcer ca-central-1
Clés IAM longues Fuite OIDC + trust bornée

Quiz (5 questions)

1. Un reusable workflow se déclare avec :
– A. runs: using: composite uniquement
– B. on: workflow_call
– C. Un webhook Slack

2. Différence clé reusable vs composite :
– A. Aucune
– B. Reusable = jobs ; composite = steps
– C. Composite seul peut faire OIDC

3. Pour transmettre tous les secrets du caller :
– A. Les coller en clair dans YAML
– B. secrets: inherit
– C. Les committer dans platform-workflows

4. Region lab DEH de ce tutoriel :
– A. us-east-1
– B. ca-central-1
– C. eu-west-3

5. Pinning recommandé pour un deploy prod :
– A. @main
– B. Tag immuable ou commit SHA
– C. Branche personnelle du stagiaire

Réponses : 1‑B · 2‑B · 3‑B · 4‑B · 5‑B

FAQ

Reusable ou composite en premier ?

Pipeline lint/test/scan multi-repo → reusable. Setup Node/Go répété → composite. Les deux cohabitent dans platform-workflows.

Repo public obligatoire pour uses: ?

Non. Privé org + Access « repositories in the organization » suffit.

secrets: inherit est-il dangereux ?

Pratique en lab. En prod partagée : mapping explicite + environments avec reviewers.

Combien de workflows dans le central ?

Un par golden path (Node, Go, Terraform plan, deploy S3…), versionné (v1), inputs documentés.

Lien avec Platform Engineering ?

platform-workflows est un golden path CI — wow-platform-engineering-2026.

Où approfondir OIDC ?

Lab IAM + S3 : github-actions-oidc-aws. Ici on l’encapsule en reusable.

Coût réel du lab ?

~0 € (workflows + dry-run sts get-caller-identity). Pas d’infra lourde.

Pour aller plus loin

Maillage série WOW
← Précédent GitLab CI avancé (WOW 36)
→ Suivant Buildkite agents (WOW 38)
Aussi GHA OIDC AWS · DevSecOps pipeline · Platform Engineering 2026 · Démarrer avec AWS

Meta publication (SEO)

  • Title SEO : GitHub Actions reusable workflows 2026 : DRY multi-repo (guide FR)
  • Meta description : GitHub Actions reusable workflows 2026 : workflow_call vs composite, org platform-workflows, secrets inherit, OIDC ca-central-1, pinning, FAQ et quiz DEH.
  • Focus keyword : github actions reusable workflows
  • Secondary : workflow_call, composite actions, secrets inherit, platform-workflows, OIDC GitHub Actions ca-central-1
  • Image : assets/web/devopelastichayway/cover-wow-github-actions-reusable-1200x630.webp (à générer)
  • Catégorie : WOW / CI-CD · Niveau : Intermédiaire
  • URL cible : https://devopelastichayway.com/tutoriels/wow-github-actions-reusable/
  • Post live : N/A (nouveau) · slug wow-github-actions-reusable · Publish : READY (feu vert contenu — draft only ; Maître centralise le publish WP)

← Catalogue Tutoriels

Pour aller plus loin — hubs live

Retour parcours Catalogue Tutoriels — hub de la série et leçons sœurs.

© 2023 devopelastichayway.com All rights reserved.