Pull requests : une barrière née de la méfiance

Les pull requests ont émergé dans un contexte bien particulier : celui de l’open source sur Internet, où des inconnus proposent des modifications à des projets maintenus par d’autres inconnus.

Linus Torvalds, submergé par les contributions au noyau Linux, avait besoin d’un mécanisme de filtrage : un sas où les changements proposés pouvaient être examinés avant d’entrer dans le code canonique. GitHub a démocratisé ce workflow, le rendant accessible et élégant.

Dans cet environnement de basse confiance par défaut, la pull request joue un rôle essentiel : elle protège le projet des contributions malveillantes, incompétentes ou simplement mal alignées avec la vision des mainteneurs. C’est une barrière nécessaire quand on ne peut pas faire confiance a priori.

L’importation inadaptée en entreprise

Transposer ce mécanisme tel quel dans une entreprise, c’est importer une solution conçue pour un problème qu’on ne devrait pas avoir.

Une entreprise est - ou devrait être - un environnement de haute confiance. Les développeurs ont été recrutés, évalués, formés. Ils partagent un contexte commun, des objectifs alignés, une responsabilité collective envers le produit.

Exiger qu’un collègue approuve chaque changement avant merge, c’est institutionnaliser la méfiance : « je ne te fais pas suffisamment confiance pour modifier le code sans supervision ». Ce message implicite, répété quotidiennement, érode la responsabilisation et infantilise des professionnels qu’on a pourtant jugés dignes d’embauche.

Le théâtre de la conformité

Les pull requests dans ce contexte deviennent souvent un théâtre de conformité plutôt qu’un véritable filet de sécurité :

• Le reviewer, pressé par ses propres tâches, survole le diff et approuve machinalement
• Ou bien il bloque sur des détails stylistiques pendant que le travail substantiel stagne
• Les cycles de feedback s’allongent : le développeur change de contexte (context switching) vers autre chose, revient des heures ou des jours plus tard, a perdu le fil

Le lead time explose, le flow disparaît, le batch size augmente pour « rentabiliser » le coût de la review.

Tout cela pour une illusion de contrôle qui ne détecte qu’une fraction des vrais problèmes : les bugs subtils passent inaperçus, seules les fautes de frappe sont relevées.

Traiter la cause, pas le symptôme

La vraie question n’est pas « comment améliorer nos code reviews ? » mais « pourquoi avons-nous besoin de cette barrière ? ».

Si la réponse est « parce qu’on ne fait pas confiance à la qualité du code produit », alors la pull request ne traite que le symptôme. La cause racine, à savoir le manque de confiance, reste intacte.

Il vaut mieux investir dans ce qui construit la confiance :

• Pair programming et mob programming où la review est continue et intégrée
• TDD qui garantit un filet de tests
• Intégration continue qui valide chaque commit
• Architecture modulaire qui limite l’impact des erreurs
• Culture blameless qui encourage l’expérimentation

Ces pratiques attaquent la source du problème plutôt que d’ériger des checkpoints.

Vers la suppression des PRs

Tendre vers la réduction ou la suppression des pull requests est un indicateur de maturité organisationnelle.

Les équipes pratiquant le trunk-based development avec commits directs sur main démontrent une confiance élevée : dans leurs tests, dans leur monitoring, dans leurs collègues.

Chaque commit déclenche un pipeline qui vérifie automatiquement ce qu’un reviewer humain vérifierait manuellement, mais plus vite et plus exhaustivement. Les erreurs qui passent sont détectées rapidement et corrigées sans drame.

Cette fluidité n’est pas de l’imprudence ; c’est le fruit d’un investissement dans les fondations (compétences, outillage, culture) qui rend les barrières superflues.

La pull request n’est pas mauvaise en soi ; elle est simplement le signe qu’on n’a pas encore construit l’environnement où elle devient inutile.