Règles de protection des déploiements GitHub

Un environnement sans règle n'est qu'une étiquette. Ce sont les règles de protection qui en font une frontière : exiger une approbation humaine, imposer un délai avant exécution, restreindre les branches autorisées à déployer, ou déléguer la décision à un système tiers. Cette page détaille les quatre, avec leurs limites chiffrées et le comportement exact des secrets pendant l'attente.

Ce que vous allez apprendre

• Exiger une approbation et savoir qui peut l'accorder, et qui ne peut pas
• Utiliser le délai d'attente comme fenêtre d'annulation, sans payer la minute
• Restreindre les branches et tags autorisés à déployer sur une cible
• Brancher une règle personnalisée portée par un outil d'observabilité ou d'ITSM
• Comprendre pourquoi les secrets ne fuitent pas pendant l'attente d'approbation

Les quatre règles disponibles

Règle	Ce qu'elle contrôle	Limite
Required reviewers	Qui autorise le déploiement	Jusqu'à 6 personnes ou équipes
Wait timer	Combien de temps on attend avant de démarrer	1 à 43 200 minutes (30 jours)
Deployment branches and tags	D'où le déploiement peut partir	3 politiques possibles
Custom deployment protection rules	Décision déléguée à un tiers	6 règles actives au maximum

Glissez pour voir

Elles se cumulent. Un environnement de production sérieux en combine typiquement trois : approbation humaine, restriction aux branches protégées, et parfois une règle personnalisée qui vérifie l'absence d'incident en cours.

Approbation obligatoire : le garde-fou principal

La règle Required reviewers met le job en pause et attend qu'une personne autorisée valide. Vous désignez jusqu'à six utilisateurs ou équipes, et une seule approbation suffit à débloquer le job. Ce n'est donc pas un quorum : c'est une liste de personnes habilitées, dont n'importe laquelle peut ouvrir la porte.

Un détail compte beaucoup en pratique : quand l'auto-approbation est désactivée dans les réglages, la personne qui a déclenché le déploiement ne peut pas l'approuver elle-même. C'est ce qui distingue un vrai contrôle à quatre yeux d'une case à cocher.

Ce qui se passe pendant l'attente

C'est le point le plus important de toute cette page, et le plus souvent ignoré :

Un job ne peut pas accéder aux secrets de l'environnement tant qu'un des relecteurs requis ne l'a pas approuvé.

Autrement dit, l'attente n'est pas une pause cosmétique avant un job déjà armé. Tant que l'approbation n'est pas donnée, le runner n'a jamais vu le jeton de production. Un workflow compromis qui atteindrait l'étape de déploiement n'obtiendrait rien de plus qu'une demande d'approbation visible par toute l'équipe.

jobs:
  deploy-production:
    needs: deploy-staging
    runs-on: ubuntu-24.04
    environment:
      name: production      # environnement avec required reviewers
      url: https://mon-app.example.com
    steps:
      - name: Déployer en production
        run: ./deploy.sh
        env:
          # Ce secret n'est délivré qu'après l'approbation humaine
          DEPLOY_TOKEN: ${{ secrets.DEPLOY_TOKEN }}

L'approbation est une trace, pas seulement un frein

Chaque approbation est journalisée avec son auteur et son horodatage. Sur un périmètre soumis à audit, c'est souvent la seule preuve exploitable que la mise en production a été autorisée par une personne identifiée, et non par un automatisme. Cette trace vaut autant que le blocage lui-même.

Délai d'attente : la fenêtre d'annulation

Le wait timer retarde le démarrage du job de 1 à 43 200 minutes, soit jusqu'à 30 jours. Sa vertu n'est pas de ralentir, mais d'ouvrir une fenêtre d'annulation : si un problème apparaît juste après la fusion, vous avez le temps d'arrêter l'exécution avant qu'elle ne touche la production.

Un point de facturation à connaître, parce qu'il lève l'objection la plus fréquente : le temps d'attente n'est pas facturé. Vous ne payez pas des minutes de runner pendant que le compteur tourne, le job n'a pas encore démarré.

En pratique, cinq à quinze minutes suffisent pour une fenêtre utile. Au-delà, vous n'obtenez plus une sécurité mais une file d'attente, et l'équipe prendra l'habitude de contourner le mécanisme.

Branches et tags autorisés

La troisième règle répond à une question simple : d'où a-t-on le droit de déployer sur cette cible ? Trois politiques sont proposées :

