Qu'est-ce qu'une pull request en développement logiciel ?

Marcus Chen Staff Engineer, Backend & Cloud, YuSMP Group · Met en place la protection de branches, les vérifications CI et les workflows de revue de code pour des équipes produit aux États-Unis et en Europe

Qu'est-ce qu'une pull request en développement logiciel ? C'est une demande formelle de fusion d'un ensemble de modifications de code d'une branche vers une autre — le plus souvent d'une branche de fonctionnalité éphémère vers main — après relecture par d'autres ingénieurs. Les développeurs l'abrègent en « PR », et dans la plupart des équipes rien n'arrive en production sans elle : c'est dans la PR que vivent ensemble le diff, la justification, les résultats de tests et la discussion de revue.

Les équipes qui pilotent des services de software product engineering à grande échelle traitent la pull request comme la seule porte que chaque modification doit franchir — relecture, tests et contrôles de sécurité ont lieu là, pas après la mise en production. La PR devient ainsi l'un des endroits les moins coûteux pour détecter un bug, et l'un des plus coûteux pour perdre du temps quand les revues stagnent.

L'échelle est considérable. Selon le rapport Octoverse 2025 de GitHub, les développeurs ont fusionné en moyenne 43,2 millions de pull requests par mois entre septembre 2024 et août 2025, soit 23 % de plus que l'année précédente, pour près d'un milliard de commits poussés. Vous trouverez ci-dessous la définition de la pull request, son cycle de vie complet, des instructions pas à pas pour en créer et en relire une, les trois méthodes de fusion, les workflows courants, les benchmarks 2026 et des règles pratiques face à la vague croissante de PR générées par l'IA.

Qu'est-ce qu'une PR en développement logiciel ?

Une PR en développement logiciel est une pull request : une proposition de fusionner une branche de modifications de code dans une autre branche, relue et approuvée par l'équipe avant la fusion. La définition de la pull request en une phrase : un ensemble de modifications relisible, discutable et testable qui demande aux responsables d'une branche cible de l'accepter.

Une pull request compare toujours deux branches. La branche source (head ou compare) contient le nouveau travail ; la branche de base (la cible) est celle où il doit arriver, en général main ou develop. La plateforme affiche l'écart entre les deux sous forme de diff — lignes ajoutées en vert, lignes supprimées en rouge — et permet aux relecteurs de commenter chaque ligne.

Trois rôles interviennent dans une PR typique. L'auteur écrit le code, ouvre la demande et répond aux retours. Un ou plusieurs relecteurs lisent le diff, posent des questions, suggèrent des modifications et approuvent. Un mainteneur ou l'auteur (une fois les approbations obtenues) effectue la fusion. Les pull requests vivent sur la plateforme d'hébergement Git : GitHub, GitLab, Bitbucket et Azure DevOps mettent en œuvre la même idée, comme le rappelle la présentation des pull requests d'IBM, même si les boutons portent des noms différents.

Que signifie PR en développement logiciel ?

En développement logiciel, PR signifie pull request — et non relations presse ou publiques. Le nom vient du modèle open source d'origine : un contributeur sans droit d'écriture poussait ses modifications dans sa propre copie et demandait au mainteneur de les tirer (to pull). Aujourd'hui l'auteur pousse souvent dans le même dépôt, mais le nom est resté. Les ingénieurs utilisent « PR » comme nom (« ouvrir une PR »), comme étape (« c'est en PR ») et comme unité de travail (« trois PR fusionnées aujourd'hui »).

Pull request ou merge request

Une pull request et une merge request sont la même chose sous deux noms : GitHub, Bitbucket et Azure DevOps disent « pull request », GitLab dit « merge request » (MR, demande de fusion) parce que l'action finale est une fusion. La documentation GitLab décrit les merge requests comme l'endroit où l'on propose, relit et fusionne des modifications de code — exactement le rôle d'une PR ailleurs.

Comment fonctionne une pull request ?

Une pull request fonctionne comme une boucle courte : vous créez une branche à partir de main, committez vos modifications, ouvrez une PR, laissez l'automatisation et les relecteurs la vérifier, corrigez ce qu'ils trouvent, puis fusionnez une fois l'approbation obtenue. Toute PR en développement logiciel suit à peu près les sept mêmes étapes :

