Pull Request : qu'est-ce que c'est, processus de création et code review

Qu'est-ce qu'un Pull Request ?

Pull Request (PR) est une demande formelle d'inclure des modifications d'une branche à une autre dans un système de contrôle de version distribué. Le PR est un élément central du développement collaboratif sur les plateformes GitHub, GitLab et Bitbucket, combinant discussion du code, tests automatisés et processus d'approbation des modifications.

Le nom « Pull Request » reflète l'essence de l'opération : un développeur demande (request) au propriétaire du référentiel de « tirer » (pull) ses modifications. Le terme a été introduit par GitHub en 2008 — auparavant, un mécanisme similaire existait sous forme de correctifs et de merge requests (terme de GitLab). Aujourd'hui, le PR est la norme de facto pour le développement d'équipe avec Git.

Selon GitHub Octoverse, 2025, 89 % des projets open-source exigent la création d'un PR pour apporter des modifications. Dans le développement d'entreprise, ce chiffre atteint 95 %. Le PR est devenu non seulement un outil technique, mais une partie de la culture de développement : à travers les PR s'effectuent le transfert de connaissances, la détection de bogues et l'alignement des décisions architecturales.

Composants d'un Pull Request

Un PR typique se compose d'un titre, d'une description, d'une liste des fichiers modifiés (diff), des commentaires des relecteurs et des statuts des vérifications CI. Chaque PR est lié à une branche source et à une branche cible spécifiques, et après la fusion peut être supprimé automatiquement.

Comment créer un Pull Request

Créer un PR commence par la publication d'une branche de fonctionnalité dans le référentiel distant. Après le push, le développeur ouvre un PR via l'interface de la plateforme ou via CLI (gh, glab). Examinons le processus en prenant GitHub comme exemple.

Push de la branche et ouverture du PR

La première étape consiste à pousser la branche de fonctionnalité vers le référentiel distant et à créer un Pull Request via l'interface web ou la ligne de commande.

# Créer et pousser une branche de fonctionnalité
git checkout -b feature/biometric-auth
git add src/auth/
git commit -m "feat: add biometric authentication"
git push -u origin feature/biometric-auth

# Créer un PR via GitHub CLI
gh pr create --title "feat: add biometric authentication" \
  --body "Implements fingerprint and face recognition login.
  Closes #142" \
  --base develop

Après la création d'un PR, GitHub exécute automatiquement les pipelines CI (GitHub Actions), vérifie les conflits avec la branche cible et invite les relecteurs. Le modèle de description du PR peut être configuré via .github/PULL_REQUEST_TEMPLATE.md afin que tous les PR contiennent les sections requises : objectif, modifications, tests, tâches connexes.

Description et étiquetage

Une description de PR de qualité comprend : un lien vers la tâche (issue/ticket), une brève description des modifications, des instructions de test et une liste des modifications connexes. Les labels (bug, feature, refactoring) aident à catégoriser le PR, tandis que les assignees et reviewers sont attribués automatiquement via CODEOWNERS.

# Attribuer des relecteurs via CODEOWNERS (fichier à la racine du référentiel)
# Exemple .github/CODEOWNERS :
# src/auth/ @team-auth @senior-dev
# src/api/ @team-backend
# *.kt @kotlin-team

# Créer un PR avec attribution de relecteurs via gh cli
gh pr create --reviewer "team-auth" --label "feature"

CODEOWNERS est un mécanisme standard de GitHub/GitLab pour attribuer automatiquement des relecteurs en fonction des fichiers modifiés. Par exemple, toute modification dans le répertoire src/auth/ attribue automatiquement team-auth et senior-dev comme relecteurs. Cela accélère le processus et garantit que les bonnes personnes voient le PR.

Mise à jour du PR suite aux relectures

Après avoir reçu les commentaires du relecteur, le développeur effectue des corrections dans la même branche de fonctionnalité et pousse de nouveaux commits — le PR se met à jour automatiquement. Il est important de ne pas réécrire l'historique (rebase) dans une branche de fonctionnalité publiée si le PR est déjà ouvert, car cela casse les liens vers des commits spécifiques dans les commentaires.

# Apporter des modifications selon les commentaires du relecteur
git checkout feature/biometric-auth
# corriger le code
git commit -m "fix: handle biometric timeout per review"
git push

# le PR sera mis à jour automatiquement
# Après approbation — fusionner le PR via l'interface GitHub

Le processus de code review

Le code review est un élément central d'un Pull Request. Le relecteur vérifie les modifications quant à leur exactitude, leur style de code, leur sécurité et leur cohérence architecturale. Une relecture de qualité prévient non seulement les bogues, mais diffuse également les connaissances sur la base de code au sein de l'équipe.