Politique	Effet	Usage typique
Aucune restriction	Toute branche ou tag peut déployer	Environnement de test jetable
Branches protégées uniquement	Seules les branches couvertes par une règle de protection	Production simple
Branches et tags sélectionnés	Motifs de noms explicites (main, release/*, v*)	Production avec branches de release

Glissez pour voir

Sans cette règle, n'importe quelle branche de fonctionnalité peut, par un workflow déclenché manuellement, viser l'environnement production et consommer ses secrets. La restriction ferme cette porte avant l'exécution : le job échoue immédiatement, sans jamais obtenir les secrets.

Restreindre la branche ne remplace pas protéger la branche

Autoriser uniquement main à déployer ne sert à rien si n'importe qui peut pousser sur main. Les deux mécanismes se complètent : la protection de branche contrôle qui écrit sur main, la politique de déploiement contrôle ce que main a le droit d'atteindre. Une chaîne n'est solide que si les deux maillons existent.

Règles personnalisées : déléguer la décision

La quatrième règle, custom deployment protection rules, délègue l'autorisation à un service tiers via une application GitHub. Le déploiement reste en attente jusqu'à ce que ce service réponde. GitHub cite notamment Datadog, Honeycomb et ServiceNow parmi les intégrations disponibles, et un environnement accepte six règles actives au maximum.

L'intérêt n'est pas de rajouter un clic, mais d'automatiser un critère que l'humain évalue mal ou trop tard :

• l'observabilité refuse le déploiement si le taux d'erreur de la version en place dépasse un seuil, ou si un budget d'erreur est déjà consommé ;
• l'ITSM refuse le déploiement hors fenêtre de changement approuvée, ou si un incident majeur est ouvert.

C'est le niveau de maturité au-dessus de l'approbation humaine : la question « a-t-on le droit de déployer maintenant ? » cesse de dépendre de la vigilance d'une personne un vendredi soir.

Une progression réaliste

Poser les quatre règles d'un coup sur un dépôt existant produit surtout du contournement. L'ordre qui tient dans la durée va du moins coûteux au plus exigeant :

Étape	Règle posée	Ce qu'elle coûte à l'équipe
1	Branches autorisées sur production	Rien, personne ne déployait depuis ailleurs
2	Secrets déplacés au niveau environnement	Une migration, une fois
3	Approbation requise sur production	Un clic par mise en production
4	Délai d'attente de 10 minutes	Dix minutes, récupérables en annulation
5	Règle personnalisée liée aux incidents	Une intégration à maintenir

Glissez pour voir

Les deux premières étapes ne se négocient pas : elles sont gratuites en friction et ferment les deux voies les plus utilisées. Les suivantes se discutent avec l'équipe, parce qu'elles se paient en temps.

Contrôle de connaissances

Vérifiez que l'essentiel de ce guide est acquis. Les questions portent uniquement sur ce qui vient d'être expliqué ici.

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

6 questions

6 min.

70% requis

Informations

• Le chronomètre démarre au clic sur Démarrer
• Questions à choix multiples, vrai/faux et réponses courtes
• Vous pouvez naviguer entre les questions
• Les résultats détaillés sont affichés à la fin

Démarrer le quiz

Lance le quiz et démarre le chronomètre

À retenir

• Quatre règles protègent un environnement : approbation, délai d'attente, branches autorisées et règles personnalisées.
• L'approbation accepte jusqu'à six relecteurs ou équipes, et une seule approbation débloque le job ; l'initiateur ne peut pas s'auto-approuver quand l'option est désactivée.
• Les secrets d'environnement ne sont pas délivrés avant l'approbation : l'attente est une vraie barrière, pas une pause devant un job déjà armé.
• Le délai d'attente va de 1 à 43 200 minutes et n'est pas facturé.
• La politique de branches empêche une branche de fonctionnalité de viser la production, mais ne remplace pas la protection de la branche elle-même.
• Les règles personnalisées (six au maximum) délèguent la décision à l'observabilité ou à l'ITSM, et automatisent le « peut-on déployer maintenant ? ».

Pour aller plus loin

• Releases et packages : Publier ce que ces règles ont laissé passer, sous forme de release taguée et d'image consommable.
• Rollback et concurrence : Le retour arrière, seul mécanisme qui reste quand l'approbation a laissé passer une régression.
• Lab : promouvoir un déploiement approuvé : La mise en pratique sur un dépôt réel, de l'image attestée à l'approbation en production.

×

📖 Voir la documentation →