Exemples d’implémentation de la gouvernance des pull requests avec des modèles, des vérifications, CODEOWNERS, des règles et des portes d’environnement

Dans cette unité, vous allez apprendre :

• Comment les pull requests agissent comme des points de contrôle architecturaux pour l’exécution de l'agent

• Comment appliquer la validation de plan avec les vérifications d’état requises

• Comment utiliser CODEOWNERS et les évaluations pour acheminer et approuver les modifications

Les pull requests sont des points de contrôle architecturaux

Les pull requests sont le mécanisme de contrôle principal pour l’exécution des agents sur GitHub. Au lieu d’autoriser les modifications directes apportées aux branches protégées, les architectures bien conçues routent les modifications de l’agent par le biais de demandes de tirage (pull request) et appliquent les exigences de fusion par le biais de la stratégie.

Un flux de travail sécurisé courant ressemble à ceci :

Agent creates branch

    ↓

Agent opens pull request (includes plan)

    ↓

Required reviews validate approach

    ↓

GitHub Actions run required checks

    ↓

All checks pass + approvals complete

    ↓

Pull request can be merged

Cette structure garantit que l’exécution est contrôlée par l’automatisation et la révision humaine.

Implémentation : modèle de pull request nécessitant un plan structuré

Un modèle de requête de tirage (pull request) garantit que chaque requête de tirage d'agent fournit des sections cohérentes de planification et de preuves.

<!-- File: .github/pull_request_template.md -->

## Plan (required)
- **Goal:**
- **Scope (paths/files):**
- **Steps:**
  1.
  2.
  3.
- **Success criteria (verifiable):**
  - [ ] Required checks pass
  - [ ] Security signals reviewed (as applicable)
- **Risks + mitigations:**
- **Rollback / escalation plan:**

## Evidence
- Workflow run(s):
- Scan results (if applicable):

## Review checklist
- [ ] Plan reviewed and approved
- [ ] Required reviews satisfied
- [ ] Required checks satisfied

Application de la validation du plan avec les vérifications d’état requises

Outre les modèles, vous pouvez appliquer la planification en tant que vérification d’état requise. Cela transforme une attente de processus (« inclure un plan ») en garantie système.

# File: .github/workflows/plan-gate.yml
name: Plan Gate

on:
  pull_request:
    branches: [ main ]

jobs:
  require-plan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Require plan artifact
        run: |
          if [ ! -f "Github/pull_request_template.md" ]; then
            echo "Github/pull_request_template.md is required for this pull request."
            exit 1
          fi
          echo "Github/pull_request_template.md found."

Note d’implémentation :

Un administrateur de référentiel peut marquer Plan Gate comme un contrôle d’état requis à l’aide des ensembles de règles ou de la protection de branche, pour garantir que les pull requests ne peuvent pas fusionner, sauf si le plan existe.

GitHub pouvez exiger une approbation explicite avant que les flux de travail ne s’exécutent sur les modifications générées par l’agent.

Utilisation de CODEOWNERS pour garantir la sécurité

CODEOWNERS garantit que les modifications apportées aux zones sensibles sont automatiquement apportées aux réviseurs appropriés.

# File: CODEOWNERS

/security/ @security-team
/.github/workflows/ @platform-team
/infra/ @platform-team
* @core-team

Cela garantit qu’un plan et un ensemble de modifications affectant les chemins à haut risque ne peuvent pas être fusionnés sans visibilité des experts appropriés (lorsqu’ils sont combinés avec les stratégies de révision requises).

Soyez méfiant de l’exécution sans validation

Si un agent peut contourner les vérifications requises ou fusionner sans révision, l’architecture perd ses mécanismes de sécurité principaux. Il s’agit moins d’un problème de modèle et plus d’un échec de conception de flux de travail.

Point clé : Les pull requests ne sont pas seulement des outils de collaboration, mais aussi des mécanismes d'application.

Ensuite, vous allez définir la quantité d’autonomie que l’agent doit avoir en fonction du risque de la tâche.