1. Créer une branche. Partez du main le plus récent pour isoler votre travail de celui des autres.
2. Committer les modifications. Faites des commits petits, logiquement regroupés, avec des messages clairs.
3. Pousser la branche. Envoyez-la sur le dépôt distant partagé (GitHub, GitLab, Bitbucket ou Azure DevOps).
4. Ouvrir la pull request. Choisissez la branche de base, rédigez un titre et une description, liez le ticket et sollicitez des relecteurs.
5. Lancer les vérifications automatisées. Le pipeline CI/CD compile le code et exécute tests unitaires, linters, contrôles de types et analyses de sécurité ; les résultats s'affichent comme status checks sur la PR.
6. Relire et corriger. Les relecteurs commentent et demandent des changements ; l'auteur pousse de nouveaux commits sur la même branche et la PR se met à jour automatiquement.
7. Approuver et fusionner. Quand les approbations et vérifications requises sont au vert, la PR est fusionnée dans la branche de base, la branche de fonctionnalité est supprimée et la modification part vers le déploiement.

L'idée clé : la PR est un objet vivant. Chaque nouveau commit sur la branche source met à jour le diff, relance les vérifications et marque les anciens commentaires comme obsolètes, si bien que la discussion reflète toujours le code actuel. Rien ne touche la branche de base tant que personne ne clique sur fusionner.

Anatomie d'une bonne pull request

Une bonne pull request est petite, ciblée et explicite : un relecteur doit comprendre ce qui a changé, pourquoi et comment le vérifier sans interroger l'auteur. Dans nos équipes, une PR qui remplit ces sept points est généralement relue le jour même :

• Un titre précis. « Ajouter un retry avec backoff au handler du webhook de paiement » vaut mieux que « Corriger un bug ».
• Une description qui répond à quoi, pourquoi et comment tester. Deux ou trois courts paragraphes ou un modèle de PR rempli.
• Un ticket lié. L'identifiant de l'issue ou de la story relie le code au besoin métier et préserve la piste d'audit.
• Un petit diff. Un seul objectif par PR ; refactoring et nouvelle fonctionnalité vont dans des PR séparées.
• Une preuve visuelle pour les changements d'interface. Captures avant/après ou courte vidéo d'écran.
• Une checklist complétée. Tests ajoutés, documentation à jour, migrations réversibles, feature flag en place — selon votre modèle de PR.
• Les bons relecteurs et libellés. Un fichier CODEOWNERS sollicite automatiquement l'équipe responsable ; des libellés comme security ou breaking-change orientent l'attention.

Créer une pull request, étape par étape

Pour créer une pull request, vous poussez une branche de fonctionnalité sur le dépôt partagé et ouvrez une PR vers la branche de base, via l'interface web ou en ligne de commande. Voici la séquence que nous utilisons sur GitHub ; GitLab, Bitbucket et Azure DevOps ne diffèrent que par le nom des boutons :

1. Mettre à jour votre main local. Lancez git checkout main puis git pull pour partir du code le plus récent.
2. Créer une branche de fonctionnalité. git checkout -b feature/payment-retry — avec un nom explicite, lié au ticket.
3. Modifier et committer. git add . puis git commit -m "Add exponential backoff to payment webhook". Gardez des commits petits et parlants.
4. Pousser la branche. git push -u origin feature/payment-retry l'envoie et définit l'upstream.
5. Ouvrir la PR. Cliquez sur « Compare & pull request » dans l'interface web, ou lancez gh pr create --base main --fill avec la GitHub CLI.
6. Compléter la description et les relecteurs. Remplissez le modèle, liez le ticket, sollicitez des relecteurs ou laissez CODEOWNERS les assigner.
7. Choisir brouillon ou prête. Ouvrez-la en draft si vous voulez un retour précoce ou un passage de CI avant la fin du code ; marquez-la « Ready for review » quand elle l'est.

Les draft pull requests méritent d'être utilisées plus souvent. Elles signalent « regardez la direction, pas les détails », laissent la CI valider la branche pendant que vous continuez et ne peuvent pas être fusionnées par erreur.

Comment relire une pull request

