FR
Réserver un appel

Approche de Développement

Pull requests empilées ou une seule grosse pull request : quelle forme de revue pour le code généré par IA ?

Pull requests empilées ou une grosse PR : taille de revue, coût du rebase, commits signés et agents, chiffres 2026.

Vérifié par Michael Kerkhoff, état au

Définition
Les agents de codage n'ont pas créé le goulot d'étranglement de la revue, ils l'ont déplacé. Écrire une fonctionnalité prend désormais quelques minutes ; la lire suppose toujours qu'un humain s'installe devant un diff. L'exemple détaillé par GitHub est sans détour : une seule consigne pour ajouter une recherche produit génère un modèle de données, une route d'API, le raccordement côté client et quatre états d'interface dans une pull request de 1 721 lignes modifiées. La réaction du relecteur dans ce billet — "je regarderai ça plus tard" — résume tout le problème. Le changement arrive insuffisamment relu non par négligence, mais parce que le colis avait la mauvaise forme. Les pull requests empilées répondent par la décomposition. Au lieu d'une pull request qui fait tout, vous livrez une chaîne ordonnée où chaque branche vise celle située juste en dessous : les données d'abord, puis l'API, puis le raccordement, puis l'interface. Chaque couche reste assez petite pour tenir dans la tête d'un relecteur, chacune part vers la personne qui maîtrise réellement cette couche, et la couche un peut être validée pendant que la couche quatre s'écrit encore. GitHub a livré cela nativement : aperçu fermé le 13 avril 2026, aperçu public le 30 juillet 2026, avec l'extension en ligne de commande gh-stack et une compétence d'agent qui apprend aux agents à construire la pile dès le départ plutôt qu'a découper un diff terminé. La contrepartie est reelle et mérite d'être annoncée d'emblée. Une pile est une chaîne de dépendances, et les chaînes de dépendances s'entretiennent. Modifiez la couche un après la revue et chaque branche supérieure doit être rebasée. GitHub automatise la cascade, mais le bouton de rebase dans le navigateur réinitialise l'auteur du commit et produit des commits non signés — ce qui casse silencieusement tout dépôt exigeant des commits signés. Cette comparaison évalue les deux approches sur la taille de revue, le délai de retour, le coût d'entretien, la mécanique de fusion, la compatibilité avec les règles de protection de branche et l'adéquation aux agents, avec des chiffres vérifiables de 2026 plutôt qu'avec des habitudes d'atelier.
Catégorie
Approche de Développement
Options
Pull requests empiléesUne seule grosse pull request

Comparaison Détaillée

Une analyse comparative des facteurs clés pour vous aider à faire le bon choix.

Pull requests empilées vs Une seule grosse pull request
FacteurPull requests empiléesUne seule grosse pull request
Taille de l'unité soumise a la revueChaque couche ne porte que sur un seul sujet et reste dans la fourchette de 200 à 400 lignes modifiées, là où la revue est mesurablement la plus efficace. GagnantLa fonctionnalité entière arrive en un seul diff ; l'exemple de GitHub compte 1 721 lignes modifiées avant décomposition.
Répartition des relecteursLa couche de données est relue par la personne responsable des données, l'interface par celle qui la maîtrise, et les couches se relisent en parallèle. GagnantUne seule personne doit tenir en tête le modèle de données, le contrat d'API, le raccordement client et les états d'interface en même temps.
Délai de retourLa couche un peut être relue, corrigee et approuvee pendant que la couche quatre s'écrit encore. GagnantRien n'est relisible avant que la fonctionnalité entière soit terminée : tous les retours arrivent a la fin.
Cout d'une modification sur une couche basseUne correction en bas impose un rebase en cascade de toutes les branches supérieures ; gh stack sync automatise la cascade, mais le rebase reste un vrai travail.Une branche, un rebase, aucune chaîne de dépendances a réparer quand un retour arrive. Gagnant
Mécanique de fusionFusionnez toute la pile en une opération, ou intégrez les couches basses et laissez les pull requests supérieures se rebaser et se recibler automatiquement.Une fusion unique, sans état de pile à interpréter ni décision d'intégration partielle.
Commits signés et protection de brancheLe bouton de rebase dans le navigateur s'exécute sur les serveurs de GitHub, réinitialise l'auteur du commit et produit des commits non signés, ce qui casse la protection exigeant des commits signés ; gh stack rebase en local l'evite.Aucun rebase en cascade, donc aucun auteur réinitialise ni signature perdue a surveiller. Gagnant
Plafond de mise a l'échelleLa pratique situe la limite utile à trois ou quatre couches ; au-delà, le suivi des dépendances pèse plus lourd que le gain de revue.Aucune limite structurelle de taille, mais la qualité de la revue et l'attention du relecteur déclinent a mesure que le diff grossit.
Adéquation aux agents de codageLa compétence d'agent de gh-stack apprend aux agents à découper le travail en couches ordonnées pendant l'écriture : la forme devient une contrainte et non une reprise. GagnantEntraînés sur dix ans de pull requests monolithiques, les agents produisent par défaut un gros diff, et le découper après coup est plus pénible que de construire en couches d'emblée.
Score Total · 2 égalités4 / 82 / 8

