# Exécuter ses workflows en local quand le code client ne peut transiter nulle part ailleurs

> Certains contrats imposent que le code ne quitte jamais une infrastructure maîtrisée, ce qui pousse à héberger soi-même l'exécution des workflows de vérification.

- Auteur : Clément Hadrot
- Publié le : 2025-08-06
- Mis à jour le : 2025-08-06
- Catégorie : Outils & workflow
- URL : https://wpmoderne.dev.wordpress-developpement.fr/outils/workflows-machine-locale-code-confidentiel/

## L’essentiel

- Un contrat de confidentialité peut interdire tout transit par une infrastructure tierce
- Un exécuteur auto-hébergé remplace les exécuteurs gérés sans changer la syntaxe des workflows
- Isoler l'exécuteur du réseau de production reste indispensable

Le contrat de prestation était clair sur un point : aucune ligne de code source ne devait transiter par un service tiers non explicitement validé, y compris pour de simples vérifications automatisées. Cette clause, courante dans certains secteurs sensibles, exclut d'office l'usage des exécuteurs gérés proposés par défaut avec GitHub Actions, puisque ces machines appartiennent à une infrastructure hors du périmètre contractuel validé.

Ce qui suit décrit comment les vérifications automatisées de code, tests unitaires et analyse statique, ont été déplacées vers une machine hébergée en interne, sans aborder la configuration générale de GitHub Actions elle-même, déjà connue par ailleurs.

## Le principe d'un exécuteur auto-hébergé

GitHub Actions permet de remplacer les exécuteurs gérés par une machine que l'on contrôle entièrement, appelée exécuteur auto-hébergé. Cette machine s'enregistre auprès du dépôt ou de l'organisation, reste à l'écoute de nouveaux travaux à exécuter, et les traite localement sans que le code ne quitte jamais l'infrastructure choisie. La syntaxe des fichiers de workflow ne change presque pas : seule la ligne désignant la machine cible est modifiée.

```
name: Vérifications
on: [push, pull_request]

jobs:
  tests:
    runs-on: self-hosted
    steps:
      - uses: actions/checkout@v4
      - name: Installer les dépendances
        run: composer install --no-interaction
      - name: Lancer les tests
        run: vendor/bin/phpunit
```

Le mot-clé `self-hosted` suffit à rediriger l'exécution vers la machine enregistrée, plutôt que vers l'infrastructure gérée par défaut.

## Où héberger cet exécuteur

> L'essentiel à retenir : Un contrat de confidentialité peut interdire tout transit par une infrastructure tierce ; Un exécuteur auto-hébergé remplace les exécuteurs gérés sans changer la syntaxe des workflows ; Isoler l'exécuteur du réseau de production reste indispensable

Le choix s'est porté sur une machine virtuelle dédiée, hébergée sur la même infrastructure que les environnements de préproduction du client, déjà couverte par le même contrat de confidentialité. L'exécuteur y tourne comme un service système, enregistré une fois via un jeton fourni par GitHub, et redémarre automatiquement en cas d'interruption. Aucune donnée ne remonte vers un service externe autre que GitHub lui-même pour la coordination des travaux, ce qui reste conforme à la clause contractuelle : celle-ci porte sur le contenu du code, pas sur les métadonnées d'orchestration.

Un point de vigilance a demandé une correction rapide après la mise en service : par défaut, un exécuteur auto-hébergé conserve le répertoire de travail entre deux exécutions successives. Un nettoyage explicite du répertoire a dû être ajouté en début de workflow pour éviter qu'un fichier de configuration temporaire d'une exécution précédente ne pollue la suivante.

## Isoler l'exécuteur du reste de l'infrastructure

Un exécuteur auto-hébergé exécute du code arbitraire provenant des travaux qui lui sont soumis : c'est une porte d'entrée qui mérite d'être traitée avec la même vigilance qu'un serveur exposé. La machine a donc été placée sur un sous-réseau isolé, sans accès direct aux bases de données de production, avec des règles de pare-feu strictement limitées aux flux nécessaires vers les dépôts de paquets et vers l'API de GitHub.

- Aucun accès direct depuis l'exécuteur vers les serveurs de production
- Jetons d'accès à portée limitée, renouvelés régulièrement
- Journalisation systématique de chaque travail exécuté, pour audit ultérieur

## Ce que cela a coûté en confort

Contrairement aux exécuteurs gérés, cette machine ne bénéficie d'aucune mise à l'échelle automatique : deux travaux simultanés se mettent en file d'attente au lieu de s'exécuter en parallèle sur des machines distinctes. Pour ce projet, dont le volume de travaux reste modéré, cette contrainte n'a pas posé de problème pratique. Elle deviendrait limitante sur un projet à fort volume de contributions simultanées, ce qui aurait alors justifié de provisionner plusieurs exécuteurs plutôt qu'un seul.

La maintenance de l'exécuteur, mises à jour système et surveillance de l'espace disque, incombe désormais à l'équipe elle-même, une responsabilité auparavant déléguée implicitement à l'infrastructure gérée.

## Notre verdict

Pour un contrat qui impose explicitement que le code ne transite par aucune infrastructure tierce non validée, l'exécuteur auto-hébergé reste la seule option compatible, sans nécessiter de renoncer à l'intégration continue. Le surcoût en maintenance et en mise à l'échelle est réel, mais reste largement acceptable au regard de l'obligation contractuelle qu'il permet de satisfaire.