# C'est quoi une bonne PR ?

-v-

## Présentation

Julien Lenormand

---

# Une pull request ?

* aussi appellé "merge request"  
* jeu à 2 joueurs pour merger du code  
* ma vision

-v-

## L'ampleur du problème

* quelques anecdotes  
* pas besoin de stats

---

## Comment ouvrir une bonne PR ? (côté reviewé)

Les 4 **C**

* **Courte**  
  * (si possible)  
  * trunk-based ?  
  * focus

-v-

* **Claire**
  * description de PR  
    * résumé  
    * instructions de setup/test/repro  
    * images  
  * nom de branche  
  * messages de commit  
    * conventional commit  
  * rebase (interactif)  
    * philosophies divergentes  
  * auto-relecture  
    * (aidé par l'IA)  
    * premier feedback  
  * "make the change easy, then make the easy change"  
  * “Programs must be written for people to read, and only incidentally for machines to execute.” - SICP

-v-

* **Contextualisée**
  * lien vers le ticket, la doc, les ADRs, ...  
  * commentaires d'auto-relecture  
  * smart commit / issue linking

-v-

* **Complète**
  * inclut les tests (auto-validée)  
  * la doc, l'infra ...  
  * CI verte (formatter, linter, tests, security checks, ...)  
  * cf Definition of Done/Ready

-v-

En bonus :

* pas d'AI slop

---

## Comment bien relire une PR ? (côté reviewer)

Une relecture n'est pas juste une "lecture".

* prendre du recul sur la manière dont la solution répond au besoin  
* voir ce qu'il manque, pas juste ce qui est présent  
  * évaluer tous les angles (ISO/IEC 25002:2024)  
  * **maintenabilité**  
  * voir ce qu'il y a en trop (merci les IAs)  
* discuter collectivement  
  * conventions  
  * dette technique

Notes:
* maintenabilité
* testabilité
* sécurité
* performance
* adéquation fonctionnelle (suitability)
* compatibilité
* fiabilité
* cohérence

-v-

* apprendre le projet
  * tout le monde peut apprendre  
  * pas de hierarchy  
  * "ask dumb questions"  
  * rester informé des évolutions  
* déléguer c'est accepter que ce soit fait différemment  
* conventional comment  
  * > suggestion(non-blocking): j'aurais mis "DTO" dans le nom, afin qu'on le distingue du modèle
  * actionnable feedback  
  * clarté de l'attendu

-v-

* choisir ses batailles
  * "disagree and commit"  
  * "je peux vivre avec"  
  * "good enough"  
  * LGTM si c'est pertinent  
  * un-pedantic  
* "On est gentils avec les humains, mais impitoyables avec le code" - le Permacodeur

---

## Et si on dézoome ?

* garde-fou pour éviter de balancer de la daube aux QAs  
  * voire directement en prod  
* effet Hawtorne : savoir qu'il y aura une relecture, on s'applique +  
* Management de la connaissance et de la responsabilité  
  * co-ownership : transfert du code d'une personne au groupe  
* dérives  
  * Rubber-stamping : LGTM + Approve sans relire (*Goal displacement*)  
    * liability laundering / compliance theater  
  * Pointillisme  
* prise de recul  
  * question avant : bonne chose à faire ?  
  * question après : bonne chose faite ? chose bien faite ?

-v-

* vision LEAN:
  * la pull request est le livrable d'une des étapes de la production logicielle  
  * la review, puis la validation de la pull request, sont les suivantes  
  * chaque commentaire de review, et de surcroit changement à faire, est un défaut, et devrait cherché à être éliminé  
  * autrement dit :  
    > une PR avec + que 3 commentaires est un échec du process  
  * des problèmes à régler en amont :  
    * problèmes de (co-)design  
    * conventions non suivies  
    * absence de definition of ready/done  
    * CI et tooling insuffisants  
    * critères d'acceptance flous  
    * manque de confiance

-v-

* améliorer la DX de la pull request :
  * temps d'attente + délai de livraison (cf DORA)  
  * goulot d'étranglement (cf Kanban)  
  * context switch forcé  
  * outillage et process  
* à problème socio-technique, solution pas que technique  
  * "don't blame the player, blame the game"  
  * everybody's problem

---

## Conclusion

* Interrogez-vous sur vos pratiques de reviews
* Comment faire mieux ?

---

## Sources

* Mon court talk sur l'acte de code review lui-même : https://lenormju.github.io/talk-code-review/index.html
* article par [Glyph - What Is Code Review For?](https://blog.glyph.im/2026/03/what-is-code-review-for.html) (à l'ère de l'IA)
* commentaires sur [Hacker News - The primary purpose of code review is to find code that will be hard to maintain](https://news.ycombinator.com/item?id=48759870)
* discussions avec Nolwenn Doucet, et Stéphane Trebel (alias Le Permacodeur)
* Talk de [Régis Medina - Manager par les "pièces" - Alpes Craft 2024](https://www.youtube.com/watch?v=26sJO3D-evo)
* podcast par [Yacine Hmito - Le LEAN à l'ère de l'IA - If This Then Dev #362](https://www.ifttd.io/episodes/le-lean-a-l-ere-de-l-ia)
* article par [Matt Hall - Software I Love: Gerrit](https://mattjhall.co.uk/posts/software-i-love-gerrit.html)
* post LinkedIn par [Colin Damon - quelques règles avant de review une PR](https://www.linkedin.com/posts/colin-damon_les-reviews-de-prmr-nont-pas-la-cote-mais-share-7411073731554381824-uVJv/)
* article par [Ronni Elken Lindsgaard - Ship/Show/Ask, The Flowchart](https://rlindsgaard.github.io/software%20engineering/2026/05/25/shipshowask-the-flowchart.html) (the Pragmatic Programmer)
* livre de `John Ousterhout - Philosophy of software design` (the intro about using its chapters for code review)
* Talk de [Romain Tellier - Git, devenir le chouchou de son reviewer](https://mixitconf.org/2024/git-devenir-le-chouchou-de-son-reviewer)

---

## Bonus : autres conseils pour les PR

* code review full sync : on la fait ensemble côte-à-côte
* code review full async : chacun travaille quand il veut/peut dans sa timezone et selon ses disponibilités
* hybride : la review est surtout async, mais la discussion se fait sync
* ship/show/ask : selon la nature de la PR, soit on merge sans review, soit mon montre pour merger, soit on demande du feedback
  * 3 tiers : confiance, feedback et douane/bureaucratie ("red tape")
  * comment savoir ? nombre de lignes modifiées, complexité cyclomatique des lignes modifiées ou du fichier modifié, ajout de commentaires pour faire taire le linter, refactoring sans couverture de tests, etc.
* pas de code review : confiance mutuelle
* code review après le merge (non-bloquante)
* pair-prog : code relu pendant son écriture, pas besoin avant de merge
* pair-conception, pair-testing, ... en amont

-v-

* code review pendant le WIP
* bots (IA) de code review
* CI-centric : du moment que la CI passe, on peut merger
* Coding guide + Contributing (exemple : https://rfc.zeromq.org/spec/42/)
* tooling : stacked PRs, Git-compatible local alternatives (jujutsu, Sapling, ...)
* Google readability review (https://abseil.io/resources/swe-book/html/ch03.html#readability_standardized_mentorship_thr) vs code review (https://abseil.io/resources/swe-book/html/ch09.html#code_review-id00002)
* règles d'attribution des PRs : tournant, pour favoriser l'apprentissage, code ownership

---

## Abstract

**C'est quoi une bonne PR ?**

Quelle taille ? Quelle quantité de commits ? Quelle quantité de commentaires ?
Quel genre de commentaires ? Quel lien avec l'outil de ticketing ? 
uel genre d'approbation ? Quel mode de prise en compte des retours ?
Pour quelle durée de développement ? Et quelle durée de relecture ?

Bref, beaucoup de question. Je vais essayer de vous apporter une réponse, et pas seulement "ça dépend".