Statistiques Clés

Données réelles provenant de sources vérifiées du secteur pour appuyer votre décision.

  • L'exemple de GitHub rassemble un modèle de données, une route d'API, le raccordement client et quatre états d'interface dans une seule pull request de 1 721 lignes modifiées, avant sa décomposition en quatre couches empilées. — GitHub Engineering Blog (2026)
  • Une analyse de 1,5 million de pull requests citée au lancement montre que celles comptant de 200 à 400 lignes modifiées présentaient 40 % de défauts en moins et étaient approuvées trois fois plus vite que les plus grosses. — InfoQ (2026)
  • Gartner prévoit que les agents de codage apporteront un gain de productivité de 50 % à chaque étape du cycle de vie logiciel d'ici 2028, augmentant d'autant le rythme auquel de gros diffs arrivent en revue. — Gartner, cite par GitHub Engineering (2026)
  • L'extension en ligne de commande gh-stack de GitHub a atteint 1 093 étoiles et sa première version balisée, v0.1.0, le 29 juillet 2026 — la veille de l'ouverture de l'aperçu public des pull requests empilées. — API REST GitHub, github/gh-stack (2026)
  • Les pull requests empilées sont passées en aperçu fermé le 13 avril 2026 et en aperçu public le 30 juillet 2026 ; l'annonce de l'aperçu public a atteint 780 points sur Hacker News. — GitHub Changelog (2026)
  • La pratique situe le plafond utile à trois ou quatre pull requests par pile, au-delà desquelles la charge mentale du suivi des dépendances pèse plus lourd que le gain de revue. — Alan West, cite par InfoQ (2026)

Toutes les statistiques proviennent de sources tierces vérifiées. La source, l'année et le lien direct sont affichés pour chaque chiffre.

Quand Choisir Chaque Option

Un guide clair basé sur votre situation spécifique et vos besoins.

Notre Recommandation

Choisissez les pull requests empilées lorsque votre goulot d'étranglement est la capacité de revue et que le changement présente des couches naturelles. C'est désormais le cas courant : le directeur technique de TED décrit exactement ce mécanisme dans l'annonce de GitHub — l'IA a rendu les développeuses et développeurs nettement plus productifs, et la nouvelle contrainte est devenue des pull requests si volumineuses que les relecteurs peinaient. Les données soutiennent l'unité plus petite : une analyse de 1,5 million de pull requests citée au lancement montre que celles comptant de 200 a 400 lignes modifiées présentaient 40 % de défauts en moins et étaient approuvées trois fois plus vite que les plus grosses. Une pile est précisément le mécanisme qui maintient chaque pull request dans cette fourchette, même pour une fonctionnalité conséquente. Choisissez une pull request unique lorsque le changement ne porte réellement que sur un seul sujet, lorsque votre dépôt exige des commits signés et que l'équipe n'empruntera pas de manière fiable le chemin local gh stack rebase, ou lorsque la fonctionnalité demanderait plus de trois ou quatre couches. Ce plafond n'est pas arbitraire : la pratique rapporte trois a quatre pull requests par pile, au-delà desquelles le suivi des dépendances coûte plus d'attention que les diffs réduits n'en font gagner. Une pile de cinq couches que personne ne rebase correctement vaut moins qu'un gros diff assumé. Le facteur décisif n'est pas la maturité de l'outillage mais l'identité de qui écrit le code. Un agent entraîné sur dix ans de pull requests monolithiques produira une pull request monolithique tant que vous ne lui direz pas autre chose, et découper après coup un diff terminé de 1 700 lignes est nettement plus pénible que de le construire en couches. Installez la compétence d'agent, donnez à chaque couche un périmètre défini et une personne responsable, et la décomposition se produit au moment de l'écriture, là où elle coûte peu. Sautez cette étape et les pull requests empilées ne sont plus que des branches supplémentaires à rebaser. La forme de la revue doit être une contrainte imposée a l'agent, pas une tâche de nettoyage laissée a l'humain.

