Des développeurs estiment que les Pull Requests sont obsolètes à l'ère de l'IA et proposent d'aller au Trunk-Based Development : Tout le monde intègre son travail sur une seule branche, plusieurs fois par jour

C’est l’un des débats les plus passionés de l’ingénierie logicielle moderne. Il oppose une culture d'intégration continue ultra-rapide à une autre basée sur la revue de code asynchrone et le contrôle qualité avant fusion. Le cœur de la controverse réside dans la gestion du compromis entre la vitesse de livraison et la réduction des risques en matière de sécurité et de qualité. Certains développeurs sont d’avis que l’approche Trunk-Based Development (TBD) est plus adaptée à l’ère du codage assisté par intelligence artificielle.

Pull Requests et Trunk-Based Development : Quels différences dans les approches ?

Dans le cas du Trunk-Based Development (TBD) tous les développeurs fusionnent leurs modifications de code dans une branche centrale unique appelée « trunk » (pour tronc) et ce, de manière très fréquente, souvent plusieurs fois par jour. Il s’oppose au modèle Gitflow qui est une stratégie de gestion de branches Git basée sur l'utilisation de plusieurs branches de longue durée (principalement main/master) accompagnée de branches de support temporaires. Gitflow est conçu pour organiser les livraisons planifiées et versionnées.

Trunk-based development is apparently the latest innovation in software engineering. I've been advocating for it for 15 years and have rarely used branches or PRs outside of open-source work.

— Nadeem Bitar (@shinzui) October 30, 2026

Le cas du projet Ruby permet de bien illustrer la rupture que représente le Trunk-Based Development

Dans l'ingénierie du projet Ruby, l'intégration continue n'est pas un vain mot : la branche principale est considérée comme le reflet immédiat de l'état de production ou de livraison. Au lieu de préparer une version majeure sur une branche isolée pendant des mois, les contributeurs fusionnent constamment des petits incréments directement sur la branche maîtresse.

Les développeurs créent des branches dont la durée de vie dépasse rarement 24 à 48 heures. Les modifications sont découpées en blocs atomiques (par exemple, ajouter une colonne en base de données, puis ajouter la logique, puis modifier l'interface) plutôt qu'en un bloc massif.

Pour pouvoir fusionner du code incomplet sans casser le comportement global de l'application, l'écosystème Ruby exploite massivement les feature flags (via des gemmes comme Flipper ou Rollout). Le code est déployé en production, mais la fonctionnalité reste invisible pour l'utilisateur final tant qu'elle n'est pas finalisée.

Pousser constamment sur le tronc requiert une confiance absolue dans sa suite de tests. Les serveurs d’intégration continue exécutent automatiquement des milliers de tests unitaires et d'intégration à chaque commit. Si le tronc devient rouge (test en échec), la correction de ce bug devient la priorité absolue de l'équipe (ou le commit est immédiatement annulé / reverted).

Lors de refactorisations majeures, les développeurs Ruby introduisent une couche d'abstraction pour faire cohabiter l'ancien et le nouveau code, migrant les composants un par un au fil des commits quotidiens avant de supprimer l'ancienne route.

Trunk-based development is the way. It requires disciplined coders but has many advantages when done right.

— Michael A. Volz (@michaelvolz_x) October 28, 2026

Malgré ses avantages en termes de vitesse, le Trunk-Based Development suscite de vifs débats et des réticences au sein des équipes d'ingénierie

Sur Reddit, les avis des professionnels sont très partagés quant à l'intégration des tests d'assurance qualité manuels. Certains craignent que l'absence de branches isolées ne repousse l’assurance qualité (QA) manuelle trop tard dans le cycle (parfois après la mise en production), générant des correctifs à chaud stressants. D'autres jugent la QA manuelle incompatible avec le rythme du TBD et estiment qu'elle doit être remplacée par une automatisation stricte.

Une idée reçue tenace veut que le TBD pousse au chaos en éliminant les revues de code. En réalité, il déplace le contrôle vers des revues par paires (Pair Programming) ou des micro-Pull Requests synchrone. L'incompréhension de cette discipline crée une forte résistance culturelle.

Comme tout le monde travaille sur le même tronc commun, une erreur individuelle peut instantanément bloquer l'ensemble des développeurs de l'entreprise (cas d'augmentation du code churn et de rupture de build à grande échelle).

Pour masquer les fonctionnalités incomplètes poussées sur la branche principale, le TBD impose l'usage intensif de feature flags (toggles). Cela introduit une dette technique et une complexité de gestion du code en production si ces indicateurs ne sont pas nettoyés régulièrement.

Starting to hear of more teams skipping PRs and doing true trunk-based dev. The argument: PRs make less sense in the age of agentic coding. The agent is the author, not me. So I, the prompter, am the first reviewer. One or more AIs operate as second reviewer. Eliminating PRs unlocks radically more throughput - At Amp they do over 100 releases a day.

— Cory House (@housecor) October 27, 2026

La démocratisation du Trunk-Based Development offre des enseignements majeurs pour l'industrie du logiciel

Le Trunk-Based Development (TBD) est conseillé lorsque le code est modulaire. Tenter d’opter pour le TBD sur un monolithe doté d'un fort couplage sans automatisation préalable mène droit à l'échec.

On ne peut pas dissocier le TBD d'un pipeline CI/CD ultra-robuste. Si la suite de tests automatisés est lente ou peu fiable (tests instables), la confiance s'effondre et le modèle s'écroule

Le TBD apprend aux organisations qu'un code peut être envoyé en production sans être immédiatement visible ou activé pour l'utilisateur final. Cela donne une flexibilité immense aux équipes produit.

La plus grande leçon est humaine. Le TBD exige de passer d'une culture d'appropriation du code ("ma branche, ma fonctionnalité") à une culture de responsabilité collective ("notre code, notre tronc commun").

Source : Site de référence dédié à l’approche

Et vous ?

Votre entreprise s’appuie-t-elle sur l’approche Trunk-Based Development pour ses projets ? Si oui, quel retour d’expérience pouvez-vous faire ?
Partagez-vous l’avis selon lequel l’approche Trunk-Based Driven trouve beaucoup plus sa pertinence en matière de codage assisté par intelligence artificielle ?
Utilisez-vous l’approche TBD pour vos projets personnels ? Quelle plus-value ?

Voir aussi :

Il existe une meilleure façon de coder avec l'IA, par Namanyay Goel

Les instructions génératives de l'IA sont aussi une dette technique, par Sean Goedecke

Nous pleurons notre métier : Le pire avec ces outils d'IA, c'est qu'ils fonctionnent, ils peuvent écrire du code mieux que vous ou moi, par Nolan Lawson

Le piège du codage par l'IA, par Chris Loy