Ce que vous accomplirez

Vous configurerez un workflow de code review qui scale de trois à trente contributeurs : branch protection, CODEOWNERS, templates de PR, vérifications automatisées, et conventions pour relecteurs et auteurs.

Étape 1 : choisir un modèle

Le modèle dominant en 2026 est GitHub Flow.

• Une seule branche main de longue durée.
• Branches feature depuis main.
• PR pour review et CI.
• Merge après approbation et checks verts.

Étape 2 : branch protection

• Requérir un PR avant le merge.
• Requérir au moins une review approuvée.
• Rejeter les approbations obsolètes.
• Requérir des status checks.
• Requérir un historique linéaire.
• Interdire les force pushes.
• Interdire la suppression directe.

gh api -X PUT repos/owner/repo/branches/main/protection \
  -F required_pull_request_reviews.required_approving_review_count=1 \
  -F required_status_checks.strict=true \
  -F enforce_admins=true

Étape 3 : CODEOWNERS

# .github/CODEOWNERS
*               @org/maintainers
/infra/         @org/devops
/docs/          @org/docs-team
*.sql           @org/dba

Étape 4 : template de PR

# .github/PULL_REQUEST_TEMPLATE.md
## Résumé
Brève description du changement.

## Pourquoi
Contexte, liens vers issues.

## Comment testé
- [ ] Tests unitaires ajoutés/mis à jour
- [ ] Smoke test manuel
- [ ] CI vert

## Captures / vidéos (UI uniquement)

## Risque et rollback
Tout ce dont les relecteurs devraient se soucier.

Étape 5 : vérifications automatisées

# .github/workflows/ci.yml
name: CI
on:
  pull_request:
  push:
    branches: [main]
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with: { node-version: '20' }
      - run: npm ci
      - run: npm run lint
      - run: npm run typecheck
      - run: npm test

Étape 6 : intégrations de bots

• Dependabot / Renovate.
• Action gitleaks.
• Codecov ou Coveralls.
• danger.js ou danger-rb.

Étape 7 : conventions de review

# CONTRIBUTING.md
## Pour les auteurs
- Branche depuis main.
- Gardez les PRs sous 400 lignes.
- Auto-révisez avant de demander review.
- Liez le ticket.
- Adressez chaque commentaire.

## Pour les relecteurs
- Répondez dans la journée.
- Distinguez bloquants et suggestions.
- Approuvez ou demandez des changements.
- Faites confiance au jugement de l'auteur sur le style.

Étape 8 : conventions de commentaires

• nit: suggestion stylistique mineure.
• question: cherche clarification.
• suggestion: changement proposé.
• blocker: doit être adressé.
• praise: souligne quelque chose de bien fait.

Étape 9 : relire petit, relire souvent

Étape 10 : gérer les désaccords

1. Discuter dans les commentaires du PR.
2. Escalader à un troisième relecteur.
3. Décider via discussion d'équipe.

Étape 11 : hygiène post-merge

• Auto-supprimer les branches mergées.
• Lancer des balayages périodiques de PR.
• Suivre le temps de cycle de PR.

Étape 12 : amélioration continue