Pour relire une pull request, lisez d'abord la description, puis le diff, et vérifiez cinq points : exactitude, tests, lisibilité, sécurité et performance. Concluez par l'un de trois verdicts — commenter, approuver ou demander des modifications. Une checklist pratique pour le relecteur :

• Exactitude. Le code fait-il ce que disent la description et le ticket, y compris pour les cas limites et les chemins d'erreur ?
• Tests. Le nouveau comportement est-il testé, et les tests échoueraient-ils si la modification était annulée ?
• Lisibilité et conception. Les noms sont-ils clairs, la logique est-elle dans la bonne couche, un nouvel arrivant comprendrait-il ?
• Sécurité. Validation des entrées, contrôles d'autorisation, secrets, risques d'injection, nouvelles dépendances.
• Performance et exploitation. Requêtes N+1, boucles non bornées, index manquants, logs et métriques pour le nouveau chemin.

Indiquez le poids de chaque commentaire. Un commentaire bloquant doit être corrigé avant la fusion ; un nit (« nit : renommer en retryCount ») est une finition facultative. Les plateformes proposent aussi les suggested changes : le relecteur écrit la ligne de remplacement exacte et l'auteur l'applique en un clic, ce qui supprime un aller-retour complet pour les petites corrections.

La rapidité compte autant que la rigueur. Dans « Modern Code Review: A Case Study at Google » (Sadowski et al., ICSE-SEIP 2018), fondée sur environ neuf millions de modifications relues, la modification médiane ne faisait que 24 lignes, plus de 35 % des modifications ne touchaient qu'un seul fichier, l'attente médiane du premier retour était inférieure à une heure pour les petites modifications (environ cinq heures pour les très grandes) et la latence médiane globale de revue était inférieure à quatre heures. Petites modifications et premier retour rapide vont de pair.

Fusionner une pull request : merge commit, squash ou rebase

Fusionner une pull request consiste à appliquer ses commits sur la branche de base, et GitHub propose trois méthodes qui ne diffèrent que par l'historique obtenu. Selon la documentation GitHub (« About pull request merges »), un merge commit conserve tous les commits et ajoute un point de fusion explicite, squash and merge combine tous les commits en un seul, et rebase and merge rejoue les commits un à un pour garder un historique linéaire.

Avant même que ces boutons fonctionnent, les règles de protection de branche décident si la fusion est autorisée : revues approuvées obligatoires, status checks obligatoires, discussions résolues et, en option, une merge queue qui teste chaque PR contre la branche de base la plus récente avant de la fusionner, pour que deux PR vertes séparément ne puissent pas casser main ensemble.

Un conflit de fusion survient quand la branche de base a modifié les mêmes lignes que votre PR. Résolvez-le en mettant votre branche à jour (git fetch puis git rebase origin/main ou git merge origin/main), en tranchant les passages en conflit, en relançant les tests et en poussant. Les PR petites et éphémères entrent rarement en conflit ; celles d'une semaine presque toujours.

Les workflows de pull request utilisés par les équipes

Les workflows de pull request définissent comment les branches sont créées, combien de temps elles vivent et où elles sont fusionnées. La plupart des équipes en utilisent un parmi cinq, et le guide IBM sur les pull requests cite les quatre premiers comme les schémas courants.

Workflow par branche de fonctionnalité

Dans le workflow par branche de fonctionnalité, chaque modification a sa propre branche issue de main et y revient via une pull request. C'est le choix par défaut de la plupart des équipes produit : simple à expliquer, facile à protéger avec des règles de branche et bien pris en charge par toutes les plateformes.

Workflow par fork

Dans le workflow par fork, les contributeurs copient tout le dépôt dans leur propre compte, poussent dans ce fork et ouvrent une pull request vers le projet d'origine. Les projets open source s'appuient dessus, car les contributeurs externes n'ont jamais besoin d'un accès en écriture au dépôt principal.

Git-flow

Git-flow utilise des branches durables main et develop ainsi que des branches de fonctionnalité, de release et de hotfix, chacune fusionnée par PR. Il convient aux produits à versions planifiées — applications mobiles, logiciels on-premise — mais ajoute de la lourdeur pour les équipes qui déploient en continu.