Les Engineering Practices de Google (2025) recommandent les principes de code review suivants : le relecteur doit comprendre le contexte des modifications, donner des recommandations spécifiques plutôt que des remarques générales et séparer les commentaires techniques et stylistiques. Le temps de relecture ne doit pas dépasser 24 heures à partir du moment de la création du PR.

Pour le développement mobile, le code review inclut des vérifications spécifiques : compatibilité avec targetSdk, gestion correcte du lifecycle (Android) / view lifecycle (iOS), absence de fuites mémoire (LeakCanary, Instruments), prise en charge du thème sombre et localisation. Ces vérifications peuvent être automatisées via des linters et Detekt/ktlint.

Types de commentaires

Les plateformes de PR prennent en charge trois types de commentaires : généraux (sur l'ensemble du PR), en ligne (sur une ligne de code spécifique) et suggestions (avec code de remplacement). Les suggestions permettent d'appliquer la modification en un clic, accélérant le processus et réduisant le nombre d'itérations.

Une fois que tous les commentaires sont résolus et que les vérifications CI sont passées, le relecteur envoie une approbation (Approved). Le PR peut être fusionné. GitHub et GitLab prennent en charge les règles de protection de branche : nombre d'approbations requis, vérifications CI obligatoires et interdiction de push dans main sans PR. Pour les projets mobiles, la protection de branche inclut également la vérification de build : un PR ne peut pas être fusionné si l'application ne compile pas (gradle build failed / xcodebuild failed).

Résolution des conflits dans le PR

Les conflits de fusion dans un Pull Request sont une situation courante dans le travail d'équipe actif. Les plateformes proposent une résolution des conflits via l'interface web (pour les conflits simples) ou recommandent de résoudre localement. GitHub Actions vérifie automatiquement la capacité de fusion à chaque push dans la branche de fonctionnalité et marque le PR comme conflictuel si la fusion est impossible.

Bonnes pratiques Pull Request

Les Pull Requests efficaces accélèrent le code review et réduisent le nombre de bogues. Une étude de SmartBear (2025) a montré que les PR de jusqu'à 200 lignes de code reçoivent 2 fois plus de commentaires pertinents que les PR de plus de 1000 lignes, et le temps de relecture est réduit de 3 fois.

• Petits PR — la taille optimale est de 100 à 300 lignes. Divisez les gros PR en parties logiques : chaque PR résout une tâche. Cela simplifie la relecture et réduit la probabilité de conflits
• Description claire — titre selon Conventional Commits (feat:, fix:, refactor:), le corps contient « quoi et pourquoi » plutôt que « comment » (le code parle de lui-même). Modèle : objectif → modifications → tests → issues connexes
• Retour rapide — relecture dans les 24 heures. Si un PR attend plus d'un jour, l'équipe perd le contexte et le nombre de conflits de fusion augmente
• Automatisation — les linters, formatteurs et tests doivent s'exécuter automatiquement lors de la création d'un PR. Ne permettez pas la fusion de PR avec des vérifications CI rouges
• Draft PR — utilisez pour une discussion précoce de l'architecture. Le Draft PR ne nécessite pas de relecture et ne peut pas être fusionné, mais permet de montrer le code aux collègues à un stade précoce

Pratiques supplémentaires : ne créez pas de PR le vendredi soir (personne ne fera de relecture avant lundi), demandez la relecture à 1-2 personnes (plus ralentit le processus sans améliorer la qualité), utilisez squash merge pour compresser l'historique avant la fusion. Pour les projets mobiles, il est également recommandé d'ajouter un lien vers le build de test (Firebase App Distribution / TestFlight) dans la description du PR afin que le relecteur puisse vérifier les modifications dans l'application en cours d'exécution.

Pull Request sur différentes plateformes

Les principales plateformes pour travailler avec les Pull Requests sont GitHub, GitLab et Bitbucket. Malgré le concept partagé, chacune a des caractéristiques qui méritent d'être considérées lors du choix d'un outil pour l'équipe.

GitHub est la plateforme la plus populaire avec la plus grande communauté, Actions pour CI/CD et un vaste écosystème d'applications (GitHub Marketplace). GitLab se distingue par son CI/CD intégré et sa capacité de déploiement self-hosted complet. Bitbucket est étroitement intégré à Jira et à l'écosystème Atlassian, populaire dans les environnements d'entreprise.

Pour le développement mobile, le choix de la plateforme est souvent déterminé par les capacités CI/CD : GitHub Actions prend en charge les runners macOS pour les builds iOS, GitLab dispose de runners intégrés pour iOS/Android, Bitbucket s'intègre bien avec Firebase Test Lab. Quelle que soit la plateforme, le processus de PR reste le même : branche → relecture → CI → fusion.