Choisissez Pull requests empilées quand...
  • Le changement se découpe naturellement en couches dépendantes — données, API, raccordement, interface — avec des responsables distincts.
  • Un agent de codage a produit un diff que vous ne pouvez honnêtement pas relire en une seule séance.
  • Votre goulot d'étranglement est la capacité de revue, pas la vitesse d'écriture.
  • Vous voulez faire relire et intégrer la couche de base pendant que les couches supérieures s'ecrivent encore.
Choisissez Une seule grosse pull request quand...
  • Le changement ne porte réellement que sur un seul sujet et reste sous quelques centaines de lignes modifiées.
  • Votre dépôt exige des commits signés et l'équipe n'empruntera pas de manière fiable le chemin local gh stack rebase.
  • La fonctionnalité demanderait plus de trois ou quatre couches, là où la charge des dépendances dépasse le gain de revue.
  • Votre équipe n'a pas d'outillage compatible avec les piles et devrait entretenir la chaîne de branches a la main.

Réponses aux questions courantes sur cette comparaison.

Questions Fréquentes

(01)Que sont les pull requests empilées ?
Les pull requests empilées forment une chaîne ordonnée où chaque branche vise non pas la branche principale, mais celle située juste en dessous. Une fonctionnalité devient ainsi une suite de petites couches relisibles indépendamment : modèle de données, puis point d'entrée d'API, puis raccordement client, puis interface. GitHub l'a intégré nativement en 2026 : aperçu fermé le 13 avril, aperçu public le 30 juillet, avec l'extension gh-stack, une carte de pile en tête de chaque pull request et la fusion de toute la pile en un clic.
(02)Les pull requests empilées fonctionnent-elles avec les protections de branche et l'intégration continue existantes ?
Oui. Les vérifications et les règles de fusion sont évaluées par rapport à la base de la pile et non au parent immediat de chaque branche : l'intégration continue s'exécute donc sur chaque couche comme si elle visait directement la branche principale, et vos protections continuent de gouverner ce qui atteint la branche principale. Une réserve compte : le bouton de rebase dans le navigateur s'exécute sur les serveurs de GitHub, ce qui réinitialise l'auteur du commit et produit des commits non signés. Si vos règles exigent des commits signés, utilisez plutôt gh stack rebase en local puis gh stack push.
(03)Pourquoi les agents de codage produisent-ils par défaut une seule énorme pull request ?
Parce que le corpus d'entraînement ressemble à cela. Les agents ont appris sur dix ans de pull requests ou une fonctionnalité entière arrivait en un seul diff : une consigne donne donc un gros changement. La solution consiste à intégrer la forme de la revue dans l'instruction plutôt qu'a la traiter en reprise. Une fois la compétence d'agent gh-stack installée, les agents compatibles apprennent à initialiser une pile, à ajouter chaque couche sur celle du dessous et à ne valider que lorsque les vérifications passent. La décomposition a alors lieu pendant l'écriture, pas après.
(04)Combien de couches une pile doit-elle comporter ?
Trois à quatre constituent le plafond utile rapporte par la pratique ; au-delà, la charge mentale du suivi des dépendances l'emporte sur le gain de revue. Visez des couches qui font chacune une seule chose et se situent entre 200 et 400 lignes modifiées : c'est la fourchette où une analyse de 1,5 million de pull requests a relevé 40 % de défauts en moins et des approbations trois fois plus rapides. Si une fonctionnalité exigeait six ou sept couches, c'est généralement le signe qu'il faut la livrér en deux fonctionnalités distinctes plutôt qu'en une pile très haute.

Besoin d'aide pour décider ?

Réservez une consultation gratuite de 30 minutes et nous vous aiderons à déterminer la meilleure approche pour votre projet spécifique.

Réserver une Consultation GratuiteNous Écrire

Consultation gratuite · Sans engagement · Réponse personnelle