Approuver / Obtenir une approbation : définition, approbation et code review dans Git

Qu’est-ce que l’approbation d’un pull request

L’approbation est une revue positive d’un pull request, signifiant que le relecteur a vérifié le code, n’a trouvé aucun problème critique et considère les modifications prêtes pour le merge. Dans l’interface GitHub, il s’agit du bouton vert « Approve » sur la page du PR. Après l’approbation, l’auteur (ou tout membre avec droits d’écriture) peut effectuer le merge.

Le processus d’approbation fait partie des Branch Protection Rules. Les propriétaires du dépôt configurent les exigences obligatoires : nombre minimum d’approbations (par exemple 1 ou 2), qui peut approuver (propriétaires du code, membres de l’équipe) et si le PR doit être ré-approuvé après modifications (Dismiss stale reviews). Sans configuration de règles, l’approbation est facultative, mais dans les équipes professionnelles, elle est obligatoire.

GitLab utilise un mécanisme similaire appelé Approval Rules. Dans GitLab, vous pouvez configurer le nombre d’approbations requises de différents groupes (par exemple, 2 des développeurs back-end et 1 de DevOps). Après réception de toutes les approbations obligatoires, le PR est automatiquement débloqué pour le merge à condition que le pipeline CI/CD soit vert.

Types de revue : Approve, Request Changes, Comment

GitHub et GitLab proposent trois types de revue qu’un relecteur peut laisser sur un pull request. Chaque type a un statut et des conséquences différents pour le processus de merge. Approve est vert, Request Changes est rouge, Comment est gris neutre. Le choix dépend de la qualité du code et de l’état de préparation des modifications à l’acceptation.

Approve — le relecteur confirme : le code est écrit correctement, respecte les normes, ne contient pas d’erreurs évidentes et peut être fusionné. Approve ne signifie pas que le code est parfait — seulement qu’il est assez bon pour la production. S’il y a des remarques mineures (style, nommage), elles peuvent être laissées en commentaires sans bloquer le PR.

Request Changes — le relecteur trouve des problèmes à corriger avant le merge : erreurs logiques, vulnérabilités, violations d’architecture, manque de tests. Après Request Changes, le PR est bloqué et une nouvelle approbation du même relecteur est nécessaire pour le débloquer (si l’option Dismiss stale reviews est activée lors de nouveaux commits).

• Approve — code prêt pour le merge, peut être fusionné après le passage du CI.
• Request Changes — corrections obligatoires, PR bloqué jusqu’à une nouvelle revue.
• Comment — remarque générale ou suggestion sans bloquer le PR.

Configuration des règles d’approbation dans le dépôt

