L’illusion des pull requests : à l’ère de l’IA, pourquoi les PR sont-elles devenues un fardeau pour les développeurs ?

Idée générale

• Il ne s’agit pas de « prononcer la mort du système de PR » en soi, mais de constater qu’à l’ère de l’IA, les PR ne fonctionnent plus comme un mécanisme de transmission de la compréhension.
• Le problème central n’est pas d’abord la qualité du code, mais le fait que le contexte, l’intention et le jugement qui devraient accompagner le code ne sont plus transmis via la PR.
• En conclusion, l’essence des PR reste valable, mais sans changement de leur mode de fonctionnement (les conditions du gate), elles ne pourront plus jouer leur rôle de ligne de défense.

1. Le problème posé : pourquoi les PR vacillent-elles ?

• Attribuer l’échec des PR à la simple « paresse des reviewers » revient à mal poser le problème.
• La vraie cause est l’accumulation d’un phénomène où la PR Review ne transmet plus la compréhension. Autrement dit, le reviewer (le développeur) ne comprend plus l’intention ni le contexte de la PR.
• L’IA réduit brutalement le coût de génération des PR, mais amplifie l’asymétrie existante (générer est rapide, examiner est lent).

2. Le rôle d’origine des PR : non pas une procédure d’approbation du code, mais un contrat de transfert de responsabilité

• Une PR n’était pas simplement une procédure permettant de vérifier la syntaxe du code ou le passage des tests.
• Elle reposait sur une promesse implicite de l’auteur : « je peux expliquer pourquoi j’ai construit cela de cette manière ».
• Le reviewer avait pour rôle d’examiner non seulement le code lui-même, mais aussi le jugement et l’intention de conception qui le sous-tendent.
• En d’autres termes, le bouton Merge n’était pas un simple bouton d’approbation du code, mais la décision issue d’un accord social par lequel l’équipe acceptait de porter collectivement la responsabilité du changement.

3. Le gate était déjà fragile auparavant

• L’open source a toujours été l’environnement qui révélait le plus nettement les faiblesses structurelles des PR.
• Avec la fatigue mentale et physique des mainteneurs, l’écart de contexte et la diversité des contributeurs, les PR avaient déjà tendance à glisser vers une approbation purement formelle.
• L’affaire de la backdoor dans xz Utils a montré moins un échec de l’automatisation qu’une manière dont un gate humain épuisé peut devenir une surface d’attaque.
  Autrement dit, même avant l’IA, le gate des PR était déjà fragile, et les signaux de ses limites s’accumulaient.
  • Affaire de la backdoor dans xz Utils : attaque de la chaîne d’approvisionnement open source dans laquelle un contributeur ayant construit sa crédibilité pendant plus de deux ans a inséré une porte dérobée via une PR.

4. Ce que l’IA a changé : explosion du flot de PR et de l’asymétrie de revue

• Les outils de coding IA ont provoqué une hausse rapide de la vitesse et du volume de génération des PR.
• En revanche, la revue dépend toujours du temps humain, de la concentration et de la compréhension du contexte.
• Il en résulte un schéma fait de plus de code, de PR plus volumineuses, de temps de revue plus longs et de davantage d’incidents.
• Cela ne revient pas à nier en soi le « gain de productivité », mais à avertir qu’une accélération sans gouvernance peut au contraire devenir toxique.

5. Un problème plus profond : du code qui fonctionne, mais que personne ne sait expliquer

• Le risque du code produit par l’IA ne se limite pas à du « code qui casse immédiatement ».
• Le problème plus grave est l’accumulation de code qui passe les tests et compile, mais dont l’explication du pourquoi de son écriture est absente.
• Quand une panne survient plus tard, l’équipe ne corrige plus réellement : elle interprète un code sans intention, en essayant d’en deviner le sens.
• C’est plus dangereux qu’un bug ordinaire, car il manque les traces du jugement de conception et l’auteur de la responsabilité.

6. Le concept clé caché : l’IA comble de façon plausible les vides d’information