Trunk-based development avec des PR éphémères

En trunk-based development, les ingénieurs fusionnent de petites PR dans main au moins une fois par jour, et les fonctionnalités inachevées restent masquées derrière des feature flags. Les branches vivent des heures, pas des semaines, ce qui rend les conflits rares et soutient la livraison continue.

Pull requests empilées (stacked PRs)

Les pull requests empilées découpent une grosse fonctionnalité en une chaîne de petites PR dépendantes, chacune basée sur la précédente. Les relecteurs reçoivent de petits diffs, l'auteur avance sans attendre chaque revue, et la pile est fusionnée dans l'ordre.

Pourquoi les pull requests comptent : bénéfices pour la qualité et les équipes

Les pull requests comptent parce qu'elles placent un point de contrôle unique et tracé entre l'idée d'un développeur et la production. Les principaux bénéfices :

• Porte qualité. Bugs, tests manquants et problèmes de conception sont détectés tant que la correction coûte peu.
• Partage de connaissances. Au moins deux personnes comprennent chaque modification, ce qui réduit le risque lié au « bus factor ».
• Traçabilité et piste d'audit. Qui a modifié quoi, qui l'a approuvé et pourquoi est enregistré — les preuves qu'attendent les auditeurs pour la gestion des changements SOC 2 et ISO 27001.
• Intégration plus rapide. Les nouveaux ingénieurs apprennent la base de code et les conventions de l'équipe en lisant et relisant des PR.
• Sécurité « shift-left ». Vérification des dépendances, détection de secrets et analyse statique tournent sur chaque PR, et non une seule fois avant la release.
• Intégration CI. La PR est le déclencheur naturel des builds, des tests et des environnements de prévisualisation, et ces vérifications forment le cœur de l'assurance qualité en développement logiciel.

Métriques de pull request et benchmarks 2026

Cinq métriques de pull request montrent si votre processus de revue aide ou freine la livraison : temps de prise en charge, temps de revue, cycle time, taille de PR et taux d'acceptation (de fusion). Elles se rattachent directement aux KPI du développement logiciel et aux métriques DORA comme le lead time for changes.

• Temps de prise en charge (pickup time) — de l'ouverture de la PR (ou de son passage en « prête ») à la première activité de revue.
• Temps de revue — de la première revue à l'approbation ou à la fusion.
• Cycle time — du premier commit à la fusion ou au déploiement ; la prise en charge et la revue en sont souvent les plus gros composants.
• Taille de PR — lignes modifiées ; le meilleur prédicteur de la durée d'une revue.
• Taux d'acceptation — la part des PR ouvertes qui sont fusionnées dans une fenêtre donnée.

Le LinearB 2026 Software Engineering Benchmarks Report, fondé sur 8,1 millions de pull requests de 4 800 équipes et 163 820 contributeurs dans 42 pays, ventile ces métriques selon la manière dont le code a été écrit. Les valeurs sont au 75e centile ; l'acceptation correspond au taux de fusion sous 30 jours :

Utilisez ces chiffres comme repère, pas comme objectif. Suivez vos propres médianes chaque semaine, observez la tendance et regardez d'abord le temps de prise en charge : c'est en général le délai le plus facile à supprimer, car c'est de l'attente pure.

Les pull requests générées par l'IA en 2026 : ce qui change pour les relecteurs

Les pull requests générées par l'IA sont plus volumineuses, attendent plus longtemps leur revue et sont bien moins souvent fusionnées que celles écrites par des humains ; elles appellent donc des règles plus strictes, pas plus souples. Les benchmarks LinearB 2026 montrent des PR assistées par IA de 408 lignes contre 157 pour les PR sans IA (75e centile), des temps de prise en charge de 8,3 heures pour les PR assistées et 17,6 heures pour les PR agentiques contre 3,4 heures sans IA, et un taux d'acceptation à 30 jours de 32,7 % pour les PR d'IA contre 84,4 % pour les PR manuelles. Même dans le groupe d'élite, les PR manuelles sont acceptées à plus de 95 % et les PR d'IA à peine au-dessus de 71 %.