Les Branch Protection Rules sont le mécanisme de GitHub pour contrôler la qualité des fusions. Configuré dans Settings → Branches pour chaque branche protégée (main, develop, release/*). Paramètres principaux : nombre d’approbations obligatoires, propriétaires du code (CODEOWNERS), vérification obligatoire CI/CD et interdiction de push sans PR.

Le paramètre Dismiss stale pull request approvals supprime automatiquement les approbations si un nouveau commit est ajouté au PR. Cela garantit que les relecteurs approuvent exactement la version du code qui sera fusionnée. Sans ce paramétrage, l’auteur pourrait ajouter du nouveau code après l’approbation et il arriverait dans main sans nouvelle vérification.

CODEOWNERS — un fichier à la racine du dépôt qui assigne les responsables pour différents répertoires. Si un PR affecte des fichiers appartenant à un propriétaire de code, son approbation devient obligatoire. CODEOWNERS permet de répartir les zones de responsabilité : les développeurs iOS sont responsables des fichiers Swift, DevOps des configurations Docker, les testeurs des scénarios de test.

# Exemple de fichier CODEOWNERS à la racine du dépôt

# Les développeurs iOS possèdent le code Swift
*.swift @team/ios-developers

# DevOps possède la configuration CI/CD
.github/workflows/* @devops-team

# Les ingénieurs QA relisent les tests
**/tests/* @qa-engineers

# Propriétaires par défaut pour tout le reste
* @tech-leads

Code review avant l’approbation : que vérifier

Le code review avant l’approbation est une vérification systématique du code, pas un coup d’œil rapide sur le diff. Un code review de qualité inclut la vérification de l’architecture, de la logique, du style, des tests et de la sécurité. Sans cette vérification, l’approbation devient une formalité plutôt qu’un outil de contrôle qualité.

Ce qui est vérifié en premier : la logique des modifications — le code résout-il la tâche, y a-t-il des effets secondaires, le traitement des cas limites est-il correct. Tests — les nouveaux tests couvrent-ils tous les scénarios, les tests existants passent-ils après les modifications. Sécurité — y a-t-il des injections SQL, XSS, fuites de données sensibles.

Ce qui ne devrait pas être l’objet de la revue : le style de formatage (c’est le rôle des linters et formateurs), les décisions architecturales prises en amont (elles sont discutées avant l’écriture du code). Si une revue dépasse 400 lignes ou prend plus d’une heure, c’est le signe que la tâche est trop grande et nécessite une décomposition. Meilleures pratiques de revue — portions de 200–400 lignes dans les 24 heures suivant la création du PR.

• Logique — exactitude de la solution, gestion des erreurs, cas limites.
• Tests — couverture des nouveaux scénarios, tests existants réussis, absence de tests flaky.
• Sécurité — absence d’injections, échappement des sorties, contrôle d’accès aux données.
• Performances — efficacité des algorithmes, requêtes excessives, fuites mémoire.
• Documentation — la documentation est-elle à jour, les commentaires dans les parties complexes sont-ils clairs.

Workflow avec approbation en équipe

Un workflow typique avec approbation dans une équipe de 5–10 développeurs ressemble à ceci : un développeur crée un PR, assigne des relecteurs (généralement 1–2 personnes de l’équipe ou propriétaires du code), CI/CD exécute des vérifications automatiques. Après réception de toutes les approbations obligatoires et d’un CI vert, l’auteur effectue le merge. Le temps de la création du PR au merge varie de 2 heures à 2 jours selon la complexité.

GitHub Actions permet d’automatiser le merge après approbation. Si les règles de branche sont configurées, GitHub bloque automatiquement le merge jusqu’à ce que toutes les conditions soient remplies. Certaines équipes utilisent bors-ng ou Mergify — des bots qui fusionnent automatiquement les PR après réception de toutes les approbations et réussite du CI. Cela accélère le processus et élimine le facteur humain dans les fusions.

Une approche moderne est le trunk-based development avec des branches à courte durée de vie. Dans ce workflow, l’approbation doit être obtenue en quelques heures, sinon la tâche est considérée comme obsolète et nécessite une resynchronisation avec main. Les équipes avec une forte culture de revue visent un temps d’approbation ne dépassant pas 4 heures ouvrables.

Erreurs d’approbation et comment les éviter

L’erreur la plus courante est l’approbation formelle sans vérification réelle du code. Quand un PR est volumineux ou que l’échéance approche, le relecteur peut cliquer sur Approve sans examiner les modifications. Cela dévalorise tout le processus de code review. Solution : fixer une limite à la taille du PR (pas plus de 400 lignes) et utiliser des outils d’analyse de code (SonarQube, CodeClimate) pour la vérification automatique.

La deuxième erreur est l’approbation excessivement stricte. Attendre un code parfait bloque le développement. Les relecteurs exigent parfois de corriger des remarques stylistiques qui n’affectent pas la qualité. Solution : séparer clairement les remarques obligatoires (bloquantes) et les suggestions optionnelles (commentaires). GitHub permet de spécifier explicitement si un commentaire est bloquant.

La troisième erreur est l’approbation sans vérification CI/CD. Même si le code semble correct, il pourrait ne pas compiler ou échouer aux tests. Les Branch Protection configurées bloquent automatiquement le merge sur CI rouge, mais certaines équipes désactivent cette protection pour gagner en vitesse. Solution : toujours vérifier le statut CI avant d’approuver et ne jamais approuver un PR avec un pipeline rouge.

• Approbation formelle — absence de vérification réelle du code. Solution : limite de 400 lignes par PR.
• Rigueur excessive — blocage pour des remarques stylistiques. Solution : diviser en bloquant et optionnel.
• Ignorer CI — approbation sur pipeline rouge. Solution : toujours vérifier le statut des tests.
• Désignation de l’auteur — approbation par l’auteur du PR. Solution : configurer Branch Protection contre l’auteur.