• L’IA a tendance, non pas à révéler ce qu’elle ignore, mais à remplir les blancs avec du code plausible.
• Le problème est que ces blancs (hypothèses cachées, contraintes non vérifiées) sont difficiles à voir au stade de la PR.
• Ainsi, le simple fait que « le code tourne / la documentation semble plausible / les vérifications passent » ne suffit plus à garantir la sûreté.
• En fin de compte, ce qu’il faut vérifier au niveau du gate des PR, ce n’est pas la compilation, mais l’existence d’un raisonnement derrière le changement (pourquoi / quoi / sous quelles contraintes).

7. Ce que montre le cas OpenClaw : une échelle et une vitesse que les PR ne peuvent pas absorber

• L’article cite OpenClaw comme un cas emblématique où l’effondrement des PR s’est rejoué en accéléré.
• OpenClaw (nom initial : Clawdbot) était un projet expérimental / playground personnel lancé par Peter Steinberger vers novembre 2025.
• En peu de temps (environ 10 semaines), le projet a connu une croissance explosive, attirant de nombreux utilisateurs, contributions et un fort intérêt externe.
• Dans ce processus, les problèmes de sécurité, les skills/contributions malveillants et la hausse de la charge de revue se sont cumulés, plaçant un mainteneur individuel ou une petite structure de maintenance dans une situation difficilement soutenable.
• Il a ensuite publié (en février 2026) un retour d’expérience sur le projet, expliquant que pour le rendre plus sûr, il fallait davantage de structure, de ressources et un accès aux recherches les plus récentes.
• Puis il a transmis le projet et rejoint OpenAI.
• L’article interprète ce point non comme une critique personnelle, mais comme la manifestation de l’écart entre « la réussite d’un excellent prototype » et « l’exploitation sûre d’une infrastructure générale ».
• Plus encore, l’enjeu central n’est pas une erreur d’implémentation isolée, mais une structure dans laquelle l’ampleur, la vitesse et la diversité des intentions des contributions dépassent la capacité de revue humaine.
• Même si le mainteneur continuait d’améliorer la sécurité, le rythme d’exposition et le rythme de remédiation n’étaient pas engagés dans la même course.
• Autrement dit, l’échec ne vient pas de l’incapacité à construire le projet, mais du fait qu’un gate conçu à l’origine pour un modèle de confiance personnel ou local n’a pas résisté à l’échelle mondiale.

8. La signification du changement de configuration GitHub : non pas une simple fonctionnalité en plus, mais un signal d’alerte

• GitHub a officiellement annoncé, le 13 février 2026, l’ajout d’une option permettant de désactiver les PR.
• Mais l’auteur y voit moins un simple ajout de confort qu’une reconnaissance discrète d’une réalité : dans certains dépôts, la PR elle-même est devenue un risque opérationnel.
• Il faut donc y lire le signal qu’il devient difficile, même pour la plateforme, de maintenir l’hypothèse selon laquelle « les PR sont toujours une bonne chose ».

9. Conclusion pratique de l’article : il ne faut pas abandonner les PR, mais redéfinir le gate.

• Il ne s’agit pas d’appeler à arrêter le développement des outils de code par IA.
• La vraie question n’est pas « faut-il utiliser l’IA ? », mais « faut-il l’utiliser sans gate qui fonctionne ? ».
• Ce qu’il faut, ce n’est pas une liste de règles, mais des principes de fonctionnement comme l’explicabilité, l’anticipation de la conception, la mention des points non vérifiés, le droit de refus des mainteneurs et la traçabilité.
• Une PR dont on ne peut pas retracer les raisons n’est pas un actif intellectuel possédé par l’équipe, mais une dette qui finira par dominer l’équipe.

10. Résumé en une ligne

• Le but d’une PR n’est pas de faire passer du code, mais de transmettre ensemble compréhension et responsabilité.
• La question essentielle à l’ère de l’IA : plutôt que « est-ce que le code fonctionne ? », « peut-on expliquer ce code ? »
• Cette question n’est pas un obstacle à la productivité, mais la condition minimale pour préserver la dernière ligne de défense du logiciel