Le phénomène s'explique facilement : les relecteurs hésitent à prendre un gros diff que personne dans l'équipe n'a vraiment écrit, et le rejettent quand l'intention n'est pas claire. Voici les parades que nous appliquons dans nos équipes :

1. Plafonner la taille. La même limite s'applique aux PR d'IA et aux PR humaines ; un agent qui produit 1 000 lignes doit découper son travail en pile.
2. Exiger des tests pour chaque PR d'IA. Aucun nouveau comportement sans tests qui échouent sur l'ancien code.
3. Désigner un responsable humain. Chaque PR générée par l'IA a un ingénieur nommé qui répond aux questions de revue et assume la fusion.
4. Utiliser les bots de revue IA comme premier filtre. Les relecteurs automatiques repèrent bien les problèmes de style, les bugs évidents et les contrôles de null manquants, mais l'approbation finale reste à une personne qui comprend le système.
5. Décrire l'intention, pas seulement le résultat. La description de la PR doit expliquer le problème et l'approche choisie, que le code ait été écrit par un humain ou par un agent.

Bonnes pratiques pour les pull requests

La bonne pratique la plus efficace consiste à garder les pull requests petites et ciblées ; la plupart des autres pratiques servent à rendre ces petites PR faciles à relire et à fusionner vite. Sept règles qui tiennent quelles que soient l'équipe et la stack, en complément des bonnes pratiques du développement logiciel plus générales :

1. Garder les PR petites. Une limite d'équipe d'environ 200 à 400 lignes modifiées fonctionne bien ; la modification médiane de 24 lignes chez Google (2018) et les 157 lignes au 75e centile des PR sans IA chez LinearB (2026) montrent à quel point les PR saines sont petites.
2. Un seul objectif par PR. Ne mélangez pas refactoring, mise à jour de dépendances et fonctionnalité dans un même diff.
3. Rédiger une description claire. Utilisez un modèle de PR avec quoi, pourquoi, comment tester et risques.
4. Ouvrir des drafts tôt. Obtenez un avis sur la direction avant d'investir dans la finition.
5. Automatiser toutes les vérifications possibles. Formatage, lint, tests, contrôles de types et analyses de sécurité doivent tourner à chaque push, pour que les relecteurs se concentrent sur la logique et la conception.
6. Fixer un SLA de revue. Par exemple, première réponse sous quatre heures ouvrées et décision sous un jour ouvré.
7. Résoudre toutes les discussions avant de fusionner. Activez la règle dans la protection de branche pour que rien ne soit fusionné avec des questions ouvertes.

Problèmes fréquents de pull request et comment les résoudre

La plupart des problèmes de pull request viennent de la taille et de l'attente : les grosses PR attendent plus longtemps, entrent plus souvent en conflit et reçoivent des revues plus superficielles. Les cinq problèmes que nous voyons le plus souvent, avec leur solution :

• PR trop volumineuses. Les relecteurs les survolent ou les repoussent. Solution : découper par couche ou utiliser des PR empilées, et ajouter un avertissement de taille dans la CI.
• Goulots d'étranglement de revue. Un seul ingénieur senior relit tout. Solution : répartir la responsabilité via CODEOWNERS, faire tourner les relecteurs et suivre le temps de prise en charge.
• Conflits de fusion. Les branches longues s'éloignent de main. Solution : fusionner chaque jour, rebaser souvent et utiliser des feature flags plutôt que des branches longues.
• Approbations de complaisance. « LGTM » en quelques secondes sur un diff de 900 lignes. Solution : des PR plus petites, une checklist de revue et l'approbation obligatoire d'un code owner.
• PR abandonnées. Des branches délaissées encombrent la file. Solution : étiqueter automatiquement les PR inactives depuis sept jours et les fermer ou les relancer lors d'un tri hebdomadaire.

FAQ

Publié le 7 octobre 2026. Sources : IBM Think, « What is a pull request? » ; GitHub Docs, « About pull request merges » ; GitHub Octoverse 2025 ; LinearB 2026 Software Engineering Benchmarks Report ; Sadowski et al., « Modern Code Review: A Case Study at Google », ICSE-SEIP 2018 ; GitLab Docs, « Merge requests ». Les benchmarks sont des repères ; confrontez-les aux données de votre propre équipe.