Le principe des quatre yeux au déploiement : imposer les validations techniquement

Objectif

Intercepter avant la production les erreurs et les abus qu'une seule personne — ou un seul agent disposant de ses droits — pourrait introduire, sans faire reposer le processus sur la confiance et la mémoire individuelles.

Prérequis

Un système de gestion de versions et d'intégration continue qui connaît des règles par branche et par environnement : GitHub propose des branches protégées et des environnements avec des « Required reviewers », GitLab des validations de déploiement (« Deployment approvals »). Au moins deux personnes disposant du droit de revue. Un déploiement exécuté exclusivement depuis la CI et uniquement depuis la branche principale.

Étapes

1. Protéger la branche principale : interdire les push directs, exiger au moins une validation, faire expirer les validations lors de nouveaux commits (GitHub : « Dismiss stale pull request approvals when new commits are pushed »), rendre obligatoires les vérifications de statut de la CI.
2. Exclure l'auto-validation : la personne qui crée la proposition de modification ne la valide pas elle-même. Pour les chemins sensibles (scripts de déploiement, infrastructure, droits), exiger via un fichier de propriétaires de code (« code owners ») un second groupe nommément désigné.
3. Définir la production comme un environnement distinct soumis à validation obligatoire, de sorte que la tâche de déploiement attende qu'une personne habilitée la valide — séparément de la revue de code, car le moment et le contexte de la livraison relèvent d'une décision propre.
4. Fermer les contournements : les administrateurs sont soumis aux mêmes règles (« Do not allow bypassing the above settings ») ; les identifiants de déploiement ne se trouvent que dans la CI, jamais sur les postes de travail.
5. Définir une voie d'urgence qui déplace le principe dans le temps plutôt que de le rompre : un déploiement d'urgence exige une seconde personne au téléphone, est marqué comme tel et fait l'objet d'une revue a posteriori au plus tard le jour ouvré suivant.
6. Vérifier régulièrement : qui dispose du droit de revue, quelles règles ont été contournées selon le journal d'audit, quelles validations ont eu lieu si vite que personne n'a pu réellement lire le contenu.

Résultat attendu

Chaque modification en production peut être rattachée à deux personnes : celle qui l'a proposée et celle qui l'a validée. Un poste de travail compromis ou un agent détourné ne peut, à lui seul, livrer une version.

Limites et base de vérification

Le principe vérifie que quelqu'un a regardé, pas avec quel soin ; les revues approuvées sans examen le vident de son sens, et seules une culture de la revue et des vérifications par sondage y remédient, pas les outils. Deux personnes qui s'entendent peuvent le contourner ; seuls des journaux et une séparation des rôles y remédient. Les réglages cités suivent la documentation GitHub et GitLab mentionnée ; aucune affirmation n'est faite sur l'effet sur les taux d'erreur.